第10話｜上げるほどではない｜東央ソリューションズ―― 実務統合型PM論・連載小説

東和物流本社。

要件定義フェーズも終盤に差しかかっていた。

大型会議室の壁面モニターには、課題管理表が映し出されている。

高梨はその一覧を眺めながら、小さく眉をひそめた。

■運用ルール未確定

■拠点間業務差異整理中

■AI判定基準検討中

■データクレンジング方針未決定

■権限設計レビュー保留

赤色ではない。

期限超過にもなっていない。

課題管理表として見れば、どれも普通だった。

だが。

高梨には分かっていた。

これらは独立した課題ではない。

全部つながっている。

そして。

どれも要件定義完了までに整理できる気がしなかった。

会議終了後。

東央メンバーだけが残った。

白石が言う。

「AI判定基準は後続設計で詰める前提でいいと思います」

神谷も頷く。

「顧客もその認識だろう」

「まずは要件定義を締めないと進まないからな」

高梨は黙った。

違和感はある。

だが。

反論する材料もない。

数日後。

品質管理部レビュー。

古市は課題管理表を眺めながら言った。

「この運用ルール未確定って何ですか？」

「現場ヒアリング継続中です」

「いつ決まる予定ですか？」

「まだ調整中です」

古市は無言になった。

そして別の行を見る。

「AI判定基準検討中」

「これは？」

「PoC結果を踏まえて・・・」

「いつ決まるんですか？」

「・・・」

高梨は答えられなかった。

レビュー後。

古市は黒田を呼び止めた。

「黒田部長」

「はい」

「この案件、かなり危険な匂いがします」

黒田は苦笑した。

「分かっています」

「高梨も苦労してますよ」

古市は首を振った。

「違います」

「苦労している話ではありません」

「誰か上位者が判断しないといけない状態です」

その言葉が妙に残った。

翌週。

東和物流との定例会。

田辺が笑顔で言った。

「要件定義もだいぶ固まってきましたね」

「来月には完了できそうでしょうか」

会議室の空気が少し止まる。

高梨は課題管理表を見る。

固まっている。

そう見えている。

だが。

実態は違う。

会議終了後。

黒田に呼ばれた。

会議室には二人だけだった。

黒田は資料を机に置いた。

品質管理部レビュー資料。

課題管理表。

議事録。

すべて並んでいる。

「高梨」

「はい」

「お前、この件どう思ってる」

高梨は少し考えた。

「正直、危険だと思っています」

「運用も整理できていませんし」

「要件もまだ曖昧です」

黒田は頷く。

「それ、いつから思ってた？」

「・・・二か月くらい前からです」

「古市にも言ったか？」

「はい」

「議事録にも書いたか？」

「はい」

「課題管理表にも？」

「入っています」

黒田は黙った。

そして静かに言った。

「それはエスカレーションじゃない」

高梨は顔を上げた。

「え？」

「お前は説明しただけだ」

会議室が静まり返る。

黒田は続けた。

「課題管理表に書く」

「議事録に残す」

「会議で説明する」

「それは情報共有だ」

高梨は何も言えない。

黒田は資料を指差した。

「エスカレーションってのはな」

「困っています」

「だけじゃない」

「このまま放置したら何が起きるのか」

「いつまでに判断が必要なのか」

「誰に判断してほしいのか」

「そこまで伝えて初めてエスカレーションだ」

高梨の視線が落ちる。

確かに。

自分は説明していた。

共有していた。

課題管理表にも載せていた。

だが。

誰かに判断を求めただろうか。

「黒田さん」

高梨が小さく聞いた。

「もし今からエスカレーションするとしたら・・・」

黒田は即答した。

「もっと早くやるべきだった」

その言葉が胸に刺さる。

だが。

黒田は続けた。

「それでも、今やらないよりはマシだ」

窓の外には夜景が広がっていた。

高梨は課題管理表を見つめる。

課題は見えていた。

危険も見えていた。

だが。

誰も判断していなかった。

いや。

判断してもらうための行動を。

誰も取っていなかった。

プロジェクトは静かに進んでいく。

そして。

静かに進んでいるように見える時ほど。

本当に危険なのかもしれなかった。

