検査と適応

改善とはものごとのあり方を変えることである。今のままで大丈夫だと思い込んだら、改善はできない。何かを変えてみよう。

─大野耐一

検査と適応の概要

継続的な改善という理念は、アジャイル(「……チームがもっと効率を高めることができるかを定期的に振り返り……」─アジャイル宣言)やリーン思考(カイゼン)やSAFeに不可欠である。SAFeでは、容赦ない改善をリーンの家の4本の柱の1つとして取り込むことで、この理念の重要性を強調している。容赦ない改善を行うためのチャンスは開発全体を通して次々と現れる。しかし、この理念にリズムと同期を適用することで、「もっとうまくやれた点は何か」の検討に使う、専用の時間を確保することができる。計画に含まれる主な2つのチャンスは、チームの振り返りと、この検査と適応ワークショップである。

検査と適応(Inspect and Adapt:I&A)ワークショップは、各プログラムインクリメントの終わりに実施される重要なイベントである。I&Aは、次のPIのベロシティーや品質や信頼性を向上するために必要な改善アクションについて、検討し、データを集め、問題を解決し、措置を講じるために、定期的に設けられる時間である。このワークショップにはプログラムの利害関係者全員が参加する。ワークショップの成果として一連の改善ストーリーが作成されるが、これを次のPI計画のバックログに追加することもできる。こうすることで、すべてのARTがPIごとに向上していく。規模の大きなソリューションでは、通常、同様の検査と適応ワークショップを価値のストリームレベルでも実施する。

詳細

SAFeでは、リーン-アジャイルの考え方の柱の1つである容赦ない改善を実施するための主要メカニズムとして、検査と適応(I&A)ワークショップを用意している。I&Aワークショップは、プログラムインクリメントそれぞれの終わりに実施し、そこで前のPIの実行と成果について検討し、次のPIの改善バックログ項目を作成する。プログラムレベルでも価値のストリームレベルでも行うことができる。このページでは、主にプログラムのイベントに焦点を絞って説明する。システム構築のプロセスを変更するのに最も適しているのは、そのシステムを構築する担当者だからである。

プログラムのI&Aワークショップには、可能な限り、システム構築に携わったすべての人が参加するべきである。これには、アジャイルチームリリース列車エンジニア(RTE)システムおよびソリューションアーキテクト/エンジニアリングプロダクト管理ビジネス責任者や、列車に乗っているその他の人たちが含まれる。価値のストリームの利害関係者がこのワークショップに出席することもある。

I&Aワークショップは次の3部から構成される。

  1. PIのシステムデモ
  2. 定量的測定
  3. 振り返りと問題解決のワークショップ

PIのシステムデモ

システムデモがワークショップの第1部である。このシステムデモは、それまで行ってきた2週間ごとのデモとは少し異なり、PIの過程で蓄積されたすべてのフィーチャーを見せるためのものである。また、通常は聞き手も普段より多い。たとえば、いつもはいない顧客を代表する人が、このデモに参加するかもしれない。そのため、デモは普段よりいくらか公式になる傾向があり、通常は準備や主催に余分の作業が必要になる。それでも、他のシステムデモと同様に、このデモにも1時間以下の時間枠を設定し、抽象度を高く保って、重要な利害関係者が参加しフィードバックを返せるようにするべきである。

定量的測定

ワークショップの第2部では、合意に基づいて収集した定量的メトリックスを見直し、データと傾向について議論する。このための準備として、RTEと価値のストリームエンジニアは、情報を収集し、興味深い統計値や発見事項を示すための分析をし、測定結果を発表できるようにする。

重要な測定項目の1つにPI予測性測定がある。これは、チームがどれだけうまく納品できたかをPI目標に照らして自己評価し、達成したビジネス価値と計画とを比較するものである。デモ時に、ビジネス責任者や顧客やその他の利害関係者は、PI目標ごとに実際に達成したビジネス価値を評価する。その様子を図1に示す。(注:背伸び目標は、確約には含まれないが、実際の成績には含まれる。これも図1に現れている。)信頼性の高い列車なら、通常は80~100%の範囲になるはずである。それであれば、ビジネス担当者や外部の利害関係者は、効果的に計画を立てることができる。

図1.  PIパフォーマンスレポート

振り返りと問題解決ワークショップ

振り返り

その後、チームは短い(30分以内)振り返りを行う。この振り返りの目標は、対処したい問題を洗い出すことである。方法は1つに決まっているわけではなく、いくつかのアジャイルな振り返りの進め方が存在する[3]。その目標は、チームが対処できそうな少数の重要な問題を特定することである。

振り返りの出席者や特定した問題の性質に応じて、ファシリテーターはどれに対処したいかをグループが判断するのを手助けする。それから、自分たちでチームレベルの問題を解決するか、プログラムレベルの問題を選択して同じ問題に取り組みたい人たちと一緒に作業するかを選択する(後者の方が一般的である)。このように自主的に選択すると、機能横断的なさまざまな視点から問題を見ることができ、問題の影響を受けそうな人や問題に対処するモチベーションの高い人を、問題解決チームに含めることができる。

ビジネス責任者や顧客や経営陣といったARTの重要な利害関係者も、チームと一緒にこの振り返りに参加する。これらの利害関係者がチームの制御外にある障害を取り除けることが多いし、それができるのは彼らだけであることも多い。

