現代のアジャイル開発と人数の考え方

仰々しいタイトルをつけたけど、普段EMとして「採用人数を増やすための短期的な動き」ばかりが先行し、中長期的な戦略が立てられないことにモヤモヤしていた。

しかし最近、「中長期を見据えなくてもいいのかもしれない」と思える考え方に辿り着いたので、その思考を忘れないためのメモ。

EMとして採用に関わっていると、目標数値や採用戦略に「明確な根拠」が欲しくなる。しかし、「その人数にはどういう裏打ちがあるのか？」という問いに対し、自分の中でずっとしっくりくる答えが出せず悩んでいた。

「いつまでに何人採用する」への違和感

採用人数の算出方法としてシンプルな方法の一つに、各チームのロードマップから逆算するパターンがあると思う。「このプロジェクトを完遂するには、これだけの人数が必要だ」という考え方。

自分はこれに違和感があった。理由は主に二つある。

ロードマップの不変性への疑問: 1年後の目標人数を今決めても、その前提となるロードマップが1年後も変わっていない保証はない。というか、ほとんどの場合で変わっている。
アジャイルとの相性の悪さ: 常に不確実性と向き合うプロダクト開発において、ロードマップは変化し続けるのが前提。その前提に立つと、1年後の予測に基づいて人数を決めること自体、アジャイルな考え方と矛盾しているような感じがする。

「1年後のために今決めても、その時何をやっているか分からないのではないか？」という疑問がずっとあった。

「終わりを目指す開発」と「終わらせないための開発」

この違和感を解くヒントになったのが、『エンジニアリング組織論への招待』に出てくる「終わりを目指す開発」と「終わらせないための開発」という言葉だ。

アジャイルという言葉も、時代背景によって意味合いが異なると考えている。アジャイルが提唱された当初は受託開発がメイン（少なくとも現代のようなSaaS形態は主流ではなかったはず）であり、ゴール（終わり）を目指す開発が一般的だった。ゴールへ向けて不確実性を下げていくプロセスなら、開発が進むにつれて必要な人数の目処も立てやすい。

一方で、現代のSaaSのような「終わらせないための開発（ビジネスを継続するための開発）」は性質が異なる。タスク単位の不確実性は減らせても、年単位のロードマップレベルの不確実性はなかなか減らない。1年後も同じ方向を見ているか分からない以上、長期的に見て「一概に何人が必要か」を定義することは本質的に難しい。

採用と開発の「期間のギャップ」

もう一つ難しい要因に、採用から戦力化までのタイムラグがあると考えてる。

1年後を見据えて逆算しても、入社した人が戦力として機能し始めるのは3ヶ月〜半年後。
ようやく戦力になった頃にはビジネスの状況が変わり、必要な人数もスキルセットも変わっている可能性がある。

採用における「中長期的な動き」

EMになりたての頃は、「短期的な補填ばかりではなく、もっと中長期的な動きをしなければ」と焦っていた。単発で終わらない、意味のある戦略を立てたいと悶々としていた。そこで視点を変え、「本当に短期的な動きを繰り返すことはダメなのか？」と考えてみた。

スループットで考える

ロードマップからの逆算がしっくりこないなら、何が人数を決めるのか。AIを相手にとりあえず壁打ちをしてたら「スループット」というワードが出てきた。

かつての開発が「終わらせるために何人必要か」だったのに対し、現代は「継続させるために何人必要か」が焦点になる。ビジネスを継続・成長させるには、リリースし続けることが不可欠であり、そのためには一定の「開発スループット」が必要になる。

この視点に立つと、採用の目的は「1年後に○人にする」ではなく、「スループットを維持できる人数を常に満たし続ける」ことになる。退職や異動で人が減ればすぐに補充し、プロダクトの成長に合わせて徐々に増やす。結果として、採用活動は「中長期の計画に基づく一括採用」ではなく、「短期的な調整の積み重ね」になる。

そう考えれば、短期的な採用活動が中心になることも、むしろ理にかなっている。中長期的な「点」の予測ではなく、常に最適な「流量」を維持し続けるという考え方がすごくしっくり来た。

最後に

もちろんこれが唯一の答えだとは思っていなくて、「ビジネス成長に必要なスループットとは具体的にどれくらいか」「昔の受託は本当に予測しやすかったのか」とか、ツッコミどころは自分でも多々あると思う。

ただ、考え方の大筋として自分の中では一旦落ち着くことができたので、今後はこの視点をベースに、考え方をブラッシュアップしていきたい。