オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

インタビュー

SAFe (Scaled Agile Framework) 上級トレーナー Gerald Caddenさんへのインタビュー前編

2018年10月18日
Gerald Cadden
Gerald Cadden

8月末にSAFeのトレーナーやコーチの認定トレーニングである「Implementing SAFe」トレーニングを東京で実施するために来日されたGerald CaddenさんにSAFeにまつわる様々な質問をお聞きしました。前編は、ご自身のSAFeとの出会い、複数のアジャイル開発のフレームワークの選択や要素の組み合わせ、SAFeの実装を取り上げます。

インタビュアー:藤井 拓

SAFeとの出会いからSPCT取得まで

―― 本日は、お忙しい中インタビューにお時間を割いて下さいましてありがとうございます。

Caddenさん― 大歓迎だよ。

―― まず最初にすごく基本的な質問ですが、名字はどのように発音するのでしょうか。

Caddenさん― 「キャデン」です。

―― ありがとうございます。次の質問は、キャデンさんがどのようにSAFe® (Scaled Agile Framework®)と出会ったかというものです。以前、キャデンさんとお話をした際にアジャイル変革を推進するご経験が長いという話を伺ったのですが、SAFeとどのように出会ったのでしょうか?

Caddenさん― 私は、以前Valtech technologiesという会社に勤めており、そこでアジャイルコンサルタントとして、ニューヨークの大きな銀行向けの大きなプロジェクトに従事し、このお客様向けにスケールするためのフレームワークを作っていた。私ともう1名の方法論者でそのフレームワークを作っており、かなり作業が進んだ時点で私たちはその年のAgile Conferenceに参加し、Dean LeffingwellがSAFeを紹介するのを見たのだ。

―― 2012年ですか?

Caddenさん― そうです。

―― 私もその場にいました。

Caddenさん― そう、あれはSAFeの初期の大々的なプレゼンだった。そして、それを見た私は、SAFeが完成されたフレームワークとしてあるので、私たちは銀行向けのフレームワークの開発を止めてよいということに気づいた。そこで、そのことを私はDeanに話をし、Valtechから来た同僚に話した。私たちは、みんなでDeanと話をして、SAFeを導入すればよいことに気づいたのだが、それを行うためには認定を取り、我々の学びの旅を始めなければならなかった。そこで、私自身とValtechの他の同僚が3人ほどトレーニングを受けて、認定を取った。たぶん、私たちが認定を取った2番目のSPC (SAFe Program Consultant)のグループだと思う。

注:SPC (SAFe Program Consultant)は、SAFeのコンサルタント/トレーナーの認定。

―― 私は、2013年の2月にSPC認定トレーニングを受講し、その際にValtechの人が同じテーブルにいたのを憶えています。

Caddenさん― そうなんだ。私は自分のトレーニングの時期を忘れてしまったが、2012年の10月か、2013年だったと思う。それがSAFeとの出会いだった。私たちは、SAFeがすでに先行していたので、それを導入し始めるだけだった。それから、会社の同僚を認定し、そこから出発した。

Caddenさん

―― 分かりました。キャデンさんは、今やSPCT (SAFe Program Consultant Trainers)の一人になられているのですが、現在SPCTは何名ぐらいいるのでしょうか?

注:SPCT (SAFe Program Consultant Trainers)は、SPCのトレーナーの認定。

Caddenさん― 世界中に30-40名程度のSPCTがいると思う。毎年新たなSPCTが就任している。毎年、Scaled Agile, Inc.(以降、SAI社)以外のスポンサーからの候補者がSPCTプログラムに参加している。それらの候補者は書類一式を提出して、私やSAI社の他のSPCTがインタビューし、経歴を読み、プログラムに入れるかどうかを審査する。十分な能力がある人もいるし、能力のさらなる向上が必要な人もいる。このプログラムはこれまで何年か運営されてきた。私は、最初期のSPCTの一人であり、最初期のトレーニングを受講し、2014年の終わりにSPCTの認定を得た。私がSPCT認定を取得した時に10人ほどだったSPCTが現在40名ほどに増えているのである。

様々なアジャイル開発フレームワークの選択と組み合わせについて

―― 次に、様々なフレームワークについての質問をいくつかさせていただきます。過去、キャデンさんが製造業の会社でSAFeを導入された事例についてお聞きしたことがあります。その際に、当初LeSSとSAFeが導入するフレームワークの候補になったとお聞きしました。キャデンさんは、LeSSの実装を経験されたことはあるのでしょうか?

