Tuck your team members in around the areas where they quickly achieve flow—those are typically where they are particularly primed to contribute value.

—Brené Brown, Dare to Lead

チームフロー

チームフローは、アジャイルチームから顧客に継続的なバリューフローが提供される状態を言います。

SAFeのチーム＆テクニカルアジリティのコンピテンシーは、効果的な機能横断的アジャイルチームとアジャイルリリーストレイン (ART) を構築するための指針となります。チームによる具体的な品質プラクティスの実践や、幅広いステークホルダーとの協力による顧客への価値あるプロダクトやサービスの提供を促進します。このコンピテンシーは、ビジネスの成果を向上させる上できわめて効果的であることが証明されています。しかし、これまでアジャイルな働き方をしたことがない人やチームも多く、阻害要因も多くあります。とはいえ、チームの効率性はどこまでも高めることができ、顧客へのバリューフローを改善する機会は常に存在します。

---

注: フローに関する記事シリーズについて
SAFeはフローベースのシステムです。そのため、フローを中断させる問題があればすべて特定し、体系的に対処することで、継続的なバリューのデリバリーを可能にする必要があります。フローベースのガイダンスはSAFe全体に組み込まれていますが、特にフローの阻害要因を直接扱う8つの記事を集めました。このシリーズに含まれる記事は、バリューストリームマネジメント、原則 6 - 途切れることのないバリューフローを実現する、チームフロー、ARTフロー、ソリューショントレインフロー、ポートフォリオフローと、詳細ガイダンス記事SAFeでフローを加速するとフローをコーチングするです。

---

詳細

世界でも特に重要なシステムを定義し、構築し、検証し、デプロイし、サポートするというきわめて重要な仕事の多くを、アジャイルチームが担っています。アジャイルチームの小規模で機能横断的な性質、与えられる権限の大きさ、顧客とのつながり、そして実証されたアジャイルプラクティスのすべてが相まって、より迅速にバリューを提供し、より一層生産性が高く、そして単純により楽しい仕事環境を生み出します。

しかし、この仕事そのものは複雑です。それがナレッジワーカーにとってこの仕事の一番の魅力でもありますが、取り組みを複雑にする要因でもあります。SAFeは、各アジャイルチームの役割とアクティビティに関するガイダンスと実践を提供することで、この課題に対処します。こうしたガイダンスや実践を適切に実装することで、各プロセスにおいて可能な範囲で、顧客までの仕事のフローがスムーズに運びます。このガイダンスの多くは、バリューフローシステムの8つの特性にフォーカスした「原則6 – 途切れることのないバリューフローを実現する」で取り上げています。8つの特性それぞれが、フローの中断を発生させる可能性の高い要因を判断するための検査と分析の機会をもたらします。フローシステムの特性とアクセラレーターはすべてのフローシステムで共通ですが、それをどう適用するかはSAFeのレベルごとに異なります。以下のセクションでは、アクセラレーターを「チームフロー」に適用する方法について説明します。

---

#1 WIPを可視化して制限する

重要な理由

仕掛かり中の仕事 (WIP) が多すぎると、チームの生産性が低下し、顧客へのバリューフローの妨げになります (図1)。個人やチームの優先順位を混乱させ、頻繁なコンテキストの切り替えを引き起こし、ムダやオーバーヘッドが増え、ストレスが増大します。ラッシュ時の高速道路と同じように、システムが処理できる量以上の仕事を抱えることに、メリットは1つもありません。

何をすべきか

• 現在のWIPを可視化する: 最初のステップは、新しいフィーチャー、メンテナンス、アーキテクチャ、インフラストラクチャ、技術的負債の削減を含むあらゆる種類の仕事を可視化することです。多くの場合、このシンプルな可視化は、実践者が大いに必要としている「警鐘」となり、仕事の量は過剰でフローは不十分というシステムの問題への対処に着手するきっかけとなります。
• WIPと利用可能なキャパシティとのバランスを取る: 次のステップは、デマンドと利用可能な開発キャパシティのバランスを取るWIP制限の設定です。ワークフローの状態がWIP制限に達すると、新しい仕事は開始されません。これにより、デマンドとキャパシティの釣り合いをとり、フローを向上させられます。

