dantotsu

Dantotsu — 不具合分析

単一の不具合を、恒久的な品質改善につなげるための体系的な手法です。元トヨタのエンジニアである野村貞夫氏が考案し、製造不良を最大98％削減するために活用しました。ソフトウェア向けに応用したところ、この手法を全面的に採用した小規模プロジェクトでは、航空宇宙産業レベルのプロセスに伴う膨大な事前仕様策定の負担なしに、コード1,000行あたり約0.3件の不具合を達成しました。これは業界平均を1〜2桁下回る数値です。

不具合 ＝ ユーザーにとって予期しない動作のことです。実際に発生した動作と、期待されていた動作との隔たりを指します。

製造業で用いられていた元の手法から受け継いだ、特定のテンプレートよりも重要な原則が2つあります。

• 不具合の重大度ではなく、どの段階で流出したかによって分類します。 重大度によるトリアージは「何を最初に修正するか」を最適化します。一方、段階による分類は「プロセスのどこから漏れているか」を最適化します。これこそが、システム全体の改善を実際に促すものです。
• 発生と流出の両方を分析します。 不具合がなぜ発生したのか（予防）と、なぜもっと早く検出できなかったのか（検出）を分けて考えます。この2つを混同すると、検出のギャップを示すシグナルが失われます。通常、これはコードの修正ではなく、プロセスやツールの改善で対処すべきものです。
• 仮説は、もっともらしさではなく事実に照らして検証します。 「なぜ」を繰り返す分析における最大のリスクは、専門知識の不足ではありません。実際に理解すること（「comprendre」）の代わりに、理解したという 感覚（「avoir compris」）で済ませてしまうことです。その分野に詳しいほど、むしろこのリスクは高まります。経験豊富な読者は、過去の経験に合致するという理由で、もっともらしい原因を早々に受け入れてしまうからです。次の「なぜ」に進む前に、連鎖する各段階を、検証可能な情報（差分、ログ、チケットの履歴など）と照らし合わせて確認してください。

検出段階

すでに明らかでない場合は、どの段階で不具合が検出されたかをユーザーに確認してください。推測してはいけません。

段階	検出された場所
A	ローカル環境（開発者自身のマシン）
B	チームレベル（CI またはコードレビュー）
C	検証環境（プロダクトオーナーがギャップを発見）
D	品質確認／ステージング環境（QA が発見）
E	本番環境（チームメンバーが発見）
F	クライアント（クライアントから報告）

後の段階（E、F）で発生した不具合は、早い段階（A、B）で発生したものよりもコストが高く、プロセス上のギャップが大きいことを示します。

再発する不具合やチームをまたぐ不具合については、動作やデータがたどった経路を図示し、不具合が見つかった場所を記録して、段階ごとに再発状況が把握できるようにしてください。現在の基準値をもとに、測定可能な改善目標を設定してください。これは、品質情報の流れを図示し、発見された場所ごとに不具合を分類し、ソフトウェアチーム向けに品質データを可視化するという野村氏の指針を応用したものです（The Toyota Way of Dantotsu Radical Quality Improvement、プレビュー、第1章）。

ワークフロー

まず、不具合によって現在も被害が発生しているかを確認してください。該当する場合は、以下の分析よりも先に、ユーザーが許可した範囲内で封じ込め（ホットフィックス、ロールバック、または回避策）を優先してください。分類や「なぜ」の連鎖を完了するために対応を遅らせてはいけません。すでに実施した封じ込め措置は、提案する対応とは分けて記録してください。

次に、以下の分析手順を順番に進めます。根本原因について結論を出す前に、不具合の内容と検出段階を特定してください。

