diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml
new file mode 100644
index 0000000..112a177
--- /dev/null
+++ b/.github/workflows/release.yaml
@@ -0,0 +1,40 @@
+on:
+  push:
+    paths-ignore:
+      - ".github/**"
+      - "!.github/workflows/release.yaml"
+    branches:
+      - master
+name: 🚀 Deploy website on push
+jobs:
+  web-deploy:
+    name: 🎉 Deploy
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          submodules: true
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV 
+      - uses: actions/cache@v4
+        with:
+          key: mkdocs-material-${{ env.cache_id }}
+          path: .cache
+          restore-keys: |
+            mkdocs-material-
+      - run: pip install -r requirements.txt
+      # - run: cd mkdocs-theme-pagerduty && python3 setup.py install
+      - run: mkdocs build --clean
+      - name: 📂 Sync files
+        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
+        with:
+          server: ${{ secrets.FTPS_SERVER }}
+          username: ${{ secrets.FTPS_USERNAME }}
+          password: ${{ secrets.FTPS_PASSWORD }}
+          protocol: ftps
+          port: 21
+          local-dir: site/
+          server-dir: opsguides/postmortems/
diff --git a/docs/culture/accountability.md b/docs/culture/accountability.md
index 0a73f8a..f55b185 100644
--- a/docs/culture/accountability.md
+++ b/docs/culture/accountability.md
@@ -1,21 +1,21 @@
 ---
 cover:
-description: A successful postmortem process is based on a culture of honesty, learning, and accountability. Culture change requires management buy-in, but you can lead culture change no matter your role. This guide describes common challenges faced in building a culture of continuous learning through postmortems and strategies for overcoming these challenges.
+description: 成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。文化の変革には経営陣の賛同が必要ですが、あなたの役割に関わらず文化の変革をリードすることができます。このガイドでは、ポストモーテムを通じた継続的学習の文化を構築する際に直面する一般的な課題と、それらを克服するための戦略について説明します。
 ---
 ![Accountability](../assets/img/headers/Postmortems-Accountability.png)
 
-Information sharing and transparency also support an environment that cultivates accountability. A common challenge to effective postmortems is that, after analyzing the incident and creating action items to prevent recurrence, information sharing to increase transparency is never done.
+情報共有と透明性は、説明責任（accountability）を育む環境をサポートします。ポストモーテムの効果を低減させるよくある課題として、インシデントを分析し再発を防ぐためのアクションアイテムを作成した後、透明性を高めるための情報共有が行われないことがあります。
 
-Start by setting a policy for when postmortem action items should be completed. At PagerDuty, high-priority action items needed to prevent a Sev-1 incident from recurring should be completed within 15 days after an incident. Action items from a Sev-2 incident should be addressed within 30 days. Communicate this expectation to all of engineering and make sure it is documented for future reference.
+まず、ポストモーテムのアクションアイテムがいつ完了すべきかのポリシーを設定します。PagerDutyでは、Sev-1インシデントの再発を防ぐのに必要な高優先度のアクションアイテムは、インシデント後15日以内に完了する必要があります。Sev-2インシデントからのアクションアイテムは30日以内に対処する必要があります。この期待値をエンジニアリング組織全体に伝え、将来的にも参照できるよう文書化してください。
 
-For action items to get done, they must have clear owners. Because we are an Agile and DevOps shop, the cross-functional teams responsible for the affected service are also responsible for implementing improvements expected to reduce the likelihood of failure. Engineering leadership helps clarify what parts of the system each team owns and sets expectations for which teams own new development and operational improvements. Ownership designations are communicated across the organization so all teams understand who owns what and ownership gaps can be identified. **As always, document this information for future reference and new hires.** Any uncertainty about ownership of an incident's action items are discussed in the postmortem meeting with representatives for all teams that may own the action item.
+アクションアイテムが実行されるためには、明確なオーナーが必要です。私たちはアジャイルとDevOpsの組織であるため、影響を受けたサービスを担当する横断チームも、障害の可能性を減らすと見込まれる改善の実装を担当します。エンジニアリングのリーダー陣は、各チームがシステムのどの部分を所有しているかを明確にし、新規開発と運用改善を担当するチームに対する期待値を設定します。オーナーシップの指定は組織全体に伝えられ、誰が何を所有しているのかをすべてのチームが理解し、オーナーシップの認識にギャップがあれば特定できるようにします。**例によって、新たにチームに加わるメンバーのために、将来的にも参照できるようこの情報を文書化してください。**インシデントのアクションアイテムのオーナーシップに不確実なところがあれば、ポストモーテムミーティングにおいて、アクションアイテムを所有する可能性のあるすべてのチームの代表者との間で議論します。
 
-We have also seen improved accountability for completing action items by involving the leaders responsible (product managers and engineering managers) for prioritizing a team's work in the postmortem meeting. Product managers are responsible for defining a good customer experience. Incidents cause a poor customer experience. Engage product managers in postmortem discussions by explaining that it will provide a wider picture of threats to customer experience and ideas on how to improve that experience. Doing so gives engineering a chance to explain the importance of these action items so that product managers will prioritize the work accordingly. Similarly, getting engineering leadership more involved in postmortem discussions gives them a better understanding of system weaknesses to inform how and where they should invest technical resources. Sharing this context with the leaders that prioritize work allows them to support the team's effort to quickly complete high-priority action items from incident analysis.
+また、チームの作業の優先順位付けを担当するリーダー（プロダクトマネージャーとエンジニアリングマネージャー）をポストモーテムミーティングに参加させることで、アクションアイテムの完了に対する説明責任が向上します。プロダクトマネージャーには、よい顧客体験を定義する責任があります。インシデントは顧客体験を悪化させます。ポストモーテムの議論にプロダクトマネージャーに参加してもらい、顧客体験に対する脅威とその体験を改善する方法についてより広い視点を提供してもらいます。これによって、エンジニアリングはこれらのアクションアイテムの重要性を説明し、プロダクトマネージャーがそれに応じて作業の優先順位を付けることができます。同様に、より多くのエンジニアリングのリーダー陣をポストモーテムの議論に参加させることで、技術リソースをどこへどのように投資すべきかの判断につながるような、システムの弱点に関する理解を深めることができます。この文脈を作業の優先順位付けを行うリーダーと共有することで、インシデント分析から発生した高優先度のアクションアイテムを迅速に完了できるよう、チームの取り組みを支援できます。
 
-Finally, ensure postmortem action items are discoverable and regularly viewed. Document postmortem action items as you would any other task. The list of action items from an incident analysis should not only live in your postmortem document. Open tickets in your task management tool, within the project of the team that will own the action item, so it can be viewed alongside all other planned work. We label all tickets with the severity level (Sev-1, Sev-2, etc.) and a date tag (YYYYMMDD) so we can easily query tickets that came from specific incidents and build reporting for the number of open tickets from major incidents.
+最後に、ポストモーテムのアクションアイテムを見つけやすく、定期的に確認できるようにしておきます。ポストモーテムのアクションアイテムを他のタスクと同様に文書化しましょう。インシデント分析から発生したアクションアイテムのリストは、ポストモーテムの文書にのみ記載しておくだけでは十分ではありません。タスク管理ツールでチケットをオープンし、アクションアイテムを所有するチームのプロジェクト内に配置して、他にも計画されたすべての作業と一緒に表示できるようにします。すべてのチケットに重大度レベル（Sev-1、Sev-2など）と日付タグ（YYYYMMDD）を付けて、特定のインシデントからのチケットを容易に照会し、重大なインシデント起点でオープンしているチケットの数のレポートを作成できるようにします。
 
-!!! info "Key Takeaways"
-    - Set a policy for postmortem action items: e.g. 15 days for Sev-1 action items, 30 days for Sev-2 action items.
-    - Clarify ownership of postmortem action items.
-    - Engage the leaders that prioritize work.
-    - Open tickets for postmortem action items in your work management ticketing system.
+!!! info "重要なポイント"
+    - ポストモーテムのアクションアイテムのポリシーを設定すること：例えば、Sev-1アクションアイテムは15日以内、Sev-2アクションアイテムは30日以内。
+    - ポストモーテムのアクションアイテムのオーナーシップを明確にすること。
+    - 作業の優先順位付けを行うリーダーを参加させること。
+    - ポストモーテムのアクションアイテムのチケットを、タスク管理システムでオープンすること。
diff --git a/docs/culture/blameless.md b/docs/culture/blameless.md
index 907c55b..783ed08 100644
--- a/docs/culture/blameless.md
+++ b/docs/culture/blameless.md
@@ -1,56 +1,55 @@
 ---
 cover:
-description: A successful postmortem process is based on a culture of honesty, learning, and accountability. Culture change requires management buy-in, but you can lead culture change no matter your role. This guide describes common challenges faced in building a culture of continuous learning through postmortems and strategies for overcoming these challenges.
+description: 成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。文化の変革には経営陣の賛同が必要ですが、あなたの役割に関わらず文化の変革をリードすることができます。このガイドでは、ポストモーテムを通じて継続的な学習の文化を構築する際に直面する一般的な課題と、それらを克服するための戦略について説明します。
 ---
 ![Blameless](../assets/img/headers/Postmortems-Blameless.png)
 
-As IT professionals, we understand that failure is inevitable in complex systems. **How we respond to failure when it occurs matters.** In _[The Field Guide to Understanding Human Error](https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265)_, Sidney Dekker describes two views on human error: 1) the old view, which asserts that people’s mistakes cause failure, and 2) the new view, which treats human error as a symptom of a systemic problem. The old view ascribes to “the bad apple theory,” which believes that removing bad actors will prevent failure. This view attaches an individual's character to their actions, assuming negligence or bad intent leads to the error.
+情報技術のプロフェッショナルとして、私たちは複雑なシステムでは障害が避けられないことを理解しています。**重要なのは、障害が発生した時にどう対応するかです。** _[The Field Guide to Understanding Human Error](https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265)_ の中で、Sidney Dekkerはヒューマンエラーに関する2つの見方を説明しています：1）古い見方では、人々のミスが障害の原因であるとし、2）新しい見方では、ヒューマンエラーをシステム的な問題の症状として扱います。古い見方では「腐ったリンゴ理論」のように、望ましくない行いをする人を取り除けば障害を防げると信じられています。この見方は個人の性格を彼らの行動に結びつけ、過失や悪意がエラーにつながると想定しているのです。
 
-An organization that follows this old view of human error may respond to an incident by finding the careless individual who caused the incident so they can be reprimanded. **This impulse to blame and punish has the unintended effect of disincentivizing the knowledge sharing required to prevent future failure.** Engineers will hesitate to speak up when incidents occur for fear of being blamed. This silence increases overall mean time to acknowledge, mean time to resolve, and exacerbates the impact of incidents.
+ヒューマンエラーに関する古い見方に従う組織では、不注意によってインシデントを引き起こした個人が叱責されることがあります。**このように非難を行い罰することへの衝動は、将来の障害を防ぐ上で必要な知識共有を妨げるという予期せぬ影響をもたらします。** エンジニアは非難されることを恐れて、インシデントが発生した際に発言することをためらうでしょう。この沈黙はインシデントの平均確認時間（MTTA）、平均解決時間（MTTR）を増加させ、インシデントの影響を悪化させます。
 
