はじめに
前回の記事では、ユーザーに見える画面や帳票を決める「基本設計（外部設計）」について解説しました。 基本設計でユーザーと「こういうシステムを作りますね」という握手が完了したら、次はいよいよ「詳細設計（しょうさいせっけい）」のフェーズに入ります。
詳細設計とは、一言でいうと「プログラマー（開発者）が迷わずコードを書けるようにするための、内部の設計図を作ること」です。そのため「内部設計」と呼ばれることもあります。
基本設計が「ユーザー向け」だったのに対し、詳細設計は完全に「開発者向け」のドキュメントになります。ITの専門用語が一気に増えるため、情シス初心者や他部署から来たDX担当者は「ここから先はサッパリわからない…」と挫折しがちなポイントでもあります。
この記事では、詳細設計で作成される代表的なドキュメントの意味と、事業会社の情シス担当者が現場で絶対に意識すべき「リアルな罠と心構え」について解説します。
機能詳細設計書（プログラム設計書）
ドキュメントの意味
基本設計で作った画面やボタンの裏側で、「プログラムが具体的にどのような計算やデータ処理を行うのか」を細かく定義するドキュメントです。 例えば、「『登録』ボタンが押されたら、入力された日付が正しいかチェックし、Aテーブルにデータを保存して、完了メッセージを出す」といった一連の処理の流れ（ロジック）を記述します。
💡 現場で意識すべきこと：「日本語プログラミング」の罠を回避せよ！
詳細設計において、最もやってはいけない無駄な作業があります。それは「プログラムのコードを、そのまま直訳したような日本語の設計書を作ること」です。
- 悪い例：「もし変数Aが1なら、変数Bに2を代入する。それ以外なら…」
これを現場では皮肉を込めて「Excel方眼紙での日本語プログラミング」と呼びます。こんなものを書いても時間がかかるだけで、プログラマーにとっては実際のコードを見た方が100倍早いです。
情シスが設計書に本当に書くべきなのは、コードの直訳ではなく「ビジネスルール（業務上の決まり事）」です。
- 良い例：「製造実績が0以下の場合は、システムとしてあり得ないためエラーを返す」 プログラマーが知らない「現場の業務ルール」をしっかり明記することが、バグを防ぐ最大の防御になります。
テーブル定義書（物理データモデル設計書）
ドキュメントの意味
前回の基本設計で考えた「データの骨組み（E-R図など）」を、実際のデータベースサーバーに作成するための具体的な設計書です。 「社員IDという項目は、半角英数字で最大10桁まで」「入社年月日は、日付型（Date型）で保存する」といった、データの「型」や「桁数」を一つ一つ厳密に定義します。
💡 現場で意識すべきこと：「5年後のデータ量」を想像できているか？
テーブル定義を決める際、初心者は「とりあえずデータが入ればいいや」と安易に桁数や設定を決めてしまいがちです。しかし、メーカーのシステムは5年、10年と長く稼働します。
- 「今は1日100件のデータだけど、全工場に展開したら1日1万件にならないか？」
- 「部品コードは現在8桁だけど、将来的に10桁に増える計画はないか？」
こういった「将来のデータ増加（スケール）」を見越して設計できるかどうかが、情シスの腕の見せ所です。ここを怠ると、数年後に「データベースの容量がパンクしてシステムが止まりました！」という大惨事を引き起こします。
バッチ処理設計書（非同期処理設計書）
ドキュメントの意味
ユーザーが画面を操作して動く機能とは別に、「裏側で自動的に動くプログラム」の設計書です。 メーカーであれば「毎日深夜2時に、その日の工場全体の生産実績を集計して、翌朝のレポート用データを作る」といった処理がこれに当たります。
💡 現場で意識すべきこと：「正常に動くこと」より「異常事態」を考えよ
バッチ処理の設計で情シスが最も意識すべきは、「異常系（エラーが起きた時）のルートをどう設計するか」です。
深夜に誰も見ていないところで動くプログラムなので、「もし途中でネットワークが切れたらどうなる？」「エラーで止まった場合、翌朝手動で途中から再実行できるのか？それとも最初からやり直すのか？」というリカバリー（復旧）の手順まで含めて設計しておくことが必須です。 「うまくいく前提（正常系）」しか書かれていないバッチ処理設計書は、時限爆弾と同じだと心得ましょう。
API設計書（外部インターフェース詳細）
ドキュメントの意味
基本設計で決めた「他システムとのデータ連携」について、さらに技術的に深く踏み込んだドキュメントです。 「URLはこれで、データを送る時の形式はJSONで、成功した時はステータスコード200を返す」といった、システム同士が会話するための「正確な文法とルール」を定義します。
💡 現場で意識すべきこと：相手のシステムを「絶対に信用しない」
他のシステムからデータを受け取る場合、「相手のシステムが常に正しいデータを送ってくる」と信じてはいけません。
「文字数がオーバーしているデータが来たらどうする？」「空っぽ（Null）のデータが来たらシステムが落ちないか？」など、意地悪なデータが送られてきても自分のシステムを守れるようなバリデーション（チェック機構）を設計に盛り込むことが、システムを安定稼働させるための防波堤になります。
まとめ
詳細設計のフェーズは、システム開発において最も「専門的で地道な作業」が続く期間です。
しかし、この詳細設計書こそが、システムがリリースされた数年後にバグが起きた際、「このプログラムは、一体どういう意図でこういう計算をしているんだ？」を紐解くための唯一の羅針盤になります。
プログラマーが迷わずコードを書けるため、そして何より「未来の情シス（数年後の自分や後任者）が保守・運用で困らないため」に、ビジネスルールやエラー時の動きをしっかりとドキュメントに刻み込んでいきましょう！
コメント