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
2 件のコメント:
>RfSで作成したプロダクトについても、きちんとした評価を行い教訓を導き出した上で開発に適用すべきなように思います。例えばこんな感じだとどうでしょう?
へー、面白いです。「学び」を伝えるということ!
学びの中には単一脳スティッキーなものが50%ある、と考えると、学んだ人を開発にちゃんと入れる、というのは肝要な気がします。で、開発を進めながら伝える。
コメントありがとうございます!
なんとなく、PFPなどで取扱われている「ふりかえり」はプロジェクト自体(人や運営など)を対象にしているなぁと最近思っているのです。
最近プロトタイプ開発手法なんて、すっかり古臭くなってしまっていますが、改めて考えてみるといろいろと勉強になります。
引続きよろしくお願いします。
コメントを投稿