前回は，「要求開発は，ユーザー企業のためのもの」ということを知ることで，方法論（Openthology）のモデリングやプロセスの目的と価値について，改めて考えるようになったことを書きました。
この論議に続いて，ある方が「モデリングには目的がある，目的のないモデルには意味がない」と言われました。私には，衝撃的な言葉でした。そこで，今回はモデリングの目的について，考えてみようと思います。
筆者は，SI企業のSEという立場で，ユーザー企業のシステム開発プロジェクトに参画します。システム要求がきちんと整理されたRFPが存在する場合は，どうやって実装するかについてモデリングを行います。これは，「正しく」システムをつくるためのモデリングです。
一方で，そこまでの具体性がないままに発注されている場合もよくあります。この場合，ユーザー企業側でも，ビジネス要求に基づくシステム要求が整理しきれておらず，まずは，一緒に検討を行い，仕様について合意を得たうえで開発を進めることになります。
ここでのモデリングの目的は，「正しい」システムをつくるために，あいまいな部分を明らかにし，システム構築に必要となる具体性を導き出すことだと筆者は考えています。何がどのくらい検討されているのかをきちんと把握し，何があいまいなのかを明らかにします。これにより，何について分析し設計したらよいかが見えてきます。
あいまいになったままの要求には，例えば，次のようなものがあります。
(1)システムの前提となる業務の目的や，期待すべき効果
(2)システムの前提となる業務の詳細
(3)システム化の範囲
(4)主要な概念とその関連
(5)システムの非機能要件（セキュリティ要件，パフォーマンス要件，ソフトウェア品質要件）
明確な目的をもってモデリングを実施すると，様々な「気づき」が得られます。簡単な例を示しましょう。
|
|
|
| 図1●As-Isの概念モデル |
さて，システムの詳細を検討する前に，顧客の層別について，概念を整理してみようと思います。
まず，現状のポイントサービスについて，「顧客が商品を購入するとポイントが付与される」という関係をモデルにすると図1のようになります。
次に，新しいシステムを導入するとどうなるのかをモデリングします。顧客には「一般客」と「会員」とがあり，会員には「一般会員」と「ゴールド会員」があるという関係を整理すると図2のようになります。
|
|
| 図2●To-Beの概念モデル |
このようにAs-IsとTo-Beの業務について，概念を整理し，比較することで，次のような効果が得られます。
(1)新システムが導入されることで，何が変わるのか具体的にイメージできる
(2)詳細な分析，設計を行うべき対象が見えてくる
上記について，例えば，次のような「気づき」があります。
- ポイントが付与されるのは会員のみで，会員は層別される。
- ゴールド会員には，特典がある。
- 会員制や層別の基準，特典サービスの実現方法などについて検討が必要。
- そのためのシステムのあり方について，検討が必要。
（期間別に累計ポイントが一定の基準を越すと，ゴールド会員に格上げされる。そのためには，システムはどうあるべきか検討が必要など）
さらに，会員情報やオーダー記録をどのように持つかなどを検討することで，クラス図は詳細化されていきます。
このように，あいまいな部分についてモデリングによる「見える化」を行うと，システムへの要求はより具体的なものになっていきます。システムを「正しく」つくるためのモデリングは，もちろん重要です。しかし，それ以前にシステムのあるべき姿が十分検討されていない場合は，「正しくない」システムを「正しく」つくるということになってしまいます。
ユーザー企業にとって，システムのあるべき姿を検討し，「ほんとうに役に立つ」システムを検討することは，非常に価値のあることです。要求開発やOpenthologyの価値はそのあたりにあることを実感しました。
次回は，これらの「気づき」をふまえて，「要求開発は誰のためのもの」について，もう一度考えてみようと思います。
| （中山 尚子＝要求開発アライアンス） |
