業務がめちゃくちゃ忙しい最中だったが、あしたの現場で役立つ「システム設計の原則」と「越境」のはじめかた - DevLOVE | Doorkeeper に行ってきましたのでメモ
発表メモ
上のスライドベースで 現場で役立つシステム設計の原則 の著者 増田さんと カイゼンジャーニーの著者 市谷さん、新井さんの対談形式だったので アジェンダごとに各著者の方々のコメントをさらっとまとめています。
双方から見た本の感想
増田さんから見た「カイゼンジャーニー」
- 自分が見てきたことがマイルドに再現された感じ
市谷さん、新井さんから見た「現場で役立つシステム設計の原則」
- 新井さんとしては「増田さんが語りかけてくる」そんな本
- 市谷さんとしては、今の時代にフィットさせたオブジェクト指向を読み解くための本
何故この本を書いたのか、書いてみてどんな変化が起きたか
「現場で役立つシステム設計の原則」増田さん
- Javaの入門書とDDDの間の本がないということで企画が持ち上がり、その折に自身の考えをまとめてもいいかなという観点で書き始めた
- 変化としては周りの反応が多く、自身の周りでしか得られなかったフィードバックがネットなどを通して得られたのが大きかった
「カイゼンジャーニー」市谷さん、新井さん
- 仕事を「自分事」として考えてやってもらう人が増やしていきたいという思いで書いた。
- 執筆後のフィードバックとしてみんながやっているだろうと削ろうとおもっていた「振り返り」のあたりが書いてくれてありがとうというフィードバックがあったりと気づきがおおかった
執筆の裏側
「現場で役立つシステム設計の原則」増田さん
- 書き始めてからかなりの時間が経過してしまった
- ただ言語化することはとてもいいことだということに気づきがあった。なかでも最初のプレビュー版で知り合いにレビューしてもらう過程でいろいろな忌憚のない意見がもらえて、すごく勉強になった部分があった
「カイゼンジャーニー」市谷さん、新井さん
- 同じく言語化するということはとてもいいことだと感じた
- 2017年11月に新たなスクラムガイドができたが、作成にあたり読み返したりした際に原文と翻訳でいろいろな解釈があるなと再認識できて学びがあった
それぞれの本で最も言いたいことは何か
「現場で役立つシステム設計の原則」増田さん
- コードを書こう、良いコードを書こう
- 良いコードを書くためには設計スキルが必要だし、そのためには分析のスキルが必要となるのでドメインに興味を持つが大事
「カイゼンジャーニー」市谷さん、新井さん
- 受け身で仕事すると辛くなってくるので、やはり自分ごととして働く人が増えてほしい。そういうものの取っ掛かりになれば。（新井さん）
- 上手く行かない人、良くない場所などいろいろな関係性の中で開発することはある。その中で色々と選択肢を選ぶことになるが、その選択肢幅を広げてほしいという意図で作った。（市谷さん）
どんな問題を扱うのか、問題の根幹・本質を見定める方法、問題解決のアプローチ方法
「現場で役立つシステム設計の原則」増田さん
- 問題意識は冒頭に書いたとおり、変更しにくいコードを作らないためにどうしたらいいか。
- 基本のアプローチは入出力の処理とビジネスルールの計算をどうやって分離するかという部分。
- 本の中ではビジネスロジックの作り方に焦点を当てている。
「カイゼンジャーニー」市谷さん、新井さん
- 人にまつわる問題を解決するためにフォーカスを当てた本、どうすれば人にまつわる問題を解決できるか。
- 両方の書籍に言えることだが、暗黙知の露出、開発側とそうではない部分にある暗黙知を露出させて共有することがドメインの成長につながる
何を学ぶのか、学び方のコツ、教えた方のコツ
「現場で役立つシステム設計の原則」増田さん
- コードやプログラムを動かすこと、テクニカルな技術に興味があるのは大前提のはずなので、その動かすプログラムの内容を知るべき。
- その内容とはすなわち業務内容なので、もっと業務内容に関して興味を持ち、ロジカルのようでロジカルでない業務ロジックを見つめていく。
「カイゼンジャーニー」市谷さん、新井さん
- カイゼンジャーニーは何故ジャーニーかというと、当事者が成長していくことを描きたかった。一足飛びでは成長できない、土台を積み重ねていくからことたどり着ける。適当ではなく、計画的にそれらをやっていかないとうまくいかない。
- 経験則というのは重要、怖がらずにやってみる
どのように始めるといいか
「現場で役立つシステム設計の原則」増田さん
- 自分がやる気になればできることなんて実は山ほどある。はじめてみて三日坊主みたいに挫折することもあるけどネガティブに捉えずまた気が向いたら始めればいい、そうやって続けていくことが大事。
「カイゼンジャーニー」市谷さん、新井さん
- 自身のタスクの見える化、分解、前工程と後工程を見ていくなど自分の範囲でやっていく。それがうまくできたら徐々に広げていく。
- 自分がこうしたいと描く妄想は大事、それを持ちながら行動していくことでいつか上手く周り始めることがくる
大喜利（質問コーナーパート）
Q.DDDを行うにはプログラマとビジネスの人達との相互理解、協働が必要と思います。とはいえバックグラウンドや経験が全く違うので大きなギャップがあるのも事実です。そのギャップを埋めるために先ずは何から手を付ければ良いでしょうか？
- ドメインエキスパートも普通の人間なんで、相手の言うことはヒントとしてとらえ、ドメインエキスパートに過度な要求はしない
- このまま歩み寄れないと気づいたときはどちらかが埋めるしかない、相互理解をして初めてプロダクトを作り上げる足並みが揃うのでそれを大事にする
- 業務の言葉がわからない、認識がずれているというセンサーは大事。ズレているんじゃないかセンサーはマックスにあげて、違和感をすぐに察知していくことが重要
Q.増田さんの本では型を定義してそれを使うことを推奨されていたと記憶しています。個人的には好きな方法ですがプロジェクトのORMと合わなかったりで断念することが多いので、折衷案があれば・・・
- フレームワークを変えろ！
- モデルとドメインオブジェクトとDBのレイヤを分けることに執着してほしい
- ドメインオブジェクトとテーブルとのダイレクトなマッピングはしない
- 処理的にはオーバーヘッドだけど、やるだけの価値はある
Q.システム設計の原則にすべて従って開発したらクラスとテーブルの数がえらいことになると思うのだが非正規化をどうされてますか
- 経験上おかしくならない、ただビジネスルールはミスリードすると起きうる
- 関心事ごとにテーブルわけるとすっきりする
- 事実の記録は正規化するが、集約したデータ用のテーブルをつくる事実の設計と集計は別の切り口を使うと良い
Q.お三方の経験として、人の問題とコードの問題が同時に起きていて大変だったと言うことはありますか？そういうときにどういうアプローチをとって解決されたのか気になります。
- 人の問題って体力と精神力を使う。疲れることもある。
- 仲間と人担当とシステム担当など、軸足を変えるような担当分けをするのも良い。
- コードもチームの問題もぐちゃぐちゃになったものを全部改修するのは無理。手がつけられそうなところから少しずつやる
Q.ドメインモデルの綺麗さと、パフォーマンスとの兼ね合いが悩ましい
- 業務的に正しく表現できてればパフォーマンスが出るのではない
- コードをチューニングするよりもハードで殴る
- どういう設計でどういうパフォーマンス条件の時に問題がでるかは興味範囲
全体を通しての感想
- ドメイン駆動のスライドを漁るようになってから増田さんのお名前を拝見するようになり、「現場で役立つシステム設計の原則」を読んで自分の中でのちょっとしたパラダイムシフトが起きたぐらい感銘を受けた本の一つなので、今日も姿勢という観点で参考になる部分が多かった。
- 「現場で役立つシステム設計の原則」はコードに対して、「カイゼンジャーニー」は人に対してシステム開発を行う経験則やアプローチを語ったものであり、どちらも『自分の手の届く範囲から変えていき、そこで成功体験を得たら隣人に、チームに、組織に広げていく』ということを薦めている話なんだなという感じなんだなと思った。
- 今日の話のエッセンスを日頃の開発業務に転換していきたいなと思った。
- カイゼンジャーニーには未読なのでポチった。
関連リンク
- ラーニング・パターン (Learning Patterns) - おそらく対談で紹介されていた「学習パターン」
