エンジニアのやる気は報酬だけじゃ維持できない：開発チームを作ろう（2）（3/3 ページ）

[佐藤大輔，オープントーン]

　では今度はNさんの立場に立って、あらためてプロジェクトを振り返ってみましょう。

　本来、彼はフリーのエンジニアですから、モチベーションの基本が報酬と作業量・時間のバランスです。多くのエンジニアは、ほかに技術的興味やメンバーとの親愛の情、あるいは顧客や仲間の評価などをモチベーションの源泉にしている場合が多いようです。

　ただ、彼は技術にもチームメンバーにも顧客にも、興味はありません。彼自身が述べているように、時間とお金を引き換えにして、プロジェクトに参加しているのです。つまり、Nさんは自身を「レンタルプログラミングマシン」としています。そのことを前提に作業しにきている作業者にとって興味があるのは、自身の作業時間と作業内容だけです。

　最初からプロジェクトの成否を含めたいかなる「プロジェクト全体の事情」にも、いささかも興味ありません。実は私は彼のようにモチベーション自体を失ったエンジニアをたくさん見続けてきました。そういうエンジニアに出会うたびに悲しい気持ちになります。しかし、そんなふうにエンジニアのモチベーションをそぐ大きな問題があるのです。それは、エンジニアの「頑張り」に対して見合わない評価や報酬です。心血を注ぐに足る「見返り」が与えられないことも多くあります。そして、非常に困ったことに、顧客企業は彼らに対して、そういったモチベーションとスキルを要求するだけの十分な報酬を払っていると思っていることです。

　これはどういうことでしょうか？

　今回元請けとの間に2社の仲介者を挟んでいます。元請け企業が払う業界標準的な単価を仮に「100万円／月」としてみましょう。発注元と受託先の間に2社挟まっている今回の場合、Nさんの報酬はいくらになるでしょう。

　通常、企業は利益を粗利ベースで30％程度と見込んでいます。50％や20％としている企業もありますが、平均して30％程度を目標にしている会社がほとんどです。さて、顧客企業は月100万円を支払う一方で、Nさんが受け取る金額を計算してみてください。元請け企業をA社としてその1次請けをB社とします。さらにB社は仲介をしているだけでC社がNさんと契約を交わした会社だとしましょうか。そうすると、以下の表のようになります。

図3 30％の場合

　何と、彼の手に渡るのは……、顧客企業が払った100万円のうち34.3万円だけです。家庭を持つ彼の元に渡るのは、残業代込みで経費（交通費等）なしの34.3万円。むちゃな話です。仲介のB社とC社は、仕方ないので利益を削ってNさんに多く支払います。すると今回は利益率20％ということになります。Nさんは下記の表のように、残業代込みでどうにか51.2万円が確保できました。

図4 20％の場合

　さて、このような操作によって、「顧客企業が払っている金額」と「Nさんがもらえる報酬」は何と2倍も離れてしまいました。そう。「顧客企業が求める頑張り」と、Nさんが「そこまで頑張ったらもらえる報酬」は何と2倍も離れてしまっているのです。

つまり、元請け企業は「これだけ払っているのだから」と考え、「作業がなければ自分で探してでも貢献せよ」と要求するのが普通です。それに対して、Nさんは「そこまで責任を負うほどギャラをもらっていません」と反応します。

　問題の本質が見えてきたでしょうか？ 「Nさんは顧客企業が求める “やる気”には程遠い」というふうに見えていました。しかし、その事実は「顧客企業の求めるやる気（責任）を要求されるほどもらっていない」という事実へと変わっていきます。いったい何が間違っていたのでしょう？ 「お金だ、報酬だ、見返りだ」と主張せず、Nさんは割に合わなくても責任を持って作業をすべきだったのでしょうか？ 「そうしていれば、いつかは報われる……かもしれない」と自分を説得すべきだったのでしょうか？ ちなみに私自身はそうすれば報われると考えています。しかし、「それをすべての人に押し付けるのはムリだ」とも思っています。

　何を改善すればこの問題は解消されるのでしょう？ 皆さんの中で悪者が浮かんできたでしょうか？ たぶん皆さんがいま思っているのは「間の会社が取り過ぎていないか？」という疑問でしょう。

　ところで、粗利30％は暴利でしょうか？ 他業種のさまざまな経営者に聞いてみてください。粗利ベースで30％は暴利か否か。意外と「粗利？ ならそんなものでは？」という答えが多いと思います。その30％を分解して見てみましょう。

　まず、リスクがあります。ここでNさんが予想外にパフォーマンスの出ない人だった場合、間に入っている会社はおのおのの責任で「交代要員」を探さないといけません。そのときには、場合によってはより高度な技術者を「おわび」として入れないといけなかったりします。え？ そんな品質の悪い技術者を取り扱ったりしないって？ ではその人が本人の責任によらない事故に遭ったらどうしますか？ 顧客からは同じような対応を求められるでしょう。

　また純粋なプロジェクトリスク。仕様やバグの問題など最後の押し付け合いの中で「属人的な問題である。Nさん自身かその会社が責任を取るべきである」という「『不当』判決」が下る場合もあります。

　さらには引き継ぎの問題です。引き継ぎの際に、半月やひと月、新任と並行稼働を顧客から求められるケースはままあります。Nさんだって「システムのライフサイクルそのものがあなたの任務期間です」という事態には耐えられないでしょう。並行稼働の経費はそういった仲介会社の責任で持たされるケースも往々にあります。

　開発期間6カ月程度の5つの案件につき、1人月程度の問題対応コストが発生するとすれば、1/30（30人月に対して1人月）のプロジェクトリスクを積む必要があります。そうすると、100万を基準にした場合3.3％（3万円程度）ですね。