Caddenさん― いえ、ない。LeSSの実装を経験したことはないが、LeSSに関する文献はかなり読んだよ。ことフレームワークの話ということであれば、あなたの質問はおそらくなぜ他のフレームワークではなく、1つのフレームワークを選んだかということではないかと思う。

いいかな。LeSSもScrum@ScaleもDADもNEXUSもSAFeもすべて市場においてスケーリングするためのフレームワークとして名が通っている。それでも、SAFeが大勢を占めている。アジャイルの状況についてのVersion Oneの最新の調査によれば、SAFeは約29%のマーケットシェアを持つ。次がLeSSだが5%にしかすぎない。それでも、本当はそんなことにあまり意味はない。私は、自分達の状況においてフレームワークを評価し、自分達に適したものを判断すべきだと思う。

各フレームワークを眺めると、似た構造があり、同じゴールを達成しようとしているのである。Scrum@ScaleとLeSSは、それらがScrumはこういうもので、このように実行されるというものに忠実にあろうと熱心に試みようとしている。SAFeでもチームレベルではスクラムが正しいと考えるが、アジャイルさやアジャイルさの意味をさらに考えることでスクラム一辺倒にはなっていない。それが、私たちが価値のストリームの概念や異なる仕事の方法を編成している理由である。私たちは、スクラムがそうであるように単にチームの作業のためにアジャイルを導入するのではなく、組織が仕事のやり方を変えることを教える手段としてSAFeを捉えている。

私たちは、リーンとアジャイルを導入する組織がリーンとアジャイルを、思考方法や組織のあり方を変えたり、目指す方向性を揃える方法として捉えてほしい。そうすることで、リーンとアジャイルをSAFeを動作させる基礎の構造と機能としつつ、価値のストリームの周りにSAFeが築かれる。

誰かが私のところに来て「LeSSはSAFeよりも優れているの?あるいは、SAFeはLeSSよりも優れているの?」と聞いたら、私は両方を見て自分で決めなさいと言うだろう。というのは、SAI社の私たちも他のフレームワークをやり玉にあげたり、自分達があなた方より優れていると語るようなゲームをしたくはないからである。本当のところ、フレームワークの合う合わないはそれを使う人が状況に応じて自ら下すべき判断なのだ。

そして、自分達にとってLeSSの方がよいと思う会社を見たり、聞いたりしても私たちは気にならない。それはよかったね。それでも、SAFeのことを見て、自分達にはSAFeの方がよいと感じてくれる会社も多い。だから、私たちは他のフレームワークと競争はしたくないのだ。私たちは、組織が抱えるビジネスの問題を解決することに注力したいのである。

―― 以前紹介して下さった製造業の事例では、SAFeが選ばれたのですよね。その際に、どうしてSAFeが選ばれたのでしょうか?

Caddenさん― 製造業でも、選ばれる理由は状況によって異なる。SAFeは、おそらく市場にある最も成熟したフレームワークであることに加えて、とてもしっかりとして認定プログラムを有しており、そして認定された人が多い。これらのことで、フレームワークを導入する人がリソースを探すのが容易くなる。私たちが話しをしているのは2、3年前の話であり、その当時組織はフレームワークを見る際に、ある程度の成熟度が見えなければならなかったのだ。そして、SAFeは市場において他のフレームワークをはるかに凌ぐ、最も成熟したフレームワークであり、フレームワークに存在する知識体系はとても完成されている。それに対して、LeSS、DAD、Scrum@Scaleは成長し、発展しようとしている状況だった。

また、SAI社は会社なのだ。Dean、Drew、Collinが会社の創業者で、Deanはフレームワークの周りに組織と会社を作り、私たちのマーケティングや営業のグループのような強力な人達を得たというとても素晴らしい仕事をした。それらの人達が、Scaled Agile Frameworkのブランドを表す会社を作った。それでも、彼らの主たる関心は常にフレームワークによりビジネスの課題を解決することなのだ。

注:Dean、Drew、Collinは、SAI社を創業したDean Leffingwell、Drew Jemio、Collin O’Neilのこと。

それで多くの会社や製造業の会社が注目し、製造業の人達にはさらに理にかなったのではないかと思う。製造業の人達は、SAFeの構造をより簡単に把握することができたからである。この点がプロセスを指向しすぎるとか、規定的だと言われるところでもあるが、実際はそうではない。というのは、フレークワームはガイダンスであり、必要に応じて調整すればよいからだ。

