技術選定の罠：設計を「問題理解」から始めるべき理由

多くのエンジニアが、深夜の障害対応や終わりの見えないリファクタリングの渦中で一度はこう思ったはずだ。「なぜ、このコードはこんなにも変更に弱いのか」と。その原因の多くは、実装の拙さではなく、設計の初期段階で犯した『問題領域の誤解』にあると私は確信している。チームラボの茂木氏が指摘するように、我々は往々にして、解くべき問題を定義する前に、JavaやSpring Boot、あるいはマイクロサービスといった「技術の箱」を先に用意してしまう。これは、家を建てる前に「どのメーカーの釘を使うか」を議論するようなものだ。技術の話は具体的で、比較軸も明確であり、何より「設計が進んでいる」という錯覚をチームに与えてくれる。しかし、その裏で、業務上の例外処理や、誰がどの責任を負うのかという本質的な問いが置き去りにされていることに、当事者は気づかない。

技術を先に固定すると、我々は無意識のうちに「その技術で扱いやすい形」に業務を歪めてしまう。例えば、マイクロサービス化を前提にすれば、業務プロセスを無視して「名詞」を切り出し、サービス境界を強引に作ってしまう。結果として、本来は一つのトランザクションで完結すべき業務が、分散システム特有の複雑さ（冪等性、分散トレーシング、ネットワーク障害への対応）を抱え込み、開発効率を著しく低下させる。コード自体はClean Architectureに則り、テストも網羅され、一見すると「美しい」かもしれない。しかし、それは『間違った問題を、極めて綺麗に実装した』という、エンジニアにとって最も残酷な成果物でしかないのだ。この構造的な負債は、最初の要件変更が来た瞬間に牙を剥く。業務の変更単位とシステムの境界が一致していないため、一つの小さな機能追加が複数のサービスを跨ぐ修正を強要し、チーム間の調整コストが指数関数的に増大する。これはもはや技術的負債というより、設計の初期段階における「認識のデッドロック」と言えるだろう。

では、我々エンジニアは明日から何をすべきか。答えはシンプルだが実行は困難だ。それは「技術の話を一旦テーブルから下ろし、業務の完了条件を徹底的に問い直すこと」である。例えば、ECサイトの注文キャンセル一つとっても、顧客にとっての「完了」とは何か、出荷済みの場合の返品フローはどうなるのか、決済取消と返金のタイミングはどう同期されるのか。これら曖昧な問いに対し、技術的な解決策を提示する前に、関係者と徹底的に対話する必要がある。茂木氏が紹介するイベントストーミングやDDDの戦略的設計は、単なる手法ではなく、チームの認識を同期させるための強力なツールだ。イベントストーミングを通じて「業務上の出来事」を可視化すれば、システムが担うべき責任と、人間が判断すべき領域の境界が自ずと見えてくる。

重要なのは、これらを「一方向の要件定義」として終わらせないことだ。設計判断は、問題理解と実装の往復運動の中で洗練されていく。C4モデルを用いて構造を可視化し、特定のコンポーネントに依存が集中していないか、あるいは境界を越えた知識が開発者に求められすぎていないかを常に検証し続ける必要がある。もし、ある機能の変更に際して、別サービスのデータ構造やAPI制約まで深く理解しなければならないのであれば、それはサービス分割の失敗を意味する。サービスを分けたからといって、開発者の認知負荷が下がるとは限らないのだ。むしろ、分散システムとしての複雑さが増した分、より高度なドメイン理解が求められるという逆説的な事実に直面する。我々が目指すべきは、技術的な正しさの追求ではなく、業務の変更単位とシステムの境界を一致させることであり、そのためのトレードオフを言語化し、チーム全体で共有することに他ならない。技術選定は、その『問題の構造』を解決するための手段として、最後に位置づけられるべきである。

最後に、我々エンジニアが自らのキャリアにおいて自問すべきことがある。それは「自分は技術の奴隷になっていないか」という問いだ。フレームワークのアップデートや新しいアーキテクチャパターンの習得に追われる日々の中で、我々は『何のためにその技術を使っているのか』という根本的な目的を見失いがちである。技術はあくまで、複雑な業務課題を解決するための道具に過ぎない。しかし、その道具の魅力に囚われ、本来解くべき問題そのものを歪めてしまうことは、エンジニアとしての専門性を放棄することと同義ではないだろうか。ロート製薬の山田会長が「会社は生物と同じ」と語るように、システムもまた、業務という生きたプロセスと共に進化し続ける有機体である。静的な設計図に固執し、技術的な整合性だけを追い求める姿勢は、この有機的な変化を阻害する要因となり得る。

読者諸氏に提案したいのは、次のプロジェクトにおいて、最初の数日間を「技術的な議論を一切禁止する期間」として設けてみることだ。その代わりに、ドメインエキスパートやプロダクトオーナーと、業務の例外ケースや失敗時のリカバリーフローについて徹底的に議論してほしい。そこで得られた「業務の真実」は、どんな高度な技術選定よりも、システムの寿命を延ばし、開発チームの幸福度を高めるはずだ。技術的な複雑さを引き受けることは、常にトレードオフを伴う。その代償として何を捨て、何を得るのか。その判断を論理的に説明できないのであれば、それは単なるオーバーエンジニアリングである。我々は、コードを書く前に、まず「言葉」を揃えなければならない。システムは、我々が理解した範囲の複雑さしか表現できないのだから。あなたは、自分の書くコードが解決している「問題」の全貌を、自分の言葉で語ることができるだろうか？