アジャイルをスケールしたいときの注意点
人間だれしも大きいものが大好きなので、大きいままやってもムダじゃね、な精神から生まれた(嘘)アジャイルもスケールさせようとするのは、ピラミッドや天守閣が巨大化していったのと同じくらい自明なのでしょうがない（諦め）
で、大規模アジャイルがクソ扱いされる場面はとてもよく見かけるし、大規模にしました！っていう場面もよく見かける。
果たして大規模アジャイルってどうなんだ。
昔そんなの書いた気はする。
大規模にアジャイルをやるにはどうしたらいいか、に対する答え - 海と山が好き
身もふたもない結論で話をしていたけど、それでもやっぱり大規模にやりたいって人は後を絶たない。
（というかスクラムマスターが昇進したりして影響力を持つと大体そういうことをしようとすることが多い気がする。）
これまでに経験してきた 3~4チームといった小規模なものから、12,3チームといった規模のアジャイルプロジェクトを見てきて、いくつか大事なポイントは見えてきて、スケールしたときに考えるべき注意点ってことでまとめておきたい。そのうち忘れるので。
スケールしたときに考えるべき点は、主に以下の3つな気がしている。
① アジリティ
② エンゲージメント
③ 顧客理解
----
① アジリティ
速くいきたければ一人で行け、のことわざではないが、取り組む人数が増えるほどスピードは下がる。
創業期は少ない人数でやりたいことがすぐに実現できたのに、チームや会社が成長して人が増えてきたら、何をやるにも時間がかかる（＝リードタイムが減る＝アジリティが下がる）ようになった、、っていうのをとてもよく見る。
つまりスケール時の注意点①は、
1チームでやってたときよりも、
バリューストリームのリードタイムが悪化していないか？
となる。（自分に刺さって死ぬ）
解決するための手段としては、Team Topology のような形での組織・アーキテクチャを設計することが組織的な取り組みとしてはベターな解な気はしている。
あとは書くな・話せ、の徹底とか。
（ご参考：【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com）
② エンゲージメント
規模が大きくなるほど、目的に対するエンゲージメントが低下しやすい。
社会的手抜きではないが、エンゲージメントを維持するのに多大なコストを支払う必要が出てくる。
解決策はいつの世も一緒なので割愛。
③ 顧客理解
チームが増えるにしたがって、顧客の顔が見えないケースが非常に増えてくる。
XP でいえば顧客同席だったのが、Scrum になるとプロダクトオーナーを介するようになったり（話すなとは言っていないが話さないフォースを生みがち）、組織が大きくなると、PO すら営業やマーケ・カスタマーとしか話してない、みたいなことも出てくる。冗談のような悲劇（よく見る）
というわけで注意点③としては、
1チームでやってたときより、顧客とエンジニア間のコミュニケーションホップ数が悪化していないか？
になる。
結果として、顧客のことがわからん、何を作っているのかわからんが指示通りに作る、みたいなことがよく起きる。
結果として、PO がそう言ったんじゃないですかーとか、チケットに書いておいてくださいよ、みたいな内ゲバが起こりがち。何と戦っているんだ俺たちは状態。
解決策は、、、、、、、現場に行けとしか。
要は創業期の熱量やスピード感をスケールしても末端まで維持できてるか？がわかりやすい観点かもしれない。
とはいえそれらの指標がどれくらい悪化するか、悪化したところでどれくらい影響があるか、その分のメリットを享受しているか、はコンテキストによるので、目をそらさずに Struggle してね。
（PO だってうまくいっているからパターンなんだから。It Depends よ。）
大企業でのアジャイルがアレな理由
# 大企業でのアジャイルがアレな理由
大企業でのアジャイルがアレな理由
コスト意識が無い。
ヒットさせるために最速でゴミだと気付きたい、という意識はない。
サンクコストを追い求める。
むしろ新しい手法にチャレンジしててえらい！って手法の採用自体が目的化する。
とくに Lean discovery なサービス創造とか。
誰に踊らされているのか分からないが、突然新しい手法に目覚め、やったこと自体を評価してもらい、成果物はアピールするが、結果は見ていない。
本来は結果を出す（＝サービスとして売り上げて生きていく）ためにLean なプロダクト探し、アジャイルなプロダクト実現があるのに、その逆。
それを生み出しているのは、圧倒的なコスト意識の低さ。
与えられている投資に対して、いつまでにどの程度のアウトプットを出さないといけないか、という意識が低い。コケても死なないし理由を作るのが得意な賢い人も多い。
と同時に、大企業ならではの管理費用の高さがあり、社員数名を投下したコストを回収する売り上げ発生なんてとてもじゃないが無理。
（代わりに、福利厚生とか、社内サービスは充実しているんだけどね。）
なので、大企業でアジャイルじゃないと生きていけない、みたいなとこは少なくて、作りすぎの無駄とかと一緒にスプリントを重ねるは肥大化プロダクト開発が多いような気はする。
まあ物量でフォロワー戦略取るのが賢いよね、体力あるし、と言われれば、それはそう。。
アジャイル導入がきらいだ
なんかよく見かける文言、「アジャイル導入」
この言葉が好きじゃない、と言うか嫌いだ
「導入」ってことは外からインストールするといった意図であろう
つまり対象は未インストールだ
という意図に気づいているかいないかはともかくその構造が背景に認識されている
あれ、アジャイルって形容詞で程度問題じゃないんだっけ？
相手のアジャイル度合いがゼロだって判断が伴ってないですか？
って気分になる
で、大体こういう方々が現場に行くと、できてないことリストとやるべきことリスト （施策、とか、打ち手、みたいなどうでもいい単語に置き換えられがち）
一方で、今の現場、現状のありざまが、どれくらいアジャイル度合いがあるか、といったことはまず話されない
目に入ってないか、せいぜい、どストレートなダメ出しが憚られるのでお通しレベルの現状褒めが出てくる程度
これって問題か？別に問題じゃなくない？だって現場は改善されるよ？みたいな
その現場が教科書から外れてる理由ってはその現場とチームが抱える制約やコンテキストやナラティブの帰結なので、そこを見ないで教科書だけ見ても効果がないんよ
患者を見ないで医学書だけ見てる医者みたいなもんで、できるのはせいぜい外科手術の対処療法だけ
なんなら元のコンテキストの制約が悪さする方向になってしまって悪化することもたまにある
なので、教科書とかガイドとか他チームの取り組みとか眺めてないで、まずチームを観察しましょう
初めて入るチームなら、まずそのチームがやれている良い所を10個見つけましょう
それを見つけた上でなお、相手が「アジャイルになっていない」ので、啓蒙（無知に教えるの意）、導入、という言葉を使いたいと思うかよく考えるべき
まあ現場から遠いマネージャに話すには使いやすいんだろうし、商業主義的にコンサル屋さんが商材を売りに来るいつものパターンでDXとかと変わらんレベルで扱われてるんやろな、とは冷静になって察するけど。
ふりかえり（レトロスペクティブ）でプロセスを改善する
アジャイル開発でふりかえりをやってプロセスを改善するのが難しいというお話。
ふりかえりってなんだっけ
XP でいえば「リフレクション」（内省）
スクラムでいえば「レトロスペクティブ」
日本国内では「ふりかえり」
※ 漢字の振り返りではなくひらがなの「ふりかえり」がよく使われている。意図して使い分けられている（PF 時代のころから？）
目的はどれも、次よりよく仕事をするために何を変えるかを考えて実行すること
※ 逆に言えば、型どおり仕事をする主義へのアンチテーゼにも見える
ふりかえりではプロセスを改善する
というだけではないのですが（例えば関係性や、立ち位置の認知共有でも「よりよく仕事をする」が達成できるならそれもアリだと思う。
とはいえ、どう仕事を進めるかという点では、プロセスや環境の改善が必要になることがままある。
ふりかえりでプロセスを改善するのが難しくなりがちだ
よく見かけるシチュエーションが、
- 課題：XX に課題があり、完成しなかった。
- 分析：XX で使っている A ライブラリを B ライブラリに変更する
- アクション：B ライブラリの導入
みたいなもの。
何がイマイチなのか
発生した課題（XX が完成しなかった）は認知されているように見える
分析もされて、問題（A ライブラリがクソ）の特定もされているように見える
アクション（Bライブラリに乗り換え）も明確になっているように見える
一方で、明らかになったのは今回の問題とその対処であって、
この「問題が課題と生み出してしまった構図」については触れられていないので、次も同じような「構図」が同様の問題を引き出してしまう。
（もちろん、A ライブラリに起因する同様の問題は発生しなくなるが）
よって解決する影響先が低いことにより再現性が低い（≒ふりかえりのアクションの ROI が低い）状態になってしまうため、この状態はイマイチととらえられそう。
どういうアクションだとよさそうか
たとえば、A ライブラリに課題があることが「完成しなかった」に紐づいてしまった理由は何かを深掘りするとよいことが起こりやすい（気がする）
なぜ課題＝終わらないとなったのか？他の開発アイテムは課題があっても遅れないのでは？ではなぜ今回のケース（PBI？）ではそれを発症したのか？
（それがAライブラリであろうということは想像できる）
では A ライブラリでなくても発生するとしたらどんなときか？A ライブラリを使っているということは何が特有だったのか？そしてそれが遅延につながった理由はなんだろうか？
完成しなかったということは、課題の解消が時間がかかったということなのか、課題の検知が遅れたということなのか？課題が発生しないようにする（ライブラリを差し替える）方針とは別に考えないといけないことを見落としていないか？とかを考えるとよさそうではある。（たとえば、課題を相談しにくい雰囲気になっていないか？とか）
なぜそうした観点を持つことが難しいのか
かならずしもそれが理由というわけではないが、過程に踏み込んでしまうということは、自分たちの内面の課題と向き合うことになってしまうことも一因な気はしている。
「ユーザーが理解していなくて」「ライブラリがいまいちで」といった、自分たちのプロセスの外へ問題を移動すると、自分たちは傷つかなくて済むので、間違いなく安心。
確かに、過程を深掘りすると反省会チックになり、Happy なスクラムチームが壊れてしまうのではという懸念がある。
（一方で、それが心理的安全性が高くない状態であろうことは想像はつく）
プロセスにフォーカスできてないと気づく方法はあるか？
とくにこれといったモノはない気がするけど、PBI になるようなアクションであれば、たぶんプロセスにフォーカスしていないことが多い。
PBI のインクリメントが導入されるのはあくまでプロダクトで合ってチームではないので。
どうすればイマイチでなくなるか
今のことろこれだ、って体系的にまとめてない
- どうイマイチになっていると気づけるか
- どうすればよりプロセスにフォーカスできるか
- どうすれば内面にフォーカスすることにチームで勇気を持てるか
とかいろいろ考えることはありそう。
スクラムマスターとしてどう振る舞うとよいだろうか
- アクションの ROI はともかくふりかえりをやる
- プロセスの話にしましょう、とファシリテーションする
- チームがプロセスの話ができるように働きかける
- チームがプロセスの話に踏み込めない要因を観察し、環境を整える
とか？いろいろありそう。
