はぁぁ……。
やれやれ、どうしたんだい？
もう僕……会社、辞めます……。
やれやれ
・・・
この間の事故報告をリスク管理マトリクスで説明は出来たんだろ？
出来ました！したんですが..そしたら、メガネカイマン部長に報告したら……
死ぬほど怒られたんです……。
そうしたら？
そしたら、そしたら・・・
そうしたら？
メガネカイマン部長に報告したら死ぬほど怒られたんです!!!
なんて言われたんだい？
正直、怖すぎてあまり覚えてないんですけど……
「暫定の対応計画と恒久対応計画を立てろ！」って……。
恒久対応計画？こうきゅう、それって……なんですか？
高級料亭のコースですか……
へへへへへへ？
……やれやれ。こいつは重症だ
オオハシさん、どうしましょ！？
そうだ！
先ほどのPMなんとかで、なんとかなりませんか！？
……
オオハシさんが好きな「PM何ちゃら」やればサクッといくでしょ？
確かにPMBOKには、
「リスク対応策の計画」「リスク対応策の実行」「リスクの監視」
……という考え方がある。
それだーーー！
それでチャチャっとなんとかしてくださいよ、オオハシさん！！
無理だ。
へ？
メガネカイマン部長が言うように、
暫定の対応計画と恒久対応計画を立てて、実行していく。
その流れは正しい。
そしてそれを、実行し、監視していく。
全体の流れは、PMBOKのリスクマネジメントと合致している。
じゃあ……！
でも、ことはそんなに簡単じゃないんだ。
どういうことですか……？
理論と現実は、なかなかうまくいかないものなんだよ。
そうなんですか・・・オオハシさんでもダメならもう僕は・・・
・・・
（チラチラ）
・・・
これはもう少し長いやりとりで解決していこう。
長いって、、、僕、
とりあえず、メガネカイマン君には私から話をしておくよ。（飛び去る）
……オオハシさん……
「なんとかしてくださいよ！」に対する一言、「無理だ。」
前回の会話劇の最後、インコ君が叫んだ
「それでチャチャっとなんとかしてくださいよ、オオハシさん！！」
というセリフに、オオハシさんは静かに、そしてはっきりと言いました。
「無理だ。」
一見、冷たいようにも聞こえるこの言葉。
どうしていつも優しいオオハシさんはこんな冷たい言葉を残すのでしょうか？
なぜ、オオハシさんは「無理だ」と言ったのか
「リスク対応策の計画」「実行」「監視」
PMBOKにしっかり書かれているプロセス。順番も整っていて、方法論としては完璧に見えます。
それなのに、なぜ「無理だ」と言ったのか？
それは、理論と現実の間にある“目に見えない壁”を知っているからです。
- 計画を立てても、現場で誰がやるのか決まらない
- 対応策を練っても、スケジュールもリソースもすでに限界
- 関係者に根回しが足りず、合意形成ができない
- 原因が複雑で、すぐに再発防止策が立てられない
つまり、「リスク対応策を立てる」ことそのものが一つのプロジェクトであり、
プロダクト管理における非常に壮大なテーマなのです。
“チャチャっと”では済まない。それが現場のリアルなのです。
それはメガネカイマン部長もわかっているはずです。それなのにインコ君に丁寧な説明をしないで
怒りに任せて投げつけた態度にも怒っていたのかもしれませんね。
この「現実は甘くない」ということがPMBOKの大きな変化の理由でもあるのです。
PMBOK第6版から第7版への変化と、その背景
PMBOK（プロジェクトマネジメント知識体系ガイド）は、長年にわたってプロジェクトマネジメントの標準として使われてきました。
第6版では、プロジェクトは「成果物を、スコープ・コスト・スケジュールに従って確実に収める」ことを目的とし、
全49のプロセスと10の知識エリア、5つのプロセス群によって構成されていました。
こうした体系的なアプローチは 汎用的なプロジェクト管理の方法としては優れているのですが、
実際には業界や規模によって適用できないものなのです。
特に変化の激しいIT分野やスタートアップ業界では、現場にそのまま適用するには堅すぎる、重すぎるという声も増えていきました。
そこで2021年に発行されたPMBOK第7版では、大きなパラダイムシフトが起こります。
ポイントは以下の通りです：
- 「プロセス志向」→「価値志向（Value Delivery）」への転換
- 固定化された手法ではなく、「原則」と「パフォーマンス領域」を中心に据えた構成
- アジャイル、リーン、デザイン思考など多様な実務を尊重し、柔軟なガイドラインへ
つまり、**「こうすればうまくいく」ではなく、「状況に応じて考えよう」**というメッセージに変わったのです。
第6版が抱えていた課題：汎用性と適用限界
第6版にも「組織体の環境要因（EEF）」や「組織のプロセス資産（OPA）」といった要素があり、
プロジェクトが置かれている文脈や組織の経験を考慮する余地はありました。
しかし、それでも多くの実務者が感じていたのは——
「確かに理想的なプロセスだけど、現場ではここまでできない」
という乖離でした。
PMBOK第6版は、あくまですべてのプロジェクトに対応できるような汎用性の高い理論書であり、
それをどこまで現場に落とし込めるかは、プロジェクトマネージャーの腕次第だったのです。
テーラリングとは？自分たちの現場に“合う”形を選ぶ力
PMBOK第7版で非常に重要なキーワードとして登場したのが、**「テーラリング（Tailoring）」**という考え方です。
これは一言で言えば、
「すべてのプロジェクトに、同じ手法・プロセスを当てはめる必要はない。
そのプロジェクトの特性に合わせて、方法を“仕立て直す”ことが大切」
という柔軟なアプローチを意味します。
たとえば——
- 小規模なスタートアップの開発案件に、50個以上のプロセスや成果物をそのまま当てはめるのは非効率
- 社内の文化がアジャイル型に寄っていれば、計画重視よりも適応力を優先すべき
- 顧客との契約条件や業界の規制によって、形式や成果物の求められ方が異なる
このように、プロジェクトごとの“前提条件”が違うのだから、
マネジメントの方法もそれぞれでいいというのが、テーラリングの基本的な考え方です。
ITシステムやWEBプロジェクトにおける「現実」との距離
今回の物語も、舞台はWebシステムの開発現場です。
- 短納期での先行リリース
- リソースの限界
- ステークホルダーの多さと情報の錯綜
- 技術的負債とバグの連鎖
こうした現場では、完璧なプロセスの実行よりも、
「いま、何ができるか」を考えて動くことのほうがはるかに重要です。
だからこそオオハシさんは、PMBOKの言葉を引用しながらも、
「理論通りにいかない現場」を見据えて、インコ君に“無理だ”と伝えたのでしょう。
次回予告：オオハシさんは、メガネカイマン部長に何を伝えるのか？
後編の今回は、「リスク対応策を立てれば解決！」という楽観的な期待に対し、
プロマネ経験者がどう答えるかを描きました。
リスクマネジメントは、計画したら終わりではなく、
実行し、周囲と連携し、そして継続的に観察していくものです。
そして次回、オオハシさんは、ついにメガネカイマン部長と対峙します。
そのとき、どんな説明をして、どう信頼を取り戻すのか。
──次回、「リスク対応策の実行と、信頼の再構築」に続きます。
お楽しみに。
コメント