【入門】事例で学ぶ基本設計

はじめに

プロジェクトマネジメントの仕事をする際に、お客さんに提案ベースの要件定義や設計をする機会が増えてきたので、私の経験に基づいて基本設計の具体的なプロセスや考え方について整理していきます。

この記事の対象者

• 基本設計の思考プロセスを学びたい人
• ビジネスサイドの要件をエンジニアサイドのシステムに落とし込む流れを学びたい人
• ビジネスサイドとエンジニアサイドのコミュニケーション能力を向上させたい人
• 具体的な事例を通して基本設計を学びたい人

前提

• 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要です
• 自分の経験に基づいた内容を言語化しています
• プロジェクト規模は10名から20名のシステム開発を想定しています(大規模なプロジェクトを想定していません)

システム開発の全体像

今回は下記の内容のうちの基本設計について解説をします。(詳細設計についても少し触れます)

基本設計について

基本設計と詳細設計の違い

基本設計

基本設計はビジネスサイドの要件定義を実現させるために、エンジニアサイドでシステムに実装する機能を明確化、具体化していく工程です。

クライアント向けに行われる設計なので、ユーザーから見た時にどのような動作になるかを決める内容であり、「外部設計」と呼ばれる場合もあります。

基本設計の代表的な成果物としては、下記のようなものが挙げられます（あくまで一例）:

• システム構成図
• 機能一覧
• 画面一覧
• 画面遷移図
• データフロー図
• APIドキュメント
  等。

詳細設計

詳細設計は基本設計の後に行うもので、基本設計をもとに実際にプログラミングをするエンジニア向けに「どのように機能を実装するのか」を示すものになります。

いわゆる、システムの内部構造の専門的な内容を設計します。システムの内部を設計することから、「内部設計」と呼ばれる場合もあります。

詳細設計の代表的な成果物としては、下記のようなものが挙げられます（あくまで一例）:

• 画面遷移図
• クラス図
• シーケンス図
• 状態遷移図
• データベース物理設計書
• 入力仕様書
• バッチ処理詳細定義

なぜ基本設計をするのか

• ビジネスサイドの要件定義をどのように開発に落とし込むのかを決めるため
• 画面設計をもとにシステムに矛盾や抜け漏れがないかをビジネス側に共有するため
• 技術的実現可能性の確認するため

経験上、ビジネス側が「要件定義で欲しい機能は決めたから、あとはエンジニアに頼んだ！」というスタンスのプロジェクトだと後にトラブルが発生する可能性が高くなります。

そのため、基本設計ではビジネス側は決まった要件をエンジニアサイドに丸投げするのではなく、エンジニアと協力しながら擦り合わせていくことが重要です。

基本設計の流れ

本記事では基本設計における下記の3つの成果物を順に作成していきます。

1. 画面設計
2. 機能設計
3. データ設計

手順	内容	成果物
1	画面設計	画面設計書、画面ワイヤーフレーム、画面遷移図
2	機能設計	機能仕様書、ユースケース図
3	データ設計	データモデル、ER図（エンティティ-リレーションシップ図）

現場によって、他にも必要な成果物が出てくるので、あくまで一例として考えてください。

要件定義の成果物

本記事で紹介する基本設計は、下記の記事で作成した要件定義書をもとに作成していきます。

• 要件定義書リンク (Googleドキュメント)

要件定義の機能一覧は下記のようになっています。

No	カテゴリー	優先度	要求内容
1	資料のDX化	高	資料のデジタル化による作成・整理・検索の効率化
2	ナレッジ共有	中	作成された資料を共有可能な形式に整形・保存
3	バージョン管理	中	資料のバージョン管理システムの導入
4	検索機能	高	高速で正確な資料検索機能の実装
5	資料整理の自動化	高	資料の自動整理・分類機能の追加
6	ナレッジベースの構築	低	作成された資料からナレッジベースの構築
7	バージョン履歴の可視化	低	各バージョンの変更履歴を一覧・表示できる機能
8	ナレッジ共有の促進	中	社内でのナレッジ共有を促進する機能
9	バージョン間の差分表示	低	異なるバージョン間での変更点を視覚的に表示
10	資料のセキュリティ強化	高	資料のセキュリティを強化し、不正アクセスを防止

