仕様書通りに作ったのに「違う」と言われる悲劇
こんばんは！IT業界で働くアライグマです！
システム開発において「仕様書通りに作ったのに違うと言われる」という経験は、多くのエンジニアが一度は通る道です。仕様書を細かく読み込み、その通りに実装したはずなのに、クライアントや上司から「イメージと違う」「こんなはずではなかった」と言われることがあります。
なぜこのような悲劇が起こるのか？ そして、どのようにすれば防げるのか？ 本記事では、仕様書と実装のギャップが生じる原因を分析し、トラブルを回避するための対策を解説します。
仕様書通りに作っても「違う」と言われる原因
仕様書の不完全さ
仕様書はシステムの設計図ですが、100%完璧な仕様書を作ることはほぼ不可能です。開発の初期段階では見落とされがちな細かい要件や、実際に動かしてみないと分からない部分が必ず存在します。
例えば、仕様書には「検索機能を実装」と書かれていても、
- 検索結果のソート順は？
- 大文字・小文字の区別は？
- 部分一致検索か完全一致検索か？
といった詳細なルールが明記されていないことがあります。開発者が仕様書の記述から推測して実装した結果、関係者の期待とズレることがあるのです。
クライアントの期待と仕様のズレ
仕様書がクライアントの期待を完全に反映しているとは限りません。特に、システム開発に詳しくないクライアントの場合、「言語化できていない期待」が存在することがよくあります。
たとえば、
- クライアントの頭の中のイメージ：「シンプルで直感的なUI」
- 仕様書の記述：「ユーザーが一覧から選択して決定ボタンを押す」
- 実際の実装：「項目が大量にあり、スクロールが必要なリスト」
このように、クライアントのイメージと仕様の文言にギャップがあると、「違う」と言われてしまうのです。
仕様変更の影響
開発中に仕様変更が入ることは日常茶飯事です。しかし、仕様変更が文書に適切に反映されていなかったり、関係者間で共有されていなかったりすると、開発者は古い仕様のまま実装してしまいます。
結果として、
- 仕様書を基に実装したのに、クライアントは最新の仕様で確認する
- 変更が口頭でしか伝えられておらず、仕様書が古いままになっている
といった状況が発生し、「違う」と言われてしまうのです。
仕様書の解釈の違い
仕様書の記述が曖昧だった場合、開発者の解釈とクライアントの意図がズレることがあります。
例えば、
- 仕様書の記述：「ボタンを押すと処理が完了する」
- 開発者の解釈：「押した瞬間に処理を実行」
- クライアントの意図：「確認ダイアログを表示してから実行」
仕様書の表現が抽象的であればあるほど、このような認識のズレが発生しやすくなります。
仕様書トラブルを回避するための対策
仕様書のレビューを徹底する
開発に入る前に、仕様書の内容を関係者全員で確認し、解釈のズレをなくすことが重要です。
- 不明点を積極的に質問する：仕様が曖昧な場合は、開発前にクライアントやPMに確認を取る。
- フロントエンドのモックアップを作成する：画面デザインやUIの流れを視覚的に示すことで、誤解を防ぐ。
- ユースケースを具体的にする：仕様書に実際の利用シナリオを加えることで、開発者が意図を正しく理解できる。
クライアントとの認識合わせを頻繁に行う
仕様書を作成した時点で認識が合っていても、時間が経つにつれて期待値が変わることがあります。そのため、定期的な打ち合わせを行い、方向性を確認することが重要です。
- 週1回の進捗報告ミーティング
- 機能ごとのデモを実施
- 試作品（プロトタイプ）を早めに見せる
これにより、開発の途中で大きなズレが発覚するリスクを減らせます。
仕様変更の履歴を明確に管理する
仕様変更があった場合、それを開発者全員が正しく把握できるように管理することが大切です。
- 変更履歴をドキュメント化
- 変更点をSlackやNotionなどで共有
- コード管理ツール（GitHubなど）と連携する
これにより、「古い仕様で作ってしまった」というミスを防げます。
仕様書の記述をより明確にする
仕様書の表現が曖昧な場合、トラブルの原因になります。可能な限り具体的な表現を使い、複数の解釈が生じないようにします。
- 「クリックすると処理が進む」→「ボタンをクリックすると、確認ダイアログを表示し、OKを押したら処理が進む」
- 「検索機能を実装」→「ユーザーがキーワードを入力し、エンターキーを押すと部分一致検索を行う」
このように記述を具体化することで、認識のズレを減らせます。
まとめ
仕様書通りに作ったのに「違う」と言われる悲劇は、仕様の曖昧さやクライアントの期待とのズレによって発生します。
トラブルを防ぐためのポイント
✔ 仕様書を細かくレビューし、曖昧な点を事前に解消する
✔ クライアントと頻繁に認識合わせを行い、期待のズレを防ぐ
✔ 仕様変更の履歴を明確に管理し、関係者全員に共有する
✔ 仕様書の表現をできるだけ具体的にし、誤解を生まないようにする
これらの対策を実践することで、無駄な手戻りを減らし、スムーズな開発を実現できるでしょう。
開発者の皆さんが、仕様トラブルに悩まされず、より快適にコーディングできることを願っています！