If we need synchronized efforts… Then the contribution of any single person to the organization’s purpose is strongly dependent upon the performance of others.
—Eli Goldratt
ARTフロー
ARTフローは、ARTが顧客に対して価値あるフィーチャーを連続的に提供する状態を説明しています。
アジャイルリリーストレイン（ART）は広範なステークホルダーと協力して顧客に近づき、継続的デリバリーパイプライン（CDP）を構築することで、価値あるプロダクトとサービスのデリバリーを加速することができます。 これは、SAFeエンタープライズのビジネスの成果を向上させるのに非常に効果的であることが証明されています。
しかしどの企業も複合的であるように、この種のデジタルトランスフォーメーションは複雑で、リーンアジャイルな働き方を採用することは大きな変化です。 多くの個人やチームはこれまでにアジャイルな方法で働いたことがなく、阻害要因がたくさんあります。 また、ARTがどれだけ効果的になるかに明確な制限はありません。 常にバリューフローのデリバリーを改善する機会があります。 実際、顧客バリューデリバリーのスコープと影響のため、各ARTには継続的なフローを改善してビジネスの成果を改善する主要な機会があるかもしれません。
注: フロー記事シリーズについて
SAFeはフローベースのシステムです。 そのため、フローへのいかなる中断も、継続的なバリューのデリバリーを可能にするために、体系的に特定され、対処される必要があります。 フローベースのガイダンスはSAFe全体に組み込まれていますが、フローへの阻害要因を直接扱う6つの特別な記事が集められています。 これらはバリューストリームマネジメント、原則＃6- 途切れることのないバリューフローを実現する、チームフロー、ARTフロー、ソリューショントレインフロー、ポートフォリオフローであり、詳細ガイダンス記事SAFeでフローを加速するでまとめられています。 これらの記事ではフローと「8つのフローアクセラレーター」が定義されており、チームは連続的なフローの達成に関する問題を解決し、最適化し、デバッグするために使用できます。 この記事では、途切れることなくバリューフローを実現する方法について説明します。
詳細
原則6 - 途切れることのないバリューフローを実現するで強調されているように、顧客バリューの連続的なフローを達成するための問題を解決し、最適化し、デバッグすることができる8つのフローアクセラレーターをSAFeは定義しています。 この記事では、8つのフローアクセラレーターを適用することにより、アジャイルリリーストレインを通じてバリューフローを加速する方法について説明します。
#1 WIPを可視化して制限する
重要な理由
過度な仕掛かり中の仕事（WIP）は、ARTの生産性を大幅に低下させ、バリューフローを妨げます。 それは人々とチームを過負荷にし、優先順位を混乱させ、頻繁にコンテキストの切り替えを引き起こし、新しい機能のための長い待ち時間を生み出します。
ARTは最善を尽くすことを目指します。 しかしARTには多くのWIPがあることは普通であり、時間をかけて達成できる量をはるかに超えていることがしばしばです。 しかし、それは逆効果です。過負荷のARTは、過負荷の場合よりも完了できる仕事が少なくなります。
何をすべきか
- プロセス内のすべてのフィーチャーを視覚化します。 ARTは、現在進行中のすべてのフィーチャーの残りを管理するべきです。 これらはARTバックログカンバンシステムで管理され、WIPが制限されています。
- キャパシティ割り当てによるコントロールを確立します。 すべてのARTの仕事がフィーチャーで表現されている訳ではありません。 従って、ARTの総WIPは、現在のフィーチャーとフィーチャーに関連しない仕事、つまり探索、インフラストラクチャ、ツール、改善アクションなどの組み合わせです。 これらの他の重要な活動に費やされる時間を過小評価しがちです。 WIPの合計に対処するために、ARTのフィーチャーやその他の仕事のためのキャパシティ割り当てを設定し、時間と共に調整します。
#2 ボトルネックに対処する
重要な理由
ボトルネックはART全体の生産性を制約するため、チームはボトルネックを解消してフローを改善する必要があります。 現在のボトルネックが解消されると次のボトルネックが現れ、それに対処しなければ次のレベルのパフォーマンスに到達することはできません。 これは連続的なプロセスです。
何をすべきか
- ボトルネックを特定します。 ARTは既知のボトルネックのみを対処できます。 一部のARTのボトルネックはPIプランニングの間に特定できます。他のボトルネックはPI実行中またはインスペクト＆アダプトの間にのみ具体化します。 ボトルネックの典型的な症状には以下のようなものがあります。
- 過負荷の個々のチームまたはチームのグループ
- アクティビティ（統合、テスト、デプロイメント、リファクタリングなど）が、あるイテレーションから別のイテレーションに繰り返し先送りされること
- 特定のタイプの依存関係の遅延実行
バリューストリームマッピング、プランニングボード、ARTカンバンシステムといったSAFeメトリクスやツールは、ボトルネックを特定するのに役立つかもしれません。
- 全体的な影響を理解します。 ARTは、現在のボトルネックがバリューフローにどのような影響を与えるかを理解する必要があります。 例えば顧客からのフィードバックが遅いと、ARTが間違ったソリューション機能を構築することにつながり、大幅なやり直しや不満が生じる可能性があります。 劣化するシステムアーキテクチャは、開発プロセスを大幅に長引かせ、予測を困難にします。
- 可能な場合は、ボトルネックのキャパシティを増やします。 問題を特定し理解したら、ボトルネックでのキャパシティを増やすことは明らかな解決策です。 例えばフロントエンド開発者の数が不足しているARTは、より多くの人々を追加するかもしれません。 またアーキテクチャが不十分な場合、ARTは技術的負債の削減により多くの時間を割くことがあります。
- ボトルネックを迂回します。 ただし、チョークポイント（渋滞箇所）でキャパシティを増やすことは、追加の人々やリソースが常に利用可能でない場合、難しいことがあります。 短期的には、閉塞を避ける方がより生産的かもしれません。 依存関係がない次に価値のあるフィーチャーを選択することは、これを行う一つの方法です。 例えばレガシーシステムの大規模なアーキテクチャの改善を開始する代わりに、ARTはシステムの退役を早めることを選択するかもしれません。
#3 引き継ぎや依存関係を最小限にする
重要な理由
情報と資産の「引き継ぎ」は、ワークプロダクトが一つのプロセスステップから別のステップへ移行するときに発生します。 そして、特定の人物や他の人物またはチームからのユニークな入力が必要な状況で、依存関係が発生します。 一部の引き継ぎや依存関係は避けられないものの、過剰で不必要な依存関係や引き継ぎは、フローを妨げます。
何をすべきか
- 依存関係を視覚化するためにARTプランニングボードを使用します。 ARTプランニングボードは、チーム間の重要な依存関係を追跡し、PI全体での実行を最適化するのに役立ちます。 新たな事実が明らかになると依存関係は調整されます。
- 依存関係のインクリメンタルな実行を促進します。 あるチームから別のチームへの重要な引き継ぎは、不確実性、再仕事、そして遅延を伴います。 代わりに依存関係は、よく小さな、より管理しやすい項目に分割することができます。 このアプローチは、チーム間の頻繁な統合、問題や不一致の積極的な発見、そしてより予測可能で速いプロセスを促進します。
- 頻繁に同期します。 ARTシンクは、依存関係と引き継ぎを同期するための優れた場を提供します。 依存関係を持つチーム間で直接的なコミュニケーションを確立することは、実装の詳細を整理するのに役立ちます。
- チームの構造を最適化します。 過度な依存関係と引き継ぎは、ARTの構造が不十分であることをしばしば示唆します。 依存関係を減らすために、機能横断的で、異なる専門分野を持つアジャイルチームを構築し、チームトポロジーを適用します。
- 外部団体との依存関係を視覚化し、管理します。 ARTは、他のARTや組織との内部および外部の引き継ぎを持つことがあり、それらもまた特定、追跡、および処理する必要があります。
#4 迅速なフィードバックを得る
重要な理由
ソリューションの開発は、ARTを正しい方向に導く迅速なフィードバックに依存しています。 フィードバックが遅延したり欠けたりしていると、間違いがすぐに積み重なり、複数のチームに大幅な再仕事を引き起こし、デリバリーが遅くなり、顧客が不満を持つことにつながります。 図1が示すように、通常2種類のフィードバックが必要です。
- ARTは顧客のために正しいものを作成していますか？
- ARTは正しく構築していますか？
何をすべきか
- 両方のタイプのフィードバックを確認します。 継続的な顧客エンゲージメントは、ARTが正しいものを構築していることを確認する唯一の方法です。 多くの状況では、顧客に到達するための近道が必要となるかもしれません。 またARTは、技術が実用的であり、ソリューションが品質の期待を満たしていることを確認しなければなりません。 このテストは連続的であり、機能要件と非機能要件（NFR）を対象とするべきです。
- ソリューションを遠隔測定します。 アプリケーションの遠隔測定は、貴重なシステムの使用状況と行動データを獲得できます。 これらのアプリケーション固有でコンテキスト依存の測定は、イネーブラーの計画と実行を必要とします。
- 早期から頻繁に顧客と関わります。 すべての機会で、プロダクトを顧客にデモンストレーションしてください。 新しい試用版の機能を、可能な時はいつでも選択した顧客に対してテストしてください。
- 頻繁に統合し、テストを行います。 アジャイルチーム内部およびART全体で統合が必要です。 テストの自動化は、実装が正しい方向に進捗状況が進んでいることを確認するための最も迅速で生産的な方法を提供します。
- リサーチスパイクとMVPを使用します。 スパイクとMVPは、意図的で実験的なデザインの例です。 それらは、顧客とソリューションについての知識を獲得するための貴重な近道です。
# 5 小さいバッチで仕事する
重要な理由
大きなバッチでの仕事は、情報の減衰、フィードバックの遅延、やり直し、および大きな変動性につながります。
何をすべきか
- バッチの種類とそれぞれのサイズを理解します。 バッチには複数のタイプがあります - 計画、統合、テスト、リリース、顧客からのフィードバックなど。 トランザクションコストとホールディングコストの合計を最小限に抑えるために、それぞれを理解し、バッチを適切な大きさにする必要があります。
- ケイデンスを使用します。 ARTケイデンスは自然にいくつかの主要なバッチタイプを制約します。 推奨されるイテレーションとPIの期間を守ることは、計画、統合、顧客からのフィードバックを助け、バッチサイズを小さく保つのに役立ちます。
- チームとARTのサイズを管理します。 推奨されるアジャイルチームとARTのサイズを適用することで、バッチサイズを小さくできます。
- デリバリーパイプラインを自動化します。 効果的な継続的デリバリーパイプライン（CDP）は、最適な統合、テスト、およびデプロイメントのバッチサイズを小さくします。
- より小さなバッチの計画を立てます。 明確に小さなバッチのプランニングをすることで、そのサイズを小さくすることができます。 例えば特定の頻繁なリリースの計画は、リリースバッチを抑制するのに役立つかもしれません。
- 薄く縦分割して仕事します。 仕事を縦分割すると、ほとんどのバッチサイズを小さくすることができます。 そうすることで、フィーチャーをより小さく、より管理し易くします。 各イテレーション内のフィーチャーをより少なくすることで、バッチサイズも小さくなります。
#6 待ち行列の長さを短くする
重要な理由
ARTバックログの待ち行列には、サービスを待っているすべてのコミットされたフィーチャーに関する仕事が含まれています。 その待ち行列が長いほど、新しいフィーチャーが顧客に届くまでの待ち時間が長くなります。
何をすべきか
- ロードマップを柔軟に保ちます。 固定された長期的なロードマップは、長い待ち行列の一例です。 一部のマイルストーンは固定されるべきですが、ロードマップは可能な限り日付と仕事のスコープを柔軟に保つべきです。 それにより、ARTは市場の変化や新たな学びに対して、実装中に対応することができます。
- 強固なプロダクトマネジメント機能を確立します。 組織が断ることができず効果的に仕事の優先順位をつけることができないために、待ち行列はしばしば発生します。 プロダクトマネージャーは、PIプランニング、PI自体、そしてインスペクト＆アダプトの間において、積極的かつ堅実なスコープマネジメントのリーダーシップを発揮しなければなりません。
- 緊急の優先事項のためのキャパシティを確保します。 ARTは、事前に知っている仕事だけを計画することができます。 実行中には、一部のエリアではさらなる探索が必要になるか、または将来の市場のイベントに依存することがあります。 他のイベントは予測不可能です。 予防措置として、イベントが新たな仕事を引き起こす時に、チームが計画に組み込むことができるようにキャパシティを確保してください。
#7 没頭する時間を最適化する
重要な理由
ソリューションの開発は、チームメンバーの創造性と集中的な知的努力に依存しています。 例えば新しいソフトウェア機能を実装するには、開発者やチームが異なるシステム間の数百の依存関係を見て回る必要があるかもしれません。 協力には高度な集中力と多くの仕事セッションが必要です。 集中する時間を最適化すること - 個々の人々とチーム全体の両方にとって - は、ARTの生産性に大きな違いをもたらします。
何をすべきか
- 仕掛かり中の仕事を少なく保ちます。 仕掛かり中の仕事（WIP）が多すぎると、コンテキストの切り替えが頻繁に発生します。 アクティブな項目が少なければ、仕事の中断も少なくなります。
- 仕事を頻繁に統合します。 定期的にチーム間の統合を行うことで、矛盾や問題を迅速に解決できます。 そうしないと、それらは積み重なり、依存関係を持つチームが頻繁に互いに割り込み、その後、以前の仕事を再実施する必要が生じます。
- ソリューションの健全性を維持します。 チームが継続的に技術的負債に対処しないと、曖昧な依存関係や新たに生じた欠陥を追求するのに多くの時間を費やすことになります。
- 効率的なイベントを確保します。 チームの生産性を最適化するために、特にPIプランニング、システムデモ、そしてインスペクト＆アダプトの全てのイベントを継続的に最適化します。
#8 既存の方針と実践を修正する
重要な理由
チームフローの記事で説明されているように、既存のポリシーと実践は、SAFeの実装中、あるいはそれ以降でも悪影響を及ぼす問題を引き起こす可能性があります。 そして、影響を受けるのはチームだけではありません。 ARTがソリューションの主要な経済的バリューを提供し、R＆D投資の大部分を消費することを考えると、重要なステークホルダーから多くの注目を集めることは確実です。 残念ながら、そのステークホルダーの一部はリーンアジャイル変革に参加していないかもしれないので、彼らは無意識のうちにフローを減速させるかもしれません。
注意すべき点
最初のステップは、これらの阻害要因が存在する可能性があることを知ることです。 阻害要因が発生した時にそれらを認識することが二つ目のステップです。 一般的な阻害要因には以下のようなものがあります。
- アジャイルチームの上に重ねられた従来のプロジェクトとプログラムマネジメント（EVM、WBS、IMS、コスト会計）
- 品質システムと組み込まれたウォーターフォールのステージゲート型のマイルストーンを含むガバナンスモデル
- 仕事を行う人々からの意見が含まれていない、確定したスコープと厳しい締切
- アジェンダと出席者が重複する冗長な報告とリリース会議
- プロダクトデザイン、アーキテクチャ、およびUXのARTとバリューストリームからの分離
- 顧客が必要とする変更を防ぐための資産の「凍結」
- 必要なツールと仕事環境の提供遅れ、不十分な効果
- 検証＆妥当性確認とコンプライアンス活動、そして最後にのみ関与するチーム
何をすべきか
阻害要因が一度特定されたら、チームは是正措置を取らなければなりません。 しかし、そのアクションは阻害要因の特定のステークホルダー、性質、およびコンテキストに依存します。 チェンジエージェントは、これらのステークホルダーの多くが変革の旅に参加しておらず、追加のトレーニングとコーチングが必要であることにしばしば気付きます。 変化が完全に文化に組み込まれるまで、変化の旅は完了しません。
ARTフローの測定
フローの測定は、ARTフローの改善にとって重要です。 SAFeのメジャー＆グローシステムは、コンピテンシー、フロー、そして成果の3つの測定カテゴリーを提供し、企業が革新的なビジネスソリューションを迅速に提供する能力をアセスメントし、改善することができます。 この計測システムには、フローに特化した6つの指標が含まれています。フロー配分、ベロシティ、時間、負荷、効率、そして予測精度です。 ARTフローに関しては、全てが関連していますが、特に予測精度、時間、負荷、効率は有用で、以下で強調されています。
ARTフローの予測精度
ARTフローの予測精度は、ARTがPIオブジェクティブを計画し、達成する能力をどの程度測定できるかを示します。 ビジネスが効果的に計画し実行するためには、一般的にARTは、コミットされたオブジェクティブの大部分と、コミットされていないオブジェクティブの1つ以上を満たすべきです。 このアプローチは通常、計画された合計の80-100％を平均して結果を出します。 図2は、ARTがPIのコミットメントに対してかなり保守的なアプローチを取っている例を示しており、平均的な予測精度は常に100％以上で推移しています。 100％を超えるスコアを獲得するには、チームがコミットしたオブジェクティブとアンコミットオブジェクティブを完了する必要があります。
ARTフロー時間
新しいフィーチャーを提供するまでの合計経過時間をARTフロー時間で測定します。 通常、構想から生産までを計算します。 図3は、比較的安定したフロー時間の平均が約36日である例を示しています。 外れ値は一般的であり、これは外部依存関係により妨げられたフィーチャー、予期しないリスク、または他の一般的な要因を示す可能性があります。
ARTフロー負荷
ARTフロー負荷は、任意の時点でのシステム内の仕事総量を測定します。 図4に示すように、面グラフで示されたARTカンバンの状態に基づく自動化されたレポートとして、それはよく生成されます。
このチャートは、このアジャイルリリーストレインのWIPが劇的に増加していることを示しています。 「なぜ」へのさらなる洞察には、ARTのコンテキストに関する知識が必要です。 例えば、アジャイルリリーストレインは実際にWIPで過負荷になっているかもしれません。または、アジャイルリリーストレインのサイズが劇的に増加し、WIPの増加は単にサイズの増加であるかもしれません。
ARTフロー効率
フロー効率は、合計アクティブ時間とフロー時間の比率です。 最適化されていないシステムでは、フロー効率が非常に低くなることがあります。これは、バックログ項目がシステム内で過ごすほとんどの時間が、別のアクティビティからのサービスを待っている時間であることを示しています。 フロー効率を理解するための出発点は、バリューストリームマップを作成し、バックログ項目がさまざまなプロセス状態でどれくらいの時間を費やすかを推定する（または実際の時間を収集する）ことです。
以下の図5に示すバリューストリームマップの例は、実際のDevOpsバリューストリームマッピング演習から取られています。 このシステムは非常に効率が悪いことが観察され、フロー効率は5％です。 また、ほぼ全ての待ち時間が特定のステップの前で発生することも観察できます。 そのステップはプロセスのボトルネックであり、他のステップでのフローを増やす仕事はあまり経済的なリターンを生み出さないでしょう。 ARTは効率を向上させるためにボトルネックに対処しなければならず、それが起こると、フロー時間も劇的に減少するはずです。
フローメトリクスの概要
SAFeのフローメトリクスは、ARTフローの改善の機会を明らかにするのに役立ちます。 しかし、数字だけでは全てを語ることはできません。 良い判断と共に質的分析が必要です。
最終更新： 2023年9月26日