また本記事では要件定義決まった内容のうち、優先度を考慮し。下記の項目に絞って基本設計に落とし込んでいきます。(残りは2次フェーズ以降で開発することを想定)

No	カテゴリー	優先度	要求内容
1	資料のDX化	高	資料のデジタル化による作成・整理・検索の効率化
2	ナレッジ共有	中	作成された資料を共有可能な形式に整形・保存
4	検索機能	高	高速で正確な資料検索機能の実装
5	資料整理の自動化	高	資料の自動整理・分類機能の追加
8	ナレッジ共有の促進	中	社内でのナレッジ共有を促進する機能、例えばナレッジ記事の作成と共有

画面設計

画面設計でやるべきこと

1. 登場するオブジェクトとユーザーのタスクの洗い出し
2. 1に基づいて必要な画面の洗い出しとタスクの割り当て
3. 画面遷移図の作成
4. 1~2の内容情報の配置を決めてレイアウトを確定する

1~3に関してはテキストベースで行い、4では実際に画面のワイヤーフレームを作成します。

また画面設計フェーズにおいては、必要に応じてUI/UXの担当者にも相談すると、よりスムーズに進めることができます。

1. 登場するオブジェクトとユーザーのタスクの洗い出し

オブジェクトの洗い出し

下記の機能に基づいて、登場するオブジェクトを洗い出します(叩きベースでも大丈夫です)。

No	カテゴリー	優先度	要求内容
1	資料のDX化	高	資料のデジタル化による作成・整理・検索の効率化
2	ナレッジ共有	中	作成された資料を共有可能な形式に整形・保存
4	検索機能	高	高速で正確な資料検索機能の実装
5	資料整理の自動化	高	資料の自動整理・分類機能の追加
8	ナレッジ共有の促進	中	社内でのナレッジ共有を促進する機能

1. 資料(Document):
   • タイトル
   • 作成者
   • 作成日
   • 最終更新日
   • バージョン
   • カテゴリ
   • タグ
   • 内容
   • ステータス(例: 下書き, 公開, 非公開)
   • 関連資料
   • コメント
2. ユーザー(User):
   • ユーザーID
   • パスワード
   • 氏名
   • 役職
   • 所属部署
   • メールアドレス
3. ナレッジ記事(Knowledge Article):
   • タイトル
   • 作成者
   • 作成日
   • カテゴリ
   • タグ
   • 内容
   • 関連資料
   • コメント
4. バージョン(Version):
   • バージョン番号
   • 作成日
   • 変更内容
   • 変更者
5. カテゴリ(Category):
   • カテゴリ名
   • 説明
6. タグ(Tag):
   • タグ名

わかりやすいように要件との紐付け表を作成します。

オブジェクト	対応する要件No	満たしている要件の説明
資料(Document)	1, 4, 5	資料のデジタル化により作成・整理・検索の効率化が図られ、資料の自動整理・分類が可能。
ユーザー(User)
ナレッジ記事(Knowledge Article)	2, 8	作成された資料を共有可能な形式に整形・保存し、社内でのナレッジ共有を促進する。
バージョン(Version)	1	資料のバージョン管理が可能になり、DX化の一環として効率化が図られる。
カテゴリ(Category)	5	資料の自動整理・分類機能の追加により、カテゴリ分けが可能となる。
タグ(Tag)	5	タグを利用して資料を整理・分類し、効率的に管理する。

ユーザータスクの洗い出し

それぞれ洗い出したオブジェクトに対して、ユーザーのタスクを洗い出します。

1. 資料の作成・編集・削除:
   • 新しい資料の作成
   • 既存の資料の編集
   • 資料の削除
2. 資料の検索・フィルタリング:
   • キーワード検索
   • カテゴリやタグによるフィルタリング
   • 作成日や最終更新日によるソート
3. 資料の閲覧:
   • 資料の詳細表示
   • 関連資料の閲覧
   • コメントの閲覧・投稿
4. 資料のバージョン管理:
   • バージョンの作成
   • バージョンの比較
   • バージョン間の差分表示
5. ナレッジ記事の作成・編集・削除:
   • 新しいナレッジ記事の作成
   • 既存のナレッジ記事の編集
   • ナレッジ記事の削除
6. ナレッジ共有:
   • ナレッジ記事の閲覧
   • ナレッジ記事へのコメント投稿
   • ナレッジ記事のシェア
