【深堀り】「原因分析」へのアプローチ- - 思考と分析の道具箱

はじめに

　私たちは日々の生活や仕事の中で、さまざまな「問題」に直面します。
　例えば、ITシステムが急に動かなくなった、商品の売上が伸び悩んでいる、チーム内のコミュニケーションがうまくいかない、などです。
　これらの問題にどう対処すれば良いのでしょうか？

　多くの場合は、目に見えている現象（症状）だけを取り除こうとしがちです。しかし、それでは根本的な解決にはなりません。症状は一時的に消えても、また同じ問題が繰り返し発生してしまうでしょう。

　そこで重要になるのが、「原因分析」です。
　これは、問題の真の根っこ、つまり「原因」を特定し、取り除くためのアプローチです。

　この記事では、「原因分析」について深掘りしていきます。

1.「原因分析」とは

1.1 「原因分析」の定義と内容

　「原因分析」とは、「問題がなぜ起こっているのか、その根本的な理由（原因）を突き止める活動」のことです。
　単に「何が起こったか」だけでなく、「なぜそれが起こったのか」を深く掘り下げて考えていく作業と言えます。

　例えば、会社のプリンターが故障したとします。
　この場合、故障したこと自体が「問題」です。

　原因分析では、「なぜプリンターが故障したのか？」
を考えます。

　紙詰まりが頻繁に起こっていたのか、
　インクが切れていたのか、
　部品が劣化していたのか、
　あるいは間違った使い方をしていたのか、
など、考えられる原因を一つずつ探っていくのです。

1.2  「問題分析」のプロセスと「原因分析」の位置付け

　ビジネスやITの世界では、問題を解決するためのプロセスを体系的に進めることがよくあります。
　これを「問題分析」と呼びます。

　一般的な「問題分析」のプロセスは、以下のようになります。

(1)問題の特定・定義
　何が問題なのかを明確にします。

(2)情報収集
　問題に関連する情報を集めます。

(3)原因分析　←ここが今回のテーマです！
　集めた情報をもとに、問題の根本原因を探ります。

(4)対策の立案
　原因を取り除くための具体的な対策を考えます。

(5)対策の実行
　対策を実行します。

(6)効果の検証
　対策の効果があったかを確認します。

(7)標準化・再発防止
　解決策を定着させ、再発を防ぎます。

　このプロセスの中で「原因分析」は、問題解決の要（かなめ）となる部分です。
　原因を特定できなければ、効果的な対策を立てることはできません。

1.3  原因分析の目的

　原因分析の主な目的は、以下の３つです。

(1)根本的な問題解決
　表面的な対処ではなく、二度と同じ問題が起こらないように、真の原因を取り除きます。

(2)再発防止
　原因を特定し、それに対する対策を講じることで、将来的に同様の問題が発生するのを防ぎます。

(3)改善点の発見
　原因を探る過程で、これまで気づかなかった業務プロセスやシステムの課題、改善すべき点が見えてくることがあります。

1.4 原因分析が必要な場面と具体例

　原因分析は、次のような様々な場面で役立ちます。

【IT分野】

(1)システム障害
　　「ECサイトがダウンした」
　　→なぜダウンしたのか？
　　　・サーバーの負荷過多
　　　・プログラムのバグ
　　　・外部からの攻撃　など

(2)パフォーマンス低下
　　「アプリの動作が遅い」
　　→なぜ遅いのか？
　　　・データベースの処理が重い
　　　・ネットワーク帯域の不足
　　　・メモリ不足　など

【ビジネス分野】

(1)売上不振
　　「特定商品の売上が前年より低い」
　　→なぜ低いのか？
　　　・競合商品の台頭
　　　・プロモーション不足
　　　・品質問題
　　　・景気悪化　など

(2)顧客クレーム増加
　　「製品に関する問い合わせが多い」
　　→なぜ多いのか？
　　　・製品の使い方がわかりにくい
　　　・説明書が不親切
　　　・初期不良が多い　など

