スウォーミングとは何か

スウォーミング (Swarming) とは，無数の虫が何かの場所や標的に群がって何かを行うことであり，ソフトウェア開発の文脈では，一つのタスクや開発トピックにチームの全員 (全員ではなくても，多人数) で取り組むことを指します．
最近しばしば話題に上がるモブ・プログラミングも概念としてはスウォーミングのひとつといえますが，もっと幅広く，ひとつのユーザーストーリーにチーム全体で取り組むことがスウォーミングという言葉がソフトウェアの文脈で一般的に指す活動です．

ソフトウェア開発チームは，一度のタイムボックス (スクラムに習って スプリント と呼びます) で複数のユーザーストーリー (例えば 注文の一覧を表示する というユーザーストーリーと，1つの注文の詳細情報を表示する というユーザーストーリー) に取り組むかと思います．
1つのユーザーストーリーを実現するためには複数のタスクをブレイクダウンできるでしょう．(例えば 注文の一覧を表示する というストーリーなら， デザインの決定, 一覧として表示する注文の定義の確定, プロダクトコードの実装, 単体テストの実装, 手動テスト とか) スウォーミングでは，これらのタスクをチーム全員で取り組みます．このときに重要なのが，チームが並行して複数のユーザーストーリーのタスクに取り組むのではなく，一度に (できるだけ) ただひとつのユーザーストーリーのタスクのみに取り組みます．

例えば 注文の一覧を表示する というユーザーストーリーの実現に取り組み始めたら，理想的にはチームの誰ひとりとしてその他のストーリーには取り組みません．まずチーム全員で デザインの決定 をする中で実装の詳細なポイントについてチーム全員で理解した後，プロダクトコードの実装 を行ったり，テスト実装が得意なメンバーがテスト駆動開発に疎い開発メンバーと一緒に テストコードの実装 を行ったり，仕様に詳しいメンバーが 手動テスト のテスト観点を洗い出したりテストを実施したりします．

なぜスウォーミングをするのか

「一度に複数のストーリーを並行して開発したほうが効率がいいんじゃないの？」と思う気持ちになる人がいて当然だと思うし，その人達にとって「スウォーミングだなんて効率が悪そう！」と思うのも無理はないでしょう．では，なぜスウォーミングをするのでしょうか．

完成までのリードタイムの短縮

チームが1スプリントに完成させるべきユーザーストーリーが3つあって，その3つをチームメンバーの間で分担して並行して取り組み，全てスプリントの最後に完成させるとなると，それぞれのユーザーストーリーのリードタイムは1スプリントの最初から最後までとなってしまいます．
どのようなプロダクトに取り組んでいるかにもよりますが，リードタイムを短くして，機能の一部でも素早く価値を実現させるステージまで持っていく (リリースをしたり，顧客の目に見えるところに持っていくなど) ことで，チームがプロダクトやプロダクトの取り組む問題について高速に学習することが出来るようになります．そのため，まずひとつのユーザーストーリーを全力で実現して，プロダクトのフィードバックを得ることがスウォーミングをする大きなモチベーションです．

手戻りの改善

作業を工程に分けることで，認識や想定の違いや，ある工程での設計上想定していなかったことが見つかったりすることで，手戻りが発生します．手戻りが発生すると，その分機能開発が完了するまでのリードタイムが長くなります．

例えば，最初の1週間をサーバーの API 開発に使い，次の1週間にウェブフロントの開発を行うとします．ウェブフロントの開発をする中で想定していなかった例外ケースに出くわしたり，API に項目の追加が必要になったりすることで，すでに完成したはずの最初の1週間の API 開発の大部分を見直す必要に出くわした経験のある人は多いでしょう．

このような手戻りに遭遇すると，「手戻りが発生しないように設計をしっかり行ってドキュメントを充実させよう」と考えることも出来なくはないですが，結局リードタイムを長引かせてしまうので，あまり良い策とはいえないでしょう．逆に，このような想定外が生じることを想定し，手戻りが起きてもダメージが少なく，リードタイムも伸ばさないように，チーム全員でひとつのユーザーストーリーに取り組み，ひとつのユーザーストーリーの粒度を大きくなりすぎないようにすることが重要になります．

知識移転の促進

チームでのソフトウェア開発を計画する上で，「この仕事は〇〇さんしかできない」というたぐいのものがあると思います．「ネットワークはあの人しかできない」などという制限がチームの開発の流れをよくすることを阻害します．知られた言葉をつかうなら「ボトルネック」というやつです．

技術的に限られたメンバーしか持っていないということにチームが自覚的であるならまだ良いのですが，それがいつしか「このタスクはこの人がやるもの」と前提にすらなってしまうことすらあるでしょう．その制限を意識的に崩すのがスウォーミングです．共同作業をすることでメンバー間での知識移転を促進し，知識やスキルのボトルネックを除くことが，スウォーミングを上手くやることで可能になります．