プロジェクトよりもプロダクトを優先

迅速な方向転換能力

以前は、IT/エンジニアリングが市場情報やフィードバックの受信後1年以内に対応できるように設定されていれば十分でした。「デジタル」が主流になるにつれて、もはやそうではなくなりました。オンライン小売の例を見てみましょう。大まかに言って、基本的なオンライン小売プラットフォームの機能は、カタログ、注文管理、支払い、フルフィルメントに分類できます。

プロジェクトモードでは、優先順位によって、注文管理、決済、フルフィルメントに影響を与えるアクティブなプロジェクトが存在する一方で、カタログ関連のプロジェクトが存在しない場合があります。この場合、市場やビジネスステークホルダーから予期せぬカタログ関連のフィードバックを受け取ったとしても、対応できるチームが準備されていない可能性があります。通常、新しいフィードバックは、ビジネスケースとプロジェクト承認プロセスを経て、人員配置の優先順位付けが行われます。アクティブなプロジェクトを一時停止してチームをカタログに再配置できたとしても、チームはカタログに不慣れなため、すぐに成果を上げることは難しいでしょう。

一方、プロダクトモードでは、カタログ、注文管理などに専任の長期的なチームがあり、常に新しいフィードバックに対応できます。新しい情報に対応するためにチームのキャパシティの一部を転換するには、チームのプロダクトオーナーとそのビジネス counterpart の決定のみが必要です。準備のできたチームを迅速に方向転換できる能力は、応答性を向上させるための最初の要素です。

エンドツーエンドのサイクルタイムの短縮

サイクルタイムは、応答性を測る一般的な指標です。全体的なサイクルタイムには、方向転換の時間と実行の時間が含まれます。ここでは、後者の要素について検討します。

ほとんどの企業のDevOpsイニシアチブは、「変更」と「運用」の組織間の分離をまったく変更しません。通常、両方の組織は、新しいツール、デプロイメントとインフラストラクチャの自動化を導入し、場合によっては「クラウド」も導入します。より頻繁で自動化された信頼性の高いデプロイメントなどのメリットを実現することもあります。

しかし、開発から集中型運用へのハンドオフが依然として存在するため、変更を配信するためのエンドツーエンドのサイクルタイムはそれほど変わりません。プロダクトモードのチームは、構築したものをデプロイおよび運用する際に、このハンドオフに悩まされることはありません。そのため、DevOps導入の潜在能力を最大限に発揮できます。アプリケーションレベルの運用と開発を同じ場所に配置することで、エンドツーエンドのイテレーションが向上し、開発者とサイト信頼性エンジニア間の理解が深まります。

プロダクトモードのチームは通常、セルフサービスの構築とデプロイのインフラストラクチャを提供し、データセンターを管理し、アプリケーションレベル以外のセキュリティを処理する、他の専門の運用チームに依存し続けることに注意してください。これらのチームは、ビジネス機能に合致していなくても、プロダクトモードで運用される場合があります。

真の反復開発能力

COOは、技術組織のコストについて不満を言うことがよくあります。しかし、根本原因が技術以外にあるため、最大の節約機会の1つを見逃しています。高額なプロジェクトは、実際のメリットを検証するための効果的なメカニズムなしに、一度に考案され、資金提供されます。これらのプロジェクトは、メリットの提供という点で、 regelmäßig 目標を達成できません。組織がメリット実現率（実際のメリット/予測メリット）を追跡する習慣があれば、ほとんどの場合、ショックを受けるでしょう。真の反復型開発プロセスは、低コストで失敗し、費用を節約できます。

反復型開発の概念はしばらく前から存在していますが、実際には、反復はほとんどの場合、スプリントの成果発表までしか行きません。ほとんどのスクラムチームは、スコープベースのスプリントのコミットメントに縛られており、問題を解決するのではなく、計画どおりにスコープを提供することが期待されています。問題を反復的に解決するには、チームはソリューションの以前のバージョンのフィードバック（使用状況分析、ユーザー調査、ステークホルダーの証言）に対応できる必要があります。安定していて長期にわたるプロダクトモードのチームは、真に反復的な方法で問題を解決することを選択できます。

プロジェクトチームは、2つの理由から、スコープの提供から簡単に抜け出すことができません。第一に、彼らは通常、ソリューションを「構築」することのみを目的としており、実行することではありません。そのため、1つ以上のリリースでソリューションのバージョンを構築し、「運用」組織のチームに引き渡し、次のプロジェクトに移ります。第二に、プロジェクトの資金調達の仕組みでは、対処している根本的な問題の寿命よりもはるかに短い期間、チームを維持するための資金が提供されます。

