基本設計書レビューで確認したい7つの観点｜技術だけでなく業務・運用まで見る

こんにちは。Lamb です。 設計書を見ていると、設定値が埋まっているだけで安心しそうになることがあります。

基本設計書のレビューでは、構成や設定の妥当性だけでなく、要件、業務、データ、運用、障害対応までつながっているかを確認する必要があります。

私は以前、監視そのものは実装されていたものの、どの業務を守る監視なのか、異常時にどの優先度で復旧するのかが整理されていない案件を経験しました。不足が表面化したのは運用フェーズに入ってからです。

この記事では、その経験をもとに、インフラの基本設計レビューで確認したい7つの観点を整理します。

基本設計レビューというと、IPアドレス、ポート、サーバ台数、バックアップ世代数など、目に見える設定値へ意識が向きやすいです。

もちろん、設定値の確認は必要です。

ただし、値が埋まっていることと、設計として判断できることは同じではありません。

なぜその構成にしたのか。

どの要件と結び付いているのか。

障害が起きたとき、どの業務に影響するのか。

誰が、何を基準に復旧を判断するのか。

こうしたつながりが見えないと、構築は進められても、運用フェーズで判断材料が足りなくなります。

私が基本設計書をレビューするときは、設定値の正誤だけでなく、次の7つを確認します。

組織や案件によって基本設計書の範囲は異なります。ここで挙げる観点をそのまま項目名として使うのではなく、自分の案件で誰がどの成果物に記載するかを確認してください。

☑️ 1. 要件と設計がつながっているか

最初に見るのは、要件と設計のつながりです。

基本設計書に構成が書かれていても、その構成がどの要件を満たすためのものか分からなければ、妥当性を判断できません。

たとえば冗長化する場合も、「一般的に冗長化した方がよい」だけでは判断材料として弱くなります。

• どの業務を継続するためか
• どの障害を想定しているか
• 許容できる停止時間はどの程度か
• コストや運用負荷とのバランスをどう考えたか

ここまで見えると、構成の正しさではなく、案件の要件に合っているかをレビューできます。

逆に、要件にない機能や過剰な構成が含まれている場合もあります。良さそうな機能を増やすことと、必要な設計を行うことは別です。

要件、設計、テスト、運用が同じ判断軸でつながっているかを確認します。

☑️ 2. 業務フローとシステム範囲が見えるか

システム構成図だけでは、業務の流れが見えないことがあります。

どの部門が利用するのか。

どの時間帯に処理するのか。

オンライン処理とバッチ処理がどうつながるのか。

処理が止まった場合、どこまで業務が止まるのか。

こうした情報がないと、技術的には正しい設計でも、運用計画や障害対応へつなげにくくなります。

私は、業務フローと業務内容をできるだけ見える形にして設計書へ残すようにしています。

資料だけでは判断できない場合は、業務部門との読み合わせやヒアリングを行います。技術チームだけで想像して埋めるのではなく、業務として何が正しいかを確認し、定義するためです。

最低限、次の点が追える状態にします。

• 対象となる業務
• 利用部門や関係者
• 処理の開始条件と終了条件
• 前後のシステムや手作業とのつながり
• 停止した場合の影響と範囲

基本設計レビューでは、「機能が動くか」だけでなく、「業務の中でどう使われるか」を確認します。

☑️ 3. データの重要度が設計へ反映されているか

データの重要度は、データ一覧へ区分を書くだけでは終わりません。

私の経験では、主に漏洩した場合のビジネスリスクからレベルを分けています。見るのは、信用低下と損失です。

重要なのは、その定義が後続の設計へ反映されているかです。

• データベース設計
• アクセス制御
• バックアップ設計
• ログの取り扱い
• データの保管や削除
• 障害時に扱うデータの範囲

データ定義では重要度が高いのに、データベースやバックアップでは他のデータと同じ扱いになっている。これでは、定義と設計がつながっていません。

セキュリティの具体的な対策は、組織の規程、契約、法令、システム特性によって異なります。レビューでは独自判断で対策を確定するのではなく、重要度に応じた考慮が必要な設計へ反映され、必要な確認先へつながっているかを見ます。

☑️ 4. 可用性・性能・拡張性の前提が明確か

非機能の値は、数字だけを見ると確認した気になりやすいところです。

稼働率、応答時間、処理件数、保管容量などが書かれていても、前提が分からなければ使えません。

• 通常時と繁忙時のどちらを想定しているか
• 対象となる処理や画面は何か
• 計測する場所と時間帯はどこか
• 将来の増加をどこまで見込むか
• 基準を超えた場合に、誰が何を判断するか

数値の根拠が要件や実測ではなく、過去案件の値をそのまま使っている場合もあります。

レビューでは、値そのものだけでなく、前提、根拠、測り方、超過時の対応まで確認します。未確定なら、未確定であることと、誰がいつまでに決めるかを残します。

☑️ 5. 監視が業務影響と結び付いているか

ここは、私自身が運用フェーズで困った経験のある観点です。

