大規模アジャイル手法を鳥の目で眺める

これは、豆蔵デベロッパーサイトアドベントカレンダー2022第14日目の記事です。

アドベントカレンダーという、いわば「お祭り」で何を書こうかとつらつら考えてみました。お祭りらしくデカくいこうと思い、またちょうど同じようなタイミングで同じテーマで講演したこともあり、「大規模アジャイル」としてみました。
とはいえ私は特定の手法の認定講師というわけでもなく、必要に迫られて書籍やWebで勉強したり、こそっと研修を受講しに行ったりしている程度で、ひとつの手法をよくご存じの方は他にもたくさんいます。そのため、私は「鳥の目」で複数の手法を眺めてみたいと思います。

大規模アジャイルというと、昔からアジャイルに携わっている人には一種の忌避反応があります。普通のアジャイル開発もまともにやったことがないのに、大規模とかフザケンナ、というヤツで、私も基本的にはこれに賛同します。

とはいえ ”あの” PMIの調査結果でさえ、アジャイル経験者が半分を超えた現在、知識とスキルを切り売りしているコンサルとしては、「大規模？ 知りませーん」というわけにもいきません。難しいと思うなら、一体何が難しいのか、ちゃんと説明できるべきでしょう。というわけで、知ったかぶりをしつつ解説してみます。

次にこれを片付けておきましょう。通常、大規模アジャイルと言う時の大規模とは「開発に一度に携わるメンバーの人数が多いこと」を指します。小さいチームでも長く続ければ総工数は多くなりますが、これを一般的には大規模とは言いません。通常のアジャイル開発以上に、一度に多くの開発メンバーが関わることを指します。

では、なぜ大規模にしなければならないか。これも大抵は答えが決まっており、「ビジネス上の必要性からどうしても短期間でプロダクトをリリースする必要があるから」です。

ここでちょっと注意していただきたいのは、こういう大規模化を安易に考えてはいけないということです。ビジネス上の必要性があることは理解します。ただ、納期を短くすると、思った以上に工数が増えることは覚悟してください（つまりめっちゃお金がかかります）。書籍「ソフトウェア見積り」内にある調査結果では、スケジュールを10％短縮しようとすると工数は50％増えるそうです。そこまでお金をかけてでも早くリリースしないといけないんだ、という時でない限り「小さいチームで細く長く開発をする」ほうが、本来はお得です。途中で小さくリリースすることでユーザーの反応を見て、無駄な機能を作らずにすむという、本来のアジャイル開発のメリットも出ます。

「わかった、金は出す」という方に限って、以下を読んでください。

なかなか本題の話にならず、イラっとしている人がいると思いますが、もうちょっと我慢してください。そもそもアジャイル開発ってどんな特徴があるんだっけ、ということを、まとめてみました。

• 反復型・適応型
  • 開発工程のすべてを小さい機能単位で繰り返し行い、頻繁にリリースする
  • 開発するもの（プロダクト）に対する頻繁なフィードバック
  • 開発の進め方（プロセス）に対する頻繫なフィードバック
• 顧客（企画）側との継続的な協調
  • 顧客は開発期間中、継続して開発者と対話する
  • ニーズの変化に俊敏に対応できる半面、顧客（企画）側の必要工数は増える
• 人（チーム）中心
  • 開発をするのが、感情をもった人であることを否定しない（むしろ利用する）
  • チーム内の暗黙知に委ねることで、文書化は効率化する
  • 役割（ロール）で厳密な責任分担を区切らず、多能工化を促す
• プラクティス（実践手法）の組み合わせ
  • どの手法を採用するか、どういう運用をするかも、開発期間中に改善していく
  • 文書／成果物やタスクによる、組織的な標準化はしづらい

特にこの中の「感情」の話は、あまり他に強調する人がいないのですが、私は強く感じています。
そして、これが大規模にする時のネックにもなります。

