魔法のチョークで描いた窓

2026年初頭に感じていること：

• 有機的な複数トラックによるプロジェクトマネジメントに自然に向かっています。AIの存在感が増したことが影響しているように思います。
• プロジェクトの中途での学習および学習機会の創出がより重要となっています。
• プロジェクトマネジメントはより非決定的になります。欲しいものを最終的に手に入れるためのやりくりが、より泥臭くなりそうです。

マネジメントの方法論について

「アジャイルかウォーターフォールか」のような議論はあまり有意義ではありません。なぜなら、事業会社において発生するプロジェクトの多くについて、プロジェクト特性との適合という観点で方法論を評価するタイミングが「リリース後」まで到来しないからです。

法規制への準拠など、プロジェクト初期での手法の選択に注意を要する場面があることは理解しつつ、より重要なのは、プロジェクトの「進展に合わせた」方法論の選定に柔軟であることです。また、開発チームへの適切な権限移譲を伴いつつ、状況に応じた「動的な」ハイブリッド構成が可能であることも大事です。

解像度は徐々に上がってくる

どれほど緻密に計画しても、必ず取りこぼす要件はありますし、プロジェクトが進む中で初めて見えてくる「創発的要件」も存在します。注意すべきは、その種の後から現れる要件は「あったら嬉しい（Nice-to-have）」機能ではなく、ほとんどの場合で「なくてはならない（Must）」要件であるという点です。

そもそも、要件とは理解するものではなく、背景も含めて「学習」するものです。学習し解像度を上げていく、これを健全なペースで推し進める必要があります。さもないと、必須の要件の取りこぼしや、優先度付けの誤りからスコープクリープが引き起こされることになります。

複数のトラックが必要

線形のアプローチであろうと、繰り返しのサイクルであろうと、単一のトラックですべてを完結させようとするのは困難です。なぜなら、「何を作るべきか」の探索の必要性は突発的に生じ（必ずしもプロジェクト初期ではありません）、それは「作る」ための時間軸とは別に進行されなければならないからです。

管理効率だけを意識しすべてを単一トラックに押し込むと、プロジェクトを「回せる」ベテラン人材への期待が過度に高まる属人化が発生します。個人の「引き出し」に頼らざるを得なくなるためです。

一方で、最初から複数トラックを意識しつつ、チームメンバー各々の自律性に期待し、複数のパースペクティブが活きる体制を作るほうが、結果的に効率的だと私は考えています。

スコープ調整とはなにか

QCDS（品質・コスト・納期・スコープ）の中で「スコープ」だけが調整可能な変数です。事業会社の内部プロジェクトにおいてはこの状況がほとんどです。したがって、スコープ調整はプロジェクトの成否を左右する重要なプロセスになります。

ここで注意すべき点があります。スコープ調整を、単に機能を「削る」ことだと誤解してはなりません。スコープ「調整」とはスコープの構成要素を「散らす（デカップリング）」ことです。当初はすべてが結合していて一つの塊に見えているスコープを細分化し、一つ一つを評価可能にすることです。

それができると、スコープ調整はプロジェクトが進行する中でリアルタイムで進み、プロダクトビジョンに沿った然るべき点に収束するはずです。「本当に欲しいものが最終的に手に入る状態」を作ることがスコープ調整の目的です。

品質管理

品質の追求に終わりは無いので、多面的な評価に基づいてバランスを取りながら「ゴールを定義する」ことが必要です。これを「チーム自ら」行えるかどうかがポイントです。一方で定義のない、あるいは借り物の定義に基づいた品質追求は、確実にチームを疲弊させます。

権限のないチーム、あるいは「託されていない」チームが品質を上乗せできる可能性はゼロです。品質が理由のちゃぶ台返しをイテレーションと勘違いしてはいけません。イテレーションの本質は、早期の検証と再学習です。転んでもすぐに起き上がれるそれまでの鍛錬と自律性とがあってこそ、生産的なイテレーションが成り立ちます。

おわりに

私は「管理」という言葉に忌避感を覚える世代なので、プロジェクトマネジメントがプロジェクト管理と訳されると違和感を覚え、私の反抗心はそれをプロジェクト監視と呼んでいます。

そのため、マネジメントを心の中では「やりくり」と訳しつつ、プロジェクトマネージャーをはじめステークホルダーと会話をしています。ここ最近、より複雑化した状況におけるマネジメントを表すためには、実は良い訳語ではないかと思っています。