"Products not Projects" は、効果的なソフトウェアプロダクト組織を設計する重要なコンセプトだ。このコンセプトは、James LewisとMartin Fowlerによって2014年3月に公開された記事 "Microservices" の中で、マイクロサービスアーキテクチャスタイルに共通してみられる9つの特徴の1つとして抽出された。
その中心にあるのは、開発チームの組織化に関する2つのモデルの対比だ。すなわち、プロダクトに対してチームを組織化するか、プロジェクトに対して組織化するかという選択肢にある。その選択が、サービス品質とチームの思考に大きな違いを生み出す。そして、"Products not Projects" という名の通り、プロダクトモデルがより優れた解なのだと説く。
このコンセプトが適用可能な対象は、マイクロサービスアーキテクチャに限定されるものではないと考えている。ソフトウェアプロダクトをビジネスの中核として展開する組織であれば、アーキテクチャに関わらず試す価値のあるものだろう。
本稿ではこのような前提に基づき、"Products not Projects" について掘り下げてみようと思う。
- Model - プロジェクトモデルとプロダクトモデル
- Knowledges & Skills - ドメイン知識と技術スキルの方向性の違い
- Team Mentality - プロジェクト思考とプロダクト思考
- プロダクトモデル実践における落とし穴
- まとめ
Model - プロジェクトモデルとプロダクトモデル
プロダクトライフタイムに対するチームのカバレッジとの関係性
原文中に1度だけ出現する "lifetime" という単語。これこそ "Products not Projects" を紐解く鍵となる。プロジェクトモデル（project model）とプロダクトモデル（product model）では、ソフトウェアプロダクトのライフタイムに対するカバレッジに大きな違いがある。それぞれのモデルを特徴づける最大の要因こそ、そのカバレッジなのだ。
ソフトウェアプロダクトのライフタイムは、並走する2つの活動によって形作られ持続していく。その2つの活動こそが、開発と運用だ。2つのモデルのいずれにしても、開発されたソフトウェアプロダクトは、リリースと共に運用に移る。そしてまた次の開発が始まり、新しいバージョンが完成したらリリースされて運用に移行する。これが何度も繰り返されていく。
[Projects] 短命な開発体制
（前略） the aim is to deliver some piece of software which is then considered to be completed.
目的は、完成したとみなされるいくつかのソフトウェアをデリバリすることである。
プロジェクトモデルでは、1度の開発からリリースまでをプロジェクトと呼び、その遂行に対してチームが組織化される。開発が終えるか、リリースが終えればプロジェクトは終了し、チームは解散する。これが、ソフトウェアプロダクトのライフタイムに対するプロジェクトモデルのカバー範囲だ。1つのプロジェクトを、フェーズと呼ばれるいくつかのリリースに分けることもあるが、終わりがある組織であることには変わりはない。このような体制を「プロジェクトチーム（project team）」と呼ぶ。
プロジェクトの成果物であるソフトウェアプロダクトは、リリースと共に運用組織に引き継がれる。いわゆるdevとopsが分離している組織構造だ。運用フェーズに移ったソフトウェアプロダクトに対する小さな変更や不具合対応、緊急対応などのソフトウェア保守業務は、専任の保守メンバーが担うことになる。本番環境にアクセスできるのは、保守メンバーを含めた運用組織だけだ。
次のバージョンに向けた大きな開発は、新たなプロジェクトとしてプロジェクトチームが編成される。つまり、dev自体もプロジェクトごとに顔ぶれが変わるのだ。それは、プロジェクトごとにその性質に適した人材配置が行われることによるものだと言いたいところだが、実態はそうでもない。組織内では常に複数のプロジェクトが並走しているのが通常だろうから、「適した人材」のリソースが空いていることなど奇跡だ。だから、人的なリソース計画の都合によって、プロジェクトへのアサインが決定する。
チームのメンバー数も、プロジェクトの規模に応じて様々だ。
[Products] 安定した開発体制
それに対し、プロダクトモデルとはどのようなものなのか。次の引用文は、原文中でプロダクトモデルに関して述べられている箇所だ。
Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime.
マイクロサービス推進者たちはこのモデル（=プロジェクトモデル）を避ける傾向にあり、プロダクトのライフタイムすべてに渡ってチームがプロダクトを所有する考え方を好む。
これが、ソフトウェアプロダクトのライフタイムに対するプロダクトモデルのカバー範囲だ。
プロダクトモデルでは、ソフトウェアプロダクトのライフサイクル全てを通し、一貫してチームが責任を負う。チームはソフトウェアプロダクト自体が終わりを迎えることが無い限り解散することがなく、存続し続けることになる。このような体制を「プロダクトチーム（product team）」と呼ぶ。
プロダクトチームは、開発だけでなく運用も担う。devとopsが分離していない。もちろん、より低レイヤーに位置するインフラに関することは、専任のインフラ運用組織が担当する。しかし、本番環境上でソフトウェアプロダクトを動作させ、安定稼働させるのは、プロダクトチームの役割だ。そのために、インフラ運用組織が提供するセルフサービス化されたプラットフォームを活用し、リリースに必要な環境の構築、そこへのアプリケーションのデプロイをはじめ、運用、保守のすべてを行う。
このような運用・保守業務と並行し、プロダクトチームは次のバージョンのリリースに向けた開発も進める。そこで活躍するのはもちろん前回の開発と同じメンバーだ。ソフトウェアプロダクトの長いライフタイムの中でプロダクトチーム内の顔ぶれも少しずつかわっていくかもしれないが、基本的にメンバー構成が一度に大きく変わるようなことはなく、安定している。
その人数も、人が親密な関係を築ける認知的な上限であるダンバー数から、7人前後程度の少人数が良いとされている。この数字は、Jeff Bezosの「2枚のピザ」ルールにも当てはまる。
Knowledges & Skills - ドメイン知識と技術スキルの方向性の違い
フィードバックループとの関係性
"Products not Projects" というコンセプトは、Amazonの "you build, you run it" という考え方をヒントにしたものだ。それは、Amazon.comのCTOであるWerner Vogelsに対するこのインタビュー記事のことだろう。
Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
開発者に運用責任を与えることで、顧客と技術の両面においてサービス品質が大きく向上した。従来のモデルでは、開発と運用に隔てる壁までソフトウェアを持っていき、放り投げて忘れ去るものだった。しかしAmazonは違う。開発した人たちが運用も行う。この考えにより開発者は、ソフトウェアの日々の運用に接することになる。顧客とのこのフィードバックループはサービス品質の改善に不可欠だ。
Vogelsが「フィードバックループはサービス品質の改善に不可欠」と話しているように、本番環境で稼働し、顧客に使われるソフトウェアプロダクトからのフィードバックは、サービス品質と強く関係している。チームの実践的な技術スキルを高め、ビジネス、ユーザーに関するドメイン知識を深めさせるからだ。
[Projects] 様々なドメインに対する広い知識と技術面での即応性
Vogelsに対するインタビュー記事からの引用文にある「従来のモデル（traditional model）」とは、プロジェクトモデルのことだ。このモデルでは、本番稼働するソフトウェアプロダクトに対する顧客や保守・運用面からのフィードバックをチームが直接受け取ることができない。リリースすれば、プロジェクトチームは解散してしまうからだ。
プロジェクトモデルであっても、顧客やビジネス担当からの要求などで断続的に新たなプロジェクトが立ち上がる。それらが技術面での改善に向けられたものであることは稀だ。多くは、機能面での追加や改善だ。これによって顧客面でのサービス品質は断続的に改善されていくことになるが、それを実行するチームは要望に応えているだけだ。
その顔ぶれも毎回異なる。例え同じメンバーであったとしても、彼らはプロジェクトとプロジェクトの合間に他のソフトウェア開発プロジェクトに従事している。関わるソフトウェアシステムはそれぞれドメインも違えば抱える課題も異なる。そこで使われる技術も異なるだろう。プロジェクトチームに携わる開発者に求められるのは、様々なドメインに対する広い知識や、技術面での即応性だろう。
[Products] 担当するドメインに対する深い知識と実践的な技術スキル
プロダクトモデルはまさに「開発した人たちが運用も行う（You build it, you run it）」の実践に他ならない。安定したプロダクトチームが開発も運用も担うため、本番稼働するソフトウェアプロダクトからのフィードバックループを形成できる。そこで得られた知識をもってサービス品質を継続的に改善することが可能なのだ。
よく言われるように、開発者が自分たちで保守を担わなければ、その成果物たるソフトウェアに優れた保守性（maintainability）を期待することはできない。開発者は、理解容易性（understandability）や変更容易性（modifiability）の低いコードで苦しんでこそ保守性の高いコードを書こうとするようになり、そういうコードを書けるようになる。これもフィードバックループだ。
運用におけるログの大切さもそうだ。適切なログが吐かれていないばかりに緊急対応で苦労してこそ、ログ設計について考えるようになる。そして、システムを安定稼働させるにはどうすれば良いか、問題発生時にシステムを素早く復旧させるにはどうすれば良いか悩み、日々の運用の中で実践を続ける。
これらはいずれも技術面でのフィードバックによって積み重ねた知識と、身につけた実践的技術スキルによって改善されていくサービス品質である。一方でビジネスやユーザー体験に関するサービス品質の向上については、顧客からのフィードバックが重要であることは明らかだ。
ビジネス向け、コンシューマ向けのいずれであるかに関わらず、ソフトウェアプロダクトとは顧客課題、つまりはビジネスやユーザーが抱える何らかの課題に対するソリューションとして作りだされる。ソリューション足り得るかどうかは、実際に顧客がそれらを採用し、利用してくれるかどうか、その結果がどうであったかをみなければ分からない。そこから得られた顧客の声やアクセスログ等は、サービス品質向上に欠かせないフィードバックとなる。
ビジネスやユーザー、技術のいずれであれ、プロダクトモデルであればそれらのフィードバックをチームが受け止めることができる。そこから得た知識や経験が、プロセスやソフトウェアプロダクトの改善につながる。そしてまたフィードバックを得る。このように、プロダクトモデルは強力なフィードバックループを形成でき、プロダクトチームの実践的な技術スキルを高め、担当ドメインの知識を徐々に深めながら、ソフトウェアプロダクトを継続的に改善していくモデルなのだ。
Team Mentality - プロジェクト思考とプロダクト思考
[Projects] 納期・予算・要件の厳守
プロジェクトモデルのゴールは、約束した期日までに、約束した予算で、約束したソフトウェアをリリースすることだ。リリースされたアウトプットが顧客課題のソリューション足り得るかどうかは、最初に決めることであり、ソフトウェアが完成してから変更するものではない。約束通りに作り上げたソフトウェアが結果として十分なソリューションとならず、ビジネスやユーザーにとっての価値を生まなくても、それは必ずしもプロジェクトの責任とは言い切れない。彼らがコミットするのはあくまでも「約束した期日までに、約束した予算で、約束したソフトウェアをリリースする」ことだ。これを「プロジェクト思考（project mentality）」と言う。
もちろん、プロジェクトモデルであっても顧客課題のソリューション足り得ることを目指す。プロジェクトの初期段階において、分析と設計に時間をかけて要件を決めることでそれを担保するのだ。しかし、そうして机上で定義された要件に基づいて完成したソフトウェアプロダクトが、顧客が真に求めるものとなるかは怪しいところだ。Chaos Report 2015によれば、「納期、予算、要件（OnTime, OnBudget, and OnTarget）」という解像度で「成功（successful）」と判断されたプロジェクトは36%であるが、「納期、予算、満足（OnTime, OnBudget, with a satisfactory result）」だと7ポイント低下して29%となっている。
また、分析と設計に多大な時間をかけることは、リリースまでのリードタイムが長くなることも意味する。それに、このアプローチは網羅的な要件と仕様を生み出しやすく、開発スコープを肥大化させるのではないだろうか。プロジェクトサイズが大きいほどプロジェクトの成功率が下がることを、Chaos Reportの調査結果が示している点も見逃せない。サイズがSmallだと「成功（successful）」が61%であることに対し、Grandだと6%しかない。
多くのソフトウェアプロダクト開発が扱う問題領域は、クネビンフレームワーク（Cynefin framework）で言うところの「探索 - 把握 - 対応（probe - sense - respond）」の繰り返しを必要とする複雑（Complex）な領域に位置するのではないだろうか。プロジェクトモデルでのアプローチでは、この問題領域を「把握 - 分析 - 対応（sense - analyze - respond）」で解決する煩雑（Complicated）な領域として扱っている。ソフトウェアプロダクト開発というものを、不確実性は高いが、予測可能性が高く、分析によって問題や解決策が明らかになるものだと想定しているのかもしれない。
[Products] 継続的なソリューションの提供
プロダクトモデルは、チームの責任範囲がソフトウェアプロダクトのライフタイム全てに及ぶ。プロダクトチームは、その長い時間の流れの中で、日々の運用や保守を続けなければならない。その間、彼らは顧客や技術面でのフィードバックにさらされ続けることになる。継続的に顧客課題や技術面での問題に直面し、それらを解決するために開発を繰り返す。ソフトウェアプロダクトをより良いものへと漸進的に進化させ続けるのだ。プロダクトモデルにおけるチームは、ビジネスやユーザーにとっての価値に対してコミットしているということだ。これこそが「プロダクト思考（product mentality）」であり、それは次の引用に集約されている。
The product mentality, ties in with the linkage to business capabilities. Rather than looking at the software as a set of functionality to be completed, there is an on-going relationship where the question is how can software assist its users to enhance the business capability.
プロダクト思考は、ビジネス能力との結びつきに紐づく。作り上げようとする機能の集まりとしてソフトウェアを見るのではなく、ユーザーのビジネス能力を向上させるためにソフトウェアがどのように支援できるかという問題に対して、継続的な関係が存在する。
プロダクトモデルでは、プロジェクトモデルのように分析と設計に多くの時間をかけて網羅的な要件と仕様を定義する必要がない。それよりも、実際にリリースしてみる方が効率が良い。リリース後のフィードバックを経て更に改善することを前提に開発できるからだ。ソフトウェアプロダクト開発というものを、不確実性が高いだけでなく、予測可能性が低い対象としてみなしているのだ。つまり、そこで扱われる問題領域を複雑（Complex）な領域と位置づけ、反復的な「探索 - 把握 - 対応（probe - sense - respond）」というやり方を実践している。
このような開発スタイルであるから、プロダクトモデルでの1度の開発規模はプロジェクトモデルに比べて相対的に小さく、リリース頻度も高い。先述したChaos Reportの調査結果にあるように、開発規模が小さい（small）なら、高い成功率も期待できるのではないだろうか。
プロダクトモデル実践における落とし穴
このようにして2つのモデルを比較してみると、プロダクトモデルのより優れた面が理解できる。プロダクトモデルを実践すれば、頭を悩ます様々な問題が解決し、成功に向けてものごとが上手く動き出すように感じてしまうかもしれない。そうしてプロダクトモデルを始めてみると、しばらくして現実はそう甘くないと痛感することになるだろう。そこには様々な落とし穴があるからだ。
まず、チームが運用を担うということは、運用負荷が高いほど開発時間が削られてしまうということでもある。運用負荷を下げるためには、それを実現するための仕組みが必要であり、運用の自動化に向けた開発といった取り組みを進めなければならない。
構築やデプロイの自動化をはじめ、ビルドパイプラインの整備、データなどのバックアップ処理、ログ収集・可視化の仕組み、モニタリング環境の整備など、運用負荷を下げるためにやるべきことは、これらも含めて他にも色々と存在する。プロダクトチームは、専任のインフラ運用組織とも協力（DevOps）して仕組みを作り上げ、維持することになるだろう。
しかしプロダクトチームは、短期間で繰り返されるリリースの中で、開発業務に追われ、運用負荷を下げるためのタスクに取り組むことがなかなかできずにいることが多い。そのために、運用業務にも時間が取られ、開発業務に必要な時間がますます逼迫して、運用負荷を下げる試みに手が出ないという悪循環に陥ってしまう。時間の無い中での開発は、プロダクトコードの品質にも悪影響があるだろう。
プロダクトモデルはサービス品質を高めるはずだが、このような状況は逆にサービス品質の低下を招きかねない。すると、ソフトウェアシステムが頻繁にトラブルを起こし、その緊急対応に追われるようになる。開発者はその都度、仕掛中の開発の手を止めることになり、開発時間が削られるだけでなく、開発に集中することすらままならなくなる。
こういった事態を回避するヒントは、SRE（Site Reliability Engineering）の「50%ルール」だろう。運用業務に費やす時間を業務時間全体の50%以下にし、それを超過した場合は運用負荷を下げるタスクに費やすというものだ。プロダクトモデルにおけるチームでも、運用業務に費やす時間を計測し、20%といった閾値を設けると良いのではないだろうか。
プロダクトモデルを実践する上での落とし穴は他にもまだまだ存在する。その代表的な例を挙げる。
- 属人化による業務負荷の偏り：トラブル対応や問い合わせ対応といった運用業務は、特定個人に集中しやすい。それが、チーム内の業務負荷を偏らせる。さらに、この状況が長く続くと属人化を生み、業務負荷の平準化を困難にするとともにリスクにもなる。退職などでチームがその個人に頼ることができない状況に陥ると、途端に業務がまわらなくなるからだ。
- 価値観の固定化：流動性の低い安定したチームは、チーム内での価値観が固定化しやすく、新しい価値を生み出しにくくなる体制でもある。チームがそのような状態にあると、ソフトウェアプロダクトもチーム自身も進化の歩みが鈍化し、イノベーションを期待することなどできなくなる。安定したチームが良いと言っても、ある程度の流動性は必要だろう。
- 悪いコンフォートゾーン：長いあいだ同じ顔ぶれで仕事を続けると、相互信頼の醸成と共に、チーム内に甘えや妥協がはびこるようになる。私はこれを「悪いコンフォートゾーン」や「勘違いの心理的安全性」と呼んでいる。チームが成長するためには、コンフォートゾーンから抜け出し、勇気を持ってラーニングゾーンで挑戦を続けなければならない。
- プロダクト思考への不達：開発業務に追われている限り、チームがプロダクト思考を獲得することはない。約束した期日までに、約束した予算で、約束したソフトウェアをリリースすることにコミットするプロジェクト思考にとどまってしまう。なんとかリリースしたらそこで終わり。そのアウトプットのことは忘れ、次のリリースに集中する。だからフィードバックループが形成されないのだ。この状態に陥ることを回避することや、既に陥ってしまったチームの問題を解決することは最も難しい。
まとめ
プロダクトモデルは、ソフトウェアプロダクトのライフサイクル全てを通し、一貫してチームが責任を負う。その長い期間の中で、少人数で安定したプロダクトチームがその運用と繰り返される開発を担う。その体制とプロセスがフィードバックループを形成し、チームのドメイン知識を深め、実践的な技術スキルを高めながら、サービス品質の継続的な改善を可能にする。チームはソフトウェアプロダクト開発が扱う問題領域を複雑な領域と位置付け、不確実性が高いだけでなく、予測可能性が低い対象としてみなしている。これら全てがチームをプロダクト思考に導いていき、チームとソフトウェアプロダクトを、改善を超えた進化へと突き進める。これが "Products not Projects" というコンセプトだ。
このコンセプトにおけるプロダクトモデルは、プロダクト思考を伴ってこそビジネスの成功を引き寄せる。体制やプロセスを真似たところで、チームがプロダクト思考を獲得するわけではない。そこには様々な落とし穴がある。プロダクトモデルを真に実践するためには、チーム自身や彼らをサポートするマネージャーが強い意思を持ってプロダクト思考に近づけようとする努力が必要なのだ。その難易度は高いが、到達したその見返りは想像以上に大きいだろう。
