メディア

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

» 2005年11月11日 12時00分公開

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

前のページへ 1|2|3 次のページへ

プロトタイピングの定義

　ここで、「プロトタイピング」という活動の定義を明確にしておきましょう。ソフトウェア開発に限らず、一般的なプロトタイピングには以下のような目的があるでしょう。

ユーザー要求を具現化し、フィードバックによってさらに明確化する
プロトタイプの設計結果から問題点を洗い出し、本番開発時の設計品質を高める
ユーザー要求や、机上で行った設計の実現可能性を検証する

　本連載ではプロトタイピングを、「本番開発の前に、これらの目的を満たす試作品を創造する活動」と定義します。

紙芝居プロトタイピング

　一般的なシステム開発の上流工程では、ExcelやPowerPointなどのツール、もしくはHTMLによって、画面定義書を作成します。画面定義書は「画面のみ」のプロトタイプであるととらえることができます。これを紙芝居プロトタイピングと呼ぶことにしましょう。紙芝居プロトタイピングは非常に有益ですが、このアプローチではカバーし切れない部分もあります。

図1 紙芝居プロトタイピングによる開発サイクル

　紙芝居プロトタイプでは、要件定義書より踏み込んだ内容の振る舞いや、ソフトウェアとしての設計は、下流工程で行われることになります。その結果、解決すべき問題と作業が集中し、（一部でも）動作可能な成果物がアウトプットされるまでの時間と労力が大きくなります。つまり紙芝居プロトタイピング、最初の動作可能な機能を実現するまでに高い障壁があります。最初の機能が動作するまでが、その後に機能を追加していくときよりもずっと大変だったという経験をされた読者も多いのではないでしょうか。

アジャイルプロトタイピング

　次に示すプロトタイプは、紙芝居プロトタイプが持つ画面のイメージに加えて、システムの振る舞い（実際のロジック）、モデル（データモデル、オブジェクトモデルなど）を含んでいます。

　本連載では、このようなプロトタイプを、「アジャイル」プロトタイプと呼ぶことにします。

図2 アジャイルプロトタイピングを適用した場合の開発サイクル

　アジャイルプロトタイプは、画面に加えて、振る舞い、モデルも含んでいるため、前掲したプロトタイピングの目的をすべて満たします。紙芝居プロトタイピングでは画面のみが検証されますが、アジャイルプロトタイピングでは振る舞い、モデルも早い段階で検証されます。また、プロトタイピングでは、モデルの構築や検証が軽視されがちですが、アジャイルプロトタイピングでは、そういったことは起こらないでしょう。

アジャイルプロトタイピングによって得られるメリット

　渡辺幸三氏によると、プロトタイプを作成すると、ユーザーのニーズを的確にとらえ、さらに開発時間も短縮可能ですが、実際は、工数的に苦しかったりしてプロトタイプが作成されることは少ないのが現実です。しかし、同氏が述べているように、プロトタイプを作成すれば結果的に手戻りが減り、工数を掛けてもお釣りが来るほどの効果があります。つまり、作らないともっと遅れてしまうのです。また、保守などを含めたソフトウェアライフサイクル全体の見地から見ても、アジャイルプロトタイプの作成は小さなコストであり、プロトタイプを使い捨てても元を取ることができるだろうと筆者は考えています。

　アジャイルプロトタイピングによって得られるメリットは、数多くあります。

顧客のフィードバックを効果的に得ることができる
非機能要件は取りあえず無視して、機能要件が定義できる
機能的フィージビリティを早期に確認できる
設計書の代替とすることができる
設計と実装が乖離（かいり）しにくい
提案に使用することで、受注確率をアップできる可能性がある
開発ボリュームの把握精度を向上できる

　では、1つ1つのメリットについて詳しく見てみましょう。

・顧客のフィードバックを効果的に得ることができる

