システム方式設計の進め方5ステップ｜なぜ失敗する？現場事例と回避チェックリスト
「方式設計で決めるべき内容はわかったが、実際どういう手順で進めればいいのか？」
「いざ設計を進めると、技術選定で揉めたり、運用チームから後でクレームが来たりする」
「どんなドキュメントを残せば、後工程の開発チームに意図が伝わるのか不安だ」
プロジェクトの現場で、こんな悩みに直面していませんか？
システム方式設計は、決めるべき範囲が広いため、手順を間違えるといつまでも議論がまとまりません。さらに、関係者との合意形成（レビュー）を怠ると、リリース直前になって「パフォーマンスが出ない」「運用が回らない」といった致命的な手戻りが発生します。
この記事では、システム方式設計を確実に前へ進めるための「5つのステップ」と、必須の成果物、そして現場で必ず起きる「3大失敗とその対策」を具体的に解説します。これを読めば、迷いなく設計を進め、自信を持って開発チームへバトンを渡せるようになります。
本記事は、システム方式設計の実践的なノウハウをまとめた実践編です。 「そもそもシステム方式設計で決めるべき5つの領域とは？」「要件定義との違いは？」といった基礎知識をおさらいしたい方は、まずは基礎編である「システム方式設計とは？要件定義との違いと『失敗しないための5つの領域』と判断基準」からご覧いただくことをおすすめします。
システム方式設計の進め方5ステップ｜合意形成で失敗しない手順
システム方式設計は、いきなり構成図を描き始めるのではなく、以下の5つのステップで段階的に進めるのが現場の鉄則です。
ステップ1：要件の整理（インプットの確認）
まずは、前工程である要件定義書を読み込み、実現すべき「機能要件」と「非機能要件（性能、可用性、セキュリティなど）」を整理します。 ここでのポイントは、「曖昧な要件をエンジニアの視点で具体化・数値化しておくこと」です。例えば、「レスポンスは速く」という要件なら、「通常時は2秒以内、ピーク時は5秒以内」といった仮の目標値を設定しておきます。
また、要件定義書の内容が最新の認識と一致しているか、関係者とすり合わせておくことも重要です。前提条件がズレたまま設計を進めると、後工程で大きな手戻りにつながります。
ステップ2：制約条件の確認（絶対ルールの洗い出し）
システムを設計する上で、避けては通れない「制約（縛り）」を洗い出します。ここを無視して理想のアーキテクチャを描いても、後で必ずひっくり返ります。
- 予算と納期: インフラ構築にいくら掛けられるか。いつまでにリリースするか。
- 既存環境の縛り: 「社内標準のDB（例：Oracle）を使わなければならない」などのルールはないか。
- チームのスキルセット: 開発チームはどの言語やクラウドに精通しているか。
ステップ3：構成案の作成（複数案の比較）
制約条件を踏まえ、システムの構成案（アーキテクチャ）を作成します。 ここで重要なのは、「最初から1案に絞らず、複数案（松・竹・梅）を作ること」です。
| 案 | 特徴 | メリット | デメリット（リスク） |
|---|---|---|---|
| A案（王道/推奨） | AWSのマネージドサービスをフル活用 | 運用負荷が低く、拡張性が高い | クラウド利用料が毎月変動する |
| B案（コスト重視） | 既存のオンプレミス環境に相乗り | インフラの初期費用がほぼゼロ | ピーク時のリソース拡張が困難 |
| C案（先進技術） | フルサーバーレス構成で新規構築 | アクセスゼロの時はコスト最安 | チームの学習コストが非常に高い |
最終的な判断は、「コスト」「リスク」「拡張性」のどれを優先するかというビジネス判断になります。 このように比較表を作ることで、ステークホルダー（顧客や経営陣）が「コストとリスクのトレードオフ」を判断しやすくなります。
ステップ4：技術選定とPoC（概念実証）
比較案の中から最適な構成を選び、具体的な技術（言語、フレームワーク、ミドルウェア等）を決定します。 もし、「チームで誰も触ったことがない新しい技術」を採用する場合は、本格的な設計に入る前に必ず小さく検証（PoC：概念実証）を行ってください。「ドキュメント上は連携できるはずだったが、実際に動かしたら特定バージョンのバグで動かなかった」という事態を防ぐためです。
ステップ5：レビューと合意形成
作成した構成案と技術選定の理由をドキュメントにまとめ、関係者とレビューを行います。 レビューでは、「この構成で本当に非機能要件を満たせるか」「運用負荷が現実的か」といった観点で厳しく確認します。 ここで絶対に巻き込むべきなのは、開発チームだけでなく「インフラ担当者」と「運用保守担当者」です。「この構成で運用を回せるか？」「監視はどうするのか？」をこの段階で合意しておかないと、リリース後に大揉めします。
いきなり図を描かず、「制約の確認」と「複数案の比較」から始めるのが合意形成の近道です。
現場あるある！システム方式設計の「3大失敗」と対策
システム方式設計を甘く見ると、プロジェクトの後半でどのような悲劇が待っているのか。現場でよく起こる3つの失敗パターンと、その回避策を紹介します。
失敗1：非機能要件を軽視した末路（パフォーマンス劣化・ダウン）
- 【状況】 要件定義で「レスポンスは普通でいい」「落ちないシステムにして」という顧客の言葉を鵜呑みにし、そのまま一般的なWebサーバー1台の構成で設計。いざ本番稼働してメディアで紹介された瞬間、アクセスが集中してサーバーがダウン。
- 【対策】 「普通」や「落ちない」といった曖昧な言葉を絶対に許さず、「同時アクセス数〇〇件」「月間〇〇PV」「停止許容時間は年間〇〇時間（稼働率99.9%）」といった定量的な目標値を方式設計の段階で必ず定義し、それに耐えうる構成（冗長化やオートスケーリングなど）を設計します。
失敗2：技術選定が「なんとなく」で大炎上（属人化と技術的負債）
- 【状況】 優秀なリードエンジニアが「いま流行っているから」という理由で、最新のマイナーなフレームワークを採用。しかし、そのエンジニアがプロジェクトを離脱した途端、誰もコードを読めずバグの修正すらできなくなる。ネット上に日本語のドキュメントもなく、プロジェクトが完全にストップ。
- 【対策】 技術選定は「流行り」ではなく、「実績（枯れた技術か）」「エコシステムの大きさ」「将来の要員確保のしやすさ」を最優先の基準とします。そして最も重要なのは、「なぜAではなくBの技術を選んだのか」という選定理由を必ずドキュメントに残すことです。
失敗3：運用を考えておらず運用チームから激怒される
- 【状況】 開発のしやすさや機能実現ばかりを優先して設計した結果、いざリリースしてみると「エラーログがどこに出力されているか分からない」「不要なアラートが1日100件も飛んできてオオカミ少年状態」となり、運用保守チームから大クレームが発生。
- 【対策】 方式設計の段階から運用保守の担当者をレビューに巻き込みます。「監視項目とアラートの閾値」「ログの出力フォーマットと保存期間」「バックアップとリストアの手順」を、システムを作る側の理屈ではなく、運用する側の理屈で設計に落とし込みます。
方式設計の失敗は「曖昧な言葉の放置」と「担当者（運用・インフラ）の巻き込み不足」から起きます。
そのまま使える！システム方式設計の必須成果物（テンプレート）
システム方式設計を終えた証として、開発チームやインフラチームに引き継ぐためのドキュメント（方式設計書）を作成します。プロジェクトの規模にもよりますが、最低限以下の項目を網羅しておくべきです。
| ドキュメント名 | 記載すべき内容・目的 |
|---|---|
| 1. システム論理構成図 | システムがどんな機能（役割）で構成され、どう連携しているかを俯瞰する図。（※基礎編で紹介したような図） |
| 2. システム物理構成図 | 具体的なサーバーの台数、IPアドレス、配置場所など、インフラの物理的な配置を示す図。 |
| 3. ソフトウェア構成図 | クライアント、Web層、AP層、DB層などで使用する言語、フレームワーク、ミドルウェアのバージョン一覧。 |
| 4. ネットワーク・セキュリティ方針書 | IPアドレス体系、ファイアウォール（WAF）の設定方針、通信の暗号化方式、認証・認可の仕組み。 |
| 5. データ・外部システム連携図 | 外部システムとのI/F（API、バッチ、ファイル連携等）のプロトコル、データフォーマット、リトライ方式。 |
| 6. データベース基本方針書 | RDBMSかNoSQLかの選定理由、文字コード、バックアップ方式、テーブル定義の基本ルール（命名規則など）。 |
| 7. 運用・監視・非機能対応方針書 | ログの出力方針、死活監視・リソース監視の項目、可用性（冗長化）や性能目標をどう担保するかの設計。 |
これらが揃っていれば、開発フェーズでエンジニアが「どう作ればいい？」と迷うことはなくなります。
漏れを防ぐ！システム方式設計の「最終チェックリスト」
設計が完了し、次の詳細設計・開発フェーズへ進む前に、以下のチェックリストを使って「検討漏れ」がないかを確認してください。1つでも「No」があれば、手戻りリスクが潜んでいます。
- [ ] 要件・制約の確認
- [ ] 予算・納期・既存環境の「制約条件」を満たした構成になっているか？
- [ ] ビジネス上の目標（想定ユーザー数、データ量）に耐えうる拡張性があるか？
- [ ] 技術選定・アーキテクチャ
- [ ] 「なぜその技術を選んだのか（他の技術を見送った理由）」が明文化されているか？
- [ ] 開発チームの現在のスキルセットで、無理なく扱える技術（構成）か？
- [ ] データ連携において「整合性（遅延・二重登録・順序保証）」の扱いが定義されているか？
- [ ] 未知の技術や不安な連携箇所について、事前にPoC（概念実証）を実施したか？
- [ ] 非機能・運用保守
- [ ] 性能、可用性、セキュリティの要件が「具体的な数値や構成」に落とし込まれているか？
- [ ] 障害発生時の復旧手順（バックアップからどう戻すか）が考慮されているか？
- [ ] インフラ担当者および運用・保守担当者のレビューを受け、合意を得ているか？
レビュー時は、このチェックリストをステークホルダーと共有し、全員で「ヨシ！」と指差呼称しましょう。
まとめ：システム方式設計は「後工程への確かな道標」
システム方式設計は、要件定義という「理想」を、開発という「現実」に落とし込むための非常にタフな工程です。
決めるべきことが多く、コストや制約との板挟みになり、時にはステークホルダーとの厳しい交渉も必要になります。しかし、このフェーズで逃げずに「トレードオフの決断」を下し、しっかりとしたアーキテクチャの骨組みを作ることができれば、その後の開発プロジェクトの成功確率は格段に上がります。
今回ご紹介した5つのステップとチェックリストを活用し、ぜひ現場での手戻りや炎上を防ぎ、自信を持ってプロジェクトを前進させてください！
【関連記事のおさらい】 「そもそもシステム方式設計で決めるべき5つの領域（システム構成、技術選定など）と判断基準」について再度おさらいしたい方は、ぜひ基礎編の記事もご活用ください。