(3)従業員の離職率増加
　　「社員が定着しない」
　　→なぜ定着しないのか？
　　　・給与体系
　　　・人間関係
　　　・仕事内容
　　　・評価制度　など

(4)プロジェクトの遅延
　　「開発プロジェクトが予定より遅れている」
　　→なぜ遅れているのか？
　　　・要件定義の不備
　　　・スキル不足
　　　・コミュニケーション不足　など

1.5 そもそも「原因」とは何か？

　「原因」とは、ある現象（問題）を引き起こした直接的または間接的な理由や根源のことです。

　例えば、「体調が悪い」という問題があるとします。

　・直接的な原因
　　・風邪を引いた
　　・寝不足
　　・食べ過ぎ

　・間接的な原因
　　・仕事のストレス
　　・不規則な生活習慣
　　・栄養バランスの偏り

　このように、「原因」にはいくつもの層があり、表面的な原因のさらに奥に、根本的な原因が隠れていることがよくあります。
　原因分析では、この「根本的な原因」を探し出すことが重要なのです。

2. 原因分析の進め方

2.1 分析の進め方

　原因分析は以下のステップで進めることが推奨されます。

(1) 問題の明確化

　何が問題なのかを具体的に定義するステップです。
　客観的な事実として問題を捉えることが重要となりますです。
　また、「5W1H」（いつ、どこで、誰が、何が、どのように）の視点から情報を整理していきます。

　問題の明確化は、原因分析の出発点であり、最も重要なステップの一つです。
　ここで問題が曖昧だと、その後の情報収集や仮説設定が的外れになる可能性があるのです。
　主観や感情を排除して、定量的なデータや具体的な事象に基づいて問題を記述することが求められます。

【具体的な事例】

　【悪い例】
　　「最近、顧客からのクレームが多い。」（曖昧で主観的）

　【良い例:】
　　「先週から、ECサイトの決済ページにおいて、ユーザーがクレジットカード情報を入力後、エラーメッセージが表示され、購入が完了しないケースが1日に50件発生している。この問題は特にPCからのアクセスで顕著であり、スマートフォンからのアクセスでは発生していない。」
　　・いつ: 先週から
　　・どこで: ECサイトの決済ページ
　　・誰が: ユーザー
　　・何が: クレジットカード情報入力後のエラーによる購入未完了
　　・どのように: エラーメッセージが表示される

(2) 情報収集と整理

　問題に関連するあらゆる情報を多角的に集めて、整理するステップです。
　データ、ログ、関係者へのヒアリング、過去の事例などが含まれます。
　集めた情報は時系列や項目別に整理して、可視化します。

　「あらゆる情報」とは、直接的に問題と関連しそうなものだけではなく、一見関係なさそうに見える情報も含まれます。
　なぜなら、予期せぬところに原因が潜んでいることがあるからです。
　情報の可視化は、複雑な状況を全体的に把握して、パターンや傾向を見つけ出すのに役立ちます。

【具体的な事例】

　前述のECサイトの決済エラーの事例で考えてみます。

　【情報収集】
　　・エラーログ: エラーが発生した日時、エラーコード、メッセージ内容
　　・サーバーログ: 決済ページのアクセス状況、サーバーのリソース使用率
　　・ネットワークログ: ユーザーのアクセス元、通信状況
　　・データベースログ: 決済関連データの記録状況
　　・ユーザーヒアリング: どのような操作をしたか、どのようなエラーメッセージが表示されたか
　　・開発者ヒアリング: 決済システムのアーキテクチャ、最近の変更履歴
　　・過去の類似事例: 同様の決済エラーが過去に発生していないか
　　・外部サービス情報: 利用しているクレジットカード決済代行サービスの障害情報

　【情報整理と可視化】
　　・エラー発生頻度を時間帯別、曜日別にグラフ化
　　・エラーコードの種類と数を表にまとめる
　　・ユーザーの操作フローをシーケンス図で示す
　　・サーバーのリソース使用率を時系列グラフで示す

