ミッション主導の開発

企業が成長するにつれて、アジャイル製品開発のスケーリングはより困難になります。 アジャイルレポートの第13州の回答者の52％によると、組織文化とアジャイルの価値観の違いが彼らの仕事の主な欠点です。

組織のリーダーは、アジャイル文化を活用して製品開発を改善することができます。 堅牢なアジャイル文化には、複雑な問題への取り組みにおけるチームの自律性、クライアントとの緊密な協力、および長期的なビジョンと戦略が含まれます。

これらの抽象的な価値を評価して関与することは困難です。組織では、それらを活用するための効果的な戦略を実装することは重要な作業になります。 Mission Driven Development（MDD）アプローチは、そのような文化を成長させるための代替手段として、中期のスタートアップから生まれました。

スケーリングの課題

スケーリング時に、いくつかの速度低下パターンが現れる可能性があります。 目的が不明確なプロジェクトでは、チームのモチベーションが低下する可能性があります。 製品マネージャーは、運用会議で迷子になり、戦略的な製品パスを設計する時間を失う可能性があります。 システムがますます複雑になるにつれて、新機能や製品の展開が遅くなる可能性があります。

これらの障壁は、文化的および実践的な観点から取り組む必要があります。 それらを克服するには、制御を放棄し、チームの自律性を高め、根本的な透明性を実装し、結果を促進するための効率的な製品開発フレームワークを設定する必要があります。

従来のアジャイルフレームワークのスケーリングの課題

アジャイルをスケーリングするときは、管理レベルとチームレベルを同期させる必要があります。 管理レベルは、会社の戦略の策定、製品ビジョンの作成と伝達、人員配置の決定の実行、およびチーム開発の促進を担当します。 チームレベルでは、このビジョンと戦略を価値のある製品と機能に効率的に変換するために必要なタスクを実行します。

従来のアジャイルフレームワーク（XP、スクラム、およびかんばん）は、チームレベルで動作するように最適化されており、管理関係は主に対処されていません。 このギャップを埋めるために、スケーリングされたアジャイルフレームワークの新しい波が進化しました。つまり、SAFe、LeSS、スクラムオブスクラム、Nexus、DADなどです。ただし、これらのアプローチには、実装の多くの計画と管理および保守の努力が必要です。

軽量のアプローチであるMissionDrivenDevelopmentフレームワークは、開発のスケーリングとアジャイル値の活用に関する堅牢な構造を実装するための十分なガイドラインを提供します。

ミッション主導型開発のコア要素

ミッション

出発点はミッションディスカバリーです。 ビジネスミッションには時間と労力がかかり、潜在的な問題、ソリューションスペース、および望ましいビジネス成果を特定する必要があります。 正確に定義されると、ミッションはモチベーションを高め、コラボレーションを促進し、より広いデザインスペースの研究を促進します。

分隊

各ミッションの成功の責任者は分隊です。 プロダクトマネージャーと協力して、2〜4人の小さなチームが、ミッションの目標と時間制限に合ったソリューションを提供するために必要な活動を行います。

6週間のサイクル

6週間のタイムボックスにより、すべてのチームが基本計画の同じタイムラインに従うと同時に、有意義な結果をもたらすのに十分な時間を与えることができます。

バッファ期間

MDDフレームワークには、通常、最終的な統合と展開、トレーニングとスキル開発、イノベーションアクティビティ、次のサイクル計画などのための1週間または2週間のバッファ期間が含まれます。

6週間のサイクルの重要性

6週間の期間は、一部のアジャイル実践者にとっては長いように思えるかもしれませんが、いくつかの重要な利点があります。

短いサイクルで作業するチームは、修正、バグ、および小さな機能の「ランドリーリスト」をチェックしているように感じるため、製品ビジョンへの関与を失う傾向があります。 これは、ソリューションを提供するための最良の方法を探求し、選択するチームの自律性を脅かします。

サイクルが長くなると、製品の推定精度が低下します。 その結果、製品チームによる多大な計画作業が必要になります。

6週間は製品タイムフレームのゴールディロックと呼ばれ、革新的な思考、ラピッドプロトタイピング、継続的デリバリーを通じて最小実行可能製品を提供するのに十分な時間を提供します。