例：退職金計算ツール

たとえば、金融サービス会社では、見込み顧客に退職商品を購入したり、既存のプランの拠出を改善したりすることを促す退職計算機を開発するプロジェクトが承認されました。プロジェクトチームは、計算機を構築するために必要な時間のみの資金が提供され、退職商品の利用を改善するという根本的な問題に対処するための資金は提供されませんでした。別のチームが会社のWebサイトに計算機を埋め込み、3番目のチームが必要なデジタルキャンペーンを設定して、計算機へのトラフィックを促進します。少なくとも3人の異なるマネージャー（スーパーバイザー）が、構築する内容を指定した後、またはせいぜい1日間の開始/温室に参加した後に、ビジネスステークホルダーと一定の距離を置いて作業の完了を綿密に追跡します。提供されたソリューションが市場で目標を達成できなかった場合、改善されたソリューションを見つけるために、別の資金調達と人員配置のラウンドを待たなければなりません。

コンバージョン率の1％増加あたりのコストと時間の点で、プロダクトモードの設定は、プロジェクトモードの設定よりもおそらく有利です。特定の組織でこれを確実に検証する唯一の方法は、いくつかの問題に対してプロダクトモードを試して、結果を評価することです。

知識の保持

ソフトウェアの真実は、ドキュメント、ハンドオーバー、知識の伝達をどれだけ行っても、チームの100％の離職を補うことはできないということです。しかし、これはまさにプロジェクトモデルがもたらすものです。技術的能力は、成熟度モデル、プロセステンプレート、ドキュメント、コード、またはインフラストラクチャには存在しません. チームの中に存在し、成長します.

知識は、同じ分野で数年間働く、安定した長期的なチームの中で、よりよく成長し、維持されます。これは、数か月ごとに立ち上げと停止を繰り返すプロジェクトチームとは対照的です。*保守できないコードは、少なくとも部分的には、保守されていないチームから生じます。*

ドキュメントは有用で必要ですが、「包括的なドキュメントよりも動作するソフトウェア」を好む組織では、プロダクトモードチーム内で発生する知識の保持の代わりにはなりません。

プロダクトモードチームでは、チームメンバーは、一般的なプロジェクト期間よりもはるかに長い期間、特定の領域（ビジネスに合わせた機能）に集中できます。これは、知識の構築、問題とトレードオフの理解の向上、ビジネスSMEおよびステークホルダーとの相互作用の質の向上に役立ちます。

チームメンバーが退職すると、プロダクトモードチームは知識を失うのでしょうか？スコープ全体の集合的所有権に基づいて作業している場合は、そうではありません。チームメンバーが個別に異なる機能またはサブ領域を所有している場合、知識の保持は危険にさらされます。

アーキテクチャの整合性

プロジェクトモードにおけるインセンティブは、チームに（しばしば認識されている）短期的な機能提供を優先させ、中期的なアーキテクチャの整合性を軽視するよう圧力をかけます。チームはそのトレードオフの結果に直面しないため、長期的なオーナーシップが存在する場合に現れるフィードバックループから利益を得ることができません。プロジェクトチームは、エンタープライズアーキテクチャガイドラインを認識していないか、単にタイムリーなプロジェクト delivery を追求するためにそれらを無視することによって、アーキテクチャ負債に（意図せずに）貢献することが知られています。中期的に、この現象はシステムの安定性を損ない、 delivery の速度を低下させます。いくつかの例を挙げます。

• 彼らは、今後の後継システムとの統合に多大な労力を費やす代わりに、廃止予定のシステムとの統合に低労力で取り組む可能性があります。これは、廃止ロードマップを損ない、類似した機能を持つ複数のシステムを持つアプリケーションランドスケープの保守コストを増加させます。
• 彼らは、APIを介して機能を公開した後に統合する代わりに、ダウンストリームシステムと直接データベース統合を実行してしまう可能性があります。これは、データベーススキーマの破壊的な変更を必要とするダウンストリームシステムの進化を阻害します。

一方、プロダクトモードチームは、自分たちが所有するシステムに他のチームが不適切に統合することを許しません。なぜなら、彼らはその結果をより深く認識しているからです。これは、「構築+運用」チームがシステムを所有することの利点であり、運用のみのチームがシステムを所有するプロジェクトモードとは対照的です。

コードとシステムの所有権

