炎上プロジェクトを救うのは「工数」ではなく「構造設計」

炎上するプロジェクトの多くは、作業量ではなく「構造」が崩れています。ユースケースから作り始めると何が起きるのか、なぜ「スキーマから始める」と安定するのか。AIに実装を任せる時代にこそ重要になる、構造中心設計の考え方を解説します。

炎上の正体は「工数」ではない

プロジェクトが炎上すると、まず「人が足りない」「スケジュールがきつい」という話になります。もちろんそれも事実ですが、立て直しに入ってコードを読むと、もっと根本的な問題に行き当たることがよくあります。

ある状態が、どこで管理されているのか誰も説明できない
同じ概念が、画面ごと・APIごとに少しずつ違う形で存在している
「これは絶対に起きてはいけない」という条件が、どこにも書かれていない
修正するたびに、別の場所が壊れる

人を増やしても、これは解決しません。むしろ悪化します。問題は作業量ではなく、構造が崩れていることだからです。

設計には三つの視点がある

ソフトウェアの設計は、大きく三つの視点で捉えられます。

視点	中身	具体的には
構造	何が存在し、どうつながり、何が許されないか	エンティティ、関係、制約、状態
振る舞い	何をするか	ユースケース、業務ルール、処理の流れ
表現	どう見せ、どう受け渡すか	画面、API、データの受け渡し形式

世の中のさまざまな設計手法は、この三つのうちどこを起点にするかで性格が分かれます。

ユースケースから始めると、何が起きるか

多くのプロジェクトは「ユーザーは何をしたいか」から始まります。要件定義でユースケースを洗い出し、画面ごと・機能ごとに作っていく。分かりやすく、お客様とも合意しやすいやり方です。

しかし、この進め方には落とし穴があります。ユースケースは「何をするか」は教えてくれますが、「システムが扱うデータが、どんな形でつながっているか」は教えてくれません。

たとえば予約システムで、

「顧客が予約を入れる」
「スタッフが予約を変更する」
「顧客がキャンセルする」

というユースケースを、それぞれ別の担当者が実装したとします。すると、「予約」が何を指すのか、キャンセルされた予約はまだ「予約」なのか、一つの枠に何件まで入れてよいのかといった前提が、実装ごとに少しずつ違ってきます。

そのズレは、最初は小さなバグとして現れます。やがて状態の持ち主が分からなくなり、責任があちこちに散らばり、直すほど壊れるコードになります。これが炎上の典型的な構造です。

データの受け渡しのための変換コードが増えるだけなら、手間が増えるだけで済みます。しかし構造が崩れると、プロジェクトそのものが崩れます。

構造中心設計とは

構造中心設計は、

振る舞いよりも先に、「システムが何を扱い、それらがどうつながるか」を固定する設計

です。進め方はシンプルです。

実体を決める：何が存在するのか（顧客、予約、予約枠、スタッフ…）
関係を決める：それらはどうつながるのか（予約は一つの枠に属する、など）
所有と参照を分ける：どれが持ち主で、どれは参照しているだけか
状態遷移を明示する：予約は「仮予約 → 確定 → 来店済み／キャンセル」と移る、など
不変条件を書く：一つの枠の予約数は定員を超えない、確定済みの予約は過去の日付に移せない、など

ユースケースを考えるのは、その後です。

構造を先に決めると、何がよくなるのか

構造は、変わりにくい

ユースケースは、事業の状況に合わせてよく変わります。画面はもっと変わります。しかし「予約」「枠」「顧客」という実体とその関係は、比較的変わりません。変わりにくい部分を土台にすれば、変更の影響を小さく閉じ込められます。

責任の置き場所が、自然に決まる

構造が決まると、状態がどこにあるべきか、ロジックがどこに属するべきか、データの正しさを何で判断するかが決まります。「この処理はどこに書くべきか」という議論の多くは、構造が曖昧なことから生まれています。

足りないユースケースが見えてくる

構造を整理すると、「キャンセル済みの予約を元に戻す操作がない」「枠の定員を減らしたとき、超過した予約をどうするか決まっていない」といった、抜けている操作や例外が見えてきます。構造は「可能な操作の範囲」を決めるので、そこから逆にユースケースを発見できるのです。

画面・API・データベースを、同じ構造でそろえる

構造中心設計をさらに進めると、スキーマを唯一の正解とし、画面もAPIもその「写し」として作る、という考え方になります。

画面用のデータ形式、API用のデータ形式、データベースの形式がそれぞれ別々に定義されていると、その間をつなぐ変換コードが大量に生まれ、変換のたびにズレが入り込みます。三つが同じ構造をしていれば、変換そのものが不要になります。

DDDやクリーンアーキテクチャとの関係

ドメイン駆動設計（DDD）は、業務の言葉と振る舞いを持つモデルを中心に据えます。クリーンアーキテクチャは、依存の向きとユースケースの分離を中心に据えます。

	DDD／クリーンアーキテクチャ	構造中心設計
設計を始める場所	何をするか（振る舞い）	何があるか（構造）
変わりにくいものとして頼る部分	業務ロジック	つながりと、守るべき条件
モデルで重視すること	業務上の意味	データの形と関係

これは対立ではなく、設計の軸をどこに置くかの違いです。構造中心設計は、それらを否定するのではなく、軸を一段深いところに置くアプローチだと考えています。

「制約」を先に決める

業務ルールには、大きく二種類あります。

制約：守られなければならない条件（定員を超えてはいけない）
手続き：どう実行するか（予約が入ったら確認メールを送る）

構造中心設計では、制約を先に決めます。制約がはっきりしていれば、手続きは後から足しても崩れにくいからです。逆に、手続きを積み重ねるだけでは、制約はどこにも書かれず、守られているかどうかも分かりません。

AIに実装を任せる時代こそ、構造から

AIのコーディング能力が上がったことで、ユースケースごとの実装は驚くほど速く作れるようになりました。しかしそれは、構造が曖昧なままでも、振る舞いを大量に生み出せてしまうということでもあります。

AIは与えられた前提に忠実に、高速に実装します。前提である「データの構造とルール」が曖昧なら、曖昧さもそのまま高速に増殖します。

だからこそ、AI時代の人間の仕事は、実装を一つずつ書くことから、システムが扱う対象と、そのルールを定義することへ移っていきます。スキーマと制約がはっきりしていれば、AIはそれを根拠に正しい実装を作り、間違った実装を自ら検出できます。構造は、AIにとっても最も確かな拠り所になるのです。

炎上したプロジェクトを立て直すとき

炎上したプロジェクトを立て直すとき、構造を定義し直すと、

全員が同じ前提（何が存在し、どうつながるか）で話せるようになる
状態のありかがはっきりする
責任の置き場所が整理される
関わる人の頭の負担が下がる

という変化が起きます。コードを整える作業というより、「このシステムは何を扱い、どんなルールで動くのか」を、関係者全員で決め直す作業だと言えます。

まとめ：実践のための5つの指針

「何ができるか」より先に「何があるか」を書く
システムの主役となる概念を、最初に一つずつ決める
それぞれの状態を、誰が持っているかを決める
「絶対に起きてはいけないこと」を、実装より先に書き出す
画面やAPIは、構造を映したものとして作る

振る舞いは変わる。しかし、構造と制約が曖昧なままだと、システムは崩れる。だから、まず「何があり、どうつながるか」を決める。

Honeysolでは、AIを組み込んだシステムの設計・開発から、行き詰まったプロジェクトの立て直しまでご相談をお受けしています。お気軽にお問い合わせください。