フロー効率重視の開発について考える 後編 ～中長期目線の話～

註：この記事は前後編の後編です。前編を先に読むこと推奨です。 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人と、ほぼソロ開発が主体になりそうな環境になります。この数値を、その組織が今置かれている状況にマッチするよう調整することで、適度にアンサンブルっぽく適度にソロっぽい開発体制を作れるし、その塩梅を動的に調整することもできます。

おわりに

長々と書いてきましたが、実際のところ最適な塩梅というのは個々の状況に依存するので、基本的な概念とベースとなる考え方を押さえた上で、そのときそのときの状況に適応する形で調整できるようになると良いのではないかなぁ、と思います。
業務だと普通はチーム/組織で開発すると思いますし、せっかくチームで開発しているのなら、個人に頼りきった開発しかしないよりはチームワークを覚えた方が良いし、そこにはフォーメーションが存在して、フォーメーション次第で様々な効果を発揮できます。そうしたフォーメーションまで考えて柔軟に戦略・戦術を組めると開発組織としては相当強くなるはずです。

そしてまた繰り返すのですが、アンサンブル開発はやれと言われてすぐできるものではなく、学習コストがあるし、ソロ開発に比べれば結構スキルが要求されるものです。なので、やってみたいと思うチームは、ここに書いたようなパフォーマンスを最初から出そうと思わず、しばらくは練習とだと思って色々試すところから始めてみてください。それなりにこなせるようになったら色々調整していって、より最適な塩梅を自分たちで模索していくとよいのではないでしょうか。

*1:ペアプロ・モブプロが全くパフォーマンス面の効能がないかというとそうではありません。モブプログラミングを提唱した Woody Zuill氏は、その効能の1つとして「フロー状態で開発ができる」ことを言っています。ここでの「フロー」はフロー効率のフローとは全く違う意味で、複数人で会話しながら作業することで、集中力の高い状態を維持できる、ということです。スポーツの世界でいう「ゾーンに入る」です。

フロー効率重視の開発について考える 前編 ～短期目線の話～

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が最近公開されていました。

note.com

【余談おわり】

一方、とにかく量で攻めるのではなく、

1. 1つずつリリースして、顧客・市場からフィードバックを得る
2. そこから自分たちが顧客について学び、その学びを活かして次の弾込めをする
3. 以上2つをひたすら何度も回す

とすることで、当たりくじを引く確率をなるべく増やし、かつ無駄打ちをしなくてよい（あるいは、ハズレを引いたときの悪影響をなるべく小さくできる）アプローチが俗にリーンスタートアップと呼ばれるビジネス戦略です。

で、リーンスタートアップを実践する上では、上記のサイクル（いわゆる仮説検証のサイクル）をどれだけ速く回せるか、が開発組織としての生産力につながります。そして、この前提においてリードタイムが短いことは大きなアドバンテージになるのです。

アンサンブル開発に関する補足

ここで注意が必要なのは、アンサンブル開発はある程度慣れないとできない、ということです。
ソロ開発は、それこそ学校の授業でプログラミングを習っても、あるいは趣味で開発したとしても、だいたいこの形式に自然と収まるのでいちいち習得の時間を取らなくてもいいです。一方アンサンブル開発は、それなりに経験やトレーニングを積んで、アンサンブル開発での考え方になじまないとうまくこなせない人が大半ではないかと思います。

加えて、上の説明だけだと「リードタイムを短くしたければ人を追加すればええんや！」と安直に思う人もいるかもしれませんが、これはまさに人月の神話で、「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」というブルックスの法則が示すのと同様の状況に嵌ってしまう可能性があります。
上で書いたようなアンサンブル開発への慣れも含め、開発者の学習曲線を無視してはいけない、ということです。

ここで思考を止めないで

さて、ここまで読んで、ソロ開発とアンサンブル開発はどちらもアリ？ という気分になられたかもしれません。

実際、短期的目線だとどっちにもメリットはあるんですが、中長期的な目線だとまた違った議論になっていきます。中長期的視点ではリソース効率とフロー効率の観点が中心になり、その視点だと全然異なる状況が見えてきます。