　さらに純粋に経費です。契約の印紙代や、名刺代などは大した問題ではありませんが、営業や管理者の人件費も発生します。最初の面談や人集めの手間そのものは無論、週に1度は顔を出し、顧客の不満や要望を聞き、あるいは技術者の抱える問題や不満を聞き、交渉を行う。移動や何かも積み上げて半日が消えるとすれば、同じように100/20*4で10％（10万）は必要になります。

図5 人件費

　さらに、単純な支払いのリスク。顧客の検収が伸びたり、入金のスパンが非常に長かったり。それでも、Nさんには毎月払わなければなりません。先払いのリスクなどで、もう5％程度は欲しいでしょう。おや、経費だけで18％になってしまいました。粗利は30％も取れればよい案件という話でしたね。今回の事例でも20％です。実際は突き詰めればもう少しは下がりますが、以外に「暴利」ともいい切れない事情が見えてきたでしょうか？

　企業とは利益を追求する存在です。さらに突き詰めて何％か下げることができるかもしれません。しかし、「商い」としてこの会社が本案件を見たときに「じゃあ、ほかのことをした方がワリがいい」ということになってしまうのです。つまり、「粗利が一定水準以上ないならほかのことをした方がよい」ということになってしまいます。

　人を集めるのも大変だし。現場や営業担当者のストレスも高いし、リスクもあるし。今回のA社、B社のように20％の利益で十数％のリスクやコストで手元には数％しか残らないのなら「いっそやらない方がよい」仕事になってしまいます。余談ですが、さらに利益の半分は税金ですしね。

---

　結局、「悪い人」がいなくなってしまいました。

　ではもう一度論点を整理してみましょう。

• Nさんは規定時間以上の作業をしない。もらっているお金以上の責任は追わない
• Nさんが作業をしないのでほかの人がNさんの作業を肩代わりすることになってしまった
• Nさん的には報酬に見合う作業と責任を負っている
• 顧客企業が求める作業や責任はもっと高いもので、顧客企業の払っている報酬は見合っている
• 双方の求める成果と報酬は実は見合っていない
• その差分は、多くの仲介企業に消えている
• 仲介企業も思われているほど割に合っているわけではない

　……誰も満足も得もしていないですね。不思議なことに。少なくとも誰かが得をしているから、誰かが損をしている。という構造ではないようです。さて、ではいったいどうすれば、Nさんは「ひどい評価」をもらわずに済んだのでしょうか？

　実はここには業界の本質ともいえる考えれば考えるほど心（エンジニア魂）が沈むネガティブな部分が潜んでいます。たぶん、この解決策は多くはありません。1つの解は、前述の「多くのエンジニアは、ほかに技術的興味や、メンバーとの親愛の情、あるいは顧客や仲間の評価などをモチベーションの源泉にしている場合が多いようです」ではないかと考えています。

　逆に顧客企業は「自分が払っている金銭的報酬が実はそれだけで技術者の献身に見合うものではないかもしれない」ということを理解しておく必要があります。ですから、顧客企業側のチームリーダー・マネージャーであるこの記事を読む多くの「上級エンジニア」の方に願うしかありません。金銭的報酬をつり上げるには限度があります。多くのエンジニアはそれを理解しています。

　ですから、金銭的以外の報酬を常に与えられる模索をしてください。「それは経営者の仕事」あるいは「営業の問題」と割り切らず、少なくとも自分のチームメンバーに与えられるものがないかもう1度自分の机の引き出しをかき回してみてください。「コードの美しさ、面白さをいっている暇があったらドキュメントを書きなさい」という前に、ちょっとだけ、その技術に対するモチベーションを褒めてあげてください。少なくとも、彼らは「飲み会が多いので、ドキュメントを書けません」といっているわけではないのですから。

　そして、エンジニアの皆さん。常に「自分が受けている金銭的に不当な扱い」にそれなりの理由があることを理解してください。そのうえで、常にほかの報酬も求める意識の高さを持ち続けてください。職人が己の作品の完成度と自身の習熟に報酬と同じ程度のモチベーションを見いだしているように。

　はっきりといえることがあります。すべての関係者が「やってあげている」という意識ばかりを強く抱くようなプロジェクトはうまくいきません。顧客はエンジニアの「献身度」に疑問を持ったときに、この記事を思い出してください。単に怒鳴りつけ「切る・切らない」という前に、一度だけ思い直してみてください。エンジニアは、顧客が困っているそのときに、もう1度だけ精いっぱいのサービスを提供してみてください。たぶんそれだけで、Nさんのような事例は大きく減る……そう考えています。

アンケート実施中!!

記事を読んで以下の投票にご協力ください。 次回の記事作成は皆さんと一緒にさせていただきたいと思っております。今回の事例をご一読なさって＆御自分の身の回りのプロジェクトを鑑みてプロジェクトへのモチベーション一番高まるのは以下の内どれを獲得したときといえますか？

1.金銭的報酬

2.顧客からの評価

3.チームメンバーからの評価

4.技術的冒険、技術的スキルアップ

5.平和なプロジェクト（プロジェクト以外のことをバランスよくできること）

「開発チームを作ろう」バックナンバー

• スキルシートと単金だけで開発チームは作れない
• 良い顧客が良いITプロジェクトを作る
• すごい技術者はすごいマネージャになれるか？
• エンジニアにとっての本当の「顧客」は誰？！
• エンジニアのやる気は報酬だけじゃ維持できない
• スキルシートでいったい何が分かるのか