(3) 仮説の設定

　集めた情報から、「これが原因ではないか？」という仮説をいくつか立てるステップです。
　この段階では断定せず、「〜かもしれない」という形で考えます。

　仮説は、情報に基づいて論理的に導き出されるべきものです。
　直感や憶測だけで立てるのではなく、集めた情報から何らかの関連性やパターンを見つけて、それが原因である可能性を示唆するものとして構築します。
　複数の仮説を立てることで、視野を広げ、真の原因を見逃すリスクを減らします。

【具体的な事例】

　ECサイトの決済エラーの事例から、情報収集の結果に基づいて以下の仮説を立てます。

　・仮説1: 最近のシステムアップデートにより、決済処理ロジックにバグが混入した可能性がある。

　・仮説2: クレジットカード決済代行サービスとの連携部分で、一時的な通信障害が発生している可能性がある。

　・仮説3: 特定の時間帯にアクセスが集中し、サーバーのリソースが不足して処理が滞っている可能性がある。

　・仮説4: データベースのデッドロックにより、決済データが書き込めなくなっている可能性がある。

(4) 仮説の検証

　立てた仮説が正しいかどうかを、さらに詳細な情報収集や実験、テストなどによって確認するステップです。
　「それは本当に原因なのか？」、「その原因がなければ問題は起きないのか？」といった問いを繰り返し、深掘りします。

　仮説検証は、単なる確認作業ではなく、仮説を裏付ける証拠を集める、あるいは反証を探すプロセスです。
　実験やテストは、再現性を確認したり、特定の要因を取り除いた場合に問題が解消するかどうかを試したりするために有効です。

【具体的な事例】

　前述の仮説を検証します。

　・仮説1の検証:
　　・システムアップデートで変更された決済関連のコードをレビューし、ロジックミスがないか確認する。
　　・テスト環境で、アップデート前のバージョンと現行バージョンで決済フローを比較テストし、エラーが再現するか確認する。

　・仮説2の検証:
　　・クレジットカード決済代行サービスの障害情報を確認する。
　　・決済代行サービスとのAPI通信ログを詳細に分析し、エラーコードや応答時間を確認する。
　　・可能であれば、一時的に別の決済代行サービスを試用して問題が解消するか確認する。

　・仮説3の検証:
　　・エラー発生時間帯のサーバーのリソース使用率（CPU、メモリ、ネットワーク帯域）を詳細に監視する。
　　・負荷テストツールを用いて、特定時間帯と同程度のアクセス負荷をかけて、エラーが再現するか確認する。

　・仮説4の検証:
　・データベースのデッドロックログやロック情報を確認する。
　　・決済処理中にデータベースのロック状態をリアルタイムで監視する。

(5) 根本原因の特定

　複数の仮説を検証して、最終的に問題を引き起こしている真の「根本原因」を特定するステップです。
　一つの問題に複数の原因が絡んでいることもあり、優先順位をつけて対策を検討します。

　根本原因とは、その原因を取り除けば問題が再発しないような、最も深層にある原因のことです。
　表面的な原因だけではなく、「なぜそれが起こったのか？」を繰り返し問いかける「5回のなぜ」などの手法が有効です。
　複数の原因が複合的に絡み合っている場合、それぞれの影響度を評価して、最も効果的な対策を打つために優先順位をつけます。

【具体的な事例】

　検証の結果、以下のことが判明したとします。

　・システムアップデートで決済ロジックに軽微なバグが見つかったが、それはエラーの直接的な原因ではなかった。
　・決済代行サービス側では障害は発生していなかった。
　・特定の時間帯（毎日21時〜22時）にアクセスが急増し、その際にデータベースへの書き込み処理が集中することで、一時的にデッドロックが発生し、決済処理が完了できない状況になっていることが判明した。これがエラーメッセージの原因であった。
　・このデッドロックは、データベースの設定が特定の書き込みパターンに最適化されていなかったために発生していた。

