はじめに
システム開発における「要件定義」を乗り越え、「システムにどんな機能を持たせるか」が決まったら、次は「基本設計（きほんせっけい）」のフェーズに入ります。
基本設計とは、一言でいうと「ユーザーから見える部分（外側）と、扱うデータの骨組みを決めること」です。そのため「外部設計」と呼ばれることもあります。
このフェーズでは様々なドキュメント（設計書）が作られますが、情シス配属になったばかりの方や、他部署からDX推進部門にやってきた方にとっては、「名前は聞いたことがあるけれど、実際何を書いて、何に気を付ければいいの？」と疑問だらけになると思います。
この記事では、基本設計で作成される「代表的な5つのドキュメント」の意味と、事業会社の情シス・DX担当者が現場で本当に意識すべきポイント（リアルな罠）について解説します。
画面設計書（UI設計書）
ドキュメントの意味
ユーザーが実際に操作する「画面」のレイアウトや動きを定義するドキュメントです。 「どこにボタンを配置するか」「どんな入力欄があるか」「『登録』ボタンを押したら次に出るメッセージは何か」などを、画面のイラスト（ワイヤーフレーム）付きで細かく指定します。
💡 現場で意識すべきこと：「全部盛り」の罠を回避せよ！
画面設計で最も陥りがちなのが、「ユーザーの要望をすべて1つの画面に詰め込んでしまうこと」です。 「このデータも見たい」「あの検索条件も足して」という要望をそのまま反映すると、ボタンや入力欄がびっしり並んだ、直感的に操作できない「コックピットのような恐ろしい画面」が完成します。
メーカーの情シスであれば、「この画面は事務所の広いモニターで見るのか？」「工場の現場で、手袋をしたままタブレットで操作するのか？」という「利用シーン」を想像することが何より重要です。時には「この情報は別画面に分けましょう」と提案する勇気を持ちましょう。
帳票設計書（レポート設計書）
ドキュメントの意味
システムから出力される「紙の書類（PDF）」や「Excelデータ」のレイアウトを定義するドキュメントです。 メーカーであれば、製造指示書、検査記録表、納品書など、システムから紙やExcelを出力する要件は非常に多く存在します。
💡 現場で意識すべきこと：「そもそもその紙、本当に必要ですか？」
帳票設計に入ると、現場からは「今のExcel（または手書きの紙）と一言一句、レイアウトも1ミリ違わず同じものをシステムから出力してほしい」という強烈な要望が出ます。
しかし、ここで言いなりになってはいけません。複雑なレイアウトの帳票をシステムで作るのは、実はかなり開発コストがかかります。 DX推進担当者の腕の見せ所は、「そもそも、なぜその紙を印刷する必要があるのか？画面で確認するだけではダメなのか？」と問い直すことです。単なるシステム化ではなく、「ペーパーレス化（業務フローの改善）」を同時に仕掛ける意識を持ちましょう。
インターフェース設計書（IF設計書）
ドキュメントの意味
「今回作る新しいシステム」と「社内にある既存のシステム」の間で、どうやってデータをやり取りするか（連携するか）を決めるドキュメントです。 何のデータを、いつ（リアルタイムか、夜間にまとめてか）、どんな形式（CSVファイルか、APIか）で受け渡すのかを定義します。
💡 現場で意識すべきこと：メーカー情シス最大の鬼門！
歴史のある事業会社において、この「既存システムとの連携」は最もトラブルが起きやすく、大炎上しやすい鬼門です。 「工場の古い生産管理システム（レガシーシステム）からデータをもらおうとしたら、文字コードが古くて文字化けした」「相手のシステムが夜間は停止していてデータが送れなかった」など、落とし穴が無限にあります。
新しく作るシステムのことだけを考えるのではなく、「連携先のシステムの仕様やクセ」を早い段階で徹底的に調査し、連携先システムの担当者と密にコミュニケーションをとることが、プロジェクトを成功させるカギになります。
業務フロー図
ドキュメントの意味
「人間の作業」と「システムでの処理」が、どのような順番で進んでいくのかを図式化したものです。 システム開発のドキュメントと思われがちですが、実際には「人が確認してハンコを押す」「システムにデータを入力する」「システムが自動計算する」といった、業務全体の流れ（プロセス）を描きます。
💡 現場で意識すべきこと：システムは「業務の一部」にすぎない
システム開発に集中していると、どうしても「システムの中の動き」ばかりに目が行きがちです。しかし、システムはあくまで業務を便利にするための「道具」にすぎません。
システムを導入したことで、逆に「現場の人間がシステムに入力するための事前準備が大変になった」という本末転倒な事態を防ぐためにも、業務フロー図を使って「人間とシステムの役割分担が綺麗に回っているか」を俯瞰（ふかん）して確認することを強く意識してください。
データモデル図（E-R図など）
ドキュメントの意味
システムの中で「どのようなデータを扱うのか」と「データ同士がどう結びついているか」を図式化したものです。 例えば、「『顧客』データと『注文』データがあり、1人の顧客は複数の注文データを持つ」といったビジネス上の関係性をパズルのように整理します。基本設計の段階では、データベースの専門的な設定というよりは、「業務上必要なデータの繋がり」を論理的に整理する（論理データモデルの設計）という立ち位置になります。
💡 現場で意識すべきこと：画面の裏には必ず「データ」がある
ユーザーは「画面」しか見ないため、「この画面にこの入力項目を追加してよ」と気軽に言ってきます。しかし、画面に項目を1つ追加するということは、裏側のデータベース（データを保存する箱）の構造も変更しなければならないことを意味します。
情シス担当者は、画面設計書を作る際、常に頭の中で「この画面で入力されたデータは、どのデータモデル（箱）に保存されるのか？」を紐付けて考えるクセをつけることが重要です。ここが矛盾していると、後から「画面の入力欄はあるのに、データを保存する場所がない！」という致命的な設計ミスに繋がります。
まとめ
基本設計のフェーズは、システム開発において「ユーザーと開発側の最後の合意形成の場」です。
今回紹介した5つのドキュメントは、単なるプログラマーへの指示書ではありません。「本当にこれで業務が回りますね？」「裏側で持つべきデータに矛盾はないですね？」と、ユーザーと握手をするための大切な確認書類です。
情シスやDX担当者は、専門用語や細かい仕様に振り回されず、「現場のユーザーにとって使いやすいか？」「業務フローやデータ構造として破綻していないか？」という、全体を俯瞰する視点を持ってドキュメントに向き合ってみてください。そうすれば、その後の開発工程が驚くほどスムーズに進むはずです！
コメント