DevOps のリーン製品の詳細

  • 6 分

『Design Sprint: A Practical Guidebook for Building Great Digital Products (デザイン スプリント: 優れたデジタル製品を構築するための実践ガイド)』と『Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams (製品のリーダーシップ: 優れた製品マネージャーが素晴らしい製品を立ち上げ、成功するチームを構築する方法)』の著者である Richard Banfield によると、優れた製品の企業には 4 つの共通点があります。

  • 市場投入までのスピード
  • 変化に直面したときの機敏性
  • デジタル ビジネスへの移行
  • 顧客満足度

製品中心のモデルを採用する理由

製品管理プラクティスの恩恵を受けるデジタル ビジネス リーダーは、2018 年には既に 3 分の 1 に達していましたが、2024 年までに 4 分の 3 を超える見込みです。

2024 年までに、IT 組織の 80% は、製品中心の運用モデルを採用するために、抜本的な再構築とミッションの変更を行う見込みです。

Gartner「A Day in the Life of a Digital Product Manager (デジタル製品マネージャーの日常)」(Deacon D.K Wan、2019 年 7 月 31 日 - ID G00400672)

図は、時間の経過に伴う製品中心のモデルの導入を示しています。全体で、回答者の 85% が製品中心のモデルを採用済みか採用予定だと回答しています。時間の経過に伴う完全な導入は回答者の 54% で発生し、部分的な導入は回答者の 32% で発生します。回答者の 15% が製品中心のモデルを完全に採用済みだと答えています。31% は今後 3 年以内に完全に採用すると予想しています。5% は今後 3 年から 5 年で製品中心のモデルを採用する予定です。3% は導入プロセスに 5 年以上かかると予想しています。回答者の 32% は製品中心のモデルをある程度使用することを予想していますが、完全にはこのモデルに移行しないと考えています。回答者の 15% では製品中心のモデルに移行する予定がありません。調査はガートナー リサーチ サークルのメンバー 129 名を対象に実施しました。質問は、「ソフトウェア配信に製品中心のモデル (プロジェクト中心のモデルではない) を使用することに関し貴社では計画はありますか。回答を 1 つ選択してください。」というものでした。

画像のクレジット: Gartner: 「Survey Analysis: IT Is Moving Quickly From Projects to Products (調査の分析: プロジェクトから製品へと短期で移行する IT)」(Bill Swanton、Matthew Hotel、Deacon D.K. Wan、2018 年 10 月 23 日 - ID G00373896)

重要

著名な作家であり、国際的なパブリック スピーカーである Martin Fowler によると、"製品モード" とは働き方の 1 つです。 これは、ソフトウェア開発の資金調達と組織化の方法であり、プロジェクトの場合とは大きく異なります。 デジタル時代の企業 IT に一般的に適用されるものですが、この働き方は、デジタル プラットフォームを通じてビジネスを推進することを目的とする人に特に適しています。

製品モードで運用することで得られる潜在的なメリット

  • 迅速な方向転換が可能
  • エンドツーエンドのサイクル タイムの短縮
  • 本当の意味で反復が可能
  • 知識の保持
  • アーキテクチャの整合性
  • チームのモチベーションとダイナミクス
  • ファイルと反復の経済性

製品中心のモデルとは

重要

ソフトウェアやデジタル エクスペリエンスを提供するためのビジネス中心の戦略で、(期間限定のプロジェクトベースのプロジェクトではなく) 継続的なビジネス能力を提供する製品を開発します。 一般的に、製品マネージャーはこの製品を所有し、継続的開発とその予算に責任を持ちます。 この製品は、プラットフォーム (基本的に、他の製品が構築される基礎となる製品) 上に存在する場合があります。

  • Gartner 社による定義

ヒント

プロジェクトは、不定期に発生する取り組みを管理するために使用されます。

製品開発プロセスは、不定期に発生する取り組みではありません。 これは、新機能を提供することで製品を改善する継続的なプロセスです。

製品はプロジェクトではありません。何を提供する必要があるかの明確な定義がないからです。 ソフトウェア開発業界における製品とは、顧客向けのシステムを指します。 顧客のニーズは時間と共に変化し、新しいテクノロジが使用できるようになるため、顧客は使用するソフトウェアも同様に変化することを期待します。そのため、何を提供する必要があるかという明確な定義はありません。 毎月、あるいは毎週のように要件が変わる可能性がある場合、すべての機能を特定の順序で提供するための 1 年計画を立てる必要はありません。 製品開発プロセスは、このような顧客のニーズの変化に対応できるものでなければなりません。

製品をいつまでに納品するかという明確な定義はありません。 そのため、製品がプロジェクト管理プロセスの重荷を負うことはありません。 製品開発プロセスは、従来のプロジェクト管理プロセスよりも常にはるかにリーンになります。製品に新機能を提供することは、新機能ごとに、検出、設計、実装、テスト、展開という常に同じプロジェクトになるためです。

重要

製品中心のモデルは

  • 外部および内部の顧客にサービスを提供できる
  • ビジネス能力によって明確に定義されている
  • 顧客にとって価値のある機能を提供する
  • 反復可能なサービスまたはプラットフォームにすることができる
  • 購入、販売、サブスクライブ、 資金調達することができる
  • 市場での競争力と製品のライフサイクルがある

開発チームを製品に合わせるには、チーム内のスキルセットを根本的に変える必要があります。 製品をエンドツーエンドでサポートするには、深い専門性ではなく、フルスタックの方法論に転換する必要があります。

製品組織はよりフラットになり、オーバーヘッドも少なくなります。

図は、製品所有者、スクラム マスター、エンジニア、サイト信頼性エンジニアの役割を含む、フル スタックの製品チームを示しています。フルスタック チームは、プロダクト マネージャーやアジャイル アーキテクトと共同作業を行います。

画像クレジット: Gartner「Overcome Objections and Sell the Benefits of Moving From Projects to Products and Agile (プロジェクトから製品およびアジャイルへの移行による反対意見の克服とメリットの売り込み)」(Bill Swanton、2019 年 2 月 12 日、- ID: G00383228)