今回は，フロントローディング開発の利用を目的別に分けて考えてみます。フロントローディング開発とは，要求開発段階で開発を行うことにより，開発段階で発生する様々なリスクを取り去ることを目的として行われるプロトタイプ開発のことです。
現段階では，フロントローディング開発についての具体的な開発タイプの定義はありません。よって，ここでは筆者が作成した方法論「Drop」＊1のプロトタイプ開発のタイプを参考にして，要求開発におけるフロントローディングのタイプを考えてみました。
＊1 オブジェクト指向方法論「Drop」については，こちらのサイトを参照してください。
実際の要求開発では，ここで解説したものを参考にしてみるとよいかもしれません。また，このほかにも有効となるフロントローディング開発パターンを見つけている人は，ぜひコメントいただければうれしいです。
フロントローディング開発の進め方
フロントローディング開発を成功させるためには，以下の事柄などを明確に決めなければなりません。
・効果と目的
・検証/評価方法
・再利用範囲
そこで，これらをフロントローディング計画（プロセスセルのプラン）で，プロトタイプ開発基本計画書（表1）として記述するとよいでしょう。
|
|
| 表1●フロントローディング開発基本計画書の主な記載事項 |
以下では，三つのプロトタイプ開発における目的，効果，注意事項を説明します。参考にしてください。
(1)プレゼンテーション支援プロトタイプ
■目的
エンドユーザーにシステムの効果や特徴をプレゼンテーションするために作成されます。これは，複雑な新規ビジネスにおけるIT活用で使用されます。エンドユーザーと開発者との間でシステムのオーバービューを確認したり，不特定多数のユーザーに対するユーザービリティの妥当性を検証できるといった効果があります。これによってエンドユーザーは，システムの大まかなビューと機能を直接目で確認できるようになり，新たな要求を創造させるきっかけを作ります。
つまり，このプロトタイプは，システム開発企画のためのナビゲーション（道案内）的役割を果たしたり，早期に要求をコミットできるようにエンドユーザーのシステムに対する理解を促したりする非常に有効な手段となります。
■効果
・ITによってビジネスに付加価値を与えるための要求の創造
■注意事項
このプロトタイプは，本番システムの予告であることを忘れてはなりません。本番の開発環境では実現不可能なユーザー・インタフェースや機能を取り込まないよう十分に注意を払う必要があります。
また，本質的に必要とされないユーザー・インタフェースの詳細にこだわる必要はありません。あくまで求められるIT化の本質部分の検証として利用する必要があります。
(2)ToBe業務評価プロトタイプ
■目的
将来業務の姿について，業務モデル（業務フローなど）を使って理解させるというのは限界があります。将来業務に対して，さらに利用者の覚悟を取り付けるために，業務フローのほかに，業務の中で利用するIT（画面/帳票）の姿を見せることは，とても効果的な方法です。しかし，モデルと画面イメージだけで，人が具体的なToBeイメージを理解するのは限界があるようです。
そこで，実際の画面イメージと操作について，使うところだけをできるだけスピーディにプロトタイプとして作り，業務フローとセットでToBeの業務イメージを行うために利用します。
ToBe業務評価プロトタイプは，このように業務フローとセットにすることで，ToBe業務の評価を行うために作成するものです。
■効果
・ToBe業務の見える化と覚悟
■注意事項
このプロトタイプは，単なる画面/帳票イメージや画面遷移を確認するためのものではありません。ToBe業務を評価するプロトタイプであることを忘れてはなりません。あくまでも業務担当者に，ToBe業務の妥当性を確認させ，ToBe業務に対して覚悟をとりつけるために利用されるものです。そのため業務担当者にToBe業務の流れを業務フローで確認してもらいつつ，その中でこのプロトタイプを利用してもらいます。
(3)システム構造評価プロトタイプ
■目的
システムの全体的な基盤構造（ベースアーキテクチャ）の決定は，その後のシステム開発に大きな影響を与えます。できるだけ早い時期に短期間で正しい選択を促さなければなりません。
また，大規模システムにおいては，複数のサブシステムにおける共通アーキテクチャを検討する必要があります。システム構造評価プロトタイプとは，システムの基盤構造を決定するために，以下のような目的を持って行うプロトタイプのことです。
・利用する市販ソフトウエア製品の性能比較評価
・システム基盤構造の実現可能性に対する評価
・システムの性能が要求を満たすレベルであるかの評価
・サブシステム間の連携（SOAなど）アーキテクチャの検証
■効果
・システム開発のベースアーキテクチャ開発におけるリスクヘッジ
・ベースアーキテクチャやアーキテクチャ開発環境に関する企業レベルの統一化
■注意事項
性能評価，方式評価が目的となるため，必要部分だけに焦点を絞って開発されます。したがって，より良いクラス設計という部分については後回にし，方式的な検証が済んだ後で，リファクタリングするとよいでしょう。
| （萩本 順三＝要求開発アライアンス理事） |