1. 不具合を説明します。 期待される動作と実際の動作を示してください。ユーザーの説明だけでは正確に記述するための情報が不足している場合は、推測したり具体的な内容を作り出したりせず、質問してください。
2. 検出段階（上記の A～F）を特定します。 記載されていない場合は、ユーザーに確認してください。
3. 再発の有無を確認します。 この同じ不具合、または根本に同じパターンがある不具合が過去に発生したことがあるか、ユーザーに尋ねてください（アクセスできる場合は、利用可能な課題トラッカーや履歴も確認してください）。不具合が繰り返し発生している場合、より深いシステム上の根本原因が示唆されるため、一度限りの修正よりも根絶が重要になります。
4. 5 Whys（発生）の手法で根本原因を特定します。 症状や推測ではなく、手順 1 の不具合の説明を出発点にし、「なぜ」を繰り返し問いかけます。そのたびに、前の回答を新たに説明すべき事柄として扱います。回答が、単なる症状の言い換えではなく、具体的に対処可能な内容（プロセス上の抜け、確認項目の不足、誤った前提など）を示したら終了します。通常は 5 段階程度ですが、回数に決まりはありません。
   • 連鎖が特定の人物による判断（設計上の選択、確認項目の省略、要件の読み違い）に行き着き、その判断理由を確認できない場合（担当者に連絡がつかない、会話履歴や意思決定ログが残っていないなど）は、その箇所を結論ではなく未確認の仮説として扱ってください。結論に事実として組み込まず、その旨を出力に明記してください。また、担当者に連絡できる場合は、最終確定前に本人に確認し、必要に応じて訂正してもらってください。
   • 例外 — 移行に起因する不具合： 既存の動作を移植またはリファクタリングする際に発生した不具合では、根本原因は、記録されていない人間の判断ではなく、移行元の入力（元のソース）にあることがよくあります。この場合、担当者や会話履歴がなくても、ソースとの差分を調べることで、通常は高い確度で原因を追跡できます。
   • 根本原因の追跡対象はコードに限りません。該当する場合は、実装したコードだけでなく、根底にあるストーリーやエピックの記述（曖昧な受け入れ条件、仕様に定められていなかった未処理のエッジケースなど）も、根本原因の候補として確認してください。
5. それ以前に検出できなかった理由を調べます（流出）。 実際に検出された段階と、妥当な範囲で最も早く検出できた段階を比較します。この調査は手順 4 とは分け、独立した短い「なぜ」の掘り下げとして行ってください。検出漏れの根本原因は、欠陥そのものとは異なり、プロセスやツールの不足（テストがない、lint ルールがない、レビューチェックリストに項目がないなど）であることがよくあります。
6. 学びを共有する項目をまとめます。 修正案を提案する前に、手順 4～5 で明らかになった誤解や不足を、共有しやすい短い要約としてまとめます（PR／Jira のコメント、Slack のメッセージ、1 枚のスライドなど）。関与していなかったチームメイトが 1 分以内で理解できる内容にしてください。根本原因が一人の頭の中にしかなければ、次の発生を防げません。学びを実際に広めるのが、この取り組みです。
7. 対策を記録します。 すでに実施した封じ込め策を記録し、残っている即時修正を提案します。完了した対応、確認された結果、提案を区別してください。封じ込めは、再発を防止するものでなくても構いません。
8. 根絶策を設計します。 対策よりも深く掘り下げます。この種の不具合全体が、遅い段階まで検出されずに残るケースも含め、構造的に再発できなくなる恒久的な変更（プロセス、ツール、自動チェック、ドキュメント、トレーニング）とは何でしょうか。大規模なリファクタリングよりも、小さなガードレールを優先してください。大規模な変更より、シンプルで自動化され、元に戻せるチェック（1 行の lint ルール、テストを 1 つ追加する、PR テンプレートからリンクするドキュメントの一節など）が適しています。実施されなかったり、新たな不具合を招いたりする大掛かりな修正より、小さなガードレールを確実に導入するほうが効果的です。1 件の事例だけに対処するものを、根絶策と呼ばないでください。
9. 予防策の検証と再発の監視は分けて行います。 再現テストや回帰チェックを使って、ガードレールが元の不具合を検出または防止することを実証し、結果と対象シナリオを記録します。未テストの対策は、提案中または未検証として明記します。再発の監視については、監視期間と、再発が起こり得る作業量または機会を記録します。何も起きなかった期間は観察結果であり、根絶の証明ではありません。継続的な追跡のため、担当者と見直しの時期を定めてください。

