この前同僚とプロジェクトって言葉があまり好きじゃないね、みたいな会話をしており、自分的になぜそう思うのか考えてみる。

コンテキストとしては、主に事業会社におけるソフトウェア開発を前提にする。

一般的に事業会社では、ユーザーに価値を届け続けるために、日々多くの機能開発や改善を行っている。その中で、特定の目的を達成するためにチームが組成されることは珍しくない。

しかし、その集まりを安易に「プロジェクト」と呼ぶことには、いくつかの構造的な課題が潜んでいると考えている。

「プロジェクト」という言葉が内包する課題

そもそも「プロジェクト」とは何を指すのであろうか。プロジェクトマネジメントの知識体系であるPMBOKでは、以下のように定義されている。

独自のプロダクト、サービス、または所産を創造するために実施される、有期性の業務

この有期性という性質こそが、最も懸念している点である。期間が定められているからこそ、いくつかの根深い問題を引き起こす傾向がある。

1. 長期的なオーナーシップの欠如

「プロジェクト」という名前がついた活動は、その定義上、始まりと終わりが存在する。メンバーは特定の目的のために期間限定で集められ、目的を達成すれば解散することが前提となる。

この構造は、メンバーの意識を「リリースまで」に限定させてしまうリスクを伴う。もし、ある機能が無事にリリースされ、プロジェクトが役割を終えて解散することが決まっている場合、そのプロダクトの将来的なメンテナンス性や運用負荷、ユーザーからのフィードバックを受けて改善し続けるといった、長期的な視点で物事を考えるインセンティブは働きにくくなる。

結果として、「作ること」自体が目的化し、リリース後のプロダクトの価値を最大化し続けるという、事業会社にとって最も重要な活動への接続が断絶されがちである。プロダクトに対する継続的なオーナーシップが育まれにくい環境は、長期的に見てプロダクトの健全な成長を阻害する要因となり得る。

2. スコープの肥大化とリードタイムの増大

「プロジェクト」として期間や体制を先に定義してしまうと、その期間内におけるメンバーの稼働率を最大化しようという力学が自然と発生する。

「せっかくこの期間、このメンバーを確保したのだから」という思考は、本来の目的達成に必要不可欠ではない機能の追加や、優先度が相対的に低い要件の盛り込み、いわゆるスコープの肥大化を招きやすい。

当初は最小限の価値（Minimum Viable Product）を迅速にユーザーへ届ける計画だったはずが、プロジェクトという枠組みの中で、いつの間にか「すべてを完璧に作り切ること」が目的となり、結果としてリリースまでのリードタイムを不必要に長期化させてしまう。

これは、スコープやビジョン、優先順位が固定化され、市場やユーザーの変化に柔軟に対応しにくいという、ウォーターフォール的な開発モデルの課題にも通じる。

3. 優先順位の形骸化

スコープの肥大化と密接に関連するのが、優先順位付けの先送りである。プロジェクトという大きな枠組みの中では、本来厳密に行われるべき個々の機能に対する優先順位の議論が曖昧なまま、開発が進行してしまうリスクがある。

例えば、AとBという2つの機能を作る計画があったとする。計画当初は、両方とも「優先度：高」と定義されていたかもしれない。しかし、もし開発終盤になって「どちらか一つしかリリースできない」という状況に追い込まれた時、そこで初めて「本当に価値が高いのはどちらか？」という真の優先順位が問われることになる。

これは、「プロジェクト期間内にすべて作る」という前提が、本来向き合うべき価値の議論を覆い隠してしまう典型的なケースである。長期的なスケジュールと確保されたリソースが、真の優先順位を見極める機会を奪い、結果的に価値の低い機能の開発にリソースを割いてしまう事態を招く。

「プロジェクト」が有効なケース

もちろん、「プロジェクト」という進め方を完全に否定しているわけではない。明確なゴールと期限が定められた、リリースそのものが目的となる場合には、非常に有効なアプローチである。

例えば、クライアントから依頼を受けてシステムを開発する受託開発の文脈では、納品することに責任を持つ。納品後の運用責任とは明確に切り離されているため、短期集中でリソースを投下し、計画通りに完遂させる「プロジェクト」型の進行は理にかなっている。

目指すべき姿

では、我々はどうあるべきだろう。

それは、短期的な成果を目的とする「プロジェクト」の集まりではなく、プロダクトや特定のドメインに対して継続的に責任を持つ「チーム」として存在することだと考える。

チームは、リリースをゴールではなく、ユーザーに価値を届けるためのスタートラインと捉える。自らが開発した機能のパフォーマンスを監視し、ユーザーの声に耳を傾け、得られた学びをもとに次の改善サイクルを回していく。この継続的なプロセスこそが、プロダクトを真に成長させると考える。

このようなチームは、期間で区切られるのではなく、プロダクトのライフサイクルと共に存在し続ける。それにより、メンバー一人ひとりがプロダクトの成功に長期的なオーナーシップを持ち、自律的に価値創造に取り組む文化が育まれていく。

また上述したスコープの肥大化&長期化に関して、常に注意する必要がある。プロジェクトと銘打つことで、多くのスコープ、期間の長期化、優先順位の形骸化が許容されてしまう構造に注目し、安易にプロジェクト化させない工夫が必要である。

そのためには、スプリントプランニングをはじめとした様々なフレームワークを取り入れるのも良いだろう。

さいごに

「プロジェクト」という言葉には、ビジネス上、関係者に計画を説明しやすく、進捗を評価しやすいというメリットがあることも事実である。第三者から見ても、機能がリリースされたかどうかは明確に判断できる客観的な指標である。
しかし、その「分かりやすさ」の裏で、プロダクトの本質的な価値向上を妨げる構造が生まれていないか、常に自問する必要がある。

単発の花火を打ち上げる「プロジェクト」ではなく、プロダクトと共に成長し続ける息の長い「チーム」でありたいものですね