本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。
本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails(以下:RoR)についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。
なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシステムなどその他のシステムであっても、本連載で提案するアプローチが応用できるでしょう。
第1回は、この提案の基となる動機から出発して、プロトタイピングの有益性と、プロトタイピングツールとして見たRoRの優位性を解説します。
[会話1]
顧客 この要望に対しては、どういう機能がベストなのか迷っているんだ。いままでの経験からよきに計らった作りにしてくれると助かるな。
要件担当者 うーん、これまであまり聞かない業務でして……。持ち帰って検討します。
[会話2]
要件担当者 どう? 進んでる?
実装担当者 要件定義書を読んだのですが、項番2-3と8-4と9-2の機能が絡み合っていて、どう実装しようか悩んでいるんです。同じサブシステム内にある機能なら作りやすいのですが……。
[会話3]
PM どうです? 販売管理サブシステムはなんとか予定どおり完成できると思います。
顧客 ……あれ? このオプションを選んだときは操作後にサマリーも更新されるんじゃないの?
[会話4]
要件担当者 ごめん、どうしてもサマリーの更新処理を追加しないといけなくなったんだ。いったんテストをストップして追加実装してくれる?
実装担当者 分かりました。しかしここでサマリーが更新されるとなると、インパクトが大きいですね……。
[会話5]
要件担当者 サマリー更新処理をこの新仕様でバージョンアップする。変更個所を洗い出しておいて。
保守担当者 サマリー更新に関する実装が、ほとんど設計書と一致しません。あとサマリー更新を呼び出す記述がどの設計書にもないんです。
あなたが上流工程の経験を積んでいるなら、経験したことのあるやりとりもあるのではないでしょうか。経験豊富な読者なら、どれもよくある状況だとさえ感じるかもしれません。また、これまで主に設計フェーズ以降にかかわってきた読者であれば、このような上流工程の影響を受けてしまった経験を持っている方も多いはずです。
それぞれの会話が浮き彫りにしている状況を考えてみましょう。
どのように上流工程を進めれば、これらの苦労を軽減できるでしょうか? 要件定義書や設計書を完ぺきになるまで洗練することができるとすれば、問題は解決するかもしれません。しかし、これは現実的ではなさそうです。また、上流工程は、技術的な設計テクニックを磨いたり、ドキュメントツールや設計ツールの腕を磨いただけでうまく進むものではありません。上流工程は、顧客のフィードバックを得ながら、要求を引き出し明確化していくという人間系の作業なのです。
本連載では、「アジャイルな上流工程:プロトタイピングを行うイテレーション」を設けることによりこれらの問題を解決する方法を提案します。
Copyright © ITmedia, Inc. All Rights Reserved.