開発フェーズ編 -
第２２章　問題領域分析

２２．１ 目的

問題領域分析フェーズは、ユーザと開発者が共同で作業を行うフェーズである。このフェーズには以下の目的がある。

1. ユーザ要求を理解する。
2. 要求仕様を作りユーザからの合意を得る。
3. 要求仕様作成と並行させながら開発基本計画を作成する。
4. 要求仕様を基に要求モデル図を構築する。
5. システムの実装基盤を決定する。

２２．２ 作業ドキュメント

問題領域分析フェーズで作成するドキュメントの一覧を示す。

ドキュメント名	解説	様式番号
基本計画書	システム開発の基本スケジュール。	1-01
要求仕様書	開発依頼者の要求事項を基にしたシステムの要求を仕様化したもの。要求モデルとして作成したクラス図とオブジェクトレイアウトカードは要求仕様書に添付される。	1-02
開発基盤検討書	システム開発の基盤となるハードウェアとソフトウェアについてまとめたもの	1-03

２２．３ 作業項目の解説

問題領域分析は、ユーザと開発チームが共同で作業を行うことが多いだろう。

ユーザは、問題領域のエキスパートとして問題領域フェーズに参加する。ユーザ参加は、問題領域の本質的な意味構造と運動法則を見抜いて、要求に落とし込むというプロセスにおいて重要な役割を果たすだろう。

その際にユーザがいくらかのモデリングに対する知識を持っていればハッピーである。それがオブジェクトモデリングではなくデータモデリングであっても、このフェーズでは両者にさほど違いが生じることはなく、「もの」を中心とした概念モデルという共通認識はすぐに持てるようになるはずだ。

問題領域分析フェーズは、システム開発に必要とされる多くのエキスパートの知識を借りて、少人数で、短期集中的に意志決定を行うことが肝要である。作業を合理的に行うために、このフェーズでは目的別に以下の３つのワークショップを開催する。ワークショップのとりまとめ役は、ADGのシステム管理者またはシステム分析者が行うようにする。ワークショップの解説は後述する。

• 要求計画ワークショップ
• 要求モデルワークショップ
• 実装基盤ワークショップ

以下にそれぞれの作業項目の説明を行う。

ユーザ要求の理解

ユーザの問題領域を深く理解する作業である。このときのユーザの責任は、なぜこのソフトウェアが必要なのかということを、自分たちが抱えている現状の問題と、それに対する戦略について整理し、システム分析者に伝えることである。

一方、システム分析者の責任は、ユーザの訴える現状の問題や戦略について、しっかりと理解することが重要となる。そしてさらに、ユーザ自身が現状の問題を深く理解していないと感じられるときや、ソフトウェア化の戦略をあまり持っていないときなどは、ユーザをコンサルタントしながらユーザ要求を導き出していかなければならない。ユーザ要求の理解において重要なことは、「何を理解したのかということについて、ユーザとシステム分析者が、共通の理解を得る」ことである。

では、何をもってユーザとシステム分析者が同じものを理解したかという判断をするのであろうか？これに対する適切な答えはないが、以下のようなアプローチは効果があるだろう。

用語辞書を作る

要求仕様を作成する前に、ユーザと話し合った問題領域の現状と戦略の中で語られる用語を整理するための辞書を作る。対象問題において重要となるであろう一般・技術用語、新たな概念を名付けるために作った造語、一般用語の意味を特化させた用語などを記述する。、ユーザとシステム分析者は、用語辞書を作ることによって、要求仕様書の中に現れる用語の意味に対して共通の理解を得ることになる。また、定義された用語の中には、シネマスコープモデルの作成においてオブジェクトの候補となるようなものが含まれているだろう。そのようなオブジェクトの候補についてもこの段階から共通の理解を得ることができる。

現状を認識して戦略を立てるプロセスにシステム分析者が参加する

上記プロセスで用いられるのが「現状認識モデル」と「戦略モデル」である。Dropでは、これらのモデルは対象外となるが、現状を理解して戦略を立てるというアプローチは重要なものであり、この段階からシステム分析者が参加。

要求仕様の作成

システム開発に対する要求を整理して要求仕様書として文書化する。要求仕様書の作成作業は、ADGのシステム分析者の責任において「要求計画ワークショップ」の参加メンバによって進められ、最終的にユーザの合意を得ることになる。

要求仕様の作成は「何を作るべきか」の観点で作成される。つまり、要求仕様書を作成する際の重要な観点は、「ソフトウェアをどう作るか」ではなく「何を作るのか」を明確にしなければならない。

しかし、例外もある。それは、ソフトウェアアーキテクチャに対して要求がだされた場合などである。このようなケースは、開発依頼者がソフトウェア開発者や企業SEであった場合などに頻繁に起こる。たとえば、将来を見据えた戦略的なソフトウェアアーキテクチャを開発依頼者が計画している時などがそうだ。このような場合は、要求仕様書の中の要求条件「構造」に、その要求を説明する文とシステム構造図などを記述しなければならない。

