  |
AIに聞くだけで特に指定してないのに建設的な方法で解決する方法まで書いてくれる
ここからさらに実務に即した背景入れたらもっと建設的な議論できるようになるだろうな
① 指摘が厳しくなる背景
エンジニアにとっては、曖昧な仕様書や不完全な情報は業務上致命的です。
エンジニアは「曖昧な仕様書」＝「何を作ればいいのか不明」＝「作業が始められない」と判断するため、厳密な仕様確定を最優先にします。
が発生します。そのため「不備を指摘する＝責任を果たすこと」であって、悪意や性格の悪さからではありません。
文面にあった指摘の仕方も、決して新人さんを攻撃しているわけではありません。
「この指摘を解消しないと作業が始められない」は事実であり、優先度を示すための表現であって攻撃ではない。
チャットなどのテキストコミュニケーションでは表情やトーンが伝わりにくいため、端的に書くことで重要な情報を正確に伝えようとしています。
また、開発部から見れば、「営業側の新人教育」は営業部の責任です。「新人さんがパニックになる」ということ自体はエンジニア側が管理する範囲外の問題であり、指摘の内容に問題がない以上、指摘したこと自体を責められるのは筋違いです。
③デザイナーとの違いについての誤解
デザイナーとエンジニアのコミュニケーションスタイルが違うのは当然です。
エンジニアが細かく「指摘」をするのは性格の悪さではなく、業務の特性上、事実確認を徹底する必要があるからです。
仕様が曖昧なまま進むことが許容されると、後に「こんなの頼んでない」「なぜ勝手に決めた？」と責められるリスクがあります。
エンジニアが明確に仕様を詰めようとするのは、自分たちが責任を問われる立場にあるからです。明確な仕様があれば、後からのトラブルを避けられ、自分たちも安心して作業に集中できます。
全体会議で「エンジニアの性格の悪さ」として議題に上げるのは問題の本質を見誤っています。
「エンジニアの性格が悪い」といった個人攻撃になってしまうと、感情的対立を深め、業務改善にならない可能性が高い。
本質的に議論すべきは「部門間のコミュニケーション方法の改善」「仕様定義プロセスの改善」です。
例えば、
エンジニアも仕様詰めに早期に参加させ、早い段階で問題を洗い出す
「配慮を持って優しく接する」「感情面に気を配る」のは確かに重要ですが、業務を正確に進める上で必要な情報や改善点を伝えることが優先されるべき場合があります。
エンジニアからすれば、指摘を「優しく遠回し」にすると、重要度や緊急性が薄まり誤解されるリスクが高まります。
営業や発注側が「丁寧なコミュニケーション」を求めるならば、エンジニア側に最初から正確な仕様書を提供する責任も同様に伴います。
今回の件を感情的に議論するのではなく、以下のような建設的な方法で解決することを提案します。
発注書作成に関して、エンジニアと営業で共有可能なチェックリストを作成し、「仕様漏れ」を未然に防ぐ。
チャットのコミュニケーションルール（表現方法や言葉遣い）について相互に合意形成する。
新人研修の際に「エンジニアが求める仕様の精度と理由」について教育する。
素晴らしい分析と言語化。
8