基本設計工程を終えて – 担当した設計と標準を振り返る

はじめに

現在、私が参画しているプロジェクトの 基本設計工程 がひと段落しました。約4か月間取り組んできたのですが、正直なところ体感では「半年分くらい働いたのでは…？」と思うほど、濃密で残業も多い期間でした（笑）。

せっかくの区切りなので、この記事では 「標準的に言われる基本設計とは何か」 を整理してみたいと思います。

基本設計

基本設計の目的

基本設計工程は、要件定義で決めた「何を作るか」を、システムとして「どう作るか」に落とし込む段階です。
ユーザーや関係者にとってイメージしやすい形でシステム全体像を整理し、後の詳細設計や実装に迷いが出ないようにすることが大きな目的です。

特に以下の役割があります。

• 利用者や業務担当と合意形成をする
  画面イメージや業務フローを見せて「こういう仕組みになるんですね」と確認できる
• 後工程に引き継ぐための設計基盤を作る
  詳細設計・実装に迷いが出ない粒度にする
• テスト観点の土台を作る
  この仕様ならどうテストするのか？が見えてくる

基本設計でやること（標準的な項目）

一般的に、基本設計では次のような作業を行います。

• 画面設計:画面一覧、画面遷移図、入力項目定義
• 機能設計:バッチ処理の流れ、業務フロー、エラーログ出力方針
• インターフェース設計:API仕様、外部システム連携の入出力
• 非機能設計:性能・セキュリティ・運用設計など
• 共通設計:命名規則、エラーコードやメッセージ一覧、共通処理方針

補足：要件定義から詳細設計までの流れ

• 要件定義
  システムで「何を実現するか」を決める工程。
  例：業務フローの整理、ユーザーがやりたいことの洗い出し、必要な機能・非機能要件の明確化。
• 基本設計
  要件定義で決めた内容を「どう実現するか」に落とし込む工程。
  例：画面設計、データモデル、インターフェース設計、非機能要件の方針決定。
• 詳細設計
  基本設計をもとに、プログラマが迷わず実装できるレベルまで具体化する工程。
  例：画面ごとの入力チェックルール、DBの物理設計（型・インデックス）、処理アルゴリズムや関数の分割方法。

担当した基本設計

• システム化業務フロー
• プロセス仕様
• 画面設計
• API設計

システム化業務フローとは？

業務フローとの違い

• 業務フロー
  要件定義でよく作成され、業務全体の流れを図式化したもの。
  As-Is（現状）や To-Be（システム導入後）を表し、ユーザーや業務担当と合意形成するのが主目的。
• システム化業務フロー
  基本設計で作られることがあるドキュメントで、業務フローをシステムの視点に落とし込み、「どの処理をシステムで支えるか」を明確にしたもの。
  業務の「どこを人がやるのか」「どこをシステムが担うのか」を整理し、機能一覧や設計の土台となります。

作るケース・作らないケース

• 作るケース
  • 大規模システムで業務とシステムの境界をはっきりさせたいとき
  • 新規開発で「どの機能で業務を支えるか」を丁寧に整理する必要があるとき
  • 関係者が多く、システム化範囲を明示しないと認識がずれる恐れがあるとき
• 作らないケース
  • 小規模プロジェクトや改修案件で、システム化範囲が明確なとき
  • 「業務フロー」＋「機能一覧」で十分合意できるとき

必須のドキュメントではなく、プロジェクト規模や状況に応じて作られるようです。

プロセス仕様とは？

プロセス仕様の役割

プロセス仕様は、システム化業務フローで定義した処理単位ごとの仕様を整理するドキュメントです。
フロー図だけでは表現しきれない「入力 → 処理 → 出力」のルールや分岐条件を文章や表形式で定義し、後続の画面設計やAPI設計につなげる役割を持っています。

典型的に盛り込まれるのは以下の内容です。

• プロセスの概要（どんな処理か）
• 入力条件や前提条件
• 処理の流れ（分岐条件、アルゴリズム概要）
• 出力内容や結果の扱い
• エラー時の処理方針

標準的な扱い

実は「プロセス仕様」という名前で必ず作るわけではありません。
多くの現場では「機能仕様書」や「処理仕様書」「ユースケース記述」などの形でまとめられることが多いみたいです。

• 作るケース
  • 処理が複雑で、画面仕様やAPI仕様だけでは表せない場合
  • 機能ごとに担当を割り振る必要がある場合
  • レビューやテストを「処理単位」で行いたい場合
• 作らないケース
  • 小規模システムで、処理が単純な場合
  • 画面仕様やAPI仕様の中に処理仕様を含めれば十分な場合

つまり、「プロセス仕様」は必須ではありませんが、どの現場でも似たような役割を持つ成果物は存在すると言えます。

まとめると

「プロセス仕様」という形で必ず作るわけではなく、現場の進め方次第です。
でも役割としては「業務フローから落とし込んだ処理単位の仕様を補足するドキュメント」なので、名前や形式は違っても、多くの現場で同じような成果物は存在しています。

画面設計とは？

画面設計の役割

画面設計は、ユーザーが実際に操作するUIをどう作るかを定義する設計工程です。
基本設計の中でも利用者にとって最も分かりやすい部分であり、システムの使いやすさや理解度に直結します。

標準的には、次のような内容が盛り込まれます。

• 画面一覧／画面遷移図：どんな画面があり、どう遷移するか
• 項目定義：各入力項目や表示項目の名前、型、桁数、必須／任意など
• 処理仕様：ボタン押下時の処理や遷移先
• エラー・制御仕様：入力チェックや状態による制御（活性／非活性など）

この画面設計をもとに、詳細設計やフロントエンド実装が進められていきます。

API設計とは？

API設計の役割

API設計は、システム内やシステム間でデータをやり取りする仕組みを定義する設計です。
画面やバッチ処理が「何を呼び出すか」を明確にし、詳細設計や実装の前に関係者で合意を取るために作られます。

基本設計でやるのか？

• 基本設計でやる場合
  • 画面や業務フローと密接に関わるため、利用シーンごとにAPIが必要かどうかを決める
  • 入出力項目やエンドポイントを大枠で決め、利用者や関係者と合意形成する
  • 他システムとのインターフェースも基本設計で仕様を固めることが多い
• 詳細設計でやる場合
  • 基本設計では「この機能はAPIで実現する」と決めるだ
  • 実際のパラメータ定義、レスポンス構造、エラーコードなどは詳細設計で記載する
  • 特に内部APIは詳細設計以降に落とし込むケースも多い
    基本設計で「APIを使うこと」と「ざっくりした入出力項目」まで決めるのは一般的ですが、
    細かいパラメータや制御は詳細設計でやるケースが多いみたいです。

まとめ

今回あらためて「基本設計」について整理してみて、自分のやってきたことを振り返る良い機会になりました。

プロジェクトはいよいよ詳細設計工程に入ります。
次回は「詳細設計とは？」をテーマに記事を書いていこうと思います。