この後いくつかの手法をご紹介しますが、すべての手法には共通点があります。
それは、ひとつのチームを大きくするのではなく、小さいチームを複数作ることです。
これはまあ理解できますよね。アジャイル開発の俊敏性を保つために、基本のチームは小さいまま、そういうチームをたくさん作りましょう、という考え方です。これによって、チーム内は今までの基本のアジャイル開発の手法を使い、さてポイントは、チーム間の連携ということになります。

私は、大規模アジャイル手法にはその方向性に違いがあると思っていて、ざっくりとこんな図で説明しています。

青の楕円が「縦に伸びるアジャイル」で、SAFeやScrum@Scaleが該当します。組織としてアジャイル手法を活用しつつ、上（経営層）と下（現場チーム）がいかに整合性を保って動けるかを志向している手法。さらに、両者の違いを加えるのであれば、SAFeはトップダウン、Scrum@Scaleはボトムアップの印象があります。

赤の楕円が「横に広がるアジャイル」で、LeSSやNexusです。横のチーム間の連携にフォーカスしています。Nexusのほうが統合チームが存在しており、やや階層的なイメージです。

とてもざっくりした説明で、各手法のプロフェッショナルなみなさまにおかれましては、それだけじゃないぞと言いたくなる方が多いでしょうが、そこは「鳥の目」ということでご容赦ください。

これだけ手法もある中で、一体何が難しいかというと、以下2点かなと思っています。

• 複数チーム間の連携
  • 各手法がフォーカスしている点ではあるが、どれも簡単ではない
  • 特に暗黙知に頼ることで文書化の工数を減らしているアジャイル開発では、それだけでは済まない部分の工数増加が目立つことになる
• ビジョン・ゴールの共有
  • ゴールを全員で共有することで自律性を促すアジャイル開発だが、人数が増えるとどうしてもそのゴールに「関与している感」は薄れがち
  • ビジョンやゴールは作る過程で共有が進むが、人数が増えるほどその過程に全員が関わるのが難しくなり「我がこと」にできない

特に後者が、先に述べた「感情」の話に関わっています。元々のアジャイル開発は、「やりたいことがある人」と「それを実現する人」をできるだけ近づけようとしている仕組みです。ユーザーの近くに開発者がいることで、自らが作り出したものが世の中に与える影響を目の当たりにし、それがモチベーションになって「やってやるぜ」と次につながることで好循環が生まれます。人間、なんだかんだ言っても感情の生き物で、論理でのみ動くわけではありません。ロジカルにものを考えるのが当たり前のIT業界だからこそ見過ごされがちなことかなと思っています。

これはアジャイル開発のよさを生かしつつ、大規模化する時の大きな壁になると思います。結局はウォーターフォール開発だろうと、アジャイル開発だろうと、組織運営だろうと、大きければ難しくなるのです。

じゃあどうする？ ということになりますが、それを何とかしようとしているのが、大規模アジャイルの各手法だと思っています。それぞれに「できるだけ全員が全員と対話する」ための仕組みがあります。ものすごく工数がかかる仕組みですが、それがその手法の重要なコアになっています（例えば、SAFeのPI Plannning）。工数がかかっても、ここで時間を惜しんではいけません。

これをやればOKという決定的な解決策はありません。さらに言えば、ひとつの手法を選べばそれで終わりではなく、複数の手法を組み合わせたり、ある手法を基本にしながら他の手法のプラクティスを取り入れたりする必要があると思います。
さらに単一チームでやっているのと同様に、組織全体で「採用している手法の継続的改善」を行う必要があります。単一チームの場合に比較して大きなフィードバックサイクルにならざるを得ませんが、これを月／年単位で時間をかけて行う必要があります。

結論をまとめるならば、

• 大規模アジャイルはそもそも難しいということを理解すること
• 取り組むならば年単位の試行錯誤を覚悟すること
• 普通のアジャイルチームもないうちから大規模とか言うなコラ

です。

みなさま、よい年末年始を（とか言いつつ、まだまだ仕事はしますが）。