……ですがここまで長くなりすぎたので、以降の議論は後編に譲ります。

bonotake.hatenablog.com

FAST導入に関するRSGT2025プロポーザルのお話

最近支援に入っているログラスのエンジニアリングマネージャー飯田さんが、RSGT2025にプロポーザルを書きました。一応僕もおまけで登壇予定です。
タイトルは「エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢について」です。

confengine.com

今年に入ってからログラスさんにて、FASTという、国内では過去おそらく導入事例のないアジャイルスケーリングフレームワークを導入する支援をしてきたのですが、その導入にまつわるエピソードを主に飯田さんの視点からまとめたものになる予定です。

同社のスケーリングに関しては、年明け頃から飯田さん他とずっと議論を重ねてきました。色々な可能性を検討する中で「FASTってフレームワークもあるよ」と情報を入れたのは僕ですが、導入を僕から勧めたことはただの一度もなかったし、FAST導入が決定したときはマジかって思いました（笑）

個々のメンバーの強い自律性が求められるフレームワークで、ログラスさんがFAST導入トライアルを公表したあと、巷では「人類には早すぎる」（tuneの日記 より）と言われたし、

tune.hatenadiary.jp

そのちょうど1ヶ月前に僕自身、ログラス社内で「人類にはまだ早いかもしれない」（原文ママ）と、同じような言葉で評価していたくらいなんですが。

でも何やかや、今のところいい感じに回り始めています。まぁ導入まではほんとハードだったし、今後もぽつぽついろんな課題が出てくるとは思うのですが。

また、今回の話で面白いのは、FAST導入を主導したEMの飯田さんが、その自律性の高さゆえに、導入後はEMとしての仕事がなくなってしまうというジレンマに陥ったことでした。そのパラドックスに彼が数カ月間悩み抜いた結果どういう境地に至ったか、てな話が聞けるのも、このプロポーザルのポイントかと思います。

といったところで、そんな話をRSGT2025で聞いてみたい！という方はぜひLikeをお願いします。

……あ、これとは別途、こちらは僕の単独で「プロダクトマネージャーこそがリーダーだった！？ リーダーシップ論から見るPdMとスクラムのいびつな関係」 というプロポーザルを書きました。こちらは僕の研究者人格でのプロポーザルで、こちらの話もまた追々どこかでする機会もあろうかと思います。

confengine.com

スクラムフェス仙台2024ã«å‚åŠ ã—ã¦ãã¾ã—ãŸ

8/23, 24 に開催されたスクラムフェス仙台2024に参加してきました。

www.scrumfestsendai.org

ということで軽い振り返りを。

2つのセッションで登壇した

今年はなるたけ研究に時間を割きたいという思いがあり、スクフェスへのプロポーザルなどは抑えめにしていたのですが、まぁ夏に1回くらいええやろ、ということで仙台には出すことに。
で、思いついたアイデア2つをまんま仙台に出したら2つとも採択されてしまいました。大変ありがたかったですが準備がやっぱり大変だった……

自分の講演1「チームが自己組織化してから敢えて専任スクラムマスターを置いてみたらめちゃめちゃワークした話」

speakerdeck.com

自分の講演2：実践 vs 理論：叩き上げのスクラムマスターが実践した手法を研究者が学術的に分析する！

speakerdeck.com

中身についてはぜひスライドなり、今後公開されるであろう当日の録画をご覧いただくとして、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の資格を取りました。

CASP 1のバッジ

たぶん存在自体知らない人が多いと思うので、このブログ記事で軽く紹介をしてみようと思います。

この資格は正式名称を 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桁を超える人数の組織を変えようと思ったら、どうしたって多少なりとも何かしら抵抗を覚える人は出てきたりするし、心理的抵抗だけでなく、下手をするとやったことないことをやる羽目になってパフォーマンスがガタ落ちする人なんかも出てきます。だから一度に意思統一なんて無理だし、いきなりビッグバン的に組織改編すると必ず軋みが来るので、それをどういう考えのもとに乗り越えていくか、など。これは実際の例をケーススタディにして、ひたすらディスカッションしました。（外国人にはきつかった…）

