アジャイル開発にありがちな誤解についてまとめました。
設計書の誤解
アジャイル開発だから設計書は書かない、と思われている方が意外と多いです。
これは大きな誤解で、アジャイルでは単に、「ユーザーが求めているものは設計書ではない」という意味で、設計書を重視していないだけです。
「設計書」が成果物として定義されていない、またはチーム間で合意が取れているのであれば、設計書は必要ありません。
しかし、チーム開発をしているのなら、仕様や設計を「伝える」ことは必須です。アジャイルでは、それが設計書という形式である必要はない、というだけです。
もしソースコードで伝わるのなら問題は無いし、ホワイトボードに書いた手書きの図をどこかに保管しておく程度でも構いません。
最近では社内の壁が全てホワイトボードになっていたりして、視線を移すだけで俯瞰できるようなオフィスもあったりします。
スクラムマスターの誤解
アジャイルのひとつであるスクラムと呼ばれる開発手法がありますが、この中でスクラムマスターというロールが存在します。
チームによってはこのロールが積極的に管理を行っているところを見ますが、それはスクラムマスターの仕事ではないのです。
スクラムマスターは視線を高く持ち、プロジェクトを俯瞰する必要はありますが、それを全面に出してスケジュール管理を行うべきではありません。あくまで、メンバー自身が自律してコントロールを行う必要があります。
スクラムマスターは要求のコントロールとチームの障害を取り除くこと以外にも、優れた「チーム文化」を醸成することに全力を注ぐべきです。
ツールの誤解
「開発の無駄を無くす」ことを主軸において進めます。ツールを導入する事が目的になってはいけません。
もちろん、適したCIやカンバンツールなどのプロジェクト管理ツールを導入することは多くのプロジェクトにとってプラスになりますが、それを最初から強要するべきではないし、より適した方法があるのなら、それに従うべきです。
見積もりの誤解
最初から明確かつズレのない見積もりは不可能であることを認識しておいてください。スクラムではプランニングポーカーなどで話し合って決める選択肢もありますが、開発チームの能力は当然、平準化されているわけではありません。
人によっては概算見積もりの半分の時間で済むこともあるし、倍の時間がかかることもあります。見積もりを正確に出すことよりも、見積もりから逸脱した場合にチームで助け合ってリカバリーできる土壌を培うことに力を注ぐほうが、いくらか健全です。
テストの誤解
アジャイルは、ウォーターフォールのサイクルを速めただけと揶揄されることがあります。
しかし、テストだけは必ず自動化してください。テストをテストとしてタスク分割することは避け、全て製造のスコープで行ってください。
なぜなら、テストを単一のタスクに分割した場合、通常、それはサイクルの最後に回ります。最後に回ったテストで問題が発覚しても、修正する時間がありません。バグは、製造フェーズで全て検出する必要があります。そのためには、テスト駆動開発などが特に有効です。
十分で入念なテストが必要な場合は、別の開発手法を検討することも考慮に入れるべきです。
人数の誤解
アジャイルは、大人数プロジェクトには向いていませんが、それに適用させることはできます。少人数のチームに分割することです。
もっと人数が多くなったら？チームをグルーピングすることもできます。管理は煩雑になりますが、スコープを密に定義することで、少人数チームと比べても遜色ないパフォーマンスを出すことができます。
ただ、当然プロダクトオーナーの負荷は高まります。プロダクト要求を管理するプロダクトオーナーチームを新設したり、チームやチームグループを管理するチームも必要になってくるはずです。
このように、アジャイルは少人数にしか適用できないということはありません。むしろアジャイル自体が「スケールアウト」に向いた開発手法であるとも言えます。
手法の誤解
スクラムには、明確なフレームワークがあります。中でもデイリースクラムなど、これが無いスクラムはスクラムではない、とさえ言われる重要な要素が存在しています。
しかし、それが必ずそのチームに合っているかといえばまったく別の話です。たとえば、リモートワークを主軸としているチームが、ビデオチャットやテキストチャットなどで問題を都度報告しあう文化を持っていれば、デイリースクラムは不要となります。
これがアジャイルの基本理念（目的）から外れているか、といえば実はそうでもなく、これはこれで目的を果たせています。
アジャイルは自由です。チーム文化に合ったやり方にアレンジしたり、時には手法を開発することも考える必要があります。
まとめ
開発手法の選択で迷うこともありますが、アジャイルはよく考えられた開発手法です。そのなかでも色々な選択肢がありますが、メリット、デメリットを正しく認識し、自分のチームに合っていない場合は固執せず柔軟にやり方を変えていくことが重要です。