現場で詰まった「設計のその先」が見えなかった話

「基本設計、やりました」と言えるレベルにはまだ達していなかった──
そう自覚したのは、あるプロジェクトの現場で、設計書通りに進めようとしたときでした

教育業界向けの学生管理システムの開発
要件定義の段階では「授業ごとの出欠管理」「保護者通知」「個別指導の進捗記録」が機能として定義されていました
自分は詳細設計を任され、担当画面の設計書を作成し、実装担当へ引き継ぎました

でも、開発が始まってから、思わぬ落とし穴に気づきました💧

「この“出欠管理”、出席・欠席だけじゃ足りなくない？」
「欠席理由が複数あるみたいです。保護者への通知内容が変わるので…」
「これ、個別指導じゃなくて、複数講師が見てるケースあるみたいですよ」

──え？そんなの、設計書には書いてなかった

現場で確認すると、どうやら実際の教室運用では、システム上の想定を超えたケースがいくつも存在していた。欠席理由には「体調不良」だけでなく「保護者都合」「塾側のスケジュール調整」などがあり、それによって通知文言を変えていた
出欠の入力も、教室の受付スタッフと講師が両方関与するシチュエーションがあり、入力タイミングもバラバラ
当然ながら、こうした“リアルな運用”が設計に落ちていなかったため、システム側が想定していたフローでは対応しきれず、仕様変更が相次いだ

「これ、設計がちゃんとしていなかったんじゃないの？」という空気が漂った。
けれど、よくよく考えれば、設計書に従って画面を作った側も、その設計の背景を理解できていなかった。つまり、設計の意図や判断基準が現場に伝わっていなかったのです

「設計書を見れば全部わかる」とは限らない、ということ
要件や背景が曖昧なまま形になった仕様は、運用に乗らない
あとから修正するコストは大きく、実装・テスト・リリーススケジュールに直撃する

この経験以降、自分は「仕様に“なぜ”を持つこと」にこだわるようになりました
なぜこの項目が必要なのか
なぜこのロジックになっているのか
なぜこの運用フローなのか

「背景を知らずに仕様だけを渡される怖さ」を、一度でも経験すると、設計の意味が一段と重くなる
もしこれから設計に関わる人がいるなら、ぜひその“なぜ”に目を向けてほしいです✨
それが、実際に使えるシステムを作る第一歩になるから☺️