序文
プロジェクトが炎上する時、そこには「言葉の定義」の不一致が原因であるばあいがあります。特に「問題」という言葉は、ビジネスにおいて最も危険な多義語です。本記事では、トヨタ生産方式、ITIL、そしてPMBOKという異なる思想を軸に、現場の混乱を構造的に解き明かし、PMが持つべき「言葉の定義権」について論じます。
前前提：事実と真実を混同していないか
多くの現場では、「誠実な報告」とは事実をありのままに伝えることだと信じられています。それ決して間違ってはいないのですが、そもそも我々は「事実」と「真実」を混同しがちです。
- 事実（Fact）：客観的な現象。ひとつしかない。
- 例：「コンデンサが破損している」
- 真実（Truth）：立場というフィルターを通した解釈。複数存在する。
- 例：エンジニアにとっての真実＝「物理的な経年劣化である」
- 例：経営者にとっての真実＝「あってはならない品質事故である」
我々が議論している「問題」とは、客観的な事実そのものではなく、常に「誰かの立場（フレームワーク）」というフィルターを通した部分的な真実に過ぎません。この前提に立たなければ、どんなに詳細な内容を記載した報告書もただのノイズだらけになってしまいます。
誰もが違う「辞書」で話している
プロジェクトが停滞する要因の一つは、「使っている辞書が違うこと」にあります。
象徴的なのが「問題管理表」です。
現場の管理表を見てみてください。「サーバーの応答が遅い（事象）」、「コンデンサを交換する（タスク）」、「運用フローが未整備である（改善点）」が、同じ「問題」という列に無秩序に並んでいないでしょうか？
これは、入力した人それぞれが持つ「問題」の定義がバラバラだからです。
ある人は「今起きている困りごと」を問題と呼び、ある人は「将来のリスク」を問題と呼びます。定義が曖昧なまま議論を進めることは、通貨の異なる国同士で、レートを決めずに商売をするようなものです。これでは、どんなに誠実に報告し合っても、会話が噛み合うはずがありません。
3つの「正義」が衝突する現場
この混乱を解きほぐすために、ビジネスの現場でよく使われる3つの「辞書（フレームワーク）」を比較してみましょう。どれも正しい定義ですが、見ている景色と、「根本原因」に対する執着度が全く異なります。
| フレームワーク | 「問題」の定義 | 根本原因の扱い | 視点と目的 |
| トヨタ生産方式 | 理想と現実のギャップ | 「なぜ」を5回繰り返す。 真因にたどり着かなければ改善にならない。 | 未来志向（改善）。 常に高い理想を掲げ、組織能力を向上させる。 |
| ITIL | インシデントの未知の原因 | 独立したプロセス（目的）。 原因が特定されるまで、その問題管理レコードはクローズできない。 | 過去・現在志向（究明）。 再発防止そのものを目的化する。 |
| PMBOK（第8版） | 価値実現への阻害要因 | 意思決定のための材料（手段）。 RCAは、品質と納期のトレードオフを判断するために行う。 | 価値志向（Value）。 「再発防止コスト」と「納期遅延リスク」を天秤にかけ、ビジネス価値を最大化する。 |
※注：PMBOKガイドにおいて管理対象となるのは「課題（Issue）」であり、ITILのような「問題管理（Problem Management）」という独立した管理プロセスは定義されていません。
「手段」か「目的」か、それが争点
ここで重要なのは、PMBOK（プロジェクトマネジメント）が決して根本原因を軽視しているわけではない、という点です。PMBOK第8版の原則にも「品質をプロセスに組み込む」ことは明記されています。
しかし、現場では以下の決定的なスタンスの違いが衝突を生みます。
- ITILのスタンス（運用）：「原因が分かるまで、終わらせない」。再発防止こそが絶対的な正義だからです。
- PMBOKのスタンス（PM）：「価値が最大になるなら、分析を切り上げる」。
PMは常に「今ここで原因究明に時間をかけることが、プロジェクトの最終的な価値（Value）につながるか？」を問います。もし、原因究明のコストが納期遅延の損失を上回るなら、あえて暫定対処で進む（リスクを受容する）判断を下します。
逆に、将来の安定稼働という「価値」を守るために、あえて納期を遅らせてでも徹底的に究明する判断もまた、PMBOK的な正解です。
この対立は、どちらかが間違っているのではなく、「再発防止」を絶対目的とするか、「価値最大化」のための判断材料とするかという前提がズレているために起きる構造的な話です。
定義だけでは足りない 「ベクトル」のコントロール
定義（辞書）の違いに加え、もう一つPMがコントロールしなければならないのが、言葉の物理的な「ベクトル（方向と解像度）」です。
方向（Direction）：どこを向いているか
その報告は、未来を向いているのか、過去を向いているのか。
- 復旧ベクトル（未来）: 顧客（ユーザー部門）は「いつ直るのか」を知りたい。
- 究明ベクトル（過去）: 品質部門や技術者は「なぜ壊れたのか」を知りたい。
解像度（Resolution）：「原因」と「問題」の連鎖
ここで最も重要なのは、「ある階層（タスク）にとっての『原因』は、その下の階層（タスク）にとっての『問題』になる」という連鎖構造です。
以下の例を見てください。立場によって「問題」と認識する対象がスライドしていくのがわかります。
表 階層（タスク）の問題と原因の解釈
| 視点 | 問題（Problem） | 原因（Cause） |
| 経営層 | 1万人の顧客に影響が出た （ビジネスインパクト） | 決済サービスが停止したから |
| 業務層 | 決済サービスが停止した （インシデント） | データベースサーバーが故障したから |
| サプライヤ | データベースサーバーが故障した （ハードウェア障害） | 内蔵HDDが応答しなくなったから |
| エンジニア | HDDが応答しない （デバイス故障） | 制御基板のコンデンサがショートしたから |
この連鎖において、エンジニアが発見した「コンデンサのショート（真実）」を、そのまま経営層に報告するのは「ノイズ」でしかありません。 しかし、PMの仕事は単に言葉を右から左へ「翻訳」することだけではありません。「システム思考（Holistic View）」を持ち、全体像を整合させることです。
「コンデンサの故障」が単なる部品不良なのか、それとも「調達プロセスのガバナンス欠如」という経営レベルの病巣なのか。その因果関係を見極め、経営層が対処すべきレベル（例：調達基準の見直し）に話を変換して届ける。そこまでやって初めて、PMはプロジェクトの価値を守る「スチュワード（Steward）」たり得ます。
現場の秘訣：最小限の情報量でクローズを狙え
PMの役割は、この連鎖の階段を自在に行き来することです。 そして、現場を生き抜くPMだけが知る秘訣があります。それは、「相手の意思決定に必要な最小限の情報量を見極める」ことです。
「隠蔽」と「抽象化」の違い
誤解してはいけないのは、これは不都合な真実を隠す「隠蔽」とは違うということです。 経営層に対して「コンデンサ」という詳細情報を伏せるのは、彼らが判断すべきは「部品の型番」ではなく、「ビジネスインパクトと復旧の確実性」だからです。
- 隠蔽: 判断に必要なリスク情報を伝えないこと。
- 抽象化: 相手の権限レベルで「意思決定できる粒度」に情報を変換すること。
経営層には「ハードウェア故障（原因）によるサービス停止（問題）であり、交換により復旧済み」と伝えれば、彼らは「よし、分かった」とハンコを押せます。そこに「コンデンサ」というノイズを混ぜれば、新たな懸念を生み、意思決定を阻害するだけです。
ただし、もしその故障が組織的な問題（安価な粗悪品の組織的採用など）に起因する場合は、あえて解像度を上げて「調達の問題」として突きつける誠実さも必要です。
相手の立っている階層に合わせて、「意思決定を支援するための最適な解像度」を選ぶ勇気を持つこと。それが、真の意味での戦略的誠実さなのです。
まとめ
「問題」という言葉を曖昧なまま放置することは、プロジェクトのリスクを放置することと同義です。
トヨタ的な改善か、ITIL的な究明か、それともPMBOK的な課題解決か。。。相手がどの「辞書」を持ち、どの「解像度」を求めているかを見極め、PM自らが共通言語を定義することは、プロジェクトの安定運営には欠かせない業務と考えます。
参考文献・出典
- Project Management Institute. (2025). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Eighth Edition.
- AXELOS. (2019). ITIL Foundation, ITIL 4 Edition.
- 大野 耐一. (1978). 『トヨタ生産方式―脱規模の経営をめざして―』ダイヤモンド社.
関連書籍
※本章にはPRを含みます。
コメント