問題解決ワークショップ

大規模なプログラムレベルの問題に系統的に対処するには、構造化された、根本原因分析による問題解決ワークショップの形式を適用するとよい。根本原因分析は、単に症状に対処するのではなく、問題の根本的な原因を識別するために使用される、問題解決ツールセットである。このセッションは、通常、2時間以内の時間枠で、RTEなどがファシリテーターとなって実施する。

次の図2は、このワークショップの進め方を示したものである。それぞれのステップについて後のセクションで説明する。

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

どの問題を解決するかに合意する

アメリカの発明家であるチャールズ・ケタリングの有名な言葉に、「問題をうまく述べることができたら、半分解決したようなものである」というものがある。この時点で、チームは対処したい問題を自分で選択している。しかし、問題が何であるかについて、本当に合意がなされているだろうか。視点が異なってはいないだろうか。それを確認するために、チームは数分を使って、問題を記述し、何をどこでいつと、影響とを、できるだけ簡潔に検討する。図3は、バハライドシステムエンジニアリングの例である。

図3.  問題記述の例

根本原因分析を行う

私たちは、特性要因図なぜなぜ分析など、以前から存在する効果的な問題解決ツールを利用することを推奨している。特性要因図は、フィッシュボーン図や石川ダイアグラムとも呼ばれる、具体的なイベントの原因やプロセスのばらつきの原因を調査するためのビジュアルツールである。図4のように、問題記述の名前を「背骨」の右端に書く。

図4.  主な原因が特定された特性要因図

問題を特定し、それを大きな分類にまとめて、背骨から分かれた骨として記述する。私たちの問題解決ワークショップでは、「人」、「プロセス」、「ツール」、「プログラム」、「環境」という大きな骨をあらかじめ書いている。しかし、これは適宜変更してよい。それから、解決したい問題の一因だと思われる要因をブレインストーミングで出し合う。原因を特定できたら、なぜなぜ分析で根本原因を特定する。「なぜ」を5回ほど問いかけることで、1つの原因の原因それぞれを発見しやすくなる。それを図に追加する。

最も大きな根本原因を特定する

パレート分析は、「80/20ルール」とも呼ばれるもので、全体としてもっとも大きな効果が得られるアクションの数を絞り込むための、統計的意思決定手法である。パレート分析は「80%の問題は20%の根本原因によって引き起こされうる」という原則を利用する。これが特に有効なのは、行動方針の数多くの候補が注目を争っている場合だが、複雑で全体的な問題を取り扱うケースではほとんどがそれに当てはまる。

原因の考え得る原因をすべて洗い出したら、チームメンバーは、最終的な問題を引き起こしている最大の要因と思われる項目はどれかについて、累積投票を行う。これは、最も問題があると思われる原因に対して、星を付けることで行うことができる(各グループメンバーに5つの星を配る。5つの星は、自分の判断で、1つの項目にまとめて付けてもいいし、複数の項目に分けてもいい)。その後、チームは図5の例のようなパレート図を作成する。この図には、大きな根本原因に関する全員の総意が現れる。

図5.  推定される原因のパレート図

新しく問題を記述しなおす

次のステップでは、最も大きい原因をリストから選び、問題として明確に記述しなおす。これには1分程度しかかからないはずである。根本原因まで非常に近いところまで来ているからである。

解決方法のブレインストーミングを行う

この時点で、根本原因から解決方法の案がいくつか見え始める。作業グループは、15~30分のセッションで、できるだけ多くの修正処置を考え付くだけ出し合う。このとき、ブレインストーミングの次のルールが適用される。

  • できるだけ多くのアイデアを出す
  • 批判や議論をしてはならない
  • 想像力を膨らませる
  • アイデアを変化させたり組み合わせたりする

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

それから、チームは、最も有望な最大3つの解決方法について、累積投票を行う。これらは、改善ストーリーや改善フィーチャーとして、そのままその後のPI計画セッションの入力となる。そのセッションで、RTEは、関連する改善ストーリーが反復計画に確実に含められるよう気を配る。計画に含めることで、他のバックログ項目と同じように、確実にアクションが起こされ、リソースが割り当てられる。これで振り返りのループが閉じ、現在の状態を改善するために必要な人とリソースが確保される。

このようにすることで、プログラムレベルと価値のストリームレベルの両方で、問題解決が系統立てて日常的に行われる。そして、チームメンバー、プログラムの利害関係者、価値のストリームの利害関係者は、価値のストリームが容赦ない改善の道を確かに進んでいることを確信できる。

価値のストリームレベルの検査と適応

ここまでで、プログラムのコンテキストにおいて問題解決をするための厳密な方法を紹介した。そこには価値のストリームレベルの主な利害関係者が加わることが多く、ソリューション開発をうまく進めるにはそれが好ましい。しかし、規模の大きい価値のストリームでは、同じ形式の検査と適応ワークショップが追加で必要になることがある。ワークショップの参加者にすべての利害関係者を含めることはできないので、対処するコンテキストに応じて最適な利害関係者を選択する。これには、価値のストリームレベルの主要利害関係者と、さまざまなARTやサプライヤーの代表者が含まれる。


さらに知りたい場合

[1] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011. (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

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

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

Last update:29 December 2015