【実践ワーク】チームで問題の真の原因を探る特性要因図（フィッシュボーンダイアグラム）ワークショップ
チームで問題に直面した際、その原因が複雑に絡み合っていると感じることは少なくありません。表面的な現象だけを見て対策を講じても、根本的な解決には至らず、同じ問題が再発するケースもあります。このような状況を打開し、チーム全体で問題の真の原因を深く理解し、共通認識を持って解決に取り組むためには、体系的な分析手法が有効です。
本記事では、問題の原因と結果の関係を視覚的に整理する効果的な手法である「特性要因図（フィッシュボーンダイアグラム）」を用いたチームワークショップの進め方について解説します。このワークショップを通じて、チームは問題の本質を見極め、より効果的な対策を講じるための基盤を築くことができます。
特性要因図（フィッシュボーンダイアグラム）とは
特性要因図は、ある結果（特性）に対して、考えられるすべての原因（要因）を体系的に整理し、その関連性を示す図です。その形状が魚の骨に似ていることから、「フィッシュボーンダイアグラム」とも呼ばれます。石川馨氏によって品質管理のために考案された手法ですが、現在では様々な分野で問題分析や原因究明に広く活用されています。
特性要因図の構成要素:
- 特性（結果、問題）： 図の右端に書かれる、分析対象となる問題や結果です。魚の頭にあたります。
- 要因（原因）： 特性につながる可能性のある原因です。大きな原因のカテゴリを「大骨」、その下の詳細な原因を「中骨」「小骨」として枝分かれさせていきます。魚の骨にあたります。
特性要因図を作成することで、原因の洗い出し漏れを防ぎ、原因間の相互関係を理解しやすくなります。また、図として視覚化されるため、チームメンバー間での情報共有や議論を促進する効果も期待できます。
特性要因図ワークショップの目的と効果
このワークショップの主な目的は以下の通りです。
- チームで直面している問題の考えられる原因を網羅的に洗い出す
- 洗い出した原因間の関連性や構造を理解する
- 問題の根本原因に対するチーム全体の共通認識を形成する
このワークショップを実施することで、チームは以下の効果を得ることができます。
- 表面的な原因にとらわれず、問題の本質に迫ることができる
- 原因に基づいた、より効果的で持続可能な対策を検討できる
- 原因究明プロセスへの全員参加により、当事者意識と納得感を高めることができる
- 原因分析のプロセスを標準化し、今後の問題解決に活かすことができる
特性要因図ワークショップの準備
ワークショップを円滑に進めるためには、事前の準備が重要です。
- 目的の明確化: 何のためにこのワークショップを実施するのか（例: 特定のバグの発生率が高い原因を特定する、開発リードタイムが長期化している原因を分析するなど）、具体的な目的を明確にします。
- 分析対象となる「問題（特性）」の設定: チームで合意された、具体的で測定可能な問題を設定します。抽象的な表現ではなく、「〇〇のバグ発生率が先月比で20%増加した」「機能Xの開発リードタイムが計画より1週間遅延している」のように、具体的な事象として定義します。
- 参加者の選定: 問題に関係する多様な視点を持つチームメンバーや関係者を選定します。開発者、テスター、プロダクトマネージャー、運用担当者など、幅広い知識と経験を持つメンバーが集まることで、多角的な原因の洗い出しが可能になります。
- 場所とツールの準備:
- オフラインの場合: 十分な広さの会議室、ホワイトボードまたは模造紙、付箋、マーカー。
- オンラインの場合: 共同編集が可能なホワイトボードツール（Miro, Mural, FigJamなど）。これらのツールは、特性要因図テンプレートが用意されている場合が多く、オンラインでの同時作業に適しています。
- 所要時間の設定: 問題の複雑さや参加人数によりますが、通常1時間半〜3時間程度を見積もります。
- 事前の情報共有: 分析対象となる問題に関するデータや背景情報を事前に参加者に共有しておくと、ワークショップ当日の理解が深まり、より質の高い議論が期待できます。
特性要因図ワークショップの手順
以下の手順でワークショップを進めます。ファシリテーターは、参加者全員が意見を出しやすい雰囲気を作り、議論を整理する役割を担います。
ステップ1：問題（特性）の定義と図の準備（10分）
- ファシリテーターが、今回分析する問題（特性）を明確に提示します。
- ホワイトボードやオンラインツールに、図の右端に問題を記述し、そこから水平に線を引いて、魚の骨の「背骨」となる部分を作成します。
ステップ2：大骨（主な原因カテゴリ）の洗い出し（15分）
- 問題を引き起こしている可能性のある、大きな原因のカテゴリをブレインストーミングで洗い出します。
- 品質管理でよく使われる「4M」や「5M+1E」といったフレームワークを参考にすると、網羅性を高めやすくなります。
- 4M: Man (人), Machine (設備・機械), Material (材料), Method (方法)
- 5M+1E: Man (人), Machine (設備), Material (材料), Method (方法), Measurement (測定), Environment (環境)
- ソフトウェア開発チームの場合は、例えば「人（スキル、経験、コミュニケーション）」、「プロセス（開発手法、レビュー、テスト）」、「技術（アーキテクチャ、ツール、ライブラリ）」、「環境（開発環境、インフラ、物理環境）」といったカテゴリが考えられます。
- 洗い出したカテゴリを、背骨から斜めに伸ばす「大骨」として図に書き加えます。大骨の数は4〜8個程度が適切です。
ステップ3：中骨・小骨（詳細な原因）の深掘り（60分）
- 各「大骨」に対して、具体的な原因をブレインストーミングで洗い出していきます。
- それぞれの原因は、大骨から伸ばす「中骨」として記述します。さらに、中骨の原因を掘り下げた具体的な事象や要因を「小骨」として枝分かれさせていきます。
- 原因を深掘りする際には、「なぜなぜ分析」（「なぜそれが起きたのか？」と繰り返し問う）の手法が有効です。一つの原因に対して「なぜ？」を繰り返すことで、より根本的な原因にたどり着くことができます。
- ブレインストーミングの際は、以下のルールを意識します。
- 批判禁止: どんな意見も受け入れ、批判や否定をしない。
- 自由奔放: 突飛なアイデアでも歓迎する。
- 量より質: まずは多くの原因を出すことを重視する。
- 結合改善: 他の人のアイデアから連想を広げたり、組み合わせたりする。
- 出された意見は付箋に書き、該当する大骨や中骨の下に貼り付けていきます。オンラインツールであれば、デジタル付箋やテキストボックスで入力します。
- ファシリテーターは、特定のカテゴリに偏りすぎないように促したり、「他には原因として何が考えられますか？」と問いかけたりしながら、全員が意見を出しやすいようにサポートします。
ステップ4：図全体の整理と原因の関連付け（20分）
- 洗い出しが終わったら、図全体を俯瞰します。
- 類似した原因をまとめたり、より適切なカテゴリに移動させたりして、図を見やすく整理します。
- 原因と原因の間に矢印を書き加えるなどして、関連性を示すことも有効です。例えば、「経験不足（人）」が原因で「コードレビューの質が低い（プロセス）」につながっている、といった関連性を明確にします。
ステップ5：重要と思われる原因の特定と合意形成（15分）
- 洗い出された多くの原因の中から、特に問題への影響が大きいと思われる原因をいくつか特定します。
- チームメンバーで議論し、どの原因が最も重要であるか、あるいはどの原因から優先的に対策を講じるべきかについて合意形成を図ります。
- 必要に応じて、投票やディスカッションを通じて、優先順位付けを行います。ただし、このワークショップの主目的は原因の洗い出しと理解であるため、すべての原因に優先順位を付ける必要はありません。次のステップに繋げるための、注力すべき原因を特定することに焦点を当てます。
ステップ6：まとめと次のステップ（10分）
- ファシリテーターが、ワークショップで洗い出された主な原因と、チームが特定した重要と思われる原因をまとめます。
- この特性要因図分析の結果をどのように活用するか（例: 特定された原因に対する具体的な対策立案ワークショップを実施する、原因に関するデータをさらに収集・分析するなど）について、次のステップを確認します。
- 参加者からの感想や意見を募り、ワークショップを終了します。
効果を出すためのポイント
- 心理的安全性の確保: 参加者が自由に意見を言える、非難のない雰囲気を作ることが最も重要です。個人の失敗や特定の部門の責任追及にならないように、問題そのものとその原因に焦点を当てます。
- 多様な視点の導入: 問題に関わる様々な役割や経験を持つメンバーが参加することで、多角的な視点から原因を洗い出すことができます。
- 具体的な記述: 原因を記述する際は、「コミュニケーション不足」のような抽象的な表現ではなく、「〇〇に関する情報共有が週に一度しか行われていない」「チャットでの確認応答に平均で半日かかる」のように、具体的で観測可能な事象として記述するように促します。
- 網羅性と深掘りのバランス: 漏れなく原因を洗い出すことも重要ですが、必要以上に細かい原因に深掘りしすぎると時間がかかります。重要な原因に注力し、議論が脱線しないようにファシリテーターが調整します。
- 客観的な視点: 感情や個人的な意見ではなく、事実やデータに基づいた原因を挙げるように促します。
具体的なシナリオ例：開発チームのバグ発生率増加
あるソフトウェア開発チームで、最近リリースした機能に関するバグ発生率が顕著に増加しているという問題が発生したとします。この問題に対して特性要因図ワークショップを実施するシナリオを考えます。
- 問題（特性）： 「機能Yのリリース後のバグ発生率が過去の機能と比較して2倍に増加した」
- 大骨の候補:
- 人（開発者のスキル、経験、知識、コンディション）
- プロセス（開発プロセス、テストプロセス、コードレビュープロセス）
- 技術（コードの複雑さ、ライブラリのバージョン、開発環境、フレームワーク）
- 環境（本番環境の差異、外部連携システムの仕様変更）
- 管理（スケジュール、リソース配分、コミュニケーション）
中骨・小骨の洗い出し例（「プロセス」の大骨の場合）：
- プロセス
- テストプロセス
- 単体テストのカバレッジが低い
- 結合テストのパターン不足
- テスト設計のレビュー不足
- パフォーマンステストが不十分
- コードレビュープロセス
- レビュー担当者の経験不足
- レビューの時間が十分に取れない
- レビュー観点が不明確
- 自動コードチェックツールの導入遅れ
- 開発プロセス
- 仕様変更の頻繁な発生
- 仕様理解の不足
- タスクの見積もり精度が低い
- ペアプログラミングの実施不足
- テストプロセス
このように、一つの大骨から具体的な原因をどんどん掘り下げていきます。他の大骨についても同様に原因を洗い出し、図全体を作成します。
まとめ
特性要因図（フィッシュボーンダイアグラム）は、チームで問題の真の原因を体系的に探し出し、共通認識を形成するための強力なツールです。このワークショップを通じて、チームは表面的な事象にとらわれず、問題の本質に迫ることができます。
ワークショップで作成した特性要因図は、そこで終わりではなく、次のアクションに繋げるための重要なインプットとなります。特定された重要な原因に対して、具体的な対策を検討し、実行計画を立てることで、問題の根本的な解決に一歩踏み出すことができます。
チームで問題解決能力を高めるために、ぜひ特性要因図ワークショップを実践してみてください。原因に対する共通理解は、建設的な議論と効果的な対策立案の出発点となります。