こんにちは、IT業界30余年、シルバーSEのおかかです。
「この仕様でよろしく」って言われたけど、よく見ると曖昧でツッコミどころ満載。なのに「納期は変えられない」って、それって無理ゲーじゃない？そんな理不尽な要件の押し付け、プロジェクトでは珍しくありません。
この記事では、なぜこうしたことが起きるのか、どう対応すればいいのかを解説します。若手エンジニアでも実践できる方法を紹介しますので、ぜひ参考にしてください！
■ なぜ「曖昧な要件」が押し付けられるのか？
- 発注側も要件を固めきれていない
業務が流動的だったり、上層部の決裁が遅れていたりするケースでは、要件が「とりあえずこんな感じで」になりがちです。 - 中間に入るPM・営業の伝達ミス
伝言ゲームのように内容が変わっていく。結果として「え、そんな前提聞いてない！」が発生します。 - 「早く動いてほしい」圧力
詳細を詰める時間より、開発を始めることが優先されてしまう雰囲気があり、準備不足のままスタートすることも。
■ よくある「曖昧な要件」の実例
- 「ユーザビリティを意識して」って、どのユーザー層？
- 「帳票をExcelで出力」って、見た目は？レイアウトは？
- 「通知が飛ぶように」って、誰に？どのタイミングで？
こういうグレーな表現のまま、設計を求められると非常に困ります。
■ 対処法：エンジニアとしてできること
① 曖昧ワードを明確化するための質問リストを持つ
「通知とは誰に対して何を知らせるものでしょうか？」
「ユーザーの操作フローはどうなっていますか？」
など、定型的に聞けるテンプレを持っておくと便利です。
② 決まっていない部分は「仮」で進めて確認をとる
すべてが決まらないまま進めるしかない場合、「現時点ではこの前提で進めます」と一筆書いて、合意をとるのがベターです。
③ 仕様書に「未確定」や「要確認」などのラベルをつける
仕様を文書化するときは、あえて曖昧な箇所を目立たせておくと、後で「言った・言わない」論争を防げます。
④ 背景を探る（なぜ曖昧なのか）
そもそも、クライアントが何に悩んでいるのかを想像すると、質問の切り口が変わります。ただし、正面から「それでは困ります」と突っぱねると関係が悪化するので注意。
まとめ
要件が曖昧なまま押し付けられる――これ、誰もが一度は経験する悩みです。でも、そのまま受け取るのではなく、「どこが曖昧か」を可視化し、少しずつクリアにしていく姿勢が大事。プロジェクトに巻き込まれるのではなく、前向きに巻き返すスタンスで行きましょう！
コメント