#2 ボトルネックに対処する

重要な理由

チームの生産性は、スキル、キャパシティ、リソース、あるいはプロセスやシステムのその他の要素がデマンドに対応できないなど、さまざまなボトルネックによって制約を受けます。チームフローを改善するには、こうしたボトルネックへの継続的な対処が必要です。

何をすべきか

まず重要なタスクは、ボトルネックの特定です。次によくあるボトルネックの例を示します。

• 特定の専門知識を持つ人材が不足している
• 過度に専門化されている
• 技術的負債が過剰になっている
• シェアードサービスを利用できない
• 顧客からのフィードバックがない

多くのボトルネックは、仕事をワークフローのあるステップから別のステップに進めるときに発生します。チームカンバンのある状態の前で仕事が溜まっているとしたら、そこがボトルネックである可能性があります (図2)。

一方で、ボトルネックの原因がキャパシティやスキルの不足の場合、必ずしも簡単に特定できるとは限らず、根本原因分析が必要になることがあります。

チームのボトルネックの特定を終えたら、通常、これに対処する方法は2つあります。

1. ボトルネックでのキャパシティを増やす。 多くの場合、人員の追加は適切な対処です。しかし、他の方法もあります。SAFeの作り込み品質をはじめとするアジャイルプラクティスには、ボトルネックでのキャパシティを増やすのに有効な、次のようなさまざまなテクニックが含まれます。

• 共同オーナーシップ: 共同オーナーシップが意味するのは、チームの誰もが不具合を修正し、作業成果物を更新し、問題を解決できるということです。ただし、意図しない結果を招くことのないよう、こうした変更を行うには、必要なコンピテンスと各所での作業成果物のガバナンスが前提となります。
• T字型のスキル開発: アジャイルチームはT字型のスキルを持つ人材を育成します。「T字型」というたとえは、1つの専門分野で専門性の高いスキルを持ち、他の分野でも幅広い (ただし、必ずしも専門性は高くない) スキルを持つ人を言います。T字型のスキルを身につけることで、チームメンバーが対処できる問題や機会の範囲が広がります。
• ペアリング: ペアワークによって、問題に対処するキャパシティが倍増し、進捗を妨げている具体的な問題に対するより的確な洞察が得られます。さらに、「T字型スキル」の開発にも役立ちます。
• スウォーミング: 「スウォーミング」では、チームメンバーが1人で完了させるのが難しい作業を、複数のチームメンバーが協力してやり遂げます。

2. ボトルネックを回避する。ボトルネックは、必ずしもすぐに根本から解消できるとは限りません。チームのバックログには、ボトルネックによる制約を受けない他のメンバーが取り組める、価値あるストーリーが他にもあるはずです。選択的な計画の見直しを行うことで、ボトルネックに対処しつつ、フローを向上させられます。

また、チームのボトルネックの根本原因の中には、チームのコントロールの範疇を超えるものがある点も重要です。この場合、インスペクト＆アダプトイベントが問題をエスカレーションする絶好の機会となります。

#3 引き継ぎや依存関係を最小限にする

重要な理由

「引き継ぎ」は、仕事のプロセスにおいてあるステップから次のステップに移行する時に発生します。「依存関係」は、別の人やチームからの特定のインプットが必要な場合に発生します。依存関係や引き継ぎの中には避けられないものありますが、不必要な依存関係や引き継ぎが多いと、チームフローが阻害され、遅延が生じ、コンテキストの切り替えとオーバーヘッドが増加します。

何をすべきか

• バリューを中心にオーガナイズする: SAFe原則10 – バリューを中心にオーガナイズするは、引き継ぎと依存関係を最小限に抑えるための主要な構成を規定します。効果的なチームトポロジーによって、チームにかかる認知負荷を軽減できます。
• 引き継ぎと依存関係を可視化する: チームは引き継ぎと依存関係とは何なのか、どのようなパターンで発生するのか、そしてどのような影響をもたらすのか理解する必要があります。
• 是正措置を実行する: どのような是正措置が必要なのかは、依存関係のコンテキストから明らかになる場合があります。こうした是正措置では、多くの場合、プロセス、構築中のシステムのデザイン、個々の作業成果物、チームの組織やスキルに変更を加える必要があります。

