要件が必要以上に複雑になるなあ、と感じるのは受託業務をしていてよくある風景である。
何かやりたい（状況的にやらざるを得ないとき）が、目的が不明瞭か、内向き（上司や社内）にある場合、機能拡充に目を向ける傾向があると思う。
必要性に質問すると、ニッチな状況を例として挙げて「こういう場合、どのような対策をお考えですか？」と逆質問で切り替えされることが多い。注意文や免責文など掲載したり、発生確率が少なければ人的対応の余地を残しておいても問題ない範囲、と私は思ったりするのだが、全自動化にこだわる担当もいらっしゃる。
IT技術が好きで、熱心に勉強されている担当者がこの傾向にあるように思う。「ITのプロに発注するけど、自分の方がよく知っている」というオーラを全面に出す方もいる。用語をよくご存じで、この時期だったら「HTML５を使った面白い提案はないですか？」というツール決め打ちで、考えを組み立てる傾向があったりする。
勉強熱心だったり、利用想定を細かく洗い出す想像力は素晴らしいのであるが、サイトやシステムを構築する目的や運用まで加味した費用対効果、関係者（発注側は当然、受注側も含まれる）のリソース配分などを総体的にみると、こだわるポイントではないなあ、と感じることがある。
受託側の立場でいうのも何だが、IT技術は何かをするためのツールでしかないので、目的が不明瞭な要件については、実現手段は何でもよいと思っている。制作したツールを使って何を実現したいか？ではなくツールを制作する行為自体が目的になっている場合は、要件定義を曖昧のまま設計の話題で盛り上がるのだが、何か出来てきて、リリース間近になるとブレ始めて、リリース前から追加や改修依頼が発生してしまう。
要件が途中で変動しない場合でも、受注側が「ズレている」と感じるポイントにコダワリが強いと、制作側のモチベーションが堅くなるので、ちょっとしたサービス提案を控えてしまうことになる。「言われた通りにやったけど、イマイチ何をしたいのか分からないし、やっぱり微妙〜」と思いながらリリースを迎えることになる。
でも発注側（というか多くの場合、窓口担当者）が満足すればよい、という概念が双方にあるため、受注側は意見があっても言わないことが多い。代わりに、要件が少しでも増えると拒絶をすることになる。「1ページ増えたから、○○円かかります」とかつまらない交渉になる。
要件確認の際、実施内容の目的や成功の定義を、受発注双方で共有することが幸せな展開になるのは間違いない。ただシステム化を伴わないウェブサイトは効果を数量化するのが難しいので、アクセス解析やコンバージョンなどという考え方を意識してもらい、リリース後にも関与できるような取り組み方をするのがよい。当初は要件をシンプルにして、本当に必要な部分だけをリリースし、様子を見つつ次の段階を一緒に考えるような取り組み方が、ウェブをつかったツールには合っていると思う。