6週間のサイクルは、自律性を活用することにより、チームのビジョンへの関与をさらに強化します。 ミッションが明確に述べられており、チームが望ましい結果のみに集中できるほどサイクルが短い限り、マイクロマネジメントは必要ありません。

最後に、製品マネージャーは6週間ごとに計画活動に従事し、チームがミッションに向けて順調に進むための十分な予測可能性を維持できます。 その結果、製品開発の戦略的および探索的側面により多くの時間を費やすことができます。

ミッション主導型開発の実装

たとえば、人工知能アプリケーションを使用してクライアントの収益を増やすネットワーク価格の最適化を提供するB2B製品を備えた中期スタートアップを考えてみましょう。 この企業は最近、関連する業界関係者としての地位を確立し、市場シェアを300％拡大することを目標に、新しい資金調達ラウンドに署名しました。

このシナリオでは、いくつかの製品開発の課題があります。

• 保留中の価値仮説を検証するために、現在および潜在的なクライアントからのフィードバックをどのように取得できますか？
• 魅力的なユーザーエクスペリエンスを実現するには、プラットフォームにどのような機能を構築または削除する必要がありますか？
• スケーリングを処理し、文化的価値を活用して成長を加速するために、管理構造をどのように設定できますか？

結局、複雑なフレームワークを回避するために、同社はMissionDrivenDevelopmentフレームワークを適用することにしました。 Mission Driven Developmentでは、「ラストマイル」の詳細はすべての組織によって定義されます。 定義する主な要素は次のとおりです。

• ミッション発見
• ミッションの構造
• 分隊アセンブリ
• 検査と適応
• バッファーの反復
• キャパシティプランニング

ミッションディスカバリー

出発点はミッションディスカバリーです。 Tim Herbigは、発見を、問題またはアイデアに関する不確実性を減らし、適切な製品が適切な対象者のために構築されることを保証する反復プロセスとして説明しています。 反復サイクルでミッションをコミットする前に、可能な限り包括的に検証する必要があります。

ミッションディスカバリープロセスは、特別に割り当てられたチームによって実施されます。 ディスカバリーチームは、プロダクトマネージャーが主導し、プロダクトリサーチャー、ビジネスアナリスト、デザイナーで構成されています。 複数の製品マネージャーが存在する場合、それらは最高製品責任者（CPO）に報告します。最高製品責任者は、製品全体の共通のビジョン、製品の適合性とグローバル企業戦略、およびタイムリーな納品を保証します。

ミッション発見の推奨される出発点は、課題、問題、または機会です。 たとえば、課題から始めて、チームがより多くの設計スペースを探索し、最終的にソリューションの可能性を広げるのに役立ちます。

ミッションの検証には、企業がクライアントのニーズをよりよく理解するのに役立ついくつかのアクティビティが含まれます。

1. 市場調査と競合他社の分析の実施
2. ミッションが定義されている問題空間を理解する
3. 忠実度の低いスケッチとプロトタイプの設計
4. ミッションの明確な範囲を定義する
5. クライアントのフィードバックと検証の収集

これらの活動は、ミッションが開発チームの確固たるガイドラインとなり、ユーザーに価値がもたらされることを保証するのに役立ちます。

その結果、一部のミッションは、ミッションバックログに入ることが検証されます。ミッションバックログは、発見アクティビティとフィードバック収集によって継続的に進化します。

この例では、この課題に取り組みましょう。魅力的なユーザーエクスペリエンスを実現するには、プラットフォームからどの機能を構築する必要がありますか？ この課題に取り組むには、製品マネージャーが率いる1つの発見チームだけで十分です。

現在、サンプル企業のプラットフォームがクライアントの生データを取得し、処理されたデータファイルに対して最適化された価格設定ネットワークを返すと仮定します。 ただし、プラットフォームUXは、魅力的なエクスペリエンスのために最適化されていません。 この時点での目標は、クライアントの価値がUXの改善、新機能の開発、またはプラットフォームサービスの強化からもたらされるかどうかを判断することです。