コードとシステムのチームレベルのオーナーシップは、チームが ideate-build-run モードで運用する能力を大きく向上させます。オーナーシップにより、チームはシステムをより迅速かつ制御された方法で進化させることができます。しかし、集合的オーナーシップの理想についてはどうでしょうか？個々のオーナーシップの代替案は問題があるため、チーム内で集合的オーナーシップを目指すべきです。しかし、チーム間では、オーナーシップの明確な境界設定により、説明責任のある autonomy が可能になります。

内部オープンソースモデルは、最先端のテクノロジー企業の一部で使用されています。どのチームの誰でも、管理者（オープンソースプロジェクトのコアコミッターチームと同様）チームにプルリクエストを送信することにより、ほぼすべてのコード領域への変更を提案できます。

このモデルはチームレベルのオーナーシップと共存できますが、依存チームが必要な変更をセルフサービスで行うというデフォルトの期待を生み出す傾向があります。これはオープンソースプロジェクトでは一般的な期待ですが（「バグを見つけましたか？素晴らしい。修正を送信してください。」）、ほとんどの主流のエンタープライズデジタル/エンジニアリング/ IT部門では非現実的です。一つには、異種システムを効果的に変更するためのドメイン知識のレベルがほとんどありません。その上、すべてのコードをセルフサービス可能なレベルのドキュメント、ビルド（チェックアウトしてビルドするだけ）、およびテストの準備状態で維持する必要があります。これは、ほとんどの組織にとって高いハードルです。これは、内部オープンソースイニシアチブが、それを試みたほとんどの主流企業で失敗した理由の1つです。このような組織にとって、デフォルトの期待をセルフサービスではなく、交渉された依存関係としておくことが現実的です。デフォルトでは、変更は所有チームと合意し、優先順位を付け、 delivery する必要があります。

チームのモチベーションとダイナミクス

チームは、ユニットとして効果的に連携するために時間をかけます。タックマンのグループ開発理論は、チームがパフォーマンス段階でその溝を見つける前に、一連の最適ではない段階（形成、 storming 、および規範化）を経ると主張しています。人員配置のプロジェクトモデルは、チームが規範化または実行段階に入るとすぐにチームを解散させるリスクがあります。安定していて寿命の長いプロダクトモードチームは、長い実行段階の恩恵を受けることができます。

研究では、 autonomy 、習熟、目的、および所属が重要な内的動機付け要因として特定されています。プロダクトモードチームは、典型的なスコープ delivery プロジェクトチームよりも大きな autonomy と目的を持っている傾向があります。したがって、プロダクトモードチームの導入は、経営陣が新しい normal に適応するのに時間がかかるとしても、通常は部隊から歓迎されます。

フローと反復の経済性

製品開発において、私たちの最大の無駄は非生産的なエンジニアではなく、プロセス queue でアイドル状態になっている作業成果物です。

--ドナルドG.ライナーツェン

これまでの議論は、従来のITの知恵とは反対のように聞こえるかもしれません。しかし、ビジネスの状況は、スマートフォンが市場に出た頃から劇的に変化しています。 IT /エンジニアリングをコストセンターとして扱うことは決して賢明ではありませんでしたが、今では擁護できません。コスト効率を最優先に考えてITを管理することは、これまで以上に逆効果でした。鈍いバックエンドITの上に高速の「デジタル」フロントエンド組織を作成するだけでは十分ではありません。バイモーダル/ツースピードITは誤った前提に基づいており、その加害者はそれを認め始めています。

従来のITの知恵は、いくつかの面で時代遅れです。そのような分野の1つは、ITスペシャリストの活用を最大化するために、規模の経済に合わせてITチームを編成するという norm です。ある意味で、プロジェクトベースの運用モデルは、1つは一時的な変更チームの使用、2つ目は設計、テスト、展開などのための共有サービスの使用によって、この norm を反映しています。一方、フローと反復の経済は、応答性の目標にとってより重要です。

規模の経済は、処理の規模の増加に伴い処理の単位コストが削減されるときに発生します。一方、フローの経済は、処理の単位時間（バッチサイズ1のエンドツーエンドのサイクルタイム–シングルピースフロー）が処理のフローの改善に伴い減少するときに発生します。多くの共有サービスによってサポートされているビルドのみのプロジェクトチームは、規模の経済を実現するのに役立つかもしれませんが、 ideate-build-run プロダクトモードチームはフローの経済を実現するのに役立ちます。

同様に、反復の経済は、小さな変更で反復する能力の向上に伴い、ビジネス上の利益を達成するために必要な労力が削減されるときに発生します。ビルドのみのプロジェクトチームは、効果的に反復するには多すぎるハンドオフに悩まされています。その上、彼らは実際のフィードバックに基づく一連の反復を維持するのに十分な期間生きていません。プロダクトモードチームは、設計上、これらの欠点に悩まされることはありません。

