はじめに
プラットフォーム開発本部CSPグループで主にDMMヘルプセンターのバックエンド開発を担当している、佐々木です。
私たちのチームでは、今年の8月から11月にかけてバックエンドAPIのリアーキテクチャに取り組みました。
このプロジェクトでは、アプリケーションアーキテクチャのプロフェッショナルとも言えるミノ駆動（@MinoDriven）さんから直接ご指導をいただきました。ミノ駆動さんは「良いコード/悪いコードで学ぶ設計入門」（以下ミノ駆動本）の著者としても知られています。
この期間中、私たちはドメインモデリングを中心とした設計手法についてのレクチャーを受けながら、リアーキテクチャを進めてきました。
その結果としてアプリケーションの品質が向上し、チームとして設計に関する知識がアップデートされ、開発効率が向上しました。
この記事では、実際に私たちがレクチャーを通して得た学びや反省点などを共有したいと思います。
※申し訳ありませんがこの記事では詳細なドメインモデリングなどの方法論や実際のソースコードに関しては長くなってしまうので割愛させていただきます。詳しい方法論を学んでドメインモデリングに挑戦してみたい！という方はミノ駆動さんの著書等をはじめ、世の中で多く出回っているので、そちらを参照していただければと思います。
レクチャー前のチーム状況
開発メンバーは5人で全員が一年以上アプリケーションの開発に従事しており、ある程度仕様も把握している状態でした。
その中でも2人は簡単なドメインモデリングの知識を持っていましたが、深い知識があるわけではなく、試行錯誤しながら徐々にリファクタリングを進めていました。
今回はその2人に加えてアプリケーションの開発初期から携わっていた私を含めた3人でレクチャーを受けることになりました。
レクチャー前のソースコードの状況
アプリケーションについてはGo言語にてMVCを中心として、モデル層が肥大化しないように分割して実装を行なっていました。
しかし、仕様が複雑になるにつれてビジネスロジックがコントローラに散らばっているといった問題がありました。
バグの発生頻度も少なくなく、過去に実装した機能を修正する際にも影響範囲に注意しながら実装しなければいけない状況でした。
私もレビュー時にコードを読む機会が多かったですが、理解しにくい部分が多く、時間がかかっていました。開発効率や品質がいいと言える状態ではありませんでした。
このような状況であったため、MVCからDDDを利用してレイヤードアーキテクチャへのリファクタリングを進めており、ある程度形にはなってきていました。
しかし、モデル層の設計と実装が思うように進まず、改善が求められる状況でした。さらに、アプリケーションアーキテクチャに精通したメンバーがいない点も課題として浮き彫りになっていました。
この状況を改善すべく、ミノ駆動さんからのレクチャーを受けることになりました。
目標
レクチャーを受けるうえでアプリケーションの改善はもちろんのこと、下記の目標が達成できるように参加メンバーで認識を合わせました。
- 設計の良し悪しを判断できるようになること。
- 変更容易性が高い（＝バグを埋め込まず、正確に変更ができる）構造を設計できるようになること。
ソースコード改善後も継続してコードの品質を保つためには、各メンバーがある程度設計の基本的な考え方を理解し、それを実践できるようになることが重要だと考えました。
やったこと
基本的な設計に関する学習
「ミノ駆動本」を活用しながら、設計の基本的な考え方を学びました。
疑問点やわからないことがあれば、直接ミノ駆動さんに質問できました。冷静に振り返ると、ベストセラー技術書の著者に直接質問できる機会は非常に貴重で、とても幸運だったと思います。
この本を通じて設計の基礎をしっかり学べたおかげで、後の設計をスムーズに進めることができました。今でも設計に迷ったときにはこの本を読み返して確認することが多く、設計をこれから学ぼうと考えている人には特におすすめの一冊です。
実務形式での設計
レクチャーを受けるのと同時期に新機能の開発が必要になったため、それに対してレクチャー受けつつ設計することになりました。
主にドメインモデリングを活用したレイヤードアーキテクチャを中心とした構造で開発することになりました。
ミノ駆動さんが非常に理解しやすい社内ドキュメントを整備してくださっており、それに従い設計を進めておりました。
新機能の概要などは記載すると長くなってしまうため、イメージしやすいように各フェーズでどのようなアウトプットが出たか簡単なイメージ図を貼らせていただきます。
ユースケース図の作成
本来ならば要件の洗い出しなどの工程があるのですが、新機能の要件はある程度決まっていたので一般的なUMLのユースケース図を作成しました。この時に意識したことはデータを破壊するのは基本的に更新系の処理なので参照系の洗い出しは省略していました。
イベントストーミング
イベントストーミングと呼ばれるモデリング手法で後のフェーズで利用する業務プロセスの可視化を行いました。
ドメインモデリング
イベントストーミングからドメインモデルを考えます。この時に重要なのが各モデルに対してデータを安全に保持するための制約を洗い出すことです。逆に言うといかにしてデータを壊すことができるかを真剣に考えるように促されました。
データを破壊するという観点についてはこちらに詳しく解説されているのでぜひ確認していただけると理解が深まるかと思います。
実装（モブプロ）
洗い出したドメインモデルをモブプロをしながら実装に落とし込みました。この時、ミノ駆動さんからはあまりああしろこうしろという指摘はなく困って質問したら助けてくれるという進め方だったので自分たちで考えながら実装できる方式だったのはよかったです。
レクチャーを受けての現在のチーム状況
現在はミノ駆動さんからの定常的なレクチャーやレビューから卒業して、新機能実装時やリファクタリング時にレクチャーを受けた設計をチーム内で行い開発を進めています。
レクチャー後は下記点から非常に実装およびレビューしやすくなっています。
- 各層ごとに細かく分けて実装ができるので細かい粒度でPRを出すことができるようになった
- 細かい粒度でPRが出てくるので可読性があがり非常にレビューがしやすくなった
- バリデーションなどの細かな仕様をドメインモデルを何度も確認しながら実装できる
- ドメインモデルを確認することでシステムの全体像が把握しやすくなり、実装中の各APIがどのように作用しあっているのか理解しやすくなった
仕様がわからなくなった時に設計時に作成したドメインモデルを確認して抜けや漏れがないかなどを確認しながらデータが壊れないようにコードレビューする新しいチーム内の文化ができたのは個人的には非常にいいことだと感じています。
特にレビューのしやすさは体感だけではなく数値にも表れています。 Findy Team+で直近半年間のレビュー状況を確認するとレクチャー前後あたりで全体的にレビュー時間がかなり減っています。ただ減っているだけではなく全体の変更行数が多いのにも関わらず減っているので確実に効果が出ています。
確実に当初の目標であったバグを埋め込まない変更容易性が高い構造を設計できるようになっていると感じています。
反省点
レクチャーを受けている時の初期にミノ駆動さんを神格化しすぎたが故に、自分たちで考えたり決断したりすることが少なくなっていました。
変数名やメソッド名、定数の置き場所など自分たちで決めるべき細かいことすらも都度「これで良いですか？」と確認してしまっていました。
また、最悪なのがチーム内レビュー中に処理の流れを聞かれた際に「ミノ駆動さんが言っていたから」と答えてしまうことが多々ありました。
レクチャーを受けてコードがそれっぽく綺麗になるようにすることが目的になってしまっており、各自が当初の良い設計ができるようになるという目標を見失っていました。
いくらミノ駆動さんがプロとは言え提供してくれているのはあくまでおすすめの方法論であり、それをどうプロダクトに落とし込むかは自分たちで決断すべきです。
どうしてもこの手のレクチャーは受け身になりがちなので、今やっていることの意味や目的を都度自分なりに考えて進めていくことが大切だと感じました。
マネージャーの理解
今回この一連の活動を通してミノ駆動さんがレクチャーしてくれたことはもちろん幸運なのですがそれと同じくらい幸運だと感じていることがあります。
それはマネージャーがリファクタリングの活動に理解を示してくださったことです。 リファクタリングは成果が見えづらく長期的にみて効果が出るものなので数値化が難しくどうしても新しい機能の実装が優先されがちになってしまうと思います。
顧客優先で目にみえる成果がないと中々リファクタリングを許可してもらえないプロダクトもありえると思いますが、予定していた新規開発を数ヶ月遅らせてこの活動を優先してやらせてもらえたのは感謝しかありません。
もしエンジニアからリファクタリングの相談を受けているマネージャーさんがいたら少しでも耳を傾けてくださるとエンジニア視点からすると非常にありがたいです。
まとめ
正直、運よく設計のプロであるミノ駆動さんからレクチャーを受ける機会があったおかげでプロダクトをよくできました。
ただ、一般的にはそのようなエンジニアからレクチャーを受けることは困難だと思います。
もし、この記事をここまで読んでくださりプロダクトの改善をしてみたいと思った方は一度「ミノ駆動本」など設計の入門書を手にして間違っていてもいいのでイベントストーミングやドメインモデリングで手を動かして設計してみることをお勧めします。
私も本などで方法論だけを学んでやった気になっていたのですが実践に勝る経験はないとあらためて認識させられました。
宣伝
DMMにはミノ駆動さんのようなアプリケーションアーキテクチャのスペシャリストだけではなくAI、QA、マイクロサービス、セキュリティ、デザインなどさまざまな領域のスペシャリストが多数在籍しています。
そのようなエンジニアからプロダクトを通して今回のレクチャーのように事業に貢献しつつも新しい知識を得られる環境が整っています。
この環境で共にプロジェクトを進めてくださる仲間を募集しています。少しでも興味がある方はぜひとも下記採用ページをご確認ください。
dmm-corp.com
