プロジェクトという概念があなたを苦しめる

この文章でいいたいこと

ソフトウェア開発をしているあなたを苦しめるのはプロジェクトという概念である。あなたはプロジェクトという概念を信仰している。その信仰を捨てることで苦しみから開放される。

プロジェクトマネージャ不要論

自分がこの結論に至ったのは「プロジェクトマネージャっているの？」という疑問が発端である。「プロジェクトマネージャが不要とか頭おかしいんじゃないか？」と思う人もいるかもしれないが、自分は情報処理技術者試験のプロジェクトマネージャに合格する程度にはプロジェクトマネジメントは勉強しているし、PMBOKも全部読んでいる。またマネジメントは必要だと思っている。

なぜそう思うのか？という根拠だが、自分が色々なプロジェクトに参画した結果至った結論は「プロジェクトマネジメントできるスキルのある人がいない」である。東証225企業から二次請けソフトウェアベンダーまで色々な現場で働いたが、本当にいない。PMBOKを全部読んだことがある人ってだけでも相当レアである。EVMでプロジェクト管理しているのも自分以外にみたことがない。恐らく二次受けより下層のソフトウェアベンダーでプロジェクトマネジメントできる人材を採用するのは不可能ではないか。

また、現実のプロジェクトでは恐ろしいほどプロジェクトマネージャに権限がない。自分が見た範囲では予算に権限があるプロジェクトマネージャはおらず、調整すらも許されない。権限がないのにプロジェクトマネージャにプロジェクトをどうこうすることはできるのか。

自分は、存在しないし権限もないプロジェクトマネージャを前提にするより、プロジェクトマネージャがいなくてもよい開発組織デザインをすべきという結論に至った。

プロジェクトマネージャがいない世界

プロジェクトという概念を信仰しているあなたは「そこまで言うなら、プロジェクトマネージャが不要としてどうやって開発するんだ？」と思うだろう。

プロジェクトマネージャが存在しないマネジメントの手法としてはアジャイル開発があるが、自分はこれに拘る必要はないと思う。WBSのメンテナンスなんて本来管理職の人間がやる仕事ではないし、PMOでも作ってそこの作業者にさせておけば良い。プロジェクトマネージャを解体し、プロジェクトの管理機能を開発チームに移譲し、本来のプロジェクトに対する権限がある人間がマネジメント（≠プロジェクトマネジメント）すれば良い。

個人的な意見では存在しないスーパーマンのプロジェクトマネージャを期待するより、開発チームの組織力を向上させるほうが圧倒的に現実的な解だと思う。チームの組織力とは何か？であるが個人レベルにブレイクダウンすると以下のようなものがある。

• 自発性
• 協調性
• セルフマネジメント
• 高い開発能力

これらはチームを成長させることで現実として得られる能力である。そこに低スキルなエンジニアでもできるような管理方法を目指すべきという思想はない。

プロジェクト型からベストエフォート型に

プロジェクトマネージャがいなくなって平和な世界が訪れた、とはいかない。もっと悪いやつがいる。プロジェクトマネージャという概念は「奴」から生まれた。それは「プロジェクト」である。あなたは「ソフトウェア開発はプロジェクトでなされるべき」という信仰を持っていないか。これを捨てることであなたは苦しみから開放される。

ここからプロジェクトではないソフトウェア開発の話をするが、「あー言われてみればうちのプロジェクト、本当はプロジェクトじゃないわ」と感じる人が多いと思う。この本来はプロジェクトではないソフトウェア開発にプロジェクトという概念を当てはめることが苦しみの原因である。実はプロジェクトを捨てることができるソフトウェア開発は多い。

ここでPMBOKの「プロジェクト」という言葉の定義を引用してみよう。

「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」
（https://ja.wikipedia.org/wiki/プロジェクト#PMI.E3.81.AEPMBOK）

実は最近、Web業界などをはじめソフトウェア開発は変容している。PMBOKの定義に当てはまるソフトウェア開発が減っているのだ。あなたの開発しているソフトウェア、本当に有期性があるのか？最近ではソフトウェアは業務の一部であり、業務が続く限りソフトウェアは改良され、運用されていく。そして企業の業務活動に終わりがない。あなたが普段使っているWebサービスに開発の終了はあるのか？

こうした業務、プロダクトと一体化したソフトウェア開発を無理やりプロジェクト型の開発で進めていくのは弊害が多い。プロジェクトでは予算とスコープがあり、システムの提供する価値よりそちらのほうが優先される。また、開発ごとに要員が集められ、開発が終わると解散されるプロジェクト型では業務、プロダクトに対する知見が揮発する。これは非常に都合が悪い。こういう人を集めて開発するスタイルの弊害はソフトウェアエンジニアであればトラウマになるほど感じている。そういうのはやめたくないか。

そこでプロジェクト型に変わりベストエフォート型の開発にするのはどうだろうか。ベストエフォート型では「いる人」「ある予算」で開発を行う。身の丈に合わない大規模なソフトウェア開発をあきらめ、あるリソースで一番価値のある機能を開発する。

この開発ではエンドユーザにとっては財務状況にあったシステム開発ができるように予算を圧縮するし、ソフトウェア開発者にとっては無理な納期の開発をねじ込まれることがない。大体、人間できること以上のことはできないのでベストエフォート以上に成果を上げる方法はない。これでもプロジェクト型の開発より成果は上がる。

こうなると後はいかにソフトウェア開発者に快適にベストエフォートで開発してもらえるかにみんながフォーカスすることになる。不快なブラック労働とはおさらば。

業務セントリックもしくはプロダクトセントリック

ベストエフォート型の開発にするにあたり中心に据えるのは「業務」や「プロダクト」である。

ベストエフォート型の業務セントリックのソフトウェア開発はすでに業務そのものである。その世界観では通常の業務を行うのとソフトウェア開発では境界がない。単に経理の担当者がEXCELのVBAマクロを作成するのが大規模化しただけである。通常の業務の一部としてソフトウェア開発が行われる。この世界観ではエンドユーザ企業が多くのソフトウェアエンジニアを雇用し、それに加えて一部のソフトウェアベンダーが参入する欧米型のソフトウェア開発に近づく。

ベストエフォート型のプロダクトセントリックなソフトウェア開発は最近増えている。わかり易い例ではSNSではよく「自社開発系Web会社」と言われるの会社の仕事がそうである。例えばAmazonのAWSを例に挙げる。AWSの開発に有期性はあるだろうか？プロダクトの価値を高める開発が常に終わりなく続けられる。AWSの開発が終わるのはAWSのプロダクトが終了するときである。この開発ではプロダクトの価値にすべてがフォーカスされる。自社開発系Web会社とは例には言ったものの、実はジャパニーズトラディショナルカンパニーにもこういうプロダクトが多く、なぜかプロジェクト型の開発がされていてその度に要員が集められ、解散させられている。

既存の古いタイプのソフトウェア開発に従事しているソフトウェア開発者も実質的にはベストエフォート型の開発のほうが望ましいのに、プロジェクト型で運営されていることは非常に多い。これらのソフトウェア開発は必ずしもモダンなものではなく、単に今のソフトウェア開発の歪みとして現れている。ここまで読んで「あー俺の開発、業務セントリックだわ」「俺はプロダクトセントリックだわ」と思った人も多いのではないか。

結局、大事なのは「業務」「プロダクト」であって「プロジェクト」ではない。はい、プロジェクトがなくなればみんなの苦しみはいくらかなくなるでしょ？