営業の無茶振りか？ITエンジニアの自己満足か？

こんにちは！中小企業診断士、ITストラテジストの岸本慎介です。 20年以上プログラマーやシステム開発者としてIT業界を内側から携わっています。また2014年には中小企業診断士の登録を受け、IT業界を外側から分析する機会を得てきました。前回は働き方改革の要諦となる「生産性」の正しい意味と、生産性向上のために必要な「便益」という考え方を紹介しました（IT業界の働き方改革　第1回／あなたの報酬は何に対する対価なのか）。今回は視点を変えて、IT業界の営業の考え方、エンジニアの考え方が、それぞれ生産性向上を阻んでいる、という話をしたいと思います。

1.　営業とエンジニア（開発）の衝突

9月から10月にかけて、10月後半に実施される中小企業診断士の2次試験の受験生にとって、最後の追い込みの時期となります。ちなみに、中小企業診断士の試験は、1次試験がマークシートでの選択式で主に知識を問われ、2次試験は記述式で企業の事例をもとに出題されます。その中には製造業の事例問題もあり、営業と開発（製造部）が意思統一されておらず、お互いに不満を持っているというパターンも少なくありません。

営業と開発の衝突は、製造業に限らずIT業界でも当然のように起こっていますし、むしろ他の製造業よりも衝突が起こりやすい環境にあるかもしれません。自分自身はITエンジニアとして担当営業に恵まれたのか、あるいは単に自分が鈍感すぎて営業の無茶振りに気づいていないだけなのか分かりませんが、営業に不満を持つような場面には遭遇していないので、典型的な衝突の事例を探してみました。

ちなみにこの話、元ネタはリクルート『Tech総研』様のサイト（下記）にあった事例で、筆者の頭の中で話を膨らませました。この記事は2005年のものですので、少なくとも12年前には出てきているわけです。古くて新しい課題なのですね。

どう反撃する？エンジニアvs営業☆壮絶バトルシーン｜【Tech総研】

この話のように、営業の知識不足で実現不可能な案件を取ってくる事例のほか、コストや納期が非現実的で、納期に間に合わせるためのしわ寄せがエンジニアに来てしまう例や、営業は案件を取ってくるだけで後の作業は開発に丸投げ、無茶振りという例なども、典型的な事例としてよく耳にします。

2.　衝突を回避するには

上記のような衝突が発生すると、営業が安値で受注してしまった案件を、長期にわたってエンジニアが開発を行うことになります。多くのエンジニアをつぎ込むことにもなり、利益も出ませんから、生産性（前回のおさらいですが、付加価値（利益＋人件費）を労働者数で割ったもの）は当然下がってしまいます。このような問題を未然に防止するために、「基本的な知識不足で営業を行わないでほしい」と考えているエンジニアは少なくないでしょう。また、工数や開発期間については、「営業が独断せず、エンジニアに見積を確認すべきだ」という意見もあると思います。そういった意見や不満は間違っていないですし、先ほどの話のように営業側に改善が必要な場合も多いでしょう。

ですが、営業側の改善のために、エンジニアができる行動はないのでしょうか？また、その行動を実際に取っているのでしょうか？例えば下の表のように、営業の知識不足を補うためにエンジニア側から取れる対策はいくつか考えられるでしょう。

3.　エンジニアの自己満足

そして、長く開発現場にいて感じるのが、私自身も含めた多くのエンジニアが、与えられた作業に対してこだわりを持ちすぎている、言い換えれば（表現は悪いですが）自己満足に陥っている、という問題です。例えば、新人のITエンジニアが試験手順書を渡されて作業を始め、記載されたとおりの結果が出なかったとき。プログラマーが設計書に従ってコーディングを行い、設計書の記載漏れでロジック（プログラムの内容）が決められなくなったとき。上級システムエンジニアが要件定義の結果を受けて基本設計を進める途中、要件が確定していないために設計を進めることができなくなったとき。こういったとき、彼らがどのような行動を取るか、想像できますでしょうか。自分が見聞きした範囲、もちろん自分が担当者としてやってしまった範囲も含めて、彼らの大半は同じ行動を取ります。それは、「自分で調べて、自力で解決しようとする」なのです。この行動は、エンジニア以外の方には、ちょっと意外だったかもしれません。

自力で解決しようとしたとき、その先にどのようなトラブルが待っているか、先に挙げた例ごとにまとめてみます。「行動1」は考えられる中でまだしも影響が小さいもの、「行動2」は多くのトラブルを引き起こしてしまったものと考えてください。

【例1】

新人のITエンジニアが試験手順書を渡されて作業を始め、記載されたとおりの結果が出なかったとき

（エンジニアの行動1）

