基本設計をする上で大事な考え方

はじめに

システム開発では、要件定義までは順調に進んだのに、基本設計に入った途端に「本当にこの設計で使いやすくなるのか？」と不安になることがあります。特に、普段は実装寄りのタスクが多い方や、初めて PL/PM として基本設計フェーズをリードする立場になった方は、そう感じる場面が多いのではないでしょうか。

私も、要件をそのまま画面項目や処理フローに落としていった結果、次のような状況に陥ったことがありました。

• 合意した要件をそのまま画面項目にマッピングしていった結果、操作が複雑になってしまった
• 「とりあえず全部盛り」で機能を詰め込んだ結果、使いづらく、改修もしづらい設計になった
• 開発を進めるうちに、データ構造や外部連携の前提が足りていないことに気づき、手戻りが発生した

こうした経験から、要件定義で合意した内容を、そのままの形で基本設計に落とすだけでは不十分だと感じるようになりました。

この記事では、要件定義から基本設計に落としていくにあたって社内のメンバーからもらったアドバイスを踏まえ、「基本設計で大事だと感じた考え方」を整理します。同じような課題をお持ちの方の参考になれば幸いです。

基本設計とは？

まず、本記事でいう「基本設計」のイメージを簡単に整理します。

ここでは、要件定義で合意した内容をもとに、次のようなアウトプットをまとめるフェーズを「基本設計」と呼びます。

• 画面一覧、画面遷移、画面レイアウト（ワイヤーフレーム）
• 機能一覧と機能間の関連、ユースケース
• データ構造（テーブル定義、主な項目）
• 外部システム連携のインターフェース概要
• バッチ処理や定期実行処理の概要

要件定義でお客様と合意した「やりたいこと」「解決したい課題」を、「実際にどのような画面・操作・データ・処理で実現するのか」という設計者の言葉と構造で形にしていく工程だと考えています。

意識すること、大事な考え方

この章では、社内で挙がったアドバイスをもとに、いくつかの観点に整理して紹介します。

1. 要件を「構造」として捉え直す

まず前提として、要件がきちんと設計に盛り込まれていることは当然重要です。ただし、要件をそのまま画面項目のリストに起こしてしまうと、たいてい使いづらい設計になってしまいます。

ここで特に重要だと感じたのが、次のようなポイントでした。

• 要件をそのまま並べるのではなく、機能ごとの関連性を意識してグルーピングする
• 画面や機能を見たときに、「何をする場所なのか」が一目で分かる構造にする
• チーム全員が技術者であれば、ある程度の実装イメージを持った状態で設計を書く
• それを支えるデータ構造について、大枠だけでもあらかじめ決めておく

要件を「点の集合」としてそのまま扱うのではなく、「どの機能がどのデータを扱い、どういう順番で使われるのか」という線や面の構造として捉え直すことで、自然と画面や処理の構成もシンプルになっていきます。

具体例

「顧客を検索する」「顧客を編集する」「顧客に紐づく契約を登録する」という要件があれば、

• 検索 → 詳細 → 契約登録 という一連の導線で一つのユースケースとして捉える
• 顧客と契約の関係をデータ構造として先に整理しておく

「とりあえず顧客マスタ画面に全部の操作を載せる」のではなく、

• 詳細表示画面と編集画面を分ける
• 契約登録は別画面にしてウィザード形式にする

など、「使う順番」「関連するデータ」に沿った分割を意識することで、無理のない設計になっていきます。

2. 使いやすさ・直感性を最優先にする

次に重要なのが、ユーザーにとっての使いやすさです。

キーワードとして挙がったのは次のようなものです。

• 使いやすさ（ユーザビリティ）
• 操作が直感的に分かりやすいか
• 操作が楽か（クリック数はなるべく少なく）

基本設計の段階では、どうしても項目や機能を「抜け漏れなく網羅する」ことに意識が向きがちです。しかし、ユーザーの目線で画面遷移や操作の流れを追ってみると、次のような違和感が見えてきます。

• よく使う操作なのに、深い階層に隠れている
• 1 つの操作をするのに、画面を何度も行き来する必要がある
• 実務の流れと画面の流れが噛み合っていない

チェックしたいポイント

• 主要なユースケースについて、一連の操作ステップを紙に書き出してみる
• 「この操作は 1 日に何回行われるか」を想像し、頻度が高いものは特に簡単な導線にする
• ボタン名やラベル名を、業務用語に合わせて違和感がないか確認する

クリック数をただ減らすだけでなく、「ユーザーが迷わず、ストレスなく操作できるか？」という観点でワイヤーフレームを見直すのがポイントです。