7. 資料の整理:
   • カテゴリの割り当て
   • タグの追加・削除
   • 資料のアーカイブ
8. ユーザー管理:
   • ユーザー情報の更新
   • パスワードの変更
   • ユーザーのロール管理 (例: 管理者, 一般ユーザー)

ユーザータスク	対応する要件No	満たしている要件の説明
資料の作成・編集・削除	1	資料のデジタル化による作成・整理・検索の効率化を実現します。
資料の検索・フィルタリング	4	高速で正確な資料検索機能の実装を通じて資料の検索を効率化します。
資料の閲覧	1, 2, 8	資料のデジタル化とナレッジ共有の促進を実現します。
資料のバージョン管理	1	資料のバージョン管理システムの導入で一貫性と整合性を保ちます。
ナレッジ記事の作成・編集・削除	2, 8	作成された資料を共有可能な形式に整形・保存し、ナレッジ共有を促進します。
ナレッジ共有	2, 8	社内でのナレッジ共有を促進する機能を実現します。
資料の整理	5	資料の自動整理・分類機能の追加を通じて資料の整理を効率化します。
ユーザー管理

2. 1に基づいて必要な画面の洗い出しとタスクの割り当て

洗い出したオブジェクトとユーザータスクを元にテキストベースで必要な画面を洗い出していきます。

ログイン画面

• ユーザー名とパスワードを入力するフィールド
• ログインボタン

ダッシュボード

ユーザーが最新の情報を簡単に見つけ、重要な通知を受け取ることができる。ここでは最近更新された資料の一覧、お勧めのナレッジ記事、および重要な通知やアップデート情報を表示します。

• 最近更新された資料の一覧
• お勧めのナレッジ記事
• 重要な通知やアップデート情報

資料作成・編集画面

ユーザーが資料を効率的に作成、編集し、システムに保存または公開することができる。

• テキストエディタ
• ファイルアップロード機能
• 資料のメタデータ入力フィールド（タイトル、キーワード、カテゴリなど）
• 保存と公開のボタン

資料検索・一覧画面

ユーザーが必要な資料を迅速かつ効率的に検索し、見つけることができる。

• キーワード検索バー
• カテゴリや日付での絞り込みオプション
• 資料の一覧表示（タイトル、作成者、作成日、キーワード）

資料詳細画面

ユーザーが資料の詳細を確認し、関連するナレッジを獲得し、フィードバックを提供することができます。

• 資料の内容表示
• 関連ナレッジ記事へのリンク
• コメントやフィードバックのセクション

ナレッジベース

• ナレッジ記事の一覧表示
• 記事の検索と絞り込みオプション
• 新しいナレッジ記事の作成ボタン

ユーザーがナレッジを探求し、共有し、新しいナレッジを作成することができます。

ナレッジ記事詳細画面

• 記事の内容表示
• 関連資料やナレッジ記事へのリンク
• コメントやフィードバックのセクション

ユーザーがナレッジ記事の詳細を確認し、関連する資料やナレッジを獲得し、フィードバックを提供することができます。

管理画面

• ユーザー管理（追加、削除、権限設定）
• システムの設定（セキュリティポリシー、通知設定など）

管理者がシステムを適切に管理し、ユーザーアクセスを制御し、システム設定を変更することができます。

資料バージョン管理画面

• 各バージョンの資料を表示
• バージョン間の差分を表示する機能
• 過去のバージョンへのロールバック機能

ユーザーが資料のバージョンを管理し、必要に応じてバージョン間の差分を確認またはロールバックすることができます。

資料整理画面

• 資料の分類・タグ付け機能
• 資料の一括移動・整理機能

3. 画面遷移図の作成

洗い出した画面の遷移図を作成します。
今回の場合は下記のような画面遷移になります。

4. 情報の配置を決めてレイアウトを作成する

今まで洗い出し画面およびオブジェクト、ユーザーのタスクを整理し各画面のレイアウトを決めます。いわゆるワイヤーの作成です。

ワイヤーは大枠をPMが作成し、細かい部分はUXデザイナーと連携して調整します。これはプロジェクトの早い段階で開始し、定期的なフィードバックセッションを通じてUI/UXの改善を図ります。これにより、ユーザーのニーズに最適化され、使いやすいインターフェースの設計が可能になります。