　【根本原因の特定】

　ECサイトの決済エラーの根本原因は、「ピークタイムにおけるアクセス集中に対応できないデータベースのロック機構設定の不備」であると特定されました。

　【対策の検討】
　・データベースのロック機構設定を最適化する。
　・決済処理のバッチ処理化や非同期処理への移行を検討する。
　・サーバーやデータベースのスケールアップ・アウトを検討する。

2.2 分析でやるべきこと

(1) 客観的な事実に基づいて考える

　感情や憶測ではなく、データや証拠に基づいて判断することが重要です。

　人間は感情的な生き物であるため、問題が発生すると無意識のうちに「誰かのせい」にしたり、「こうだろう」と決めつけたりしがちです。
　しかし、感情や憶測に基づいて原因を特定しようとすると、誤った方向に進み、時間と労力を無駄にするだけでなく、真の原因を見逃してしまいます。
　データやログ、具体的な事象といった客観的な証拠だけを頼りに思考を進める習慣を身につけることが、正確な原因分析には必要なのです。

【具体的な事例】

　「あの新人が操作ミスをしたからシステムが止まったに違いない」と憶測で判断するのではなく、「システムログを見ると、新人が操作を行った直後にデータベースへの接続エラーが記録されている。これは新人の操作が直接の原因ではなく、操作トリガーとなったデータベース処理に問題があった可能性を示唆している」のように、ログという客観的な事実に基づいて考えます。

(2) 多角的な視点を持つ

　一人で考え込まず、チームメンバーや異なる部署の人など、多様な意見を取り入れることで、見落としていた原因に気づくことがあります。

　どんなに経験豊富な人でも、一人で考えられる範囲には限界があります。問題にはさまざまな側面があり、それぞれの専門性を持つ人々が異なる視点から意見を出し合うことで、より包括的な原因究明が可能になります。

　例えば、開発者、運用担当者、営業担当者、顧客サポート担当者など、それぞれの立場から見た問題点や情報を提供してもらうことで、一人では気づけなかった関連性や盲点を発見できます。

【具体的な事例】

　ある製品の不具合が発生した際、開発チームだけが原因究明を行うのではなく、製造ラインの担当者から「最近、特定の部品のサプライヤーが変わった」という情報、品質管理部門から「この部品の品質検査で以前から微細な問題が指摘されていた」という情報、営業部門から「特定の顧客から似たような不具合報告が複数寄せられている」という情報を集めることで、部品供給元の変更が根本原因である可能性にたどり着きます。

(3) 「なぜ？」を繰り返す

　一つの原因が見つかっても、「なぜそれが起こったのか？」とさらに深掘りして、根本原因にたどり着くまで問い続けることが大切です。これを「5回のなぜ」などと呼びます。

　表面的な原因に対処しても、その根本にある原因が解決されていなければ、問題は再発します。
　「なぜ？」を繰り返すことで、問題の連鎖を解きほぐして、最終的に真の根本原因に到達することができます。これは、問題解決における最も強力なツールの一つです。

【具体的な事例】

「なぜ、Webサイトの表示が遅いのか？」

　QA-1. なぜ遅いのか？ → サーバーの応答が遅いから。

　QA-2. なぜサーバーの応答が遅いのか？ → データベースへのクエリが遅いから。

　QA-3. なぜデータベースへのクエリが遅いのか？ → 特定のテーブルにインデックスが貼られていないから。

　QA-4. なぜインデックスが貼られていないのか？ → 開発時に性能テストが不十分だったから。

　QA-5. なぜ性能テストが不十分だったのか？ → 開発スケジュールがタイトで、テスト項目から省略されてしまったから。

　この場合、根本原因は「開発スケジュールの管理不備とテストプロセスの甘さ」であると特定できます。単にインデックスを貼るだけではなく、今後の開発プロセスを見直すという根本的な対策に繋がります。