#4 迅速なフィードバックを得る

重要な理由

ソリューション開発は、チームの仕事の指針となる必要なフィードバックを得られるかどうかにかかっています。フィードバックがなかったり、遅かったりすると、すぐに認識のずれが積み重なり、それが手直し、デリバリーの遅れ、そして顧客の不満につながります。図3に示すように、一般に「正しいものを構築する」ため、そして「正しく構築する」ための2種類のフィードバックが必要です。

何をすべきか

• 抜けているまたは不十分なフィードバックの種類を特定する: 異なる形式のフィードバックによって、さまざまな質問に対してそれぞれ異なる回答が得られます。優先順位づけは適切ですか？アーキテクチャは機能をサポートしていますか？顧客はプロダクトを使用できますか？
• レビューのシフトレフト: すべての作業成果物について、サイクルのできる限り早い段階でピアレビューを行うべきです。人はとかく、他の人に見せる前に、自分の仕事を完成した状態にしておきたいと考えがちです。しかし、そうしてしまうと、未検証のデザインに過剰な投資が行われたり、制作者が自己防衛に走ったりする恐れがあります。透明性を高め、すべてのWIPのレビューをシフトレフトします。
• 動作するシステムのデモを行う: SAFeには迅速なフィードバックを得るためのイベントがあります。最も基本的な例として、2週間に1回行われるシステムデモが挙げられます。システムデモによって、統制の取れたやり方で、核となる仮定を検証できます。
• 頻繁に統合し、顧客とのエンゲージメントを図る: 頻繁に統合することで、現在の実装アプローチに関する重要なフィードバックが得られます。また、顧客がステージング環境における現在のプロダクトインクリメントにアクセスできるようにすることで、早い段階で重要なフィードバックが得られると考えられます。

#5 小さいバッチで仕事する

重要な理由

ストーリー、タスク、その他のアクティビティに大きなバッチで対応しようとすると、フィードバックの遅れ、大幅な手直し、そして大きなバラツキが発生します。チームのフローシステムには、次のようなさまざまな種類のバッチが含まれます。