スタッフの活用

一般的な懸念は次のとおりです。「プロダクトモードチームの仕事がなくなった場合はどうなりますか？」。チームがカタログやフルフィルメントなどの十分な大きな領域を担当している場合、これは決して起こりません。また、チームの規模は定期的に（たとえば、年に1回）見直され、変化する相対的な優先順位に合わせて調整されます。一部の場所では、従業員のコアチームと請負業者によるフレックストップアップのコアプラスフレックスモデルを使用しています。それでも、特定のビジネス機能領域に堅牢または十分に重要なロードマップがない場合は、次のレビューまで、隣接する機能に（コアチームとともに）折りたたまれます。

場合によっては、根本的な質問は次のとおりです。「私たち（PMOなど）が特定のチームの作業領域で何も優先順位付けしない場合はどうなりますか？」そして答えは、プロダクトモードチームは権限を与えられた半 autonomy 的なユニットであることを意図しているため、外部からの優先順位付けに完全に依存していないということです。部門横断的なイニシアチブのみが外部から優先順位付けされます。ロードマップの作業については、チームレベルのプロダクトオーナーは、ビジネスの利害関係者と協力して優先順位を付ける権限を与えられています。経験則として、3分の2のロードマップ作業と3分の1以下のイニシアチブ作業を目指してください。したがって、ポートフォリオ管理は、プロダクトモードで根本的に変化します。

機能横断型チームのさまざまな役割の活用はどうでしょうか？すべての異なる役割を忙しくしておくのに十分な仕事がない場合はどうなりますか？まあ、人々は自分のスキルに隣接する仕事を引き受けます。たとえば、ビジネスアナリストは探索的テストを実行したり、QAはドキュメントの改善を支援したりする可能性があります。当初は、最初のレベルのスキルを習得するために他の人をシャドーイングする必要があるかもしれませんが、すぐにスペシャリストから一般化するスペシャリストになります。

活用のトピックについて言えば、活用を最適化することはエンドツーエンドのサイクルタイムの短縮に有害であることに注意することが重要です。高速道路の交通の流れを改善するために、その活用率を向上させる（つまり、より多くの車両を導入する）ことはありません。活用に重点を置くことは、「コストセンターとしてのIT」という考え方の名残です。デジタルビジネスには場違いです。

孤立化

安定していて寿命の長いチームは、島国根性と一般的な停滞のレシピではないでしょうか？それはリスクですが、通常、技術チームには常にいくらかのチャーンがあり、これは新しい思考の注入を提供します。また、多くの組織は、顧客体験、A / Bテストなど、特定のコンピテンシーに合わせた非公式の内部ネットワークである実践コミュニティを後援し、チーム全体の人々を集めています。

新たなサイロ化

プロジェクトモードでは、製品管理、アーキテクチャ、設計、開発、テスト、運用、サポートなどのサイロが発生します。プロダクトモードでは、カタログ、注文管理、支払、フルフィルメントなど、ビジネス機能に合わせた新しいサイロになってしまうのでしょうか？おそらく、しかし、それらはアクティビティ指向のサイロほど悪くはありません。プロダクトモードチームは、成果指向であるため、最悪の場合でも、ビジネス成果に向けて取り組むサイロが発生する可能性があります。ビジネス機能に合わせたサイロは、製品開発バリューストリームの段階に合わせたサイロほど悪くはありません。

とはいえ、「問題の解決」などのサービスエクスペリエンス、または「注文から現金化」などのビジネスバリューストリームによって定義されたビジネスに合わせた機能境界に沿ってプロダクトモードチームを編成することにより、新しいサイロのリスクをある程度軽減できます。これが単一のチームにとって大きすぎる場合は、複数のチーム（Spotifyで普及したネーミングスキーマの観点から、トライブ内の分隊）にセグメント化しますが、それらを同じ場所に配置し、サービスエクスペリエンスチャンピオンまたはビジネスバリューストリームオーナーを任命して、セグメントレベルのプロダクトオーナーと協力するようにします。

対策として、複数のプロダクトモードチームにまたがるイニシアチブについては、プロダクトオーナーとビジネスの利害関係者と協力する、サイロを貫通する、優先順位を交渉する、依存関係を管理するソリューションチャンピオンを任命することをお勧めします。もう1つの良い習慣は、18か月から24か月など、長期間のスティントの後、チームを変更するオプションを人々に提供することです。

最終的に、プロダクトモードでのサイロ打破は、 autonomy とともに整合性を確保することです。昔ながらのアプローチは、 autonomy を犠牲にすることで整合性を実現します。代わりに、アラインメントマップなどの手法を使用して、両方の長所を最大限に活用します。

