※この記事は途中まで無料でお読みいただけます。続きはnote（有料）で公開しています。
はじめに
基本設計と聞くと、多くの人は画面設計や帳票設計を思い浮かべるかもしれません。
もちろん、それらは重要です。
しかし、システム基盤SEの目線では、基本設計はそれだけでは終わりません。
現場で本当に怖いのは、画面や帳票は設計されているのに、システムを本番で運用するための設計が抜けているケースです。
ログを何日保管するのか。ログローテーションをどう実現するのか。バックアップ対象とリストア方法は何か。夜間バッチが時間内に終わらない場合、どう判断するのか。障害時に誰へ通知し、誰が一次対応するのか。開局前に、アプリやミドルウェアが正常に起動していることをどう確認するのか。
こうした内容を「運用フェーズで考えればよい」と誤解すると、サービス開始後に問題が表面化します。ログがあふれてディスクを使い切る。バックアップはあるのに戻せない。バッチが終わらず朝の業務開始に影響する。監視アラートは出ているのに、誰も対応しない。ジョブは定義されているのに、それを動かすスクリプトがない。
これは保守フェーズだけの話ではありません。
ログ、監視、バックアップ、ジョブ、起動停止、復旧方法、開局判定、運用手順、運用スクリプトは、基本設計の段階から処理方式とセットで考える必要があります。
基本設計とは、画面や帳票を決めるだけの工程ではありません。要件を、システム構成、処理方式、運用方式に落とし込み、本番で使える形に変える工程です。
ただし、ここで誤解してはいけないことがあります。
基本設計は、完全な白紙からすべてを決める工程ではありません。
多くのSIer案件では、RFP、要件定義、提案、見積の段階で、システム構成、採用製品、サーバ台数、クラウドサービス、冗長化方式、リソース、運用方式の大枠はすでに置かれています。なぜなら、それらがまったく決まっていなければ、提案価格も見積もりも出せないからです。
つまり、基本設計で行うのは、RFPや見積段階で置いた前提を、要件と照合しながら具体化し、詳細設計、構築、テスト、運用へ渡せる粒度に落とすことです。
この記事では、基本設計の全体像を確認したうえで、特にシステム基盤SEが基本設計で何を具体化しているのかを、現場目線で整理していきます。
基本設計には業務設計と基盤設計がある
基本設計とは、要件定義で決めた内容を、システムとして実現できる形に落とし込む工程です。もう少し具体的に言うと、「要件を、利用者から見える仕様と、裏側で動くシステム構成に変換する工程」です。
要件定義では、お客様と「何を実現したいのか」を合意します。たとえば、申請を登録できるようにしたい、承認者に通知したい、月末に集計処理を実行したい、障害時も業務影響を最小限にしたい、といった内容です。
しかし、要件定義で合意しただけでは、まだ開発や構築はできません。申請画面をどう作るのか。集計処理はオンラインで実行するのか、夜間バッチで実行するのか。バックアップはどの前提方式で取得し、何世代保持するのか。こうした実現方法を具体化するのが基本設計です。
基本設計には、大きく分けると業務・アプリケーション寄りの設計と、システム基盤寄りの設計があります。
業務・アプリケーション寄りの基本設計では、たとえば次のようなことを決めます。画面設計、帳票設計、業務フロー設計、外部インターフェース設計、データ項目設計、権限設計、入力チェック、エラー表示などです。
一方、システム基盤寄りの基本設計では、次のようなことを具体化します。システム構成、処理方式、サーバ構成、ネットワーク構成、DB構成、ストレージ方式、ジョブ・バッチ方式、監視方式、ログ方式、バックアップ・リストア方式、セキュリティ方式、運用方式などです。
一般的な基本設計の記事では、画面設計、帳票設計、外部インターフェース設計が中心になりがちです。もちろん、それらは重要です。ただ、このシリーズで主役にしたいのはそこではありません。システム基盤SEが基本設計で何を見ているのかです。
システムは、画面ができれば完成ではありません。画面を動かすサーバ、データを保存するDB、外部システムと連携する通信経路、夜間処理を動かすジョブ管理、障害を検知する監視、バックアップから戻す仕組み、不正アクセスを防ぐセキュリティ設計、本番運用で使う手順・スクリプト・ジョブが必要です。基盤SEの基本設計は、こうした裏側を具体化する工程です。
基本設計には「処理方式設計」と「運用設計」の両方がある
ここで、基盤SE目線では特に重要な考え方があります。基本設計には、処理方式を具体化する設計と、運用でどう回すかを具体化する設計の両方がある、ということです。
処理方式とは、要件をどのような仕組みで実現するかを具体化するものです。バックアップをどの方式で取得するのか。ログローテーションをLinuxのlogrotateで行うのか、ジョブ管理製品で実行するのか。バッチをJP1などのジョブ管理製品で制御するのか。こうした内容が処理方式設計です。
一方で、運用設計では、その仕組みを実際の運用の中でどう扱うのかを具体化します。ログを何日保持するのか。障害時に誰へ通知するのか。業務開局時刻に間に合わない場合、業務を止めるのか、後続処理をスキップするのか。どの運用手順を作り、どのスクリプトを作り、どのジョブとして登録するのか。こうした内容が運用設計です。
この2つは別物ですが、完全に分けて考えることはできません。
たとえば、運用設計で「syslogは1か月保持する」と決めたとします。その場合、処理方式側では、syslogをどの周期でローテーションするのか、退避先フォルダをどこにするのか、圧縮するのか、バックアップ対象に含めるのか、ディスク容量は足りるのかを設計する必要があります。逆に、Linux設計側でログの退避先を決めたなら、その情報を運用設計側へ伝えなければなりません。
運用設計側が「何を、どれくらい、何の目的で管理したいのか」を決める。処理方式設計側が「それをどの仕組みで実現するのか」を決める。基本設計では、この両者をつなげることが重要です。
この関係は、一方向の受け渡しではありません。運用要件が処理方式に影響し、処理方式の制約が運用設計に戻ってくる。つまり、処理方式設計と運用設計は、レビューやすり合わせを通じて入出力を繰り返しながら固めていくものです。
たとえば、バックアップであれば、運用側は「何世代保持するのか」「何時までに業務開局したいのか」「失敗時に誰が判断するのか」を決めます。処理方式側は、それを受けて、スナップショット方式、退避先、世代管理、ジョブ制御、遅延判定、リストア方式を具体化します。そして、処理方式上の制約が分かれば、運用側は保持期間、取得タイミング、エスカレーション、リスク受容を見直します。
この往復がないと、設計は机上の理想で止まります。本番直前になって「ログがローテーションされない」「バックアップ対象が漏れている」「ジョブを動かすスクリプトがない」「監視はあるが誰も対応しない」といった問題が起きます。
なお、運用設計そのものは非常に広いテーマです。システム運転スケジュール、ジョブ管理、監視、ログ管理、バックアップ管理、ユーザ管理、アクセス管理、パッチ管理、起動停止、キャパシティ管理など、掘り下げるべき論点が多くあります。そのため、運用設計の詳細は別の記事で扱います。この記事では、まず基本設計の段階から、処理方式と運用設計が密接につながっていることを押さえてください。
基本設計の全体像
基本設計を全体で見ると、業務・アプリケーション設計とシステム基盤設計は分かれているように見えます。しかし、実際の現場では完全に切り離せるものではありません。
業務機能が決まると、基盤設計にも影響します。ファイルアップロード機能を作るなら、保存先、容量、バックアップ、ウイルスチェック、暗号化、削除ルールを考える必要があります。夜間バッチを作るなら、起動方式、ジョブ順序、異常終了時の再実行、DB負荷、バックアップとの競合、監視アラートを考える必要があります。外部システム連携を作るなら、通信経路、認証方式、ファイル転送方式、再送方式、文字コード変換、監視、障害時連絡を考える必要があります。
このように、業務・AP側で決まることは、基盤側の設計に必ず影響します。逆に、基盤側の制約によって、業務側の実現方法や運用ルールを見直すこともあります。
基本設計とは、こうした業務要件と基盤要件を切り離さずに、システム全体として成立する形へ落とし込む工程です。
その全体像を示したのが次の図です。
この図で見てほしいのは、基本設計が画面設計だけの工程ではなく、業務・AP設計と基盤設計が相互に影響しながら固まっていく工程だということです。
この記事では、このうちシステム基盤基本設計を中心に見ていきます。
業務機能は必ず基盤設計に影響する
基盤設計を考えるうえで重要なのは、業務機能は必ずシステム基盤に影響するということです。業務SE目線では、ある機能を「できること」として定義します。一方で、基盤SE目線では、その機能を本番で動かすために、どのような構成や方式が必要かを考えます。ここを分けて考えすぎると、後工程で問題が起きます。
ファイルアップロード機能の例
たとえば、RFPや要件定義の中に「ファイルアップロード機能」が含まれていたとします。一見すると、これは単に「ファイルを登録できる機能」に見えるかもしれません。
しかし、基盤SE目線では、まず確認すべきことがあります。それは「ファイルをどこに保存するか」だけではありません。その前に、そのファイルアップロード機能を何で実現する前提なのかを確認する必要があります。
- 業務アプリ側で新規に開発するのか
- 導入するPKGの標準機能を使うのか
- 既存の文書管理基盤やクラウドストレージ連携を使うのか
- RFP段階で実質的に想定されている製品やサービスがあるのか
この前提によって、基盤側で設計できる範囲は大きく変わります。
現場では、RFPに製品名が明記されていないこともあります。特定製品名を書くとベンダーロックインだと見られるため、あえて「必要な機能を満たすこと」「既存システムと連携できること」「ファイル管理機能を有すること」といった表現にしているケースもあります。しかし実態としては、既存システムとの接続方式、運用体制、ライセンス、過去の導入実績、社内標準などを踏まえると、ほぼ特定のPKGやサービスを前提にしていることがあります。
この場合、基盤SEは「自由に好きな保存方式を設計できる」わけではありません。PKGがファイルをどこに保存する仕様なのか。保存先を変更できるのか。DBに持つのか、ファイルシステムに置くのか。オブジェクトストレージに対応しているのか。ウイルスチェックと連携できるのか。暗号化に対応しているのか。こうした制約を確認する必要があります。
たとえば、基盤側では「添付ファイルはオブジェクトストレージに置きたい」と考えていても、PKGがその保存方式をサポートしていなければ採用できません。逆に、PKGの標準仕様ではファイルをDBに格納する設計になっている場合、DB容量、バックアップ時間、リストア時間、性能への影響を見直す必要があります。
つまり、ファイルアップロード機能は、単に「ファイルを登録できる機能」ではありません。アプリ、PKG、ストレージ、ネットワーク、セキュリティ、運用、製品サポート条件が絡む設計対象です。
そのうえで、基盤SEは次のような論点を具体化していきます。
- ファイル保存先はどこか（DB、ファイルサーバ、オブジェクトストレージ）
- アップロードサイズ上限は何MBか
- 同時アップロード数はどれくらいか
- 通信タイムアウトはどうするか
- ウイルスチェックを入れるか
- バックアップ対象にするか
- 保存期間と削除ルールはどうするか
- 暗号化するか
- 障害時に再アップロードできるか
この例で伝えたいのは、ファイルアップロードという一見単純な機能でも、基盤SEは「保存先」だけを見ているわけではない、ということです。まず、RFPや提案段階でどの製品・方式が前提になっているのかを確認する。次に、その製品や方式で実現できること、できないことを見極める。そのうえで、容量、性能、バックアップ、セキュリティ、運用、サポート範囲に落とし込む。ここまで考えて、ようやく基本設計として成立します。
夜間バッチの例
もう一つ、夜間バッチを考えてみます。業務SE目線では、「毎日夜間に集計する」「翌朝までに結果を表示する」「月末に締め処理を行う」と表現されることがあります。これも一見、単純に見えます。
しかし、基盤SE目線では、多くの論点があります。何時に起動するのか。何で起動するのか。JP1などのジョブ管理製品を使うのか、cronで足りるのか。異常終了時にどこから再実行するのか。バッチ実行中にバックアップと競合しないか。DB負荷は問題ないか。処理時間は業務開始時刻に間に合うか。月次・年次処理と重なる日はどうするか。
ただし、夜間バッチで本当に困るのは、単に「失敗した」ときだけではありません。より厄介なのは、異常終了していないのに、バッチウィンドウ内に終わらない状態です。
たとえば、夜間0時から朝4時までが業務バッチの処理時間帯だとします。3時時点で全体の15％しか処理が終わっていなければ、残り1時間で完了する見込みはほぼありません。このとき、続行するのか、途中で止めるのか、後続ジョブをスキップするのか、業務開始を遅らせるのか、誰が判断するのか、こうしたことを事前に決めておく必要があります。
基盤処理でも同じです。たとえば、朝4時にスナップショットで復旧ポイントを取得し、その後、退避、整合性確認、ログ退避、アーカイブ転送などの後続基盤処理を行う設計だったとします。スナップショットによって復旧ポイントの取得自体は短時間で終わる構成もあります。しかし、それでバックアップ設計が終わるわけではありません。復旧時に、DB、ファイル、ログなどを同じ時点の断面として戻せるのか。不完全な退避データを正常バックアップとして扱わない制御があるのか。アーカイブ先から戻す場合、業務が求める時間内に復旧できるのか。ここまで考える必要があります。
また、6時時点で後続基盤処理が進んでいない場合、7時の業務開局に影響する可能性があります。この場合、処理を継続するのか、打ち切るのか、後処理ジョブへ進めるのか、当日バックアップ未取得として扱うのか、当日分のオンライン処理は業務側で再実施してもらえるのかを事前に決めておく必要があります。
さらに厄介なのは、バックアップ処理がフリーズしていても、エラーを吐かず、CPUやメモリの閾値も超えず、ジョブ管理上は実行中のまま、というケースです。この場合、単純な死活監視やリソース監視だけでは検知できません。
そのため、バッチやバックアップでは、成功・失敗だけでなく、予定時刻までに開始しているか、想定時間を超えていないか、一定時間内に進捗があるか、後続ジョブに影響していないか、業務開始時刻までに完了見込みがあるかを見る必要があります。
現場では、ジョブ管理製品の終了遅延監視や判定ジョブを使い、一定時刻までに終わらない場合は処理を打ち切り、後処理ジョブへ進める設計にすることもあります。ただし、強制終了するなら、不完全なバックアップファイルの扱い、当日バックアップ未取得時のリスク、前回正常世代からの復旧可否、関係者への通知まで決めておく必要があります。
そして、後処理ジョブでは単にジョブを終了させるだけでは足りません。朝7時に業務を開局するためには、運用日付が切り替わっていること、アプリケーションが起動していること、ApacheやTomcatなどのミドルウェア・監視エージェントが想定どおり動いていること、監視が正常に再開されていることまで確認して、初めて「開局できる」と判断できます。
この流れを、夜間バッチ、基盤処理、開局判定まで含めて見える化したのが次の図です。
この図で見てほしいのは、夜間処理が「バッチが終われば完了」ではないということです。
業務バッチ、スナップショット取得、後続基盤処理、開局前チェックがつながっており、それぞれに遅延時・異常時の判断ポイントがあります。特に開局前チェックでは、ジョブ終了だけでなく、運用日付、アプリ起動、ミドルウェア起動、監視再開まで確認して、初めてオンライン業務を開始できます。
ここで大事なのは、これを「運用で何とかする話」にしないことです。業務開始を優先するのか。バックアップ完了を優先するのか。未取得時のリスクを許容するのか。許容するなら、障害時にどこまで業務側で再実施するのか。こうした判断は、基盤SEだけでは決められません。基本設計の段階で、業務側やお客様と調整しておくべき内容です。
大規模プロジェクトでは、こうした論点を個人の気合いで拾うのではなく、体制として拾いにいくことがあります。たとえば、業務開局時刻、監視通知、エスカレーション、障害時の判断、手動リカバリといった運用要件を整理する基盤運用共通チームと、バックアップ方式、ジョブネット、バックアップ製品の設計、終了遅延監視、後続ジョブ制御といった処理方式を詰めるチームに分け、両者が定期的にすり合わせることで、業務開局時刻、バックアップウィンドウ、打ち切り判断、後処理、通知、リスク受容の考え方を合わせていきます。
もちろん、すべてのプロジェクトで専任チームを置けるわけではありません。小規模案件では、基盤SEが運用要件、処理方式、ジョブ設計、監視設計を兼ねることもあります。それでも重要なのは、運用要件を誰が洗い出すのか、それを誰が処理方式に落とすのか、業務側と誰がリスクを合意するのかを曖昧にしないことです。
基本設計では、技術要素だけでなく、運用要件と処理方式をつなぐ体制や役割分担も意識する必要があります。
夜間バッチは、単に「夜に動く処理」ではありません。業務日付、締め処理、外部連携、バックアップ、監視、障害対応、業務開始可否の判断と密接につながっています。だからこそ、基本設計では、バッチウィンドウ、タイムアウト、進捗監視、後続ジョブ制御、スキップ条件、エスカレーション基準まで考える必要があります。
ここから先では、基盤SEが基本設計で具体的に何を詰めていくのかを整理します。
システム構成、処理方式、サーバ・リソース、DB・ストレージ、外部連携、ジョブ、監視、バックアップ、セキュリティ、運用設計概要まで、現場で見るべき観点を順に解説します。
あわせて、基盤基本設計で作成する成果物を整理した「基本設計成果物一覧」、設計書の構成を考えるための「基本設計書の目次サンプル」、後工程へつなげるための「詳細設計成果物例」も用意しています。
本文で説明する設計ポイントを、実際の設計書作成や成果物整理に使えるように、成果物名、主な記載内容、入力、確認観点、後続工程への申し送りまで一覧化しています。
読むだけで終わらず、自分のプロジェクトで「何を成果物として作るべきか」「どこに抜け漏れがありそうか」を確認できる構成にしています。
コメント