(4) 情報を可視化する

図やグラフ、表などを使って情報を整理することで、複雑な関係性も理解しやすくなります。

人間は視覚から得る情報に強く影響されます。大量のテキストデータや数字の羅列では見落としがちなパターンや傾向も、図やグラフにすることで一目で把握できるようになります。特に、複数の要素が絡み合う複雑な問題では、情報間の関係性を視覚的に表現することで、議論を促進し、共通認識を形成するのに役立ちます。

【具体的な事例】

　・エラー発生率の推移を折れ線グラフで示すことで、特定の期間に急増していることがわかる。

　・システム間のデータフローをフローチャートで示すことで、どこでデータのボトルネックが発生しているか一目でわかる。

　・各プロセスにかかる時間をガントチャートで示すことで、遅延している部分が明確になる。

　・関係者間の意見をマインドマップで整理することで、異なる視点や潜在的な関連性を把握しやすくなる。

2.3 分析で注意すべきこと

(1) 犯人探しにならない

　原因分析は、誰かを責めることではありません。問題の再発防止と改善が目的であることを忘れないでください。

　問題発生時に、ついつい「誰がミスをしたのか」という犯人探しになりがちです。
　しかし、犯人探しはチームの士気を下げ、情報の隠蔽を招き、真の原因究明を妨げます。
　目的は問題を解決して、再発を防ぐことであり、個人を特定して非難することではありません。
　システム、プロセス、環境など、個人ではなく根本的な要因に焦点を当てるべきです。

【具体的な事例】

　あるシステム障害が発生した際、「Aさんが設定を間違えたからだ！」とAさんを責めるのではなく、「Aさんが設定を間違えた背景には、設定手順が不明確だった、チェック体制がなかった、緊急時に十分な情報が得られなかった、といったプロセスの問題があったのではないか」という視点で分析を進めます。

(2) 早急な結論を出さない

　表面的な原因に飛びついて、すぐに解決策を講じようとしないように注意します。

　問題解決を急ぐあまり、目に見える表面的な原因だけに対処してしまうことがあります。しかし、それでは根本的な問題は解決されず、同じ、あるいは類似の問題が再発する可能性が高くなります。
　深掘りして根本原因にたどり着くまでの忍耐と、そのための適切なプロセスを踏むことが重要なのです。

【具体的な事例】

　顧客からの問い合わせが増加した際に、「担当者の対応が遅いからだ」と即断して、担当者数を増やすだけでは、一時的に問い合わせ件数が減っても、問い合わせ自体が増加している根本原因（例：製品の説明書が不十分、WebサイトのFAQが分かりにくいなど）が解決されないため、再び問い合わせが増える可能性があります。

(3) 情報不足で判断しない

　不確かな情報や断片的な情報だけで原因を特定しようとすると、誤った結論を導き出す可能性があります。

　情報が十分に集まっていない段階で結論を出すのは危険です。
　断片的な情報や未確認の噂に基づいて判断すると、見当違いの対策を講じてしまい、問題解決をさらに遅らせるだけではなく、新たな問題を生み出すこともあります。
　常に情報の網羅性と正確性を意識し、必要であれば追加の情報収集を行うべきです。

【具体的な事例】

　システム障害の報告を受けた際に、エンジニアからの断片的な情報（例：「データベースが落ちたようです」）だけで判断して、「データベースのスペックを上げよう」と決定する。しかし、その後の詳細な調査で、実際にはデータベースサーバーのネットワーク設定に問題があり、断続的に接続が切れていたことが判明し、スペックアップは無駄な投資だったという結果になる。

(4) 全ての原因を特定しようとしない

　時間とリソースには限りがあります。影響度が高く、対策可能な根本原因に焦点を絞ることが現実的です。

