我々は「改善マインド」を必要とする。それは会社の改善を絶えず推進するための果てしない危機感である。

— ジェフ・サザーランド、スクラムの共同提唱者

 

 

検査と適応の概要

「改善マインド」の原理原則がアジャイル開発とリーン思考に不可欠である。(アジャイル宣言:チームがもっと効率を高めることができるかを定期的に振り返り。改善はSAFeにおけるリーンの家の3本柱の1つである。)SAFeの中でこれを示す方法の1つが、各プログラムインクリメント(PI)の終盤に開催された検査と適応(I&A)ワークショップである。チームに関するスプリントデモや振り返りと同様、I&Aはリリース列車に関するイベントである。I&Aは、定期的、プログラムに従い開催し、振り返りや問題解決の時間である。また、次のインクリメントのベロシティ、品質と信頼性を高めるために必要なアクションを識別し、改善アクションを採る。

I&Aの一部として、チームは適切な利害関係者にソリューションを現時点の状態でデモし、そして正しい軌道を進むために必要な迅速なフィードバックをもらう。その後、振り返りと問題解決ワークショップを行う。アジャイルチームが直面している課題の多くは、プログラムレベルで根ざしているので、このワークショップに出席する利害関係者は変化をもたらす権限が与えられている責任者でなければならない。ワークショップの結果は一式の改善ストーリーであり、プログラムの次のPIバックログに追加できる。そして、翌日のリリース計画中にすぐ組み込むことができる。

詳細

検査と適応ワークショップは、定量的と定性的な部分で構成される。定量的には、チームはソリューションをデモし、PI目標に対するフィーチャーの完成度を自己評価する。また、合意した他のプログラムレベルのメトリックスをレビューする。このデータを入手してから、定性的な部分(主観的)が始まる。このために、SAFeは構造化された「検査と適応」の根本原因分析及び是正アクション計画の形式をお勧めする。SAFeの検査と適応ワークショップは以下3部構成である。

  1. ソリューションのデモと顧客フィードバックの収集
  2. 定量的測定
  3. 問題解決ワークショップ

各構成要素を以下でさらに詳細的に説明する。

ソリューションのデモと顧客フィードバックの収集

一般的に、ソリューションデモは60-90分間の時間枠で行われる。ソリューションデモ(PI終了時のシステムデモ)中で、チームは適切な利害関係者へソリューションの新しいフィーチャーや、非機能要求へのシステムの適合性をデモする。このデモはプロダクト管理プロダクトオーナー及びシステムチームのメンバーによって実施される。システムの現状をデモすることにより、プログラムは正しい方向に進むための即時のフィードバックが得られる。この情報は、次のリリース計画策定ミーティングへの入力として使用される。リリース計画時に、ビジョンロードマップ、およびプログラムバックログが最新に更新される。また、この情報は後の問題解決ワークショップのインプットとして利用される。

定量的測定

ワークショップで最初行うことは定量的なARTメトリックスを考察することである。1つ主な測定はリリース予見性測定(RPM)である。この指標はPIで実際達成したビジネス価値と計画を比較するためのものである。ほかのプログラムメトリックスも収集され、レビューされ、議論される。

問題解決ワークショップ

次のセッションは収集したデータに関する定性的な振り返りである。その後、問題解決ワークショップが続く。参加者はプログラムのほぼ全員であり、主要な利害関係者を含む。参加者たちは振り返りで識別されたプログラムの課題から、対処したいものを識別する。その後、参加者たちはいくつかのグループに分かれて、グループ毎に特定の課題に対する是正アクション計画を作成する。是正アクション計画はグループ全体でレビューされる。最終的な結果は一連のプログラム改善ストーリーであり、これらのストーリーは翌日のプログラム計画用のバックログに追加される。

