Kaizen is about changing the way things are. If you assume that things are all right the way they are, you can’t do kaizen. So change something!

—Taiichi Ohno

インスペクト＆アダプト

インスペクト＆アダプト: 概要

インスペクト＆アダプト (I&A) は、各PIの終わりに開催される重要なイベントで、ソリューションの現状がデモで示され、評価されます。その後、チームは構造化された問題解決ワークショップを通じて改善バックログ項目を特定し、振り返ります。

アジャイルソフトウェア開発宣言は、原則「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」を通じて、継続的な改善の重要性を強調しています。

また、SAFeには「たゆまぬ改善」が4つのSAFeコアバリューの一つとして、さらに継続的な学習文化のコアコンピテンシーの特性の一つとして含まれています。PI全体を通じて継続的に改善の機会 (例えば、イテレーションレトロスペクティブ) がありますが、一部の構造、ケイデンス、同期を適用することで、複数のチームやアジャイルリリーストレイン全体で改善点を特定するための時間も確実に確保できるようになります。

詳細

すべてのARTステークホルダーは、アジャイルチームと共にI&Aイベントに参加します。その結果、次のPIプランニングイベントのためのARTバックログに入る一連の改善バックログ項目が得られます。このように、すべてのARTはすべてのPIを改善します。類似のI&Aイベントがソリューショントレインによって開催されます。

インスペクト＆アダプトイベントは、以下の3つの部分で構成されています。

PIシステムデモ
定量的、定性的な測定
レトロスペクティブと問題解決ワークショップ

可能な限り、ソリューションの構築に関わるすべての人々がI&Aに参加するべきです。 ARTの場合、次の人々が含まれます。

さらに、ソリューショントレインのステークホルダーもこのイベントに参加できます。

PIシステムデモ

PIシステムデモは、インスペクト＆アダプトの最初の部分であり、各イテレーション後の通常のシステムデモとは少し異なります。このデモでは、ARTがPIにおいて開発したすべてのフィーチャーを示します。通常、対象者はより広範で、例えば、顧客やポートフォリオの代表者がこのデモに参加する可能性が高くなります。したがって、PIシステムデモはどちらかというと正式なものになる傾向があり、通常よりも綿密な準備が必要です。しかし、他のシステムデモと同様に1時間以下のタイムボックスで実行され、ステークホルダーが積極的に参加しフィードバックを提供するためには、抽象度が十分高いものでなければなりません。

PIシステムデモの前に、または一部として、ビジネスオーナーは各アジャイルチームと協力して、各チームPIオブジェクティブのビジネスバリューの実績値のスコアを算出します (図1参照)。

「達成率」は、「プラン時の値」と「実績値」の列のビジネスバリューを別々に合計して計算されます。アンコミットオブジェクティブは、プラン時の値の合計には含まれていませんが、実績値の合計の一部となります。その後、実績値の合計をプラン時の値の合計で割り、図1で示されている達成率を計算します。

図1 各チームのビジネスバリューの実績値のスコアを算出する

定量的、定性的な測定

I&Aイベントの2番目の部分では、チームは収集することに合意した定量的および定性的な測定を共同でレビューし、その後、データと傾向について議論します。これに備えて、RTE (リリーストレインエンジニア) とソリューショントレインエンジニアは、情報を収集し、潜在的な問題を特定するためにそれを分析し、その結果をARTにプレゼンテーションするのをファシリテートします。

図2に示すように、各チームのビジネスバリューのプラン時の値と実績値が集計され、ART予測精度の測定を作成します。

図2 各チームのビジネスバリューのプラン時の値と実績値からART予測精度の測定が作成される

信頼性の高いトレインは80〜100パーセントの範囲で運用されるべきです。これにより、ビジネスとその外部ステークホルダーは効果的にプランを立てることができます。 (注: アンコミットオブジェクティブは、プランされたコミットメントからは除外されますが、図1で示されている通り、ビジネスバリューの実績値には含まれています。)

レトロスペクティブ

その後、チームは短時間 (30分以下) のレトロスペクティブを実施し、問題解決ワークショップで取り組みたいいくつかの重要な問題を特定します。これを行う決まった方法はありません。いくつかの異なるアジャイルレトロスペクティブの形式が使用できます[3]。

レトロスペクティブと特定された問題の性質に基づいて、ファシリテーターはグループが取り組みたい問題を決定するのを支援します。各チームがひとつの問題に取り組むか、より一般的には、同じ問題に取り組みたいと思っている異なるチームの個々の人々から新たなグループが形成されます。この自己選択により、問題の機能横断的かつ異なる視点が提供され、問題の影響を受けた人々と問題に最も積極的に取り組む人々をひとつにします。

主要なARTステークホルダー (ビジネスオーナー、顧客、マネジメントを含む) は、レトロスペクティブと問題解決ワークショップのチームに参加します。ビジネスオーナーは、チームが制御できない阻害要因をしばしば取り除くことができます。

問題解決ワークショップ