Geraldさんからの補足:特に製造業の会社がSAFeを好むのは、SAFeによりソフトウェア開発をファームウェアやハードウェアの開発に統合することの複雑さに対応できるからである。SAFeにおけるリーンの重視、4つの中心的価値である品質の作り込み、ベクトル合わせ、透明性、プログラムの実行、そして9つの不変の原則は、フレームワークの構造やプラクティスを通じて貫かれている。これらにより、製造業の会社は開発と納品に関する予見性と透明性を得るとともに、意思決定を経済性の観点で下し、使命に対してさらにベクトルを合わせることができる。

Caddenさん

―― なるほど、分かりました。次は、Scrum@Scaleに関する質問です。今年の始めに、Scrum@Scaleのプレゼンを見たのですが、その中の事例にリリース列車の概念ととても似たものが含まれていました。まるでSAFeのようにScrum@Scaleを適用しているように見えました。その一方で、メタスクラムとエクゼブティブ・アクション・チームのような概念はSAFeを補うためにも使えるのではないかと感じました。Scrum@ScaleとSAFeは併用できるのでしょうか?

Caddenさん― あなたの質問には、異なるフレームワークの異なる要素を混在すべきかという問いが含まれていると思う。私だったら、フレームワークをしっかりと見て、このフレームワークで私にとって価値があるものが何で、足りないものは何かと自問するように考える。異なるフレームワークをプラグ・アンド・プレイすべきだという意見にはあまり賛成できない。というのは、それらのフレームワークの各々について、主要な3つのフレームワークとしてSAFe、LeSS、Scrum@Scaleが将来競争力を持つだろうと私は考えているが、それらの3つが競争力を持ち続けると考えるのは、それらがアジャイルの性質に最も忠実だからである。スクラムか、アジャイルとリーンを考えるかの違いはある。

ご存知のように、LeSSのエリアプロダクトオーナーを取り、それをSAFeに置いてみると、SAFeには同じ役割があり、それはプロダクトオーナーである。というのは、LeSSのプロダクトオーナーはSAFeではプロダクト管理者だからだ。

注:ここでは、LeSSとして複数の機能分野にまたがるような開発を行うためのLeSS Hugeの話をしている。LeSS Hugeでは開発体制全体にプロダクトオーナーが一人いて、機能分野毎にエリアプロダクトオーナーがいる。SAFeでは、LeSS Hugeのプロダクトオーナーの位置にプロダクト管理者がいて、エリアプロダクトオーナーの位置にプロダクトオーナーがいる。

LeSSにおけるエリアプロダクトオーナーが私たちにとってはプロダクトオーナーなので、これらの馬鹿げた会話に巻き込まれるのだが、それらの役割が行うことの説明を見れば、それらは全く同じことをするのである。これはLeSSやScrum@Scaleがプロダクトオーナーに拘りたいからであり、プロダクトオーナーが顧客の声を体現していることに拘りたいからにすぎない。

その一方でSAI社では、通常ビジネスの用語、ビジネスの役割に基づき、実際に顧客と話をする人をプロダクト管理者として捉える。スクラムが小さく素朴な形で始まったときにはプロダクトオーナーは直接顧客と話ができて、プロダクトオーナーに対して仕事をしてくれるチームがいたという形が可能だっただろう。だが、このモデルは10名以上のプロダクトオーナーがいて、それらの人達が1人の顧客に話をしようとすると崩壊する。それは、無理というものだ。実際には、会社には以前から役割が存在しており、プロダクト管理者と呼ばれており、その役割は今も存在する。それで、私たちはそれがSAFeで意図した顧客の声を実際に体現する役割だと感じたのである。むろんそれらの人たちがそれを行い、それがプロダクト管理者なのである。

そのため、部分をプラグ・アンド・プレイできるとは私は思わない。フレームワークには必要なものがすべて含まれているからだ。まず腰を落ちつけて考えなければならない。そして、もし価値があると考えられるような特定の仕事の仕方があるのであれば、他のフレームワークと同様にSAFeは必要なものの追加を受け入れるし、オープンである。フレームワークなので。

フレームワークを導入する本当のスキルは、異なる動作をする部分の間の関係を理解することにある。例えば、私がフレームワークに新たなプラクティスを追加したい場合、そのプラクティスを文書化しなければならないが、さらにそのプラクティスが周囲にどのような影響を与えるかを理解しなければならない。プラクティスを取り除く際も同じだ。そのため、例えば私がデイリースタンドアップを時間の無駄だと感じて、スクラムからそれを外してもスクラムは機能するだろう。それでも、スプリント計画をスクラムから外すと、スクラムは機能しなくなるだろう。

