開発
設計書・テスト・開発進行ルールについて
設計書ルール
📌 絶対ルール
新規・改修・保守を問わず、基本的には設計書ドキュメントを作成し、開発前にクライアントに確認を取ること。
⚠️ 重要な考え方
内部的処理をどうするかよりも、クライアントが確認できて理解できるレベルのアウトプットを共有することを優先する。
🎯 目的
手戻り防止、チームプレイ
手戻り防止、チームプレイ
設計書ごとのルール
📋
要件定義書
AIでたたき台を作成し、機能要件・非機能要件を Docs で確定する
要件定義書ルールを見る
🗺️
概要設計書
承認済みの要件定義書を参照して、システム全体の構成と対象範囲を固める
概要設計書ルールを見る
🖥️
画面設計書
要件定義書と概要設計書を前提に、画面単位の仕様を Sheets で整理する
画面設計書ルールを見る
1
要件定義書ルール
案件の目的、対象範囲、機能要件、非機能要件、制約事項、確認事項を整理し、最終版は Google Docs に保存する。
必須
最低限そろえる項目
案件名、背景、目的、対象機能、対象外、機能要件、非機能要件、外部連携、権限制御、制約事項、未決事項。
運用
作り方
AI と一問一答で叩き台を作る。確定版は必ず人が確認し、クライアント確認前に曖昧表現を消す。
2
概要設計書ルール
承認済みの要件定義書を必ず参照し、対象範囲、機能一覧、画面一覧、権限概要、外部連携、データ概要を整理する。最終版は Google Docs に保存する。
前提
先に必要なもの
要件定義書が未確定のまま概要設計書へ進まない。AI で作る場合も、参照する要件定義書の URL または保存先を紐づける。
3
画面設計書ルール
要件定義書と概要設計書を前提に、画面単位で項目、入力制御、バリデーション、ボタン動作、遷移先、権限差分を整理する。管理しやすさを優先して Google スプレッドシートで保存する。
粒度
画面設計の最低粒度
画面ID、画面名、項目名、型、必須/任意、初期値、入力制御、バリデーション、ボタン、イベント、遷移先、備考を 1 画面ずつ管理する。
テストルール
📌 絶対ルール
例外なくテスト仕様書を作成し、2人以上で確認する。
バグ対応時もテスト仕様書を作成し、クライアントに提出する。
🎯 目的
チームプレイ、品質向上
チームプレイ、品質向上
テストのチェックリスト
- テスト仕様書を事前に作成する（例外なし）
- テストは必ず2人以上で実施・確認する
- バグ対応後もテスト仕様書を作成してクライアントに提出する
- テスト結果はドキュメント化して保管する
⚠️ バグ対応時も同じルールが適用されます
「軽微な修正だから」と省略しない。すべてのバグ対応にテスト仕様書が必要です。
開発進行ルール
📌 ルール
1週間以上の開発期間を要するプロジェクトでは、発注担当者と必ず定例会議または進捗会議を設置し、進捗共有と課題共有を行う。
🎯 目的
品質向上、手戻り防止、信頼性向上
品質向上、手戻り防止、信頼性向上
開発フロー
1
要件定義・設計書作成
クライアントが確認できるレベルの設計書を作成する。画面設計書・要件定義書など。
2
クライアントへの設計書確認
開発開始前に設計書をクライアントに確認してもらい、合意を得る。
3
開発実施（1週間以上の場合は定例進捗会議を設置）
発注担当者と定例または進捗会議を設置し、進捗・課題を定期共有する。
4
テスト仕様書作成・テスト実施（2人以上）
例外なくテスト仕様書を作成し、2人以上で確認する。
5
クライアントへテスト結果提出・リリース
テスト仕様書をクライアントに提出し、承認後にリリースする。
| 開発期間 | 進捗管理方法 | 備考 |
|---|---|---|
| 3日未満 | 報連相（基本ルール準拠） | 完了報告を忘れずに |
| 3日〜1週間 | 途中進捗報告 + 報連相 | 50%時点で必ず報告 |
| 1週間以上 | 定例・進捗会議を設置 | 発注担当者と定期的に共有 |