メディア

プロトタイピングの成功は実装技術に左右される：Rubyでアジャイルプロトタイピング（6）（2/2 ページ）

» 2006年05月17日 12時00分公開

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

アジャイルプロトタイピングのこれから

　IT技術が日々進化しており、開発手法も日々進化を重ねていることはいうまでもありません。筆者が今後の情報システム開発全体において、必ず理解しておくべきと考えている概念の1つに、要求開発があります。ここでは要求開発の考え方に沿って、本連載で提案したアジャイルプロトタイピングが、どのような進化を遂げていくか、また遂げるべきであるかを考察してみたいと思います。

● 要求開発とは

　まず要求開発を簡単にご紹介します。要求開発は、その提言を行った要求開発アライアンス（1）という有志団体によって、以下のように説明されています。

　「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値に基づいて『開発』されるべきものである」という信念にもとづき、経営上の目的を果たすために、業務の設計、あるいは再設計を行う中で、ビジネス上の要求と情報システムが担うべき要求を導き、定義する活動。

　要求開発アライアンスからは、要求開発方法論である「Openthology」が発表されています。Openthologyのコアは、要求開発アライアンスのWebページて、読みやすくまとまったパワーポイントの資料として公開されていますので、ぜひ一読されることをお勧めします。また、要求開発アライアンスのメンバーである山岸氏による記事「ビジネス要求に基づく“役立つシステム”の実現手法」でも、要求開発が非常に分かりやすく紹介されています。

● アジャイルプロトタイピングと要求開発

　要求開発はシステム開発より上位の概念です。Openthologyによれば、広義の要求開発はシステム開発まで含むとされています。要求開発を本連載で提案したアジャイルプロトタイピングと単純に並べて比較することはできませんが、「顧客の要求はあいまいである」という、共通の出発点に立っています。要求開発とアジャイルプロトタイピングがどのように関係するかを考えてみましょう。

● 要求開発から読み取れるアドバイス

　要求開発はアジャイルプロトタイピングに対して、いくつかの貴重な示唆を含んでいます。

（1）顧客の中でも、さまざまな立場の人間に話を聞く

　Openthologyコアでは、良いシステム開発ができない大きな理由として、次の3つのステークホルダ間で合意が取れていない場合が多いことを挙げています。

業務管理者（経営者、管理職）
業務担当者（現場の担当者）
システム開発者（顧客の中では、IT部門の担当者）

　アジャイルプロトタイピングでは、顧客から大量、高質のフィードバックを引き出しますが、上記三者からのフィードバックを万遍（まんべん）なく引き出すことが重要であることに気付かされます。

（2）ユーザーからヒアリングした要求が、正しいとは限らない

　これはなかなかショッキングな事実です。要求開発にはその名のとおり、「要求は業務からロジカルに導かれなければならない」という考え方が根底にあります。この考え方にのっとれば、アジャイルプロトタイピングにおいて、獲得したフィードバックを盲目的にプロトタイプに反映するのは危険です。フィードバックの獲得とプロトタイプへの反映作業の間では、ロジカルに要求を導出することを忘れてはなりません。

　顧客の「本当はどうしたいの？」を探すとともに、「本当はどうすべきなの？」を探すことが重要です。間違えたものを正しく作っても、システムの投資効果は得られないのです。

（3）HowでなくWhatの試行錯誤を行う

　RubyやRoRといった、いわば高性能なエンジンにより、アジャイルプロトタイピングの速度は大幅に加速されます。ただし、これらのツールで直接的に加速されるのは、要求をどのように実現するかを考える、いわば「Howの試行錯誤」の部分です。要求開発は何をすべきかをロジカルに導くべきだとしていますが、要求の開発はシステムの開発と同じように複雑な活動であり、その中に「何をすべきか」を見いだすための試行錯誤、つまり「Whatの試行錯誤」を含んでいると考えられます。このWhatの試行錯誤を常に意識して、アジャイルプロトタイピングを進めることが大切です。

　以上を踏まえると、下図のような多重ループを成す開発サイクルが見えてきます。

「何をすべきか」の知見を得るフィードバックサイクル

（4）要求モデルか、動くプロトタイプか

　要求開発においては、主にUMLなどで記述される要求モデル（ドキュメント）が成果物とされます。これは一見、動くプロトタイプを重視するアジャイルプロトタイプと相反するように思えます。しかし、顧客の要望を動作可能でかつ業務に有益なプロトタイプまで落とし込むには、要求の整理とモデル化が必要です。つまり、要求開発とアジャイルプロトタイピングは排他的ではないのです。

　Openthologyは、無駄なモデル（ドキュメント）を省くために、それぞれの開発で必要なモデルだけを「プラグイン」できるように設計されています。Openthologyコアのプロセス概要編では、開発タイプを大まかに4つに分類し、それぞれどのようなモデル化が望ましいかが言及されています。このように見事に設計された柔軟性のおかげで、無駄なモデル化を強制される心配はありません。では、要求モデルがあればプロトタイプは不要でしょうか？

● アジャイルプロトタイピングの使い所

　要求開発の中で、アジャイルプロトタイプは以下のような場合に特に効果的です。

顧客企業がIT部門などの専門部隊を持たず、要求モデルを理解してもらうことが困難
モデル化で煮詰まってしまい、作ってみた方が早い
要求モデルはできたが、いまいち具体的システムイメージがわかない
要求モデルができた場合の最終合意として、動くプロトタイプが欲しい
モデルのベンチマーク（ROIの検証）、複数のプロトタイプでの比較をしたい

　アジャイルプロトタイピングは、要求開発のプロセスで煮詰まったときのブレイクスルーとなる可能性を秘めています。そして、アジャイルプロトタイピングは要求開発に組み込むことによって、真の効果を発揮できるものになるのではないでしょうか。

　Openthologyが原稿執筆時点でバージョン0.6とされていることからも分かるように、要求開発はまだまだ発展を続けている分野です。筆者は、今後、要求開発にプロトタイピングがさらに取り入れられ、進化していくことを期待しています。

● RoRのこれから

　最後に、RoRの進化について簡単に紹介しておきます。連載開始時点ではバージョン1.0がリリースされていませんでしたが、原稿執筆時点（2006/04/01）ではバージョン1.1がリリースされています。RoRの機能の充実ぶりは、すでにニーズを追い越すほどになっています。また、これまでは書籍、Webページともに英語のリソースが中心でしたが、「Agile Web Development with Rails」の邦訳「RailsによるアジャイルWebアプリケーション開発」が出版されたことなどもあり、RoRの認知度が一層高まってきたように感じられます。RoRは世界中の開発者に支えられながら、これからもすさまじい速度で進化していくでしょう。

　連載を通していえることは、上流工程と製造工程は相互作用し合い、繰り返される活動であるということです。アジャイルプロトタイピングは上流～下流横断的な活動です。だからこそ、業務全体の最適化に貢献できるのです。そして、横断的活動であるからこそ、上流工程の方法論だけでなく、RoRのような実装よりの新技術もバランスよく押さえることが重要ではないでしょうか。本連載は上流工程におけるアジャイルなプロトタイピングがどのように有効かをお伝えしてきました。しかし、たとえ上流工程ではなくとも、開発プロセス全体のどこかに、あるいは新たな発想のきっかけとしてでも、本連載が少しでも読者の方々のお役に立てば幸いです。

「Rubyでアジャイルプロトタイピング」バックナンバー

前のページへ 1|2 　　　　　　