ウォーターフォールではなく、アジャイルだからこそできたこと
SHIFTの丸山氏はアジャイル開発だからこそのメリットを、現在携わっているプロジェクトを例に話してくれた。そのプロジェクトは、ある会社が長年使用してきた基幹システムの刷新プロジェクトだ。「会社の成長とともに必要になった機能を追加してきたが、データモデルや処理が複雑になり、現在の業務に合わない機能も多くなった。現在となっては無駄な手順も多くなってしまった。メンテナンスもしにくくなっているので刷新したい」という内容で依頼を受けたという。
このプロジェクトに丸山氏が所属するSHIFTはQA（Quality Assurance）担当として参加した。メンバーは職能別にベンダーごとの得意な部分を活かした編成になっており、丸山氏が所属するQA担当のほかにはバックエンド担当、フロントエンド担当、DB担当、インフラ担当、旧システム担当がおり、それぞれ別々のベンダーが担当している。
プロジェクト開始当初はそれぞれの担当を集めた1つのチームで作業が始まり、その後3段階のステップを踏みながら作業が本格化していったという。1ステップ目はツールの選定、環境構築、アジャイル開発をどのように進めるかの検討の時間を使い、2ステップ目は自動テストを導入してバグ検知体制を構築した。3ステップ目を迎え、テストの進め方が分かってきたところで、チームを複数に増やして開発スピードを向上させていったそうだ。
システムは「問い合わせ」や「契約処理」などの業務単位でプロダクトを区切って開発していった。業務単位で完成したらプロダクトを順次リリースしていく形だ。このあたりはシステム全体を一気に完成させるウォーターフォールとは異なるところだ。
スプリントは2週間に設定。とはいえ、2週間でプロダクトをリリースできるわけではない、リリースに必要な機能を少しずつ作っていき、4～12週間かけて完成させてリリースという形を採った。1回のリリースまでに複数回のスプリントを回すことになる。
ここまで説明してきた体制を見ると、アジャイル開発で取り組むことが分かる。丸山氏は基幹システムや大規模システムにアジャイル開発は向いていないという話もよく聞くという。しかし、個人的には「そんなことはない」と思っているそうだ。
例えば丸山氏は「ウォーターフォールで事前に綿密に予定を立てても、実際は予定通り進むことなどない」と実感しているという。今回のプロジェクトでも実際に、開発が始まってから半年がたった頃に基幹システムへの新規の機能追加依頼が経営層からやってきたと実例を挙げる。
もしも今回のプロジェクトでウォーターフォールを採用していたとして、こんな依頼がやってきたら大騒ぎになることは間違いない。「ウォーターフォールで進めていたとしたら、ようやく設計が終わってこれから実装していこうという段階だ。新機能をどうやって実装すれば良いのかをかなり考えなければならない。そして、システム全体の開発期間が延びることになるが、それでも良いのかという問題もある。ウォーターフォールは柔軟性に欠けると言わざるを得ない」
今回のプロジェクトでは、業務単位でプロダクトを区切って、完成次第順次リリースしていく方針を採っていたため、新機能の優先順位を考えて、プロダクト開発のすき間に新機能の開発スケジュールを差し込んで、無理なく対応できたという。丸山氏は「アジャイルなら優先度に応じて開発予定を柔軟に変更できる。どちらが優先なのかを考えられるのがアジャイルの良いところ」と語っている。
アジャイルなら、システムによる効果が早い段階から現れる
もう一つ、丸山氏がアジャイルならではのメリットと考えているのが、新しいシステムによる業務改善効果が早い段階から表れる点だ。ウォーターフォールでは、一度にシステム全体が完成するため、システム完成後は業務に良い効果が大きく表れる。しかし、成果が表れるまでシステム完成を待たなければならない。
今回のプロジェクトなら、業務単位でプロダクトを区切って完成次第順次リリースしていたため、早ければプロジェクト開始2カ月後には少ないながらも業務改善の効果が現れていた。
この違いを、業務に携わる人員の数で考えると、アジャイルには大きなメリットがあると分かる。例えば今回のシステムで言うと、問い合わせ、契約処理、発注処理、納品／出荷処理、支払処理、請求処理、仕入先管理のそれぞれの業務に1カ月当たり2人ずつかかっていた。合計で14人月ということになる。
これが、システム刷新後には仕入先管理に人手が要らなくなり、残りの業務も1カ月当たり1人で済むようになる。最終的には合計で6人月で業務を回せるようになる計算だ。
ウォーターフォールで開発していたとしたら、14人月が12カ月（リリースまで）かかる。追加機能ができるまでの2カ月間は1カ月当たり8人体制。それが過ぎて、1カ月を6人で回せるようになる。14カ月間合計で184人月かかっている。
アジャイルなら、早い段階で小さい結果を出していくので、人員節約の効果が少しずつだが、すぐに出てくる。14カ月間合計で148人月。開発中も36人月節約できるのだ。
とはいえ、アジャイル開発をスムーズに進めるには苦労もあった。チームが常に最高のパフォーマンスを出せるのなら言うことはないが、実際にはチームのパフォーマンスは落ち込むこともある。そこでいかにしてパフォーマンスを向上させるのかを考えなければ、アジャイル開発の成功はあり得ない。
丸山氏のプロジェクトでも、パフォーマンスの上下があるという。例えば、プロジェクト開始当初は1チーム体制で関係者も10人程度だったため、全員の目線がそろいやすく、チームのパフォーマンスにも問題はなかった。この頃は1つだけある開発チーム全体がスプリント（2週間）単位で振り返りの機会を持っていたという。
ところが、開発スピードを上げるために複数チーム体制にして、メンバーを増員したところ、パフォーマンスは良くない方向に向かった。複数の開発チームをすべて集めてスプリント単位で振り返りをしても、開発チームが異なると、メンバーの興味の対象が変わる。結果としてメンバーの時間を無駄に使わせてしまった。
そこで、振り返りは開発チーム単位で実施し、その場では開発に関することを話すようにした。さらに、開発チーム全体での振り返りも従来通り実施したが、ここではメンバー間のコミュニケーションの問題について話し合うことになった。
その後も、「要件定義の段階で振り返りをしても、メンバーによっては課題は特にないということになってしまう。初期フェーズで振り返ってもあまり意味はなかった」という問題が浮上して、開発チーム単位の振り返りをリリース後にするなど、さまざまな形で調節をしていきながら、チームのパフォーマンスを引き出そうとしているという。
丸山氏は「アジャイルソフトウェア開発宣言」の中でも、「よりよい開発方法を見つけだそうとしている」が重要だと感じているそうだ。上記のようなチームのパフォーマンスに応じていろいろ調節することも、より良い開発方法を見つけ出すための活動と言えるだろう。この点について丸山氏は「チームの良くない状態を改善しなければ、良い開発プロセスになることはなく、良い開発プロセスにならなければ、良いプロダクトを作ることもできない」と考えているそうだ。
最後に丸山氏は、大規模システム開発にアジャイル開発は向いていないという声に対して「そんなことはない。大規模システムにこそアジャイル開発の考え方は必要だ」と訴えた。
