個々の進捗は「順調」なのに、全体が読めなくなった ― 「複雑さ」の原則が示す相互作用の罠

各社が担当する機能は、単体で見ればどれもシンプル。個々の進捗表は「おおむね順調」。それなのに、全体としては予測困難な遅延が積み上がっていく——複数の協力会社が並行開発する案件で、私が実際に味わった不気味さです。この記事では、この「読めなさ」の正体から始めて、PMBOK第7版の原則⑨「複雑さ」の話をします。

この記事でわかること

要素ではなく「要素間の相互作用」が制御を難しくする仕組み
複雑さの原則が言う「複雑さはどこから生まれるか」
複雑な状況で、計画の精緻化より優先すべきこと

筆者はSIerのPMです。PMPを学び直しながら、「なぜあの案件は途中から読めなくなったのか」を教科書の言葉で捉え直して書いています。

まず言葉から。複雑さの原則が扱うのは、システムの相互依存、不確実性、人の予測しづらい行動が絡み合うと「複雑さ」が生まれる。それを認識し、状況に応じた対応をとるという考え方です。大事なのは、複雑さは「個々の要素の難しさ」からではなく「関係の数」から生まれるという点。一つずつは単純でも、多数がつながり影響し合うと、全体は予測できない振る舞いをします。

個々は単純なのに、全体が読めなくなった
複雑さを「難しさ」の一種だと捉えていた
「難しい」と「複雑」は別物
今は必ずやっていること
よくある質問(FAQ)
最後に
関連記事

個々は単純なのに、全体が読めなくなった

リーダー経験がまだ浅かった頃、複数の協力会社が並行して開発し、それぞれのインターフェースを連携させる案件に入りました。各社が担当する機能は、単体で見ればどれもシンプルでした。だから当初、私は「個社の進捗さえ管理すれば大丈夫」と考えていました。

ところが、フタを開けると全体が読めなくなっていきます。原因は、機能そのものではなく、会社間の連携タイミングの微妙なズレでした。A社の完了がB社の着手条件で、B社の遅れがC社に波及する——こうした依存関係のズレが少しずつ積み重なり、全体としては予測困難な遅延になっていたのです。個々の進捗表はどれも「おおむね順調」なのに、全体は遅れる。この不気味さが複雑さの正体でした。

そこで私は、個社の進捗管理とは別に、「会社間の依存関係だけを可視化した統合スケジュール」を作りました。誰の完了が誰の着手を止めているのか、その連鎖を一枚に描いたのです。すると、遅延の兆候が「つながり」の中に早く見えるようになりました。要素ではなく関係を見る。それが複雑さと付き合う第一歩でした。

複雑さを「難しさ」の一種だと捉えていた

「一つひとつをきちんと管理すれば、全体も管理できる」私はそう思い込んでいました。だから個社の進捗を細かく追うことに力を注いでいたのです。

でも、要素をいくら詳細に管理しても、要素間の相互作用を見なければ複雑さは制御できません。むしろ、複雑な状況ほど「計画をさらに精緻化する」より「観察して素早く適応する」ほうが効くことがあります。緻密な計画で複雑さをねじ伏せようとすると、たいてい計画のほうが先に崩れる。力の入れどころが違っていたのだと、あとで気づきました。