何でできないの？

　あなたがこのせりふを口にすると、険悪な雰囲気の中で、ただただ不満をぶつけ合うだけのコミュニケーションになってしまいがち。

　まずは、エンジニアが「できない」と言った背景や理由（例えば工数不足、技術的な制約、納期に間に合わないなど）を把握し、理解しないといけない。そして、一緒に問題を解決していく姿勢を示すことが大切だ。

その作業必要なの？

　プログラムの仕様を変えることなく、ソースコードそのものの品質を上げる「リファクタリング」という作業がある。こうした作業の必要性を理解せずに、無駄な仕事をしているように受け取って、イラつく人も結構いる。

　将来的な開発工数の削減や、システムの安定性の向上、運用負荷の軽減などにつなげるべく、「取りあえず動いている」だけの状態を改善していく。こうした作業は、エンジニアと現業の担当者との“いさかい”のもとになりがちだ。

　エンジニアの視点からは極めて重要だが、プログラミングやその仕組みを知らないビジネスパーソンは、作業の価値や意味を理解しにくい。コミュニケーション不全が起きがちだ。

（安易に）ここ修正しておいて

　すでに仕様が固められ、開発が進んでいるタイミングで、「簡単に修正できるでしょ」とばかりに修正を依頼する。エンジニアが途方に暮れる一言だ。

　依頼された内容が「修正」にとどまらず、仕様を大幅に変更しなければいけないレベルの話になることもままある。

　また、修正箇所がプログラムを書く量としては少なかったとしても、ドキュメントの修正や関連するテストのやり直しなども含め、それによって新たな作業が発生してしまう場合がある。

　修正を依頼するなら、修正が影響する範囲や、それによる手間の程度もイメージしておきたい。