はじめに
ちゃろー☆
medibaにおける数多のシステムを設計した産みの親で、テックリードの菅原です。
この記事は、mediba Advent Calendar 2025の２日目にエントリーしています。
元々はこの日のために大作ポエムを書いていましたが、完成させてから時間が経つほど恥ずかしくなってきたので、それは下書きのまま封印して、テックリードっぽい記事を急遽拵えて投稿しました。
さて、短納期のプロジェクトにアサインされる――エンジニアの皆さんであれば、メンバー、リーダーの役割を問わず、一度はどこかで経験したことがあるのではないでしょうか（あれ？もしかして無いんですか？そういう人は、己の環境と幸運に感謝しましょう）。
そういった状況に置かれることが多かった私は、精神的と体力的の両面で辛すぎる地獄から生き残るために、どのようにチームづくりをしていくべきなのか。そして、チームメンバー、リーダー、お客様が三方良しの「Triple-Win」な関係になるためには、プロジェクトをどのように遂行するのが良いのか。それらを何とかできる解決策を常日頃考えていました。
そして、数多の経験と犠牲を伴う実践を繰り返すことで、答えを得たのです。
内容については、完全な一般化がされているわけでもなく、確実な再現性があるわけでもないことを予めご了承の上、ご覧ください。
課題
答えの前にまずは、10名程度の中規模チーム（リーダー１名、テックリード１名、メンバー８名の構成）で、短納期＋スクラム開発＋モブワークを行った時に発見・抽出した課題を３つほど列挙します。
タスクを圧迫するレビュー
チーム内では相互レビューを必須にしていました。そのため、各々のメンバーが熟すべきタスクに加えて、他のメンバーが作成したプルリクエストやイシューがマージ、または、クローズされるまで、随時レビューしなければいけません。
これはチームメンバーが多くなればなるほど、一人当たりのレビューコストが線形的に増大することを意味します。
この事実は単純明快で至極当たり前のことですが、一つのスプリント当たりに処理できるメンバーのタスク量が圧迫されたことに加え、レビュー待ちのままタスクを完了できずに次以降のスプリントに持ち越す状態が慢性化しました。その結果としてベロシティの指標が悪化し、チームの生産性低下が露呈しました。
なお、レビューを一切しないという狂気の選択肢や、レビューを誰かに押し付ける選択肢、レビューを全てAIに任せるという不安定な選択肢は、中長期に渡って保守性と生産性を維持する観点から早々に除外しました。
リンゲルマン効果の発生
チームメンバーが多いことで「リンゲルマン効果」が発生しました。リンゲルマン効果とは、グループや集団の中で共同作業する人数が増えるほど、それに所属する各個人の生産性や貢献度が小さくなる現象を言います。
これを具体的に言い換えると、「自分は手を抜いて他人に頑張ってもらおう」と画策するフリーライダーや、「頑張っても評価されないのでやらない」と考えるモチベーションを喪失した人たちを発生させる現象です。
事例としては綱引きが挙げられますが、チーム開発においては、各個人のタスク量の減少やレビューの遅延といった形で顕在化します。他にも、モブワークにおいては、よく喋る人に任せて、意見を発信せずにただ黙って参加しているだけの人になりがちです（注：エンジニアの気質から考えると、社交性が低いだけという可能性もあります）。
チームの習熟度が低く、文化形成が進んでいなかった頃には、この現象に悩まされることが多かったです。
費用対効果の低いスクラム開発
持て囃されがちなアジャイル開発（スクラム開発）ですが、費用対効果が低くなりやすい開発手法である、と経験則から考えています。
スクラム開発は、デイリー、リファインメント、スプリントレビュー、レトロスペクティブ、プランニングとイベント尽くしであり、中規模チームでこれらを開催した場合に必要な時間をざっくり合計すると、１日程度は見込まれます。
したがって、１週間でスプリントを回すと、メンバーが確保できる作業時間は不足し、「何の成果も得られませんでした」という結果になりかねず、これは納期が短くなるほど致命的です。加えて、ドメイン知識のないメンバーを追加した場合、ジョインしてから１週間以内で成果を出せる状態にするのは難しいです。
１週間スプリントで回していた最初期は、メンバーから作業時間の少なさに対して苦情が出ていましたし、各個人の能力差が顕著になりやすく、前述のリンゲルマン効果を加速させていたようでした。
課題への解答とその強み
さて、前述したそれぞれの課題は、メンバーの人数が多い、という原因が共通しています。
そして、このことから「人海戦術で乗り切ろうと考えることが間違いである」という証明ができます。なぜなら、人海戦術を有効に機能させるためには、それが各個人の能力に依存しない単純で画一的なものでなければいけません。特にシステム開発においては、各メンバーに割り当てるタスクがそのような性質を持ちにくいため、大抵の場合は有効に機能しないということになります。
したがって、共通の原因を考慮した適切な解答は、「小規模チーム（５名前後）、または、中規模チームを２つの小規模チームに分ける」です。
以降で、小規模チームにする主なメリットを２つ述べていきます。
各種コストの削減効果
レビューやスクラム開発イベントの総コスト量が低くなり、もともと圧迫されていた分を、各メンバーのタスクの作業時間へ割り当てられるようになりました。
結果的に、各メンバーがスプリント当たりに熟せるタスクの総ストーリーポイントがおよそ２倍に増え、ベロシティも大幅に改善しました。
責任感とモチベーションの獲得
各メンバーが行ったタスクの成果を、他のメンバーがしっかりと認知・認識できる精神的な余裕が生まれ、責任感を持って作業をしてもらえる状況を作れました。
これによって、フリーライダーを防止しつつ、さらに減衰しにくいモチベーションを獲得でき、リンゲルマン効果を抑止することが簡単になりました。
おわりに
なお、小規模チームは、どんな課題でも解決できる「銀の弾丸」ではありません。
短納期で確実に生き残るための焼き畑農業的な手法であるため、組織的な成長（スキル不足なエンジニアを育成する、開発チームの文化を醸成する等）という観点では明確にデメリットになります。短期的な戦術としてスポットで実施するのは有効ですが、中長期的な戦略として継続して行うのは不適切ですので、用法容量には細心の注意を払ってください。
別件になりますが、弊社medibaでは一緒に働いてもらえるエンジニアを募集しています。
この記事を見て、一緒に働いてみたい等、興味を少しでも持ってもらえたなら、カジュアル面談から参加できるようになっているので、是非とも気軽に申し込みくださいませ。