こんにちは。ディップ株式会社でエンジニアとして「バイトル」のリアーキテクチャプロジェクトでSoRの新規開発を担当している中嶋です。
現在、私たちは20年以上続く巨大な求人サービス「バイトル」を、 「今後10年戦える持続可能なシステム」 へと進化させるべく、ドメイン駆動設計（DDD）を用いた大規模なリアーキテクチャに取り組んでいます。
その一環として先日、『現場で役立つシステム設計の原則』の著者である増田亨さんをお招きし、3日間にわたる設計ワークショップを実施しました。
本記事では、単なる講義録ではなく、20年モノのレガシーシステムと対峙する私たちが、増田さんとの対話を通じて得た学びと 「設計に対する価値観の転換」 について共有したいと思います。
ワークショップのスタイル：正解を教わるのではなく、視点をぶつけ合う
今回のワークショップの目的は、「正解の設計」「正解のコード」を教わることではありません。
ワークショップを通して増田さんは、
私の言っていることが正解ではない。参加メンバー同士でも視点が異なり、異なる視点から新たな気づきを得ることこそに、このワークショップの真の価値がある
と繰り返し仰っていました。
「開発のスピードや質は、すべて設計次第である」
この設計至上主義とも言える前提のもと、増田さんの考え方を一つの「強力な視点」として取り入れつつ、我々自身が設計に対する向き合い方を考え直す場でした。
Day 1：「カプセル化の本質」と向き合う
初日は、設計の基礎にして奥義、「カプセル化」についての常識を揺さぶられる一日でした。
フィッシュボウル形式でコードについて議論し、周囲がそれを観察・参加するスタイルで進めました。
1. 「ゲッター/セッター」はカプセル化を壊している
私は学生時代「privateフィールドにGetter/Setterをつけるのがカプセル化」と習いました。そんな私にとって、増田さんの視点は衝撃でした。
「ピスタチオの殻（カプセル）は固い。外から中身を自由に取り出せたり（Get）、書き換えられたり（Set）するなら、それは殻の役割を果たしていない」
小さいクラスにデータを詰め込み、外からガチャガチャと操作するのはカプセル化とは呼びません。 「データと、そのデータを操作するロジックを一つの場所に閉じ込める」 ことこそがカプセル化の本質なのです。
2. Factoryメソッドによる「実装詳細」の隠蔽
コンストラクタをprivateにし、Factoryメソッド経由でインスタンスを生成する手法も学びました。
これにより、利用側には「インターフェース」だけを見せ、裏側にある「具体的なクラス（フィールドの型など）」という実装詳細を隠蔽できます。これもまた、強力なカプセル化の一形態であると腹落ちしました。
3. メソッドチェーンの危険信号
piyo.getHoge().getFuga() のようにメソッドチェーンが2つ以上続く場合、それは 「データと計算ロジックが離れすぎている」 という危険信号です。
色々な設計改善手法を学びましたが、結局のところ 「すべての改善は、適切なカプセル化に繋がっている」 という事実に気づかされました。
Day 2：「費用対効果」で考える設計改善
2日目は、「変更容易性」という言葉の解像度を上げる議論が中心となりました。
1. 変更容易性には種類がある
「楽に安全に変更できる」ことが変更容易性ですが、私はこれを3つのレイヤーで整理しました。
- ビジネス（事業戦略レベル）に対する変更容易性
- 現場レベル（事業範囲内での施策）の変更容易性
- システム都合の変更容易性
ただコードを綺麗にするだけでなく、 「今、どのレベルの変更容易性が求められているのか？」 を意識することが重要です。
2. 設計改善における「費用対効果」
増田さんは 「設計改善は費用対効果を意識することが大事」 と強調されていました。
美しさを求めて無限に時間をかけるのではなく、ビジネスの価値に直結する部分にコストをかける。このバランス感覚こそがプロフェッショナルの設計です。
Day 3：実プロジェクトでの実践で痛感した設計改善の難しさ
最終日は、実際のプロジェクトのコードを題材にした実践編です。
PC画面を囲んで議論している様子
1. 天然モノのコードを前に、手が止まる
1日目・2日目のサンプルコードではスムーズに進んでいた私の手は、実際のプロジェクトのコードを前にした途端止まってしまいました。
いくつか問題らしき「匂う」箇所は見つけられました。しかし、1日目・2日目で扱ったコードに比べコンテキストが複雑なコードを目の当たりにし、 「複雑な問題を複雑なまま」 扱おうとしてしまったのです。 結果、増田さんが繰り返し仰っていた「小さく素早い仮説検証」ができず、立ち尽くしてしまいました。頭では理解していても、身体にはまだ設計改善の動きが染み付いていないことを痛感させられた瞬間でした。
2. 「猿の壺」と問題の単純化
実務のコードは複雑で、どこから手をつけていいか迷います。そこで教わったのが 「猿の壺」のメタファー です。
壺の中の木の実を欲張って一度にたくさん掴もうとすると、拳が大きくなって抜けなくなります。リファクタリングも同じです。
- まずは「重複排除」だけやる。
- まずは「早期リターン」でネストを浅くする。
- 「区分」らしきものを
enumに切り出してみる - 「コレクション操作」をクラスに切り出してみる
「一つずつ問題を片付けて単純化する」 ことで、複雑なコードに立ち向かえます。
3. 「気持ち悪い」を放置しない仮説検証サイクル
設計改善を実務で実践するコツは、 「気持ち悪いと思ったらすぐ直してみる」 こと。
- まずはやってみる。
- 変更前と変更後、どちらが良いか考える。
- やりすぎるところまでやってみて、初めて「ちょうど良い」ラインが見える。
この試行錯誤を高速で回すためには、IDEの機能をフル活用すること、そして安心して壊せる単体テストコードがあることが重要です。これらが変更コストを下げ、仮説検証のスピードを生み出します。
4. 設計に「正解も終わりもない」
今回のワークショップを通じて得た大きな学びの一つです。
「最も良さそうに見える設計は、ビジネスの動向と対話から見えてくる」
設計改善にゴールはありません。変化し続ける事業において価値を提供し続けるためには、常にその時点での「費用対効果」を考え、ソフトウェアが解決すべきドメインに向き合い続ける必要があります。
机上の空論ではなく、人との対話から設計のヒントを見つけ出す姿勢こそが、私たちエンジニアに求められているのだと学びました。
今後10年戦えるシステムのために
今回のワークショップを経て、私自身、設計に対する解像度が大きく上がりました。しかし、知っているだけでは意味がありません。 「10年戦えるシステム」を実現するため、私は以下の3つのアクションを実行することをここに宣言します。
1. 「猿の壺」を意識した、計画的なリファクタリングの実践
これまでは大規模な構造変更に対して、「時間がかかりそうだから」という理由で着手するのをためらってしまうこともありました。 今後は、「猿の壺」の教えを守り、リファクタリングのステップを細かく分割して計画します。まずは担当システムにおいて、中規模以上の構造改善を一つ、安全に完了させることを直近の目標とします。
2. コードレビューでの「複雑さ検知」と対話
「気になるけど、これくらいなら…」という小さな妥協が、将来の変更容易性を下げます。チーム内で「なぜそれが変更容易性を下げるのか」を対話し、チーム全体の「複雑さを嗅ぎ分ける能力」を底上げしていきます。
3. ビジネス戦略と紐づいた設計判断
技術的な美しさだけでなく、ビジネスサイドの動向にアンテナを張り、「将来の変更コスト」をシミュレーションした上で設計判断を行います。「事業のために、今どこに設計コストをかけるべきか」を常に問い続けます。
おわりに
「クリーンアーキテクチャであること自体に価値はない。こだわりすぎて変更容易性が下がっては本末転倒」
増田さんのこの言葉通り、型にハマるのではなく、目の前のビジネスとコードに向き合い続けることが重要だと学びました。
