アジャイルプロトタイピングで上流工程が変わる：Rubyでアジャイルプロトタイピング（1）（1/3 ページ）

[鍜治舍浩, 西川仁, 林秀，永和システムマネジメント/永和システムマネジメント/アークピア]

想定する読者はこういう人々

　本連載では、新たなアプローチでプロトタイピングを行い、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案します。読者には、次のような方を想定しています。

1. 上流工程に携わっているが、うまく進まず悩んでいる
2. これから上流工程に挑戦しようとしている
3. 下流工程でコスト、労力が増大してしまったが、その原因は上流工程にあったと感じている
4. 上流工程の進め方について、新しいアプローチを模索している

　本連載では、プロトタイピングに使用するツールとして、オブジェクト指向スクリプト言語であるRubyと、Ruby上に構築されたWebシステムフレームワークであるRuby On Rails（以下：RoR）についても説明し、実際に要件定義からプロトタイピングを作成してみるところまで行う予定です。

　なお、Webシステムの開発を前提として解説を行いますが、クライアントサーバシステムなどその他のシステムであっても、本連載で提案するアプローチが応用できるでしょう。

　第1回は、この提案の基となる動機から出発して、プロトタイピングの有益性と、プロトタイピングツールとして見たRoRの優位性を解説します。

上流工程の苦労

[会話1]

顧客　この要望に対しては、どういう機能がベストなのか迷っているんだ。いままでの経験からよきに計らった作りにしてくれると助かるな。

要件担当者　うーん、これまであまり聞かない業務でして……。持ち帰って検討します。

[会話2]

要件担当者　どう？ 進んでる？

実装担当者　要件定義書を読んだのですが、項番2-3と8-4と9-2の機能が絡み合っていて、どう実装しようか悩んでいるんです。同じサブシステム内にある機能なら作りやすいのですが……。

[会話3]

PM　どうです？ 販売管理サブシステムはなんとか予定どおり完成できると思います。

顧客　……あれ？ このオプションを選んだときは操作後にサマリーも更新されるんじゃないの？

[会話4]

要件担当者　ごめん、どうしてもサマリーの更新処理を追加しないといけなくなったんだ。いったんテストをストップして追加実装してくれる？

実装担当者　分かりました。しかしここでサマリーが更新されるとなると、インパクトが大きいですね……。

[会話5]

要件担当者　サマリー更新処理をこの新仕様でバージョンアップする。変更個所を洗い出しておいて。

保守担当者　サマリー更新に関する実装が、ほとんど設計書と一致しません。あとサマリー更新を呼び出す記述がどの設計書にもないんです。

　あなたが上流工程の経験を積んでいるなら、経験したことのあるやりとりもあるのではないでしょうか。経験豊富な読者なら、どれもよくある状況だとさえ感じるかもしれません。また、これまで主に設計フェーズ以降にかかわってきた読者であれば、このような上流工程の影響を受けてしまった経験を持っている方も多いはずです。

　それぞれの会話が浮き彫りにしている状況を考えてみましょう。

1. 要件がはっきりしていない
2. 要件から設計へのギャップに悩んでいる
3. 顧客のイメージと開発したシステムの動きが食い違っている
4. 3の結果、開発後期に仕様がブレてしまい、その影響範囲が大きい
5. 詳細設計書を書いたが、コーディングした結果、設計が変わってしまった

どうすれば解決できるか

　どのように上流工程を進めれば、これらの苦労を軽減できるでしょうか？ 要件定義書や設計書を完ぺきになるまで洗練することができるとすれば、問題は解決するかもしれません。しかし、これは現実的ではなさそうです。また、上流工程は、技術的な設計テクニックを磨いたり、ドキュメントツールや設計ツールの腕を磨いただけでうまく進むものではありません。上流工程は、顧客のフィードバックを得ながら、要求を引き出し明確化していくという人間系の作業なのです。

　本連載では、「アジャイルな上流工程：プロトタイピングを行うイテレーション」を設けることによりこれらの問題を解決する方法を提案します。