最初の市場調査の後、決定は新しい機能を開発することです。 プラットフォームの候補機能は次のとおりです。

• 超高速の価格改定
• 高速で応答性の高いインターフェース
• インテリジェントで高度な価格改定ルール
• 価格改定と販売履歴

発見の目的で、同社はデザインスプリントアプローチを採用することを決定しました。これは、デザイン、プロトタイピング、およびユーザーとのアイデアのテストを通じて、重要なビジネスの質問に答えるための5日間のプロセスです。 検出プロセスは、候補となる機能ごとに実行され、現在および潜在的なクライアントにとってより多くの価値を生み出すものを確認します。 開発用に選択された最も重要な機能は、インテリジェントで高度な価格改定ルールです。

ミッション構造

確かなミッションの定義を達成することは簡単な作業ではありません。 明確なビジネス上の課題を描写し、その結果の境界を設定すると同時に、チームが革新的で効率的なソリューションに到達するための十分なスペースを提供する必要があります。 明確で正確な使命：

• 問題のある領域を特定して描写したことで、ビジネス上の課題を明確に述べています。
• 前のフェーズで発見されたすべての情報と洞察を統合します。
• 望ましいビジネス成果へのリンク。
• 結果指向であり、ミッションの成功の全体像を明確に示しています。
• 6週間のサイクルの機会内で現実的かつ達成可能です。
• 焦点を保証するために十分に狭く、細部から遠ざけるために十分に広い。

この例では、1週間の発見の後、情報とユーザーのフィードバックが収集され、統合されています。

ターゲットユーザー：クライアントの価格設定アナリスト。

問題領域：ユーザーは、特定の条件で価格を自動的に調整できるように、価格に関するインテリジェントで高度なルールを設定および管理できることを望んでいます。

ルールの最も価値のある条件は、競合他社の価格、出荷の緊急性、注文の合計、利用可能な在庫、およびプレミアムクライアントの割引です。

インサイト：ルールはカスタムの優先順位で適用され、必要に応じて変更可能である必要があります。

アナリストは、特定の製品に特定の時間にどのルールが適用されるかを簡単に確認したいと考えています。

望ましいビジネス成果：プラットフォームで費やした時間で測定すると、ユーザープラットフォームのエンゲージメントを25％増加させます。

分隊アセンブリ

チーム編成プロセスは、開発サイクルごとにその場で行われます。 チームの自律性と自己組織化の原則は依然として中心的です。 チームの組み立ては、ミッションの複雑さ、開発者と設計者のスキル、興味、チームの化学的性質など、さまざまな要素の組み合わせによって導かれます。

分隊編成のプロセスは、アジャイルコーチによって促進されます。 決定を下す前に、各人は次の6週間でどのような種類の仕事をしたいかを尋ねられます。 次に、経験、知識、スキルに基づいて分隊が編成され、ミッションに首尾よく取り組むために必要な知識とスキルを確実に身に付けます。

アジャイルコーチは、開発サイクルに沿っていくつかのチームと協力し、障害や依存関係を高めるのに役立ちます。 複数のアジャイルコーチが存在する場合、彼らはチームの組み立て、継続的な改善、およびアジャイル製品の提供を担当するアジャイルの責任者に報告します。

推奨される分隊のサイズは2〜4人です。通常、ミッションの複雑さに応じて、1人の設計者と1人または2人の開発者です。 QAエンジニアは、1つまたは複数のチームが目的の品質基準を達成するのを支援すると見なされます。

分隊はサイクルごとに混合されることが多いため、パフォーマンスの高い分隊が数サイクル一緒に作業する場合でも、全員がさまざまな人々と協力し、知識を広め、さまざまな製品の側面に取り組むことができます。

この例の特定のチームは、UIデザイン、データ処理、およびデータ視覚化機能を備えた人々を考慮する必要があります。

サイクル内での検査と適応

透明性、検査、および適応は、標準的なアジャイルプラクティスを通じてアジャイルコーチによって継続的に奨励されるべきです。

