私見ですが（要求開発アライアンスの意見ではなく），要求開発は，「人」を何も変えずに有効活用する方向性ではなく，現在のテクノロジをフル活用して，ビジネス変化に対応できる競争力を備えたシステムを構築可能にする方向性を選んでいると思います。そのテクノロジの一つがオブジェクト指向です。
そこで前回はオブジェクト指向に関するトレードオフとシステム開発現場の現状について考察しました。今回は要求開発とオブジェクト指向について考えてみたいと思います。
要求開発におけるオブジェクト指向の活躍の場
前回述べた通り，現在のテクノロジを有効に活用し，変化に強い，保守性に優れたシステムを作るためには，システム開発フェーズにおいてオブジェクト指向が必要であり，そのトレードオフとしてオブジェクト指向技術者が必要です。
要求開発は，システム開発ではなくビジネスモデリングにおいて，オブジェクト指向やUMLを活用しています（ただし要求開発で使うすべてのダイアグラムに必ずしもオブジェクト指向を使っているというわけではなく，すべてのダイヤグラムはUMLというわけでもありません*1）。
＊1 筆者意向により一部文章を修正（2007/01/13）
具体的には，TFP分割や概念モデルといったクラス図を使った静的モデルの部分にオブジェクト指向が採用されています。逆に，業務フローの部分や目的構造図，ゴール記述などといった部分はオブジェクト指向とは全く関係ありません。
ビジネスモデリングでの活用例
ビジネスモデリングを行う意義の一つに，ある側面においてビジネスをモデル化することによってビジネスの「概観」を俯瞰できるということがあります。
文字でだらだらと書いてあってもいいのですが，それを読んで覚えて頭で理解するのは大変なことです。それが図になっていると，多くの情報を無理なく読み取ることができます。プレゼンテーションなどでもたいてい図が多く使われています。
さらに，図の表記法が決められていれば，より多くの情報を正確に読み取ることが可能です。UMLを例にとると，図1のダイアグラムからいろいろなことを読み取ることができます。
|
|
| 図1●モデルから多くの情報を読み取る（アプリケーションの権限についての例） |
図1は，アプリケーションの権限についての図です。この図からは以下のことが読み取れます。
・アプリケーションに対して，会社，部門，ユーザーごとに権限を設定できる
・権限には参照権限と更新権限がある
・部門は上位の部門を持っているケースがある
・ユーザーは複数の部門に所属できる（兼務）
・ログイン時にどの部門のユーザーとしてログインするかを選択する
さらに，図を示しながら対話することで，仕様の間違いや抜け/漏れに気づいたり，ビジネスの改善案が出ることもあります。図2～図4の例を見てください。
|
|
| 図2●仕様の問題に気づく | |
あるユーザーと会計部門のシステムについてディスカッションをしていた。ユーザーは「部門」という言葉を使って要件定義をしていたが，どうも話がかみ合わない。よくよく聞いてみると，「部門」といっても会計用の部門と実際の組織の部門の2種類があるようだ。これらの関係を図に整理すると上のようになる。 現在の仕様はシステムにログインする「ユーザー」の「部門」は「会計部門」ということになるが，画面に「組織部門」も表示してほしいという要求がでた。 この図を見ると，システムには「従業員」ではなく「ユーザー」としてログインしているので,「ユーザー」が所属する「会計部門」は特定できる。しかし，一つの「会計部門」に対して「組織部門」は複数あるので，表示したくてもどの「組織部門」を表示するのかを特定できない。このように現場であいまいに使われる用語を可視化して整理することにより，仕様の問題に気づくケースがある。 |
|
|
| 図3●モデルで抜け/漏れを発見する | |
「部門」と「社員」の関係についてユーザーとディスカッションをしている。この場面で，ステップ1のモデルを描いてみた。 ステップ1では，「部門」に対して複数の「社員」がいることが確認できる。確認のために“「社員」は必ず一つの「部門」に所属しますか？”と聞くと，兼務もあると言う。そこで，モデルをステップ2に変更した。これは，一つの部門に複数の社員がおり，社員も複数の部門に所属できることを表す。 さらに要求をまとめていくと，社員が部門に配属された日を取得したいケースがでてきた。ステップ2ではそれが表現できないので，ステップ3に書き換えた。社員と部門には「配属」の関係があるので，「配属」を出して属性として「配属日」を記録するようにしたものだ。 ここでユーザーに“組織変更があるか”と聞くと“頻繁にある”との回答。ステップ3のモデルでは，例えば4月に組織変更がある場合，いったんすべての部門を消して，すべての新部門を登録し直す必要がある。しかも，受注などのデータも旧部門に記録されていると，新しい組織ではどの部門にあるのかわからなくなってしまう。 そこで，一例としてステップ4のように部門に開始日と終了日を持たせて旧部門/新部門がわかるように表現した。こうすれば，データ移行することなく4月1日が来た時点で有効な部門が切り替わる。 |
|
|
| 図4●モデルで業務改善提案 | |
概念を「もの」（顧客や部門）と「こと」（販売実績や受注など）に分ける。現在の構造では，部門・顧客別に月次部門販売実績がある。 基本的に「もの」と「もの」の間に「こと」の概念が存在することが多い。そこで，まだ「もの」と「もの」の間に「こと」が存在しない関係がある場合に，そこにどういう「こと」が存在するかを考えると業務改善につながることがある（大げさだが）。 例えば，現状では「顧客」と「社員」の間に「こと」がない。ここに「こと」が入るとすればどんなものがあるだろうと考えてみる。この会社では「月次社員別販売実績」をとっていないので，このデータを保存すれば，個人別の業績を分析できるようになるだろう。 もう一つ「顧客」と「顧客」の間の「こと」を想像してみる。例えば「紹介」というのがあるかもしれない。そうすれば顧客に顧客を紹介してもらって友達割引を行うようなビジネスができるかもしれない。 |
このような例は，データ・モデリングにおいても同様の効果があります。では，これに「オブジェクト指向で」という条件が付いた場合はどうなるでしょうか？
オブジェクト指向によるビジネスモデリングの利点
オブジェクト指向によるビジネスモデリングがデータによるものと異なる点は，「振る舞い」が付いていることと，「データでないもの」をモデル化できることです。例えば，データでないものをモデル化する場面にはこのようなものがあります。
|
|
| 図5●データ以外のモデル化 | |
この例では「得意先」と「商品」ごとに「値引き」が決まり，「値引」には「法人値引」「個人値引」「特別値引」がある。そしてそれぞれ値引計算のロジックが異なることを示している。 |
|
|
| 図6●振る舞いの使い方 | |
ある建築系企業で顧客からのクレームに対する対応方法を考えている。メンバーは「最初のモデルスケッチ」を書いた。 「クレーム」をモデル化し，クレームは「顧客」から上がってくるので「顧客」もモデル化している。クレームに関係しそうな要素は「プロジェクト」と「建物」があるので，それらを出しておく。一つの「プロジェクト」で複数の「建物」を建てるケースがあり，一つの「建物」が複数の「プロジェクト」によって作られるケースもある。 メンバーはこの図を見ながらディスカッションした。まず，クレームは何に対して発生しているのか。どう考えても顧客は「プロジェクト」は見えていないので，クレームは「建物」から発生する。さらにクレームの内容は建物の古さが原因になることが多かったので，「建物」を継続して「改修」するような施策をうてばどうか？という意見も出た。それを表したのが図6の議論後のスケッチである。 |
また，オブジェクト指向は，機能やデータで分析するよりも，より多くのものをまとめて扱うことができます。図7は，スーパークラスを使った例です。
|
|
| 図7●スーパークラスの例 | |
ある企業では，商品には「定価商品」「バーゲン対象商品」「季節商品」の三種類がある。それらを大きくくくると「商品」と考えることができるとき，モデル化に際しては白い三角印で表す。 すると「商品」には「定価商品」「バーゲン対象商品」「季節商品」があると読み取れるようになる。また，単価の計算ロジックもそれぞれの商品で全く違うことが想像できる。例えば，バーゲン対象品はバーゲンごとに単価を設定できるようだ。 |
ただし，スーパークラスに関しては，データ中心の手法でもスーパークラスなどの概念が取り入れられているケースがあります。
もう一つ，データ中心の方法と比較すると，関連にキーというものが存在しないので，オブジェクト指向は世の中のものをモデル化するという点ではより自然に表現できるという特徴があります（図8）。
|
|
| 図8●データ・モデル（左）とオブジェクト・モデル（右） | |
データ・モデルでは，主キーや外部キーの設定を意識しなければならない。オブジェクト・モデルでは，関連があるからといって，関連の付いた概念に何か属性を追加することはない。 |
データ・モデリングには，属人性が出にくいという非常にすばらしい利点があります。一方，オブジェクト・モデリングはより多くの表現が可能で，同じことを簡潔に表すことができるので，ビジネスの表現においてはより自然に表せます。
ただし，オブジェクト・モデリングには，自由度が高すぎてモデルに属人性が出るという大きな欠点があります。そこで，要求開発アライアンスでは，データ・モデリングの考えを「ルール」としてオブジェクト・モデリングに持ち込んで，モデリングを簡単に属人性を少なくする「TFP分割」という手法を開発しています（図9）。
|
|
| 図9●TFP分割モデル例（Function図最上位） |
TFP分割手法は，生まれたばかりでブラッシュアップしている最中ですが，実プロジェクトにおいてかなりの効果を発揮しています。
「手法」はしょせん人が便利になるためのものなので，どの方法論が云々といったことはどうでもよくて，現場が便利になるならば，どんどん取り入れていけば良いと思います。
ユーザーに理解できるのか？
私が要求開発を始めて「これは良い」と思ったことは，システム開発で培った知識（オブジェクト指向やUMLの知識）をそのまま要求開発の場面で活用できることです。
例えば，あまり知らない（もちろん最低限の業務知識などは習得していますが）業種の顧客へ伺ってビジネスモデルを作っていく過程では，事前の調査に加えて，オブジェクト指向の考え方を活かしてロジカルに考察し，質問できました。また，図を作り上げる際にも，いきなり議論に参加できて問題点や業務の改善ポイントを指摘したりすることができました。
地味なことですが，こうしたところが私が気に入っているポイントの一つです。さらにシステム開発をオブジェクト指向で実施するのであれば，要求開発の成果物をスムーズにシステム開発につなげることが可能です。
ところで「オブジェクト指向の知識を必要とするTFP分割などのダイアグラムがユーザーに理解できるのか？」という点は，私自身も要求開発を始めるまではかなり疑問でした。しかし，実際の体験を通じて，思いのほかユーザーに理解してもらえることがわかりました。
とはいえ，TFP分割で作成したダイアグラムをいきなりユーザーに見せても「なんじゃこりゃ？」となるのは当然です。それをわかってもらうためにはどうするか？
それには“モデルを作っている過程を見てもらう”というプラクティスがとても有効に働きます。UMLだ，オブジェクト指向だといっても，実際にやるのは単純なことです。ユーザーが持っている現場の資料を使って，どのようにクラスを考えて，図にまとめるかという作業を一緒にやってみると，オブジェクト指向やUMLの知識がないユーザーでも，ビジネスモデリングに必要なモデル要素に関しては簡単に理解してもらえました。「これはスゴイ！」と言われることもありました。
ただし，ユーザーにはあくまで業務をまとめる「整理術」として説明し，難しいオブジェクト指向の専門用語は使わないようにしています。
また，ユーザーにとってわかりにくい「振る舞い」に関しては，前回紹介したオブジェクト・ゲームのビジネスモデリング版を体験してもらうこことで，理解してもらえるようです。
要求開発の課題
今回は，要求開発とオブジェクト指向のかかわりを中心に説明しました。要求開発は，現時点のバージョンでも十分に役立つレベルにはありますが，まだまだ発展途上なので課題もあります。最後にその課題を整理して本稿を締めたいと思います。
1．オブジェクト指向の壁（ユーザー）
オブジェクト指向の考えは，前述のような方法を実施すると意外に簡単にユーザーに理解してもらえるものです。しかし“簡単にわかってもらう”方法がまとまっていません。今後はもっと簡単に理解してもらうための方法をまとめていく必要があります。私もオブジェクト・ゲームのビジネスモデリング適用の方法や上記のノウハウなどを要求開発アライアンスで共有していきたいと考えています。
2．オブジェクト指向の壁（システム側）
オブジェクト指向をシステム開発で活用できる人を短期間に増やす方法をもっともっと考えていく必要があります。これに関しても，オブジェクト・ゲームなどの新しいアイデアが出てきているので，さらに推し進めるべきです。そして多くの人がもっと楽にオブジェクト指向をマスターできる方法を開発するべきです。それをマスターすることがシステム開発の基礎知識だと認知されるレベルになることが必要です。
3．複数のプロジェクトをまたがる大きなシステムへの対応
要求開発は，もともとは一つのプロジェクトをターゲットにしたものです。しかし，現実には，ユーザー企業では複数のプロジェクトを運営しています。したがって，要求開発は，複数のプロジェクト全体を最適化するといったシーンにも対応していく必要があります。実際現場ではそのようなプロジェクトへの適用が始まっています。そのノウハウはまだ整備されていませんので，今後整備していくべきだと思います。
4．代替案
要求開発領域のプロセスがわかりやすくまとめられているという点で，要求開発は大変すばらしいものです。しかし，要求開発領域はカオス的な状況が多いので，方式的にもいろいろな「代替案」を提示できることが必要です。要求開発にはプラグインの仕組みがあり，代替案を提示することが可能です。とはいえ，プラグインの数はまだ少ないのが現状です。現場でうまくいった事例のフィードバックをどんどんプラグイン化して，いろいろな代替案を提示しやすくするアクションも必要です。
5．システム開発での変化への対応
現在の要求開発は，「要求開発」からRFP（Request For Proposal）を経由して「システム開発」にバトンタッチされるようなイメージに見えます。いくら要求開発といえども，要求開発の時点で100％仕様を確定するのは不可能でしょう。システム開発過程で仕様変更があった場合でも，要求開発では，経営戦略からのトレーサビリティがわかりやすくなっているため，要求変更時/追加時の判断が格段に正確になると思います。しかし，ビジネス自体が変化を起こすこともあります。したがって，要求開発とシステム開発はダイナミックに融合して変化を抱擁できるようにするべきではと思います。要求開発アライアンスでもそのような議論がなされています。
6．その他
最後に筆者個人の意見です。要求開発の最大のトレードオフは「オブジェクト指向を使える人を育てる必要がある」ということです。現在のITインフラの状況を見ても“現場流”だけで押し切るのはそろそろ限界に来ていると思います。とすれば，できるだけ簡単に“オブジェクト化”してしまう方法を考えて，変化に強いシステムを作れるような方向に進んだほうがいいでしょう。そうなった人には，要求開発はとても便利な道具になります。
一方，ユーザー企業でも現在のビジネスは複雑かつ変化に富んでおり，これからのビジネスパーソンには複雑さに対処するためにビジネスの「抽象化」能力が必要と思われます。現在では，ビジネスを抽象化する方法は，様々で統一されていません。しかし，例えば，要求開発で使っているようなUMLでの抽象化の方法を選択すると，前述のようなメリットがあり，システム開発メンバーともスムーズに意思疎通ができるようになります。
ユーザー企業のシステム部門でも，システム開発を発注するケースで，内部がブラックボックス化していたものを，要求においても中身においてもコントロールを取り戻すことができる一歩になります。
ビジネスとITが融合している現在において，ITとスムーズにつながる要求開発はとても魅力のある手法であり，これからの日本のシステム開発シーンをより良くしていく一つの大きな可能性と感じています。
|
| （牛尾 剛＝要求開発アライアンス） |
