RfS（Ruby for Specifications）

牛尾さんが日経IT Pro Watcherに投稿していたオフショア時代を乗り切る明確な要求仕様作成術について。
ちなみに、牛尾さんは要求開発アライアンスの執行委員つながりです。というわけで、昨日も「大ネタを書いたんですよー」と事前に聞いていたのですが、こりゃ確かに大ネタです。

　Rubyという生産性の高い言語とフレームワーク，そしてアジャイル開発があれば，「仕様書としてのアプリケーション構築」が現実のものとなる。このようなRubyの使い方を，RfS（Ruby for Specifications）と名付けよう。そもそも要件定義フェーズは，作るものが決まっていない「準委任契約」のフェーズである。このフェーズで，動くか動かないか，または正確なのかが わからない紙ベースでの仕様を作るかわりに，Railsを使ったアジャイル開発で，迅速に「仕様書としてのアプリケーション」を構築する。要求開発でプロ ジェクト企画を行い，その後アジャイル開発を使って，実際に動くアプリケーションという「仕様」を作成していくのだ。

オフショア時代を乗り切る明確な要求仕様作成術

興味深いテーマです。基本的にシステム開発プロジェクトが失敗する(もしくは、リスクが高い)原因の一つとしては、

• 計画(設計)が間違っていて、後でこの誤りを修正しようとしてクチャクチャになる。
• 計画(設計)通りに作ってみたら、顧客のイメージと違い使えない。

これを防ぐ為に、ユースケースシナリオを書いてみたりしますが、やはりドキュメントは所詮ドキュメントであり、ユーザと開発者の認識があっていなかったり(解釈が違う)、ユーザが設計ドキュメントのレビューに慣れておらず、誤りを見逃してしまう可能性もあるわけです。(話が横道に逸れますが、ユーザは当然のことながら業務のスペシャリストであって、設計のスペシャリストではないわけです。よくレビューで見逃された不備を「仕様通りです」と押し切ろうとする人がいますが、ステークホルダーがそれぞれ何のプロフェッショナルとして参加しているのかの分析誤りであることがあります)

というわけで、RfSのアイデア及び、「動くものを早めにつくり、確認する」という発想はアグリーです。
とはいえ反論(やアイデア)もあります。

たぶん、Ruby(もしくは似たような何か)で構築されたプロダクトとコードを引き渡して実装に突入するのはさすがにリスキー。データモデルやオブジェクト構成、業務テストシナリオなどを引継ぐのは良いと思いますが、コード等までやってしまうと色々な問題が出てきそうです。
ソフトウェア開発の古典 「達人プログラマー　システム開発の職人から名匠への道(アンドリュー・ハント／デビット・トーマス著)」から引用しますが、

ヒント16. プロトタイプの真の目的は学びにある
プロトタイピングとは、学習経験のことである。その価値はできあがったコードにあるのではなく、学習した教訓そのものなのである。

という意味では、RfSで作成したプロダクトについても、きちんとした評価を行い教訓を導き出した上で開発に適用すべきなように思います。例えばこんな感じだとどうでしょう？

• RfSプロダクトについての、良い点と悪い点(評価レポート)
• RfSプロダクトで試した事、試さなかった事(評価レポート)
  
• 実際のユーザの使われ方(Flash Movieなどで)
• データモデルやオブジェクトモデルの設計(設計書/UMLやDDLなど)
• シンプルな業務テストシナリオ(RfSプロダクトを元に作ってドキュメント化する)
  

このあたりで断ち切ってしまえばちょうどよいかなぁ。
勢いで書いているので、間違ってたらごめんなさい。

ちなみにさっそくSeasar2のひがさんからツッコミが来ていますね･･･。両方知っているのでちょっと微妙な立ち位置･･･。

Blogged with Flock