根絶策の優先順位付け（任意、定期的なチーム利用向け）

複数の根絶策の候補があり、優先順位を付ける必要がある場合（その場で決定するのではなく、定期的なチームの時間枠で検討する場合など）は、各候補を評価し、自動化されていて、リスクが低く、この不具合の領域に限定されているものを優先します。無関係なサービスに影響するものは避けます。

基準	確認すること
影響	この不具合や同様の不具合の再発を防げたでしょうか？
複雑さ／リスク	新たなバグを引き起こしたり、無関係なコードを不安定にしたりする可能性はありますか？
作業量	開発者一人あたり、実装にどのくらいの作業が必要ですか？
検証にかかる時間	自動で（短時間で）検証できますか？ それとも手動での確認（時間がかかる）が必要ですか？

候補を一度にすべて実施するのではなく、各サイクルでスコアが高くリスクの低い項目を少数選びます。一度に多くをまとめて実施すると、この手法が避けようとしている火消し対応や大規模リファクタリングによる不安定化を招きます。

チームの実施ペース（任意、参考例）

単発ではなく継続的に取り組むチーム向けに、この方法では以下のように調整します。

• 1日に1件のバグ修正分析をテックリードが担当します。差分を確認し、根本原因を記録し、コードベース内に同様の潜在的な不具合がないかを調べます。
• 毎日の短い同期ミーティング（10～15分、「Bug Fix Analysis Coffee」）で、チームが一緒に対策を提案します。新しい lint ルール、エッジケース用フィクスチャ、修正をきっかけとした小規模なリファクタリングなどが挙げられます。指示系統ではなく、助け合いの連鎖として捉えます。「プロセスが想定どおりに進まなかった箇所を一緒に確認して、対策を考えましょう」という姿勢であり、「X をやめて、代わりに Y をしてください」という姿勢ではありません。目的は、責任を追及することではなく、自分自身の見落としに気づけるようメンバーを支援することです。
• 不具合が表面化してから24時間以内に対応し、状況をよく覚えているうちに分析を行います。

単一の不具合についての分析ではなく、継続的なチームの取り組みをユーザーが立ち上げている場合に限り、この実施ペースを提案してください。

A分類の不具合を減らす：「最初から正しく」（任意の手法）

ステージAの不具合（コーディング中に発見される不具合）を特に減らすには、開発者が機能ごとに手動テスト／更新を試せるのは1回のみという制約を設けます。最初の試行で失敗した場合は、A分類の不具合として数えます。これにより、開発者は事前の設計や TDD に注力するようになります（手動でのクリックを繰り返すのではなく、端末で高速にテストを実行して正しさを確認するようになります）。また、機能を一度で完成させたチームは、公開の場で称賛できます（Slack bot による称賛など）。この方法は、A分類の不具合に対する個別の手法としてのみ提示し、他のステージの一般的な根絶策としては扱わないでください。

注意事項