そのため、SAFeを理解している、よいコーチ/コンサルタントは、新たなプラクティスをフレームワークに追加したり、プラクティスを外すことの意味を理解しなければならない。LeSSからプラクティスを取り出してSAFeに追加するのなら、それは可能だろうが、どのような影響があり、それがSAFeの他のプラクティスとどのように連携するのかということや、土台となるリーンやアジャイルの価値や原則と整合しつづけるかを理解しなければならない。

SAFeの実装

―― 次は、SAFeの実装に関する質問をいくつかさせて頂きます。SAFeのいくつかのドキュメントにSAFeのアジャイルリリース列車は5チーム以上の状況に適していると書かれていると思います。キャデンさんは、2チームや4チームのような少数のチームの場合にもSAFeは適用可能だと思われますか?

Caddenさん

Caddenさん― もちろん適用可能だよ。この点は、SAI社の内部ですら意見の違いがあるところかもしれない。まず、SAFeが小さな環境で本当に実装できるか?だが、実際のところ、SAFeは時を経た、優れた効果的なアジャイルプラクティスであるもので作り上げられたフレームワークである。フレームワーク全体は必要なく、これらのものだけが必要だと言うこともできる。

1つの例を挙げよう。連携してほしいと思う3つのスクラムチームがあるとし、それらのチームを1つの価値のストリーム―SAFeのコア要素の1つ―に専属としたいと思うかもしれない。そのようなことはできるかもしれないし、リリース列車エンジニアは必要なく、3名のスクラムマスターが互いに連携すればよいかもしれない。その状況で、プロダクトバックログやプログラムバックログという概念は残したいと思うかもしれない。チームバックログという概念を残したいと思うかもしれない。プログラムインクメント (PI) のケイデンスやスプリントのケイデンスというようなケイデンス(リズム)の概念を残したいと思うかもしれない。それでも専任のアーキテクトはいらないかもしれない。

先に述べたように、本当に必要なものを決めればよいのだ。繰り返しになるが、フレームワークの一部を適用することになるので、それが価値の納品に対してどのような意味を持つかや、それでも効果的になれるのかを評価しなければならない。それはSAFeのすべての役割を用いることのオーバーヘッドをトレードオフするように、バランスを取ることである。

SAFeを分解して必要な部分を使ってもフレームワークとしてSAFeの恩恵を受けることができるということもありえると思う。それでもチームが追加されたり、拡大したりするにつれてそれらの部分を元に戻すことに最終的にはなるだろう。SAFe全体を実装しなければならないと思っている人たちも多く、SAI社自身にもそう考える人がいるが、私はそうではないと思う。そうする必要はないし、取り出して使えるプラクティスが多いと私は思う。

PI計画策定を取り出して、関係者を集めて1つの部屋でベクトル合わせをするためだけに使うという人たちを考えてみよう。それらの人達は、関係者を1つの部屋に集めて計画策定セッションを持ち、ベクトル合わせをするための手段として大部屋計画策定あるいはPI計画策定の概念を使うだけなのだ。とても素晴らしいテクニックだよ。

―― 分かりました。2日間のPI計画策定を1日に短縮したり、PIの期間を8週から8週未満にするのもまったく問題ないのでしょうか?

Caddenさん― うーん、それはちょっと話が違うね。3つのスクラムチームがあり、PI計画策定の概念を残したい場合だよね。計画策定に30-40名の人達に参加してもらい、6週間毎にPI計画策定を行うとしよう。そこで、すべての計画策定をやり遂げるために本当に2日間が必要かどうかを判断しなければならない。必要ないと考えると、次にどのような調整を行うべきかについて判断しなければならない。私の回答は、実際に試して学習すべきだということだ。それについて考え、1日または1日半の期間で実行してみる。1日または1日半でできることが分かったら、次に実行する際に短縮すればよい。

すなわち、試してみてうまく行ったこと、うまく行かなかったこと、そして調整を行うという振り返りをするのだ。フレームワークをカスタマイズし始める場合には、どのようなフレームワークであれ、まず実践してみて、その実践から学び、どのような調整を施すかを学ぶべきだと思う。そのようにすることで現実にあった調整―何が起こるかという推測に基づいて調整するのではなく、事実に基づく調整―を施す。

前編の最後に

次回は、SAFeの複数の構成、SAFeに関する様々な質問、キャデンさんのプライベートについてお聞きした内容を掲載します。