« データモデルの静と動 | トップページ | 新人技術者にはOOPLの前にDSLを »

2015.02.28

「ドメイン・エキスパート」になろう

 20年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。

 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。

 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD(ドメイン駆動設計)で言うところの、開発されるソフトウエアの適用分野(ドメイン)に関する専門家のことをいう。「ドメイン」の具体例としては、「業務システム」、「ゲームソフト」、「組み込みソフト」、「ECサイト」などいろいろな例が挙げられる。

 ドメインの「広がり」をどう想定するかは重要である。たとえば、販売管理システムや生産管理システム等を広く含める「業務システム」をぐっと狭めて、「輸入管理システム」くらいにしてみたらどうだろう。そんなドメインの専門性が成立しないわけではないだろうが、どうもあてにならない。なぜなら業務システムというものは、業務システムであるゆえのさまざまな共通パターンを持つからだ。何かのきっかけで輸入管理システムがわかった気になったとしても、業務システム一般に通じていないのであれば、その人物が気の利いた輸入管理システムを生み出せるとは思えない。

 とは言うものの、システム開発を通じて特定業務に詳しくなったなら、業務システム一般の専門家になることはそれほど難しいことではない。そもそも、特定業務の世界に閉じこもっていれば、扱える案件が限られてしまう。開発スキルとともに営業効果を高めるためにも、ドメインの拡張が求められる。ようするに、学習コストと営業効果の兼ね合いでドメインの粒度は自然に決まるということだ。

 さて、「ドメイン・エキスパートと開発者とが協働するための開発手法」としてDDDは説明されるが、業務システムのように複雑なソフトウエアを相手にするのであれば、開発者自身がドメイン・エキスパートでなければうまくいかないだろう。少なくとも、「ドメインに関する知見は別の誰かが補完してくれるから、開発者自身がドメイン・エキスパートである必要はない」といったメッセージをDDDから受け取るべきではない。

 なぜか。私は自分を「業務システムのエキスパート」と規定しているが、じっさいのところ、開発のさまざまな局面でこの専門性にもとづく知見を援用している。ユーザや管理者の語りでさえ、仕様を見定めるために参考にする手がかりのごく一部でしかない。つまり、エキスパートとしての膨大な知見を自ら補完することなしには、モデリングも実装もできないというのが現実なのだ。このドメインではそうだという話だが、他のドメインでも状況は似たり寄ったりではないだろうか。

 だから、「英語できます」や「プログラミングできます」で満足してはいけない。それらの技能を生かすためには、技能の価値を社会化するための別の専門性が要る。我々は何よりも、それぞれの相場観や適性にもとづいて「自分のドメイン」を見定め深めることを怠ってはいけない。

|

« データモデルの静と動 | トップページ | 新人技術者にはOOPLの前にDSLを »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「ドメイン・エキスパート」になろう:

« データモデルの静と動 | トップページ | 新人技術者にはOOPLの前にDSLを »