階層化されたチーム

前述のオンライン小売の例では、カタログ、注文管理、チェックアウト、フルフィルメントなどのプロダクトモードチームが提案されました。退職商品の例では、搭乗、登録、保存、引き出しなどのプロダクトモードチームが提案されました。これは、これらのチームがエンタープライズアプリケーションスタックに関してエンドツーエンドの責任を負っているかどうか、つまり、市場向けのフロントエンドシステムからバックオフィス機能をサポートするバックエンドシステム（下の図のティア3および4）までの質問を提起します。以下の理由により、答えは「常にではありません」。

図1：オンライン小売における階層化されたプロダクトモードチームの簡略化された例。

エンドツーエンドの責任は成果志向に役立ちますが、システムの形態を考えると現実的でない場合が多いです。例えば、オンライン小売プラットフォームは通常、少なくとも、顧客向けのウェブアプリとモバイルアプリ、サポート向けのコールセンターアプリ、店長向けの店舗管理アプリをフロントエンドとして備えています。通常、これらのフロントエンドシステムはそれぞれ、カタログ、注文管理、チェックアウト、フルフィルメントなどの基盤となる機能に独自の依存関係を持っています。通常、エンドツーエンドのカタログ（またはその他の機能）チームにとって、明確なフロントエンドシステムの境界はありません。例えば、ティア4の店舗管理アプリチームが、カタログなどの単一のティア3機能のみに依存している場合は、そのチームを回避できる可能性があります。図では、店舗管理がカタログ以外にも依存関係を持っていると想定しています。したがって、図のように、ティア3とティア4に別々のプロダクトモードチームを配置しています。上位ティアは下位ティアのコンシューマーです。

最近のトレンドは、フロントエンドシステムをティア3の機能に対応するマイクロフロントエンドに分解することです。これにより、ティア3とティア4にまたがるエンドツーエンドチームを編成しやすくなります。しかし、マイクロサービスに移行した/移行中のほとんどの企業は、まだマイクロフロントエンドへの移行を計画していません。

場合によっては、複数のティア2B機能をサポートするレガシーシステムが存在することで、ティア3チームが対応するスキルを持つティア2Bチームにも依存する状況が発生することがあります。理論的には、ティア2Bの人員を対応するティア3チームに組み込むことは可能です。しかし実際には、これは、ティア2Bの能力が不足していること、または共有構成管理、テスト環境などの実際的な課題によって制約される可能性があります。

ティア1とティア2Aは、継続的デリバリー、DevOps、リーン製品開発を実現するためのイネーブラーです。これらは、ビジネスドメイン全体に適用できます。例えば、パイプラインインフラストラクチャチームは、Jenkins/GoCD/TeamCity...インフラストラクチャの保守を担当します。彼らは、上位ティアチームのビルドの破損に対応する責任はありません。したがって、上位ティアは下位ティアに1つ以上の依存関係を持つ場合があります。ティアに関係なく、各チームは、安定した、長期的な、クロスファンクショナルな、成果志向の、ideate-build-runチームであるという意味で、プロダクトモードです。下位ティアチームは、上位ティアチームを（スコープデリバリーではなく）問題解決の観点から（社内）顧客として扱います。

スクワッドとトライブ

多くの場合、カタログのような単一の領域は単一のチームにとって大きすぎる可能性があり、それを複数のプロダクトモードチームに分割することは問題ありません。この場合、カタログトライブには複数のスクワッドがあり、それぞれに独自の成果、ロードマップ、および管理下のシステムがあります。この構造により、各スクワッドに組み込むのが難しい役割をローカルで（トライブ内で）共有することもできます。スクワッドは典型的なプロジェクトチームよりもはるかに長期間存続することを意図していますが、スクワッドメンバーは、知識の幅を広げ、単一障害点になることを避けるために、18〜24か月間隔でトライブ内で意図的にローテーションするように求められる場合があります。

しかし、プロダクトはどこにあるのか？

冒頭で述べた点を繰り返しますが、プロダクトモードで運用するために製品を構築する必要はありません。とはいえ、市場で販売されているものという製品の従来の定義を超えて考えると、カタログを製品であるかのように見ることが可能です。カタログのような機能がチームが所有するシステムのセットに含まれ、社内アプリケーションまたは十分に文書化されたAPIを介して公開されると、社内顧客に対応する、再利用可能でセルフサービスの、製品のような機能になります。同じことが下位ティアのプロダクトモードチームにも当てはまります。