• 統合バッチ (チームが他のチームと統合することなく開発できる機能の単位)
• テストバッチ (チームが系統的テストを行わずに作成できる機能の単位)
• アーキテクチャバッチ (ユーザー向けフィーチャーを検証することなく作成できるアーキテクチャイネーブルメントの単位)
• 顧客フィードバックバッチ (顧客フィードバックなしで実装できる機能の単位)
• デプロイメントバッチ (本番環境でデプロイもテストもせずに実装できる機能の単位）

何をすべきか

• 推奨されるケイデンスやチーム規模を採用する: SAFeの構造的ガイダンスによって、バッチサイズを小さく保てます。短いPIとイテレーションの期間を守ることで、バッチサイズが小さくなります。さらに、ARTとチームの規模が最適化されるため、一度に処理できる仕事量が自動的に制限されます。
• 小さなバッチをサポートできるようにプロセスを調整する: 特定のバッチが大きすぎる場合には、プランニングと実行の調整が必要になることがあります。また、バッチを処理するのに必要な労力を減らすため、コンテキストに特有の変更が必要になる場合もあります。
• 適切なイネーブルメントを確保する: バッチサイズを縮小すると、多くの場合、発生する小規模なトランザクションの数が増えることになります。バッチサイズの最適化や縮小は、通常、アーキテクチャとインフラストラクチャをリファクタリングするためのイネーブラーのプランニングと実行を伴います。

#6 待ち行列の長さを短くする

重要な理由

待ち行列は、コミットされたバックログが実装待ちになると発生します。待ち行列が長いほど、新機能の待ち時間も長くなります。

何をすべきか

一般的に、各待ち行列の長さは、チームが直接制御できます。チームは次のようなさまざまなメカニズムで、待ち行列を短縮できます。

• ベロシティや負荷などのフロー指標 (下記を参照) を利用することで、チームは利用できるキャパシティの範囲内でコミットできます。PIオブジェクティブは、チームによるスコープを超えたコミットメントを制限し、新しい仕事の待ち行列がPIの期間を大きく上回ることのないようにします。
• イテレーションのタイムボックスを短くし、イテレーションのオブジェクティブを簡潔にすることで、当面の仕事に集中できます。
• 公式にまたは非公式に追加の仕事がリクエストされた場合には、バックログに追加して、待ち行列を短く保つ必要があります。

#7 没頭する時間を最適化する

重要な理由

ソリューション開発は、創造性、集中力、そしてチームメンバーによる知的作業に大きく依存しています。例えば、新しいソフトウェアフィーチャーを実装するには、開発者が特に開発中のコンポーネントに関連して、コードのさまざまなパート間に存在するいくつもの複雑な依存関係を処理する必要があります。「没頭する」とは、きわめて生産的な精神状態であり、その状態に入って維持するのには時間がかかります。

人が仕事の状況に完全に没頭するまでには15〜20分程度かかり、些細な外的要因によって簡単に集中が途切れてしまうことがあります。

何をすべきか

個人やチームが没頭し、それを維持するのを困難にしている要因がいくつかあります。WIPが多すぎる、会議が多すぎる、頻繁なコンテキストの切り替え、中断、開発ツールが足りない、CDパイプラインのインフラストラクチャなどです。

こうした要因が確実に解消されるようにすることは、すべてのリーダーやコーチにとっての重要なタスクです。次のような取り組みによって、没頭できる時間を増やせます。

• ミーティングとイベントを最適化する: あらゆる仕事のセッションの効率を、チームで評価する必要があります。その結果、例えば、ケイデンスに基づくイベント (デイリースタンドアップなど) よりも、チームメンバーが1日を通して対話する方がより生産性が高まることが明らかになるチームもあるでしょう。逆に、定期的な同期ミーティングをスケジュールすることで、コミュニケーションにケイデンスが生まれ、中断が最小限に抑えられることが分かるチームもあるでしょう。チームで定期的にすべてのミーティングをレビューし、必要なミーティングと出席者を把握する必要があります。
• 仕掛かり中の仕事をさらに制限する: コンテキストの切り替えは、多くの場合、WIPが多すぎるために起こります。任意の時点でアクティブな項目が少ないほど、仕事の中断は少なくなります。
• 革新的なコラボレーションパターンを使用する: 没頭すると言っても、他の人から切り離されて単独で働くという意味ではありません。ペアワークやモブプログラミングなど実践により、より深く没頭し、集中力を高めることができます。
• 作業成果物の健全性を向上させる: チームは、健全なコードとアセット基盤を維持する必要があります。これらを維持できないと、システムを効率的に発展させ、維持するのに必要な仕事が増えます。

#8 既存の方針と実践を修正する

重要な理由

トランスフォーメーションをリードする人が、最新の手法を活用したいと思うのは妥当です。ところが、往々にして、リーダーは従来の手法を維持しようとします。こうした新旧の実践の中には互換性がないものもあり (デザインを次第に発展させる手法と事前にデザインを確定する手法など)、チームは困難な状況に陥ります。そうなると、互いに矛盾するポリシーに従うふりをして透明性が下がるか、開発を進めながらもシステムに抵抗し、進捗を遅らせて内部での衝突を招くかのいずれかです。いずれにしても、互換性のない新旧のプラクティスはシステムを通じたフローを妨げ、企業全体が中途半端なアジャイルモードに陥ります。

注意すべきポイント

リーダーやチェンジエージェントがまず認識すべきことは、たとえ経営トップがリーンアジャイルトランスフォーメーションを支持していたとしても、おそらく従来のポリシーや実践は残るという点です。以下に、いくつか例を挙げます。

• アジャイルチームの実践に加えて、従来型のプロジェクトおよびプログラムマネジメント (アーンドバリューマネジメント、作業分解計画、統合日程計画、プロジェクトコスト中心の会計など) が存続している
• 透明性​と客観的証拠に基づくシステムに移行した後も、マネジメントへの進捗報告を継続している
• 古いタイムシートも残っている状態で、アジャイルライフサイクル管理 (ALM) ツールにも勤務状況を記録するため、開発者が二重に報告しなければならない
• 「いつもそうしてきたから」という理由で、例えば、設計仕様の文書化や重要でないコードのトレーサビリティ、その他規制で義務付けられていない実践を要求している
• あらゆる不具合に対して、見つけて修正して次に進むのではなく、根本原因分析と文書化を強制している
• 「品質に関する関心の分離」のため、それが義務付けられていない場合でも、開発者、テスター、V&Vチームを分けている
• チームに従来のフェーズゲートレビューを受けさせている
• マネージャーによるアーティファクトのレビューを要求し、マイクロマネジメントの負担をかけている
• 報酬とパフォーマンスのポリシーによって、間違った種類の行動が評価されている
• すべてのチームのメトリクスを収集し、パフォーマンスの指標として使用している

何をすべきか

残念ながら、上記のリストは、決してすべてを網羅しているわけではありません。リーダー、スクラムマスター、コーチ、SPCは、常にこれらを含むフローの阻害要因に目を配る必要があります。既知の問題があれば、LACEがトランスフォーメーションロードマップに組み込んで対処する必要があります。フローの阻害要因となったり、余計な仕事を増やしたりする従来型の実践やポリシーが新たに明らかになった場合には、直ちに対処が必要です。

チームフローを測定する

測定していないものを改善することは困難です。SAFeのメジャー＆グローガイダンスでは、コンピテンシー、フロー、成果という3つの測定カテゴリを設けて、企業が革新的なビジネスソリューションを迅速に提供する能力をアセスし、改善できるようにしています。このガイダンスでは、フローの指標として、フロー配分、フローベロシティ、フロー時間、フロー負荷、フロー効率、フローの予測精度の6つを設けています。フローベロシティとフロー配分は、特にチームフローとの関連性が高く、以下でも取り上げます。

フローベロシティ

図4は、チームのフローベロシティの例です。この新たに結成されたチームは、当初はベロシティが不安定ですが、一部高いスループットも見られます。ところが、後になって取り組んでいたストーリーがより広範なシステムにうまく統合できない、あるいはすべての非機能要件を満たしていないことが判明しました。つまり、実際は「完了」していなかったのです。

この場合の適切な対応は、完了の定義 (DoD) をより厳密にして、その質を上げることです。そうすることで、デリバリーのベロシティは低下しますが、各ストーリーの質は向上します。時間の経過とともに、チームの体制が整い、より安定した、質の高い、ハイパフォーマンスな状態へと移行します。前述のように、情報を正しく解釈するためには、定量的データに定性的データを組み合わせる必要があります。

例えば、ベロシティの変化は、多くの場合、チームの基本的な生産性の実際の増減を示しています。ただし、新しいビジネス分野やテクノロジースタックへの移行、またはフローを改善するためにより小さな作業項目にシフトしようとする取り組みが反映されている場合もあります。

同じく重要な点として、こうした指標はアジャイルチーム同士の比較には使用できません。チームごとにローカルコンテキストが異なると考えられるからです。特定のベロシティを目標に設定したり、ベロシティをパフォーマンスの指標として使用しようとしたりすることは、改善に結びつかないだけでなく、場合によっては逆効果になる恐れもあります。

フロー配分

図5は、あるチームのフロー配分の例です。各PIの境界で測定された、システム内のさまざまな作業項目が示されています。

一般に、作業項目のバランスは、チームとシステムの健全性のバロメーターです。この例では、一部の技術的負債を解消するため、あるいは今後の新しい機能をサポートするために、アーキテクチャ (イネーブラー) への大規模な投資が必要だったようです。しかし、こうした指標は、各チームのコンテキストや責任に応じて、チームごとに大きく異なると考えられます。例えば、チームの中には、現在のシステムのメンテナンス業務が占める割合が高いところもあれば、新規開発を一手に引き受けているところもあります。

フローベロシティとフロー配分に加え、同じくSAFeのフロー指標であるフロー時間、フロー負荷、フロー効率、フローの予測精度も、チームにとって重要です。前述のように、定量的な指標は、それとは異なる定性的な洞察と併せて考える必要があります。常に判断力が求められます。

最終更新: 2022年12月9日