3. 外部連携・バッチなど非機能寄りの前提を早めに押さえる

外部連携やバッチ処理に関しては、次のような視点が挙がりました。

• 外部連携がある場合に、インターフェース（IF）が定義されているか
• バッチ処理など、バックグラウンドの処理が必要か
• 要件（必要性）と実装難易度（コスト）とのバランスが悪い部分はないか

画面や機能に意識が向きすぎると、外部連携やバッチ処理といった「見えない処理」の検討が後回しになりがちです。これらはシステム全体のアーキテクチャやスケジュールに大きく影響します。

押さえておきたいこと

外部連携について

• データの流れ（どのタイミングで、どちらからどちらへ、何を連携するか）
• インターフェース方式（REST / ファイル連携 / メッセージキュー など）
• エラー時のリトライやリカバリの方針

バッチやバックグラウンド処理について

• どの単位で、いつ、どれくらいのデータ量を処理するのか
• ユーザー操作との関係（オンライン処理にするもの／バッチに任せるもの）

また、要件とコストのバランスを早めに議論することも重要です。

• 「あると便利だが、実装・運用コストが高い」機能はないか
• MVP（=Minimum Viable Product、最低限実用な製品）の観点で削れる部分がないか

基本設計の段階で「これは重い割に効果が薄いのでは？」と気づけると、後工程の負荷を大きく抑えられます。

4. 変更しやすさ・テストしやすさを設計段階から意識する

変更やテストに関しては、次のような観点が挙がりました。

• 変更/調整がしやすいか（柔軟性の考慮）
• テストがしやすいか

リリース後のことを考えると、要件や運用が変わったときにどこまで簡単に対応できるかはかなり重要です。ここが弱いと、少しの仕様変更のたびに大掛かりな改修になってしまいます。

変更しやすさの例

• マスタデータ化しておくべきものを、画面にベタ書きしていないか
• 将来増えそうな項目を、最低限追加しやすいテーブル構造にしているか
• 画面や API の責務を分けておき、「ひとつの変更があちこちに波及する」構造になっていないか

テストしやすさの例

• ユースケース単位でのテストケースが素直に書ける画面/機能構成になっているか
• 異常系（エラーやタイムアウト）の経路が設計上明示されているか
• バッチや外部連携の処理単位が、テスト時に切り出して実行しやすいか

「この設計だと、どんなテストケースを書くことになるだろう？」と想像しながら基本設計書を見直すと、自然と責務の切り方やインターフェースの設計も整理されていきます。

5. 性能・セキュリティ・導線といった「見落とされがちな視点」

性能やセキュリティ、画面遷移の導線については、次のような指摘がありました。

• 実装時の検索や処理が重くならないか
• セキュリティリスク
• 各機能への動線

どれも重要ですが、基本設計の段階では細かいチューニングまで決める必要はありません。「致命的にまずそうなところがないか」を粗くチェックしておくことがポイントです。

性能面の観点

• 検索条件や一覧画面で、フルスキャン前提のような設計になっていないか
• 初期表示で、不要な情報まで大量に読み込もうとしていないか
• バッチ処理で、一度に全件処理しないといけない設計になっていないか

セキュリティ面の観点

• 権限によって見えてはいけない情報が適切にマスキング/非表示になる前提になっているか
• 外部連携で扱う情報の中に、暗号化やマスキングが必要なものがないか
• 監査ログや操作履歴が必要な領域を押さえられているか

各機能への動線

• ユーザーがよく使う画面への導線が、トップ画面や一覧からすぐ届くようになっているか
• 関連機能へのリンク（例：詳細画面からの編集・履歴・関連情報）が自然に張られているか

こうした観点は、後からまとめて対処しようとすると大きな手戻りになりがちです。基本設計のタイミングで「危険な匂いがする所」を見つけておくだけでも、リスクを大きく減らせます。

まとめ

本記事では、基本設計で意識したいポイントを社内で挙がったアドバイスをベースに整理しました。

もともとの課題感は、「要件定義をそのまま設計書に起こそうとすると、本来やりたいことができない、操作しにくい設計になりがち」というものでした。今回あらためて整理してみる中で、基本設計は「要件を図にする作業」ではなく、ユーザーと開発者の両方の視点から、長く使えるシステムの土台を作る工程だと考えることが重要だと感じました。

この記事が、日々の開発タスクの合間に基本設計も任されている方や、これから PL/PM としてプロジェクトをリードしていく方にとって設計と向き合う際の一助となれば幸いです。もし他にも「自分はこんな観点を大事にしている」というものがあれば、ぜひチーム内で共有してみてください。