今回は大枠のワイヤーのみを成果物として作成します。

ログイン画面

• ユーザー名とパスワードを入力するフィールド
• ログインボタン

ダッシュボード

ユーザーが最新の情報を簡単に見つけ、重要な通知を受け取ることができる。

• 重要な通知やアップデート情報
• 最近更新された資料一覧
• おすすめのナレッジ記事一覧

資料作成・編集画面

ユーザーが資料を効率的に作成、編集し、システムに保存または公開することができます。

• テキストエディタ
• ファイルアップロード機能
• 資料のメタデータ入力フィールド（タイトル、キーワード、カテゴリなど）
• 保存と公開のボタン
• 編集の場合は、初期値が格納されるようにする

「建築現場の資料作成」なので、セレクトボックスで資料ごとに入力テンプレートを用意できるようにしておきます。

【資料作成画面】

【資料作成画面(日報選択時)】

他の選択項目は今回は省略します。

資料検索・一覧画面

ユーザーが必要な資料を迅速かつ効率的に検索し、見つけることができます。

• キーワード検索バー
• カテゴリや日付での絞り込みオプション
• 資料の一覧表示（タイトル、作成者、作成日、キーワード）

資料詳細画面

ユーザーが資料の詳細を確認し、関連するナレッジを獲得し、フィードバックを提供することができます。

• 資料の内容表示
• 関連ナレッジ記事へのリンク
• コメントやフィードバックのセクション

残りの3つの下記の画面に関しては、今回は省略します。資料作成や一覧と同じような構成で作成ができるので、興味がある方は挑戦してみてください。

• ナレッジ一覧
• ナレッジ記事詳細画面
• 管理画面

機能設計

画面設計の後に、システムを実装する上で必要な機能の設計をします。

機能設計の成果物としては下記の項目が挙げられます。

• 機能名と処理内容
• 処理に必要なデータ、データの取得元 (画面からの入力、DBからの取得)
• 処理したデータの受け渡し先 (画面表示、DBへ保存)

【成果物の例】

機能設計の進め方

1. 値が変わる項目の洗い出し
2. ユーザー操作の洗い出し
3. 各機能の説明

引き続き下記の要件定義をもとに進めていきます。

No	カテゴリー	優先度	要求内容
1	資料のDX化	高	資料のデジタル化による作成・整理・検索の効率化
2	ナレッジ共有	中	作成された資料を共有可能な形式に整形・保存
4	検索機能	高	高速で正確な資料検索機能の実装
5	資料整理の自動化	高	資料の自動整理・分類機能の追加
8	ナレッジ共有の促進	中	社内でのナレッジ共有を促進する機能、例えばナレッジ記事の作成と共有

1. 値が変わる項目の洗い出し

下記の手順で値が変わる項目を洗い出していきます

• 毎回変わる情報はどれか
• データの取得元はどこか

毎回変わる情報の整理

各画面において毎回変わる情報を洗い出します。

• 資料の内容やメタデータ（タイトル、作者、作成日、タグなど）
  • 作成済み資料内のコメント
• ナレッジ記事の内容とタグ
• ユーザーの検索クエリと検索結果

データの取得元はどこか

上記で洗い出した、毎回変わるデータの取得先を先ほど作成したワイヤーの中に書き込んでいきます。

【ログイン画面】

【ダッシュボード】

【資料作成】

【資料作成検索】

【資料詳細】

2. ユーザー操作の洗い出し

ユーザー操作の洗い出しフェーズは下記の手順で内容を整理しワイヤーに記載していきます。

• 処理が発火するトリガー
• 対象のDB
• 処理内容

【ログイン画面】

【ダッシュボード】

【資料作成】

【資料作成検索】

【資料詳細】

3. 各機能の説明

最後に今までの内容をスプレットシートやエクセルにまとめていきます。

項目としては下記となっています。

• ID
• 対象ページ
• トリガー
• 対象DB
• 処理内容
• データの渡し方

今回は画面ワイヤーに内容を全て書き込んだのでこの部分は割愛しますが、ビジネスサイドとすり合わせる際に必要な成果物なので、ぜひ作成してみてください。

データ設計

データ設計では下記の成果物を作成していきます。