ある案件では、バッチ処理の監視は実装されていました。

しかし、そのバッチがどの業務のために動いているのか、エラーやアラートが発生した場合に業務へどの程度影響するのかが整理されていませんでした。

そのため、障害時に次の判断軸がありませんでした。

• 業務停止レベルとして即時復旧するのか
• 一部業務への影響として優先対応するのか
• ベストエフォートで対応できるのか
• どの時点で業務部門へ連絡するのか

不足が表面化したのは、基本設計レビューではなく、運用計画の作成時や実際に障害が発生した後でした。

障害が起きてから業務部門へ影響を確認することになり、初動が遅れました。その結果、二次的な影響も広がりました。

監視項目が存在するだけでは、障害対応に使える監視とは限りません。

私はこの経験以降、監視対象ごとに次の情報が追えるかを確認しています。

アラートの閾値や通知先だけでなく、その通知を受けて業務上の初動を判断できるかまで確認します。

☑️ 6. バックアップと復旧が一続きで設計されているか

バックアップを取得していることと、復旧できることは別です。

基本設計レビューでは、取得方法や保存先だけでなく、有事の復旧方法とリカバリ計画まで確認します。

• 何をバックアップするか
• どの単位で戻せるか
• どの時点へ戻す想定か
• 復旧時に必要な権限や担当者は誰か
• 復旧後に誰が技術確認と業務確認を行うか
• 複数のシステムやデータがある場合、何を優先するか
• 復旧方法を確認する機会が計画されているか

復旧方針は、技術チームだけで決められない場合があります。

どの業務を先に再開するか。

どこまでデータを戻せれば業務を始められるか。

一部機能だけで暫定再開できるか。

業務判断が必要なら、設計段階で確認先と判断者を明確にします。

☑️ 7. 設計意図・未決事項・判断者を追えるか

レビューで確認したいのは、完成した答えだけではありません。

なぜその方式にしたのか。

他にどの案を検討したのか。

何を優先し、何を制約として受け入れたのか。

設計意図が残っていないと、レビューする側は結果だけを見て推測することになります。運用開始後に構成を見直す場合も、当時の判断理由が分かりません。

また、すべての項目が基本設計レビューまでに確定するとは限りません。

未決事項があること自体よりも、未決であることが見えず、誰も追っていない状態が問題です。

最低限、次の情報を残します。

• 未決事項
• 決めるために必要な情報
• 確認先
• 判断者
• 期限
• 決まらない場合に影響する後続作業

空欄を埋めることを優先せず、判断できる状態になっているかを確認します。

☑️ レビュー時に使うチェックリスト

基本設計書を確認するときは、次の項目を見ます。

➕️ 要件・業務

• 設計項目が要件と結び付いているか
• 対象業務と利用部門が明確か
• 業務フローとシステム処理がつながっているか
• 停止時の影響と範囲が整理されているか

➕️ データ・非機能

• データ重要度の定義があるか
• 漏洩時の信用低下や損失を考慮しているか
• 重要度がデータベースやバックアップ設計へ反映されているか
• 可用性、性能、容量の前提と根拠があるか

➕️ 運用・障害対応

• 監視対象と対象業務が結び付いているか
• アラート時の業務影響と復旧優先度を判断できるか
• 緊急連絡体制が決まっているか
• バックアップからの復旧方法と確認者が明確か
• 有事のリカバリ計画があるか

➕️ 設計判断

• 設計意図と採用理由が残っているか
• 未決事項、判断者、期限が見えるか
• 後続工程へ影響する論点を追跡できるか
• 技術チームだけで決められない項目の確認先があるか

チェックリストは、項目を埋めるために使うものではありません。

レビューで気づいた不足を、誰と、いつまでに、どの成果物で決めるかへつなげるために使います。

☑️ まとめ

基本設計書のレビューでは、設定値の誤りを探すだけでは足りません。

確認したいのは、次の7つです。

1. 要件とのつながり
2. 業務フローとシステム範囲
3. データの重要度とセキュリティ
4. 可用性・性能・拡張性
5. 監視と業務影響
6. バックアップと復旧
7. 設計意図・未決事項・判断者

特に運用・監視では、「アラートを検知できるか」だけでなく、「どの業務に影響し、どの優先度で復旧するか」を判断できる状態が必要です。

設計段階で分からないことがあれば、業務部門との読み合わせやヒアリングを行い、対象業務、影響と範囲、復旧方針と優先度、緊急連絡体制を明確にします。

基本設計は、構築のためだけの資料ではありません。

運用開始後に問題が起きたとき、関係者が同じ情報を見て判断するための土台でもあります。

☑️ 次に読みたい記事

基本設計レビューの前段では、要件定義でスコープ、優先順位、対応範囲を合意しておく必要があります。

インフラ要件定義で最初に確認したい7項目では、後工程の認識齟齬を減らすために最初に確認したい内容を整理しています。

移行案件全体の前提を確認したい場合は、AWS移行プロジェクトで最初に決めることもあわせて参照してください。