自分で想定通りの結果が出ない理由を調べ、プログラムに不具合があることを発見してリーダーに報告した。

（行動1に対する結果）

既知の不具合で、別のプロジェクトで改修が決まっているので、調査も不要だった。

（エンジニアの行動2）

自分で調査した結果、特定の条件では期待通りの結果になることを確認し、OKとして試験を終了させた。

（行動2に対する結果）

顧客への納品後に不具合であることが発覚し、瑕疵対応として同じ処理を行っている箇所をすべて洗い出し、再試験することになった。

【例2】

プログラマーが設計書に従ってコーディングを行い、設計書の記載漏れでロジックが決められなくなったとき

（エンジニアの行動1）

他の設計書の同様の処理箇所などを参照するが、結局のところ確信が得られないため設計担当者に確認する。

（行動1に対する結果）

単なる記載漏れで、設計担当者が想定していたロジックがすぐに回答されてくる。

（エンジニアの行動2）

プログラマー自身が、適切だと思うロジックを検討し、自己判断でそのロジックでプログラムを作成してしまう。

（行動2に対する結果）

設計者の想定していたロジックとは異なるため、不具合となってしまい、テスト工程以降で設計書を修正することになって工数が増大する。

【例3】

上級システムエンジニアが要件定義の結果を受けて基本設計を進める途中、要件が確定していないために設計を進めることができなくなったとき

（エンジニアの行動1）

要件に現れていない設計項目であることには気がついたが、レビュー時に確認すれば良いと考えていったん保留。

（行動1に対する結果）

レビュー時に顧客への確認が必要なことが発覚し、設計終了までの時間が掛かってしまう。顧客への確認後、設計を修正して再レビューとなる。

（エンジニアの行動2）

要件として定まっていないため、考えられるあらゆる条件を想定し、そのすべての場合に対応できるような設計を構築してプロジェクトを肥大化させてしまう。

（行動2に対する結果）

顧客からはそこまで作成してもらえるなら、という話になってしまい、肥大化したプロジェクトのまま、コストや納期は変わらず後続の作業に進んでしまい、進捗遅れの要因となる。

問題が発覚した時点で、「すぐに誰か情報を持っている人に問い合わせれば良いのに」と考えるかもしれません。ですが、彼らはそれを確認せず、自己解決するために、多くの時間を使ってしまうのです。結果的に行動2のように多くのトラブルを引き起こしてしまうことにもなるのですが、自分で解決することを優先してしまいがちです。

なぜそのような行動を取ってしまうのか、エンジニア側の言い分もあるでしょう。質問しようにも上司や担当者が忙しくて質問するタイミングが取れない、あるいは自分の力で調べることで、自分自身の知識となって将来の成長の糧になる、などなど。

しかし、「自力で解決する」というのは自分が納得するためだけの行動に過ぎなく、生産性向上、プロジェクトの成功、顧客の便益といった、本来の目的の達成からは遠ざかることにもなってしまいます。それは、エンジニアの自己満足と呼ばれても仕方がないでしょう。

4.　まとめ：衝突を避け、自己満足に陥らないために

営業とエンジニアの衝突という文脈で、エンジニアの自己満足といえば「エンジニアは顧客の要望を聞かずに、自分の作りたいものしか作らない」といった営業側の不満を指すことも多いかと思います。この視点は重要ではあるものの、すでに多くの議論がなされている論点でもあり、今回は別の切り口で取り上げてみました。営業の知識不足で衝突や混乱を引き起こしたり、エンジニアが自己解決を目指してかえってプロジェクトを肥大化させたりすることで、短納期、低コストで多くの作業を要求されることになります。これは工数の増大と売上・利益の低下を招きますから、必然的に生産性は大きく悪化することになってしまいます。

いずれの問題も、エンジニアから見れば営業部門、顧客、開発部門内の他の担当者や上司などとの関係構築がうまくいっていないために起こってしまうことです。普段から話しやすい環境を作れるに越したことはありませんが、そうでなくとも問題があれば速やかに質問、相談、共有する、という意識を持つことが大事だと考えます。

余談になりますが、調べればすぐにわかることを質問するのは恥ずかしい、ということもあるかと思います。同語反復的ではありますが、「調べればすぐにわかることは、調べればすぐにわかる」のだから、「ここまで調べて解決しなかったら質問しよう」といった線を最初に引いておく、という方法であれば、人に聞くのを躊躇することも減らせるのではないでしょうか。

今回は営業とエンジニアの衝突、またエンジニアが陥りがちな「自己満足」について考えてみました。次回は、これまで2回の問題提起を踏まえて、より俯瞰的な視点からの考え低来たいと思います。