-For the postmortem process to result in learning and system improvements, the new view of human error must be followed. In complex systems of software development, a variety of conditions interact to lead to failure. **The goal of the postmortem is to understand what systemic factors led to the incident and identify actions that can prevent this kind of failure from recurring.** A blameless postmortem stays focused on _how_ a mistake was made instead of _who_ made it. This is a crucial mindset leveraged by many leading organizations (such as Etsy, a pioneer for [blameless postmortems](https://codeascraft.com/2012/05/22/blameless-postmortems/)) for ensuring postmortems have the right tone, empowering engineers to give truly objective accounts of what happened by eliminating the fear of punishment.
+ポストモーテムプロセスを学習とシステム改善につなげるためには、ヒューマンエラーに関する新しい見方に従う必要があります。ソフトウェア開発における複雑なシステムでは、様々な条件が相互作用して障害を引き起こします。**ポストモーテムの目的は、インシデントの発生につながったシステム的要因を理解し、この種の障害が再発するのを防ぐためのアクションを特定することです。** ブレームレス（非難のない）なポストモーテムは、「誰が」ミスを犯したかではなく、「どのように」ミスが発生したかに焦点を当てます。これは、多くの先進的な組織（例えば[ブレームレスなポストモーテム](https://codeascraft.com/2012/05/22/blameless-postmortems/)のパイオニアであるEtsy）が活用している重要なマインドセットであり、罰に対する恐怖を排除することにより、実際に何が起こったかをエンジニアが真の意味で客観的な説明をできるようにし、ポストモーテムが適切なトーンで行われることを保証します。
 
+## なぜブレーム（非難）を意識することが難しいのか
+継続的改善の文化を望むことは簡単ですが、学習に求められる非難のない状態の実践は難しいです。予期せぬことが発生する障害の性質は、自ずと人間が理解する妨げとなるような反応を招きます。情報を処理する際に、人間の心は無意識のうちにショートカットを取ります。一般的な経験則を適用することで、心は正確さよりもタイムリーさに最適化されるのです。これが誤った結論を生み出す場合、それは認知バイアスと呼ばれます。
 
-## Why Being Blame Aware is Hard
-It is easy to agree that we want a culture of continuous improvement, but it is difficult to practice the blamelessness required for learning. The unexpected nature of failure naturally leads humans to react in ways that interfere with our understanding of it. When processing information, the human mind unconsciously takes shortcuts. By applying general rules-of-thumb, the mind optimizes for timeliness over accuracy. When this produces an incorrect conclusion, it is a cognitive bias.
+[J. Paul Reed](https://techbeacon.com/blameless-postmortems-dont-work-heres-what-does)は、非難する傾向が何百万年もの進化的神経生物学によって配線されているため、ブレームレスなポストモーテムは神話だと主張しています。この傾向を無視したり、完全に排除しようとしたりすることは不可能です。「ブレームアウェア（非難を意識する）」であることの方が生産的です。**私たちのバイアスを意識することで、それらが発生した時に識別し、乗り越える取り組みを行えるでしょう。** 以下ではいくつかのバイアスについて触れますが、詳細については、ポストモーテムを実施する際に意識すべき認知バイアスについての[Lindsay Holmwood](http://fractio.nl/2015/10/30/blame-language-sharing/)の記事をお読みください。
 
-[J. Paul Reed](https://techbeacon.com/blameless-postmortems-dont-work-heres-what-does) argues the blameless postmortem is a myth because the tendency to blame is hardwired through millions of years of evolutionary neurobiology. Ignoring this tendency or trying to eliminate it entirely is impossible. It is more productive to be “blame aware.” **By being aware of our biases, we will be able to identify when they occur and work to move past them.** We touch upon some of the biases below, but for more details, read [Lindsay Holmwood's](http://fractio.nl/2015/10/30/blame-language-sharing/) article on the cognitive biases we must be aware of when performing postmortems.
+**[基本的帰属エラー（fundamental attribution error）](https://en.wikipedia.org/wiki/Fundamental_attribution_error)**は、人々の行動が、彼らの状況ではなく性格を反映したものであると信じる傾向です。これはヒューマンエラーの古い見方を表し、障害を不注意で無能な悪い人物のせいにします。皮肉なことに、私たちは自分自身の行動を説明する際には、自分の性格ではなく状況によって説明する傾向があります。このように他者を非難する傾向と戦うには、個人が取った具体的な行動ではなく、状況的な原因へ意図的に分析の焦点を当てることです。
 
-**[Fundamental attribution error](https://en.wikipedia.org/wiki/Fundamental_attribution_error)** is the tendency to believe that what people do reflects their character rather than their circumstances. This describes the old view of human error, assigning responsibility for a failure to bad actors who are careless and incompetent. Ironically, we tend to explain our own actions by our context, not our personality. Combat this tendency to blame by intentionally focusing the analysis on situational causes rather than discrete actions individuals took.
+もう一つの広く見られる認知バイアスは**確証バイアス（confirmation bias）**で、これは既存の信念を強化する情報を好む傾向です。曖昧な情報に直面すると、私たちはそれを既存の仮定を支持する方法で解釈する傾向があります。ヒューマンエラーの古い見方と組み合わさると、このバイアスはポストモーテムにとって危険です。なぜなら、それは腐ったリンゴを非難しようとする流れにつながるからです。個人に責任があるという仮定でアプローチすると、反対の証拠があるにもかかわらず、その信念を支持する方法を探してしまうでしょう。
 
-Another pervasive cognitive bias is **confirmation bias**, which is the tendency to favor information that reinforces existing beliefs. When presented with ambiguous information, we tend to interpret it in a way that supports our existing assumptions. When combined with the old view of human error, this bias is dangerous for postmortems because it seeks to blame the bad apple. When approaching the analysis with the assumption that an individual is at fault, you will find a way to support that belief despite evidence to the contrary.
+確証バイアスと戦うために、調査の過程で逆の立場をとる代弁者を任命することをHolmwoodは提案しています。ただし、逆の立場をとる代弁者によって否定性や対立性がもたされることには注意してください。また、他のチームから誰かを招いて、彼らの心に浮かぶあらゆる質問をしてもらうことで、確証バイアスに対抗することもできます。これにより、チームが当然と考えるようになっていた調査の方向性が明らかになります。
 
-To combat confirmation bias, Holmwood suggests appointing someone to play devil’s advocate to take contrarian viewpoints during investigations. Be cautious of introducing negativity or combativeness with a devil’s advocate. You can also counter confirmation bias by inviting someone from another team to ask any and all questions that come to their mind. This will help surface lines of inquiry the team has learned to take for granted.
+**後知恵バイアス（hindsight bias）**は、判断を形作るために事象を思い出す際の記憶の歪みの一種です。結果を知っていると、当時はそれを予測する客観的な根拠がほとんどまたは全くなかったにもかかわらず、その事象が容易に予測可能だったと見なしてしまいがちです。私たちはしばしば、自分自身をよりよく見せるようなやりかたで出来事を思い出します。例えば、インシデントの原因を分析している人が、それが起こるとを予期していたと信じる場合が挙げられます。このバイアスを体現すると、チーム内の防御と分裂を招きかねません。Holmwoodは、後知恵バイアスを避けるために、事象を予見の観点から説明することを提案しています。すなわちタイムライン分析をインシデント発生前の時点から始め、解決から逆算するのではなく、前に進むようにするのです。
 
-**Hindsight bias** is a type of memory distortion where we recall events to form a judgment. Knowing the outcome, it is easy to see the event as being predictable despite there having been little or no objective basis for predicting it. Often, we recall events in a way to make ourselves look better. An example is when a person analyzing the causes of an incident believes they knew it would happen like that. Enacting this bias can lead to defensiveness and division within a team. Holmwood suggests avoiding the hindsight bias by explaining events in terms of foresight instead. Start your timeline analysis at a point before the incident and work your way forward instead of backward from resolution.
+注意すべきもう一つの一般的なバイアスは**[否定性バイアス（negativity bias）](https://en.wikipedia.org/wiki/Negativity_bias)**です。これは、否定的な性質のもののほうが、中立的または肯定的な性質のものよりも、人の精神状態に大きな影響を与えるという概念です。社会的判断に関する研究では、他者に対する印象において、否定的な情報がとてつもなく大きな影響を与えることが示されています。これは「腐ったリンゴ理論」、つまり組織内に障害の責任を負うべき好ましくない人物がいるという信念に関連しています。研究はまた、人々が否定的な結果を他の人の意図によるものだとする可能性が、中立的および肯定的な結果よりも高いことを示しています。これもまた、重大なインシデントを説明するために個人の性格を非難する傾向を説明しています。
 
-Another common bias to be aware of is **[negativity bias](https://en.wikipedia.org/wiki/Negativity_bias)**. This is the notion that things of a more negative nature have a greater effect on one’s mental state than those of neutral or even positive nature. Research on social judgments has shown negative information disproportionately impacts a person’s impression of others. This relates to the “bad apple theory,” the belief that there are negative actors in your organization to blame for failures. Studies have also shown people are more likely to attribute negative outcomes to the intentions of another person than neutral and positive outcomes. This also explains our tendency to blame individuals’ characters to explain a major incident.
+実際には、物事がうまくいくことの方が、うまくいかないことよりも多いのですが、私たちは否定的な出来事に焦点を当て、その重要性を強調する傾向があります。インシデントを否定的な出来事として焦点を当て、誇張し、内面化することは、士気を低下させ、燃え尽き症候群を招く可能性があります。インシデントを学習の機会として再構築し、対応でうまく対処された事柄を説明することを忘れないようにすることで、視点のバランスを取っていきましょう。
 
-In reality, things go right more often than they go wrong, but we tend to focus on and magnify the importance of negative events. Focusing on, exaggerating, and internalizing incidents as negative events can be demoralizing and lead to burnout. Reframing incidents as learning opportunities and remembering to describe what was handled well in your response can help balance perspective
+### 認知バイアス
 
-### Cognitive Biases
-
-| Bias | Definition | Countermeasure |
+| バイアス | 定義 | 対策 |
 |---|---|---|
-| Fundamental attribution error | What people do reflects their character rather than their circumstances. |   |Intentionally focus the analysis on situational causes rather than discrete actions individuals took. |
-| Confirmation bias | Favoring information that reinforces existing positions. | Appoint someone to play devil’s advocate to take contrarian viewpoints during investigations. |
-| Hindsight bias | Seeing the incident as inevitable despite there having been little or no objective basis for predicting it because we know the outcome. | Explain events in terms of foresight instead. Start your timeline analysis at a point before the incident, and work your way forward instead of backward from resolution. |
-| Negativity bias | Things of a more negative nature have a greater effect on one’s mental state than neutral or even positive things. | Reframe incidents as learning opportunities, and remember to describe what was handled well in incident response. |
+| 基本的帰属エラー | 人々の行動には彼らの状況ではなく性格が反映されているものとみなす。 |   |分析を個人が取った具体的な行動ではなく、状況的な原因に意図的に焦点を当てる。 |
+| 確証バイアス | 既存の立場を強化する情報を好む。 | 調査の過程で逆の立場の代弁者を任命する。 |
+| 後知恵バイアス | 結果を知っているため、それを予測する客観的な根拠がほとんどまたは全くなかったにもかかわらず、インシデントが避けられなかったとみなす。 | 事象を予見の観点から説明する。タイムライン分析をインシデントの前の時点から始め、解決から逆算するのではなく、前に進む。 |
+| 否定性バイアス | より否定的な性質のものが、中立的または肯定的なものよりも、人の精神状態に大きな影響を与える。 | インシデントを学習の機会として再構築し、インシデント対応でうまく処理されたことを説明することを忘れないようにする。 |
 
-We all have these cognitive biases that can lead to distorted views of events and damage team relationships if gone unchecked. It is important to be aware of these tendencies so we can acknowledge bias when it occurs. By making postmortems a collaborative process, teams can work as a group to identify blame and then constantly dig deeper in the analysis.
+私たち全員がこれらの認知バイアスを持っていて、見過ごされると事象の歪んだ見方につながったり、チームの関係を損なったりする可能性があります。これらの傾向を意識することで、バイアスが発生した時に認識することが重要です。ポストモーテムを共同プロセスにすることで、チームはグループとして非難を特定し、分析をより深く掘り下げることができます。
 
-## How to Cultivate a Blameless (or Blame-Aware) Culture
-Acknowledging blame and working past it is easier said than done. What behaviors can we adopt to move towards a blameless culture? Holmwood eloquently writes about the importance of the words we use to minimize blame and maximize learning. He urges us to ask “what” questions (e.g., “What did you think was happening?” and “What did you do next?” Asking “what” questions grounds the analysis in the big-picture contributing factors to the incident.
+## ブレームレス（または非難を意識した）文化をどのように育むか
+非難を認識し、それを乗り越えることは、言うは易く行うは難しです。ブレームレスな文化に向けてどのような行動をとればよいでしょうか？Holmwoodは、非難を最小限に抑え、学習を最大化するために使用する言葉の重要性について雄弁に書いています。彼は「何」という質問（例えば、「何が起きていると思いましたか？」「次に何をしましたか？」）をするよう促しています。「何」という質問をすることで、インシデントに寄与した大きな要因に分析の基礎を置きます。
 
-In his article “[The Infinite Hows](https://www.oreilly.com/ideas/the-infinite-hows),” John Allspaw encourages us to ask “how” questions because they get people to describe (at least some of) the conditions that allowed an event to take place. Holmwood also notes that “how” questions can help clarify technical details, distancing people from the actions they took. Avoid asking “why” questions because it forces people to justify their actions, attributing blame.
+彼の記事「[The Infinite Hows](https://www.oreilly.com/ideas/the-infinite-hows)」の中で、John Allspawは「どのように」という質問をするよう勧めています。なぜなら、それらは人々に出来事が起こることを可能にした条件（少なくともいくつか）を説明させるからです。Holmwoodもまた、「どのように」という質問が技術的な詳細を明確にし、人々を彼らが取った行動から距離を置かせるのに役立つと指摘しています。「なぜ」という質問は避けてください。なぜなら、それは人々に自分の行動を正当化させ、非難を帰することになるからです。
 
-[Crucial Accountability](https://www.vitalsmarts.com/crucial-accountability-training/) offers a helpful framework for approaching difficult conversations about unmet expectations that can be applied to postmortems when emotions run high. When analyzing failure, we may fall into victim, villain, and helpless stories that propel emotions and attempt to justify our worst behaviors. You can move beyond blame by telling the rest of the story. Consider your and others’ roles in the problem. Ask yourself why a reasonable, rational, and decent person may have taken the action that seems to have caused the incident. This thinking will help turn attention to the multiple systemic factors that led to the incident.
+[Crucial Accountability](https://www.vitalsmarts.com/crucial-accountability-training/)では、期待と現実の不一致に関する難しい会話にアプローチするのに役立つフレームワークが提供されており、感情が高まるようなポストモーテムにも適用できます。障害を分析する際、私たちは感情を駆り立て、最悪の行動を正当化しようとする被害者、悪役、無力な物語に陥る可能性があります。物語の残りの部分を語ることで、非難を乗り越えることができます。問題における、あなた自身と他者の役割を考慮してください。合理的で理性的で良識のある人が、インシデントの原因となったように見える行動を取った理由を自問してください。この思考は、インシデントにつながった複数のシステム的要因に注意を向けるのに役立ちます。
 
-Even when you have made a best effort to remain blameless, it is possible someone may still become defensive during a postmortem meeting if they feel they are being blamed. When this happens, work to restore mutual purpose and mutual respect so a productive discussion can continue. Restore mutual purpose by reiterating that the goal of the postmortem is to understand what systemic factors lead to the incident and collaboratively identify actions that can reduce failure moving forward. Often, people act out defensively when they feel their character is being attacked. Restore mutual respect by contrasting. Say what you did not intend (“I did not mean to imply you’re bad at your job.”) contrasted with what you do intend (“I meant to inquire to the situational factors that would lead any responder to take that action.”) Refocus your inquiry away from individual motivation, which implies blame. Abstracting to an inspecific responder also encourages other responders to contribute more suggestions as to what could have contributed to the system failure.
+最善の努力をしてブレームレスであろうとしても、ポストモーテムミーティング中に誰かが非難されていると感じると、人は防御的になる可能性があります。これが起こった場合、生産的な議論を続けるために互いの目的意識と尊重を回復するよう努めてください。ポストモーテムの目的はインシデントにつながったシステム的要因を理解し、将来の障害を減らすためのアクションを共同で特定することだと再確認することで、相互の目的意識を回復します。しばしば、人々は自分の性格が攻撃されていると感じると防御的に行動します。対比することで相互の尊重を回復します。あなたが意図しなかったこと（「あなたが仕事が下手だと言うつもりはありませんでした」）と、あなたが意図したこと（「任意の対応者がその行動を取るような状況的要因を尋ねるつもりでした」）を対比させてください。非難を暗示する個人の動機からは、調査の焦点を逸らしてください。特定されていない対応者に抽象化することで、システム障害に寄与した可能性のあることについて、他の対応者がより多くの提案を行いやすくなります。
 
-!!! info "Key Takeaways"
-    - Ask “what” and “how” questions rather than “who” or “why.”
-    - Consider multiple and diverse perspectives.
-    - Ask yourself why a reasonable, rational, and decent person may have taken a particular action.
-    - When inquiring about a human action, abstract to an inspecific responder. Anyone could have made the same mistake.
-    - Restore mutual purpose and mutual respect by contrasting what you did not intend with what you do intend.
+!!! info "重要なポイント"
+    - 「誰が」「なぜ」ではなく、「何を」「どのように」という質問をする。
+    - 複数の多様な視点を考慮する。
+    - 合理的で理性的で良識のある人が特定の行動を取った理由を自問する。
+    - 人間の行動について尋ねる際、特定されていない対応者に抽象化する。誰でも同じミスを犯す可能性がある。
+    - あなたが意図しなかったことと意図したことを対比させることで、相互の目的と尊重を回復する。
diff --git a/docs/culture/introduce.md b/docs/culture/introduce.md
index eccdd35..1a1d0e3 100644
--- a/docs/culture/introduce.md
+++ b/docs/culture/introduce.md
@@ -1,31 +1,31 @@
 ---
 cover:
-description: A successful postmortem process is based on a culture of honesty, learning, and accountability. Culture change requires management buy-in, but you can lead culture change no matter your role. This guide describes common challenges faced in building a culture of continuous learning through postmortems and strategies for overcoming these challenges.
+description: 成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。文化の変革には経営陣の賛同が必要ですが、あなたの役割に関わらず文化の変革をリードすることができます。このガイドでは、ポストモーテムを通じた継続的学習の文化を構築する際に直面する一般的な課題と、それらを克服するための戦略について説明します。
 ---
 ![How to Introduce](../assets/img/headers/Postmortems-Introduce.png)
 
-Whether you're introducing postmortems as an entirely new practice at your organization or working to improve an existing process, culture change is hard. No matter your role, the first step to introducing a new process is getting buy-in from leadership and individual contributors because, often, bottom-up changes are more successful than top-down mandates from management.
+ポストモーテムを組織に全く新しい実践として導入する場合でも、既存のプロセスを改善する場合でも、カルチャーの変革は難しいものです。あなたの役割に関わらず、新しいプロセスを導入する最初のステップは、リーダーシップと個々の貢献者から賛同を得ることです。なぜなら、多くの場合、ボトムアップの変化は経営陣からのトップダウンの指示よりも成功する可能性が高いからです。
 
-To practice blameless postmortems and encourage a culture of continuous improvement, you need commitment from leadership that no individuals will be reprimanded in any way after an incident.
+非難のない（ブレームレスな）ポストモーテムを実践し、継続的改善の文化を促進するためには、インシデント後に個人が何らかの形で叱責されることはないというリーダーシップからのコミットメントが必要です。
 
-To convince management to support a shift to blameless analysis, clarify how blame is harmful to the business and explain the business value of blamelessness. For instance, punishing individuals for "causing" incidents discourages people from speaking up when problems occur for fear of being blamed. This silence will increase the mean time to acknowledge incidents, mean time to resolve, and, ultimately, exacerbate the impact of incidents. Organizations can rapidly improve the resilience of their systems and increase the speed of innovation by eliminating the fear of blame and encouraging collaborative learning.
+経営陣の納得を得ながら非難のない分析への転換を進めるためには、非難がビジネスにどのように有害であるかを明確にし、非難がない状態のビジネス価値を説明しましょう。例えば、インシデントを「引き起こした」個人を罰すると、人は非難されることを恐れて問題が発生したときに発言を躊躇します。この沈黙はインシデントの平均確認時間（MTTA）、平均解決時間（MTTR）を増加させ、最終的にはインシデントの影響を悪化させます。組織は、非難に対する恐怖を排除し、協力的な学習を奨励することで、システムの回復力を迅速に向上させ、イノベーションのスピードを上げることができます。
 
-It may sound silly, but when selling a new blameless postmortem process to management, avoid blaming them for blaming others. Acknowledge that practicing blamelessness is difficult for everyone. Teams can help hold each other accountable by calling each other out when blame is observed in response to failure. Ask leadership if they will be receptive to receiving that feedback if and when they accidentally suggest blame after an incident.
+奇妙に聞こえるかもしれませんが、経営陣に非難のないポストモーテムプロセスを売り込む際には、過去に他者を非難したことで経営陣を非難することは避けてください。ブレームレスを実践することは誰にとっても難しいことを認識しましょう。チームは、インシデント後に非難が見られた場合、お互いに責任を持ち、指摘することができます。リーダー陣がインシデント後に誤って非難めいた発言をした場合、そのフィードバックを受け入れる意思があるかどうかを尋ねてください。
 
-A verbal commitment from management to refrain from punishing people for causing incidents is an important start to introducing blameless postmortems, but that alone will not eliminate the fear of blame. Once you have leadership support, you will also need buy-in from the individual contributors who will be performing postmortem analysis. Share that you have commitment from management that no one will be punished after an incident. Because the tendency to blame is not unique to managers, explain to the team why blame is harmful to trust and collaboration. Agree to work together to become more blame-aware and kindly call each other out when blame is observed.
+インシデントを引き起こしたことで人々を罰しないという経営陣からの口頭でのコミットメントは、非難のないポストモーテムを導入する重要な第一歩ですが、それだけでは非難への恐怖を排除するには不十分です。リーダーシップの支持を得たら、ポストモーテム分析を実行する個々の貢献者からも賛同を得る必要があります。インシデント後に誰も罰せられないという経営陣からのコミットメントを共有してください。そして、非難が信頼と協力に有害である理由をチームに説明しましょう。非難をより意識し、非難が観察されたときにお互いに優しく指摘することに協力することに同意してください。
 
-When Google studied their teams to learn what behaviors made groups successful, they found that psychological safety was the most critical factor for a team work well together. Harvard Business School professor Amy Edmondson defines psychological safety as "a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up." A sense of safety makes people feel comfortable enough to share information about incidents, which allows for deeper analysis and results in learnings that improve the resilience of your systems.
+Googleが、チームに対する研究を行いグループを成功させる行動を学んだとき、チームがうまく協力するための最も重要な要素は心理的安全性であることがわかりました。ハーバード・ビジネス・スクールの教授Amy Edmondsonは、心理的安全性を「誰かが発言したときにチームが恥入らせたり、拒絶したり、罰したりしないという自信」と定義しています。安全の感覚は、インシデントに関する情報を共有するのに十分な心の余裕を人々に与え、それによってより深い分析が可能になり、システムの回復力を向上させる学びにつながります。
 
-Google found that high-performing teams with strong psychological safety share two key behaviors. First, these teams demonstrate conversational turn-taking. Team members speak in roughly the same proportion. When everyone is able to share their perspective, the collective intelligence of the group increases. Second, good teams have high social sensitivity or empathy. Successful teams are able to sense when someone is feeling upset or left out based on nonverbal cues.
+Googleは、心理的安全性の高いハイパフォーマンスチームに共通する2つの重要な行動があることを発見しました。まず、これらのチームでは参加者みんなに会話の順序が回ってきます。チームメンバーはほぼ同じ割合で話します。全員が自分の視点を共有できるとき、グループの集合知が増加します。第二に、よいチームは高い社会的感受性または共感を持っています。成功したチームは、非言語的な手がかりに基づいて誰かが動揺したり取り残されたりしていることを感じとることができます。
 
-These behaviors and the resulting sense of psychological safety can be encouraged by modeling vulnerability. A manager at Google found his team was able to find ways to work better together after doing an ice-breaker activity in which everyone shared something personal about themselves. The manager started by telling the team about his struggle with cancer, which helped everyone else feel more comfortable sharing something. Creating emotional bonds within a team leads to greater psychological safety and higher performance.
+これらの行動と結果としての心理的安全性の感覚は、弱みをモデル化することで奨励することができます。Googleのマネージャーは、全員が自分自身について何か個人的なことを共有するアイスブレーカー活動をした後、チームがより良く協力する方法を見つけることができたことに気づきました。マネージャーはがんとの闘いについてチームに話すことから始め、それが他の全員がより快適に共有することを助けました。チーム内で感情的な絆を作ることは、より大きな心理的安全性と高いパフォーマンスにつながります。
 
-Culture change does not happen overnight. Iteratively introduce new practices to the organization by starting small, sharing successful results of experimenting with new practices, and slowly expanding those practices across teams. You can start experimenting with blameless postmortems within a single team. To get started, use our ["How to Write a Postmortem"](../how_to_write/writing.md) guide to share tips.
+カルチャーの変化は一夜にして起こるものではありません。新しい実践を組織に反復的に導入するには、小さく始め、新しい実践を実験した成功結果を共有し、それらの実践をチーム間で徐々に拡大していきます。まずは、単一のチーム内で非難のないポストモーテムの実験を始めるとよいでしょう。始めるには、私たちの[「ポストモーテムの書き方」](../how_to_write/writing.md)ガイドを使用してヒントを共有してください。
 
-It is also easy to start practicing blameless postmortems by analyzing smaller incidents before tackling major ones. Doing postmortems for smaller incidents allows the team to develop the skill of deeper system analysis that goes beyond how people contributed to an incident. This also helps protect individuals while everyone is practicing blameless culture as people may revert to blame, but the impact on the individual will be less than if that same mistake happens with a more critical incident.
+また、より小さなインシデントのポストモーテムを実践することから始めるのもよいでしょう。小さなインシデントのポストモーテムを行うことで、チームはインシデントへの個々人の貢献に留まらず、より深いシステム分析のスキルを高めることができます。これはまた、全員が非難のない文化を実践している間、個々人を保護するのにも役立ちます。人々は非難に戻ってしまうこともあるかもしれませんが、同じ失敗がより重大なインシデントで起こった場合よりも、個人への影響は少なくなります。
 
-!!! info "Key Takeaways"
-    - Sell the business value of blamelessness: faster incident resolution, more resilient systems, more time for innovation
-    - Commit to kindly calling each other out when blame is observed
-    - Start with a single team
-    - Start with smaller incidents
+!!! info "重要なポイント"
+    - 非難のない状態（ブレームレス）のビジネス価値を売り込むこと：より迅速なインシデント解決、より回復力のあるシステム、イノベーションのための時間の増加
+    - 非難が観察されたときにお互いに優しく指摘することを約束すること
+    - 単一のチームから始めること
+    - より小さなインシデントから始めること
diff --git a/docs/culture/sharing.md b/docs/culture/sharing.md
index 1935859..f733f82 100644
--- a/docs/culture/sharing.md
+++ b/docs/culture/sharing.md
@@ -1,27 +1,27 @@
 ---
 cover:
-description: A successful postmortem process is based on a culture of honesty, learning, and accountability. Culture change requires management buy-in, but you can lead culture change no matter your role. This guide describes common challenges faced in building a culture of continuous learning through postmortems and strategies for overcoming these challenges.
+description: 成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。文化の変革には経営陣の賛同が必要ですが、あなたの役割に関わらず文化の変革をリードすることができます。このガイドでは、ポストモーテムを通じた継続的学習の文化を構築する際に直面する一般的な課題と、それらを克服するための戦略について説明します。
 ---
 ![Information Sharing](../assets/img/headers/Postmortems-InfoSharing.png)
 
-You can scale culture through sharing.<sup>1</sup> People want to share their successes, and when people see something that’s going well, they want to replicate that success. It may seem counterintuitive to share incident reports because it seems like you’re sharing a story of failure rather than success. The truth is, practicing blameless postmortems leads to success because it enables teams to learn from failure and improve systems to reduce the prevalence of failure. Framing incidents as learning opportunities with concrete resulting improvements rather than a personal failure also increases morale, which increases employee retention and productivity.
+私たちは、共有を通じて文化を広げることができます。<sup>1</sup>人々は自分の成功を共有したいと思い、何かがうまくいっているのを見ると、その成功を再現したいと思います。インシデントレポートを共有することは、失敗の話を共有しているように見えるため、直感に反するかもしれません。けれども実際は、非難のない（ブレームレスな）ポストモーテムの実践こそが成功につながります。なぜなら、チームは失敗から学び、失敗の発生を減らすためにシステムを改善することができるからです。インシデントを個人的な失敗ではなく、具体的な改善をもたらす学習の機会として位置づけることで、モラルも向上し、従業員の定着率と生産性が高まります。
 
-**Sharing the results of postmortems has two main benefits:**
-1. It increases system knowledge across the organization.
-1. It reinforces a blameless culture.
+**ポストモーテムの結果を共有することには2つの主な利点があります：**
+1. 組織全体のシステム知識を増やします。
+1. 非難のない（ブレームレスな）文化を強化します。
 
-By sharing learnings from incident analysis, you help the entire organization learn, not just the affected teams responsible for remediation. PagerDuty sends completed postmortems via email to an “Incident Reports” distribution list that includes all of engineering, product, and support, as well as all Incident Commanders (who may not be in any of those departments.) This widens system knowledge for everyone involved in incident response.
+インシデント分析からの学びを共有することで、影響を受けた修復を担当するチームだけでなく、組織全体が学べるようにします。PagerDutyは完了したポストモーテムを「インシデントレポート」配布リストを通じてエンジニアリング、プロダクト、サポートのすべて、およびすべてのインシデントコマンダー（前述の部門のいずれにも属していない可能性があります）にメールで送信します。これにより、インシデント対応に関わるすべての人のシステム知識が広がります。
 
-We encourage teams to learn postmortem best practices from each other by hosting a community of experienced postmortem writers available to review postmortems before they are shared more widely. This ensures blameless analysis through feedback and coaching while postmortems are being written.
+私たちは、ポストモーテムが広く共有される前にレビューが行われるよう、経験豊富なポストモーテム作成者のコミュニティを主催することで、ポストモーテムのベストプラクティスをチームが互いに学べるようにすることを奨励しています。これにより、ポストモーテムが書かれている間にフィードバックとコーチングを通じて非難のない分析ができるようになります。
 
-We also schedule all postmortem meetings on a shared calendar. This calendar is visible to the entire company, and anyone is welcome to join. This gives engineering teams the opportunity to learn from each other on how to practice blamelessness and deeply analyze incident causes. It also makes clear that incidents are not shameful failures that should be kept quiet.
+また、すべてのポストモーテムミーティングを共有カレンダーにスケジュールしています。このカレンダーは会社全体に公開されており、誰でも参加することができます。これにより、エンジニアリングチームはブレームレスを実践し、インシデントの原因を深く分析する方法について互いに学ぶ機会が得られます。また、インシデントは隠しておくべき恥ずかしい失敗ではないことを明らかにします。
 
-Being transparent about system failure reinforces a culture of blamelessness. When postmortems are shared, teams will see that individuals are not blamed or punished for incidents. This will reduce the fear of speaking up when issues inevitably occur. Creating a culture where information can be confidently shared leads to a culture of continuous learning in which teams can work together to design improvements.
+システムの障害について透明性を持つことは、非難のない文化を強化します。ポストモーテムが共有されると、チームはインシデントに対して個人が非難されたり罰せられたりしないことを知ります。これにより、問題が発生したときに発言することへの恐怖が軽減されます。自信を持って情報を共有できる文化を作ることは、チームが協力して改善を設計できる継続的学習の文化につながります。
 
-!!! info "Key Takeaways"
-    * Create a community of experienced postmortem writers to review postmortem drafts and spread best practices.
-    * Schedule postmortem meetings on a shared calendar, open for any interested parties to listen and learn.
-    * Email completed postmortems to all teams involved in incident response to share learning and reinforce blamelessness.
+!!! info "重要なポイント"
+    * 経験豊富なポストモーテム作成者のコミュニティを作り、ポストモーテムのドラフトをレビューし、ベストプラクティスを広めます。
+    * ポストモーテムミーティングを共有カレンダーにスケジュールし、関心のある人なら誰でも聞いて学ぶことができるようにします。
+    * 完了したポストモーテムをインシデント対応に関わるすべてのチームにメールで送り、学びを共有し非難のない状態を強化します。
 
 ---
-1. Puppet’s [2018 State of DevOps Report](https://puppet.com/resources/whitepaper/state-of-devops-report) tells us operationally mature organizations adopt practices that promote sharing.
+1. Puppetの[2018年DevOpsレポート](https://puppet.com/resources/whitepaper/state-of-devops-report)によると、運用的に成熟した組織は共有を促進する実践を採用しています。
diff --git a/docs/how_to_write/effective_postmortems.md b/docs/how_to_write/effective_postmortems.md
index 948c98a..d9cd1a5 100644
--- a/docs/how_to_write/effective_postmortems.md
+++ b/docs/how_to_write/effective_postmortems.md
@@ -1,21 +1,21 @@
 ---
 cover:
-description: Here are concrete steps for producing a postmortem document. You will learn the most important information to include in the postmortem, how to collect and present that information, and how to conduct an effective analysis that results in system improvements.
+description: 効果的なポストモーテム文書を作成するための具体的なステップを紹介します。ポストモーテムに含めるべき最も重要な情報、その情報の収集と提示方法、そしてシステム改善につながる効果的な分析の実施方法を学びます。
 ---
 ![Effective Postmortems](../assets/img/headers/Postmortems-Tips.png)
 
-Writing detailed and accurate postmortems allows you to learn quickly from mistakes and improve systems and processes for everyone. This guide lists some of the things we do to make sure our postmortems are effective.
+詳細で正確なポストモーテムを作成することで、ミスから迅速に学び、全員のためにシステムとプロセスを改善することができます。このガイドでは、効果的なポストモーテムを作成するために私たちが行っていることをいくつか紹介します。
 
-## Do
-- Make sure the timeline is an accurate representation of events.
-- Define any technical lingo/acronyms you use that newcomers may not understand.
-- [Separate what happened from how to fix it](https://www.youtube.com/watch?v=TqaFT-0cY7U).
-- Write follow-up tasks that are actionable, specific, and bounded in scope.
-- [Discuss how the incident fits into our understanding of the health and resiliency of the services affected](https://www.pagerduty.com/blog/postmortem-understand-service-reliability/).
+## すべきこと
+- タイムラインに出来事が正確に表現されていることを確認すること。
+- 新しく参加した人が理解できない可能性のある専門用語や略語を定義すること。
+- [何が起きたかと、それをどう修正するかを分けて考えること](https://www.youtube.com/watch?v=TqaFT-0cY7U)。
+- フォローアップタスクは、実行可能で具体的かつ範囲が限定されたものにすること。
+- [インシデントと、影響を受けたサービスの健全性と回復力に関する自分たちの理解を照らし合わせ、どのように合致するかを議論すること](https://www.pagerduty.com/blog/postmortem-understand-service-reliability/)。
 
-## Do Not
-- Use the word "outage" unless it really was an outage. Accurately reflect the impact of an incident. Outage is usually too broad a term to use. It can lead customers to think the product was fully unavailable when that likely was nowhere near the case.
-- Change details or events to make things "look better." Be honest in postmortems, otherwise they lose their effectiveness.
-- Name and shame someone. Keep postmortems blameless. If someone deployed a change that broke things, it's not their fault. Everyone is collectively responsible for building a system that allowed them to deploy a breaking change.
-- Blame "human error." Very rarely is the mistake "rooted" in a human performing an action. There are often several contributing factors (the script the human ran didn't have rate limiting, the documentation was out of date, etc.) that can and should be addressed.
-- Only point out what went wrong. Drill down to the underlying causes of the issue.
\ No newline at end of file
+## すべきでないこと
+- 本当に停止していない限り、「停止（outage）」という言葉を使わないようにし、インシデントの影響を正確に反映させること。「停止」は通常、使用するには広すぎる用語です。顧客に製品が完全に利用できなくなったと思わせる可能性がありますが、実際にはそうではないことがほとんどです。
+- 「より良く見せる」ために詳細や出来事を変更しないこと。ポストモーテムでは正直であることが重要で、さもないとその効果が失われます。
+- 特定の人を名指しで非難しないこと。ポストモーテムは非難のないものにしましょう。誰かが問題を引き起こす変更をデプロイした場合、それはその人の責任ではありません。破壊的な変更をデプロイできるシステムを構築したことに対して、全員が共同で責任を負っています。
+- 「ヒューマンエラー」を非難しないこと。ミスが人間の行動に「根ざしている」ことはほとんどありません。多くの場合、いくつかの要因（人間が実行したスクリプトにレートリミットの対応がなかった、ドキュメントが古かった、など）が関係しています。このような事柄には対処することができ、また対処すべきです。
+- 何が間違っていたかだけを指摘しないこと。問題の根本的な原因を掘り下げましょう。
diff --git a/docs/how_to_write/writing.md b/docs/how_to_write/writing.md
index 60a380c..9c1d4e2 100644
--- a/docs/how_to_write/writing.md
+++ b/docs/how_to_write/writing.md
@@ -1,274 +1,274 @@
 ---
 cover:
-description: Here are concrete steps for producing a postmortem document. You will learn the most important information to include in the postmortem, how to collect and present that information, and how to conduct an effective analysis that results in system improvements.
+description: ポストモーテム文書を作成するための具体的なステップを紹介します。ポストモーテムに含めるべき最も重要な情報、その情報の収集と提示方法、そしてシステム改善につながる効果的な分析の実施方法を学びます。
 ---
 ![Step by Step](../assets/img/headers/Postmortems-StepByStep.png)
 
-Below are the steps involved in performing a postmortem at a high level. Below are the details of how to perform each step.
+以下は、概要レベルでのポストモーテム実施のステップです。各ステップの実施方法の詳細を以下に示します。
 
-1. Create a new postmortem for the incident.
-1. Schedule a postmortem meeting within the required timeframe for all required and optional attendees on the "Incident Postmortem Meetings" shared calendar.
-1. Populate the incident timeline with important changes in status/impact and key actions taken by responders.
-    - For each item in the timeline, include a metric or some third-party page where the data came from.
-1. Analyze the incident.
-    - Identify superficial and root causes.
-    - Consider technology and process.
-1. Open any follow-up action tickets.
-1. Write the external messaging.
-1. Ask for review.
-1. Attend the postmortem meeting.
-1. Share the postmortem.
+1. インシデントの新しいポストモーテムを作成する。
+1. 「インシデントポストモーテムミーティング」共有カレンダーに、必須および任意の参加者のために、必要な時間枠内でポストモーテムミーティングをスケジュールする。
+1. ステータス/影響の重要な変化と、対応者が取った主要なアクションをインシデントタイムラインに記入する。
+    - タイムラインの各項目について、データの出所となるメトリクスまたはサードパーティのページを含める。
+1. インシデントを分析する。
+    - 表面的な原因と根本的な原因を特定する。
+    - 技術とプロセスの両方を考慮する。
+1. フォローアップアクションのチケットを作成する。
+1. 外部向けメッセージを作成する。
+1. レビューを依頼する。
+1. ポストモーテムミーティングに参加する。
+1. ポストモーテムを共有する。
 
-## Owner Responsibilities
-At the end of a major incident call, or very shortly after, the [Incident Commander](https://response.pagerduty.com/training/incident_commander/) selects one responder to own the postmortem. The selected owner will be notified directly by the Incident Commander. Writing the postmortem will ultimately be a collaborative effort, but selecting a single owner will help ensure it gets done.
+## オーナーの責任
+重大なインシデント対応の終了時、またはその直後に、[インシデントコマンダー](https://response.pagerduty.co.jp/training/incident_commander/)は対応者の一人をポストモーテムのオーナーとして選出します。選出されたオーナーはインシデントコマンダーから直接通知を受けます。ポストモーテムの作成は最終的には共同作業となりますが、単一のオーナーを選出することで確実に完了させることができます。
 
-The owner of a postmortem is responsible for the following:
+ポストモーテムのオーナーは以下の責任を負います：
 
-- Scheduling the postmortem meeting on the shared calendar and inviting the relevant people (this should be scheduled within 3 calendar days for a Sev-1 and 5 business days for a Sev-2).
-- Investigating the incident, pulling in whoever is needed from other teams to assist in the investigation.
-- Ensuring the page is updated with all of the necessary content. See our [Template](../resources/post_mortem_template.md) for what should be included.
-- Creating follow-up tickets. (The owner is only responsible for creating the tickets, not following them up to resolution).
-- Reviewing the postmortem content with appropriate parties before the meeting, and running through the topics at the postmortem meeting (the Incident Commander will "run" the meeting and keep the discussion on track, but you will likely be doing most of the talking).
-- Communicating the results of the postmortem internally.
+- 共有カレンダーにポストモーテムミーティングをスケジュールし、関連する人々を招待する（Sev-1の場合は3日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります）。
+- インシデントを調査し、調査に必要な他のチームのメンバーを招集する。
+- ページに必要なすべてのコンテンツが更新されていることを確認する。含めるべき内容については[テンプレート](../resources/post_mortem_template.md)を参照してください。
+- フォローアップチケットを作成する（オーナーはチケットの作成のみ責任を負い、解決までのフォローアップは責任外です）。
+- 会議前に適切な関係者とポストモーテムの内容をレビューし、ポストモーテムミーティングでトピックを進行する（インシデントコマンダーが会議を「運営」し、議論を軌道に乗せますが、あなたが最も多く話すことになるでしょう）。
+- ポストモーテムの結果を社内に伝える。
 
-The owner of a postmortem creates the postmortem document and updates it with all relevant information.
+ポストモーテムのオーナーはポストモーテム文書を作成し、関連するすべての情報を更新します。
 
 
-## Administration
+## 管理
 ![Administration](../assets/img/thumbnails/1Administration.png)
 
-1. Create the document.
-2. Add all responders to it.
-3. Schedule the meeting.
+1. 文書を作成する。
+2. すべての対応者を追加する。
+3. 会議をスケジュールする。
 
-If not already done by the Incident Commander, the postmortem owner's first step is to create a new, empty postmortem for the Incident. Go through the history in Slack to identify the responders and add them to the page so they can help populate the postmortem. Include the Incident Commander and Scribe as well. Add a link to the incident call recording.
+まだインシデントコマンダーが実施していない場合、ポストモーテムオーナーの最初のステップは、インシデントのための新しい空のポストモーテムを作成することです。Slackの履歴を確認して対応者を特定し、彼らにポストモーテムの作成を手伝ってもらえるようにページに追加します。インシデントコマンダーと書記官も足しましょう。インシデント対応のレコーディングへのリンクを追加します。
 
-Next, schedule the postmortem meeting for 30 minutes to an hour, depending on complexity of the incident. Scheduling the meeting at the beginning of the process helps ensure the postmortem is completed within the SLA. **The meeting should be scheduled within 3 calendar days for a Sev-1 and 5 business days for a Sev-2.** Don't worry about finding the best time for all attendees. The priority is to schedule within this timeframe and attendees should adjust their schedules accordingly. At PagerDuty, we schedule all postmortem meetings on a shared "Incident Postmortem Meetings" calendar so they are easily discoverable for any interested parties across the organization.
+次に、インシデントの複雑さに応じて30分から1時間のポストモーテムミーティングをスケジュールします。プロセスの最初に会議をスケジュールすることで、SLA内にポストモーテムが完了することを確保します。**会議はSev-1の場合は3暦日以内、Sev-2の場合は5営業日以内にスケジュールする必要があります。**すべての参加者にとって最適な時間を見つけることを心配する必要はありません。優先事項はこの時間枠内にスケジュールすることであり、参加者はそれに応じてスケジュールを調整する必要があります。PagerDutyでは、すべてのポストモーテムミーティングを「インシデントポストモーテムミーティング」共有カレンダーにスケジュールし、組織全体で関心のある人々が簡単に見つけられるようにしています。
 
-Invite the following people to the postmortem meeting:
+ポストモーテムミーティングには以下の人々を招待します：
 
-- Always
-    - The [incident commander](https://response.pagerduty.com/training/incident_commander/).
-    - The incident commander shadowee (if there was one).
-    - [Service owners](https://response.pagerduty.com/training/subject_matter_expert/) involved in the incident.
-    - Key engineer(s)/responders involved in the incident.
-    - Engineering manager for impacted systems.
-    - Product manager for impacted systems.
-- Optional
-    - [Customer liaison](https://response.pagerduty.com/training/customer_liaison/) (only for Sev-1 incidents).
+- 必須
+    - [インシデントコマンダー](https://response.pagerduty.co.jp/training/incident_commander/)。
+    - インシデントコマンダーをシャドーイングしていた担当者（いた場合）。
+    - インシデントに関与した[サービスオーナー](https://response.pagerduty.co.jp/training/subject_matter_expert/)。
+    - インシデントに関与した主要なエンジニア/対応者。
+    - 影響を受けたシステムのエンジニアリングマネージャー。
+    - 影響を受けたシステムのプロダクトマネージャー。
+- 任意
+    - [カスタマーリエゾン](https://response.pagerduty.co.jp/training/customer_liaison/)（Sev-1インシデントの場合のみ）。
 
-PagerDuty postmortems have a "Status" field that indicates where in our process the postmortem currently is. Here's a description of the values and how we use them.
+PagerDutyのポストモーテムには、ポストモーテムが現在プロセスのどの段階にあるかを示す「ステータス」フィールドがあります。以下は、値の説明と使用方法です。
 
-| Status | Description |
+| ステータス | 説明 |
 |-|-|
-| **Draft** | Indicates that the content of the postmortem is still being worked on. |
-| **In Review** | The content of the postmortem has been completed, and is ready to be reviewed during the postmortem meeting. |
-| **Reviewed** | The meeting is over and the content has been reviewed and agreed upon.<br/>If there is an "External Message", the Customer Support team will take the message and update our status page as appropriate. |
-| **Closed** | No further actions are needed on the postmortem (outstanding issues are tracked in JIRA).<br/>If no "External Message", you can skip straight to this once the meeting is over.<br/>If there's an "External Message", then the Support team will update it to this status once the message is posted. |
+| **ドラフト** | ポストモーテムの内容がまだ作業中であることを示します。 |
+| **レビュー中** | ポストモーテムの内容が完成し、ポストモーテムミーティングでのレビューの準備ができていることを示します。 |
+| **レビュー済み** | 会議が終了し、内容がレビューされ合意されたことを示します。<br/>「対外メッセージ」がある場合、カスタマーサポートチームがメッセージを取り、適切にステータスページを更新します。 |
+| **クローズ** | ポストモーテムに関するさらなるアクションは必要ない状態です（未解決の問題はJIRAで追跡されます）。<br/>「対外メッセージ」がない場合、会議終了後にこのステータスに直接移行できます。<br/>「対外メッセージ」がある場合、サポートチームがメッセージを投稿した後にこのステータスに更新します。 |
 
-## Create a Timeline
+## タイムラインの作成
 ![Timeline](../assets/img/thumbnails/2CreateATimeline.png)
-Begin by focusing on the timeline. Document the facts of what happened during the incident. Avoid evaluating what should or should not have been done and coming to conclusions about what caused the incident. Presenting only the facts here will help avoid blame and supports a deeper analysis. Note the incident may have started before responders became aware of it and began the response effort. The timeline includes important changes in status/impact and key actions taken by responders. To avoid hindsight bias, start your timeline at a point before the incident and work your way forward instead of backwards from resolution.
+まずタイムラインに焦点を当てます。インシデント中に起きた事実を文書化します。何をすべきだったか、何をすべきでなかったか、インシデントの原因は何かといった評価は避けてください。ここで事実のみを提示することで、非難を避け、より深い分析をしやすくします。またインシデントは、対応者が気づいて対応を開始する前に始まっていた可能性があることに注意してください。タイムラインにはステータス/影響の重要な変化と対応者が取った主要なアクションを含めます。後知恵バイアスを避けるため、タイムラインはインシデント発生前の時点から始め、解決から逆算するのではなく、時系列に沿って進めてください。
 
-Review the incident log in Slack to find key decisions made and actions taken during the response effort. Also include information the team didn't know during the incident that, in hindsight, you wish you would have. Find this additional information by looking at monitoring, logs, and deployments related to the affected services. You'll take a deeper look at monitoring during the analysis step, but start here by adding key events related to the incident, and include changes to incident status and the impact to the timeline.
+Slackのインシデントログを確認して、対応中に行われた重要な決定やアクションを見つけます。後から考えると知っておきたかったけれども、インシデント中には知らなかった情報も含めましょう。このような追加情報は、影響を受けたサービスに関連するモニタリング、ログ、デプロイを確認すると見つけることができます。モニタリングについては分析の段階で精査しますが、まずはインシデントに関連する重要なイベントをタイムラインに追加し、インシデントのステータスと影響の変化も含めてください。
 
-For each item in the timeline, identify a metric or some third-party page where the data came from. This helps illustrate each point clearly and ensures you remain rooted in fact rather than opinions. This could be a link to a monitoring graph, a log search, a tweet, etc.—anything that shows the data point you're trying to illustrate in the timeline.
+タイムラインの各項目について、データの出所となるメトリクスまたはサードパーティのページを特定します。これにより各ポイントが明確に説明され、意見ではなく事実に基づいていることが保証されます。これはモニタリンググラフへのリンク、ログ検索、Xのポスト、その他タイムラインで説明しようとしているデータポイントを示すものであれば何でも構いません。
 
-!!! info "Key Takeaways"
-    * Stick to the facts.
-    * Include changes to incident status and impact.
-    * Include key decisions and actions taken by responders.
-    * Illustrate each point with a metric.
+!!! info "重要なポイント"
+    * 事実に忠実であること。
+    * インシデントのステータスと影響の変化を含めること。
+    * 対応者が行った重要な決定とアクションを含めること。
+    * 各ポイントをメトリクスで説明すること。
 
-## Document Impact
+## 影響の文書化
 ![Impact](../assets/img/thumbnails/3DocumentImpact.png)
-Impact should be described from a few perspectives:
+影響はいくつかの観点から説明する必要があります：
 
-- How long was the impact visible? In other words, what was the length of time users/customers were affected?
-    - Note the length of impact may differ from the length of the response effort. Impact may have started some time before it was detected and incident response began.
-- How many customers were affected?
-    - Support may need a list of all affected customers so they can reach out individually.
-- How many customers wrote or called support about the incident?
-- What functionality was affected and how severely?
-    - Quantify impact with a business metric specific to your product. For PagerDuty this includes event submission, delayed processing, slow notification delivery, etc.
+- 影響が発生していた期間はどれくらいですか？言い換えれば、ユーザー/顧客が影響を受けた時間の長さはどれくらいですか？
+    - 影響の長さは対応作業の長さとは異なる場合があることに注意してください。影響は、問題が検出されてインシデント対応が開始される前にすでに始まっていた可能性があります。
+- 何人の顧客が影響を受けましたか？
+    - サポートは、影響を受けたすべての顧客のリストを必要とする場合があり、個別に連絡を取ることがあります。
+- 何人の顧客がインシデントについてサポートに連絡しましたか？
+- どの機能がどの程度影響を受けましたか？
+    - 製品に特化したビジネスメトリクスで影響を定量化します。PagerDutyの場合、これにはイベント送信、処理の遅延、通知配信の遅延などが含まれます。
 
-## Analyze the Incident
+## インシデントの分析
 ![Analyze](../assets/img/thumbnails/4AnalyzeTheIncident.png)
-Now that you have an understanding of what happened during the incident, look further back in time to find the contributing factors that led to the incident. Technology is a complex system with a network of relationships (organizational, human, technical) that is continuously changing.
+インシデント中に何が起きたかを理解したら、さらに時間をさかのぼってインシデントにつながった要因を探します。テクノロジーは、継続的に変化する関係のネットワーク（組織的、人的、技術的）を伴う複雑なシステムです。
 
-In his paper, "[How Complex Systems Fail](http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf)," Dr. Richard Cook says that because complex systems are heavily defended against failure, it is a unique combination of apparently innocuous failures that join to create catastrophic failure. Furthermore, because overt failure requires multiple faults, attributing a "root cause" is fundamentally wrong. **There is no single root cause of major failure in complex systems, but a combination of contributing factors that together lead to failure.** The postmortem owner's goal in analyzing the incident is not to identify the root cause, but to understand the multiple factors that created an environment where this failure became possible.
+リチャード・クック博士の論文「[How Complex Systems Fail](http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf)」によれば、複雑なシステムは障害から強く防御されている一方、一見無害な問題が独自に組み合わさった結果、壊滅的な障害を引き起こします。さらに、明白な障害には複数の欠陥が必要なため、「根本原因」を特定することは根本的に間違っています。**複雑なシステムの大きな障害には単一の根本原因はなく、障害が可能になる環境を作り出す複数の要因の組み合わせがあります。**ポストモーテムオーナーのインシデント分析の目標は根本原因を特定することではなく、この障害を引き起こした可能性のある複数の要因を理解することです。
 
-Cook also says the effort to find the "root cause" does not reflect an understanding of the system, but rather the cultural need to blame specific, localized forces for events. Blamelessness is essential for an effective postmortem. **An individual's action should never be considered a root cause.** Effective analysis goes deeper than human action. In the cases where someone's mistake did contribute to a failure, it is worth anonymizing this in your analysis to avoid attaching blame to any individual. Assume any team member could have made the same mistake. According to Cook, "all practitioner actions are actually gambles, that is, acts that take place in the face of uncertain outcomes."
+クックはまた、「根本原因」を見つける努力はシステムの理解を反映するものではなく、むしろ発生した出来事に対して特定の局所的な力を非難する文化的な必要性を反映していると述べています。非難がないことは効果的なポストモーテムにとって不可欠です。**個人の行動が根本原因と見なされるべきでは決してありません。**効果的な分析では、人間の行動よりも深いところまで掘り下げを行います。誰かのミスが障害に寄与した場合、分析においては個人への非難を避けるためにこれを匿名化する意味があります。どのチームメンバーも同じミスを犯す可能性があると仮定しましょう。クックによれば、「あらゆる実務担当者の行動は実のところギャンブルであり、不確実な結果に直面しながら行われる行為です。」
 
-The postmortem owner should start their analysis by looking at the monitoring for the affected services. Search for irregularities like sudden spikes or flatlining when the incident began and leading up to the incident. Include any commands or queries used to look up data, graph images, or links from monitoring tooling alongside this analysis so others can see how the data was gathered. If there is not monitoring for this service or behavior, make building monitoring an action item for this postmortem. More on [writing action items](#followup) below.
+ポストモーテムオーナーは、影響を受けたサービスのモニタリングを調査することから分析を始めるべきです。インシデントが始まった時点とその前に、突然のスパイクやフラットラインがなかったか異常を探します。データがどのように収集されたかを他の人が確認できるように、データを検索するために使用したコマンドやクエリ、グラフ画像、モニタリングツールからのリンクをこの分析と一緒にまとめてください。このサービスや動作に対するモニタリングがない場合は、モニタリングの構築をこのポストモーテムのアクションアイテムとしてしましょう。以下の[アクションアイテムの作成](#followup)で詳しく説明します。
 
-!!! warning "Importance of Monitoring"
-    Puppet's 2018 State of DevOps Report highlights making monitoring configurable by the team operating the service as a foundational practice for successful DevOps. Empowering teams to define, manage, and share their own measurement of performance contributes to a culture of continuous improvement.
+!!! warning "モニタリングの重要性"
+    Puppetの2018年DevOpsレポートは、サービスを運用するチームがモニタリングを設定できるようにすることが、成功するDevOpsの基本的な実践であることを強調しています。チームが自分たちのパフォーマンス測定を定義、管理、共有できるようにすることは、継続的改善の文化に貢献します。
 
-Another helpful strategy for targeting what caused an incident is reproducing it in a non-production environment. Experiment by modifying variables to isolate the phenomenon. If you modify or remove some input does the incident still occur?
+インシデントの原因を特定するもう一つの有効な戦略は、本番以外の環境でインシデントを再現することです。現象の切り分けを行えるように変数を変更して実験を行います。入力の一部を変更または削除した場合も、まだインシデントは発生しますか？
 
-This level of analysis will uncover the superficial causes of the incident. Next, ask why the system was designed in a way to make this possible. Why did those design decisions seem to be the best decisions at the time? Answering these questions will help you uncover root causes.
+このレベルまで分析を行うと、インシデントの表面的な原因が明らかになります。次に、このような事象が発生しうる形でシステムが設計された背景を尋ねます。なぜ、当時それらの設計判断が最良の決定だと思われたのでしょうか？これらの質問に答えていくと、根本原因を明らかにするのにつながります。
 
-Here are some questions to help the postmortem owner identify the class of a particular problem:
+以下は、ポストモーテムオーナーが特定の問題の種類を特定するのに役立つ質問です：
 
-- Is it an isolated incident or part of a trend?
-- Was this a specific bug, a failure in a class of problem we anticipated, or did it uncover a class of issue we did not architecturally anticipate?
-- Was there work the team chose not to do in the past that contributed to this incident?
-- Research if there were any similar or related incidents in the past. Does this incident demonstrate a larger trend in your system?
-- Will this class of issue get worse/more likely as you continue to grow and scale the use of the service?
+- これは単独のインシデントですか、それとも直近よく発生しているものの一部ですか？
+- これは特定のバグや予想された種類の障害だったか、またアーキテクチャ的に予想していなかった問題の種類を明らかにしましたか？
+- 過去にチームがやらないことを選択した作業で、このインシデントに寄与したものはありましたか？
+- 過去に類似または関連するインシデントがあったかどうかを調査します。このインシデントは、システムのより大きな範囲の傾向を示すものですか？
+- サービスの使用を継続的に成長させ拡大するにつれて、この種の問題は悪化/より発生しやすくなりますか？
 
 !!! tip
-    At PagerDuty, we have a separate process for analyzing larger trends across multiple incidents to inform technical and organizational planning. Learn more in our guide on [Operational Reviews](http://reviews.pagerduty.com).
+    PagerDutyでは、技術的および組織的な計画に情報を提供するために、複数のインシデントに渡るより大きな範囲の傾向を分析するための別のプロセスがあります。詳細は[運用レビュー](http://reviews.pagerduty.com)に関するガイドをご覧ください。
 
-Though it may not be a root cause, consider the process in your analysis. Did the way that people collaborate, communicate, and/or review work contribute to the incident? This is also an opportunity to evaluate and improve the incident response process. Consider what worked well and didn't work well within the incident response process during the incident.
+根本原因ではないかもしれませんが、分析においてはプロセスも考慮してください。人々が協力し、コミュニケーションを取り、作業をレビューする方法がインシデントに寄与しましたか？これはまた、インシデント対応プロセスを評価し改善する機会でもあります。インシデント中の対応プロセスで何がうまくいき、何がうまくいかなかったかを考えてみてください。
 
-Write a summary of the findings in the postmortem. The team may find further learnings and identify additional causes through discussion in the meeting, but the owner should do as much pre-work and documentation as possible to ensure a productive discussion.
+ポストモーテムに調査結果の要約を書きます。チームは会議での議論を通じてさらなる学びを見つけ、追加の原因を特定するかもしれませんが、オーナーは生産的な議論を確保するために可能な限り事前作業と文書化を行ういましょう。
 
-### Questions to Ask
-Below is a non-exhaustive list to help stimulate deep analysis. Ask "how" and "what" questions rather than "who" or "why" to discourage blame and encourage learning.
+### 質問項目
+以下は、深い分析を促進するためのリストです。非難を避け、学習を促進するために、「誰が」や「なぜ」ではなく、「どのように」「何が」という質問をしてください。
 
 <table>
     <tr>
-        <td>Cues</td>
+        <td>手がかり</td>
         <td>
             <ul>
-                <li>What were you focusing on?</li>
-                <li>What was not noticed?</li>
-                <li>What differed from what was expected?</li>
+                <li>何に注目していましたか？</li>
+                <li>何が見落とされていましたか？</li>
+                <li>予想と異なっていたのは何でしたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Previous Knowledge/Experience</td>
+        <td>過去の知識/経験</td>
         <td>
             <ul>
-                <li>Was this an anticipated class of problem or did it uncover a class of issue that was not architecturally anticipated?</li>
-                <li>What expectations did participants have about how things were going to develop?</li>
-                <li>Were there similar incidents in the past?</li>
+                <li>これは予想された問題の種類でしたか、それともアーキテクチャ上予想されていなかった問題の種類を明らかにしましたか？</li>
+                <li>参加者は事態の進展についてどのような想定を持っていましたか？</li>
+                <li>過去に類似したインシデントはありましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Goals</td>
+        <td>目標</td>
         <td>
             <ul>
-                <li>What goals governed your actions at the time?</li>
-                <li>How did time pressure or other limitations influence choices?</li>
-                <li>Was there work the team chose not to do in the past that could have prevented or mitigated this incident?</li>
+                <li>当時のあなたの行動を支配していた目標は何でしたか？</li>
+                <li>時間的制約やその他の制限が選択にどのような影響を与えましたか？</li>
+                <li>過去にチームが行わないことを選択した作業で、このインシデントを防止または軽減できたものはありましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Assessment</td>
+        <td>評価</td>
         <td>
             <ul>
-                <li>What mistakes (for example, in interpretation) were likely?</li>
-                <li>How did you view the health of the services involved prior to the incident?</li>
-                <li>Did this incident teach you something that should change views about this service's health?</li>
+                <li>どのようなミス（例えば、解釈における）が起こりやすかったですか？</li>
+                <li>インシデント発生前に、関連するサービスの健全性をどのように見ていましたか？</li>
+                <li>このインシデントは、このサービスの健全性に関する見方を変えるべき何かを教えてくれましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Taking Action</td>
+        <td>行動</td>
         <td>
             <ul>
-                <li>How did you judge you could influence the course of events?</li>
-                <li>What options were taken to influence the course of events? How did you determine that these were the best options at the time?</li>
-                <li>How did other influences (operational or organizational) help determine how you interpreted the situation and how you acted?</li>
+                <li>どのように事態の流れに影響を与えられると判断しましたか？</li>
+                <li>事態の流れに影響を与えるためにどのような選択肢が取られましたか？これらが当時の最善の選択肢であると、どのように判断しましたか？</li>
+                <li>他の影響（運用上または組織上）が、状況の解釈や行動の決定にどのように役立ちましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Help</td>
+        <td>支援</td>
         <td>
             <ul>
-                <li>Did you ask anyone for help?</li>
-                <li>What signal brought you to ask for support?</li>
-                <li>Were you able to contact the people you needed to contact?</li>
+                <li>誰かに助けを求めましたか？</li>
+                <li>どのような契機で他の人へサポートを求めましたか？</li>
+                <li>連絡する必要のある人々に連絡することはできましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Process</td>
+        <td>プロセス</td>
         <td>
             <ul>
-                <li>Did the way that people collaborate, communicate, and/or review work contribute to the incident?</li>
-                <li>What worked well in your incident response process and what did not work well?</li>
+                <li>人々が協力し、コミュニケーションを取り、作業をレビューする方法がインシデントに寄与しましたか？</li>
+                <li>インシデント対応プロセスで上手くいったことと上手くいかなかったことは何ですか？</li>
             </ul>
         </td>
     </tr>
 </table>
 
-!!! info "Key Takeaways"
-    * Find contributing factors, not the root cause.
-    * Focus on the system, not the humans.
-    * Look for anomalies in monitoring.
-    * Reproduce and experiment in a non-production environment.
-    * Don't forget to review your processes.
+!!! info "重要なポイント"
+    * 根本原因ではなく、寄与要因を見つけること。
+    * 人間ではなく、システムに焦点を当てること。
+    * モニタリングの異常を探すこと。
+    * 本番以外の環境で再現し実験すること。
+    * プロセスのレビューを忘れないこと。
 
-## Follow-Up Actions<a name="followup"></a>
+## フォローアップアクション<a name="followup"></a>
 ![Followup](../assets/img/thumbnails/5FollowUpActions.png)
-After identifying what caused the incident, ask what needs to be done to prevent this from happening again. Based on your analysis, you may also have proposals to reduce the occurrence of this class of problem, rather than this specific incident from recurring.
+インシデントの原因を特定した後、これが再び起こらないようにするために何をする必要があるかを考えます。分析に基づいて、この特定のインシデントではなく、この種の問題の発生を減らすための提案もあるかもしれません。
 
-It may not be possible (or worth the effort) to completely eliminate the possibility of this same incident or a similar incident from happening again, so also consider how you can improve detection and mitigation of future incidents. Does the team need better monitoring and alerting around this class of problem so they can respond faster in the future? If this class of incident does happen again, how can the team decrease the severity or duration? Remember to identify any actions that can make the incident response process better, too. Go through the incident history in Slack to find any to-do items raised during the incident and make sure these are documented as tickets as well. (At this phase, you are only opening tickets. There is no expectation that tasks will be completed before the postmortem meeting.)
+同じインシデントや類似のインシデントが再び発生する可能性を完全に排除することは不可能（または努力に値しない）かもしれないので、将来のインシデントの検出と軽減をどのように改善できるかも考慮してください。この種の問題に対してはより良いモニタリングとアラートが必要で、将来より迅速にチームが対応できるようにする必要がありますか？この種のインシデントが再び発生した場合、チームはどのように重大度や対応時間を抑えることができますか？インシデント対応プロセスを改善するためのアクションも特定することを忘れないでください。Slackのインシデント履歴を確認して、インシデント中に提起されたすべてのToDoアイテムを見つけ、これらもチケットとして文書化されていることを確認してください。（この段階では、チケットを作成するだけです。ポストモーテムミーティングの前にタスクを完了させる必要はありません。）
 
-Create tickets for all proposed follow-up actions in your task management tool. Label all tickets with their severity level and date tags so they can be easily found and reported in the ticketing system. Provide as much context and proposed direction on the tickets as you can so the team's product owner will have enough information to prioritize the task against other work and the eventual assignee will have enough information to complete the task.
+提案されたすべてのフォローアップアクションのチケットをタスク管理ツールで作成します。すべてのチケットに重大度レベルと日付タグを付けて、チケットシステムで簡単に見つけて報告できるようにします。チームのプロダクトオーナーが他の作業と比較してタスクの優先順位を付けるのに十分な情報があり、最終的な担当者がタスクを完了するのに十分な情報を得られるよう、チケットにできるだけ多くのコンテキストと提案された方向性を提供してください。
 
-In the _;login:_ magazine article, "[Postmortem Action Items: Plan the Work and Work the Plan](https://www.usenix.org/system/files/login/articles/login_spring17_09_lunney.pdf)," John Lunney, Sue Lueder, and Betsy Beyer write about how Google writes postmortem action items to ensure they are completed quickly and easily. They advise all action items to be written as actionable, specific, and bounded.
+_;login:_ マガジンの記事「[Postmortem Action Items: Plan the Work and Work the Plan](https://www.usenix.org/system/files/login/articles/login_spring17_09_lunney.pdf)」で、John Lunney・Sue Lueder・Betsy Beyerは、Googleがポストモーテムのアクションアイテムを迅速かつ簡単に完了させるためにどのように書いているかを説明しています。彼らはすべてのアクションアイテムを実行可能、具体的、かつ範囲が限定されたものとして書くことを勧めています。
 
-- **Actionable:** Phrase each action item as a sentence starting with a verb. The action should result in a useful outcome.
-- **Specific:** Define each action item's scope as narrowly as possible, making clear what is in and out of scope.
-- **Bounded:** Word each action item to indicate how to tell when it is finished, as opposed to open-ended or ongoing tasks.
+- **実行可能：** 各アクションアイテムを動詞で始まる文として表現します。アクションは有用な結果をもたらすようにします。
+- **具体的：** 各アクションアイテムの範囲をできるだけ狭く定義し、範囲内と範囲外を明確にします。
+- **範囲が限定的：** 各アクションアイテムを、オープンエンドまたは継続的なタスクではなく、いつ終了したかを示すように表現します。
 
-| Poorly Worded | Better |
+| 不適切な表現 | より良い表現 |
 |-|-|
-| Investigate monitoring for this scenario. | **Actionable:** Add alerting for all cases where this service returns >1% errors. |
-| Fix the issue that caused the outage. | **Specific:** Handle invalid postal code in user address form input safely. |
-| Make sure engineer checks that database schema can be parsed before updating. | **Bounded:** Add automated presubmit check for schema changes. |
+| このシナリオのモニタリングを調査する。 | **実行可能：** このサービスが>1%のエラーを返すすべてのケースのアラートを追加する。 |
+| 停止を引き起こした問題を修正する。 | **具体的：** ユーザーアドレスフォーム入力の無効な郵便番号を安全に処理する。 |
+| エンジニアが更新前にデータベーススキーマが解析できることを確認するようにする。 | **範囲が限定的：** スキーマ変更の自動事前送信チェックを追加する。 |
 
-<small>Source: _;login:_  Spring 2017 Vol. 42, No. 1.</small>
+<small>出典: _;login:_  Spring 2017 Vol. 42, No. 1.</small>
 
-If there are any proposed follow-up actions that need discussion before tickets can be created, make a note to add these items to the postmortem meeting agenda. These may be proposals that need team validation or clarification. Discussing these items in the meeting will help decide how best to proceed.
+チケットを作成する前に議論が必要なフォローアップアクションの提案がある場合は、これらの項目をポストモーテムミーティングの議題に追加するメモを作成しましょう。場合によってはチームの検証や明確化が必要な提案かもしれません。会議でこれらの項目を議論すると、どのように進めるのが最善かを決定するのに役立つでしょう。
 
-Be careful with creating too many tickets. Only create tickets that are P0/P1s; i.e., tasks that absolutely should be dealt with. There will be some trade-offs here, and that's fine. Sometimes the ROI isn't worth the effort that would go into performing an action that may reduce the recurrence of the incident. When that is the case, it is worth documenting that decision in the postmortem. Understanding why the team is choosing not to perform an action helps avoid learned helplessness.
+あまりにも多くのチケットを作成しないように注意してください。P0/P1のタスク、つまり絶対に対処すべきタスクのみを作成しましょう。ここにはいくらかトレードオフが発生することがありますが、それは問題ありません。ときには、インシデントの再発を減らす可能性のあるアクションを実行するために必要な労力に対して、ROIが見合わないケースもあります。その場合も、その決定をポストモーテムに文書化しておく価値があります。チームがアクションを実行しないことを選択した理由を理解するのは、やったことが役に立たなかったのではないかという無力感を避けるのにも役立つでしょう。
 
-Note the person who creates the ticket is not responsible for completing it. Tickets are opened under the projects for the teams that own the affected service. At least one representative for all teams that will be responsible for a follow-up action are invited to the postmortem meeting.
+チケットを作成する人自身がそれを完了する責任を負うわけではないことに注意しましょう。チケットは影響を受けたサービスを所有するチームのプロジェクトでオープンされます。フォローアップアクションの責任を負うすべてのチームの代表者を少なくとも1人、ポストモーテムミーティングに招待します。
 
 
-!!! info "Key Takeaways"
-    * What needs to be done to reduce the likelihood of this, or a similar, incident from happening again?
-    * How can you detect this type of incident sooner?
-    * How can you decrease the severity or duration of this type of incident?
-    * Write actionable, specific, and bounded tasks.
+!!! info "重要なポイント"
+    * このインシデントや類似のインシデントが再発する可能性を減らすために、何をする必要がありますか？
+    * この種のインシデントをより早く検出するにはどうすればよいですか？
+    * この種のインシデントの重大度や対応期間をどのように抑えることができますか？
+    * 実行可能、具体的、かつ範囲が限定されたタスクを書くこと。
 
-## Write External Messaging
+## 対外メッセージの作成
 ![External](../assets/img/thumbnails/6WriteExternalMessaging.png)
-The goal of external messaging is to build trust by giving customers enough information about what happened and what you're doing about it, without giving away proprietary information about your technology and organization. There are parts of your internal analysis that primarily benefit the internal audience and do not need to be included in your external postmortem.
+対外メッセージの目的は、技術や組織に関する独自情報を明かすことなく、何が起こったのか、それに対して何をしているのかについて顧客に十分な情報を提供することで信頼を築くことです。内部分析の一部は主に内部の読者に利益をもたらすもので、外部のポストモーテムに含める必要はありません。
 
-The external postmortem is a summarized and sanitized version of the information used for the internal postmortem. External postmortems include these three sections:
+外部ポストモーテムは、内部ポストモーテムに使用される情報を要約し、整理したものです。外部ポストモーテムには以下の3つのセクションが含まれます：
 
-1. **Summary:** Two to three sentences that summarize the duration of the incident and the observable customer impact.
-1. **What Happened:** 
-    - Summary of cause(s).
-    - Summary of customer-facing impact during the incident.
-    - Summary of mitigation efforts during the incident.
-1. **What Are We Doing About This:** Summary of action items.
+1. **要約：** インシデントの期間と観測可能な顧客への影響を要約した2〜3文。
+1. **何が起きたか：** 
+    - 原因の要約。
+    - インシデント中の顧客向け影響の要約。
+    - インシデント中の緩和努力の要約。
+1. **これに対して何をしているか：** アクションアイテムの要約。
 
->Tip: Avoid using the word "outage" unless it really was a full outage—use the word "incident" or "service degradation" instead. Customers generally see "outage" and assume the worst.
+>ヒント：本当に完全な停止でない限り、「停止（outage）」という言葉を使用することは避けてください。代わりに「インシデント」または「サービス低下」という言葉を使用してください。顧客は一般的に「停止」を見て最悪の事態を想定します。
 
-Note that at this point, the external postmortem is drafted language that should not be sent or published. It needs to be reviewed during the postmortem meeting before being sent out.
+この時点で、外部ポストモーテムはまだ送信または公開すべきではないドラフトであることに注意してください。送信前にポストモーテムミーティングでレビューする必要があります。
 
-## Postmortem Review
+## ポストモーテムレビュー
 ![Review](../assets/img/thumbnails/7PostmortemReview.png)
-At PagerDuty, we have a community of experienced postmortem writers available to review postmortems for style and content. This avoids wasted time during the meeting. We post a link to the postmortem into Slack to receive feedback at least 24 hours before the meeting is scheduled.
+PagerDutyでは、スタイルと内容に関するポストモーテムのレビューに活用できる経験豊富なポストモーテム作成者のコミュニティがあります。これにより、会議中の無駄な時間を減らせます。会議がスケジュールされる少なくとも24時間前に、Slackへポストモーテムへのリンクを投稿してフィードバックを受け取ります。
 
-Here are some of the things we look for:
+以下は、私たちが主に確認する事柄です：
 
-- Does it provide enough detail?
-- Rather than just pointing out what went wrong, does it drill down to the underlying causes of the issue?
-- Does it separate "What happened?" from "How to fix it"?
-- Do the proposed action items make sense? Are they well-scoped enough?
-- Is the postmortem well-written and understandable?
-- Does the external message resonate well with customers or is it likely to cause outrage?
+- 十分な詳細を提供していますか？
+- 何が間違っていたかを指摘するだけでなく、問題の根本的な原因を掘り下げていますか？
+- 「何が起きたか？」と「どう修正するか」を分けていますか？
+- 提案されたアクションアイテムは意味がありますか？十分に範囲が限定されていますか？
+- ポストモーテムは適切に書かれ、理解可能ですか？
+- 対外メッセージは顧客の共感を得られそうな内容ですか、それとも反感を引き起こす可能性がありますか？
 
-Reviewing a postmortem isn't about nitpicking typos (but do make sure the external message isn't littered with spelling and grammatical errors). It's about providing constructive feedback on valuable changes to a postmortem to get the most benefit from them.
+ポストモーテムのレビューは誤字脱字を細かく指摘することではありません（ただし、対外メッセージにスペルや文法エラーがないことを確認してください）。重要なのは、ポストモーテムから最大の利益を得るために、ポストモーテムに価値ある変更を加えるための建設的なフィードバックを提供することです。
diff --git a/docs/index.md b/docs/index.md
index add0f8e..30edaf6 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,42 +1,42 @@
 ![PagerDuty](assets/img/headers/Postmortems-Title.png)
 
-Performing postmortems after incidents is how you learn what you're doing right, where you could improve, and most importantly, how to avoid making the same mistakes again and again. Well-designed postmortems allow your teams to iteratively improve your infrastructure and incident response process.
+インシデント発生後にポストモーテムを実施すると、何がうまくいったのか、どこを改善できるのか、そして最も重要なこととして、同じ誤りを繰り返さないための方法を学べます。適切に設計されたポストモーテムを行えば、チームはインフラストラクチャとインシデント対応プロセスを段階的に改善できるでしょう。
 
-The postmortem concept is well known in the technology industry, but it can be difficult for newer individuals, teams, and organizations to adopt the cultural nuances required for effective postmortems. This guide will teach you how to build a culture of continuous learning, the most important components to include in your analysis, and how to conduct effective postmortem meetings.
+ポストモーテムの概念はテクノロジー業界ではよく知られていますが、効果的なポストモーテムに求められる文化的ニュアンスを、個人やチーム、組織が新たに取り入れるのは難しいこともよくあります。このガイドでは、継続的な学習の文化を構築する方法、分析に含めるべき最も重要な要素、そして効果的なポストモーテムミーティングを実施する方法について説明します。
 
-## Who Is This For?
-This resource is for on-call practitioners who want to iteratively learn from incidents affecting their team and for managers who want to cultivate a culture of learning in their organization.
+## 対象者
+このリソースは、チームに影響を与えるインシデントから段階的に学びたいオンコール担当者や、組織内に学習の文化を育みたいマネージャーを対象としています。
 
-## What Is Covered?
-### What Is a Postmortem?
-The who, what, when, and why of [postmortems](what_is.md).
+## 内容
+### ポストモーテムとは
+[ポストモーテム](what_is.md)を誰が、何を、いつ、なぜ行うのか。
 
-### Blameless Culture
-A successful postmortem process is based on a culture of honesty, learning, and accountability. Culture change requires management buy-in, but you can lead culture change no matter your role. This section describes common challenges in building a culture of continuous learning through postmortems, and strategies for overcoming them.
+### 非難のない（ブレームレスな）文化
+成功するポストモーテムプロセスは、誠実さ、学習、そして説明責任の文化に基づいています。カルチャーの変革には経営陣の賛同が必要ですが、あなたの役割によらず推進していくことは可能です。このセクションでは、ポストモーテムを通じて継続的な学習の文化を構築するにあたっての一般的な課題と、それらを克服するための戦略について説明します。
 
-- [The Blameless Postmortem](culture/blameless.md)
-- [How to Introduce Postmortems](culture/introduce.md)
-- [Information Sharing](culture/sharing.md)
-- [Accountability](culture/accountability.md)
+- [非難のない（ブレームレスな）ポストモーテム](culture/blameless.md)
+- [ポストモーテムの導入方法](culture/introduce.md)
+- [情報共有のありかた](culture/sharing.md)
+- [説明責任の考えかた](culture/accountability.md)
 
-### How to Write a Postmortem
-You will learn what information to include in the postmortem, how to collect and present that information, and how to conduct an effective analysis that results in system improvements.
+### ポストモーテムの書き方
+ポストモーテムに含めるべき情報、その情報の収集と提示方法、そしてシステムの改善につながる効果的な分析の実施方法について学びます。
 
-- [Step by Step](how_to_write/writing.md)
-- [Tips for Effective Postmortems](how_to_write/effective_postmortems.md)
+- [段階を追ったポストモーテムの書きかた](how_to_write/writing.md)
+- [効果的なポストモーテムのためのヒント](how_to_write/effective_postmortems.md)
 
-### Postmortem Meetings
-How to conduct productive [postmortem meetings](meeting.md).
+### ポストモーテムミーティング
+生産的な[ポストモーテムミーティング](meeting.md)の実施方法を解説します。
 
-### Additional Resources
+### 追加リソース
 
-- [Template](resources/post_mortem_template.md)
-- [Checklist](resources/checklist.md)
-- [Analysis Questions](resources/analysis.md)
-- [Examples](resources/examples.md)
-- [Further Reading](resources/reading.md)
+- [テンプレート](resources/post_mortem_template.md)
+- [チェックリスト](resources/checklist.md)
+- [分析にあたっての質問](resources/analysis.md)
+- [実践例](resources/examples.md)
+- [参考文献](resources/reading.md)
 
-### License
-This documentation is provided under the Apache License 2.0. In plain English that means you can use and modify this documentation and use it both commercially and for private use. However, you must include any original copyright notices, and the original LICENSE file.
+### ライセンス
+このドキュメントはApache License 2.0の下で提供されています。平たく言えば、このドキュメントを使用および修正し、商業的にも個人的にも使用することができます。ただし、元の著作権表示と元のLICENSEファイルを含める必要があります。
 
-Whether you are a PagerDuty customer or not, we want you to have the ability to use this documentation internally at your own company. You can view the source code for all of this documentation on our GitHub account, feel free to fork the repository and use it as a base for your own internal documentation.
+PagerDutyのお客様であるかどうかに関わらず、このドキュメントを自社内でご活用いただきたいと考えています。このドキュメントのソースコードはすべて当社のGitHubアカウントで閲覧でき、リポジトリをフォークして独自の内部ドキュメントのベースとして使用することができます。
diff --git a/docs/meeting.md b/docs/meeting.md
index 33b95a7..8fb8adf 100644
--- a/docs/meeting.md
+++ b/docs/meeting.md
@@ -1,140 +1,139 @@
 ---
 cover:
-description: After you have completed the written postmortem, follow up with a meeting to discuss the incident. The purpose of this meeting is to deepen the postmortem analysis through direct communication and to get buy-in for action items.
+description: 文書化されたポストモーテムを完了した後、インシデントについて議論するためのミーティングを行います。このミーティングの目的は、直接的なコミュニケーションを通じてポストモーテム分析を深め、アクションアイテムへの賛同を得ることです。
 ---
 ![The Postmortem Meeting](assets/img/headers/Postmortems-Meeting.png)
 
-## Purpose
-After you have completed the written postmortem, follow up with a meeting to discuss the incident. **The purpose of this meeting is to deepen the postmortem analysis through direct communication and to get buy-in for action items.** The asynchronous production of the written postmortem helps the team start learning from the incident, but having a conversation leads to deeper learning. Furthermore, having a meeting scheduled to discuss the written postmortem creates [accountability](culture/accountability.md) for the postmortem to be completed in a timely manner. Using this time to discuss action items also helps ensure that those tasks will be completed.
+## 目的
+文書化されたポストモーテムを完了した後、インシデントについて議論するためのミーティングを行います。**このミーティングの目的は、直接的なコミュニケーションを通じてポストモーテム分析を深め、アクションアイテムへの賛同を得ることです。** 文書化されたポストモーテムの非同期的な作成はチームがインシデントから学び始めるのに役立ちますが、会話を持つことでより深い学びにつながります。さらに、文書化されたポストモーテムについて議論するためのミーティングをスケジュールすることで、ポストモーテムをタイムリーに完了するための[説明責任（accountability）](culture/accountability.md)が生まれます。このミーティングでアクションアイテムについて議論することで、それらのタスクが確実に完了するよう支援します。
 
-An anti-pattern for the postmortem meeting is to be overly focused on the immediate concerns documented in the written postmortem. Avoid filling the meeting time by simply reading through each section of the document. The best use of this time is to take a step back from the detailed analysis to better understand the systemic factors that led to the incident.
+ポストモーテムミーティングのアンチパターンは、文書化されたポストモーテムに記載された直接的な懸念事項に過度に焦点を当てることです。ドキュメントの各セクションを単に読み上げることにミーティング時間を使うのは避けてください。この時間を最も有効に使う方法は、詳細な分析から一歩引いて、インシデントにつながったシステム的要因をより良く理解することです。
 
-Some teams make use of the [Retrospective Prime Directive](http://retrospectivewiki.org/index.php?title=The_Prime_Directive) to set the tone for the meeting and serve as a regular reminder of the goals. It can be a helpful tool to anchor the discussion and provide a clean slate to start a retrospective, postmortem, or post-incident review.
+一部のチームは、ミーティングの基調を設定し、目的を定期的に思い起こすために[レトロスペクティブ・プライム・ディレクティブ](http://retrospectivewiki.org/index.php?title=The_Prime_Directive)を活用しています。これは、レトロスペクティブ、ポストモーテム、またはポストインシデントレビューを始めるための白紙の状態を提供し、議論の基盤となる役立つツールとなります。
 
 >
-  "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
-  --Norm Kerth, Project Retrospectives: A Handbook for Team Review
+  「私たちが何を発見しようとも、その時点で知っていたこと、スキルと能力、利用可能なリソース、そして直面していた状況を考慮すれば、誰もが最善を尽くしたと理解して信じています。」
+  --Norm Kerth著「Project Retrospectives: A Handbook for Team Review」
 
 
-**The most important outcome of the postmortem meeting is buy-in for the action plan.** This is an opportunity to discuss proposed [action items](how_to_write/writing.md), brainstorm other options, and gain consensus among team leadership. Sometimes the ROI of proposed action items is not great enough to justify the work or postmortem action items must be delayed for other priorities. The postmortem meeting is a time to discuss these difficult decisions and make clear what work will and will not be done, as well as the expected implications of those choices.
+**ポストモーテムミーティングの最も重要な成果は、アクションプランへの賛同です。** これは提案された[アクションアイテム](how_to_write/writing.md)について議論し、他の選択肢についてブレインストーミングし、チームリーダーシップ間でコンセンサスを得る機会です。ときには、提案されたアクションアイテムの投資対効果が作業を正当化するほど大きくない場合や、他の優先事項をポストモーテムのアクションアイテムに比べて遅らせなければならない場合もあります。ポストモーテムミーティングは、これらの難しい決断について議論し、どの作業を行い、どの作業を行わないのか、そしてそれらの選択によって予想される影響を明確にする時間です。
 
-Whereas the written postmortem is intended to be shared widely in the organization, the primary audience for the postmortem meeting is the teams directly involved with the incident. This meeting gives the team a chance to align on what happened, what to do about it, and how they will communicate about the incident to internal and external stakeholders.
+文書化されたポストモーテムは組織内で広く共有されることを意図していますが、ポストモーテムミーティングの主な対象者はインシデントに直接関わったチームです。このミーティングは、チームが何が起こったのか、それについて何をすべきか、そしてインシデントについて内部および外部のステークホルダーにどのように伝えるかについて認識を合わせる機会を提供します。
 
 !!! tip
-    Send a link to the postmortem document to meeting attendees 24 hours before the meeting. Though the postmortem does not need to be complete when it is sent to the attendees, it should be finished before the postmortem meeting. It is still worth sending an incomplete postmortem to meeting attendees in advance so they can start reading through the document.
-
-    This will help you avoid wasting time in the meeting simply reading through the document. Remember the purpose of the meeting is to have an in-depth conversation about what caused the incident and how to prevent it in the future, not to review the document. The postmortem meeting is also an opportunity to clarify any questions about what happened and what the team plans to do to prevent it from happening again. Encourage attendees to ask any and all questions to help everyone get on the same page
-    and help the team consider new perspectives for their analysis.
-
-## Agenda
-Here is a sample agenda for the meeting:
-
-1. **Postmortem owner** summarizes incident causes and timeline. **Facilitator** leads discussion:
-    - What were the larger cultural and structural factors that lead to the incident? **How did we get here?**
-1. **Postmortem owner** summarizes proposed follow-up action items. **Facilitator** leads discussion:
-    - Is the team **confident** this plan will reduce the likelihood of this incident recurring?
-    - **What more or different work might be needed?**
-    - Will team leadership (Engineering Manager, Product Manager, Tech Lead, etc.) **commit** to prioritizing these action items?
-1. **Customer liaison** summarizes customer impact.
-    - Provide any new context about customer reaction to the incident.
-    - Review and approve external communication drafted in the postmortem.
-
-## Who Participates
-The postmortem owner invites the following people to the postmortem meeting. Below is more detail about the role each plays in the discussion.
-
-- Always
-    - The [incident commander](https://response.pagerduty.com/training/incident_commander/).
-        - The incident commander is responsible for coordinating the response. During the postmortem meeting the incident commander can provide valuable feedback on the incident response effort and process improvements.
-    - The incident commander shadowee (if there was one).
-        - This person may have served as the [scribe](https://response.pagerduty.com/training/scribe/) or [deputy](https://response.pagerduty.com/training/deputy/). The deputy incident commander is responsible for adding necessary responders to the call and updating internal stakeholders outside of the incident response call. The deputy can provide valuable feedback on the response effort and the ease or difficulty of communicating with additional responders and stakeholders during incident response.
-    - [Service owners](https://response.pagerduty.com/training/subject_matter_expert/) and other key engineers involved in the incident.
-        - On-call service owners and other engineers that responded to the incident are the experts of the affected services. During the postmortem meeting they can provide historical context about how the systems were built, cultural context about what was happening with the team leading up the incident, and proposals for what work would reduce the likelihood of this incident recurring.
-        - Productive postmortem discussions will include engineers with in-depth knowledge of the part of the system that their team owns. If the engineer(s) that responded to the incident are newer to the team, it will be helpful to include more experienced engineers from their team in the postmortem meeting.
-    - Engineering manager for impacted systems.
-        - The manager responsible for the teams that responded to the incident attends the postmortem meeting to inform their staffing and technical investment decisions
-    - Product manager for impacted systems.
-        - Product managers attend postmortem meetings to understand the effect incidents have on their customers' experience. For postmortem action items to be prioritized and completed, it is critical to engage product managers in this discussion of the importance and scope of proposed follow-up tasks.
-- Optional (Only Sev-1 incidents)
-    - [Customer liaison](https://response.pagerduty.com/training/customer_liaison/).
-        - The customer liaison can speak to customers' reactions to the incident. They need to understand the team's decision on action items so they can finalize and send external messaging.
-
-## Facilitation
-### What Is Facilitation
-The facilitator's role in the postmortem meeting is different from the other participants. The facilitator does not voice their own ideas in the meeting; instead, they encourage the group to speak up and keep the discussion on track. The postmortem owner, the incident commander, or any other meeting attendee that played an active role during the incident are the ones who need to contribute to the discussion and should not also be responsible for facilitating.
-
-The facilitator:
-
-- Encourages people to speak up and makes sure that everyone is heard.
-- Clarifies insights and challenges the team with questions.
-- Helps the team see different perspectives and different options.
-- Keeps everyone on time and on track. Cuts off tangents and stops people from dominating the entire meeting.
-- Speaks as little as possible. Remember to guide the discussion, but do not take over the meeting.
-
-The facilitator does not:
-
-- Make decisions.
-- Take sides. If the facilitator takes sides, team members might feel attacked and might stop contributing to the meeting.
-    - Comment on what people say, even if they are trying to give positive feedback. It may make the speaker feel validated, but it might also make the others feel worse about what they have to say or discourage them from contributing something.
-
-### Who Should Facilitate
-Good facilitators tend to have a high level of emotional intelligence and can easily read non-verbal cues to understand how people are feeling. They use this sense to cultivate an environment where everyone is comfortable speaking. Agile coaches and project managers are often skilled facilitators. At PagerDuty, we have a guild of confident facilitators who coach individuals interested in learning how to facilitate. When searching for individuals in your organization to help facilitate postmortem meetings, look for people with these core competencies:
-
-- Can read non-verbal cues to assess how people are feeling in the room and spot who might have something to say.
-- Can paraphrases what is said to clarify for self and others.
-- Can ask open questions to stimulate deeper thinking.
-- Is comfortable interrupting when discussion gets off track or when someone dominates the discussion.
-- Can redirect conversation to focus on goals.
-- Can keep track of time and give time reminders.
-- Can drive discussion to decision-making and action items.
-
-Postmortem meeting facilitators do not need to be experts in the affected systems. Facilitators do not need to be well-versed in the content of the discussion. Remember, the facilitator does not contribute their own opinions to the discussion, but works to get others to speak. The meeting attendees that were involved with the incident response are the experts on the incident, and the facilitator will ask the right questions to encourage those experts to share information with the group.
-
-Your facilitator should, however, be familiar with the postmortem process and the goals of the postmortem meeting so they can guide the group discussion to achieve those goals. Postmortem meeting facilitators must have a strong understanding of [blamelessness](culture/blameless.md) so they can help the group avoid blaming speech in the meeting.
-
-## Facilitation Tips
-The postmortem meeting facilitator helps the team dig deeper into their analysis, [avoid blame](culture/blameless.md), and get buy-in for their action items. Common challenges for the postmortem meeting are being overly focused on the written postmortem and succumbing to the tendency to blame individuals for system failure. Below are tips on how to run effective postmortem meetings and how to handle awkward situations when they arise.
-
-**Housekeeping**
-
-- Set ground rules at the beginning of the meeting.
-    - Set the expectation that everyone should speak but no-one should hog the conversation.
-    - Remind the group that we practice blameless postmortems.
-- Establish a safe word for when the conversation gets off track.
-    - If a team member notices the conversation is getting off-topic they can say the safe word and have the team re-evaluate the usefulness of the discussion. At PagerDuty, some teams use the acronym ELMO which stands for "Enough, let's move on." This takes pressure off the facilitator alone to interrupt when discussion gets off-topic.
-- Share the agenda so the team is clear on what is on- and off-topic.
-- Use a timer to timebox.
-    - You can timebox each agenda item. Presenting a timer makes everyone aware of the time limit and reduces the need for the facilitator to interrupt for time.
-- Present the postmortem document from your laptop onto the TV so everyone can see.
-
-[**How to avoid blame:**](culture/blameless.md)
-
-- Remind the team at the start of the meeting and/or when blame occurs during the meeting that we have agreed to practice blameless postmortems and call each other out when blame occurs.
-- Look out for and avoid "who" or "why" questions, which limit analysis and imply blame. Instead ask "what" and "how" questions, such as:
-    - "What did you think was happening?"
-    - "What did you do next?"
-    - "How did that action make sense at the time?"
-- When inquiring about a human action, abstract to an non-specific responder. Remind the team anyone could have made the same mistake.
-    - "What could have led any responder to take that action?"
-
-**What to do when the conversation is getting off-topic:**
-
-- The facilitator's job is to keep the team on track and will need to interrupt to remind the team of the meeting goals by asking if it is valuable to continue with a topic or if it can be taken offline.
-    - "Sorry to interrupt, but this topic seems unrelated to the goals of this meeting, do we want to go back to the original topic or continue with this discussion?"
-- Timebox agenda items. Once the time is done they can vote if they want to keep talking for another few minutes.
-
-**What to do when one person is dominating the meeting:**
-
-- Say upfront that participation from everyone is important. Explain the facilitator's responsibilities so they won't be offended if they are asked to stop talking or speak up. Pay attention to how much people are talking throughout the meeting.
-- "I wasn't able to hear what the first person was saying."
-- Act as a mediator and call out when people are getting interrupted: "Hold that thought – I want to make sure Shari has a chance to finish"
-
-**If a team member has not said anything, how do you get them to contribute:**
-
-- "Let's go around the room and hear from everyone"
-- "What's stood out for you so far?"
-- "What else might we need to consider?"
-
-**How to stimulate analysis:**
-
-- Ask open questions, no questions that can be answered with "yes" or "no."
-- Reference our [analysis questions](resources/analysis.md). The team may have asked themselves these questions as they were preparing the written postmortem. Asking some of these in the meeting will encourage new, collaborative thinking.
+    ミーティングの24時間前にポストモーテムドキュメントのリンクを参加者に送信してください。ポストモーテムは参加者に送信される時点で完成している必要はありませんが、ポストモーテムミーティングの開催までに完成させましょう。参加者が文書を読み始められるように、不完全なポストモーテムでも事前に共有しておく価値があります。
+
+    これにより、ミーティングで単に文書を読み上げるために時間を無駄にすることを避けられます。ミーティングの目的は、インシデントの原因と将来それを防ぐ方法について深い会話をすることであり、文書をレビューすることではないことを覚えておいてください。ポストモーテムミーティングは、何が起こったのか、そしてそれが再び起こるのを防ぐためにチームで何をするかに関する疑問点を明らかにする機会でもあります。全員が同じ認識を持てるよう、参加者にあらゆる質問を促し、分析を進める上でチームが新しい視点から考えられるようにしましょう。
+
+## アジェンダ
+ミーティングのサンプルアジェンダは以下の通りです：
+
+1. **ポストモーテム担当者**がインシデントの原因とタイムラインを要約します。**ファシリテーター**が議論をリードします：
+    - インシデントにつながったより大きな文化的・構造的要因は何でしたか？**どのようにしてここに至ったのでしょうか？**
+1. **ポストモーテム担当者**が提案されたフォローアップアクションアイテムを要約します。**ファシリテーター**が議論をリードします：
+    - この計画がインシデントの再発の可能性を減らすことに、チームは**自信**を持てますか？
+    - **どのような追加または異なる作業が必要な可能性がありますか？**
+    - チームリーダーシップ（エンジニアリングマネージャー、プロダクトマネージャー、テックリードなど）はこれらのアクションアイテムを優先することを**約束**しますか？
+1. **カスタマーリエゾン**が顧客への影響を要約します。
+    - インシデントに対する顧客の反応について、新たなコンテキストを提供します。
+    - ポストモーテムで起草された外部コミュニケーション内容をレビューし、承認します。
+
+## 参加者
+ポストモーテム担当者は、ポストモーテムミーティングに以下の人々を招待します。以下は、各自が議論で果たす役割についての詳細です。
+
+- 必須参加
+    - [インシデントコマンダー](https://response.pagetduty.co.jp/training/incident_commander/)。
+        - インシデントコマンダーは対応の調整を担当します。ポストモーテムミーティングでは、インシデントコマンダーはインシデント対応の取り組みとプロセス改善について貴重なフィードバックを提供できます。
+    - インシデントコマンダーのシャドーイングをしていた人（いた場合）。
+        - この人は[書記官](https://response.pagetduty.co.jp/training/scribe/)または[副指揮官](https://response.pagetduty.co.jp/training/deputy/)を務めた可能性があります。副指揮官は、必要な対応者をコールに追加し、インシデント対応コール外の内部ステークホルダーを更新する責任があります。副指揮官は対応の取り組みと、インシデント対応中に追加された対応者やステークホルダーとのコミュニケーションに関し、やりやすかった面や難しかった面について貴重なフィードバックを提供できます。
+    - インシデントに関わった[サービスオーナー](https://response.pagetduty.co.jp/training/subject_matter_expert/)と他の主要なエンジニア。
+        - オンコールのサービスオーナーとインシデントに対応した他のエンジニアは、影響を受けたサービスの専門家です。ポストモーテムミーティングでは、システムがどのように構築されたかについての歴史的コンテキスト、インシデントに至るまでのチームで起きていたことについての文化的コンテキスト、そしてこのインシデントの再発の可能性を減らすためにどのような作業が必要かについての提案を提供できます。
+        - 生産的なポストモーテムの議論には、チームが所有するシステムの部分について深い知識を持つエンジニアが含まれます。インシデントに対応したエンジニアが新しいチームメンバーである場合は、同じチームのより経験豊富なエンジニアにポストモーテムミーティングへ参加してもらうと効果的です。
+    - 影響を受けたシステムのエンジニアリングマネージャー。
+        - インシデントに対応したチームを担当するマネージャーは、スタッフ配置と技術投資の決定に情報を提供するためにポストモーテムミーティングに参加します。
+    - 影響を受けたシステムのプロダクトマネージャー。
+        - プロダクトマネージャーは、インシデントが顧客体験に与える影響を理解するためにポストモーテムミーティングに参加します。ポストモーテムのアクションアイテムを優先し完了するためには、提案されたフォローアップタスクの重要性と範囲についてのこの議論にプロダクトマネージャーを関与させることが重要です。
+- 任意参加（Sev-1インシデントのみ）
+    - [カスタマーリエゾン](https://response.pagetduty.co.jp/training/customer_liaison/)。
+        - カスタマーリエゾンはインシデントに対する顧客の反応について話すことができます。彼らは外部メッセージを最終化して送信できるように、アクションアイテムに関するチームの決定を理解する必要があります。
+
+## ファシリテーション
+### ファシリテーションとは
+ポストモーテムミーティングにおけるファシリテーターの役割は、他の参加者とは異なります。ファシリテーターはミーティングで自分のアイデアを表明せず、代わりにグループが発言し、議論を軌道に乗せるよう促します。ポストモーテム担当者、インシデントコマンダー、またはインシデント中に積極的な役割を果たした他のミーティング参加者は、議論に貢献する必要があり、ファシリテーションの責任も負うべきではありません。
+
+ファシリテーターが行うこと：
+
+- 人々が発言するよう促し、全員の声に耳が傾けられるようにします。
+- 洞察を明確にし、チームに質問を投げかけます。
+- チームが異なる視点と異なる選択肢に目を向けられるよう促します。
+- 全員が時間通りに議論を進め、軌道に乗るようにします。話の脱線を防ぎ、特定の人々がミーティング全体を支配するのを止めます。
+- できるだけ少なく話します。議論を導くことを念頭におきながら、ミーティングを乗っ取らないように注意してください。
+
+ファシリテーターが行わないこと：
+
+- 決定を下すこと。
+- 誰かの肩を持つこと。ファシリテーターが特定の側につくと、チームメンバーは攻撃されていると感じ、ミーティングへの貢献をやめるかもしれません。
+    - 人々が言うことにコメントするのは、たとえそれが肯定的なフィードバックを与える意図だったとしても避けましょう。話者自身は肯定感を感じるかもしれませんが、他の人からすると自分がこれから言おうとすることについて悪く感じたり、貢献することを思いとどまったりすることにつながるかもしれません。
+
+### 誰がファシリテートすべきか
+優れたファシリテーターは通常、高度な感情的知性を持ち、人々がどのように感じているかを理解するために非言語的な手がかりを容易に読み取ることができます。彼らはこの感覚を使って、誰もが話しやすい環境を育みます。アジャイルコーチやプロジェクトマネージャーはしばしば熟練したファシリテーターです。PagerDutyでは、ファシリテーションの学習に興味のある個人をコーチする自信のあるファシリテーターのギルドがあります。組織内でポストモーテムミーティングのファシリテートを手伝う個人を探す際には、これらのコアコンピテンシーを持つ人を探してください：
+
+- 部屋の中で人々がどのように感じているかを見定め、非言語的な手がかりを読み取って言いたいことがある人を見つけることができる。
+- 自分自身と他の人のため、発言内容が明確になるように言い換えることができる。
+- より深い思考を刺激するために、オープンな質問をすることができる。
+- 議論が脱線したとき、または誰かが議論を支配するときに中断することに慣れている。
+- 会話が目標に向かっていくように方向転換することができる。
+- 時間を追跡し、時間の通知を与えることができる。
+- 議論を導き、意思決定とアクションアイテムへ繋げることができる。
+
+ポストモーテムミーティングのファシリテーターは、影響を受けたシステムの専門家である必要はありません。ファシリテーターは議論の内容に精通している必要はありません。ファシリテーターは議論に自分の意見を貢献するのではなく、他の人が話すよう促すことを忘れないでください。インシデント対応に関わったミーティング参加者がインシデントの専門家であり、ファシリテーターはそれらの専門家がグループと情報を共有するよう促す質問をします。
+
+しかし、ファシリテーターはポストモーテムプロセスとポストモーテムミーティングの目標に精通しているべきで、それによりグループ議論をそれらの目標達成に導くことができます。ポストモーテムミーティングのファシリテーターは、[非難のないこと（ブレームレス）](culture/blameless.md)についてしっかりした理解を持っている必要があり、グループがミーティングで非難の言葉を避けられるようにします。
+
+## ファシリテーションのヒント
+ポストモーテムミーティングのファシリテーターは、チームが分析をより深く掘り下げ、[非難を避け](culture/blameless.md)ながら、アクションアイテムへの賛同を得られるようにします。ポストモーテムミーティングの一般的な課題は、文書化されたポストモーテムに過度に焦点を当てることと、システム障害の責任を個人に帰する傾向に屈することです。以下は、効果的なポストモーテムミーティングを実施する方法と、発生した場合の厄介な状況の対処方法に関するヒントです。
+
+**準備事項**
+
+- ミーティングの冒頭でルールを設定します。
+    - 全員が発言すべきだが、誰も会話を独占すべきではないという期待値を設定します。
+    - ブレームレスなポストモーテムを実践していることを、改めてグループに認識してもらいます。
+- 会話が脱線した場合のセーフワードを確立します。
+    - チームメンバーが会話がトピックから外れていることに気づいた場合、セーフワードを言って、チームに議論の有用性を再評価させることができます。PagerDutyでは、一部のチームは「ELMO」という頭字語を使用しています。これは「Enough, let's move on（十分です、次に進みましょう）」を意味します。これにより、議論がトピックから外れたときに中断するプレッシャーをファシリテーターだけが負う必要がなくなります。
+- アジェンダを共有して、チームが何がトピックに含まれ、何が含まれないかを明確にします。
+- タイマーを使用して時間を制限します。
+    - 各アジェンダ項目の時間を制限できます。タイマーを表示することで、全員が時間制限を認識し、ファシリテーターが時間のために中断する必要性が減ります。
+- ポストモーテムドキュメントをあなたのラップトップからTVに表示して、全員が見られるようにします。
+
+[**非難を避ける方法：**](culture/blameless.md)
+
+- ミーティングの開始時、および/またはミーティング中に非難が発生した場合に、ブレームレスなポストモーテムを実践することに同意していること、そして非難が発生した場合にお互いに指摘することをチームに思い出してもらいます。
+- 分析の可能性を狭め、非難を暗示するような「誰が」または「なぜ」という質問は避けるよう注意してください。代わりに「何を」や「どのように」という質問をします：
+    - 「何が起きていると思いましたか？」
+    - 「次に何をしましたか？」
+    - 「その行動はその時点でどのように理にかなっていましたか？」
+- 人間の行動について尋ねるとき、特定されていない対応者に抽象化します。誰でも同じミスを犯す可能性があることをチームに思い出させます。
+    - 「どのような要因によって対応者がその行動を取る可能性が生じましたか？」
+
+**会話がトピックから外れている場合の対処法：**
+
+- ファシリテーターの仕事はチームを軌道に乗せておくことであり、トピックを続けることが価値があるか、またはオフラインで取り上げることができるかを尋ねることで、ミーティングの目標をチームに思い出してもらい、不適切なトピックを中断する必要があります。
+    - 「申し訳ありませんが、このトピックはこのミーティングの目標と関係ないようです。元のトピックに戻りますか、それともこの議論を続けますか？」
+- アジェンダ項目の時間を制限します。時間が終わったら、さらに数分間話し続けるかどうかの投票を行います。
+
+**一人がミーティングを支配している場合の対処法：**
+
+- 全員の参加が重要であることを最初に言います。ファシリテーターの責任を説明して、話すのをやめるように頼まれたり、発言するように頼まれたりしても気分を害さないようにします。ミーティング全体を通して、人々がどれだけ話しているかに注意を払います。
+- 「最初の人が言っていたことが聞こえませんでした。」
+- 仲介者として行動し、人々が中断されているときに指摘します：「その考えをいったん保留してください – Shariが話を終える機会を確保したいと思います」
+
+**チームメンバーが何も言っていない場合、どのように貢献させるか：**
+
+- 「部屋を一周してみなさん全員から意見を聞きましょう」
+- 「これまでで目立ったことは何ですか？」
+- 「他に考慮すべきことは何がありますか？」
+
+**分析を刺激する方法：**
+
+- オープンな質問をします。「はい」または「いいえ」で答えられる質問はしません。
+- [分析の質問](resources/analysis.md)を参照してください。もしかするとチームでは既に、文書化されたポストモーテムを準備する際にこれらの質問を自問しているかもしれません。ミーティングで改めてこのうちのいくつかの項目を尋ねることで、協調的で新しい思考を促しましょう。
diff --git a/docs/next_steps.md b/docs/next_steps.md
index 9762d00..5d8598c 100644
--- a/docs/next_steps.md
+++ b/docs/next_steps.md
@@ -1,63 +1,63 @@
 ---
 cover:
-description: Now that you have learned how to create a postmortem, let's take a look at how to create one in the PagerDuty application.
+description: ポストモーテムの作成方法を学んだところで、PagerDutyアプリケーションでポストモーテムを作成する方法を見てみましょう。
 ---
 ![Next Steps](assets/img/headers/Postmortems-NextSteps.png)
-## Create a Report in PagerDuty
+## PagerDutyでレポートを作成する
 
-If you are using PagerDuty for incident management, we strongly encourage you to take advantage of our postmortems feature. This allows you to associate incidents and other data within PagerDuty with your report, which will help with timeline generation and allow you to write a more comprehensive report. Note that only non-stakeholders can create, modify, and/or delete postmortems. (For a matrix of user permissions, please see our [support page](https://support.pagerduty.com/docs/user-roles) and refer to the postmortems line items.)
-### Create the Report
+インシデント管理にPagerDutyを使用している場合は、ポストモーテム機能を活用することを強くお勧めします。これにより、PagerDuty内のインシデントやその他のデータをレポートに関連付けることができ、タイムラインの生成に役立ち、より包括的なレポートを作成することができます。Stakeholder以外のロールの方のみがポストモーテムの作成、変更、および/または削除を行えることに注意してください。（ユーザー権限のマトリックスについては、[サポートページ](https://support.pagerduty.com/main/lang-ja/docs/user-roles)を参照し、ポストモーテム（Postmortem）の項目を確認してください。）
+### レポートを作成する
 
-To create a postmortem from an incident, you can select the (resolved) incident and click the New Postmortem Report button:
+インシデントからポストモーテムを作成するには、（解決済みの）インシデントを選択し、「New Postmortem Report」ボタンをクリックします：
 
 ![Create a New Report Option 1](assets/img/thumbnails/NextSteps/1NewPostmortemReport.png)
 
-Alternatively, you can create a postmortem from the catalog, by either going to Incidents -> Postmortems or directly to `yoursubdomain.pagerduty.com/postmortems`. From there, you click New Report:
+または、カタログからポストモーテムを作成することもできます。「Incidents」→「Postmortems」に移動するか、直接`yoursubdomain.pagerduty.com/postmortems`にアクセスします。そこから「New Report」をクリックします：
 
 ![Create a New Report Option 2](assets/img/thumbnails/NextSteps/2NewPostmortemReport.png)
 
-If you're creating a postmortem report from the catalog, you'll need to associate the incident after you start the report. If you include the estimated start and/or end times, the PagerDuty app will limit the possible incidents associated with that report to incidents that happened in that timeframe.
+カタログからポストモーテムレポートを作成する場合は、レポートを開始した後にインシデントを関連付ける必要があります。推定開始時間や終了時間を含めると、PagerDutyアプリはその時間枠内に発生したインシデントに関連するレポートに対象範囲を制限します。
 
 ![Data Sources](assets/img/thumbnails/NextSteps/3PostmortemDataSources.png)
 
 
-Regardless of whether you created a report from an incident or the catalog, you can add additional incidents using the timeframe or incident number for situations where multiple incidents apply to a single report.
+インシデントからレポートを作成したか、カタログから作成したかに関わらず、複数のインシデントが単一のレポートに適用される状況では、時間枠またはインシデント番号を使用して追加のインシデントを追加できます。
 
-The PagerDuty app will create a timeline to appear in the postmortem based on the in-app events:
+PagerDutyアプリは、アプリ内のイベントに基づいてポストモーテムに表示されるタイムラインを作成します：
 
 ![Create Timeline](assets/img/thumbnails/NextSteps/4CreateTimeline.png)
 
-If you have integrated with Slack or another data source, that information will also appear in the Available Data on the left. You can choose which items to add or remove using the arrows in the center.
+Slackやその他のデータソースと統合している場合、その情報も左側の「Available Data（利用可能なデータ）」に表示されます。中央の矢印を使用して、どの項目を追加または削除するかを選択できます。
 
-After you've completed the timeline, you will need to write in the Analysis. This section has several subsections. Some of the default subsections are Overview, What Happened, and Resolution:
+タイムラインを完了した後、分析を記入する必要があります。このセクションにはいくつかのサブセクションがあります。デフォルトのサブセクションには「Overview（概要）」、「What happened（何が起こったか）」、「Resolution（解決）」などがあります：
 
 ![Postmortem Details](assets/img/thumbnails/NextSteps/5PostmortemDetail.png)
 
-Once you have the information you would like in the report, click Save & View Report. This will save the report in the Draft state (the report will also autosave in the Draft state). The states available for the postmortem report are: Draft, In Review, Reviewed, and Closed. You can edit the status by clicking on the report from the Postmortem Catalog and using the Status drop down menu, which is located at the top of the page:
+レポートに含めたい情報が揃ったら、「Save & View Report」をクリックします。これによりレポートが「Draft（下書き）」状態で保存されます（レポートは「Draft」状態で自動保存されます）。ポストモーテムレポートで利用可能な状態は：Draft（下書き）、In Review（レビュー中）、Reviewed（レビュー済み）、Closed（クローズ）です。ポストモーテムカタログからレポートをクリックし、ページ上部にあるステータスドロップダウンメニューを使用して、ステータスを編集できます：
 
 ![Change Postmortem Status](assets/img/thumbnails/NextSteps/6ChangePostmortemStatus.png)
 
-## Addenda
-### External Access
-You can export your postmortem report to a PDF at any stage. This is primarily used if there are reviewers not in the PagerDuty app or if there is a different, centralized tool for the company for others to view the final report. To save as a PDF, simply select the report from the Postmortem Catalog and click the Save as PDF button:
+## 補足
+### 外部アクセス
+ポストモーテムレポートはどの段階でもPDFにエクスポートできます。これは主に、PagerDutyアプリにいないレビュアーがいる場合や、他の人が最終レポートを閲覧するための会社の一元化されたツールがある場合に使用されます。PDFとして保存するには、ポストモーテムカタログからレポートを選択し、「Save as PDF」ボタンをクリックするだけです：
 
 ![Export Postmortem to PDF](assets/img/thumbnails/NextSteps/7ExportPostmortemPDF.png)
 
-### Customizations
-We strongly recommend that you modify the default report template to fit your company's needs. This can involve adding or removing sections, changing wording to match common language, or modifying the clarifying text in each section so that it communicates what is needed.
+### カスタマイズ
+デフォルトのレポートテンプレートを会社のニーズに合わせて変更することを強くお勧めします。これには、セクションの追加や削除、共通言語に合わせた文言の変更、または各セクションの説明テキストを必要なことを伝えるように変更することが含まれます。
 
-If you would like to add, edit, or remove sections you can do so under Settings in the Postmortem Catalog:
+セクションを追加、編集、または削除したい場合は、ポストモーテムカタログの設定で行うことができます：
 
 ![Edit the Postmortem Template](assets/img/thumbnails/NextSteps/8EditPostmortemTemplate.png)
 
-You can Edit sections by clicking on the gear for the appropriate section. You can also click Add Section at the bottom of the template to add a completely new section:
+適切なセクションのギアをクリックしてセクションを編集できます。また、テンプレートの下部にある「Add Section」をクリックして、まったく新しいセクションを追加することもできます：
 
 ![Edit Postmortem Section Text Areas](assets/img/thumbnails/NextSteps/9EditPostmortemSections.png)
 
-Changes will only apply to postmortem reports moving forward—they will not apply to reports that have already been created.
-For some guidance for what questions and clarifying information to put on your questions, take a look at the [Analysis Questions section](https://postmortems.pagerduty.com/resources/analysis/) under the Resources for this guide.
+変更は今後のポストモーテムレポートにのみ適用されます。既に作成されたレポートには適用されません。
+質問や説明情報をどのように設定するかのガイダンスについては、このガイドの[分析の質問](https://postmortems.pagerduty.co.jp/resources/analysis/)セクションを参照してください。
 
-If at any point you'd like to start again from the default template, you can reset the template. To revert to the original default sections, click on the Reset Template button at the top of your Report Template. You will be prompted in a pop-up menu to Reset Template or Cancel.
+いつでもデフォルトのテンプレートから再開したい場合は、テンプレートをリセットできます。元のデフォルトセクションに戻すには、レポートテンプレートの上部にある「Reset Template」ボタンをクリックします。ポップアップメニューでテンプレートをリセットするか、キャンセルするかの選択が促されます。
 
-### Navigating Between Reports and Associated Incidents
-Currently, the only way to see an incident associated with a report is to open the report and look at the incidents that have been added to it. You cannot currently view a report by navigating to an incident to see an associated report.
+### レポートと関連インシデント間のナビゲーション
+現在、レポートに関連付けられたインシデントを確認する唯一の方法は、レポートを開いて追加されたインシデントを確認することです。現在、インシデントに移動して関連するレポートを表示することはできません。
diff --git a/docs/resources/analysis.md b/docs/resources/analysis.md
index 21aa59d..8e1ecd7 100644
--- a/docs/resources/analysis.md
+++ b/docs/resources/analysis.md
@@ -1,80 +1,80 @@
 ---
 cover:
-description: Questions to ask to stimulate deep postmortem analysis.
+description: ポストモーテム分析を深めるための質問事項。
 ---
 ![Analysis](../assets/img/headers/Postmortems-Questions.png)
 
-Inspired by Gary Klein’s debriefing questions in Sidney Dekker’s *The Field Guide To Understanding Human Error*, below is a non-exhaustive list to help stimulate deep analysis. Ask “how” and “what” questions, rather than “who” or “why,” to discourage blame and encourage learning.  
+Sidney Dekkerの著書『The Field Guide To Understanding Human Error』に掲載されているGary Kleinのデブリーフィング質問を参考に作成された、深い分析を促すための質問リスト（網羅的ではありません）を紹介します。「誰が」や「なぜ」ではなく、「どのように」「何が」という質問を使うことで、非難を避け、学習を促進します。
 
-[Download as a PDF](../assets/pdf/PostmortemAnalysisQuestions.pdf).
+[PDFとしてダウンロード](../assets/pdf/PostmortemAnalysisQuestions.pdf)。
 
 <table>
     <tr>
-        <td>Cues</td>
+        <td>手がかり</td>
         <td>
             <ul>
-                <li>What were you focusing on?</li>
-                <li>What was not noticed?</li>
-                <li>What differed from what was expected?</li>
+                <li>何に注目していましたか？</li>
+                <li>何が見落とされていましたか？</li>
+                <li>予想と異なっていたのは何でしたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Previous Knowledge/Experience</td>
+        <td>過去の知識/経験</td>
         <td>
             <ul>
-                <li>Was this an anticipated class of problem or did it uncover a class of issue that was not architecturally anticipated?</li>
-                <li>What expectations did participants have about how things were going to develop?</li>
-                <li>Were there similar incidents in the past?</li>
+                <li>これは予想された問題の種類でしたか、それともアーキテクチャ上予想されていなかった問題の種類を明らかにしましたか？</li>
+                <li>参加者は事態の進展についてどのような想定を持っていましたか？</li>
+                <li>過去に類似したインシデントはありましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Goals</td>
+        <td>目標</td>
         <td>
             <ul>
-                <li>What goals governed your actions at the time?</li>
-                <li>How did time pressure or other limitations influence choices?</li>
-                <li>Was there work the team chose not to do in the past that could have prevented or mitigated this incident?</li>
+                <li>当時のあなたの行動を支配していた目標は何でしたか？</li>
+                <li>時間的制約やその他の制限が、あなたの選択にどのような影響を与えましたか？</li>
+                <li>過去にチームが行わないと決定した作業で、このインシデントを防止または軽減できたものはありましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Assessment</td>
+        <td>評価</td>
         <td>
             <ul>
-                <li>What mistakes (for example, in interpretation) were likely?</li>
-                <li>How did you view the health of the services involved prior to the incident?</li>
-                <li>Did this incident teach you something that should change views about this service’s health?</li>
+                <li>どのようなミス（例えば、解釈における）が起こりやすかったですか？</li>
+                <li>インシデント発生前に、関連するサービスの健全性をどのように見ていましたか？</li>
+                <li>このインシデントから、サービスの健全性に関する見方を変えるべき何かが学べましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Taking Action</td>
+        <td>行動</td>
         <td>
             <ul>
-                <li>How did you judge you could influence the course of events?</li>
-                <li>What options were taken to influence the course of events? How did you determine that these were the best options at the time?</li>
-                <li>How did other influences (operational or organizational) help determine how you interpreted the situation and how you acted?</li>
+                <li>事態の流れに対し、どのように影響を与えられると判断しましたか？</li>
+                <li>事態の流れに影響を与える上でどのような選択肢を取りましたか？これらが当時の最善の選択肢であると、どのように判断しましたか？</li>
+                <li>他の影響（運用上または組織上）が、状況の解釈や行動の決定にどのように役立ちましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Help</td>
+        <td>支援</td>
         <td>
             <ul>
-                <li>Did you ask anyone for help?</li>
-                <li>What signal brought you to ask for support?</li>
-                <li>Were you able to contact the people you needed to contact?</li>
+                <li>誰かに助けを求めましたか？</li>
+                <li>どのようなシグナルを起点に、あなたはサポートを求めましたか？</li>
+                <li>連絡する必要のある人々に連絡を取ることはできましたか？</li>
             </ul>
         </td>
     </tr>
     <tr>
-        <td>Process</td>
+        <td>プロセス</td>
         <td>
             <ul>
-                <li>Did the way that people collaborate, communicate, and/or review work contribute to the incident?</li>
-                <li>What worked well in your incident response process and what did not work well?</li>
+                <li>人々が協力し、コミュニケーションを取り、作業をレビューする方法がインシデントに寄与しましたか？</li>
+                <li>インシデント対応プロセスで上手くいったことと上手くいかなかったことは何ですか？</li>
             </ul>
         </td>
     </tr>
diff --git a/docs/resources/checklist.md b/docs/resources/checklist.md
index a20bb35..1bd7b48 100644
--- a/docs/resources/checklist.md
+++ b/docs/resources/checklist.md
@@ -1,14 +1,13 @@
 ---
 cover:
-description: A checklist for performing a postmortem.
+description: ポストモーテム実施にあたってのチェックリストです。
 ---
 ![Postmortems Checklist](../assets/img/headers/Postmortems-Checklist.png)
 
+ポストモーテムが必要なインシデント（Sev-1またはSev-2インシデント）毎に、ポストモーテム実施の各ステップのサブタスクを持つチケットテンプレートをクローンします。これにより、ポストモーテム作成におけるチームの共同作業を支援し、ポストモーテムミーティングまでの進捗を可視化します。
 
-For each incident that requires a postmortem (Sev-1 or Sev-2 incidents), we clone a ticket template that has subtasks for each step of performing a postmortem. This helps a team collaborate on creating the postmortem and provides visibility on progress leading up to the postmortem meeting.
+以下は、ポストモーテムを実行するために必要なステップです。
 
-Below are the steps involved in performing a postmortem at a high level.
-
-[Download as a PDF](../assets/pdf/PostmortemChecklist.pdf).
+[PDFとしてダウンロード](../assets/pdf/PostmortemChecklist.pdf).
 
 ![Checklist](../assets/img/thumbnails/PostmortemChecklist.png)
diff --git a/docs/resources/examples.md b/docs/resources/examples.md
index 132cfe4..aac8d8d 100644
--- a/docs/resources/examples.md
+++ b/docs/resources/examples.md
@@ -1,11 +1,10 @@
 ---
 cover:
-description: Examples of postmortems.
+description: ポストモーテムの参考例です。
 ---
 ![Postmortem Examples](../assets/img/headers/Postmortems-Examples.png)
 
-
-Here are some examples of postmortems from other companies as a reference,
+以下は、他社で実施されているポストモーテムの参考例です：
 
 * [Stripe](https://support.stripe.com/questions/outage-postmortem-2015-10-08-utc)
 * [LastPass](https://blog.lastpass.com/2015/06/lastpass-security-notice.html/comment-page-2/)
diff --git a/docs/resources/post_mortem_template.md b/docs/resources/post_mortem_template.md
index 1699e92..6d7467a 100644
--- a/docs/resources/post_mortem_template.md
+++ b/docs/resources/post_mortem_template.md
@@ -1,13 +1,13 @@
 ---
 cover:
-description: This is a standard template we use for postmortems at PagerDuty. Each section describes the type of information you will want to put in that section.
+description: PagerDutyのポストモーテムで利用されている標準テンプレートです。各セクションにどのような情報を入力するかが説明されています。
 ---
 ![Postmortem Template](../assets/img/headers/Postmortems-Template.png)
 
 
-This is a standard template we use for postmortems at PagerDuty. Each section describes the type of information you will want to put in that section.
+PagerDutyのポストモーテムで利用されている標準テンプレートです。各セクションにどのような情報を入力するかが説明されています。
 
-[Download](../assets/pdf/PostmortemTemplate.pdf) as a PDF to start using with your team.
+PDFとして[ダウンロード](../assets/pdf/PostmortemTemplate.pdf)し、チームで使ってみましょう。
 
 ---
 ![Template](../assets/img/thumbnails/PostmortemTemplate_preview.png)
diff --git a/docs/resources/reading.md b/docs/resources/reading.md
index b370347..e912662 100644
--- a/docs/resources/reading.md
+++ b/docs/resources/reading.md
@@ -1,28 +1,29 @@
 ---
 cover:
-description: This is a collection of additional reading on the topic of incident response that we've found useful.
+description: インシデント対応のトピックスにおいて参考となる追加の読み物一覧です。
+
 ---
 ![Futher Reading and Resources](../assets/img/headers/Postmortems-Resources.png)
 
-## Creating a Blameless Culture
-### Books
+## ブレームレスな文化の醸成
+### 書籍
 * [The Field Guide to Understanding Human Error](https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265) (Sidney Dekker)
 * [Crucial Accountability](https://www.amazon.com/Crucial-Accountability-Resolving-Expectations-Commitments/dp/0071829318) (Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler, David Maxfield)
 
-### Articles
+### 記事
 * [Blame. Language. Sharing.](http://fractio.nl/2015/10/30/blame-language-sharing/) (Lindsay Holmwood)
 
-### Talks
+### 講演
 * "[Three analytical traps in accident investigation](https://www.youtube.com/watch?v=TqaFT-0cY7U)" (Johan Bergstrom)
 * "[Two views on Human Error](https://www.youtube.com/watch?v=rHeukoWWtQ8)" (Johan Bergstrom)
 * [Advanced PostMortem Fu and Human Error 101 (Velocity 2011)](http://www.slideshare.net/jallspaw/advanced-postmortem-fu-and-human-error-101-velocity-2011) (John Allspaw)
 
-## How to Analyze Incidents
-### Articles
+## インシデントの分析方法
+### 記事
 * [The Infinite Hows](https://www.oreilly.com/ideas/the-infinite-hows) (John Allspaw)
 
-### Documents
+### 文書
 * [Postmortem Action Items: Plan the Work and Work the Plan](https://www.usenix.org/system/files/login/articles/login_spring17_09_lunney.pdf) (John Lunney, Sue Lueder, and Betsy Beyer)
 
-## Process and Mechanics of Postmortems and Retrospectives
+## ポストモーテムの振り返りのプロセスと仕組み
 * [The Agile Retrospective Wiki](http://retrospectivewiki.org/index.php?title=Agile_Retrospective_Resource_Wiki)
diff --git a/docs/what_is.md b/docs/what_is.md
index e6eed42..a6faa62 100644
--- a/docs/what_is.md
+++ b/docs/what_is.md
@@ -1,42 +1,42 @@
 ---
 cover:
-description: The basics of Postmortems. Why postmortems are important, when they should be done, and who is responsible for the postmortem.
+description: ポストモーテムの基本。ポストモーテムが重要な理由、いつ実施すべきか、そして誰がポストモーテムの責任者かについて。
 ---
 ![What is a Postmortem?](assets/img/headers/Postmortems-WhatIs.png)
 
-> What went wrong and how do we learn from it?
+> 何が間違っていたのか、そしてそこから何を学ぶのか？
 
-A postmortem (or post-mortem) is a process intended to help you learn from past incidents. It typically involves a blame-free analysis and discussion soon after an event has taken place. An artifact is produced that includes a detailed description of exactly what went wrong in order to cause the incident, along with a list of steps to take in order to prevent a similar incident from occurring again in the future. An analysis of how effective your incident response process itself was during the incident should also be included in the discussion. The value of postmortems comes from helping institutionalize a culture of continuous improvement.
+ポストモーテム（または post-mortem）は、過去のインシデントから学ぶことを目的としたプロセスです。通常、インシデント発生後すぐに非難のない分析とディスカッションを行います。インシデントの原因となった具体的な問題点の詳細な説明と、将来同様のインシデントが発生するのを防ぐための手順リストを含む成果物が作成されます。インシデント対応プロセス自体がインシデント中にどれだけ効果的だったかの分析も議論に含めるべきです。ポストモーテムの価値は、継続的改善の文化を制度化するのに役立つことにあります。
 
-Organizations may refer to the postmortem process in slightly different terms:
+組織によっては、ポストモーテムプロセスを少し異なる用語で呼ぶことがあります：
 
-- Learning Review
-- After-Action Review
-- Incident Review
-- Incident Report
-- Post-Incident Review
-- Root Cause Analysis (or RCA)
+- ラーニングレビュー
+- アフターアクションレビュー
+- インシデントレビュー
+- インシデントレポート
+- ポストインシデントレビュー
+- 根本原因分析（RCA）
 
-## Why Do Postmortems
-During incident response, the team is 100% focused on restoring service. They cannot (and should not) be wasting time and mental energy thinking about how to do something optimally or performing a deep dive on what caused the incident. That's why postmortems are essential—they provide an opportunity to reflect once the issue is no longer impacting users. **The postmortem process drives focus, instills a culture of learning, and identifies opportunities for improvement that otherwise would be lost.**
+## なぜポストモーテムを行うのか
+インシデント対応中、チームは100％サービスの復旧に集中しています。最適な方法を考えたり、インシデントの原因を深く掘り下げたりするために時間と精神的エネルギーを無駄にすることはできません（そうすべきでもありません）。そのためポストモーテムは不可欠で、ユーザーに影響する問題が解消された後に振り返りの機会を提供します。**ポストモーテムプロセスは焦点を絞り、学習の文化を醸成し、そうでなければ失われてしまう改善の機会を特定します。**
 
-Without a postmortem, you fail to recognize what you're doing right, where you could improve, and, most importantly, how to avoid making the same mistakes in the future. Conducting an effective postmortem allows you to learn quickly from your mistakes and improve your systems and processes. A well-designed, blameless postmortem allows teams to continuously learn, serving as a way to iteratively improve your infrastructure and incident response process. Be sure to write detailed and accurate postmortems in order to get the most benefit out of them.
+ポストモーテムを行わなければ、何がうまくいっているのか、どこを改善できるのか、そして最も重要なことに、将来同じ誤りを避ける方法を認識できません。効果的なポストモーテムを実施すれば、ミスから迅速に学び、システムとプロセスを改善することができます。適切に設計されたブレームレス（非難のない）なポストモーテムは、チームが継続的に学習し、インフラストラクチャとインシデント対応プロセスを段階的に改善する方法として機能します。ポストモーテムから最大限の利益を得るためには、詳細で正確なポストモーテムを作成するようにしましょう。
 
-## When to Do a Postmortem
-**Do a postmortem for every major incident** (Sev-2/1). This includes **any time incident response is triggered**—even if it is later discovered that severity was actually lower, it was a false alarm, or it quickly recovered without intervention. A postmortem should not be neglected in these cases because it is still an opportunity to review what did and did not work well in the incident response process. If the incident should not have triggered incident response, it is worthwhile understanding why it did so monitoring can be tuned to avoid unnecessarily triggering incident response in the future. Doing this analysis and follow-up action will help prevent alert fatigue going forward.
+## いつポストモーテムを行うべきか
+**すべての重大なインシデント（Sev-2/1）に対してポストモーテムを実施してください**。これには**インシデント対応が発動されたすべての場合**が含まれます。後に重大度が実際には低かったことが判明した場合や、誤報だった場合、または介入なしで迅速に回復した場合であっても実施します。これらのケースでもポストモーテムを怠るべきではありません。なぜなら、インシデント対応プロセスで何がうまくいき、何がうまくいかなかったかを確認する機会だからです。インシデントがインシデント対応を発動すべきでなかった場合、なぜ発動されたのかを理解し、将来、不必要にインシデント対応を発動しないようにモニタリングを調整することが価値があります。この分析とフォローアップアクションを行うことで、今後のアラート疲れを防ぐのに役立ちます。
 
-Postmortems are done shortly after the incident is resolved, while the context is still fresh for all responders. Just as resolving a major incident becomes top priority when it occurs, completing the postmortem is prioritized over planned work. Completing the postmortem is the final step of your incident response process. Delaying the postmortem delays key learning that will prevent the incident from recurring.
+ポストモーテムはインシデントが解決された直後、すべての対応者にとってコンテキストの記憶が鮮明なうちに行われます。重大なインシデントが発生した時にその解決が最優先事項になるのと同様に、ポストモーテムの完了は計画された作業よりも優先されます。ポストモーテムの完了はインシデント対応プロセスの最終ステップです。ポストモーテムを遅らせると、インシデントの再発を防ぐための重要な学習が遅れます。
 
-**PagerDuty's internal policy for completing postmortems is 3 calendar days for a Sev-1 and 5 business days for a Sev-2.** Because scheduling a time when everyone is available can be difficult, the expectation is people will adjust their calendars to attend the postmortem meeting within this timeframe.
+**PagerDutyの社内ポリシーでは、Sev-1の場合は3暦日以内、Sev-2の場合は5営業日以内にポストモーテムを完了することになっています。** 全員が参加できる時間を調整するのが難しい場合があるため、この期間内にポストモーテムミーティングに参加できるよう予定を調整することが期待されています。
 
-## Who Is Responsible for the Postmortem
-At the end of a major incident call, or very shortly after, the [Incident Commander](https://response.pagerduty.com/training/incident_commander/) selects and directly notifies one responder to own the postmortem. Note that the postmortem owner is not solely responsible for completing the postmortem themselves. **Writing a postmortem is a collaborative effort** and should include everyone involved in the incident response. While engineering will lead the analysis, the postmortem process should involve management, customer support, and business communications teams. The postmortem owner coordinates with everyone who needs to be involved to ensure it is completed in a timely manner.
+## 誰がポストモーテムの責任者か
+重大なインシデントコールの終了時、またはその直後に、[インシデントコマンダー](https://response.pagerduty.co.jp/training/incident_commander/)は一人の対応者を選び、ポストモーテムを担当するよう直接通知します。ポストモーテムの担当者が単独でポストモーテムを完了する責任を負うわけではないことに注意してください。**ポストモーテムの作成は共同作業であり**、インシデント対応に関わった全員を含めるべきです。エンジニアリングが分析をリードする一方で、ポストモーテムプロセスには経営陣、カスタマーサポート、ビジネスコミュニケーションチームも関与します。ポストモーテムの担当者は、タイムリーに完了するために関与する必要のあるすべての人と調整します。
 
-It is important to designate a single owner to avoid the bystander effect. If you ask all responders or a team to do the postmortem, you risk everyone assuming someone else is doing it, and therefore, no one does. When selecting an owner you may choose a single individual who meets any of the following criteria:
+傍観者効果を避けるために、単一の担当者を指定することが重要です。すべての対応者やチームにポストモーテムを依頼すると、誰もが他の誰かがやっていると思い込み、結果的に誰もやらないリスクがあります。担当者を選ぶ際には、以下の基準のいずれかを満たす個人を選ぶことができます：
 
-- Took a leadership role investigating during the incident
-- Performed a task that led to stabilizing the service
-- Was the primary on-call responder for the most heavily affected service
-- Manually triggered the incident to initiate incident response
+- インシデント中の調査でリーダーシップの役割を担った
+- サービスの安定化につながるタスクを実行した
+- 最も影響を受けたサービスのオンコール対応者だった
+- インシデント対応を開始するためにインシデントを手動で発動した
 
-Doing the postmortem is not a punishment, and the owner is not the person that "caused" the incident. Effective postmortems are blameless. In complex systems there is never a single cause, but a combination of factors that lead to failure. The owner is simply an accountable individual who performs select administrative tasks, follows up for information, and drives the postmortem to completion. Writing the postmortem will ultimately be a collaborative effort, but selecting a single owner to orchestrate this collaboration helps ensure it is done.
+ポストモーテムの実施は罰ではなく、担当者はインシデントを「引き起こした」人ではありません。効果的なポストモーテムは非難のない、ブレームレスなものです。複雑なシステムでは、単一の原因はなく、失敗につながる要因の組み合わせがあります。担当者は単に、特定の管理タスクを実行し、情報を追跡し、ポストモーテムを完了に導く責任のある個人です。ポストモーテムの作成は最終的には共同作業になりますが、この共同作業を調整する単一の担当者を選ぶことで、確実に実施されるようになります。
diff --git a/mkdocs.yml b/mkdocs.yml
index b037a74..63e2d17 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -2,10 +2,10 @@
 site_name: PagerDuty Postmortem Documentation
 site_description: A collection of information about the PagerDuty postmortem process and industry best practices. This guide will teach you how to build a culture of continuous learning, the most important components to include in your analysis, and how to conduct effective postmortem meetings.
 site_author: PagerDuty, Inc.
-site_url: https://postmortems.pagerduty.com/
+site_url: https://www.pagerduty.co.jp/ops-guides/postmortems/
 
 # Repository
-repo_url: https://github.com/pagerduty/postmortem-docs
+repo_url: https://github.com/pagerduty/postmortem-docs-ja
 
 # Copyright
 copyright: 'Copyright &copy; PagerDuty, Inc.'