要求仕様書の作成作業は、以下のようなステップを繰り返し行う。

1. 要求事項を箇条書きする。
   システムの要件について箇条書きする。文章の中でわかり辛い用語については用語辞書に追加する。
2. 要求条件の実現可能性を検証するプロトタイプを計画する。
   シネマスコープモデルのシナリオに記述されるキーワードや手順の中で、実現可能性の検証が必要なものを洗い出し、プロトタイプ開発の計画を立てて実施する。
3. 開発期間と要求事項の調整をする。
   要求事項を実現するための期間を見極め、システム基本計画書に定められた期間との調整を行う。

開発基本計画の作成

完成されつつある要求仕様を基に、ターゲットとするソフトウェアの開発スケジュールの調整を行う。この作業は、システム管理者とシステム分析者が中心となって具体的な開発スケジュールを立て、「要求計画ワークショップ」によって最終的な意志決定がなされる。

要求モデルの作成

要求モデルとは、要求の中からソフトウェア実装環境に依存しない部分をモデルとして図式化したものある。要求の中にある基本的なデータ管理と振る舞いに着目点をおいている。

要求モデル作成の意義は、自然言語で記述された要求仕様を、基本的なデータ管理と振る舞いに着目点をおいてモデル化しておくことで、アーキテクチャモデルに要求を的確に反映させることができる点にある。

要求モデルは、理想的なソフトウェア環境を想定した上で作成する。その効果は、DRO解説でも述べたように、実装環境における細かな制約に気をとられることなく、要求に基本的なデータ構造とインタフェースに注目しながらオブジェクトモデリングすることで、ユーザ要求に的を絞った抽象モデルの世界に開発者の意識を引き込んでいけることにある。それによって開発者は、次フェーズにおいて要求モデルをアーキテクチャモデルの揺るぎない基盤とすることができるのである。 また、ユーザ要求を、自然言語ではなく抽象化されたモデルとして、開発メンバで共通のイメージとして持つことができる。

図22-1 アーキテクチャモデルは要求モデルの安定した基盤となる

要求モデルは以下の手順で作成される。数枚のクラス図とオブジェクトレイアウトカードが作成される。

1. シネマスコープモデルにより要求オブジェクトの候補を見つける
   • 要求機能の項目からシナリオ表を作成する
   • シナリオからシーン図を作成する
   • シーン図からシーン統合図を作成して、オブジェクトの候補を得る
2. DRO手法を使って、要求オブジェクトの詳細化を図る
   • オブジェクトの候補をPD（Process、DataManage）レイアに分類する
   • DRO手法に従って、Processの振る舞いとデータ管理(DataManage)オブジェクトの洗練化を行う。

システム実装基盤の調査と決定

システム構築における最適な実装基盤を選定する。検討結果は「開発基盤検討書」として最終的にまとめられる。「開発基盤検討書」は、要求仕様を実現するためのハードウェア・ソフトウェアを決定する。

この決定は、要求仕様の作成と並行して行い、早期に最適な結論を出すことが要求される。しかし、要求分析と混同してこの作業を行ってはならない。あくまで、両者を区別して観点を変えて作業を行う必要がある。要求仕様の作成は「何を作るべきか」の観点、システム実装基盤の決定は「どう作るか」という観点である。

この作業をスムーズに進めるために「実装基盤ワークショップ」が開かれる。「実装基盤ワークショップ」によって、要求分析とは別の観点で実装基盤を決定するために以下の内容について議論され、最終的にドキュメント化される。

1. システムの動作環境の決定（ハードウェア、OS、GUI）
   システムの動作するプラットフォームを決定する。
2. 開発環境と開発ツールの決定（使用する開発言語、市販コンポーネント・フレームワーク製品の決定）
   システム開発において使用する開発言語の決定、市販のソフトウェア（コンポーネント）の決定、使用する開発ツールの決定を行うものである。
3. システム実装のためのフレームワーク環境の検討
   開発環境と開発ツールが決定されることで、その開発環境上で優れたフレームワーク環境を選定する。 フレームワークは、開発言語製品や市販の製品として販売されているものをベースにするか、もしくは、ODGの再利用資産として構築されているものの中から選択することになる。
4. システムの基本コンポーネントと再利用コンポーネントの抽出
   ODGのコンポーネント分析者は、コンポーネント抽出の観点で問題領域分析フェーズに参加する。要求モデルの中から基本コンポーネントを見つけだし、その中から再利用可能なコンポーネントを抽出する。そして、システムを構築する上でのフレームワークや、もっと小さな再利用コンポーネントを構想する。

２２．４ 重要なこと、陥りやすい罠