• AI エージェントは、欠陥がコードのどこで入り込んだかを確実にたどれますが、担当者がなぜそのように書くことを選んだのかまでは確実に特定できません。作者に確認できる場合や、保存された意思決定ログ／会話履歴を照合できる場合を除き、その因果関係は、どれほど確信を持って述べられていても仮説です。確定した根本原因として提示しないでください。これは回避策をプロンプトで工夫して解決できる問題ではなく、明確な限界です。
• ステップ 4 またはステップ 5 で、当時理由が記録されていなかったために「なぜ」を再構成できないという抜けが見つかった場合、それ自体が発見事項です。意思決定ログがないことは、有効な再発防止策の候補です（今後、その種の意思決定について簡潔な理由を文書に残すようにすること）。これは、目の前の欠陥に対処するコード修正とは別に扱います。
• 対策と再発防止策は同じものではありません。対策は今回の事象を修正し、再発防止策はその種の欠陥が再び起きるのを防ぎます。別々のセクションに記載し、対策を再発防止策に見せかけないでください。
• 5 Whys の因果関係は、ステップ 1 で記述した欠陥の説明から始めてください。ユーザーがついでに述べた、より曖昧な症状から始めてはいけません。
• 「なぜ発生したのか」（ステップ 4）と「なぜ検出できなかったのか」（ステップ 5）は、別々に掘り下げます。ひとつの因果関係にまとめないでください。
• ユーザーが検出段階や欠陥の説明を確信できていない場合は、最も可能性の高い選択肢をこちらで選ぶのではなく、直接質問してください。
• 再発防止策は「大規模なリファクタリング」を意味しません。抜けを埋める、最小限の自動チェックを優先してください。過剰な修正は優先度を下げられやすく、独自の欠陥を招く可能性も高くなります。
• 深刻度ではなく段階で分類してください。ここでは不適切な問いに最適化してしまうため、Low／Medium／High の軸を再導入しないようにしてください。
• 最終報告書は、ユーザーが欠陥を説明したときに使った言語で作成してください。
• 厳密さを装う、次の 2 つの失敗パターンに注意してください。**「魔法のような思い込み」とは、すべてを説明する根本原因がひとつだけあるはずだと思い込み、もっともらしい答えがひとつ出た時点で因果関係の検証を止めてしまうことです。「因果関係の拡散」**とは、あらゆることがあらゆることにつながっていると扱い、ほぼどのような提案でも正当化できるようにすることです。どちらも実際の検証手順を省略しています。適切な「なぜ」の連鎖は範囲を絞り、各リンクを証拠に照らして確認し続けます。

出力テンプレート

単一の欠陥を分析する場合は、_template.md の構造化テンプレートを使用してください。テンプレートには、メタデータ表、問題の記述、因果関係、根本原因分析、検出失敗の原因、対策、再発防止策からなる文書全体の構成が定義されており、各セクションにはインラインのガイダンスコメントが含まれています。

証拠によって裏付けられる原因のみを記載してください。未確認の説明には仮説の印を付け、不足している情報は不明と記載します。該当しないサブセクションは、誤解や検出失敗をでっち上げて埋めるのではなく、省略してください。

「Causal Chain」と「Root Cause of Occurrence」セクションには、欠陥の説明、再発チェック、5 Whys の因果関係全体、「なぜ早期に検出されなかったのか」の分析を記載してください（後者は「Detection Failure Causes」に記載します）。「Countermeasure」と「Eradication」は厳密に分けてください。

ユーザーが学びの共有項目や優先順位付けのスコアも文書に記録したい場合は、任意の ## Learning to share セクションと ## Prioritization セクションを追加してください。デフォルトでは追加せず、明示的に依頼された場合、またはチームレベル／継続的な課題として明らかに取り組んでいる場合に限り追加します。

ユーザーがインラインでの表示ではなくファイルへの保存を希望する場合は、Markdown（.md）ファイルとして作成してください。

ベンチマーク

シナリオ：.benchmarks/scenarios/dantotsu-001-escape-stage.md · 実行日：2026-08-31 · ログ：.benchmarks/runs/2026-08-31/dantotsu-001-escape-stage.json

モデル	なし	あり	差分
claude-opus-4-8	67%	100%	+33%
claude-sonnet-4-6	83%	100%	+17%
claude-haiku-4-5	83%	100%	+17%

合格（実行日：2026-08-31）。全体として小幅な向上です。ベースラインでも、ステージ分類を最初に行うルールがある程度は適用されています。.agents/skills/skill-optimizer/rules/release-gates.md に従って判定してください。