なぜ設計が必要なのか — コードを書く前に考えること

「とりあえず動くものを作ってから考えよう」——実務で一度はこう思ったことがあるはずです。 小さなスクリプトならそれでも問題ありませんが、チームで開発するWebアプリでは、設計なしに進めた代償が後から重くのしかかります。

この章では、設計とは何か、なぜ必要なのかを「設計しなかった場合に何が起きるか」から逆算して考えます。

設計しないとどうなるか

以下の場合は設計は必要ない

• PMとSEが一人で企画から開発まで行う場合（意思疎通が不要）
• 要件を全て理解している場合
• ドキュメント化しなくても、バグなど問題起きない場合、コードを書くことができる場合
• 運用保守が不要な場合

逆にいうと上記が設計をすると、以下のメリットと考えれます

• 意思疎通
• 要件の理解
• バグの発見
• 運用保守の容易化

設計を飛ばして開発を始めると、典型的にはこうなります。

• テーブル構成が決まらないまま実装が進み、途中で大幅なマイグレーションが発生する
• API のレスポンス形式がエンドポイントごとにバラバラで、フロントエンド側が個別対応に追われる
• 同じバリデーションロジックがフロントとバックで重複し、片方だけ修正して不整合が起きる
• 新しいメンバーが入っても、どこに何があるか分からず「聞かないと分からない」状態になる

これらはすべて「事前に決めておけば防げた問題」です。設計の本質は未来の自分とチームメンバーのために判断を記録しておくことにあります。

設計の目的

このセクションは現在執筆中です。

• 共通認識を作る（チーム内の「そういうことだと思ってた」を防ぐ）
• 手戻りを減らす（実装前に矛盾を発見する）
• 変更に強い構造を作る（要件変更を低コストで吸収する）
• 意思決定を記録する（なぜこの構成にしたか、を後から追える）

設計の流れ（上流工程）

設計と実装のバランス

このセクションは現在執筆中です。

• 過剰設計（YAGNI違反）の問題
• 「設計書を書く＝ウォーターフォール」ではない
• アジャイルでも設計は必要、粒度が違うだけ

ちゃんと使うためのポイント

• 設計は「完璧なドキュメントを作ること」ではなく「判断を共有すること」
• 規模が小さいうちから設計の習慣をつけておくと、規模が大きくなったときに活きる
• この本では「駆け出しエンジニアが最初に押さえるべき設計の型」を章ごとに整理していく

次の章では、設計の起点となる要件定義の進め方を見ていきます。