第１０回XMLコンソーシアムDayで、１０時からの「i*法を用いたゴール指向分析とサービス設計」で、ウィリアムのいたずらがした質問、？？？だったようなので（ちゃんと話す時間もなかったので）ここに書いておきます。
■質問の前提（i*法でできること）
要求仕様分析方法として、最近i*法（あいすたーほう）が注目されている。
i*法では、「誤ったサービスの共通化」を防ぐ効果がある。
「誤ったサービスの共通化」とは、本来共通化すべきサービスではない（まったく違ったサービス）なのに、機能名が同じために、共通のサービスとしてしまうことを言う。
たとえば、顧客管理という同じ名前なので、サービスを共通化しようとすると、個人顧客、法人顧客でまったく違い、ひとつも共通化できないといったものである。
この場合、”利用者”からみた
・ゴール
・ソフトゴール（早く行う、とか言った副詞的な要望）
・リソース
が同じならば、共通化できる。
という説明がありました。
■質問
サービスが同じかどうか判断する必要がある時は、多数のサービスがあると思われる。
そうすると、
・ゴール
・ソフトゴール
・リソース（入出力）
が同じものといっても、見つけるのが大変なうえ、ソフトゴール、リソースが辞書になっているとか、標準化していないと、本当は同じことでも違う言葉として表記されている場合もあり得る。
そこで、
・ソフトゴールの標準化
・ＸＭＬ（とデータデータディクショナリ）を使い、機械的にリソース、ソフトゴールが
一致しているというような自動的なチェック方法
が必要になってくると思われる。
ソフトゴールの標準化に関しては、お話の中にあった（"ilities"）が、もう一方の、ゴール、ソフトゴール、リソースをＸＭＬ化して、同じサービスを見つけようとか、そういうことは、考えていますか？
■質問の答え
考えていない模様・・・
■質問した背景
ウィリアムのいたずらも、まったく違う手法において、サービスやシステムを共通化できるかどうかの目安として、
利用者からみた
・ゴール
・ソフトゴール
・リソース（入出力）
が重要だという結論を得た。
（利用者！ですよ、売る人から見たら、もー、売れそうならなんでも、おんなじ、悪いようにはしないから・・ですから・・）
さらに、そこから発展して、
サービスが同じ場合、リソースやソフトゴールが一致するというのは、極論するとまれなことであって、
多少の違いがあっても、共通化できる、
しかし、ある限度をこえると、共通化できない
というように考えられる。ここまでの話のところまで、きている。
そして、これを、数値的に表すための数理モデル（つまり、このモジュールと、このモジュールは、開発したら、たぶん共通部分がこれくらいあり、危険性（共通でない可能性）がこれくらいある。それを改修するために、これくらいのコストがかかる）を思いつき、それで、ドクターをとることを狙っている（ここには、上記のＸＭＬが出てくる）。
修士では、その数理モデルに必要な、基本的な枠組みを作ろうと思っている。
なので、この共通化をやる手法を、私がドクターをとるまでの間、５年間くらいの間にできちゃうと困るんです。なので、どこまでできているのか？と思って質問しました。
質問の意味が分かんないので、たぶん、ここまで行ってませんね。あんしんあんしん。
（質問の意味がわかっても、その数値的に表すための数理モデルがわからないと思う。従来の情報科学のななめ上をいくようなことを考えているので。もっとも、修士の範囲の枠組みは、情報処理科学の範疇なのだが・・・）
i*法や、ＸＭＬコンソーシアムＤａｙの話は、また別に書きます。
Ｐ．Ｓ ということであのとき、一番初めに質問した人がウィリアムのいたずらです。
２番目に質問した人もサービスの共通化に関してだったし、次のＸＭＬ設計技術勉強会でもサービスの共通化の話がでてたから、やっぱりこの辺、関心が高いのかも？
あ、なぜ、関心がたかいか、に関して、別の機会に書きますね。これが標準化や、フレームワーク選定、再利用につながってくる話なんですよね！！