内容的には日本でも需要ありそうだと思うんですが、どうなんでしょうね？

ログラスがOrg Topologiesを使って組織の目標設定をした話

この記事は、元々僕がLinkedInに2回に渡って投稿したものがまとめられ、Org Topologies というフレームワークの公式サイトにケーススタディとして紹介されたもの（こちら）の翻訳です。
えらく仰々しく掲載していただいたし、せっかくなので日本語版を自分のブログに載せておくか、と思って翻訳することにしました。元英文は自分が書いていますが、それを雑に日本語へ機械翻訳したあと軽く手を入れる、ということをやっています。大変翻訳文チックな日本語になっていますがご容赦ください。
ただし、ただの単なる翻訳ではなく、僕なりの考えや意味の補足をちょこちょこ挟んでいます。

目次

ログラスでOrg Topologiesを試した

私は昨年、Zuzi Shocova のA-CSM研修を受けた際、研修中に彼女が Org Topologies に軽く言及したのをきっかけに興味を持つようになりました。
それは、構造化や高い適応性の促進、透明性のある変更プロセスの確保を通じて組織設計を強化するように設計されたフレームワークでした。

Org Topologiesは、Scope of Capabilities と Scope of Work という2軸を使って展開します。 これらの軸を組み合わせると、さまざまな組織パターンまたはタイプを表す16のアーキタイプが形成されます。 これらのアーキタイプは、組織の適応性とパフォーマンスを最適化するために組織を識別、評価、設計するのに役立ちます。

Scope of Capabilities は、クロスファンクショナリティのレベルと、ユニットが独立して価値を提供する能力を測定します。 ケイパビリティの統合度が高いということは、技術的な依存関係が少なくなり、自律性が高まることを意味します。 一方Scope of Workは、タスク単位の狭い作業から、顧客のニーズ全体を網羅する幅広い価値定義まで、ユニットが処理できる作業のスコープの大きさを評価します。

このフレームワークにより、2軸マップ上で16の異なるアーキタイプを簡単に視覚化して分類できます。 これらのアーキタイプを理解することで、組織は十分に練られた組織設計を行い、変化するビジネスニーズに対してより高い適応性とレジリエンスを得ることができます。

2024年1月に、私は経営管理の生産性向上を目的としたクラウドベースのサービスを提供する日本企業、 ログラスに Org Topologies を導入しました。 同社は当時、プロダクトを複数の機能領域に分割し、各領域において独立したスクラムチームを置いて開発していました。 それぞれのスクラムチームは単体としては高い能力を発揮していましたが、チーム間の連携はそれまであまり行われていませんでした。

私は 30分間の短いセッションで Org Topologies を簡単に紹介しました。するとログラスの皆さんが強い関心を示し、翌日には開発組織の全メンバーを対象に1時間のワークショップが開催され、各チームの現状をマップ上にプロットすることになりました。

短いワークショップでの自己評価のみでしたが、私の予想通り、ほとんどのチームが A1〜A2 に位置づけられました。 詳しく説明すると、A1およびA2のアーキタイプは以下のようなタイプの組織構造を表します。

• A1 (フィーチャーに重点を置いた、サイロ化された機能グループ) : このアーキタイプ内のチームは特定のスキル/職能に特化し、フィーチャー単位の開発に取り組んでいます。サイロ内で作業する傾向があり、他のチームとのやり取りは限られています。

• A2 (フィーチャー重視の、不完全なマルチスキルチーム) : これらのチームはさまざまなスキルを持っていますが、完全にクロスファンクショナルではありません。また、A1チームと同様にフィーチャー単位の開発に重点を置いていますが、チーム間のコラボレーションが少し多くなっています。

このあと社内では主に、自分たちがAレベルからBレベルへ昇格すべきか、についての議論になりました。Bレベルのアーキタイプは、より協調的でビジネス目標に沿ったものであり、市場のニーズに対する俊敏性と応答性が向上します。たとえば、次のようになります。

• B2 (ビジネス領域に重点を置いた、不完全なマルチスキルチーム) : 完全にクロスファンクショナルではないが、さまざまなビジネス領域間でより協力的に作業し、ビジネス目標とのより良い整合性を促進するチーム