　理想的には全ての原因を特定して、完璧な解決策を導き出したいものですが、現実には時間、予算、人材といったリソースに限りがあります。
　あらゆる可能性を追求することは、非効率的であり、迅速な問題解決を妨げることもあります。最も大きな影響をもたらしている根本原因や、比較的少ない労力で対策可能な原因に焦点を絞り、優先順位をつけて取り組むことが、現実的なアプローチなのです。

【具体的な事例】

　あるWebサービスのレスポンス速度低下の原因が複数発見されたとします。
　・データベースクエリの最適化ができていない
　・画像ファイルの容量が大きい
　・JavaScriptファイルの読み込み順序が適切でない
　・一部の外部APIの応答が遅い
　・サーバーの物理的な老朽化している

　これらのうち、「データベースクエリの最適化ができていない」が最もパフォーマンスへの影響が大きく、かつ比較的短期間で改善可能であると判断した場合、まずはその対策に注力して、他の原因は次のフェーズで検討するといった優先順位付けを行います。

3.原因分析に使える手法／ツールの具体的な事例と使い方

　原因分析には、様々な手法やツールがあります。ここでは、代表的なものをいくつか紹介します。

3.1  5回のなぜ (5 Whys)

【概要】
　トヨタ生産方式で用いられる手法で、「なぜ？」という問いを繰り返すことで、問題の根本原因を掘り下げていくシンプルな方法です。

【使い方】
　(1)まず、問題を定義します。

　(2)その問題に対して「なぜそれが起こったのか？」と問いかけます。

　(3)その答えに対して、さらに「なぜそれが起こったのか？」と問いかけます。

　(4)これを5回程度（または根本原因にたどり着いたと感じるまで）繰り返します。

【例】
　問題: 「システム障害が頻繁に起こる」

　(1)なぜ障害が頻繁に起こるのか？
　　→ サーバーの負荷が高いから。

　(2)なぜサーバーの負荷が高いのか？
　　→ 同時アクセス数が多いから。

　(3)なぜ同時アクセス数が多いのか？
　　→ サイトの宣伝を強化したから。

　(4)なぜサイトの宣伝を強化したのか？
　　→ 新しいキャンペーンを始めたから。

　(5)なぜ新しいキャンペーンを始めたのか？
　　→ 売上目標を達成するため。

　この例では、根本原因は「売上目標達成のためのキャンペーン開始」に伴う「システム負荷への考慮不足」と見えてきます。

3.2 特性要因図 (フィッシュボーン図、Ishikawa Diagram)

【概要】
　魚の骨のような形をしていることから「フィッシュボーン図」とも呼ばれます。問題（結果）に対して、どのような要因（原因）が影響しているかを体系的に整理し、視覚化するツールです。

【使い方】
　(1)図の右端に「問題（結果）」を記入します。

　(2)大きな骨（主原因）として、「人」「モノ」「方法」「設備」「環境」「測定」など、問題に関わる主要なカテゴリーを設定します。

　(3)それぞれの主原因に、さらに具体的な要因（小骨）を書き込んでいきます。

　(4)それぞれの要因について、「なぜそれが原因なのか？」と深掘りし、さらに細かい要因（枝骨）を書き加えていきます。

【例】
　「製品の不良品が多い」という問題に対し、人、モノ、方法、設備といった観点から原因を掘り下げていきます。

3.3 パレート図

【概要】
　問題を引き起こしている原因の中から、影響度の大きいものを特定するために使われるグラフです。
　棒グラフと折れ線グラフを組み合わせたもので、「80:20の法則（パレートの法則）」に基づいています。これは「問題の80%は、原因の20%から発生している」という経験則です。

【使い方】
　(1)発生している問題（不良品の種類、クレーム内容など）を、原因別に分類し、それぞれの発生件数や損失額を集計します。

　(2)集計したデータを、発生件数の多い順に並べ替えます。

　(3)棒グラフで各原因の件数を表し、折れ線グラフで累積構成比を表します。

