本を読む (P217) †
要約 †
- モデルの概念を探す際には、その分野で明白であると考えられている概念を見過ごしてはならない。ほとんどの分野に存在する、基本的な概念や伝統的な知恵を記した書籍を読むことで、対象分野についてよりよく考えられた状態で協業をはじめられるかもしれない。
- 例：本で興味をひきつける
- 前回と同様の例だが、今回はドメインエキスパートが忙しく、ソフトウェア開発にあまり注意を払ってくれないため、セッションで欠けている概念を探し出すことができない。
- かわりに会計の専門書を読むことで、うまく定義された概念のセットを見つけられる。開発者にとって特に有用だった概念は以下のようなものだ。
- 発生主義会計：この手法では、「収入」は、支払いがあったかどうかに関わらず、経済事象が発生した時点で認識（記録）する。すべての「支出」も同様に、実際に支払ったかどうかに関わらず、その責務を負った時点で計上される。税金を含むすべての支払い義務は、支出として計上される。
- 開発者はもはや「会計」の概念を一から作り上げる必要はなく、他の開発者とブレーンストーミングして図9.9のようなモデルを作り上げた。
- 開発者には、「資産」が「収入」のGeneratorであるという洞察はないため「Calculators」は依然として存在しているし、「元帳」という概念はドメインレイヤではなくアプリケーションレイヤに属している。しかし、収入の「発生」と「支払い」は分離できているし、「発生(accrual)」という語をモデルとユビキタス言語に導入できている。
- ドメインエキスパートにドメイン知識への興味を印象づけ、またより良い質問を用意することで、エキスパートが開発者の言うことに耳を傾け、開発者の質問に答えるよう特別に労力を払ってくれるようにできた。
- ドメインエキスパートのサポートが十分にある場合でも、書籍を読んで対象分野の理論の大枠をつかむことには価値がある。大抵の分野では金融ほど明確なモデルは存在しないが、それでもビジネスプラクティスについて要約し、体系化してくれるような人物はいるものである。
- そのドメインで仕事をした他のソフトウェア開発者の著作を読むことも有用。例えば、「アナリシスパターン」の第6章では、開発者にまったく異なる洞察を与えてくれる。出来合いの解決策が得られるわけではないが、自身の経験を積むにあたっての開始地点をいくつか示してくれるだろう。11章「アナリシスパターンを適用する」では、この部分についてより深く掘り下げる。
担当者のつぶやき †
みんなの突っ込み †
- 「本を読め」っていうのは、なんか身も蓋もない感じですね。ここを読んだときは、笑いました・・・ -- 佐藤?
- 勉強会の時、佐藤さんの突っ込み読むの忘れてましたorz -- 渡邉?
- 自分は逆にすっきりしましたよ（笑 ＜本を読め -- 渡邉?