• B3 (ビジネス領域に重点を置いた、エンドツーエンドの高速フローチーム) : あるビジネス領域全体を対象とし、より迅速な提供と高い適応性を促進する、高度にクロスファンクショナルなチーム

そして彼らを観察しているうち、私はいくつかの点に気づきました。

1. 一部の人々の視点は、組織全体ではなく、自分のチームのみに向けられていました。たとえば何人かは、自分のチームがBレベルに昇格したいと述べましたが、これには他のチームとの強い合意と協力が必要であることを認識していないようでした。

2. 参加者のほとんどはBレベルチームの利点を認識していましたが、Bレベルまたは "team of teams" が、自分たちの組織において実際どのようなものになるかは想像できていないようでした。

3. Aレベルに留まることも現実的な選択肢であると感じた人もいました。彼らは、現行チームが十分「最適化」されており、各チームとも非常に生産的である一方、Bレベルに移行するにはコストがかかるだろうことを主張していました。

以降、ログラス開発組織の皆さんと私は、彼らの組織がチャレンジすべき課題は何なのか、そして彼らの目標は何かという点について長い間議論を重ねました。 そして最終的に、彼らは「昇格」することを数ヶ月かけて決断しました。

そして5か月後、開発生産性カンファレンスにて

5か月後の2024年6月、開発生産性カンファレンス が開催され、ログラスVPoEのいとひろさん（@itohiro73）が講演しました。 いとひろさんは、Org Topologiesを使って1月に行ったマッピング活動を紹介し、現在チームがA1-A2にあり、今後B2-B3に移行することを決定したと語りました。

Org Topologies を使ってAレベルからBレベルに上げることを説明しているいとひろさん

彼はさらにアジリティを組織に拡張していくことについて話し、そのため現時点では、FAST Agile の導入を試みる予定だと述べました。

FAST (a.k.a FaST Agile) は、カンバン、オープン スペース テクノロジー（OST）やその他アジャイルのアイデアを融合した、軽量でスケーラブルなフレームワークを作成するアプローチです。 集団（コレクティブ）を形成し、最初のセットアップで組織基盤を構築したあと、「バリューサイクル」と呼ばれる、2日程度の短いイテレーションサイクルを通じて継続的に改善することに重点を置いています。 このサイクルごとに、コレクティブはその中での同期と自己組織化を毎回行い、およそ30分だけの定期的なミーティングを通じて全体のアラインメントを取りながら開発を進めます。

いとひろさんによる、FASTフレームワークについての説明

このときのいとひろさんの講演資料はこちらで見れます。この記事で語った内容は、主に資料の後半で述べられています。

speakerdeck.com

この決断はログラスにとっては大きなチャレンジかもしれませんが、そこから得られる経験は、たとえFAST導入が上手く行かなかったとしても、彼ら組織にとって貴重な財産になると思っています。 私も、今後も積極的にサポートしていくつもりです。

夜目が効かない人が夜に本を読むためのライフハック

最近夜目が効かなくなって、夜、特に寝る前の寝床でに紙の本を読むということがほぼほぼできなくなっていました。 なので、どうしても読みたければ電子書籍で…となってたんですが、このクリップライトのおかげで一気に問題が解消したので書き留めておきます。

クリップライト led デスクライト テーブルランプ LED 電気スタンド LEDブックライト 3段階調色 無段階調光 デスクライト スタンドライト テーブルランプ 譜面ライト USB充電式 記憶機能 仕事 勉強 卓上 読書灯 寝室 子供 在宅勤務 授乳 目に優しい 停電 防災用

これ、LEDライトと大きめのクリップがセットになってます。
で、普段はベッドの縁につけて夜間照明に使ってるし、本を読む時はクリップでページを挟み、ライトでページを照らしながら読むという大胆な読み方をしてます。それで寝る前に紙の本を読むのが全然苦ではなくなりました。

いやマジで助かった。最近睡眠不順で、あんま寝る前にモニタ画面を観たくなかったので、ほんとありがたやです。