ウォーターフォールではなく、アジャイルだからこそできたこと
SHIFTの丸山氏はアジャイル開発だからこそのメリットを、現在携わっているプロジェクトを例に話してくれた。そのプロジェクトは、ある会社が長年使用してきた基幹システムの刷新プロジェクトだ。「会社の成長とともに必要になった機能を追加してきたが、データモデルや処理が複雑になり、現在の業務に合わない機能も多くなった。現在となっては無駄な手順も多くなってしまった。メンテナンスもしにくくなっているので刷新したい」という内容で依頼を受けたという。
このプロジェクトに丸山氏が所属するSHIFTはQA（Quality Assurance）担当として参加した。メンバーは職能別にベンダーごとの得意な部分を活かした編成になっており、丸山氏が所属するQA担当のほかにはバックエンド担当、フロントエンド担当、DB担当、インフラ担当、旧システム担当がおり、それぞれ別々のベンダーが担当している。
プロジェクト開始当初はそれぞれの担当を集めた1つのチームで作業が始まり、その後3段階のステップを踏みながら作業が本格化していったという。1ステップ目はツールの選定、環境構築、アジャイル開発をどのように進めるかの検討の時間を使い、2ステップ目は自動テストを導入してバグ検知体制を構築した。3ステップ目を迎え、テストの進め方が分かってきたところで、チームを複数に増やして開発スピードを向上させていったそうだ。
システムは「問い合わせ」や「契約処理」などの業務単位でプロダクトを区切って開発していった。業務単位で完成したらプロダクトを順次リリースしていく形だ。このあたりはシステム全体を一気に完成させるウォーターフォールとは異なるところだ。
スプリントは2週間に設定。とはいえ、2週間でプロダクトをリリースできるわけではない、リリースに必要な機能を少しずつ作っていき、4～12週間かけて完成させてリリースという形を採った。1回のリリースまでに複数回のスプリントを回すことになる。
ここまで説明してきた体制を見ると、アジャイル開発で取り組むことが分かる。丸山氏は基幹システムや大規模システムにアジャイル開発は向いていないという話もよく聞くという。しかし、個人的には「そんなことはない」と思っているそうだ。
例えば丸山氏は「ウォーターフォールで事前に綿密に予定を立てても、実際は予定通り進むことなどない」と実感しているという。今回のプロジェクトでも実際に、開発が始まってから半年がたった頃に基幹システムへの新規の機能追加依頼が経営層からやってきたと実例を挙げる。
もしも今回のプロジェクトでウォーターフォールを採用していたとして、こんな依頼がやってきたら大騒ぎになることは間違いない。「ウォーターフォールで進めていたとしたら、ようやく設計が終わってこれから実装していこうという段階だ。新機能をどうやって実装すれば良いのかをかなり考えなければならない。そして、システム全体の開発期間が延びることになるが、それでも良いのかという問題もある。ウォーターフォールは柔軟性に欠けると言わざるを得ない」
今回のプロジェクトでは、業務単位でプロダクトを区切って、完成次第順次リリースしていく方針を採っていたため、新機能の優先順位を考えて、プロダクト開発のすき間に新機能の開発スケジュールを差し込んで、無理なく対応できたという。丸山氏は「アジャイルなら優先度に応じて開発予定を柔軟に変更できる。どちらが優先なのかを考えられるのがアジャイルの良いところ」と語っている。
