CEOが愛した_ドメイン駆動設計.pdf

Transcript

1. CEO：松原舜也
   CEOが愛した
   ドメイン駆動設計
   

   View Slide

2. 自己紹介
   香港、英国、ドイツで 13年を過ごす。
   新卒時代はバイクエンジニア兼テストライダーとして
   命がけで日々テストサーキットを疾走。
   まだ生きたくてリクルートに転職。
   新規事業企画とエンジニアリングを学ぶ。
   「モノづくりが好きな人が、
   　モノづくりを純粋に楽しめる環境」
   を作るため、2018年末にPrAha Inc.を設立。
   （エンジニア採用中だよ！）
   Twitter: @dowanna6
   （最近一番うまく描けた絵）
   

   View Slide

3. PrAha Inc.のスローガン
   「失速しない開発組織」
   止まるんじゃねぇぞ...
   

   View Slide

4. 弊社の開発を
   失速させている要因は
   いねがー
   

   View Slide

5. うそっ、
   私のレビューコメント
   多すぎ...？
   

   View Slide

6. 「失速してるかも？」
   俺が遅い?
   俺がスロウリィ!?
   速さが足りないっ!!
   

   View Slide

7. WHAT：コードで実現していることが間違ってる！
   - 例：ボタンを実装し忘れてるよ！
   HOW：コードの書き方が間違ってる！
   - 例：Promise.allしたほうがいいよ！
   WHERE：コードを書く場所が間違ってる！
   - 例：これはRepository層に書くべきじゃないよ！
   - 例：これは別のClassとして切り出したほうがいいよ！
   - 例：これはPubSubに任せたほうがいいよ！
   - 例：これはマイクロサービスとしてCloud Functionsに切り分けたほうがいいよ！
   - 例：ここはEntityじゃなくてValueObjectとして切り分けておいたほうがいいよ！
   レビューコメントは3種類に分類できた
   弊社のPRコメントは
   6~7割がWHERE
   に関する指摘だった
   

   View Slide

8. WHAT：何をコードで実現するのか？
   - 例：ボタンを実装し忘れてるよ！　-> 直さなきゃ動かない -> よし直そう
   HOW：どうコードを書くのか？
   - 例：Promise.allしたほうがいいよ！ -> すぐ直せる -> よし直そう
   WHAT, HOWは揉めない
   車もねぇ！
   ラジオもねぇ！
   

   View Slide

9. 直さなくても動いてるのに・・・問題が起きてから直せばいいのでは・・・？
   （急いで対応する必要がないため、優先度が下がる）
   ええー、今から変更するの大変なんだけど・・・
   （テストの書き方、DIの仕方など変更箇所が増えて、工数がかかりやすい）
   本当にこれで合っているのか、自信がない・・・
   （アーキテクト経験、丁寧な設計で実装経験を積んだエンジニアは希少なので、
   その書き方で正しい確証が持てず、直しづらい）
   WHEREに対する指摘は揉めやすい
   

   View Slide

10. 優先度が低い
    工数がかかる
    直しづらい
    WHEREに対する指摘は揉めやすい
    

    View Slide

11. WHERE　に対する指摘を減らせれば
    失速しない開発組織になるのでは！？
    

    View Slide

12. アーキテクチャを固めてしまえば
    WHERE で揉めなくなるのでは！？
    

    View Slide

13. エヴァンス先生！
    

    View Slide

14. ほぼみんなエヴァンス本は読んでるし、楽勝やろ
    

    View Slide

15. そんなことはなかった
    

    View Slide

16. ・あれ、一つのエンドポイントから呼ぶ usecaseって1つだけ？それとも複数もアリ？
    ・集約をまたぐ時のトランザクションって分かれていいんだっけ？
    細かいところで認識が合わない
    

    View Slide

17. ・あれ、一つのエンドポイントから呼ぶ usecaseって1つだけ？それとも複数もアリ？
    ・集約をまたぐ時のトランザクションって分かれていいんだっけ？
    ・あれ、DB保存後に返すのって DTOだっけ？Entityだっけ？
    ・QueryServiceってEntityを返すんだっけ？
    ・DB内の重複確認メソッドって、 entityに書いて良いんだっけ？
    細かいところで認識が全然合わない
    

    View Slide

18. 「知っている」と「できる」は違う
    

    View Slide

19. ・ハンズオン勉強会
    ・PR道場
    ・可視化、明文化
    対策
    

    View Slide

20. ・毎週木曜日に2時間ぐらいかけて、DDDの勉強会を始めた
    ・自社サービスをDDDに基づいてリファクタリングし始めた
    ・「ハンズオン」でなければ、定着しない
    ハンズオン勉強会
    

    View Slide

