アプリケーションドメイン

ドメイン分割ができたら、次はアプリケーションドメインから順番に分析を始 めます。「順番に」と書きましたが、アプリケーションドメインが最難関で、 これさえできればそれ以外のドメインはあまり考える事はないはずです。

アプリケーションドメインだけは年期の入ったソフトウェア屋さんほどなじみ にくいはすです。なぜなら、ユーザインターフェースやデータベースドメイン はコンピュータを対象としていますが、アプリケーションドメインだけはコン ピュータは対象範囲外だからです。ソフト屋さんが日頃使い慣れている言葉は 使ってはいけないのです。だから難しいのであり、意識改革が必要なのです。

アプリケーションドメイン分析の目指すところ

アプリケーション分析では、対象としているソフトウェアが扱う対象世界につ いて分析します。ソフトウェアそのものの分析ではありません。ですから、あ なたがこれから作ろうとするソフトウェアに関する事柄はまったく出てこない はずです。このソフトウェアで「何をするのか」ではなく、その対象がそもそ も「何であるか」を記述するのです。

音楽データベースなら「音楽とは何か？作曲者とは何か？編曲とは？」といっ た問いに答えることであり、財務処理ソフトなら「収入とは？支出とは？税と は？」といった問いに答えることです。あなたがソフトウェアを作る立場であ れば、このあたりの話はきっと専門ではないでしょう。逆にあなたより依頼主 の方が詳しい話です。あなたは依頼主から話を聞きながら、あなたなりに対象 世界を理解するのです。

アプリケーションドメイン分析に意義はまさにここにあります。なぜアプリケー ションドメインの分析をするかというと、それがあなたの知らない領域であり、 そしてソフトウェアを作成するにはその世界を理解しないといけないからです。 自分なりに分析をしましょう。そしてその結果をその分野の専門家(つまり依 頼主)に見てもらいましょう。そこでその専門家に「どこも間違っていない」 と保証してもらうことができれば、あなたは対象世界を専門家並に正しく理解 したということなのです。

いったんアプリケーションドメイン分析ができてしまえば、もう疑問点を依頼 主にあれこれ聞く必要はなくなります。なぜなら専門家に聞くべき疑問点はす べて分析結果としてできているわけですから。その他の点、例えばユーザイン ターフェースやデータベース管理などはあなたの専門分野であり、依頼主より あなたの方が詳しい分野です。だからアプリケーションドメインの分析が最重 要課題なのです。

依頼主に見てもらうための仕様書

アプリケーションドメイン分析は、あなたではなくその分野の専門家である依 頼主に見てもらうべき内容です。依頼主が先生でありあなたはその生徒なので す。あなたは答案を先生に見せて点数をつけてもらう立場なのです。ですから、 アプリケーションドメインの分析結果はその分野の専門家が見てわかる内容で なくてはなりません。

仕様書を提出して「こういう仕様でソフトウェアを作りますけどいいですか？」 と確認するのは誰もがしていることでしょう。しかし、多くの場合その仕様書 はコンピュータ用語の羅列で、(コンピュータの)素人には読んでも何がなんだ かさっぱりわかりません。その結果、「よくわからないけどまあいいんじゃな いですか」という答えが返ってきて、製作者側はそれを「すべてOK」と解釈し ます。ここがすべてのトラブルの元になることは皆さんよくご存知でしょう。

こうしたトラブルの根源は、コンピュータ用語の羅列である仕様書を、見てわ かるはずもない人にチェックさせることにあるのです。相手にその能力がない 事を知りながら、「ちゃんとチェックしてもらった」と責任を逃れるためだけ にチェックをさせる確信犯だからです。こうした犯罪行為はやめてもっと誠意 ある対応を取りましょう。つまり、「相手にわかるように書く」ということで あり、「相手がわからないような事は書かない」ということです。これがつま りコンピュータの言葉は一切使わずに対象世界のみを記述するということあり、 アプリケーションドメイン分析なのです。

アプリケーションドメイン分析を専門家に正しく確認してもらえたら、あとの 責任はすべて製作者のあなたにあります。もし「こんなフォームは現場では使 いにくい」という話になったら、その責任は使いにくいフォームを設計したあ なたにあります。そのソフトウェアが現場でどう使われるかはアプリケーショ ン分析でわかっているはずですから。こんな場合、「この仕様書でOKを出した はずなのに今さらそんな事を言うなよなぁ」とぶつぶつ文句を言っていません でしたか？この原因はあなたが「現場でどう使われるか」を質問しなかったこ とにあります。そしてどう使われるかわからないまま使いにくいフォームを設 計したことにあります。そしてこれを疑問に思わなかったあなたの責任です。

第一に先生を敬いましょう。そして先生が読んでわからない答案は先生の読み 方が悪いのではなくあなたの書き方が悪いのです。最後にあなたはコンピュー タの専門家なんですから、自分の仕事には自信と責任を持ちましょう。

採点してもらえる仕様書の書き方

さて、ここでは依頼主に採点してもらえる仕様書の書き方のコツをお話ししま しょう。コツはただ一つ、「バツをつけてもらえるように書く」というのもの です。

そもそも何のために採点してもらうのでしょう？100点をもらうためですか？ いえ、そうではありません。自分の間違いを見つけて直してもらうためです。 100点をもらえる仕様書を書くのは簡単です。よくわからない所をあいまいに ぼかして、全体を難解で読みにくくすればいいのです。そうすれば「なんだか よくわからないけど、明らかに間違っているという場所は見つからないよ」 と100点をもらえるでしょう。しかしそれでは意味がありません。むしろバツ をつけてもらうことにこそ意味があるのです。

書いていてよくわからないと思ったらもちろん先生に聞くのが一番ですが、多 くの場合それが頻繁にできません。その場合は勝手に決めつけて断定的に書き ましょう。その点をぼかしたり書かなかったりするのは一番良くないことです。 間違いが書いてあれば指摘するのは簡単ですが、何も書いてない事を指摘する のは難しいのです。

間違いを書く事を恐れてはいけません。とにかく自分が知っている事、勝手に 思い込んでいる事をすべて書きましょう。アプリケーションドメイン分析の理 想は「お前はこんな当たり前の事を何でわざわざ書いてくるんだ」と言われる 事です。そしてその次にいいのは「お前はこんな事も知らないのか」と言われ る事です。「なんだかよくわからないけどすごい」と言われるのは最低の仕様 書です。