ID:78473さん

# プロジェクト経験概要 配送指示・ルート管理・ドライバー割当など、業務領域が多岐にわたる配送管理SaaSのバックエンド開発を担当。 対象は配送を依頼する企業の社内オペレーターや事務担当者で、業務の複雑性と継続的な仕様変化への対応が求められる環境でした。 中でも特に難易度が高かったのは、配送依頼に関わるコアドメインにおいて、Uber Directなどの即配パートナー企業が個別に提供していた独自仕様のAPIと連携しながら、自社側のドメイン整合性を保つ必要があった点です。 # チーム情報 ## チーム編成 * CTO兼PdM 1人 * バックエンド2人 ## チーム内の自身の役割 バックエンド兼バックエンドアーキテクト 機能開発に加え、バックエンドアーキテクトとして技術的負債の解消に尽力。DDDに基づきUseCase層を導入し、保守性の高いアーキテクチャを設計しました。さらにテックリードとしてチームの設計文化そのものを醸成し、開発プロセス全体を改善。予測可能で安定したリリースサイクルの実現に貢献しました。 私がバックエンドアーキテクトとしておこなったことは次のことをしました。 # 実装と設計の取り組み 以下の取り組みは、日々の実装やレビュー、定例のやりとりを通してチーム全体で意識的に進めたもので、設計や開発の土台を共有・強化することを目的としていました。 ## API実装パターンの設計・適用 ### 背景・課題 開発初期から多用されていたサービスオブジェクトやFormObjectが、責務が曖昧なまま肥大化し、ビジネスロジックがアプリケーション全体に散在していました。これにより、似た処理が重複して実装されたり、仕様変更時の影響範囲の特定が困難になったりする問題が発生していました。 また、外部APIとの連携においては、パートナー企業の独自仕様がドメイン層に直接入り込み、特定の外部仕様の変更がプロダクトのコア機能にまで影響を及ぼす、変更に弱い構造になっていました。 ### 解決策と選択理由 単なるAPI実装にとどまらず、Railsアプリケーション全体の開発基盤となる実装パターンの設計を担当。 ビジネスロジックの凝集度を高め、責務を明確に分離することが根本的な解決策だと考え、MVC構造にUseCase層を追加する構成を導入しました。これにより、戦略的DDDの考え方をRailsの開発スタイルに適応させ、「何をするか（UseCase）」と「どう実現するか（Domain/Infrastructure）」を分離し、処理の流れと責務を整理した実装構成を構築しました。 外部APIとの連携においては、今後もパートナーが増減することを見据え、個別の仕様変更からドメインを守る必要があると考えました。そこでAdapterパターンを採用し、各APIを抽象化して共通のインターフェースとして扱えるように設計。 これにより、ドメイン層に外部仕様を持ち込まず、内部構造の安定性と拡張性を確保しました。 ## テスト設計の方針転換 ### 背景・課題 従来のテストは「内部の処理がどう呼ばれたか」という実装の詳細に強く依存した（モックを多用した）形式に偏っていました。その結果、リファクタリングなど内部実装の変更をしただけでテストが失敗する「脆いテスト」となり、次第に形骸化していました。テストを読んでもビジネス上の仕様が理解できず、品質保証の役割を果たせていない状態でした。 ### 解決策と選択理由 **テストの本来の目的である「ビジネス要求が満たされていることの保証」に立ち返る必要があると考え、方針を転換しました。 ユースケース単位で「どんな入力（Given）に対し、何を行い（When）、どういう結果が期待されるか（Then）」**を明示する、振る舞い駆動開発（BDD）に近いテスト構成に刷新。これにより、テストそのものが「動く仕様書」として機能し、仕様理解と変更時の安心感を得られる環境を整備しました。 ## アーキテクチャとチーム設計基盤の整備 ### 背景・課題 業務の複雑性と仕様変化の多さに対し、チーム内で設計方針が明確に共有されておらず、実装者ごとに構造や責務の捉え方にばらつきがありました。これにより、コードレビューでは本質的な設計議論よりも細かな実装スタイルの指摘に時間が割かれ、開発速度の低下やコードの属人化を招いていました。 ### 解決策と選択理由 トップダウンでルールを決めても形骸化すると考え、まずはチームメンバーが設計の必要性や原則を自分たちの言葉で語れるようになることが重要だと判断しました。 そこで、"Learning Domain-Driven Design" を翻訳ソフトを使って読み進める社内読書会を提案。当時はまだ日本語訳が出版されていなかったものの、内容が非常に実践的で、現場の課題感に直結すると確信し、この書籍を選定しました。 この読書会を通して、ドメインモデリングや設計原則についてチームの共通言語と視点を醸成しました。 （のちにこの書籍は「ドメイン駆動設計をはじめよう」として日本語版が出版されました） こうした対話と学びという土台の上に、具体的な指針としてRailsに適した形でレイヤードアーキテクチャとモジュラーモノリスを導入。依存関係や責務を整理し、ディレクトリ構成や命名規則を共通化することで、実装判断の軸をチーム全体で揃えていきました。 # もたらした変化と貢献 一連の設計改善とチームへの働きかけを通じて、開発プロセスとコード品質に以下の変化をもたらしました。 ## 変更容易性の向上 外部APIとの連携部分を抽象化したことで、将来のパートナー追加に対応できる拡張性と、外部APIの仕様変更に左右されない独立性を両立させました。 ## 開発プロセスと文化の改善 アーキテクチャや設計方針を共通化したことで、コードレビュー時の議論が構文や命名といった細部から、設計の意図や業務要件の表現といった本質的な対話へと移行しました。 その結果、設計の背景が自然と共有される文化が生まれ、知識が個人に留まることなく、チームの資産となる状態を実現しました。これによりコードの属人性が低下し、より安定した開発が可能になりました。 ## コードベースの健全化と予測可能性の向上 ディレクトリ構成と責務の分離を明確にしたことで、「どこに何を書くか」といった実装判断の迷いがなくなりました。 その結果、開発者は細かな実装ルールに思考を奪われることなく、「この機能のAPIはどうあるべきか」「このクラスの責務はどこまでか」といった、より本質的で、将来の保守性や拡張性を見据えた設計についての議論に時間を注げるようになりました。 ## 品質保証と心理的安全性の向上 ユースケース単位でのテスト構成に刷新したことで、ビジネスの仕様とテストコードが1対1で対応するようになり、仕様の理解が深まりました。 また、これにより「テストが守ってくれる」という強い安心感が生まれ、開発者が複雑な既存コードの改善（リファクタリング）にも、臆することなく挑戦できる文化が醸成されました。結果として、技術的負債の蓄積を防ぎ、コードベースの健全性を長期にわたって維持できるようになりました。 ## 予測可能なリリースサイクルの実現 整備された設計とテストの構造は、CI/CDパイプライン上で効率的に機能し、機能追加や大規模なリファクタリングを行いながらも、リリース後の重大な障害や、それに伴う緊急の切り戻しをほぼ発生させることなく、安定した価値提供を続ける上で中心的な役割を果たしました。