21. ・PRでWHEREに関する指摘を受けたら、
    　チャットで議論せず、「PR道場」（と言う名の spreadsheet）
    にストックして、ひとまずマージする
    ・週1日、全員で一緒にPRに目を通し、全員で議論する（初回は2時間ぐらいかかった）
    ・議論した後に、初めてWHEREに関する指摘に対応する
    なぜこうしたのか？
    ・アーキテクチャは開発者全員の意識が揃っていないと効果が薄い
    ・例：5人のうち2人しか理解していないと
    　　・指摘が増えるだけ
    　　・理解していない 3人がお互いに指摘し合うと、余計に混乱する
    ・なので全員で一斉に勉強して、同じレベルに早く到達することにこだわった
    PR道場
    

    View Slide

22. 可視化
    ・各々が異なるイメージを持っていると、
    　いつまでも認識が揃わない
    ・現時点のアーキテクチャと、
    　あるべきDDDの姿を比較して
    　何をどこに移動すれば良いのか
    　可視化してみた
    ・これを基に議論すれば、
    　もう迷わない！
    

    View Slide

23. 明文化
    ・マークダウンで指摘点を
    　記載して、VuePressで
    　簡易的なドキュメントサイトを
    　社内限定公開した
    ・誰かが過去に聞いた質問は、
    　ここを見れば分かる！
    

    View Slide

24. ・ハンズオン勉強会
    ・PR道場
    ・可視化、明文化
    対策
    

    View Slide

25. ・モブプログラミング
    　・「違う！そこはDomain層にinterfaceを書かなきゃ！」
    　・「そこはQueryServiceだよ！」
    　・と野次建設的な意見が飛び交い、細部を議論することで認識が揃う
    ・GitHubのPRコメントを自動連携、ドキュメント化するサービスを開発
    　・誰かが答えた質問が何度も聞かれないようにする
    　・社内で試験運用中。上手くいったらサービス化したい...
    （その他に有効だった）対策
    

    View Slide

26. 効果
    

    View Slide

27. なんということでしょう
    実装スピードが格段に上がった
    コメントだらけだった
    レビューはスッキリ
    コメントではなく、
    実装に集中できるように
    コメントではなく、
    実装に集中できるように
    

    View Slide

28. BEFORE
    「責務が曖昧になって低凝集になってしまうのと、
    　今後変更に耐えられるよう、
    　インフラの実装に直接依存するのではなく、
    　同じ階層の抽象を経由するようにしたいです。
    　なのでこちらは同じ階層のどこかにインターフェースを定義して、
    　実装は別のファイルにおくのが良いのではないでしょうか。
    　階層が特に決まっているわけではないのですが、
    　一つ上の階層に新しく別の階層を用意しましょう。
    　DBとやり取りをするのはここの階層だけです。」
    「えっと、すみません、インターフェースを定義する理由が・・・」
    「これは依存性の逆転と言いまして・・・」
    「どうしてそれが必要なんでしょう」
    「この階層の依存関係を、同じ階層に留めておきたくて」
    「どうしてこの階層だけ？他の階層は同じ階層間に留めなくて良いのですか？」
    「・・・あっ、大丈夫です。あとで僕が直しておきます。マージしちゃってください
    ^ ^」
    「ヒィ」
    AFTER
    インターフェースはEntityに、
    実装はRepositoryに書きましょう。
    コミュニケーションのスピードが格段に上がった
    開発チームにも
    ユビキタス言語が！
    

    View Slide

29. コミュニケーションのスピードが格段に上がった
    （大体の）IT企業で一番高いコストは人件費
    社員が8時間働いて生み出す価値を最大化すること
    が経営者の役割
    コミュニケーションコストを減らすことは
    ここに直結する
    

    View Slide

30. 新規参画者が、すぐ活躍できる
    ・どこに何が書いてあるか、すぐわかる
    ・「バイブルを読んでおいてね」
    　で共通認識が取れる
    

    View Slide

31. 新規参画者が、すぐ活躍できる
    （大体の）IT企業で一番高いコストは人件費
    ・新しく入った人がすぐに活躍する
    ・既存メンバーが、育成ではなく開発に集中できる
    シャチョウサン、
    ウレシイ！
    

    View Slide

32. ・開発スピード
    ・コミュニケーションスピード
    ・育成スピード
    効果
    DDDを取り入れた組織は、全てが
    通常の3倍
    

    View Slide

33. ・ヒアリング能力が改善
    ・チームとしての一体感が生まれる
    ・負債を可視化できるように
    （予想外の）効果
    

    View Slide

34. ・どうモデリングしよう、をまず考えるクセがつく
    ・「一度のヒアリングで意図を正確に汲み、
    　　ソフトウェアとして表現してくれるエンジニア」
    　　はクライアントから強く信頼される
    ・また、高いヒアリング能力はエンジニアの身を守る
    ・開発が進んでから「あ、実はこんな仕様があって」は、一番困る
    ・手戻りしやすい「モデル」を先に固める癖は、とても有益
    ヒアリング能力が改善
    今日、一番話したかった
    のはコレ！！！
    

    View Slide

