「現場で役立つシステム設計の原則」読書会 vol.4

第4回の感想です。前回はこちら。

patorash.hatenablog.com

記事の投稿日付は連続になってますが、読書会自体は週に1度の開催です。

会社のテックブログのレポートはこちら。

4章ドメインモデルの考え方で設計する

要件定義のタイミングで色々と質問をしてドメインモデルを設計する上でのヒントを聞き出すことが大事だなと思った。
ドメインモデルの作り方。やはり全体と部分を行ったり来たりしながら徐々に洗練させていくものだよなぁと改めて思った。設計通りにはうまくいかないことが多い。業務フローをまとめて、そこから俯瞰して何が重要そうかを見つけていく。
ドメインモデルは独立した部品でなければならない。部品同士を組み合わせていくのはいい。
業務の関心事は、ヒト／モノ／コトで整理できるとあった。これは楽々ERDレッスンに書いてあったことに通じるなと思った。楽々ERDレッスンではリソースとイベントとなっていたが、まずイベントを洗い出せという話だったかと思う。この本でも、コトを整理の軸とする、とまとめに書いてある。ついついヒト／モノのリソースだけに注目してDB設計しがちなので、そこは気を付けるポイントとなるだろうなと思った。
業務ロジックにもパターンがある。パターンを認識しておくと、応用が効く。たしかに、大体がこの4パターンかなと思う。
業務を表現するのがドメインモデルなので、名前がより具体的になっていく。そのため、どこに何が定義されているのかを探しやすい。抽象度を高めることが汎用的なプログラミングには大事だけれど、ドメインモデルについては全くの逆。暗黙知を明らかにしていくという役割を担っているということか。暗黙知の言葉が、クラス名やメソッド名になっていくとわかりやすいコードになりそう。
開発者が業務の用語を正しく理解して使うことが重要。そうすれば、ドメインモデルが作りやすくなる。
関係をわかりやすく図で表現してあると全体を俯瞰しやすい。UMLで表現できるものばかり。
その業務分野について興味をもって学ぶというのが大事。プログラムだけ上手くなろうとしても片手落ちで、我々は業務知識を学ばなければならない。会計ソフトを作っている会社のエンジニアが簿記の資格をとったりする話もある。自分の場合は、弊社の社長や営業さん達がお客さんとの会話で得られたものを定例会の時に教えてくれたりしたので、それがよかった。客先にいって質問する機会も何度かあったが、その時にも、どういうところを重視しているのか？などを質問できて学べることがあった。会話能力が基本スキル、というのはそうだろうなと思う。
ある意味、ズケズケと聞いて認識を合わせていくようにしないと、全然違った時のリカバリが難しい。プログラムだけならまだしも、信用が落ちる可能性もある。なんで聞かなかったの？とか、なんで確認しなかったの？とか。
ドメインモデルの設計とは、より良い回答を探し続けること。改善し続けること。
やはり終わりはない。常にリファクタリングし続けていく必要がある。プログラムもだけれど、自分自身も学び続けなければならないんだなぁと改めて思った。

雑感

ドメイン知識を付けながら、プログラム能力も上げていかなければならないので、テクニックだけに絞って勉強しててもいかんよねという話をしたり、コミュニケーション能力大事だよねっていう話をしたりしてました。現在の開発メンバーは、わりかし大人しい人が多く、あまり質問しなかったりするので、会話を引き出すためのキッカケを作る練習とかはしたほうがいいんじゃないか？って話したかなと思います。

例えば、感想のところに書いた「営業さん達がお客さんとの会話で得られたものを定例会の時に教えてくれた」という話1つとっても、営業さん達が能動的に開発チームにフィードバックをくれるわけではありません。もう議題がないかなというあたりで「そういえばこの前、操作説明会をされてたと思うんですが、お客さんの反応ってどうでした？」とか、「この前追加した機能について、お客さんから何か反応ありましたか？」とか、聞いてみるわけです。そうすると、「あー、あれは喜ばれてましたよ」と言ってもらえたりするので。

ネガティブフィードバックはこちらから言わなくても言ってもらえるんですが、ポジティブフィードバックはなかなか聞けなかったりするので、こちらから聞いていく姿勢も大事です。

「要件定義に関しては、どういうふうに要件を聞き出していけばいいんでしょうか？」という相談があったので、チェックシートを作っておくといいんじゃないか？という話をしたり。お客さんにチェックシートを記入してもらうわけではなく、こちらが質問したかどうかのチェックシートとして活用すると、抜け漏れを防げるんじゃないかな？会話の糸口にもなるんじゃないかな？と。

日々勉強して、リファクタリングを繰り返しながら正解に近づけていくのが王道だなと、改めて思いました。