先日、スケールド・アジャイル・フレームワーク（SAFe）の数あるトレーニングのうち、SAFe プログラム・コンサルタント（SPC）のトレーニングを受講しました。その後 SPC の試験に合格するために SAFe の資料を熟読し、その甲斐あって、なんとか SPC の試験に合格することができました。
今回の SAFe プログラム・コンサルタント（SPC）は、前回の SAFe Agilist に次いで二回目のトレーニングだったので、一回目とは異なりすでに SAFe の知識と経験があったためか、あまり抵抗も感じず、素直に頭に入ってきました。
また一回目の SAFe Agilist の時は SAFe に対する理解が浅かったためか、トレーニングを受講し試験に合格した後も、「こんなもの実際に使えるのか？」と非常に SAFe に対して懐疑的でしたが、今回の SPC は実際に組織に SAFe を導入した後だったこともあり、SAFe を勉強すればするほどそのフレームワークや導入プロセスに共感を覚えることができ、「これは案外使えるかもしれない」と思うようになりました。
ところでスケールド・アジャイル・フレームワーク（SAFe）ってナニ？
最近エンタープライズ・アジャイルが注目されています。エンタープライズ・アジャイルはこれまでのチームという小さな単位（特にソフトウェア開発）で用いるアジャイルとは異なり、アジャイルを企業全体という大きな単位で用いて、迅速に価値を顧客へ届けようとする大規模なフレームワーク、かつシステムです。グローバル競争がますます激しくなる今、企業にとって Time to Market がこれまで以上に重要になってきており、その解決方法としてエンタープライズ・アジャイルが注目されています。
エンタープライズ・アジャイルには二つのフレームワークがあります。一つはディシプリンド・アジャイル・デリバリー（Disciplined Agile Delivery: DAD）フレームワーク、そしてもう一つがスケールド・アジャイル・フレームワーク（Scaled Agile Framework: SAFe）です。
僕はディシプリンド・アジャイル・デリバリーは詳しくないので確かなことは言えないのですが、僕のイメージでは、ディシプリンド・アジャイル・デリバリーは小さなアジャイルをボトムアップ的に積み上げ、企業レベルで組織化するためのフレームワークです。一方スケールド・アジャイル・フレームワークは、はじめから企業まるごとアジャイルな組織に作り変えるためのフレームワークです。
たくさんの乗客を運ぶ船に喩えて言えば、ディシプリンド・アジャイル・デリバリーはたくさんの小さな船で多くの乗客を運ぶような感じでしょうか。乗客を安全に目的地に届けるためには、それぞれの船が航路や運航方法についての情報を正しく共有する必要があります。
一方スケールド・アジャイル・フレームワークは、一隻の巨大なクルーズ船のような感じでしょうか。クルーズ船を作るためには小さな船とはまったく違った設計が必要になります。またその運航には様々な異なった役割を持った専門のクルー達が必要です。特別設計の大型船と、クルー達のチームワークがあってはじめて、多くの乗客を安全に目的地まで届けることができます。
僕のイメージが正しいかどうかは別として、米国 Fortune 100 に連なる大企業の 70% がスケールド・アジャイル・フレームワークを採用しているところを見ると、今のところ大企業の幹部達は小さな船での旅よりも、大型クルーズ船による優雅な旅を好んでいるようです。
リーンシックスシグマで上手くいかなかったこと
リーンシックスシグマもフレームワークの一つです。DMAIC や DMADV のように、問題に応じて最適なフレームワークを選び、その中で最適なツールを使って問題を解決します。またリーンシックスシグマを企業レベルで実践するために、チャンピオン、マスター・ブラックベルト、ブラックベルト、グリーンベルトなどの組織的な役割やその導入方法も定義しています。
しかしリーンシックスシグマはプロジェクト志向が強いことや、チームが一時的／暫定的であるため、問題解決が部分的・限定的なものになりがちです。
またプロジェクトのリーダーやチーム員は本業とは”別に”リーンシックスシグマのプロジェクトを実施することが多くなるため（ベルト認定プロジェクトなど）、プロジェクトのスケジュールが曖昧になるだけでなく、リーンシックスシグマが「本業を妨げる余計な仕事」として捉えられることもあります。
つまりリーンシックスシグマのプロジェクトは、組織全体の最適化や、本業としてのプロジェクト遂行が難しいところがあるのです。
スケールド・アジャイル・フレームワーク（SAFe）とリーンシックスシグマ
僕が所属する組織がスケールド・アジャイル・フレームワークを取り入れたとき、「え、また違うフレームワークを取り入れるの？すでに SCRUM もやっているし、DMAIC や DMADV もやってるし、これ以上新しいフレームワークは必要ないよ！」と思いました。
しかしスケールド・アジャイル・フレームワークを勉強するにつれて、リーンシックスシグマを含めたすべての活動をこのフレームワーク上に取り入れることができるのではないか、と思うようになりました。例えばリーンシックスシグマに関して言えば、
- 2週間ごとの Retrospective （振り返り）で問題点を洗い出し、潜在的なリーンシックスシグマのプロジェクトをチーム・バックログに入れる
- リーンシックスシグマのプロジェクトを本業の一環として SCRUM で実施する
- 大きなリーンシックスシグマのプロジェクトはビジネス・オブジェクティブとしてプログラム・バックログに入れる
- 10週間ごとの Inspect and Adapt Workshop では、リーンシックスシグマのツールを使って、チームで問題の解決にあたる
- 問題（リスク）を未然に防いだり、品質を維持するために、ユーザーストーリや機能（Feature）のアクセプタンス・クライテリア（受入基準）にリーンシックスシグマの項目を追加する
- 品質の関する仕様を Compliance として Solution Intent の中で定める
などを行うことにより、スケールド・アジャイル・フレームワーク上でリーンシックスシグマが活かせるだけではなく、本業（仕事）としてリーンシックスシグマのプロジェクトが行え、かつ組織全体の最適化が計れるのではないかと思いました。また アジャイル（SCRUM）でリーンシックスシグマのプロジェクトが管理できるので、プロジェクトの進捗も把握しやすくなります。
今は結論として、「スケールド・アジャイル・フレームワークって結構良いんじゃない」というところに落ち着いています。
スケールド・アジャイル・フレームワークが面白いので、これからはリーンシックスシグマだけでなく、スケールド・アジャイル・フレームワークについてもこのブログで書いていきたいと思います。
Note: エンタープライズ・アジャイルについての別のブログを始めました。そちらの方も宜しくお願いします。