前回に要件定義について説明したので、次のステップのシステムの基本設計について説明しようと思います。

基本設計とは？

システム開発における「基本設計」は、要件定義で決めた“やりたいこと”を、どう実現するかを設計するフェーズです。

もっと噛み砕くと、「ユーザーが求めている体験を、どんな仕組み・画面・データで実現するか」を明確にする工程です。

たとえば、「顧客情報を管理できるシステムを作りたい」という要件があった場合、基本設計では次のような内容を具体化します：

どんな画面構成にするか（トップページ、顧客一覧、詳細ページなど）
どんなデータを扱うか（顧客名、住所、購入履歴など）
どの機能を誰が使えるのか（権限管理）
他システムとの連携方法はどうするか（API、CSV連携など）

つまり、システム全体の設計図を描く段階であり、後続の「詳細設計」や「開発」に直結する極めて重要なフェーズです。

基本設計が大事な理由

① 開発の“道しるべ”になる

基本設計がしっかりしていれば、開発チームは迷わずに実装できます。

逆にここが曖昧だと、エンジニアやデザイナーがそれぞれの解釈で作業を進めてしまい、「こんな仕様じゃなかった」というトラブルが多発します。

② 品質・コスト・納期を左右する

このフェーズで要件の漏れや矛盾を潰しておくことで、後の修正コストが激減します。
システム開発では「後工程に進むほど修正コストが跳ね上がる」とよく言われます。
たとえば、

基本設計での修正コストを1とすると、
詳細設計での修正は3、
開発後の修正は10倍以上、
リリース後の修正は数十倍にもなることも。

つまり、基本設計での詰めが甘いほど、後で痛い目を見るわけです。

③ 顧客・開発者・デザイナーの“共通言語”になる

基本設計書は、技術者だけでなく顧客も読めるレベルでまとめられます。
画面イメージや業務フローなど、ビジュアル要素も多いため、「これならわかりやすい！」と顧客との認識合わせができるのが強みです。
この認識のズレを最小限にすることが、プロジェクト成功の鍵です

基本設計でよくあるミス

❌ 1. 要件定義との整合性が取れていない

要件定義で決めた内容と、基本設計の内容がズレるケースです。

たとえば「顧客データをCSV出力できる」と要件に書かれていたのに、設計書にはその機能が反映されていないなど。

“要件定義書を逐一参照しながら作成する”ことが重要です。

❌ 2. ユーザー目線が欠けている

設計者がシステム都合で考えすぎて、「操作が複雑」「クリック数が多い」といったUX上の問題が起こることがあります。
特に業務システムでは、“1日に何十回も触る人の体験”を設計段階から意識することが大切です。

❌ 3. 曖昧な表現・抜け漏れ

「適宜対応」「可能な限り」「必要に応じて」などの曖昧な表現は、後で必ずトラブルを招きます。
基本設計書では、仕様を定量的・明確に記述することが鉄則です。
（例：「10件以上登録された場合は、ページネーションを表示する」など）

❌ 4. 開発・テストを意識していない設計

設計段階でテストのしやすさを考慮していないと、後に検証が難しくなります。
また、API設計やデータ設計を軽視すると、開発チームが地獄を見ることになります。
「設計は開発者のためでもある」という視点を忘れずに。

❌ 5. レビューを省略してしまう

スケジュールがタイトになるとつい「レビューは後で」と後回しにされがちですが、基本設計書のレビュー＝プロジェクトの安全装置です。

必ず第三者の目を通し、要件の漏れや矛盾を早期に発見しましょう。

今ならAIにレビューを依頼するのも良いかもしれないですね！

まとめ

基本設計は、システム開発の“骨格”を決める最重要フェーズです。
要件定義で固めた「何をしたいか」を、“どう実現するか”の形に落とし込むことで、
開発全体の精度・スピード・品質が大きく左右されます。

✅ 要件との整合性を保つ
✅ ユーザー目線で考える
✅ 曖昧さを排除する
✅ 開発・テストを意識する
✅ レビューを怠らない

これらを意識するだけで、後戻りや手戻りが激減し、「失敗しないシステム開発」に一歩近づけます

失敗しないシステム開発入門｜基本設計とは？