"SAFeを評価する"を読んで見た
こんにちは@TakahiRoyteです。
今回はMark Balbes氏の"Evaluating SAFe（SAFeを評価する）"を読んで、客観的にSAFeがどう見られているかを理解し、それに対する回答をSPCとしてどう考えられるかを考えてみます。
Balbes氏が考えだしたエンタープライズアジャイルの要件は以下の6点です。
・バリューストリーム中心で組織を作る
・依存関係はできるだけ壊し、壊せないなら管理する
・すべてにおいて複雑性を容赦なくシンプルにする
・コミュニケーションを促す
・硬直さと戦って戦って戦う
・不確実性を最小化する
それぞれに対してYes/NoでSAFeがBalbes氏の要件を満たしているかを見ていってます。
バリューストリーム中心で組織を作る
Yes. SAFeは企業のポートフォリオレベルでバリューストリームに対して取り組んでいる。実際、SAFeはバージョン5.0から新たな原則 #10 Organize around value（顧客価値を創造するために組織を作る）が追加された。
バリューストリームとは、製品やサービスが生み出す価値が最終的に顧客に届けられるまでの一連のプロセスです。要は、顧客にとっての価値を中心に組織が作られているかが問われています。例えばコーヒー豆のECサイトがあるとします。そのECサイトを中心に、豆の仕入れチーム、ロジスティクスチーム、カスタマーサポートチーム、サイト開発運営チームが作られていて、それらが上手く共同で働く仕組みができているかということ。
これはECサイトの例で言えば当たり前に思うかもしれません。ですが巨大企業になると、バリューストリームが分断されてそれぞれのフェーズごとにサイロ化された縦割りシステムになっている、なんてことがよくあります。それでも複数チームにおいてアライメントが取れていればいいのですが、必ずしもそうではないのが現状です。
依存関係はできるだけ壊し、壊せないなら管理する
Yes and No. SAFeは「継続的デプロイ、オンデマンドのリリース」という依存関係をなくすための良い哲学があります。継続的なデプロイにより、リリーストレインにいる複数のチームはコードを共有しチーム間の依存関係に対しフレキシブルに最小化できる。リリースオンデマンドはデプロイされたコードがビジネス上で必要な時にすぐ利用可能になる。
これを超える範囲については、SAFeは依存関係をなくすより管理する方式を取っている。これはチーム間の共同作業により行われるが、これこそがSAFeが批判される複雑性に繋がる。
デプロイとリリースの話は、コードは継続的にデプロイし、スイッチなどで実ユーザーが触れられるようリリースする、という方式について説明しています。デプロイとリリースの切り分けは実際大規模開発においては効果を発揮するでしょう。小規模ならそのスイッチングの仕組み作ることがムダになるか微妙なところでうす。
チーム間の共同作業による管理は、SAFeや他のどの手法でも結局難しいでしょう。依存関係管理専門の役職なども考えられますが、結局それぞれの機能について一番深く理解しているのはそれぞれの機能の担当チームなのでそのチーム間で解決するのがベストなのではないでしょうか。
すべてにおいて複雑性を容赦なくシンプルにする
No. SAFeはマネジメントとテクニカルなガバナンスを効かせるために複数のレイヤーを設けることで複雑性が増す。そもそも複雑性はテクノロジーや組織に内在しているものであり、だからこそSAFeを使うとも言える。アジャイルが求められる環境に複雑性が存在するのは当たり前の状況とも言えるが、SAFeはこの点についてメソドロジーを提供していない。
Balbes氏も触れていますが、大規模開発の時点で複雑性は避けられないもので、そのためにある程度のガバナンスを効かせるのは必要なことです。大規模で技術的なガバナンスを掛けないとどうなるかは自明の理です。具体的なメソドロジーは提供していないと批判的な論調ですが、System Architectやより大規模ならSolution Architectを置くなど、規模に応じたレイヤーを設けることで
コミュニケーションを促す
Yes. メソドロジーとしてのSAFeは、複数のコミュニケーションパスとセレモニーによりすべてのメンバーたちの間でアラインメントが取れるよう考えられている。
コミュニケーションがアジャイルのすべてです。アジャイルマニフェストに掲げられているように、それが実現できていないのにアジャイルという看板掲げていたらKen SchwaberだけじゃなくてJeff Sutherlandも看板奪いに道場破りに行くでしょう。
硬直さと戦って戦って戦う
No. SAFeは非常に厳密な構造を導入する。構造への変化はSAFeの新バージョンにより実現される。これはSAFeを信じ従う非アジャイルかつ硬直した環境になれた組織に不幸をもたらす。私の同僚たちがSAFeの成功事例について話す時、たいてい「SAFeやってるよ。だけど……」から始まる。
厳密な構造は確かにSAFeの特徴です。ですが「厳密な構造＝悪」ではないと思っています。「いかにビジネスアジリティを高めるか」を考えた末に作られた効率的な構造がSAFeであり、SAFeで定義されている各チームでありロールなのだと思ってます。
また、チームやロールの定義以外でSAFeが厳密に感じる理由は、Big PictureやImplementation Roadmap（導入ロードマップ）などが揃いすぎていることも理由にあると思います。他にこんな親切なフレームワークあるんですかね？もちろんこれらの教材は必ずその通りにやらなければならないOnly Wayではなく、「道案内」で使えとSAFe内でも言われています。だからこそ、「SAFeやってるよ。だけど……（自分達はここはカスタマイズしてるよ）」みたいに繋がるのかな、と。
不確実性を最小化する
Yes. SAFeには予測姓を高めるのに充分なプランニングミーティングとフィードバックループがある。さらに、SAFeは予期せぬ悩みに対応するための時間を確保するためのセーフガードも存在している。
リーンアジャイルは不確実性に立ち向かうためのツールなので、SAFeがそれに対して考えられて作られているのは当然のことです。
まとめ
総評としてBalbes氏は自分の定義した要件も満たしているし、「アジャイルを理解している企業には次のステップとして良いフレームワークだろう。ただし、まだアジャイルでない企業にとって、よりシンプルなアジャイルを体験しないままSAFeへ直接踏み込むことはおすすめしない」としています。
これに対してSAFeは自らImplementation Roadmapというアンサーを持ってます。SAFe自体も、Teamレベル、Large Solutionレベル、Portfolioレベル、Fullレベルと4つのコンフィグレーションを定義しており、企業のレベルに合わせて段階的に進められる道筋は実はSAFe内で用意されているのです。もちろん、そのImplementation Roadmapのジャーニーを進むためにはSPCやSPCを育てるというエグゼクティブ層の判断は必要です。
そういったことを理解しているFortune 100企業の70%はすでにエグゼクティブ層主導でSAFeに取り組んで結果を出しています。一刻も早く、日本の企業にもSAFeのような企業レベルのアジャイルを取り入れてドラスティックな変化を生み出すことを期待していますし、私としても早くお手伝いしたい限りです。
それでは、Stay SAFe（気をつけてね！）。
（SAFeの動画は最後に決めゼリフでこれを言う。笑）
いいなと思ったら応援しよう！