これを達成するために、構造化された、根本原因分析ワークショップの形式を推奨する。根本原因分析は、単に明らかな現象に対処することではなく、問題の根本的な原因を識別するために使用される問題解決ツールセットである。アジャイルチームが直面している課題の多くは、プログラムレベルで根ざしているので、このワークショップに出席する利害関係者は変化をもたらす権限が与えられている責任者でなければならない。このセッションは通常3時間以内の時間枠で、リリース列車エンジニアによって司会される。

根本な原因分析ワークショップの形式は以下のステップによって構成される:

  1. 解決しようとする課題を合意する
  2. 根本な原因分析ツールを適用する
  3. 一番大きな根本な原因を識別する
  4. 改善ストーリーに関するブレインストーミングを行う

解決しようとする課題に合意する

1つのグループとして、プログラムメンバーはプログラムが直面している主要な問題や障害を識別する。それから、それらの人達は自分のチーム内でチームレベルの問題を解決するか、あるいはプログラムの問題を選択し、同じ問題に取り組みたい人たちと一緒に作業するかを選択する。

根本な原因分析ツールを適用する

特性要因図5つのなぜパレート分析などを含む従来の効果的な問題解決ツールの利用を推奨する。

特性要因図

石川図としても知られている。特性要因図は、プロセス内の特定のイベントまたはバラツキの源となる原因を探すために利用するビジュアルツールである。図1に示したように、問題の名前は「背骨」の右端に書かれている。

図1.主要な原因が識別された特性要因図

図1.主要な原因が識別された特性要因図

各原因が特定され、主骨から枝分かれする骨のように、グループ分けされ、主要なカテゴリに分類される。我々のソフトウェア関連の問題解決ワークショップでは、主骨は「人」、「プロセス」、「ツール」、「プログラム」と「環境」と事前に分類される。もちろん、これは必要に応じ調整できる。それから、ブレインストーミングで、解決すべき問題に関する要因をチームメンバーは自分が思ったものを出し合わせる。原因が洗い出した後、「5つのなぜ」テクニックで根本的な原因を特定する。「なぜ」を5回ほど問いかけることで、1つの原因の各原因をより発見しやすくなり、それを図に追加する。

一番大きな根本な原因を識別する

「80/20ルール」としても知られているパレート分析は、統計的意思決定テクニックである。これを用いて、最も著しく全体な効果を導くアクションの数を絞り込む。パレート分析は「80%の問題は20%の根本原因によって引き起こされた」という原則を利用する。これは取り得るアクションのコースが注目を集めるために多数競いあうときにとりわけ役立つが、特に複雑で全体的な問題を取り扱うケースではほとんどそのような状況になる。

すべての原因の原因が識別された後、チームのメンバーは、問題を引き起こして最大の要因について投票する。この投票は、各人が最も問題だと思う原因に星印をつけることによって行うことができる。(各人に星印を5つに与え、そして各人が複数の根本原因に投票できる)。その後、チームは図2に示すパレート図を作成する。この図は一番大きな根本原因に関して、全体の総意を示す。

 図2.あり得る原因のパレート図

図2.あり得る原因のパレート図

改善ストーリーに関するブレインストーミングを行う

根本原因が特定された後に、解決の選択肢が通常容易に識別できる。チームは、多くの場合、単にいくつかの是正アクションをブレインストーミングし、それから再び投票によって、今後の期間に対処したいと思う1つまたは2つのこと、及びそれらを対処するためのステップを決める。選ばれたものは、プログラムバックログの改善ストーリーとして書き直す。次の計画策定セッションでは、関連の改善ストーリーがスプリント計画に入れられるように、リリース列車エンジニアは注意を払う。そうすることで、他のバックログ項目と同じように、確実に是正アクションが実施され、リソースが割り当てられるようにする。

このように、プログラムレベルの問題解決を定期的に体系的に行い、チームメンバー、そしてプログラムの利害関係者はこのプログラムは確実に継続的な改善の旅をしていることを確信できる


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. (邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007. (邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

[3] Derby, Esther and Larsen, Diana. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2009.(邦訳:アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き、オーム社、2007)

Last update: 22 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.