挨拶
こんにちは。
今回は、自分が関わった「画面設計書作成プロジェクト」で、「これじゃダメだ…」と痛感したポイントと、次から絶対に決めておきたいルールを備忘録としてまとめます。
設計書の内容も大事ですが、 「どう作るか」「どう運用するか」 をちゃんと意識することも大事だと痛感しました。
反省点と対策案
1. 書き方がバラバラすぎる
- フォントやサイズが人によって違う
- 項目の並びや粒度、言葉の使い方に統一感がない
- 「社員ID」「従業員コード」など、同じ意味でも名称が揺れていた
→ 結果：
レビューのたびに「毎回ここが違うな...」状態になり、後で修正コストが爆発。
対策案：
- 最初に「フォーマット見本」を1枚作る
- 使用フォント・サイズ・書式・単語ルールを明文化（命名辞書を作る）
- 項目の並び・粒度も最初に合意しておく
2. 担当範囲の分布が曖昧
- 誰がどの画面を設計しているかが不明
- 似た画面を別の人が重複して作成
- 逆に、誰も担当していない画面が後から発覚
→ 結果：
スケジュールがどんどん後ろ倒しに。
対策案：
- 最初に「画面一覧」を作り、担当者を紐づける
- 一覧に進捗（未着手／作業中／レビュー済など）を明記
- スプレッドシートやチケット管理系サイトで見える化して共有
3. メンバーの状況が見えていない
- 「実はわからないまま進めた」人が複数いた
- 進捗報告は形式的で、困っている人を拾えなかった
- 結果的に“設計書だけが進む”状態になり、実装との乖離が発生
→ 結果：
出来上がった設計書が“机上の空論”に。
対策案：
- 週1でもいいので「画面設計レビュー会」を定例化
- 各メンバーが「詰まっていること」を共有する時間を確保
- 設計者同士で内容をクロスレビューする
4. レビューを後回しにしてしまった
- 社内レビューもクライアントレビューも、全て最後にまとめて実施してしまった
- 「途中レビューだと効率悪そう」と判断してスキップ
- 結果、最終段階で大量の修正依頼が発生し、波及修正が止まらなかった
→ 結果：
- 「仕様が固まってから直そう」と思っていたが、実際は修正コストが数倍に
- 関連画面・API・設計書全体への影響が拡大して炎上
対策案：
- 進捗30〜50%時点で社内レビュー（フォーマット・方向性確認）
- 70〜80%時点でクライアントレビュー（要件整合性の確認）
- レビューコメントは「スプレッドシート」や「チケットコメント」などで管理
- 誰が・いつ・どの指摘を反映したかを記録して、トレース可能にする
設計書の精度は「最後に一気に仕上げる」よりも、「途中で何度も小さく直す」方が圧倒的に高いです。
途中レビューは時間がかかるように見えて、最終的には手戻りコストを削減する投資になります。
次から決めておきたい運用ルール
| カテゴリ | 決めるべきルール | 目的 |
|---|---|---|
| フォーマット | フォント・項目名・記法・命名統一 | 見やすくレビューしやすい |
| 担当範囲 | 画面一覧＋担当者＋進捗表 | 抜け漏れ防止 |
| レビュー体制 | 定例レビュー・社内/クライアントWチェック | 品質維持・手戻り削減 |
| 更新管理 | 変更履歴・バージョン管理ルール | 最新版を一意に保つ |
| 用語集 | 共通語彙・命名辞書 | 一貫性確保 |
まとめ
- 設計書の「見た目」と「構造」はチーム全員で決める
- 担当分布と進捗を見える化するだけで、炎上リスクは大幅に下がる
- 定例レビューで“詰まり”を可視化し、途中段階で修正する
- 最後にまとめて直すより、途中で小さく直すほうが圧倒的に効率的
おわりに
正直、今回のプロジェクトは途中までかなり混沌としていて、「設計書って何のためにあるんだろう？」と思う瞬間もありました。
でも振り返ると、問題の多くはツールやスキルではなく、運用設計（レビュー・共有・ルール決め）の欠如が原因の一つでもありました。
次からは、まずチームで「どう設計書を作り、どうレビューするか」から始めようと思いましたね。
同じように設計フェーズで苦しんでいる人の参考になれば幸いです。