はじめに
- 受託アジャイルでは開発規模が大きくなりやすい
- 大規模アジャイルフレームワークと呼ばれているものの紹介（知ってる範囲内で）
- 大規模なアジャイル開発で何を気にしたらいいのかのポイント
大規模アジャイルフレームワーク
LeSS
個人的な認識
- 重厚なルールではなく、なるべくシンプルなルールでスクラムを実現していこうというスタンス。シンプルでわかりやすい印象。
- ルールというよりは、スクラムの解説が多い印象なので、スクラムガイドでは説明しきれてない部分を丁寧に説明してくれている印象。
- スケールの範囲は単一PJとしての大きさのレベル。
- そのPJ特有の進化をしやすく、他のPJ適用を考える際には一から考える部分が多くなりやすい。
SAFe
個人的な認識
- ルールや形式が割とガチガチに決まっている。どうにも情報量が多すぎて、最初に飲み込むのはすごく大変。専用の用語も多い。
- 導入パターンをいくつか用意されており、単一PJでの適用〜経営レベルまでの統合まで含めたスケールが考えられている。
- 会社レベルで導入を考えるのであれば、ある程度のロードマップが用意されているため、考えやすい部分が多い。
- 一方で、最初の導入はルールと現場の実態とのギャップが大きい場面が多く、そういう苦しみはある。
- 形が決まっているので、他のPJ適用もある程度似たような形でスケールできる。
Nexus
- LeSSとSAFeの中間くらいのイメージ。
- ガバナンスを効かすために統合チームを置くような考えを持っているのが特徴。（SAFeでも似たようなLACEというチームがある）
- SAFeほどガチガチにはしたくないが、LeSSよりはガバナンスを効かせたいという要望がある時に使えそう。
どれが良いか
改変要否
どれもそうなんですけど、「改変せずに導入しなさい」って言われています。
が、個人的には改変せざるを得ない場面の方が正直多いように感じます。
改変は必要ですが、安直な改変は反対です。
改変するときは「なぜその仕組みが必要だと言われているのか？仕組みを変えることによる弊害はどのように対処するのか？」をセットで考える必要があります。
そこのサポートにはアジャイルコーチや、該当のフレームワークに応じた研修参加による十分な理解が必要だと思っています。
（WEB情報だけでやろうとするのはやめた方がいい）
どれが良い？
個人的には改変する必要があると思っているタイプです。
なので、どれをベースに考えるか？というレベル感でのどれが良いか、という考えになります。
LeSS
- 初めて単一PJでチームをスケールしていくなら、最初はこれがいい気がする。
- 特別な用語が出て来ないので、スクラムの理解度も合わせて深まるのが一番のメリットだと思っている。
Nexus
- 正直導入したことがないので判別がついてない。
- 感覚としてはLeSSでうまくいかない時に、Nexusがハマるかどうか確かめるのがいい気がしてる。
SAFe
- 徐々にスケールするのではなく、（アンチパターンだけど）最初からある程度の規模でスタートする必要がある場面に適している印象。
- 多少イベントは重いが、コミュニケーション不具合を解消するような標準イベントが丁寧に用意されているため。
- 最終的には経営レベルまでの適用も考えれるので、会社単位でアジャイル化を目指すなら一つの道だと思う。
- 用語がマジでわかりづらいので、イメージしやすいようにPJ固有の名前に変えちゃうのもありだと思う。「リリース トレイン エンジニア」→「チーフ スクラムマスター」とか。
大規模化の検討（個人的な経験則）
徐々にスケールすべし
いきなり3チームも4チームも走らせるのは無理。
できれば1チーム。やっても2チームくらいに止めるのが良い。
スクラム知らない人をそんなにたくさんいっぺんにサポートできない。
ちゃんとスクラムマスターアサインしたとしても、PJとしてどうすべきか？という判断はたくさん生まれます。
単一チームで表出する課題を解消したのちに、複数チームで表出する課題に対応するのが良いです。
両方いっぺんに対処するのはしんどいです。
チームの増やし方
大きく2種類あると思ってる。
完全に新しい人だけで新チームを立ち上げる
- 既存チームの開発範囲と、新チームの開発範囲が完全に分離できる。
- 新チームの立ち上げに多少時間がかかっても良い。
- 既存チームの開発力を落としたくない。
既存チームを分割して、新チームを立ち上げる
- 既存チームの開発範囲と、新チームの開発範囲が被ってしまっている。
- 新チームの立ち上げを早くしたい。
- 一時的に開発力が下がるのは許容できる。
どちらが良いか
理想を言えば「既存チームの開発範囲と新チームの開発範囲が完全に分離できている」のが望ましいので、「完全に新しい人だけで新チームを立ち上げる」。
ただ、開発範囲が被りやすい場合は、既存のお作法などを伝達することを考えると「既存チームを分割する」のが現実的だと思っている。
どちらも一長一短だし、PJに応じて判断だとは思っています。
アンチパターンじゃないのか？
「チームは固定化すべき（要員を入れ替えるべきではない）」という話はあるんですが、それは機能しているチームに限った話だと思っています。
機能していないチームであれば、そもそも「チームごとさよなら」を検討すべき状態だと思っています。
目的はプロダクトないしはPJ目的の達成であって、チームを固定化するのは手段です。
その手段で目的が達成できる見通しが無いのであれば、その手段は変えるべきです。
開発範囲が被っている場面においては、「既存チームを分割する」方が、早く開発力が上がっていく実感があります。
（あくまで個人の観測範囲内なので、全てのケースでそうだとは思って無いですが・・・）
SAFeの導入
今の現場ではSAFeを導入しています。
が、初っ端からSAFeを入れていたわけではなく、最初は素のスクラムから始めています。
SAFeは「PIプランニング」と呼ばれる３ヶ月分の計画から始まる「大きなサイクル」と、「スプリントプランニング」と呼ばれる1〜2週間分の計画から始まる「小さなサイクル」の２種類のサイクルを同時に回すスタイルでやります。
スクラムのサイクルがわからない人に3ヶ月分の計画をさせるのは無理だなと感じたので、最初の3ヶ月はPIプランニングなしで、素のスクラムを回しました。
今ではもうSAFeのプロセスにも慣れて、安定してイベントを回せるようになってきています。
SAFeはあくまで例だと思っていますが、開発メンバーの学習段階をちゃんとデザインする必要があると考えています。
まとめ
アンチパターンは踏み抜くもの
他でもいいましたが、受託アジャイルをするのであればアンチパターンは必ず踏みます。なるべく避けるべきですが、踏まざる得ないものは、周りの理解を得た上で対策を立てた上で踏み抜いていきましょう。
地雷原の先にしか受託アジャイルの未来はないです。
後続の受託アジャイルが少しでもやりやすくなるように、地雷を踏み荒らしていくのだ！という気持ちで進みましょう。
次回予告
そういえば触れてなかった見積もりの話をします。