仕事を整理し、障害や依存関係を高めることを容易にするために、毎週短い会議が開催されます。 必要に応じて、チームがミッションとユーザーストーリーを完全に理解できるようにグルーミングが行われます。 変更と改善を特定して実装するために、毎週の終わりに短い回顧が行われます。

継続的デリバリーの慣行は、サイクル全体を通して維持する必要があります。 6週間のサイクルタイムボックスは、チームの予測可能性の達成を支援しながら基本ルールを設定するためのケイデンスベースのアプローチであるため、ミッションの目標は早期に達成できます。

透明性を高めるための良い習慣は、チームと製品マネージャーの間で合意されたマイルストーンに基づいた、第4週の終わりのデモです。 これらのデモの目標は、必要に応じてスコープを適応、縮小、または拡大することです。

ミッションの例では、4つの異なるリリースでチームとプロダクトマネージャーの間でリリース計画が合意されています。

1. リリース1：
   • 新しいルール機能UI
   • 競合他社の価格ルール
2. リリース2：
   • 配送緊急ルール
   • 注文合計ルール
   • ルールの優先順位
3. リリース3：
   • 利用可能な在庫ルール
   • 視覚化アプリケーションルール
4. リリース4：
   • プレミアムクライアントの割引

リリース3は、第4週のデモとして合意されています。 リリースは開発サイクル全体で実行されているため、開発サイクルが開始された瞬間から、望ましいビジネス成果（この場合はユーザーエンゲージメント）を追跡する必要があります。 グラフィカルに、次のように進歩が期待されます。

バッファ期間

バッファ期間として1〜2週間かかることは、Mission Driven Developmentの実装や、SAFeなどの他のスケーリングアプローチを通じて再現されるプラクティスです。

SAFeでは、イノベーションと計画の反復がすべての開発サイクルで行われます。 これはコンテキストスイッチャーとして機能し、他の配信に焦点を合わせたフレームワークでは通常省略される探索と革新のプロセスとアクティビティを可能にします。 このバッファ週に実装されたアクティビティの例：

• ソリューションの最終統合。 6週間のサイクルの終わり近くに展開する場合、統合、検証、文書化、および検証が保留されたままになる可能性があります。 専用の時間は、既存の製品に新しいソリューションを効果的かつスムーズに統合するのに役立ちます。
• ミッションの計画と優先順位付け。 ミッションは洗練され、小さなバッチまたは大きなバッチに分類され、次の開発サイクルに優先順位が付けられます。 ミッションに優先順位を付ける場合、一部の企業は、トップミッションが会社に提示され、その後、共同で次の開発サイクルにコミットするピッチデーを実施します。
• ハッカソン。 ハッカソンは、イノベーションを促進し、コミュニティを作成し、楽しい方法で新しい知識とスキルを構築する能力のおかげで、スタートアップや企業の間でますます人気が高まっています。 結果は他の人に提示され、ミッションバックログの候補になります。
• 実験的なプロトタイプの開発またはサイドプロジェクト。 エンジニアと設計者がバッファ時間の終わりに行われた作業を示している限り、彼らが決定したものに取り組む時間を与えるのが一般的な方法です。
• エンジニアリング作業。 通常、インフラストラクチャの開発、テストの自動化、技術的負債の削減、システムの移行などの純粋なエンジニアリング作業が実行されます。
• 新しいスキルと知識の開発。 知識の進化の急速なペースにより、開発者は世界のトレンドを常に把握する必要があります。 バッファ時間は、オンサイトトレーニング、実践コミュニティ、テクノロジーワークショップなどを開催するのに適しています。

バッファー期間は、特定された知識のギャップ、イノベーションの目的、および次のサイクルのニーズに依存する必要があります。 たとえば、1週間のバッファ期間は次のようになります。

キャパシティプランニング

Basecampの共同創設者であるJasonFriedによると、次の開発サイクルのミッションコミットメントを決定する際の一般的な方法は、最初に小さなバッチまたは大きなバッチを特定することです。 大きなバッチは大きな製品の特徴または機能を指し、小さなバッチは小さな反復またはタスクを指します。 与えられた例では、新しい機能のために選択されたミッションは大きなバッチと見なすことができます。

