PR

 前回は,要求開発によってシステム開発の生産性が期待通りに向上しない原因として,次の3つを取り上げた。その3つとは,(1)要求開発モデルに記述するべき情報の基準がない,(2)要求開発モデルを活用するツールがない,(3)完全な要求開発モデルを作成する時間がない,である。以下ではこれらの問題が,前々回に触れた「モデルによる工程間連携」と「要求開発フロント・ローディング」によってどのように克服できるかを解説していく。

 (1)では,ISBNコードの例を取り上げた。ここでの課題は以下の2つである。

(A)ISBNコードの文字列長のような「型」に関する情報を要求開発モデルに含めるべきか否か
(B)含めるべきとする場合,どのような方法で表現するか

 まず,(A)の「含めるべきか否か」を決定する。このとき,ISBNコードだけを特別扱いして検討してもよいが,もう少し一般的な問題として考えることもできる。ここでは,(A)の課題を,およそ商品と呼ばれる部類の概念について,「それらの商品番号の文字列長を要求開発の段階で補足すべきかどうか」という課題としてとらえ直すことにしよう。このようにとらえておけば,書籍に限らず,日用雑貨,家電製品など多様な商品を扱う場合でも同じ考え方を適用できる。

 では,そのようにとらえ直した課題に対してどんな方法で決定を下せばよいのだろうか。当たり前のことに聞こえるだろうが,その情報がIT(情報技術)に関係なくビジネスの専門家から得られる情報であり,なおかつ,その情報がシステム開発段階で確実に活用できることが分かっている場合にモデルに含めればよいのである。そして,情報がシステム開発段階で活用できるかどうかを見極めるには,プロトタイピングを行えばよい。商品番号の文字列長の例で言えば,この情報を要求開発モデルに含めるべきであると最終的に判断することになるのはほぼ間違いないのだが,それがどのような形で設計あるいは実装に登場するかを具体的に確かめるのである。

 プロトタイピングは,要求開発で見極めてきたユースケースの中で代表的なものに対して行うようにする。また単に機能要件を設計・実装するだけではなく,性能面など非機能要件も反映したものとする。これは,いわゆるUP(Unified Process:統一プロセス)の推敲(すいこう)フェーズで実施するアーキテクチャ・ベースラインの見極めと似ている。ただし,ここでの主眼は,要求開発モデルのモデル要素に関する情報が最終的にどのような形で,設計あるいは実装に活用できるかどうかを見極めることである点に注意していただきたい。また,通常は要求開発に期待されることのない情報であっても,そうすることに経済的な理由があれば,要求開発で明確化すべき情報としてモデルに含めてもよいだろう。

 もちろん,こうした見極めの結果は,適用されるITあるいはプラットフォームによって変わってくる可能性がある。そのため,未経験のプラットフォームで開発を行う可能性がある場合には,特に入念にこの見極めを行わなければならない。

 要求開発モデルのモデル要素と,システム開発モデルのモデル要素との間に存在する関係を分析することも大切である。このようなモデル要素間の関係を明確にするためには,プロトタイピングであっても,デザイン・パターンを駆使した設計をしたり,リファクタリングにそれなりの時間をかけたりする必要がある。こうした点は,プレゼンによる要件の確認を主目的とするプロトタイピングとは姿勢が異なる。そのあたりを強調して,これを「要求開発フロント・ローディング」と呼ぶ。

 このフロント・ローディング作業により,商品番号の型情報がシステム開発における様々な成果物に浸透していくことを確認できるだろう。具体的には,画面のフィールド長,サービス機能の定義情報,DTO(データ・トランスファ・オブジェクト),データベースのスキーマ情報などである。

 このように,要求開発フロント・ローディングを行うことにより,要求開発で得られた情報を確実にシステム開発で活用できる。またシステム開発側が期待する情報を取りこぼすこともない。これは,将来の手戻りがなく,システムの構築において一定の品質が実現されることを意味する。このあたりは,製造業におけるフロント・ローディングと同様である(次回に続く)。