問題領域分析フェーズにおいて、ユーザ要求を理解して要求仕様書を作ることは、もっとも重要な作業である。要求仕様が完成することで、要求モデルの範囲が明確となり、また、実装基盤の決定もなされるからである。

誤ったアプローチの例は、要求モデル（クラス図）を構築することで要求を見つけだそうとしたり、要求仕様を無視して要求モデルの図式表現だけに関心を持つようなやり方である。これはよくオブジェクト指向開発で陥りやすい罠である。この場合、要求がいつまでたっても明確にならないため、要求モデルに現れるオブジェクトの妥当性を評価できなくなってしまうのである。

２２．５ 発想主導型のソフトウェア開発における要求

製品開発や研究開発における要求は、ターゲットとされる市場を分析することで、開発チームが自ら作り出す必要がある。このような開発では、システム分析者（または発案者）の持つアイデアを要求項目として明確に示すとよいだろう。しかし、それは１枚の紙で終わる簡単なものかもしれない。なぜなら、細かな要求については市場にプロトタイプをリリースしながら決めていくというアプローチが適切であることが多いからである。このような発想主導のソフトウェア開発では、無理に多くの要求項目を決定するより、いち早く市場にプロトタイプ第１号をリリースすることで、市場に対して主導権を握ることが重要な戦略となる。

このような開発では、細かな要求を作り出すよりも、アイデアを製品化することができるかという点に的が絞られるだろう。その際、アイデアをいくつかの具体的な要求項目として整理し、その要求項目をストーリとしてシナリオ化することが重要となる。もし、シナリオ化できなければ、それはアイデアを現実世界へ落とし込むレベルまで到達していないことになり、アイデア自体に検討の余地があるということになる。

このように、発想主導のソフトウェア開発においては、その中心となるアイデアのコンセプトを検証するために、開発者自身が骨格となる要求項目を作り、それをシナリオ化してチームの中でシナリオを検証することが重要となる。細かな要求については、プロトタイプを市場にいち早く出すことで、市場から徐々に吸収していくアプローチがとられることになる。

２２．６ チェックリスト

問題領域分析フェーズの作業過程や完了時に、作業内容の評価を行う材料として以下のチェックリストを示す。

要求仕様書に関するチェックリスト

• 要求項目にシステムの理想が述べられていないか？ 要求項目にはシステム分析者とユーザが合意した内容が記されているものであり、それは実現のための開発期間とコストに裏打ちされたものでなければならない。従って、要求仕様書にシステムの将来的な要求や理想的な要求を記述する場合は、要求項目とは別に、「システムの拡張要求」や「今後の計画」というタイトルを設けて記述しなければならない。

要求モデルに関するチェックリスト

• 要求から考えて開発システムに存在する必要のないオブジェクトはいないか？ たとえば、実世界を分析するために必要となったオブジェクトの中で、要求の範囲外となったオブジェクトなどや、開発するシステムの外に存在するオブジェクトなどがモデルから排除されているかを確認する。
• モデリングに不用意に時間をかけすぎていないか？ 要求モデルの作成には、時間をかけすぎてもよい結果はでない。正確性や形式性にとらわれすぎて、あまりにも詳細化しすぎたモデルは、分かりづらく、要求の基本部分から逸脱してしまうことが多い。問題領域の規模にもよるが、半日から１日程度でモデルを仕上げるように心がけるとよいだろう。 要求モデルを評価する際は、そのモデルが正確であるかという判定より、理解しやすいものであるかが重要となる。
• オブジェクトの役割を明確にしているか？ 要求モデルの中に登場するオブジェクトは、要求仕様に記述された要求項目の役割を担うものでなければならない。役割の不明確なオブジェクトはモデル上から排除するか役割を明確にしなければならない。ただし、作業過程で、検討が必要であるが、まだ分析しきれていないオブジェクトについては、確定するまで未確定なクラス(Pending Classマークを付ける)として残しておくとよいだろう。
• オブジェクトの関連は最適・最小であるか？ 作成された要求モデルを要求仕様のシナリオによりメッセージトレースを行い、要求に必要な関連だけを残す。また、関連の方向性についても検討し、オブジェクトの利用関係を分かる範囲で明確にしておく。（利用関係についてはDROを参照のこと）
• モデルとして取り扱う構造がアーキテクチャに依存してはいないか？ DROでは役割レイアに属するProcessも要求モデルとして抽出する。Processのモデル化があるため、理想的なソフトウェア環境における要求の構造モデルから逸脱して、アーキテチャモデルに限りなく近づいたものを要求モデルとすることもある。このような場合は、現在進行中の要求モデリングが要求の構造のWhatに着目したものであるか？Howに着目したものであるか？ということを見極めてみよう。もし、Howに着目しているのであれば、Whatに観点を切り替えてモデル化し直してみる必要がある。

reference:

参考URL:

• オブジェクト指向シニフィアンス（現状分析の意義と実践 ）

この記事のトップへ