ここでの推奨事項は単純です。常に小さなバッチと大きなバッチを組み合わせてください。 小さなバッチは3〜4週間かかると推定されるミッションであり、大きなバッチは6週間以上かかる場合があります。

小バッチチームが第3週または第4週までにミッションを達成した場合、合意されたデモは、チームが実装されたソリューションの改善に取り組み続けるか、別のチームを支援するか、新しい小バッチミッションを開始するか、開始するかを評価する機会です。計画外の作業。

大小のバッチを適切に組み合わせると、人々は100％の容量で作業できなくなり、計画外の作業が発生した場合に操作して適応できるようになります。 大規模なバッチのチームは、サイクル中に可能な限り集中しますが、小規模なバッチのチームは、予期しない作業から発生するアドホックなタスクに対処できます。

小さなバッチと大きなバッチを組み合わせると、リスクも軽減されます。 大きなバッチしかない場合、ユーザーエクスペリエンスに悪影響を与える可能性が高くなります。 いくつかの新機能が互いに近くにリリースされている場合は、それらに適切な変更管理を伴う必要があります。 さらに、計画外の作業の場合、利用可能な容量が少なくなります。 最後に、いくつかの大規模なチームが失敗した場合、反復は非生産的であると感じられ、チームの士気をくじく可能性があります。

ミッション主導型開発のリスク

Mission Driven Developmentを実装することには多くの利点がありますが、規範的なフレームワークとして、考慮する必要のあるいくつかの固有のリスクがあります。

ミッションスコープ

ミッションは現実的であり、チャレンジの複雑さと分隊のスキルの適切な適合を目指している必要があります。 そうしないと、開発成果への影響が大きくなる可能性があります。

過度に野心的な任務は、フラストレーションと不安を引き起こし、チームのパフォーマンスに悪影響を与える可能性があります。 一方、熱心でない任務は、チームの意欲低下と退屈を引き起こす可能性があります。 したがって、Minimum Viable Productの考え方は、フレームワーク内で一定のままである必要があります。

ミッションの理由

堅牢なビジネスミッションでは、問題領域とその企業ビジョンとの関係を包括的に定義する必要があります。 この関係が明確でない場合、問題解決が会社の目標にどのように影響するかについての理解が不足しているため、貴重な洞察が失われる可能性があります。

滝の罠

6週間の間にウォーターフォールモデルに陥るのは、チームにとって自然な傾向です。 これには2つの主な要因があります。 まず、展開のプレッシャーはサイクルの終わり近くで強くなります。 第2に、チームはミッション内で可能な限り多くのスコープを絞りたいため、開発サイクルの最後に展開することが急務になります。 したがって、サイクル全体でアジャイルリリースを達成し、ウォーターフォール関連のリスクを回避するために、継続的デリバリーの実践を奨励する必要があります。

製品の操作

インフラストラクチャ、サービスの管理、コンポーネントの監視などの製品運用タスクは、速度に影響を与える可能性があるため、チームの範囲外に保つ必要があります。 アトミック設計などの開発標準や手法に依存することで、開発の労力が軽減され、その結果、スケーリングが加速されます。 このフレームワークでのもう1つの一般的な方法は、製品の運用と監視の管理に加えて、インフラストラクチャを処理する中央運用チームです。

近視の枠組みとしての6週間のサイクル

一部のシナリオは、フレームワークには適切ではありません。 これは、R＆Dプロジェクトや重要なシステムの移行など、クライアントエクスペリエンスに多大な影響を与える可能性のある大規模で複雑なシステムを扱う場合に特に当てはまります。

アジャイルをスケーリングするための軽量オプション

製品開発と企業の成長のペースを維持するためにアジャイルをスケーリングすることは、アジャイル実践者にとって潜在的な課題です。 最近開発されたアジャイルアプローチとして、Mission Driven Developmentフレームワークは、その使いやすさと実装のしやすさで企業の間で人気を博しています。 MDDフレームワークは、従来のアジャイル構造に存在するギャップを埋める、発見から提供までのエンドツーエンドの横断的な製品イノベーションプロセスを開始します。 Mission Driven Developmentは、成長する企業にとって新しいスクラムになる可能性があります。