　(4)累積構成比が80%に達する部分に線を引くことで、優先的に対処すべき原因を特定します。

【例:】
　「顧客からのクレームが多い」という問題で、クレームの内容を分類し、件数を集計します。
　パレート図を作成することで、「操作方法が不明」と「初期不良」のクレームが全体の8割を占めていることがわかり、これらに優先的に対策を講じるべきだと判断できます。

3.4 ロジックツリー

【概要】
　複雑な問題をツリー状に分解し、要素間の関係を視覚的に整理する手法です。MECE（ミーシー：Mutually Exclusive and Collectively Exhaustive / 漏れなく、ダブりなく）を意識して分解していくことで、全体像を把握しやすくなります。

【使い方】
　(1)一番上に「問題」を置きます。

　(2)その問題を、構成要素や原因に分解し、枝分かれさせます。

　(3)さらにその枝を分解していき、具体的なレベルまで掘り下げます。

【例】
　「売上が減少している」という問題を、「客数減少」と「客単価減少」に分解し、さらにそれぞれを細かく分解していくことで、考えられる原因を洗い出し、整理します。

　これらの手法は、単独で使うだけではなく、組み合わせて使うことで、より効果的な原因分析が可能になります。

おわりに

　「原因分析」は、問題解決の第一歩であり、最も重要なステップです。
　表面的な現象に惑わされず、「なぜ？」という問いを繰り返し、問題の真の根っこを見つけ出すことで、私たちはより良い未来を築くことができます。

　ITシステムの問題解決からビジネス戦略の改善、日々の生活の困りごとまで、原因分析の考え方はあらゆる場面で役立ちます。

　ぜひ、紹介した手法も活用しながら、目の前の問題に「深堀り」してみてください。

　そうすれば、きっと解決の糸口が見つかることでしょう。

書籍の紹介

・世界一やさしい問題解決の授業―自分で考え、行動する力が身につく 単行本 – 2007/6/28
　渡辺 健介 (著), matsu
　世界最高峰のコンサルティング会社で学んだロジカルシンキング・問題解決の考え方を中高生にもわかるように解説。
　世の中を生き抜く「ホンモノの思考力」が身につきます!
　日本、そして世界を代表する企業において、新人から経営陣まで大絶賛の問題解決力研修を提供する著者が、本質を、　分かりやすく、刺激的に届けます。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・「図解」問題解決入門: 問題の見つけ方と手の打ち方 単行本 – 2003/11/1
　佐藤 允一 (著)
　ダイヤモンド社 (2003/11/1)
　問題をいち早く発見し、原因を正しくとらえ、的確に対策をまとめる。日常の仕事や生活の問題解決を図解でわかりやすくガイド。
　問題の発見から解決まで、目標達成を可能にする思考力と行動力の基本スタイルを日常レベルの“問題”を題材にして、ユニークな図解と平易な語り口で展開。『目標・方針・戦略・戦術・機会活用、危機管理』などの正しい理解と認識を促す決定版。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解入門ビジネス 最新ロジカル・シンキングがよくわかる本 Kindle版
　今井信行 (著)  形式: Kindle版
　秀和システム (2023/3/30)
　ビジネスに役立つロジカル・シンキングが図解でわかる入門書。論理的ですばやい問題解決方法をみつける基本的な思考法と具体的な使い方、身に付けるにはどうしたらよいのか、便利なツールなど解説します。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・新版　問題解決プロフェッショナル Kindle版
　齋藤 嘉則 (著)  形式: Kindle版
　ダイヤモンド社 (2010/4/15)
　「ゼロベース思考」「仮説思考」「ＭＥＣＥ（ミッシー）」「ロジックツリー」など、　２つの思考、２つの技術、１つのプロセスを通じて、ビジネスの現場で問題解決を実践する方法を体系化。問題解決の基本的考え方はここにある。旧版のシンプルで明快な問題解決理論はそのままに、企業事例や演習課題を刷新。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-