アジャイルなら、システムによる効果が早い段階から現れる
もう一つ、丸山氏がアジャイルならではのメリットと考えているのが、新しいシステムによる業務改善効果が早い段階から表れる点だ。ウォーターフォールでは、一度にシステム全体が完成するため、システム完成後は業務に良い効果が大きく表れる。しかし、成果が表れるまでシステム完成を待たなければならない。
今回のプロジェクトなら、業務単位でプロダクトを区切って完成次第順次リリースしていたため、早ければプロジェクト開始2カ月後には少ないながらも業務改善の効果が現れていた。
この違いを、業務に携わる人員の数で考えると、アジャイルには大きなメリットがあると分かる。例えば今回のシステムで言うと、問い合わせ、契約処理、発注処理、納品／出荷処理、支払処理、請求処理、仕入先管理のそれぞれの業務に1カ月当たり2人ずつかかっていた。合計で14人月ということになる。
これが、システム刷新後には仕入先管理に人手が要らなくなり、残りの業務も1カ月当たり1人で済むようになる。最終的には合計で6人月で業務を回せるようになる計算だ。
ウォーターフォールで開発していたとしたら、14人月が12カ月（リリースまで）かかる。追加機能ができるまでの2カ月間は1カ月当たり8人体制。それが過ぎて、1カ月を6人で回せるようになる。14カ月間合計で184人月かかっている。
アジャイルなら、早い段階で小さい結果を出していくので、人員節約の効果が少しずつだが、すぐに出てくる。14カ月間合計で148人月。開発中も36人月節約できるのだ。
とはいえ、アジャイル開発をスムーズに進めるには苦労もあった。チームが常に最高のパフォーマンスを出せるのなら言うことはないが、実際にはチームのパフォーマンスは落ち込むこともある。そこでいかにしてパフォーマンスを向上させるのかを考えなければ、アジャイル開発の成功はあり得ない。
丸山氏のプロジェクトでも、パフォーマンスの上下があるという。例えば、プロジェクト開始当初は1チーム体制で関係者も10人程度だったため、全員の目線がそろいやすく、チームのパフォーマンスにも問題はなかった。この頃は1つだけある開発チーム全体がスプリント（2週間）単位で振り返りの機会を持っていたという。
ところが、開発スピードを上げるために複数チーム体制にして、メンバーを増員したところ、パフォーマンスは良くない方向に向かった。複数の開発チームをすべて集めてスプリント単位で振り返りをしても、開発チームが異なると、メンバーの興味の対象が変わる。結果としてメンバーの時間を無駄に使わせてしまった。
そこで、振り返りは開発チーム単位で実施し、その場では開発に関することを話すようにした。さらに、開発チーム全体での振り返りも従来通り実施したが、ここではメンバー間のコミュニケーションの問題について話し合うことになった。
その後も、「要件定義の段階で振り返りをしても、メンバーによっては課題は特にないということになってしまう。初期フェーズで振り返ってもあまり意味はなかった」という問題が浮上して、開発チーム単位の振り返りをリリース後にするなど、さまざまな形で調節をしていきながら、チームのパフォーマンスを引き出そうとしているという。
丸山氏は「アジャイルソフトウェア開発宣言」の中でも、「よりよい開発方法を見つけだそうとしている」が重要だと感じているそうだ。上記のようなチームのパフォーマンスに応じていろいろ調節することも、より良い開発方法を見つけ出すための活動と言えるだろう。この点について丸山氏は「チームの良くない状態を改善しなければ、良い開発プロセスになることはなく、良い開発プロセスにならなければ、良いプロダクトを作ることもできない」と考えているそうだ。
最後に丸山氏は、大規模システム開発にアジャイル開発は向いていないという声に対して「そんなことはない。大規模システムにこそアジャイル開発の考え方は必要だ」と訴えた。
