DDDを実践できるエンジニアを育成するための取り組みについて
•
8 likes•16,745 views
https://ddd-alliance.connpass.com/event/100397/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DDDを実践できるエンジニアを育成するための取り組みについて
Similar to DDDを実践できるエンジニアを育成するための取り組みについて (20)
DDDを実践できるエンジニアを育成するための取り組みについて
- 2. 2 © BIGLOBE Inc. 自己紹介-経歴 SRE ミドルウェアの標準化 規模大きめサービスのシステムアーキテクチャ設計・運用 開発 社内向け業務システム開発 会員管理システム開発 BIGLOBEモバイル関連のシステム開発
- 3. 3 © BIGLOBE Inc. BIGLOBEモバイル 2017年3月の国内MVNO利用状況調査(MM総研調べ)にて、 お客さま総合満足度No.1をいただきました
- 4. 4 © BIGLOBE Inc.
- 5. 5 © BIGLOBE Inc. 本題 ・育成に取り組んだ背景 ・具体的な取り組み内容 ・取り組んでみて見えてきた課題
- 7. 7 © BIGLOBE Inc. 問題 新しくDDDを使った開発を進めていく、 既存の開発メンバー、新しく加わった開発メンバーにとって DDDって何？？？って人がほとんど バックボーンは様々 いきなりチームに入って理解を合わせるのは厳しい
- 8. 8 © BIGLOBE Inc. そもそもDDDを導入した目的 法改正やキャリアの仕様変更、他社との競争に挑み、業務の変 更が頻繁に発生するシステムを開発し続け、 サービス開発のトータルコストが指数関数的に増加していく現実 コストを下げて、高速に高品質なサービスを提供し続けていきた い
- 9. 9 © BIGLOBE Inc. では DDDって何？ って聞かれて 的確かつ相手が理解できるような説明をすることができるか？
- 10. 10 © BIGLOBE Inc. 壁 DDDって難しい 理解も解釈も、そこから生まれる設計も人それぞれになりがち システムはそれなりに大きい 30年ほどの負債が組み込まれている 関係する開発者の数も多い
- 11. 11 © BIGLOBE Inc. 壁 開発は1人で行わない バックボーンも知識もバラバラな人たちがいきなり取り組んだとし ても、バラバラな設計方針で開発を進めてしまう システム全体で設計に一貫性がなければ理解が難しく、サービス 開発のトータルコストが跳ね上がる
- 12. 12 © BIGLOBE Inc. じゃあどうするか？ 設計のガイドライン・ルールをがっちり決めて、 ドキュメント化していけば誰でもできる
- 13. 13 © BIGLOBE Inc. いやいや そんなにうまくいくわけない ルールに従うだけだと、思考停止して、なぜこういう設計をしようと しているか考えられなくなる 新しいパターンの設計だったり、既存設計の改善だったりが、でき なくなってしまう
- 14. 14 © BIGLOBE Inc. 私たちのたどり着いた答え BIGLOBEでDDDに取り組む上での設計の基本的な考え方を チーム全体で共通理解にしていく 開発チームのメンバー全員が理解し、実感する ドメインモデルも関係者全員で共通理解できるものとして作ってい くことが大事ですよね
- 15. 15 © BIGLOBE Inc. のれん分け方式 ノウハウを理解したメンバーを分けて新しいチームを立ち上げて、 新メンバーを育成していく ノウハウの伝授を重視した方式 チームごとに考え方が異なると保守性が下がる 一から教えることで教える側も理解が深まる 解決策 - 組織への展開方法
- 16. 16 © BIGLOBE Inc. 解決策 - 育成コンテンツ DDDに取り組むエンジニアは、いきなりプロダクト開発にアサイン せず まずは共通の練習問題をこなし DDDの目的と効果を理解し、実感する その結果、基本的な設計方針の下、多くのメンバーで大きなシス テムの開発を進めていっても、サービス開発のコストを下げていく ことが可能となる
- 17. 17 © BIGLOBE Inc. なぜ練習問題を解く形式にしたか 講義形式の場合 ・話し手の知識・経験と、聞き手の知識・経験に差がありすぎると 話が理解できない ・質問することへのハードルが高い ・講義自体も聞いてるだけで集中力が持たない（寝てしまう、内職 する）
- 18. 18 © BIGLOBE Inc. なぜ練習問題を解く形式にしたか 練習問題形式にすると ・実践することで、具体的にわからない箇所がはっきりするので質 問できるようになる ・実際の成果物に向かって議論できる
- 19. 19 © BIGLOBE Inc. 具体的に何をやってきたか まずDDDとは何かを知る いきなりエヴァンス本は敷居が高いので、まずはこの2冊 「Domain Driven Design Quickly」 「現場で役立つシステム設計の原則」
- 20. 20 © BIGLOBE Inc. 練習問題その１ レイヤーアーキテクチャを理解する練習問題 前提：シンプルな勤怠データ管理業務がmainで全て実装されてい る （１）レイヤーアーキテクチャにリファクタ （２）ファイル入出力のライブラリ変更 独自実装から外部ライブラリに切り替え （３）休憩時間が増えるという業務の変更に対応
- 21. 21 © BIGLOBE Inc.
- 22. 22 © BIGLOBE Inc. 練習問題その１ よくハマるポイント • 業務の関心ごとと、システムの関心ごとの区別がつけられな い この課題を通して、業務とシステムの関心ごとを分離できるように なっていく 業務の変更による改修がしやすくなることを実感
- 23. 23 © BIGLOBE Inc. 練習問題その２ 実業務に近い形式で、ドメインに注力した課題 簡易な入退会の業務を扱う 既存業務に機能追加が発生した場合、ドメインモデルがどのよう に変わっていくか 実業務での適用の仕方を実感できる
- 24. 24 © BIGLOBE Inc. 練習問題その２ （１）入会機能 （２）退会機能追加 （３）コースの変更機能追加 （４）外部サービスへの認証機能提供
- 25. 25 © BIGLOBE Inc. 練習問題その２ 新規入会機能 • 入会ページより入会を申し込む • 入会可能条件を満たした場合、入会することができる 条件 • 入会可能条件 • 氏名および氏名かなが合致する人物が既に入会済みでない • 20歳以上である • 利用可能なクレジットカードを保有している • 入会時のコースは固定 ※ベーシックとかプレミアムみたいなコース • 入会の際、会員登録情報として申込者の個人情報等を必要とする
- 26. 26 © BIGLOBE Inc. 練習問題その２ 退会機能追加 • 会員が退会ページから退会を申し込む • 退会前には自身の会員情報を表示し、本当に退会してもよいかの意思を確認 • 退会可能条件を満たした場合、退会申込日の月末をもって退会する 条件 • 退会可能条件 • 退会申込者が本人であること • 既に退会を申し込んでいないこと
- 27. 27 © BIGLOBE Inc. 練習問題その２ コース変更機能の追加 • コース変更ページから変更を申し込む • コース変更可能条件を満たした場合、コース変更申込日の翌月からコースを切り替 えることができる 条件 • コース変更可能条件 • コース変更申込者が本人であること • BIGLOBEに入会中であること • 既にコース変更を申し込んでいないこと • 変更を申込むコースが現在のコースとは異なること • コースは下記の２つ • 「ベーシック」コース • 「プレミアム」コース • コース変更のキャンセルは不可
- 28. 28 © BIGLOBE Inc. 練習問題その２ 外部サービスへの認証機能提供 • 外部のサービスと連携可能とする 条件 • 外部システムから呼び出される • 「ベーシック」コースは認証NG、「プレミアム」コースは認証OK • 退会済みの場合は存在しない
- 29. 29 © BIGLOBE Inc. 練習問題その２ よくハマるポイント • ドメイン層の作り方 • バリューオブジェクトにせずStringでデータを持つ • ロジックをどこに書いていいかわからなくなる
- 30. 30 © BIGLOBE Inc. 練習問題の進め方 （１）ドメインモデルの作成 （２）チームメンバーでの集合レビュー （３）実装 （４）プルリクベースでのレビュー レビューアは既にDDDに取り組んできている開発メンバー
- 31. 31 © BIGLOBE Inc. レビュー形式にした理由 育成にはバラつきがある 加えて、既存のDDDに取り組んできているメンバーも、手探りで 学んできた初期のメンバーなど、色々な世代がいて理解度にバラ つきがある 既存メンバーはレビューアとして繰り返し練習問題に触れていくこ とで、理解度を深め、設計方針を共通化していくことができる
- 32. 32 © BIGLOBE Inc. レビュー形式にした理由 練習問題については、この繰り返しの中でフィードバックを受けて 何度もブラッシュアップ 何度も同じモデルに向き合う事で、設計レベルについてもブラッ シュアップされていく 共通認識を合わせるだけでなく共通認識を育てていく 新規のメンバーだけでなく、既存メンバーの設計レベルを上げて いかないと組織として成長しない
- 33. 33 © BIGLOBE Inc. 育成は終わらない その他にもこのような取り組みを実施 ・増田さんにコンサル ・練習問題のレビュー ・プロダクトのレビューや設計方針の相談 ・エヴァンス本の読書会 ・実務でのドメインモデル/実装はチームをまたいでレビュー会実 施
- 34. 34 © BIGLOBE Inc. 育成に取り組んでの課題その１ 育成にはコストがかかる レビューなど既存メンバーのコストも使う 育成だけにコストをかけすぎるのは実業務が回らなくなるので本 末転倒 使えるコスト感、期限、ゴールを決めておく ※期限を決めておく事でやる気が出る
- 35. 35 © BIGLOBE Inc. 育成に取り組んでの課題その２ DDDに関わる開発者が増え、チームも増えてきた DDDへの取り組みの規模が大きくなればなるほど、共通の理解 を揃えていく難易度は高くなる 設計について思考停止せず考えることが恒常的になった結果、設 計の進化だったり、改善だったりが各チームで同時多発的に起こ る 設計方針が進化してきていて、過去に開発してきたプロダクトの 設計方針が古くなっている場合もある
- 36. 36 © BIGLOBE Inc. 育成に取り組んでの課題その２ 規模に合わせたシステムアーキテクチャを作っていくことも必要 例えば設計方針をシステムの範囲によって分けていくとか →マイクロサービス化 とはいえこれだと設計方針がずれていくの許容する事になるか ら、別の方法も模索中
- 37. 37 © BIGLOBE Inc. まとめ BIGLOBEの開発現場では、 すごい勢いでエンジニアが育っていきます
- 38. 38 © BIGLOBE Inc. まとめ そして卒業していきます
- 39. 39 © BIGLOBE Inc. DDD実践に興味のある エンジニアを募集しています！ 詳細を聞いてみたい、という方は 採用担当(crecruit@ml.biglobe.co.jp)まで 以下内容を入力しご連絡ください。 《お名前、会社名、担当業務、当社のどこに興味を持ったか》 ぜひお気軽にご連絡ください♪ ↓メールの送信画面が開きます ★☆ BIGLOBEにjoinしませんか？
- 40. © BIGLOBE Inc.