Takuma510顧客と言語を共有する
現在取り組んでいる受託開発案件で顧客への仕様の説明の際，積極的にシステムの概念モデルから演算できるよう意識した。
概念図を書き，このようなモデルで設計しているので，その帰結として仕様はこうなります。それ故，このようなケースではこのように動作します。といった具合である。個人的には全てのケースの動作を文章化し，それぞれ並び立てるより断然システムに関する正しい理解の仕方であると思っている。なぜなら全てのケースを文章化しても顧客はそんなもの読み込まないし，理解しずらいからだ。
そこでの概念図で用いる言葉はなるべくシステムコードで用いられている言葉の定義と合わせて記載した。顧客と言語を共有するためだ。
言語を共有するメリット
顧客と開発エンジニアの言語を統一すると様々なメリットがある。
- 顧客のシステムに関する理解が深くなる。
- 顧客がシステムの思想からはずれた無茶な要求を出さなくなる。
- 顧客と仕様についての議論がしやすくなる。
- 要件実現の為仕様変更によるメリット，デメリット，リスクがお互いにわかりやすくなる。
実際，追加要件の話をする際に，そのように意識して作った概念図を顧客が理解し，概念図の言葉を使って議論ができたことは収穫であった。
必要条件
当然ながらこのようなやり方が意味をもつようにするには顧客がシステムに対して積極的に関わらなくてはうまくいかない。これはコントローラブルではないのが悩ましい。
また，顧客に対する要件だけでなく，システムも当然ドメインモデルという概念を念頭に設計されていなくてはならない。そうでないと，話している内容と実装が矛盾を生じてしまい共通言語が全く意味をなさなくなってしまう。
おわりに
このような概念はEvans先生のDDD本で学んだ。この本では具体例と共に上記のような内容が記載されている。
