書籍『誰も教えてくれなかったアジャイル開発』（日経BP）では、ウオーターフォール型開発が主流の「日本企業」で試行錯誤しながらアジャイル開発を成功に導いてきたコンサルタントたちが、自らの経験を体系化している。本書から抜粋し、初回リリースの進め方のコツを解説する。（技術プロダクツユニットクロスメディア編集部）
ポイント（5） 初回リリースは半年以内に
本書『誰も教えてくれなかったアジャイル開発』の基礎編の第3章では、「利用頻度の高い最小限の機能」に限定して初回リリース（最初のイテレーションのリリースではなく、最初の本稼働）することをお勧めした。初期計画の工程では、初回リリースに向けて、イテレーションごとに実装するPBI（プロダクト・バックログ・アイテム）を積み上げて初回リリースの対象となるPBIを定義していく。
初期計画の工程で、いつからいつのイテレーションでどのPBIを実装し、最終的にいつリリース（本稼働）させるかを「リリース計画」として作成する際、第一に優先すべきはユーザー部門の業務イベントである。必要なユーザーストーリーを積み上げた結果として、意味のある単位で構成してリリースするタイミングを定めることも重要であるが、まずはエンドユーザーに利用してもらうために、棚卸しや年度会計処理といった業務イベントに合わせてリリースのタイミングを検討したい。
そのうえで、特に間に合わせるべき業務イベントがない場合は、最大6カ月を目安に初回リリースできるように調整するとよい。実際にリリース計画を立てる際には、社内システムならではのリリース準備や手続きも必要な場合があるため、リリースの頻度をあまり多くできない。
6カ月超ならリリース分割を
一方で初回リリースまでの期間が6カ月を超えるようだと、リリースによる業務変更の度合いが大きいだけでなく、初回リリースにおけるタスクの複雑さが増す。アジャイル開発に期待されるスピード感なども考慮すると、6カ月程度の単位に収まるようにリリースタイミングを分割したい。
エンドユーザーにとっても、1年後の業務がどうなっているか想像することは難しくても、6カ月先ならばある程度の想像がつきやすいだろう。短期でのリリースを計画することで、エンドユーザーの日常業務の変更も吸収していける。
エンドユーザーの要望は日々進化していく。加えてユーザー部門代表者自らが挙げた要望であっても、実際の操作画面を見ると「伝えたかったものと違う」などとして変化するものだ。
チームが機能の実現方法のみに焦点を当てて議論を進めた場合は、実際にエンドユーザーがやりたかったこととずれていることもある。リリースせずに机上で検討していては、ユーザー部門代表者の要望とのギャップが埋まらないだけでなく、すれ違いが大きくなってしまう。「Fail Fast」という言葉があるように、少しでも早くエンドユーザーに実物を見せてフィードバックをもらうことで、アジャイル開発のメリットを引き出したい。
リリース計画を検討する際に注意すべき点は、「業務が上流から下流まで、確かに流れる」と、改めてチェックすることだ。ポイント（3）で解説したユーザー・ストーリー・マップで検討するとよいだろう。
