FAST: 流動的チーミングによるプロダクトディスカバリーの革命
※ この記事は、FAST考案者であるQuinton Quartel氏がMediumで公開している記事を、本人の許諾の下で日本語に翻訳したものです。プロダクトディスカバリーの観点から、FASTがどのように機能するかを説明する記事です。
FAST: 流動的チーミングによるプロダクトディスカバリーの革命
現代のプロダクトマネジメントの到来により、ディスカバリーとデリバリーの両方に効果的な作業プロセスを見つけることが課題となっています。Fluid Adaptive Scaling Technology (FAST)は、チーム全体をベースとしたメソッドを提供します。
Marty Cagan、Jeff Patton、Teresa Torresといった、現代のプロダクトマネジメントをリードする人々は、口をそろえて「エンジニアリングをプロダクトディスカバリーに統合することで、より迅速で革新的なソリューションが生まれる」と言っています。しかし、それをどのように実現するのでしょうか？ Teresa Torresは安定したプロダクトトリオ（プロダクトマネージャー、デザイナー、エンジニアの3種による合同チーム）内に専任のエンジニアを置くことを提唱する一方、Marty Caganはエンジニアのローテーションを推奨しています。私はCaganの提案に賛同しますが、「どのように」という部分が欠けています。そして、私はこの質問への回答となるプロセスを開発したと考えています。 ――それが Fluid Adaptive Scaling Technology、別名FASTです。
プロダクトチームの一部としてのディスカバリートライアド — John Cutler氏による画像
流動的にエンジニアをローテーションするためのFASTの導入
FASTは、プロダクトのデリバリーとディスカバリーにおける複数の課題を解決します。このブログでは、Caganが推奨するプロダクトディスカバリーへのエンジニアの参加とローテーションをFASTがどのように支援できるかに焦点を当てます。
ユーザビリティーと価値のテストの両方あるいはどちらか一方をおこなうときは、たいていの場合、プロダクトマネージャー、プロダクトデザイナー、開発チームの（中で同席を希望する）エンジニアの1人が出席する。私の好みはエンジニアをローテーションすることだ。前にも言ったように、魔法はエンジニアがいるところで起こることが多いので、可能なかぎりエンジニアが同席するように勧めている。
~ Marty Cagan, INSPIRED
FASTは流動的なチーミングを可能にし、プロダクトトリオがエンジニアをローテーションさせるのに理想的です。これはディスカバリー活動、結果として生まれるプロダクト、そしてチームの健全性に利益をもたらします（ここでいうチームはFASTでコレクティブと呼ばれます。FASTは複数チーム組織にスケールできるためです）。
ディスカバリー作業に開発者やチームの他のメンバーを参加させないのは、彼らにとって不利益だと思います。通常、やるべきディスカバリー作業は十分すぎるほど存在し、チーム全体を巻き込む方法もたくさんあります。
~ Jeff Patton
プロダクトディスカバリーを通じたエンジニアローテーションの具体的なメリット
エンジニアをプロダクトディスカバリーに参加させる効果として、エンジニアが顧客とその課題に対してより深い共感を得られることが挙げられます。プロダクトディスカバリー活動に参加することで、エンジニアは顧客の声を、また聞きではなく、直接聞くことができます。多くの人々の主張によれば、開発者が顧客に共感を持つことでコードの品質が向上し、より良いソリューションが生まれます。ローテーションは、エンジニアにプロダクトライフサイクルの異なる部分に触れさせ、異なる問題を解決する機会を与えます。これによりエンジニアはスキルを成長させ、エンゲージメントを維持することができます。
FASTによるプロダクトトリオを通じたエンジニアのローテーション方法
FASTは、人々が何かしらの 活動（work）を中心に自己組織化するための方法です。短いサイクル（例：2-3日）を利用して、コレクティブのメンバーが集まり、進捗と学びを共有し、次に何をするかを決定します。この集まりをFASTミーティングと呼びます。次に行う活動アイテムが選択されると、コレクティブはその活動を中心に自己組織化します。これがFASTの要点です。FASTの完全な解説は長くなりすぎてこの記事の趣旨から外れてしまうので、ここでは詳細を述べません。FASTについての詳細はFASTのウェブサイトでご確認ください。以下は、コレクティブが次のバリューサイクルで取り組む活動アイテムを決定した状況を示すマーケットプレイスボードをビジュアルに表現したものです。
FASTマーケットプレイスボードの前に立つFASTコレクティブ、つまりプロダクトチーム。次のバリューサイクルでにてディスカバリー活動（Discovery Work）のアイテムが計画されています。
1バリューサイクルでディスカバリー活動を行う場合、プロダクトマネージャー、デザイナー、そして（少なくとも）1人のエンジニアがそのサイクルの活動のマーケットプレイスで、そのスイムレーンに自ら参加することが期待されます。
コレクティブのメンバーが自己組織化して、活動アイテムの周りでチームを作った状態
各FASTミーティングは、コレクティブが活動に集中しているモードから一時的にビッグピクチャーのプランニングモードに切り替わるチェックポイントを表します。マーケットプレイスでは、どのエンジニアもそのサイクルのプロダクトトリオに自ら参加することができます。FASTは群衆の知恵、あるいは集合知を使用してローテーションを管理し、誰がどのチームにいるべきかを決定します。これは創発的なプロセスです。FASTはオープンスペーステクノロジーに基づいており、そこでよく聞かれるフレーズは「そこにいるものは誰でも適任者である」というものです。FASTでも、同じ創発性に依存しています。集合知が、正しいことに取り組む正しい人々を正しいタイミングで決定します。プロダクトトリオの場合、それは適切なエンジニアを意味します。
当初のトポロジーがどれほどチームをエンパワーしていたとしても、その効果が未来永劫続くわけではない。職場の現実は常に変化しており、場合によってはトポロジーに変更を加えなければならない形で変化することもある。
― Marty Cagan, EMPOWERED
注意：すべてのエンジニアがプロダクトディスカバリー活動を望むわけではない
プロダクトディスカバリーへのエンジニアのローテーションに賛同する場合でも、すべてのエンジニアがこれを望むわけではなく、ディスカバリー活動に適性を持っているわけでもないことに留意してください。これがFASTの素晴らしい点です：強制することなくエンジニアが参加できるようにします。コレクティブは、どのエンジニアがディスカバリー活動に適性と興味を持っているか、持っていないかをすぐに発見することができます。（もし「今後はプロダクトトリオでディスカバリーをする」と決めたら、それによって以降のエンジニアの採用基準や採用の決め方が変わる可能性があります。）
FASTに関する一般的な誤解
重たい調整と計画ではなく自己組織化に頼ることは、必然的にカオスを生み出し、うまく機能するはずがないと思うかもしれません。しかし、現実は全く異なります。流動的なチーミングがどのように機能するかを理解するには、James ShoreによるFAST体験レポートの動画をご覧ください。
FASTを初めて見た人がよく抱くもう一つの大きな誤解は、活動アイテムがサイクル内で「完了」する必要があるものだ、と思ってしまうことです。これはバリューサイクルを誤って、スクラムのスプリントやXPのイテレーションと同じだと考えてしまっています。スクラムでたとえるなら、より近いのはデイリースクラム（時にデイリースタンドアップやハドルと呼ばれる）です。ハドルでは、進捗を共有し、チームメイトから学んだことを基に何をするかを決定します。ハドルに参加する際、必ずしも何かを完了している必要はありません。進捗を出すか学ぶことが必要です。FASTはタイムボックス方式ではなく、フロー方式です。
プロダクトディスカバリーにおけるFASTのメリット まとめ
- イノベーションの促進： FASTは異なるアイデアと視点の交換を促し、新しい発想を生み出します。
- エンジニアの成長： FASTはエンジニアがスキルと知識を拡大することを可能にします。
- チームの俊敏性向上： FASTはチームが変化するニーズに素早く適応することを可能にします。
- サイロ化の軽減： FASTはサイロを打破し、コラボレーションを促進します。
- プロダクト品質の向上： より多くのエンジニアがプロダクト全体に触れることで、プロダクト品質が向上します。
- コード品質の向上： 顧客への共感の増加により、より高品質なコードが生まれます。
FASTをプロダクト開発プロセスに統合する方法
一度にすべてをFASTに変更するのではなく、チームの流動性を試すために小規模な、失敗しても安全な実験を行うことができます。まだスクラムを使用している場合は、トリオに1スプリントごとにエンジニアを配置し、各スプリントでローテーションを行います。あるいはさらに良い方法として、ディスカバリー活動アイテム間の自然な完了ポイントを見つけ、次のスタンドアップミーティングで誰かが交代できるか尋ねてみましょう。
一度この方法を試すと、FASTはすぐにPMがディスカバリーとデリバリーを組み合わせる際に好む方法となるでしょう。流動的なチーミングがディスカバリーとデリバリー作業にもたらす利点――適応性とレジリエンスの最適化――を実感することができます。
ぜひ試してみてください！ サポートが必要な場合は、お気軽にご連絡ください。この方法での作業経験を持つコンサルタントをご紹介できます。
RSGT2025のOST 「3回目の参加だけど今回はRSGTが楽しくなかった」セッションに思ったこと
今年もお陰様で、RSGT2025に参加できました。
で、まともな参加記などを書かず、こんなポストを書いています。すいません。
タイトルにあるセッションは、RSGT2025 Day3のOSTにて実施されたものでした。目を引く提案だったこともあり、RSGT終了後も様々な方が、特に「内輪ノリ」に絡めて言及しているようでした。
私もこのセッションに直接参加していましたが、「内輪ノリ」と関連付けるのは、正直なところ、違和感がありました。そして、このような流れがこのまま大きくなっていくのも良くないな、と感じています。
なので、私がセッションに参加して実際にどう感じていたのかを、一応記録として残しておきたいと思います。
最初にお断りしておきますが、登場する方々を含め、この文章で誰かを責めたりする意図は全くありません。実際、誰かが悪いとか、そういった話ではない、そんなことは僕は全く考えていない、ということをご理解いただければと思います。
「内輪ノリ」の問題だったのか
まず、ホストのお悩みを整理します。ホストの方は、自身の悩みをこのように説明していました。
- RSGT1回目は、顔見知りもいなくてぼっちだったが、アテンドしてくれる方がいて、それから楽しめるようになった
- 2回目も純粋に楽しめた
- 3回目は、なぜか他の人達の会話に混ざれず、疎外感を感じた
この時点で、僕からすると単純な「内輪ノリ」の問題ではないように思えます。なぜなら、1回目・2回目はそれぞれ楽しめていたわけなので。もし昨年に比べて今年は遥かに内輪ノリが酷かった、というのであれば理解できますが、恐らく多くの人はそう思っていないのではないかと思います。
確かに僕も、数年前にこのコミュニティに初参加した頃はちょっと独特のノリに馴染みにくかったのですが、それは去年までの話です。去年までは楽しめていて、今年は楽しめなかったホストの問題とは別の問題だと考えられます。
なので、少なくともこのセッションを起点として昨年以前から続く話を語ったり、2024年以前のRSGTを回顧して「昔似たようなこと体験した」と連想するのは、この問題の考察としてはちょっとズレています。
適切なふりかえりだったか
また僕がこのセッションに参加して感じたことを正直に言うと、これをふりかえりのセッションとしてみたとき、進行に改善の余地があったということでした。
というのも、ホストが事情を話した後、ほぼ最初の時点から「RSGT2025全体の問題である」という前提で話が進んでしまったのです。
しかしこの話、あくまでホストの方個人の問題である、という可能性も十分にあったように思いました。たまたまその時の心理状態だったり、いくつかの勘違いが重なったりして、周囲の人間は変わってないはずなのになぜか疎外感を覚える……といったことは、割とどんな状況でも日常的に、誰にでもあることじゃないかと思います。その現象を心理学的に説明することも可能です。
なのでホストの指摘が、本人の個人的なものなのか、あるいは他にも多くの方が同様に感じていてRSGT2025自体の問題といえるものなのか、どっちなんだろう……と、説明を受けた直後から自分は疑問に思っていました。 しかし、そういった確認が一切なされないまま、そのセッションでは「RSGT2025全体の問題」という前提で話が進んでしまいました。誰か他にも何人か同じ思いをした人がいたならそう捉えても差し支えないように思いますが、そういった質問が参加者にされたわけでもないし、そう発言した人は（自分が記憶している限り）他にはその場にいなかったんじゃないかと思います。
※ 念のため、ですが、別にホストの方を責めていません。その流れにそのまま乗っかった全員（僕を含む）の共同作業によるものですし。
「今回は楽しめなかった」というのは、ホストの方が感じられた間違いない事実です。が、それがホストの個人的なものか、それともRSGTというイベントに問題があったのかによって、取るべき対策がまったく異なってくるはずです。内輪ノリの問題とするのも、あくまで後者の場合なら、という前提による話だと思われます。
僕自身も本来なら、この違和感を感じた時点でそういう発言をすべきだったかもしれません。ただ、その時点では「自分には今年（のRSGT）に何か違いがあるのかよくわからない」と発言するのみでした。
正直なところ、自分はこのセッションが「ホストの方のぼっち状態を解消できればとりあえず成功」だと考えていたし、それは実際そうなりました。（多くの参加者の方がホストの方と連絡先を交換されていました。）なので、それ以上何かの改善をその場で求める気は特にありませんでした。
ただし、もしこのセッションがRSGTのOSTでなく、通常のスクラムチームのスプリントレトロスペクティブであったとしたら、このような流れを作ってしまうと根本原因を見誤ってしまいかねないので、あまり良くはなかったでしょう。もしそのレトロのファシリを僕が担当していたら、その流れができた時点で一旦議論を止めていたと思います。
以上、ホントはこの話は誰に話すまでもないもので、だから胸に留めておくつもりだったんですが、予想以上にこのセッションが話題になっており、RSGT終了後もちょっとした余波が続いているようだったので、あえてここに記しました。
何度も書きますが、誰かを責める意図はまったくありませんので、ご了承ください。
フロー効率重視の開発について考える 後編 ～中長期目線の話～
註：この記事は前後編の後編です。前編を先に読むこと推奨です。 bonotake.hatenablog.com
TL;DR（後編のみ）
- 中長期的には、ソロ開発はリソース効率（人員の稼働率の高さ）、アンサンブル開発はフロー効率（タスクが滞りなく処理される度合い）に長所がある
- アンサンブル開発はボトルネックが生じにくいため、中長期目線ではアンサンブルの方が安定的な開発ができ、スループットも高くなる逆転現象が起こりうる
目次
前編のおさらい的な何か
よく「リソース効率重視」とか「フロー効率重視」とか呼ばれるのは、特にアジャイルの文脈ではそれぞれ「ソロ開発」と「アンサンブル開発」とも呼べる2つの開発スタイルを指すのが一般的、という話を前編でしました。
- ソロ開発 ... 個人1人1人にタスクを割り当て、個人ベースで開発を進める。
- アンサンブル開発 ... 1つのタスクを複数人で、コミュニケーションを取りながら協働でやっつける。
そして、それぞれのメリットは、短期目線と中長期目線で分けて、以下のように分類できる、としました。
| ソロ開発 | アンサンブル | |
|---|---|---|
| 短期 | スループットの高さ | リードタイムの短さ |
| 中長期 | リソース効率 | フロー効率 |
短期の話は前編でしたので、この記事では中長期の話をします。
中長期的な比較：リソース効率 vs フロー効率
前編ではソロ開発について、短期的にはスループットが高い（アウトプットの総量が多い）という話をしました。一方アンサンブル開発は、コミュニケーションや待ちが発生して、すき間なく作業できない、と書きました。
しかし現実には、ソロ開発でも別の理由からすき間が生じます。インシデント対応やよくわからない雑務、予定外のミーティングなどが降ってきたりして、1人の開発者が自分の時間を100%開発に集中できることはほぼまれです。
前編の例で、もしこうした差し込みが発生したら？ ということを考えていきましょう。
これは前編のソロ開発の例で、 $t_3$ で差し込みタスクが発生した場合を考えています。開発者Cがその対応にあたり、まるまる1週間潰しています（図中の灰色のマス）。
ここで注目してほしいのは、差し込み対応をしていると、青タスクの作業が中断してしまう ということです。そのせいで、青タスクの完了は1週間延びています。
一方、アンサンブル開発をやっていて同じ差し込みタスクが発生したらどうなるか、見てみます。
同じく $t_3$ 付近で開発者Cが対応に当たったとします。 この影響がどの程度になるのか厳密に想定するのは難しいですが、もしかすると少しだけ青タスクのリードタイムが延びたかもしれません（そんな気持ちを雰囲気で図に表しています）。ただ重要なのはそこではなく、アンサンブル開発では、開発者1人が抜けても青タスクの開発作業は他の開発者によって続行される、ということです。完了までの時間は多少延びるかもしれないですが、それでも青タスクは程なく完了するでしょう。反面、ソロ開発の場合、開発者が抜けるとその間、開発は中断されたままの状態が続きます。誰かが引き継げればいいのですが、担当者が急な事情で途中で抜けた場合、他の開発者が引き継ぐのもなかなか大変です。
これが、フロー効率の効能です。フロー効率は以下の数式で表される指標で、要は「タスクがどれだけ滞りなく処理されたかの度合い」を示します。
$$フロー効率 = \frac{タスクに意味のある作業がなされた時間}{タスクのリードタイム}$$
先ほどの例でいうと、ソロ開発での青タスクのフロー効率は 4/5 = 80% となります。一方アンサンブル開発では、青タスクの開発の手は止まっていないので、フロー効率は100%です。
一方リソース効率とは以下の式で示される、人員ベースの稼働率です。
$$リソース効率 = \frac{実際に開発者が作業した時間}{開発者が作業できる総時間}$$ 双方の $t_4$ までのリソース効率を考えると、ソロ開発はどの開発者も（差し込みタスクも含めて）すき間なく作業できている、つまりフル稼働しているので、リソース効率は100%です。一方アンサンブル開発は、前編でも述べた通り、オーバーヘッドが発生してスループットが 3/4 に落ちており、よってリソース効率も 3/4 = 75% になっています。
このように、やはりフロー効率とリソース効率も、普通はトレードオフの関係になります。ソロ開発はリソース開発に優れる一方、アンサンブル開発はフロー効率に優れています。
ボトルネックの問題
先ほどの説明では、「フロー効率が劣後する例」と「フロー効率が優先される例」の比較を見ることになりました。そして、アジャイルにおいては「フロー効率重視」ということがよく言われます。
どうしてフロー効率を重視するのでしょうか。それは、フロー効率が低い、ということはそれだけボトルネックが発生していることを意味しているからです。
言い換えると、ソロ開発はボトルネックが発生しやすく、開発が意図せず中断する確率が高いのです。
更に言うと、この状態は開発が完了した後も続きます。たとえば、先ほどの青タスク開発終了から数か月後、ここで書かれたコードが起因でインシデントが発生したとします。
しかし、もし開発者Cが辞めていたり異動していたりして、既に開発から離れていた場合、どうなるでしょうか？ 恐らく、ここのコードを触ったことのない開発者がインシデントに対応することになるでしょう。多大な時間と労力をかけることになるはずです。
一方、アンサンブル開発で同様の事象が発生して、そしてやはり開発者Cがいなくなっていたとしても、残りの3人はまだ残っているので、その3人の誰かが対応に当たれば、恐らくソロ開発のケースよりは少ない時間と労力で対応できることでしょう。
ここで重要なのは、アンサンブル開発では、開発と同時にナレッジシェアが行われる ということです。この効果は文字通り計り知れなくて、様々な観点で組織を強靭にし、開発を長期にわたって安定させる効果をもたらします。
一方でソロ開発は、組織の中で特定の知識を担当者1人しか持っていない、という状態を簡単に作り出してしまいます。その担当者が簡単にボトルネックになってしまうという意味で、開発組織としてはとても脆弱です。
そして、その担当者から他の開発者に、開発後に知識を引き継ぐのはかなりコストが高いのです。僕はそうした形でナレッジシェア（いわゆる引継ぎ）がまともになされたのを見たことがありません。
そして、前編では「ソロ開発は短期的なスループットの高さが長所」という話をしたのですが、ここまでの話を踏まえると、中長期の観点では必ずしもスループットが高いとは言えなくなります。特に差し込み対応が多い開発組織では、ボトルネックが発生する頻度も跳ね上がってしまい、それだけ開発が遅延してしまいます。その分、安定して開発できるアンサンブル開発をしている方が、中長期で見ればスループットが高くなる、という逆転現象の可能性が出てくるのです。
まとめると、中長期の目線で考えれば、アンサンブル開発を採用した方が、安定してパフォーマンスを発揮できる開発組織にでき、メリットが大きいと言えます。
アジャイル本来の意味からフロー効率を考える
若干話がそれますが、よく、アジャイルのことを「スピードが速い」という意味と勘違いしている人を見かけます。しかしスピードとアジリティ（「アジャイル」の名詞形）は、実は似て非なる概念です。
スポーツの世界でのスポーツとアジリティの意味を書き出すと、こうなります。
- スピード … できるだけ短い時間で動作を行う能力。100m走の速さなど。
- アジリティ … 方向転換や動きの変更における素早さ。サッカーやバスケットボールで相手選手をかわす動き。
そしてこれは、プロダクト開発の世界でよく見るアジャイルとスピードの違いと本質的に同じです。こちらの世界でアジャイルとは「周囲の変化に俊敏に対応できる」ことを指します。
それを踏まえて、ソロ開発とアンサンブル開発、どちらがアジャイルと言えるでしょうか。ソロ開発は、開発者が安定して作業に集中できる環境ならその本来の特性を活かせますが、不確実性の高さや変化の多さにとても弱いです。アンサンブル開発の方が、差し込みが来ようが、開発方針が多少変わろうが柔軟に対応できる余地を残していて、よりアジャイルだと言えます。
アジャイルにおいてフロー効率重視のスタイルが推奨されるのは、そういう理由だからでしょう。
つまりは冗長性を確保するということ
以上などから僕は、少なくとも中長期視点では、アンサンブル開発がソロ開発より優れている、と考えます。
少し抽象的な議論になるのですが、アンサンブル開発というのは結局のところ「冗長性を持たせて信頼性やパフォーマンスを上げる」という、情報科学 / コンピュータサイエンスの世界では広く使われるテクニック、設計原理の応用だと言えます。
RAIDを想像してもらえばわかるのですが、ストレージを必要最低限のn倍だけ余分に使って、信頼性を上げたりアクセス速度を上げたりします。RAIDはデーターセンターやオンプレミスのサーバーで広く使われており、それを「リソースの無駄だ」と考えるエンジニアはほぼいないでしょう。
似たような話で、特に中長期的な視点に立てば、アンサンブル開発を採用して組織を冗長化しておくことは十分なメリットがあります。
そして中長期的に必要と思うことは、今から始めて、普段から実践しておくべきです。中長期の話をすると「今は目の前のことで余裕がないから」といって後回しに考える人も多いですが、「RAID入れとくべきだと思うけど、今はそんな余裕ないしな」という人はたいてい、将来においてもRAIDを導入しません。この話もそういった類のものかもしれません。
前編で触れたように、アンサンブル開発には学習コストも必要、ということもあります。いざというときにすぐできるものではないので、普段から少しずつ実践して取り入れていくべきでしょう。
また、RAIDはレベル（アルゴリズム）の選択によって信頼性を上げる方に寄せたり、性能を上げる方に倒したり、どちらもバランスよくいいとこどりしたり、といったことができます。 アンサンブル開発でも似たようなところがあり、スクラムのスウォーミングは比較的パフォーマンス、つまりリードタイム重視な面があり、XP由来のペアプログラミングやモブプログラミングは信頼性、つまりフロー効率重視なところがあります*1。そういった特性をうまく見極めながら工夫をすると、同じアンサンブル開発でも様々な形で効果を発揮することができます。
ソロとアンサンブルでバランスを取る
さて、今まではソロかアンサンブルか、リソース効率かフロー効率か、の2択で話してきましたが、実際のところは、どちらかに極端に寄せるのは得策ではありません。アンサンブル開発がいいと言っても、たとえば1タスクを30人でやっつける、というのは流石に非効率に過ぎる、と思うでしょう。
そうした、リソース効率もフロー効率もいい塩梅で収めるために使われるプラクティスが、カンバンのWIP制限です。
カンバンではWIP（Work In Progress、仕掛り中のタスク）の最大数を決め、それによって、開発するタスクの並列数をコントロールします。WIP制限を3に設定すれば同時に3つまでしかタスクは開発できないし、10に設定すれば10タスクまで並列にできます。
これを12人チームでやった場合、12人で3タスクだけやるのと、10タスクをやるのとではフロー効率・リソース効率に大きな違いが出るし、引いてはスループットやリードタイムにも変化があるでしょう。
僕は株式会社ログラスにおいてFASTというアジャイルフレームワークを導入していますが、FASTではWIP制限をカンバンから輸入していて、チームのメンバー数の調整に使います。12人のコレクティブ（開発メンバー全員の集団）でFASTをやったとすると、WIP = 3 では1タスクあたり平均4人のチームができ上がるし、WIP = 10 では平均1.5人と、ほぼソロ開発が主体になりそうな環境になります。この数値を、その組織が今置かれている状況にマッチするよう調整することで、適度にアンサンブルっぽく適度にソロっぽい開発体制を作れるし、その塩梅を動的に調整することもできます。
おわりに
長々と書いてきましたが、実際のところ最適な塩梅というのは個々の状況に依存するので、基本的な概念とベースとなる考え方を押さえた上で、そのときそのときの状況に適応する形で調整できるようになると良いのではないかなぁ、と思います。
業務だと普通はチーム/組織で開発すると思いますし、せっかくチームで開発しているのなら、個人に頼りきった開発しかしないよりはチームワークを覚えた方が良いし、そこにはフォーメーションが存在して、フォーメーション次第で様々な効果を発揮できます。そうしたフォーメーションまで考えて柔軟に戦略・戦術を組めると開発組織としては相当強くなるはずです。
そしてまた繰り返すのですが、アンサンブル開発はやれと言われてすぐできるものではなく、学習コストがあるし、ソロ開発に比べれば結構スキルが要求されるものです。なので、やってみたいと思うチームは、ここに書いたようなパフォーマンスを最初から出そうと思わず、しばらくは練習とだと思って色々試すところから始めてみてください。それなりにこなせるようになったら色々調整していって、より最適な塩梅を自分たちで模索していくとよいのではないでしょうか。
フロー効率重視の開発について考える 前編 ～短期目線の話～
TL;DR（前編のみ）
- 「リソース効率重視」、「フロー効率重視」と呼ばれる開発スタイルは、それぞれソロ開発（個人分担制）とアンサンブル開発（1つのタスクを複数人で協働する方法）を指すのが一般的
- 短期的には、ソロ開発はスループットの高さ（開発アウトプットの総量）、アンサンブル開発はリードタイムの短さ（1タスクが完了する速さ） に長所がある
- どちらがいいかは状況次第だが、アウトプットでなくアウトカムを見て判断すべき
目次
僕はなんでこれを書いているのか
アジャイルで開発やっていると、度々「フロー効率重視」という言葉が聞こえてきます。しかし、この言葉が意味するところの理解は人によって結構バラバラだったりします。リソース効率、フロー効率 といった言葉を扱ったブログ記事なども多数ありますが、よくよく読むとちょっとずつ違うことを書いていたりして、割と混乱しがちです。
この記事では、特にアジャイルの文脈で「フロー効率重視」あるいは「リソース効率重視」と呼んだ場合、とどのつまり何を意味しているのか、結局どっちがいいのか、を考察していきます。
正確な定義を試みるというよりは、僕自身がどう解釈しているか、それぞれのメリットデメリットをどう評価しているか、という点を重視して書いています。そういう意味では、色々ある、ちょっとずつ違うフロー効率の解説記事をもう1個増やすだけかもしれません。そのへんはご留意ください。
2つの開発スタイルについて
長々と前置きした上でしょっぱなからいきなりですが、「リソース効率重視」や「フロー効率重視」という世間一般の表現は、実際にはあまり正確ではありません。
よくその2つの言葉を使って語られることは、以下に挙げるように、大別して 「ソロ開発」 と、アジャイルでよく採用される 「アンサンブル開発」 の2つのスタイルの開発方法があるよ、ということです。なお、ソロ／アンサンブル の名称は僕がここでつけたもので一般的な呼称ではありません。
- ソロ開発 .... 1人1人にタスクを割り振って、そのタスクを最初から最後まで1人で開発してもらうスタイル。個人分担方式。
- メリット
- リソース効率が良い
- 短期的にはスループットが高い
- デメリット
- リードタイムが長い
- メリット
- アンサンブル開発 ... 1つのタスクを複数人で、恊働（コラボレーション）で片づけるスタイル。
- メリット
- リードタイムが短い
- フロー効率が良い
- デメリット
- 短期のスループットが低い
- メリット
「リソース効率」、「フロー効率」、「スループット」、「リードタイム」の4つの用語を今のところ定義なく使っていますが、スループットとリードタイムはこの後説明します。リソース効率とフロー効率の説明は後編に回します。すみません。
ただ、ここで知っておいていただきたいのは、2つのスタイルそれぞれの長所・短所はリソース効率とフロー効率に限らないということです。一般的に、前者のスタイルを「リソース効率重視」、後者のスタイルを「フロー効率重視」と言ったりするのですが、実際のところはリソース効率・フロー効率だけが主要な要素ではなく、他にもメリット、デメリットが複数あります。
比較ポイント
そして、ソロとアンサンブルでそれぞれ比較すべきポイントが複数あるのですが、それが短期目線と中長期目線では少し異なってきます。
以下はそれぞれの観点で長所を表形式にまとめたものです。
| ソロ開発 | アンサンブル開発 | |
|---|---|---|
| 短期 | スループットの高さ | リードタイムの短さ |
| 中長期 | リソース効率 | フロー効率 |
他にも色々あると思うのですが、この記事では特に、前編は短期的視点でスループットとリードタイムに、後編は中長期視点でリソース効率とフロー効率に着目しての比較をしていきます。
短期的な比較：スループット vs リードタイム
短期的な視点に立った場合のソロのメリットはスループットの高さ、つまり開発の総量の大きさです。一方、アンサンブル開発のメリットはリードタイムの短さです。つまり、タスクが作成されてから完了（リリース）されるまでを短縮できる、ということです。
2つの開発スタイルを比較してみる
では、ソロ開発とアンサンブル開発とがそれぞれどんなものか、どういう違いがあるかを、スループット・リードタイムの2つの観点から見ていきます。
まずはソロ開発。
正方形のマスがそれぞれ作業を表し、色はタスクを表します。4つの色があるので、ここでは4つの異なるタスクがある想定です。どのタスクも原点で作成されたとします。
縦軸は4人の開発者A～D、縦軸が経過時間を表します。 から $t_4$ はそれぞれ1週間分と想定します。
ソロ開発では、開発者Ａ～Dがそれぞれ別個のタスクにアサインされ、1人1人が別個のタスクをこなしていきます。
この開発スタイルの長所は、スループットの高さ、つまりアウトプットの総量が高い事です。この例だと、$t_4$ までに16マス分、4タスクを完了させています。
一方、この方法の弱点は、1つのタスクに常に1人分しか開発リソースを割けないので、どうしてもリードタイム、すなわちタスクが作成されてから完了するまで時間がかかる、ということです。この例だと、どのタスクも$t_1$から$t_4$までの4週間分の時間がかかっています。
一方アンサンブル開発では、1つのタスクを複数人で分担するので、理想的には以下のような図の状態にできます。
黄色のタスクはリードタイムを1週間まで縮めることができています。他のタスクもまとめて書くと、
- 黄色 .. 1週間
- 緑 ... 2週間
- 青 ... 3週間
- ピンク ... 4週間
と、ピンクのリードタイムはソロ開発と変わらず、それ以外の3タスクは全てリードタイムを短縮できています。
しかし、これは極めて理想的なケースで、現実的にはこう上手くはいきません。共同で1つのタスクを倒そうとすると、開発者間でコミュニケーションを取りながらになりますし、待ちも発生しがちです。
なので現実は、以下の図のようになったりします。
コミュニケーションや待ちのオーバーヘッドによって、各開発者はそれぞれきっちりすき間なく作業はできていません。 $t_4$ までに3つのタスクが完了しており、その3つに均等に作業時間がかかったとすると、それぞれのリードタイムは
- 黄色 ... 4/3 ≒ 1.33 週間
- 緑 ... 8/3 ≒ 2.67 週間
- 青 ... 4 週間
かかったことになります。これでも、先に着手した3タスクについてはソロ開発よりはリードタイムを短縮できているのですが、後に回したピンクのタスクは $t_4$ までに着手できていません。つまり、$t_4$ までのアウトプットの総量は12マス・3タスク分となり、スループットはソロ開発に比べて 3/4 に減少しています。
このように、ソロ開発とアンサンブル開発は、短期的にはスループットの高さとリードタイムの短さ、という点でトレードオフの関係にあって、ソロ開発はスループットに優れる一方、アンサンブル開発はリードタイムを短くすることができる、という長所があります。
結局どっちがいいの？
スループットの高さとリードタイムの短さ、どっちを取るのがベターか、は状況依存で、必ずしもどっちかが常に良いとは限りません。
ただし、今までの議論はアウトプットがベースになっていることに注意が必要です。 一方で、プロダクト開発においてはアウトカム、つまりユーザーや顧客に何かしら与える価値、があるかを意識しないといけません。つまり、スループットを取るのかリードタイムを取るのか、に関してもアウトカムを基準に考えるべきです。
そして、アウトプットの量とアウトカムの量はほとんどの場合において相関がない、というのは今日において良く知られた事実です。何かしら機能を作ってリリースしても、ユーザーが喜んでくれる保証も、それに顧客がお金を出してくれる保証も何もありません。
※ にもかかわらず、アウトカムの量はアウトプット量に比例すると錯覚して、とにかくアウトプットを求めてしまう状態が俗に「ビルドトラップ」と呼ばれるものです。
その上でスループットの高さ、つまりアウトプットの量を選択すべきだとしたら、それは 開発予定のアイテムが必ず価値を生むことが保証されている場合 と言えるでしょう。雑に言い換えると、「作る予定のものの中に当たりくじが必ず入ってると確信できる」なら、あとは量で攻めても良いでしょう。
受託開発はそもそもアウトプットに対して対価が支払われるビジネスモデルなので、この範疇に入ります（そういう割り切り方が良いかはともかく）。
また自社サービスの開発においても、たとえばテーブルステークス、つまり、どこかの許認可を受けないと販売できないとか、何かしらの要因で「とにかくそれがないと市場から門前払いを食らう」ような機能を作る状況もこの範疇に入るでしょう。
ただ、プロダクト開発におけるほとんどの状況において、そんな保証はありません。天井のないガチャを引き続けるのと同じで、「ここまで作れば必ず売れる」という確証がないのが普通です。
で、そんな状況でアウトプットの量で勝負してしまった場合、大量に機能を作ったのに全部ハズレ、なんてことになってしまう可能性も十分あります。それは開発のコストを丸々ロスしてしまうだけでなく、大量のゴミを自分のプロダクトに追加してしまう ことを意味します。プロダクトは無駄に複雑になり、ユーザーにとっての価値も下がるし、開発者にとっての生産性も下がってしまいます。
つまり現代のソフトウェア開発において、良い機能を作ることと同等以上に余計な機能を作らないことはとても重要です。
【ここから余談】
一定以上育ったソフトウェアは「コードを1行追加したらプロダクトとしての価値は下がる」と思った方が良い、と自分は思っています。機能を追加したければ、その複雑性増加に伴う価値の低下を大きく上回る価値を付与しないとペイしません。
僕は割とエンジニア目線で話をしていますが、PdM目線で似たようなことを語るnoteが最近公開されていました。
【余談おわり】
一方、とにかく量で攻めるのではなく、
- 1つずつリリースして、顧客・市場からフィードバックを得る
- そこから自分たちが顧客について学び、その学びを活かして次の弾込めをする
- 以上2つをひたすら何度も回す
とすることで、当たりくじを引く確率をなるべく増やし、かつ無駄打ちをしなくてよい（あるいは、ハズレを引いたときの悪影響をなるべく小さくできる）アプローチが俗にリーンスタートアップと呼ばれるビジネス戦略です。
で、リーンスタートアップを実践する上では、上記のサイクル（いわゆる仮説検証のサイクル）をどれだけ速く回せるか、が開発組織としての生産力につながります。そして、この前提においてリードタイムが短いことは大きなアドバンテージになるのです。
アンサンブル開発に関する補足
ここで注意が必要なのは、アンサンブル開発はある程度慣れないとできない、ということです。
ソロ開発は、それこそ学校の授業でプログラミングを習っても、あるいは趣味で開発したとしても、だいたいこの形式に自然と収まるのでいちいち習得の時間を取らなくてもいいです。一方アンサンブル開発は、それなりに経験やトレーニングを積んで、アンサンブル開発での考え方になじまないとうまくこなせない人が大半ではないかと思います。
加えて、上の説明だけだと「リードタイムを短くしたければ人を追加すればええんや！」と安直に思う人もいるかもしれませんが、これはまさに人月の神話で、「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」というブルックスの法則が示すのと同様の状況に嵌ってしまう可能性があります。
上で書いたようなアンサンブル開発への慣れも含め、開発者の学習曲線を無視してはいけない、ということです。
ここで思考を止めないで
さて、ここまで読んで、ソロ開発とアンサンブル開発はどちらもアリ？ という気分になられたかもしれません。
実際、短期的目線だとどっちにもメリットはあるんですが、中長期的な目線だとまた違った議論になっていきます。中長期的視点ではリソース効率とフロー効率の観点が中心になり、その視点だと全然異なる状況が見えてきます。
……ですがここまで長くなりすぎたので、以降の議論は後編に譲ります。
FAST導入に関するRSGT2025プロポーザルのお話
最近支援に入っているログラスのエンジニアリングマネージャー飯田さんが、RSGT2025にプロポーザルを書きました。一応僕もおまけで登壇予定です。
タイトルは「エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢について」です。
今年に入ってからログラスさんにて、FASTという、国内では過去おそらく導入事例のないアジャイルスケーリングフレームワークを導入する支援をしてきたのですが、その導入にまつわるエピソードを主に飯田さんの視点からまとめたものになる予定です。
同社のスケーリングに関しては、年明け頃から飯田さん他とずっと議論を重ねてきました。色々な可能性を検討する中で「FASTってフレームワークもあるよ」と情報を入れたのは僕ですが、導入を僕から勧めたことはただの一度もなかったし、FAST導入が決定したときはマジかって思いました（笑）
個々のメンバーの強い自律性が求められるフレームワークで、ログラスさんがFAST導入トライアルを公表したあと、巷では「人類には早すぎる」（tuneの日記 より）と言われたし、
そのちょうど1ヶ月前に僕自身、ログラス社内で「人類にはまだ早いかもしれない」（原文ママ）と、同じような言葉で評価していたくらいなんですが。
でも何やかや、今のところいい感じに回り始めています。まぁ導入まではほんとハードだったし、今後もぽつぽついろんな課題が出てくるとは思うのですが。
また、今回の話で面白いのは、FAST導入を主導したEMの飯田さんが、その自律性の高さゆえに、導入後はEMとしての仕事がなくなってしまうというジレンマに陥ったことでした。そのパラドックスに彼が数カ月間悩み抜いた結果どういう境地に至ったか、てな話が聞けるのも、このプロポーザルのポイントかと思います。
といったところで、そんな話をRSGT2025で聞いてみたい！という方はぜひLikeをお願いします。
……あ、これとは別途、こちらは僕の単独で「プロダクトマネージャーこそがリーダーだった！？ リーダーシップ論から見るPdMとスクラムのいびつな関係」 というプロポーザルを書きました。こちらは僕の研究者人格でのプロポーザルで、こちらの話もまた追々どこかでする機会もあろうかと思います。
スクラムフェス仙台2024に参加してきました
8/23, 24 に開催されたスクラムフェス仙台2024に参加してきました。
ということで軽い振り返りを。
2つのセッションで登壇した
今年はなるたけ研究に時間を割きたいという思いがあり、スクフェスへのプロポーザルなどは抑えめにしていたのですが、まぁ夏に1回くらいええやろ、ということで仙台には出すことに。
で、思いついたアイデア2つをまんま仙台に出したら2つとも採択されてしまいました。大変ありがたかったですが準備がやっぱり大変だった……
自分の講演1「チームが自己組織化してから敢えて専任スクラムマスターを置いてみたらめちゃめちゃワークした話」
自分の講演2：実践 vs 理論：叩き上げのスクラムマスターが実践した手法を研究者が学術的に分析する！
中身についてはぜひスライドなり、今後公開されるであろう当日の録画をご覧いただくとして、2つとも初の共同登壇だったんですが、違いは、1つめがオンラインで2つめがオンサイトの現地登壇だったことでした。
1つめに関しては共同登壇した3人のうち、佐藤さんが東京からオンラインでつなぐ、ということで、登壇者同士もリモートでやりとりするので、やっぱり結構難しいというか、担当分けてただ読んでくしかできなかったです。
他方2つめは、元々壇上で雑談するノリで気楽にやろうと打ち合わせていたのもあり、すごくやりやすかったですね。聴衆の反応もわかりやすいし。
仙台のオンライントラック、現地会場でも中継しているのですがその人たちとコミュニケーションをとる手段がほとんどなくて、Discord使う人も少数派だし、Zoomの人数カウントにも反映されないので、何人の人が聴いてたのかもわからず聴衆の反応もわからない、という辛さがありました。いい方法ないかなぁ。
キーノートがやばかった
「特務機関NERV」を開発している株式会社ゲヒルンの石森社長によるキーノート、凄かったです。石森さんの口から語られるストーリーがあまりにもドラマチックで、まるで映画を観ているかのような気分になりました。
こんな企業が現実に存在してビジネスを維持できているのはある種の奇跡だと思います。ビジネスが目的ではなく、あくまで自分たちがやりたいことをやり続けるための手段であるという信念を社長が貫いていて、そうなると確実に発生しそうな株主との衝突をうまくやりすごせるNo.2がいて、普通の会社には馴染めないかもしれない尖ったギーク達がパフォーマンスを発揮し続けられる環境が作れていて……という、あらゆるピースがキレイにハマっているのがまさに奇跡ではないかと。
この日の夜、後述する「おおひらラジオ」で、こうした尖ったギーク達をスクラムはコミュニケーションを重視するあまりに排除していっているのでは、本当にそれでいいんだっけ、という話をkyonさんとしていました。
何人かの方とお話しした
今回、他のセッションも当然見てたのですが、現地で人と話してる方が色々印象的だったので書き残しておきます。
横道さんと話した
1日目のネットワーキングパーティの時間、プロダクトコーチの横道さん が声をかけてくださいました。実は初対面。
横道さん、6月にあったスクラムフェス大阪のキーノートで出世とかマネジングアップとかの話をされて結構コミュニティ内でも好意的な反応があったんですが、自分がそれが実は嫌で、1週間後くらいにTwitterでついこんなつぶやきをしたんです。
率直に言って、僕はマネジングアップって言葉がかなり苦手です
— takeo (@bonotake) 2024年7月6日
マネージャーが「上」にいるって前提なのがね
僕は積極的に使いたくない言葉です
それを横道さんが捕捉されてて、開口一番「マネジングアップ嫌なんですか？」って話を振ってこられ……正直めっちゃ焦ったんですが、腹をくくって、かなり率直ベースで横道さんのキーノート批判を本人に対して一通り話しました。
横道さんはそれを真剣に受け止めてくださって、パーティ終了時間がほぼ終わって会場を追い出される直前まで2人で色々話しこんでました。
その日宿に帰ってから「初対面の人相手に率直に話しすぎたのでは？」と思い、翌日の会場で横道さんを見かけて謝罪したのですが、むしろフィードバックをもらえてありがたかった、と言ってくださってほっとした次第。今たまたまですが共通の企業を支援させてもらっていることもあって、今後も色々話しましょう、といってお別れしました。
どういう議論をしたかの内容を書き出すと長くなるので詳細は別の機会に譲りますが、ごく一部だけ書き出すと、横道さんは経営層の人たちと話した経験などがキーノートのモチベーションになっていたようで、なので横道さんが想定するマネジングアップの対象が実はトップマネジメントに寄っているのでは？ と自分は推測しました。当日のキーノートだとミドルマネジメント層が対象に聴こえてしまったのですが。
日本はまだ企業丸ごとアジャイルトランスフォーメーションした事例ってほとんどなくて、仮にアジャイルを積極導入している企業でも普通はある階層までにとどまっており、それ以上は従来の階層型組織のままなので、ある階層以上のトップマネージャーに対してまだまだ「マネジングアップ」が必要、と考えるのはまぁわかる、という感じでした。
Ryoさんと話した
2日目の昼過ぎ、偶然 yamanecoのRyo Tanakaさん と初めてお会いして、お話しする機会がありました。
僕は数か月程度ですがホラクラシーを実践している企業で働いていたことがあり、その体験を以前おおひらさん に以前したことがあって、それ以降おおひらさんに度々「Ryoさんとぜひ話してみてほしい」と言われていたんですが、 それがひょんな拍子に実現した次第。
それでホラクラシーの話をしたんですが、Ryoさんが常に1つの組織を「ホラクラシーを実践するティールな組織」と「営利企業を運営するオレンジな組織」の2重人格のような体でずっと話されるのが大変興味深かったです。あー、ホラクラシーをやりこんだ人はこんな思考の仕方をするんだ、というのが学びでした。
理に適っているし、なるほどなーと思いつつ、常に2つの人格の間でアンビバレントな2つの思考を同時にし続けられるようになれる人ってどれくらいいるのかなぁ、とも。
ただ、僕は今ログラスさんでFASTというフレームワークを導入している最中で、あれもティール組織なので割とこの思考法は役に立つかも、とも思いましたし、このままやっていけばログラス社内の何人かもまたそういった思考にたどり着くかもしれません。ただし考案者の Quinton Quartel は恐らくそんな思考の持ち主ではなく、普通のアジリスタ（アジャイル実践者）な感じです。一般的なエンジニアからすると夢想家に見えるかもしれませんけど。
トークセッションひとことメモ
時間が無くなってきたので一言コメントですが、いくつかのトークセッションに参加しました。
- rin otomo さんの「チームのリーダーとして振る舞うにあたって大事にしてよかった７つのこと」で、不意に自分の名前が出てきて面くらいましたが、チームのリーダーとして何をどう考えればいいか、といった中にRSGT2024での僕の講演にインスパイアされたところがあったそうで、シンプルに嬉しかったです。自分が話したことが見知らぬ誰かのためになっていた、というの、いいものですね。
- naibanさんの「仙台育英の監督さんがサーバントリーダーそのものだった話」、仙台育英の監督の本をベースにサーバントリーダーシップを騙る話だったのですが、たまたまこの直前のセッションが自分としのぴーさんのリーダーシップ関連の講演で、たまたま自分が野村監督の『「問いかけ」からすべてはじまる』を参照しながらリーダーシップを語ってしまったため、ネタを被せてしまった形になっていました。いやはや申し訳ない。でもいずれちゃんと、仙台育英監督のリーダーシップについてnaibanさんとちゃんと話してみたいな、と思いました。
おおひらラジオ
1日目のネットワーキングパーティの後、翌日の朝最初のセッションが自分の講演だったためさっさと宿に帰ったんですが、ふとホテルの部屋でDiscordを覗くと「おおひらラジオ」なるチャンネルが。
kyonさんとおおひらさんが何やら話していたので、自分も何となく入って、その後語りました。なんかめっちゃ濃い話をいっぱい気がします。中でもおおひらさんのQAスタイルがエンタープライズ系ソフトウェア特化のかなり特殊なものだというのがどんどん解剖されていく様が大変楽しかったです。
2日目も、主にまつしゅーさんと、自分やまつしゅーさん含めてスクラムコミュニティの人が最近いろんな大学でアジャイルを教える流れができているようで、やっていき、的な話をしていました。
アジャイルスケーリングのための CASP 1 っていう資格を取ったよ
この度、CASP 1っていうScrum Allianceの資格を取りました。
たぶん存在自体知らない人が多いと思うので、このブログ記事で軽く紹介をしてみようと思います。
この資格は正式名称を Certified Agile Scaling Practitioner 1 と言って、アジャイルのスケーリングに関する資格です。
スケーリングの資格としてのCASP 1の大きな特徴は特定のフレームワークに依らないというところです。LeSSに関するCLPとかScrum@Scaleに関する
RS@SPとかありますが、これはどのフレームワークか、とか関係なく、あるいはフレームワーク以外の手段も全部ひっくるめて、何を使ってどんな風に考えてチームより大きい組織にアジャイルを導入したらいいか？ といったことを扱います。
去年の12月くらいに創設されたばかりの資格で、自分はそれをたまたま見つけて、割と興味本位で研修を受けてみた次第。
ただ、本当は5月に、イタリアのコーチングの会社がオンラインでやる研修に申し込んでたんですけど、人が集まらずキャンセルになり、改めて今回オーストラリアのGlow Your Agilityがやってる研修に申し込んだのでした。トレーナーのSam Bowtellさん曰く、現時点でこの研修をやってるトレーナーは世界で20人くらいでは、とのこと。
周囲でこの資格を取ったって話を全然聞かないので、ワンチャン日本人で最初？ とか思ってましたが、そのSamのクラスに集まった8人の生徒の中に偶然もう1人日本人が。偶然にも、過去にRSGTでお会いしたことのある方でした（許可は取ってないのでお名前は伏せますが）
ちなみに研修の最初のほうであった話として、スケーリングには horizontal scaling（水平スケーリング） と vertical scaling （垂直スケーリング）の2種類があって、CASP 1 は水平スケーリングしか基本的に扱わない、とのことでした。ちなみに水平は同一組織内の複数チームが連携するためのスケーリングで、垂直は開発組織とビジネス部門とHRと、といった異なる部署をまたいだスケーリングのこと。
たとえばScrum@ScaleやSAFeは両方を扱えますが、LeSSは水平のみのフレームワークです。
垂直スケーリングは、きっと今後登場すると想像される CASP 2 とか 3 とかでやることになるのかもしれません。
研修の内容としては、各種フレームワークの比較をやったり、あとスクラムパターンとか、Quarterly Planning（SAFeでのPIプランニング）とかロードマップとかOKRとか、もやりました。チームトポロジーも入ってました。やることめちゃめちゃ多い！
Samの趣向でワークショップがすごろく形式になっており（⁉）止まったマスにあるやつを学んでいくという形式で、そもそも全部は研修中にカバーできない前提で「残りは、気になったら自分で勉強してね」とのことだったんですが、当日扱った分だけでも膨大な内容だった気がする……
自分としては、日数増やしていいから、もっと1つ1つを丁寧にやりたかったかもしれません。Samも「自分がこのコースを開催するのはこれが初めて」ということで、今後ブラッシュアップされていくのかも。
あと、そういう具体的なテクニックや手法だけではなく、いわゆるチェンジマネジメントの話もやりました。やはり2桁を超える人数の組織を変えようと思ったら、どうしたって多少なりとも何かしら抵抗を覚える人は出てきたりするし、心理的抵抗だけでなく、下手をするとやったことないことをやる羽目になってパフォーマンスがガタ落ちする人なんかも出てきます。だから一度に意思統一なんて無理だし、いきなりビッグバン的に組織改編すると必ず軋みが来るので、それをどういう考えのもとに乗り越えていくか、など。これは実際の例をケーススタディにして、ひたすらディスカッションしました。（外国人にはきつかった…）
内容的には日本でも需要ありそうだと思うんですが、どうなんでしょうね？
