アジャイル開発は一般的に10人以下のチームが推奨されています。
なぜでしょう。
実際に20人以上のチームでアジャイルを行った失敗経験をお話します。
共通認識がたいへんになる
アジャイルではドキュメントの作成をなるべく抑え、コミュニケーションで開発を進めていきます。
（もちろん、必要ならドキュメントは作成します。）
10人を超える人たちとコミュニケーションをとって、方針や仕様を共通認識するのはとても大変です。
Aさん、Bさんとは会話して共通認識にできたけど、Cさんには話ができていない。
Dさんには話をするのを忘れてた。
なんてことが起きやすくなります。
うちあわせが増える
Cさん、Dさんに伝え漏れをなくすために、打ち合わせで一斉に伝達することを考えるでしょう。
すると、Aさんから伝えたいこと、Bさんから伝えたいこと・・・・
人数が増えるほど、打ち合わせの回数や、打ち合わせ時間が長くなります。
これはウォーターフォール開発でも同じでは？
と思うかもしれません。
アジャイル開発の特徴として、組織がピラミッド構造になっておらず、全員横並びの組織構成なのです。
唯一PO（プロダクトオーナー）が上に立っていますが、開発者は横並びで、各要因がマルチプレイヤーとして活躍するのです。
チームをピラミッド構造にすると？
打ち合わせなどを効率化するために、チームを細分化して、リーダーを設置して、ピラミッド構造で仕様決定や伝達を行うとどうでしょうか？
伝言ゲームを行うと、伝達漏れや誤認が起きやすくなります。
それなら、ドキュメントで伝えようと考えるかもしれません。
ドキュメントを作る時間が必要になります。
せっかく、スピードを重視するアジャイルの良さが失われます。
また、ピラミッド構造という事は意思決定は頂点まで上げて承認を取る必要があります。
正しく説明をして、承認を得るためには、詳細なドキュメント（設計書）を書くことになってしまいます。
いつの間にかウォーターフォール開発みたいになってますね。
チームが疲弊する
表面的にはアジャイルの体裁をとって、短期リリースを行います。
しかし、内部ではウォーターフォールのようなプロセスになっています。
短期間でウォーターフォールを回すような事態になります。
成果物の割に、プロセス（作業量）が大きくなり、だんだんチームメンバーが疲弊していくのです。
コメント