• データの具体的な中身
• データベースの設計
• データの流れ

データの種類

データの種類は大きく下記の2つに分類されます。

• ユーザーが画面に入力するデータ
• データベースから読み取るデータ

データ設計の手順

1. データ構造を明確化
2. データ間の関係性の定義

データ構造を明確化

機能設計を元に、必要なテーブルを洗い出します。
必要なテーブル一覧は下記です。(一旦叩きベース)

資料テーブル (Documents Table)

Field Name	Data Type	Description
id	int	Primary key for documents
title	varchar(255)	Title of the document
content	text	Content of the document
creation_date	datetime	Document creation date
last_update_date	datetime	Last document update date
version	float	Document version
status	varchar(50)	Status (e.g., Draft, Public)
category_id	int	Foreign key from categories

資料カテゴリーテーブル (DocumentCategories Table)

Field Name	Data Type	Description
id	int	Primary key for categories
name	varchar(255)	Name of the category
description	text	Description of the category

タグテーブル (Tags Table)

Field Name	Data Type	Description
id	int	Primary key for tags
name	varchar(255)	Name of the tag

資料とタグの中間テーブル (DocumentTags Table)

Field Name	Data Type	Description
document_id	int	Foreign key from documents
tag_id	int	Foreign key from tags

ユーザーテーブル (Users Table)

Field Name	Data Type	Description
id	int	Primary key for users
username	varchar(255)	User's username
password	varchar(255)	User's password
full_name	varchar(255)	User's full name
email	varchar(255)	User's email
role	varchar(50)	User's role in the system

ナレッジテーブル (KnowledgeArticles Table)

Field Name	Data Type	Description
id	int	Primary key for articles
title	varchar(255)	Title of the article
content	text	Content of the article
creation_date	datetime	Article creation date
category_id	int	Foreign key from categories

ナレッジカテゴリーテーブル (KnowledgeArtiCategories Table)

Field Name	Data Type	Description
id	int	Primary key for categories
name	varchar(255)	Name of the category
description	text	Description of the category

資料コメントテーブル (DocumentComments Table)

Field Name	Data Type	Description
id	int	Primary key for comments
document_id	int	Foreign key from documents
user_id	int	Foreign key from users
comment_text	text	Content of the comment
creation_date	datetime	Comment creation date

データを活用するのは「ビジネス側」なので、必要なデータが揃っているかをビジネス側に共有しつつ、最終的なデータ構造を決めることが重要です。

データ間の関係性の定義

テーブル間のリレーションは下記のようになります。

• 資料テーブルは資料カテゴリーテーブルと1対1の関係を持つ。

  • 資料テーブルのcategory_idは資料カテゴリーテーブルのidを参照する。

• 資料テーブルは資料タグ中間テーブルを介してタグテーブルと多対多の関係を持つ。

  • 資料タグ中間テーブルのdocument_idは資料テーブルのidを参照する。
  • 資料タグ中間テーブルのtag_idはタグテーブルのidを参照する。

• ナレッジ記事テーブルは記事カテゴリーテーブルと1対1の関係を持つ。

  • ナレッジ記事テーブルのcategory_idは記事カテゴリーテーブルのidを参照する。

• ナレッジ記事テーブルは記事タグ中間テーブルを介してタグテーブルと多対多の関係を持つ。

  • 記事タグ中間テーブルのarticle_idはナレッジ記事テーブルのidを参照する。
  • 記事タグ中間テーブルのtag_idはタグテーブルのidを参照する。

• 資料コメントテーブルは資料テーブルと1対多の関係を持つ。

  • 資料コメントテーブルのdocument_idは資料テーブルのidを参照する。

• 資料コメントテーブルはユーザーテーブルと1対多の関係を持つ。

  • 資料コメントテーブルのuser_idはユーザーテーブルのidを参照する。

文章だけだと分かりづらいので、ER図にします。

以上で基本設計におけるす全ての成果物の作成が完了しました。

本来であれば今までの成果物である下記

• 画面設計
• 機能設計
• データ設計

を一つにまとめて可視化させビジネスサイドに共有しますが、今回は割愛します。

最後に

いかがだったでしょうか。

今回はプロジェクトにおける基本設計フェーズの進め方について解説しました。

他にも色々な記事を書いているので読んでいただけると嬉しいです。