非エンジニアな発注者や経営者やプロジェクトマネージャーは、開発の実務や現場のエンジニアの目線がわからないために、善意や正しいつもりで、エンジニアの退職を引き起こしかねない地雷を踏み抜くケースが多いので、傾向と対策をまとめてみました！

元ネタ：

地雷1 「～なら簡単だろ？」系

エンジニアは、技術で問題を解決するプロフェッショナルです。自分ではできない専門的なお仕事を専門家に依頼する時にもっともダメなのが「～なら簡単だら」というワードです。

ベストは、「◯◯という問題がありますが、どのような解決策が考えられますか？」という形で、素人が思いついた解決策ではなく、解決したい問題を相談する形のコミュニケーションがベストです。

最低でも、「◯◯を作りたいのですがどれぐらい時間はかかりますか？」という聞き方にとどめましょう。

地雷２ 不具合への理解不足

まず、誰が作っても完璧なシステムは絶対に作れません。

システム開発では、エンジニアがどんなに注意しても技術があっても、必ず不具合は発生します。そして非エンジニアは知らないのですが、システムを依頼する際にシステムの完成像が不明瞭なまま、設計やプログラミングにとりかからせてしまうことが、不具合を引き起こす最大の原因です。なので不具合や障害の原因は、プログラマーではなく指示をした上司や発注主が原因であることが多いです。そのような中に、不具合や障害を咎める発言は、エンジニアが離職する原因になります。

次に、どんなに時間をかけて分析や設計をしても、優秀なエンジニアでも、注意を払って開発をしても、必ず不具合や障害は発生します。そのため、必要以上に不具合や障害の発生に怯えてテスト時間を獲りすぎると、システムをリリースする頻度は落ちていきます。リリースする間隔が長くなればなるほど、逆にリリースした時に不具合の発生確率はあがり想定以上に大きな不具合が起きやすいです。不具合や障害をゼロにするよりも、こまめにリリースして速やかに対応できる体制をつくりましょう。

地雷 3 とりあえず人数を充足しようとする

開発の遅れを取り戻すために安易に人を追加したり入れ替えするのはダメです。例えベテラン・エンジニアでも、不慣れな技術の習熟に一ヶ月〜数ヶ月かかりますし、初めて参加するプロジェクトの流儀を理解するのに二週間〜一ヶ月はかかります。

人を追加すると良くてもその間のパフォーマンスはゼロで見こむ必要があります。それどころか現在のメンバーのレベルより低いメンバーをいれると、プロジェクトが進むのではなく、メンバーの面倒をみるのにベテランエンジニアの手が取られたり、よくわかっていないまま開発に参加することで不具合を大量に発生させてプロジェクトが遅れたりなどします。

地雷4 やる気の問題にする

プログラミングのお仕事は、営業のようにマインドさえあれば明日からでも成果を出せるということがありません。長期間に渡るトレーニングとトラブルシューティングの経験値を積み重ねて初めて一人前にできるようになります。

例えるならば、東大受験の数学をあなたは解けますか？

もし東大受験の数学の問題を解かされて解けない時に「本気でやっているのか？」「６問しかなくて試験時間は１５０分なのに１日たっても１問も解けないのか？」と言われたらどう感じますか？

技術的なお仕事には小学生レベルの難易度から東大受験レベルの難易度までさまざまな難易度のお仕事があります。また、エンジニアのレベルも偏差値８０から４０まで様々です。

エンジニアに割り当てたタスクが進まない時は、お仕事の難易度とエンジニアの技能があっていないので、できるエンジニアをメンター的にあてて、起きていることをキチンとヒアリングすることが重要です。

「やる気」とか「考え方」のような精神論では解決できませんし、残業をひたすらさせて時間をかけても解決しません。

地雷5 仕事を依頼する側が雑すぎるパターン

失敗する開発プロジェクトは、開発チームの問題や開発のススメ方の問題よりも、開発を頼む側の問題であることが大半です。

「解決すれば期待した効果が手に入る解決すべき問題をキチンと特定していますか？」

 「リソースの制約条件や前提条件をきちんと把握していますか？」

「効果的・効率的・快適に解決される適切な解決策ですか？」

システムではなくまず「お仕事」の設計をキチンとしていますでしょうか？プロジェクトの成功の８割はそこにかかっています。