ARTは、組織上の問題に対処するための構造化された根本原因問題解決ワークショップを開催します。根本原因分析は、症状をただ修正するのではなく、問題の実際の原因を特定するために使用される問題解決ツールを提供します。 RTEは通常、2時間以下のタイムボックスでセッションをファシリテートします。

図3は、問題解決ワークショップのステップを示しています。

図3 問題解決ワークショップの形式

次のセクションでは、プロセスの各ステップについて説明します。

解決すべき問題について合意

アメリカの発明家チャールズケタリングは、「問題を手際よく表現すれば、問題は半ば解決されている」と言ったとされています。この時点で、各チームは自分たちが対処したい問題を自己選択しています。しかし、チームは問題の詳細について同意しているでしょうか、それとも異なる視点を持っている可能性が高いでしょうか。このために、チームは、「何が」、「どこで」、「いつ」、そして「影響」をできるだけ簡潔に強調して問題を明確に述べるために数分間を費やすべきです。図4は、効果的に記述された問題文を示しています。

図4 問題の記述の例

根本原因分析を実行する

効果的な問題解決ツールには、フィッシュボーンチャートと「5 Whys」が含まれます。特性要因図としても知られるフィッシュボーンチャートは、特定のイベントの原因やプロセス内のバラツキの原因を探求する視覚的なツールです。図5は、前の問題文の要約が「魚」の頭部に書かれたフィッシュボーンチャートを示しています。

図5 主要なリソースが特定されたフィッシュボーンチャート

問題解決ワークショップでは、主な骨格は通常、人々、プロセス、ツール、プログラム、そして環境というデフォルトのカテゴリから始まります。ただし、これらのカテゴリは適切に適応させるべきです。

チームメンバーはその後、問題解決に貢献すると思われる原因をブレインストーミングし、これらのカテゴリーに分類します。潜在的な原因が特定されたら、その根本的な原因は5 Whysテクニックで探求されます。「なぜ」と5回尋ねることで、前の原因の原因が明らかになり、図に追加されます。適切な根本原因が特定されると、プロセスは一度停止し、次の原因に対して同じプロセスが適用されます。

最大の根本原因を特定する

80/20ルールとも呼ばれるパレート分析は、全体的に最も大きな影響をもたらすアクションの数を絞り込むために使用されます。それは、問題の80％を引き起こす原因が20％であるという原則を使用します。それは、複雑な組織上の課題では一般的となっている、多くの潜在的なアクションに注意を向ける必要がある場合に有益です。

考えられるすべての原因の原因が特定されたら、チームメンバーはそれぞれが元の問題に対して最も重要な要因と考える項目に累積投票を行います。これはドット投票によって行うことができます。例えば、各人は5票を得て、最も問題だと思われる一つまたは複数の原因を選びます。その後、チームは投票をパレートチャートにまとめます。図6の例では、最も重要な根本原因についての集団的なコンセンサスを示しています。

図6 有力な原因のパレートチャート

新しい問題を再記述する

次のステップは、最も多くの票を得た原因を選び、それを明確に問題として再度表現することです。再記述には数分しかかからないはずです。なぜならチームは明らかに根本原因を理解しているからです。

解決策のブレインストーミング

この時点で、再定義された問題はいくつかの潜在的な解決策を示し始めます。チームは固定のタイムボックス (約15〜30分) 内で可能な限り多くの是正措置をブレインストーミングします。ここではブレインストーミングのルールが適用されます。

できるだけ多くのアイデアを出す
批判や議論を許さない
想像力を飛翔させる
アイデアを探求し組み合わせる

改善バックログ項目を作成する

その後、チームは最も実現可能なソリューションを最大3つまで累積投票します。これらの潜在的なソリューションは、改善ストーリーとフィーチャーとして記述され、次のPIプランニングイベントで計画されます。そのイベント中、RTEは、特定の改善を提供するために必要な関連する仕事がプランされていることを確認します。このアプローチによりループが閉じられ、その結果、アクションが実行され、人々とリソースが必要に応じて現状の改善に専念することを保証します。

このプラクティスに従うと、問題解決はルーチン化し、体系的になり、チームメンバーやARTステークホルダーは、トレインがたゆまぬ改善という道のりを進んでいることを確認できます。

ソリューショントレインのためのインスペクト＆アダプト

ここでは、1つのARTにおけるコンテキストでの問題解決への厳密なアプローチを説明しています。 ARTがソリューショントレインの一部である場合、I&Aイベントには、ソリューショントレインからの主要なステークホルダーがしばしば含まれます。しかし、大規模なバリューストリームでは、同じ形式に従って、追加のソリューショントレインのI&Aイベントが必要になる場合があります。

ソリューショントレインに参加する人数の多さから、大規模ソリューションのI&Aイベントには全員を含めることができず、問題に対処するのに最適なステークホルダーが選ばれます。この人々のサブセットは、ソリューショントレインの主要なステークホルダーと、さまざまなARTとサプライヤーからの代表者で構成されます。

詳しく学ぶ

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[3] Derby, Esther, and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2009.

最終更新： 2023年1月22日