35. ・ヒアリング能力 != 「流暢に話す技術」
    ・ヒアリング能力 = 「ソフトウェアで実現できる事実を聞き出す技術」
    ・「あれ？このドメインルールって必要なんでしたっけ？」
    ・「どうしてこんなルールがあるんでしょう？」
    ・暗黙の了解を「ルール」として浮き彫りにすることで、
    　深掘りのキッカケが生まれる
    ・「聴く力」が求められるクライアントプロジェクトと相性⭕
    ヒアリング能力が改善
    

    View Slide

36. 弊社の理念に近い DDDを用いて、
    ソフトウェア開発者と企画者が
    一緒に考えながら、物作りを進める
    ピッタリやんけ！！！
    

    View Slide

37. ・リモート輪読会の習慣が定着
    ・技術者として一番の喜びは「新しいことを学び、活かせる環境」
    ・チームとしての一体感が生まれる
    これに少し近づけて良かった
    

    View Slide

38. 負債を可視化できるように
    ・コロナ騒動で外出できず、暇だったので
    ファイル1つあたりのコメント数を
    可視化してみた
    ・意味を持ったディレクトリの
    切り方をすることで
    「どこが、なぜ混乱を生んでいるか」
    見つけやすくなった
    Repository層の扱いに関して
    まだチーム内で合意が取れていないようですねぇ
    

    View Slide

39. ・ヒアリング能力が改善
    ・チームとしての一体感が生まれる
    ・負債を可視化できるように
    （予想外の）効果
    

    View Slide

40. 総括
    ・DDDはCEOから見ても素晴らしいことだらけ。愛してるー！
    ・一方、普及には壁が
    　・「実践ドメイン駆動」を読むだけでは難しい。文字通り「実践」しないと身につかない
    　・DDDに詳しい人がチームに必要。居ないと「これで正しいのかなぁ...」と足踏みしてしまう
    　・「全員」が習熟しないと効果が薄いため、チーム全員の学習意欲に左右される
    ・効果的な勉強法：勉強会、具体的な実装例が豊富な本、ライブコーディング
    　全部が揃っている#dddcj、凄い
    ・もしDDD導入、リファクタリングに躊躇っている経営者が居たら、めっちゃ早口で説得します
    

    View Slide

41. あじゃじゃしたー
    Twitter: @dowanna6
    エンジニア採用中！
    https://www.praha-inc.com/
    

    View Slide

42. 質疑応答後の補足
    

    View Slide

43. 負債を可視化できるように（後記）
    質問：
    「コメント数と負債は関係ないのでは？」
    回答：
    弊社にとって「負債」の定義 = 「開発速度を落とすモノ全て」
    ・「セクシーなコードだね」「 LGTM」みたいなコメントであれば関係ないが、
    　　弊社の場合コメントは基本的に実装ミスなどに対する真面目な指摘。問題がなければコメントは書かれない
    ・なのでコメントが多い＝認識が揃っていない、ミスを生みやすい　と考えた
    ・こうした箇所は後々もコメントが増えたり、わけのわからない設計、負債となる確率が高い
    ・未然に負債化を防ぐ意味も込めて、コメントが多すぎるコードは負債として扱った
    

    View Slide

44. 質問：
    DDDで開発すると、書く量が増えてスピード落ちない？
    回答：
    確かに、純粋なコードを書く量は増えます。
    ただ、エンジニアの仕事は「読む」が 6割、「考える」が3割、「書く」が1割ぐらいだと考えています。
    書く量が増えて影響を受けるのは「書く」だけなので、全体の 1割だけです。
    代わりにコードが読みやすくなることで、仕事全体の 6割が改善する。
    こんな風に考えています。
    また、将来的には拡張しやすい（書きやすい）作りになるため
    中長期で見れば書くスピードも DDDを取り入れた方が早いと感じます。
    DDDで開発スピード上がる？（後記）
    

    View Slide

45. 質問：
    認識が揃うのに、どれぐらいかかりましたか？
    回答：
    2ヶ月くらいかかりました。（今でも細かく認識がズレてる時がありますが ...）
    PR道場を始めて全員で認識を揃えにかかったタイミング、
    実際に手を動かして自社サービスをリファクタリングし始めたタイミングで
    一気に全員の認識が揃い始めたように感じます。
    どれぐらい時間かかった？（後記）
    

    View Slide

46. 質問：
    「DDDを導入しようとしたけど、ダメだった」話が多いのですが、
    なぜPrAhaではDDDが定着したのでしょうか？
    回答：
    ・要因は4つかと思います。
    １）DDDに詳しいメンバーが居た（詳しい人が居ないと「これで合ってるのかなぁ ...」と空中分解する）
    ２）全員が勉強好き、技術議論好き（ここは採用面接で最重視している）
    ３）全員で一緒に勉強した（全員の認識が揃わないと、効果が薄い）
    ４）手を動かした（実際に自社サービスをリファクタリングする事で、細部の認識が揃った）
    どうして定着したの？（後記）
    

    View Slide