　上流工程は試行錯誤の場です。顧客から質の高いフィードバックをどれだけ密に受け取ることができるかが、最終成果物の質を大きく左右します。例えばマンガ家は、まずネーム（下書き）を作ります。ネームには、話の構成、シーンの時間、場所、登場人物の振る舞いがすべて含まれているでしょう。そしてネームを基に担当編集者（顧客）と打ち合わせを行い、その結果をネームにフィードバックします。マンガ家にとってネームを書かずに執筆を進めることは想像し難いでしょう。システム開発でも同じように、システムの構成、振る舞い、ユーザビリティを含んだ機能イメージを明確化し、早期に顧客との合意を獲得することが必須です。アジャイルプロトタイプによって、実際に顧客が使ってみるまで出てこない要望を抽出することができます。百聞も百見も一触にしかず［※1］というわけです。

［※1］渡辺幸三、業務システムのための上流工程入門──要件定義から分析・設計まで

・非機能要件は取りあえず無視して、機能要件が定義できる

　上流工程のタスクは機能要件の定義だけではありません。実際には、ソフトウェアアーキテクチャの決定や非機能要件の実現方法検討などが行われます。このような作業は、一般的にはアーキテクトによって機能要件の定義と並行されます。つまり本番開発を行うには、これらの作業の終了を待たなければならない部分もあります。しかし、プロトタイプがあればこれを待たずに機能要件の精度を向上することができます。

・機能的フィージビリティを早期に確認できる

　特にWebシステムでは、「本当にこんな画面を実現できるのだろうか？」というような状況がよくあります。プロトタイプを作成して白か黒かをはっきりさせれば、実現不可能な要件でも別の方法を考えることができます。プロトタイプがなければ、開発工程の後半で仕様変更の影響が大きく広がることになってしまうでしょう。

・設計書の代替とすることができる

　完成したプロトタイプを、要求定義のアウトプットとして位置付けることができます。例えば、プロトタイプ画面のショットを仕様書にできますし、入出力項目も洗い出すことができます。また、プロトタイピングによって得られた知見を設計フェーズ以降のインプットとして利用することができます。ある程度の範囲は、設計そのものの代替にまでなるでしょう。さらに、動作可能な成果物があることによって、開発要員への説明も容易になります。リプレイスのプロジェクトは現行システムが仕様となり、比較的スムーズに進む場合がありますが、同等の効果がアジャイルプロトタイピングにより享受できます。

・設計と実装が乖離しにくい

　プログラミングしてみないと設計がどうなるか分からないにもかかわらず、開発プロセスの取り決めから、プログラミングよりも詳細設計を先に行わなければならないことがままあります。この結果、詳細設計書と実装がまったく異なるものになってしまうこともしばしばです。プログラミングは、本質的にソフトウェアの設計行為そのものなので［※2］、実際に試行錯誤しながら作ってみなければ分からないことが数多くあることは、多くの読者にも経験のあることでしょう。アジャイルプロトタイピングでは、動かない設計書をCASEツールで作るよりも、動くソフトウェア［※3］に価値を置きます。この結果、熟考して作成した詳細設計書を書き直す工数を取らなくて済みます。

［※2］ Jack W. Reeves、ソフトウェア設計とは何か？（原題： What Is Software Design?）

［※3］佐原伸、分析・設計ツールとしてのSmalltalk

・提案に使用することで、受注確率をアップできる可能性がある

　アジャイルプロトタイプには振る舞いが実装されるため、開発受注前の提案用モックアップとしてアピールします。アジャイルプロトタイピングにより、提案時のコストを最小限に抑えることも可能でしょう。RoRによってスピーディーにプロトタイピングが行えることは、おいおい解説していく予定です。

・開発ボリュームの把握精度を向上できる

　要求、設計の手戻りが減るので、下流工程の工数ブレが軽減されます。また、システムにおけるすべての層を通した知見が早い段階で得られるため、開発ボリュームの見通しが立てやすくなります。見通しが立てば、当然、見積もり精度の向上も期待できます。いい換えれば、見積もり根拠を明確に示すことができるようになります。

何を捨てて、何を得たいのか