現場で役立つシステム設計の原則 読書会 に参加してきました。
読書会の第５回目からなのに参加してきました。
読書会は輪読形式。
章の中の小さい章（段落？）を一つの区切りとして
その中の内容で疑問、反論、突っ込み等、議論していく形式。
もちろん、参加者が全員「まぁ、そうだよね」と思ったり、
特に何か議論が発生しそうな内容で無い場合は、議論しない場合もあります。
なので
読む時以外、一切しゃべる事なく人が話しているのを聞いているだけでも大丈夫です。
話を聞いているだけでも
「あ、それ思った。」とか「その視点は面白いな。」とか「あーなるほどね」とか
参加してみたら実感として分かるのでおススメなのですが。
みなさん、色んな事考えながら読んでらっしゃるんだな。というのがわかります。
もし、この本を一人で読んでいる方がいらっしゃるならば
是非、読書会に参加してみてはいかがでしょうか。
自身で読んで体験した事とは別の視点から本を読む事が出来るかと思います。
本の内容的には４章の後半から５章の前半にかけてでした。
４章前半では、ドメインオブジェクトはこうやって作っていくんだよ。
ちょっとでも油断するとすぐにトランザクションスクリプトになっちゃうから
気を付けて、丁寧に設計、開発していかないといけないんだよ。
安易にソースコードにロジックを書くんじゃなく、ドメインを意識してソースコードを書かないといけないんだよ。
的な事が書かれていると思います。
で、後半部分なのですが、そのドメインをどのように育てていくかが書かれているわけなのですが。
読書会でも誰かが言っていましたが「コミュニケーションスキルを磨け」って事が書かれているように見えてですね…。
本当に「ドメイン育てるには、コミュニケーションスキルを磨け」って書いてあるのか？私の思い違いじゃないか？
と思ったのが、この読書会に参加しようと思ったきっかけ。
４章の途中までは、チーム内の共通認識だったり、約束事だったりでドメインオブジェクトは作っていけるな。
とチーム内でも展開しやすい内容だぞ。実践出来そう。と思っていたのですが。
「ドメインの知識を増やすために顧客から業務知識を引き出せ。」
と言われた時に、それが出来るのって、チームか？スクラムマスターの仕事じゃないか？とかチームの共有の情報にするためにどうする？とか
もちろん、製造しているチケットの内容によってはチームが顧客から業務知識を引っ張り出す事は可能かもしれませんが、認識の範囲外の事を引き出すのは難しいんじゃなかろうか。
ワークフローをいかに熟知していたとしても…。
そう思って参加してみたものの
やっぱり「コミュニケーションスキルを磨け」って書いてますよね。
得た知識をドメインに反映せよ。とは書いているものの。
どうやってチームに展開するかとかは書かれてない。ドメインというものは複数人で育てていったとしても、上手にスケールアップしていかないといけないわけで。チーム内でどうやって育てていくか。レビュー以外の場で得た暗黙知をどうやって伝えるか。
ウォータフォールにしろ、アジャイルにしろその辺が課題かなぁ。とか思ってました。
揚げ足取りに近いんですけど。
どうしても、気になって気になって夜も眠れず、これのためだけにブログを更新しようと思ったんですけど。
「業務に習熟した人」と「業務の経験者」と「業務の専門家」
という、意味的に似たり寄ったりな単語が複数使われており、多分文脈的に同じ人を指しているんだろうけど、ここで表現方法が揺れるのはどうなんだろう？もしかして、これは意図的に変えてるのかな？
とか、ちょっと勘繰りが入ったりするので、そういうところは読みにくいかな。と思いました。が、これは私が細かいだけだと思います！！！
