DDDの思い出２つ

年度末になると宿題の駆け込み・年末の道路工事と同じく急な案件見積もりや技術調査依頼なんてのが入るもんで、すっかりまいっておりました。

こういうのももうちょい計画的にやってくれたら楽なのに。。。

上記のエントリ見て２つほど思い出したことがあったので。

ドメインを甘く見てはいけない

仕事をやっていると、外部公演や外部研修といった場で他企業でエンジニアやマネージャやっていた講師の話を聞くことがあります。

で、その場で出た話。

講師「まず、プロジェクトを進めるためには、プロジェクトマネジメントやアーキテクチャ、プログラミングと言った開発能力が必要となります。」

当方「それらが必要なことは理解しておりますが、業務知識・ドメイン知識はより重要ではないのですか？」

講師「業務知識はユーザがもてば良いもので、開発者はそこまで重視しなくても大丈夫です」

この話。ずーっとモヤモヤしてたのですよね。

なんだかんだ言って顧客の作りたいもの理解しなければ、顧客に提供しようとしているものをイメージできなければ、たとえどんなに円滑にプロジェクトが進もうと、開発ができても顧客満足度を上げられず失敗になるんじゃないの？って。

この講師の方は、オッサンの会社のライバル会社出身の方で、超大手に分類される方でした。

実はその方の出身の会社って、ここ数年顧客と「求められるシステムを作れない」なんて大騒ぎになってちょくちょく話題になったりしてたんですよね。

※表現はぼかします。

ただまあ、こういう話を思い出すと、海外でDDDが話題となった理由も何となく分かるかなあ。

今思えばやっぱりなって感じなんですけど、ドメインや業務知識といった能力はシステム開発のベースになるんだし、それを無視したら行けないだろって思うんですよ。

以前、DDDの話を最初に聞いた時にそんな感想を持った次第でした。

ドメイン・エキスパートとソフトウェア開発者は一体とするべきか

元記事だと一体化するべき、という意見なんですけど、個人の経験的には分離したほうがよい、って思うんですよね。

最大の理由は、「ドメインモデルの難易度と、ソフトウェア開発の難易度に相関があまり見られない」から。

つまり、複雑で解決困難なドメインモデルがあったとしても、実際のソフトウェアを作成する際には、案外簡単なものとなっていることがよくある話。

逆に、ドメインとしてはカンタンなものでも、実際にソフトウェアをつくろうとした場合に非常に苦労するようなこともある。

※非機能要件がらみの開発物とか。

となれば、優秀なプログラマ・ソフトウェア開発者をドメインモデルのタスクに割り当てて時間を消費することは、ときとしてもったいないことだったりするので、適材適所で上手く役割分担をしたほうが良いって感じたりもするんですよね。

プログラミングのスキルを鍛えるのにパワーが必要になるように、ドメインを理解し定義できるようにするにもパワーがいる話なので、理想的には両方の能力を鍛えることとはいえ、どちらかにならざるのは仕方ない部分もあるんじゃないのかな。

なので、その現実を直視し、

ドメインモデルが、開発者とドメイン知識をもつ人（ユーザ、専門家等）との間の共通言語となるようにする

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場

ってのがDDDの基本的な思想なんだろうなって思うわけです。

DDDの話に触れた際に、チームとして頑張りましょうってことなのかな、なんて考えたことをふと思い出しました。

まとめ

まあ、ざっくりと書いたのですが、結局言いたいこととしてはドメインの重要さを軽視せず、また重く見過ぎず、上手く付き合えるようにしたら良いんじゃないかなと思います。

いつもどおり、バランスが大事ってことですかね。

以上

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)