ここまで読んで、「高梨はなぜもっと早くエスカレーションしなかったのか」と感じた方もいるかもしれません。

しかし実際のプロジェクトでは、高梨のような判断は珍しくありません。

• まだ何とかなるかもしれない

• 上司に迷惑をかけたくない

• 顧客との関係を悪化させたくない

• まずは自分で解決すべきだ

こうした責任感や善意が、結果として問題を大きくしてしまうことがあります。

そして多くの場合、問題は「エスカレーションしなかったこと」そのものではありません。

「どの状態になったら、誰に、何を、どのようにエスカレーションするのか」が定義されていないこと。

そこに本質的な問題があります。

今回のケーススタディでは、

「エスカレーションはなぜ遅れるのか」
「PMはどのタイミングで上位層を巻き込むべきなのか」
「組織としてエスカレーションを機能させるには何が必要か」

を考えてみましょう。

ケーススタディ

ケース

東和物流DX推進プロジェクト。

要件定義フェーズが進む中、

• 部門ごとに要求が食い違う

• 課題が増え続ける

• スケジュールに遅延兆候が出始める

という状況になっていた。

PMの高梨は問題を認識していたが、

「まだ挽回できる」
「次回会議で整理できるはずだ」

と考え、自身の上司である黒田へのエスカレーションを見送っていた。

しかし数週間後。

問題はさらに拡大し、顧客経営層への説明が必要な状況にまで発展する。

結果として、

より大きな調整コストと信頼低下を招いてしまった。

Q1

エスカレーションが遅れるプロジェクトにはどのような特徴があるでしょうか？

A1｜解答例

最も多い原因は、

「問題が見えていない」のではなく、「問題だと認めたくない」ことです。

プロジェクト現場では、

• まだ何とかなる

• もう少し様子を見よう

• 次回で解決できるはず

という心理が働きます。

特に責任感の強いPMほど、

「自分で解決しなければならない」

と考えがちです。

しかし問題は放置されるほど解決コストが増加します。

プロジェクトマネジメントでは、

早すぎるエスカレーションより、遅すぎるエスカレーションの方が圧倒的に危険

と考えるべきです。

Q2

PMはどのようなタイミングでエスカレーションすべきでしょうか？

A2｜解答例

PMの役割は、

問題を自分で抱えることではなく、

適切なレベルの意思決定者に適切なタイミングで問題を届けること

です。

例えば、

• 重要課題が一定期間解消しない

• スケジュール遅延が見え始めた

• 部門間対立が解決できない

• 契約前提が揺らぎ始めた

• 顧客との認識差が拡大している

といった状態はエスカレーション対象です。

重要なのは、

問題が確定してからではなく、

重大問題になりそうな兆候が見えた段階で上位層を巻き込むこと

です。

エスカレーションとは敗北宣言ではありません。

組織の力を使うための仕組みです。

Q3

エスカレーションを個人依存にしないためには何が必要でしょうか？

A3｜解答例

必要なのは、

エスカレーション基準の明文化です。

例えば、

• 重要課題が2週間以上未解決

• 工程遅延が10％を超過

• 顧客部門間で合意形成ができない

• スコープ変更要求が発生

• 品質リスクが一定基準を超過

など、

事前にルールを定義しておきます。

そうすることで、

PM個人の性格や経験に依存せず、

組織として同じ判断ができるようになります。

実際に成熟した組織では、

「エスカレーションするかどうか」

ではなく、

「基準に該当したのでエスカレーションする」

という運用になっています。

今回の学び

第10話で高梨が苦しんだのは、

問題が見えていなかったからではありません。

見えていたにもかかわらず、

「まだ自分で何とかできる」

と考えてしまったことです。

そしてそれは高梨個人の問題ではなく、

エスカレーション基準が存在しない組織で頻繁に起きる現象でもあります。

プロジェクトを守るために必要なのは、

優秀なPMではありません。

問題が大きくなる前に組織が動ける仕組みです。

次回、第11話。

責任の所在が曖昧なまま進んだプロジェクトで、ついに大きな問題が発生します。

そして会議室では、こんな言葉が飛び交い始めます。

「大丈夫ですよね？」