ソフトウェアプロダクトの機能追加・機能改善をプロジェクト体制で進めるのはもうやめよう
ソフトウェアプロダクトをビジネスの中心に据える企業にとって、プロダクトの競争力を高めることは、一番の関心事です。だからこそ、プロダクトをより顧客価値の高いものに磨き上げようと、アップデートを繰り返すことに腐心する。
しかし、残念なことに、魅力的なプロダクトというものは、すぐに競合他社に真似されてしまいます。一度獲得した優位性を、長期間持続することは難しい。むしろ、競争優位性など一時的であることが普通だと考えた方が良い気さえします。
だからこそ、「プロダクトの競争力を高めること」と同時に、「プロダクト開発能力の競争力を高めること」が重要だと、私は考えています。魅力的なプロダクトを作ることに再現性があり、それを短期間で実現できる強い開発組織を作り上げるということです。競合他社も、プロダクトを真似することは簡単にできても、開発能力を真似することはさすがに難しいはず。
プロダクト開発に実行責任を持つチーム体制としては主に2種類、「プロジェクトチーム」と「プロダクトチーム」が考えられます。どちらの体制でも、プロダクトを磨いていくことはできると思いますが、プロダクト開発能力を高めていくという視点では、プロダクトチームに軍配が上がると考えています。
では、プロジェクトチームの何が一体、問題なのでしょうか。チーム編成、チームビルディング、経験学習効果、フィードバックループという4つの観点で見ていきたいと思います。
チーム編成に対する問題点
チームを編成する時、そのチームを率いるリーダーやマネージャーが望むことは、優秀な人材がアサインされることです。誰が入るのか、どのような能力を持った人が参加するのかで、チームのパフォーマンスが大きく変わるからです。
プロジェクトチーム制を採用する組織では、新たな機能追加や機能改善のたびにプロジェクトを立ち上げます。そして、プロジェクトの性質に応じて最適な人員を配置する……とまあ、そうできれば良いのですが、現実的にはそうはいきません。いくつものプロジェクトが並走している中で、手が空いている人などいないからです。悲しいことに、優秀なエンジニアほど忙しい。新たに立ち上げるプロジェクトでは、その時に残っている人をかき集めるしかありません。
とはいえ、最低限の開発能力がチームに備わっていなければ、プロジェクトが成立しません。だから、優秀な人材が、複数のプロジェクトを掛け持ちすることになります。掛け持ちだから、そのリソース計画をめぐって、プロジェクト間での複雑な調整が頻発します（参考記事『兼務はチームの独立性とのトレードオフ』）。
このような状態で、プロジェクトチームがパフォーマンスを発揮できるとは考え難い。
プロダクトチームは、5名から9名程度のメンバーが固定で配置された体制です。プロダクトの規模に応じて、複数のチームが作られ、並走します。プロジェクトチームとは違い、都度編成するわけではないため、あらかじめ、各チームの能力バランスがとられた形で編成されます。それゆえに、極端に弱いチームにはなりにくいと言えます。
プロダクトチームでは、メンバーが複数のチームを兼務しません。もちろん、チーム内で複数の機能開発が並走すると、リソースやスケジュールの調整が必要となりますが、チーム内での調整であるからまだコストが安くすみます。
チームビルディングに対する問題点
タックマンモデルにあるように、立ち上がったばかりのチームより、様々な対立や混乱を乗り越えてきたチームの方が、高いパフォーマンスを出します。このチームビルディングという観点でプロジェクトチームとプロダクトチームを比較してみると、どのような差が見えてくるのでしょうか。
プロジェクトチームは、プロジェクトが終了したら解散します。チームの存在期間は長くはありません。その限られた期間の中で、最高のチームを作り上げようとする過度な努力は逆に、オーバーヘッドになりかねません。
そもそも、期間が短かすぎてチームが機能期（performing）を迎える前にプロジェクトが終了してしまう。プロジェクトチームの持つポテンシャルを最大限に引き出すことは難しそうです。
プロジェクトチームはそういった背景から必然的に、プロジェクトマネージャーが事細かに指示・管理し、メンバーが受け身的なチームになりやすいのです。
一方のプロダクトチームには、終わりがありません。長く続くプロダクト開発という活動の中でチームビルディングが進んでいきます。
もちろん、はじめはリーダーがあれこれと世話をやかなければ機能しないかもしれませんが、長いチーム活動の中で、チームメンバーはそれぞれ自身の役割を見出していきます。気が付けばチームは、お互いを補い合い、自律行動する組織に変わっている。リーダーが主導する受け身なチームではなく、自己組織化された「考えるチーム」として成長しやすいと言えます。
経験学習効果に対する問題点
組織は、プロセスと呼ばれるアルゴリズムで動いています。プロセスの出来が良いほど、組織は高いパフォーマンスを出すことができます。だからこそ、実行によって得られた成功体験・失敗体験をもとにプロセスを改良し、最適化していく活動は、ビジネスの成功と密接に関係します。
プロジェクトのスコープには通常、開発プロセスの改善は含まれません。プロジェクトはあくまでも、開発プロセスを通してアウトプットされる機能追加や機能改善にコミットしているだけです。
プロジェクトの終了時にプロジェクトメンバーが集まって「振り返り」を実施することはあると思いますが、それをもって解散する体制で行われた振り返りが、次のプロジェクトにどこまで引き継がれるのか、どこまで効果を発揮するかは、期待しすぎない方が良いかもしれません。
プロダクトチームは、固定のメンバーが開発からリリースまでのサイクルを絶え間なく繰り返します。そしてその一度のサイクルごとに振り返りが行れます。これが経験学習となり、開発プロセスに高い改善効果を生み出します。
フィードバックループに対する問題点
ソフトウェアプロダクトの保守・運用は、日々、フィードバックに溢れています。綿密に企画・設計した機能であっても、それが想定通りユーザーに受け入れられるか、想定通り動作し続けられるかは、リリースしてみなければ分かりません。実際の本番環境で稼働し、様々なデバイスで使われ、様々な状況下で、様々なユーザーに、様々な使われ方をすることによって、良いところ、悪いところが浮き彫りになります。
プロジェクトは、計画された機能を開発し、リリースしたら終了です。チームはそこで解散となるため、プロダクトの保守・運用は、プロジェクトのスコープには入りません。だから、プロジェクト体制を敷く組織では、保守・運用を専任とするチームを置くことになります。これはつまり、開発と保守・運用が分離された体制です。
開発と保守・運用を分離した体制は、このような貴重なフィードバックがプロダクトに活かされることを阻害する障壁になってしまいます。保守・運用チームは、プロジェクトに加わっていないため、プロジェクトチームほどには企画・設計を深く理解していません。その状態で、フィードバックから深い気付きを得られるはずもありません。その上さらに、分離された体制が、知見の流通をせき止めます。
プロダクトチームは、自分たちで開発し、自分たちで保守・運用します。だから、フィードバックループをまわすことへの障壁はありません。保守・運用によって得られる貴重なフィードバックから学習し、プロダクトの改善を続けることができます。つまり、プロダクトチームは、「学習する組織」なのです。
音楽ストリーミングサービスで有名な企業である Spotify もチームを学習する組織として位置付けています（「『ユニコーン企業のひみつ』という組織論」参照）。
最後に
馴染みのやり方を、何も考えずにずっと続けてしまっていることって多いですよね。でも自分自身ではそれに気付いていない。そうしている間にも世界は進化し続けていて、新しいやり方や、より進化したやり方が生まれている。自分が長い時間をかけて熟達したはずのやり方は、すでに周囲より相対的にパフォーマンスの悪いやり方になってしまっている。
かつて、ソフトウェアプロダクトは、パッケージ販売されることが主流であり、そこではプロジェクト型の開発体制が適していました。多くの消費者、多くの企業に買ってもらうことが重要であり、発売日に向け、長い時間をかけて計画的に機能を作り込み、限界まで品質を向上させることが注力すべきことだったからです。
しかし今やソフトウェアプロダクトはサービスとなりました。売って終わりではなく、サブスクリプションモデルに代表されるように、長く使ってもらうことが収益を生み出すようなビジネスモデルが主流となっています。そのために、日々、プロダクトのアップデートを繰り返し、そのサイクルはますます短く、高頻度になっています。
このようなビジネスモデルの移り変わりの中で、最適なプロダクト開発体制がどういうものであるか、それも移り変わっていったのだと思います。
この記事が気に入ったらサポートをしてみませんか？