0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

開発をスムーズに進めるために!プロジェクト進行に必要な資料まとめ

Posted at

プロジェクト進行に必要な資料を作成するには?

ディレクション初心者やシステム開発の流れを知りたい人向けに解説!

こんにちは、ディレクターとしてプロジェクトを進行している ぐみ です。

システム開発の現場では、プロジェクトをスムーズに進めるために、さまざまな資料を作成します。

  • 「どのタイミングで、どんな資料を作ればいいの?」
  • 「ディレクターは何を用意すればいいの?」
  • 「デザイナーや開発者が必要な資料は?」

こんな疑問を持つ方も多いのではないでしょうか?

この記事では、プロジェクト進行のフェーズごとに、どの資料を、誰が作るのかを整理 しました。
さらに、プロジェクトの規模に応じて、省略できる資料・省略すべきでない資料 も解説します。

「ディレクションが初めての人」「システム開発の流れを知りたい人」に向けた内容ですが、
経験者でも「この資料、本当に必要?」と考える際のヒントになるはずです!

📑 プロジェクト進行フェーズごとの資料作成一覧

まずは、プロジェクトのフェーズごとに、ディレクター・デザイナー・開発者 が作成する資料を整理しましょう。

フェーズ ディレクター担当 デザイナー担当 開発者担当
① 要件定義 仕様書(文章)、機能表(表)、フローチャート(業務フロー) - -
② 基本設計(仕様策定) 状態遷移図(データ・画面遷移) 画面設計書(ワイヤーフレーム+UI仕様)、スタイルガイド -
③ 詳細設計(実装仕様) 詳細仕様書(文章) UIデザイン(高解像度のデザインデータ)、アニメーション仕様書 シーケンス図(APIの通信・データの流れ)、DB設計書
④ 開発・実装 必要に応じて仕様修正 必要に応じてデザイン修正 実装仕様書(詳細設計の補足)
⑤ テスト・検証 テスト仕様書 - 単体テスト仕様書

📘 各担当の資料の詳細説明

👤 ディレクター担当の資料

1. 仕様書(文章)

🎯 何のために作るの?
システムの目的や概要、できること、できないことを整理するための資料です。
関係者全員が「何を作るのか」を共通認識として持つために必要です。

💡 いつ作るの?
プロジェクトの最初(要件定義フェーズ)

2. 機能表(表)

🎯 何のために作るの?
システムに必要な機能を一覧にして、優先度や必要な要件を整理するための資料です。
例えば、「ログイン」「決済」など、具体的な機能の整理に役立ちます。

💡 いつ作るの?
要件定義フェーズ

3. フローチャート(業務フロー)

🎯 何のために作るの?
ユーザーの操作の流れを図で整理するための資料です。
「どこで分岐があるのか?」「どの画面へ進むのか?」が視覚的にわかります。

💡 いつ作るの?
要件定義フェーズ

4. 状態遷移図

🎯 何のために作るの?
画面やデータの「状態」と、それがどのように変化するのかを整理する資料です。
例えば、「注文が完了すると、状態が"支払い待ち"から"支払い完了"へ変わる」などのルールを図にします。

💡 いつ作るの?
基本設計フェーズ

👤 デザイナー担当の資料

1. 画面設計書(ワイヤーフレーム+UI仕様)

🎯 何のために作るの?
画面のレイアウトや、ボタン・入力欄などのUI要素を整理するための資料です。
「このボタンを押したらどこに遷移するのか?」といった動きも記載します。

💡 いつ作るの?
基本設計フェーズ

👤 開発担当の資料

1. シーケンス図

🎯 何のために作るの?
APIの通信や、システム内部でのデータのやり取りを整理するための資料です。
「どのタイミングで、どのデータが送られるのか?」を明確にします。

💡 いつ作るの?
詳細設計フェーズ

2. DB設計書

🎯 何のために作るの?
データベースの構造を整理する

💡 いつ作るの?
詳細設計フェーズ

📌 プロジェクト規模に応じた資料の省略・簡略化

プロジェクトの規模によっては、すべての資料を作成する必要がない場合 もあります。
以下の基準を目安に、プロジェクト規模に応じた資料の取捨選択 を行いましょう。

🔍 小規模プロジェクト(3人以下、期間:1ヶ月以内)

💡 特徴:少人数でスピーディーに進めるため、最低限の資料でOK!

省略できる資料

  • 詳細仕様書(口頭やチャットで共有し、仕様変更に柔軟に対応する)
  • シーケンス図(簡単なメモやホワイトボードでの説明で済ませる)

省略しない方がいい資料

  • 仕様書・機能表(最低限、要件の共有は必要)
  • フローチャート(開発者と共通認識を持つ)
  • ワイヤーフレーム(UIの基本構成は整理する)

🔍 中規模プロジェクト(10人以下、期間:1〜3ヶ月)

💡 特徴:チームメンバーが増えるため、ある程度のドキュメントが必要

省略できる資料

  • 詳細仕様書(文章量を最小限にし、必要な要件のみ箇条書きで記述する)

省略しない方がいい資料

  • 仕様書・機能表(各メンバーが仕様を正確に理解するため)
  • 状態遷移図(データや画面の状態を明確にする)
  • ワイヤーフレーム+UI仕様(開発とデザインの連携をスムーズにするため)

🔍 大規模プロジェクト(10人以上、期間:半年以上)

💡 特徴:関係者が多くなるため、すべての資料をしっかり作成しないと混乱する

✅ 必須資料(省略できないもの)

  • 仕様書(詳細)(開発者・デザイナー・QAが迷わないよう、明確に記述)
  • 状態遷移図(画面やデータの遷移を整理する)
  • 画面設計書(詳細版)(開発者が理解しやすいよう、デザインシステムを整理する)
  • シーケンス図 各APIのリクエスト・レスポンスの流れを明確にする。

💡 まとめ

✅ プロジェクトの役割ごとに必要な資料を整理しよう!

  • ディレクター:プロジェクトの目的・仕様・業務フローを整理し、関係者全員が理解しやすい資料を作る。
  • デザイナー:画面設計書やUI仕様を作成し、開発とデザインの連携をスムーズにする。
  • 開発者:シーケンス図やDB設計書を作成し、システムの動作やデータの流れを明確にする。

✅ プロジェクトの規模に応じて、必要な資料を選ぼう!

  • 小規模(3人以下 / 1ヶ月以内):最低限の資料(仕様書・機能表・フローチャート・ワイヤーフレーム)を用意。
  • 中規模(10人以下 / 1〜3ヶ月):状態遷移図やUI仕様を加え、開発者とデザイナーの認識をそろえる。
  • 大規模(10人以上 / 半年以上):全ての資料を作成し、開発の進行や品質を担保する。

✅ 「ドキュメントを作ること」が目的ではなく、「プロジェクトをスムーズに進めること」が大切!

  • 必要な資料を適切に作成し、関係者全員がスムーズに作業できる環境を整えよう!

この記事を参考に、最適な資料を作成して、プロジェクトを成功に導きましょう! 🚀

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?