ボーナス制とITエンジニアの相性

47歳さんの退職漫画が話題でしたが、フィクションとノンフィクションの狭間を行くこの漫画で主人公の47歳さんが退職を決意したキッカケはボーナスでした。ボーナスというのは過程ではなく、あくまでも成果を軸に評価した結果となります。

私もこれまでボーナス制の会社と年俸制の会社のそれぞれで中間管理職をしてきました。メリット・デメリット双方ありますが、圧倒的に年俸制のほうがピープルマネージメント上のリスクが少ないです。今回はそんなお話です。

99日目で実は本人以外はボーナスが出ていたのではないかという話が見えてくるとコメントや引用RTで激しいやり取りが行われています。役職者、従業員、外野の有象無象が様々な確度から（皆様口悪く）議論をしており興味深いです。

まずはボーナス制によるメリットについてお話していきます。

有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。

【企業側】【ボーナス制のメリット】経営上のバッファ

経営がまずくなった時に支出を変動させられる幅があるのは大きいです。

【ボーナス制のメリット】業績還元によるやる気アップ

伸びた業績分を従業員に還元することで、頑張りと報酬が連動しているように見せられるのはメリットでしょう。

かつて一人だけ退職理由に「ボーナスが出ないとやる気が出ない」と言った同僚が居ましたが、そんな彼もボーナス制の企業に移った後に起業したのでそんなに大したやる気には繋がらなかったのかなと思っています。

【ボーナス制のメリット】給与制度から飛び出した功績を出した人材への報酬

在籍年数に伴い少しずつ昇進し、少しずつ給与が上がるという環境では優秀な人材はしびれを切らして居なくなるという傾向にあります。例え新卒であっても成果が飛び出していれば給与に色をつけやすいというのがボーナス制です。もっとも、営業職でこうした評価はよく見られるものです。専門職メンバー層ではレアではないかと思います。

【企業側】【ボーナス制のメリット】懲罰としてのボーナス減・無し

ボーナス制のメリットについて経営者から聞いた中で最も興味深かったのはコレです。成果を高く出した人には色をつける。普通の人には約束した金額を出す。ここまではよくある話です。

社会規範的な事故を起こしたり、やらかした人にはボーナスを出さない。懲罰としてのボーナスというのは非常に興味深い発想でした。最後通告のようなお話です。

次からは主に社員の定着に関連するデメリットについてお話します。

【ボーナス制のデメリット】特定個人の成果"だけ"を切り出すのは難しい

ITエンジニアに対してボーナスでどう色を付けるのかというのは非常に難しいと捉えています。

例えば自社サービスにおいて施策Aが当たったとします。ではこの施策Aに関わったITエンジニアBさんのボーナスを多めに出しましょうというロジックは一見分かりやすく見えます。では施策Aを企画した企画部Cさんも多めにしましょう。これも分かりやすいです。しかし施策A自体は難易度も品質も内容も大したことがないものでしたが、ゴリゴリに営業して売り捌いたDさんが功労者です、となると社内政治が動き始めます。

もう一つの観点として、何かSaaSを導入した情シスEさんを褒める場合や、流行りの技術や外部APIを用いて施策を実装したITエンジニアFさんを褒める場合も厄介です。EさんやFさんは当該SaaSや外部APIを導入した人ではありますが、通常業務との線引が難しく、「導入にはEさんやFさんの専門性はどの程度必要だったのか。社外サポートがほぼやってくれたのではないか？」というのが他組織からのFAQも想定しなければなりません。「導入はしてくれたけど何がどう良くなったの？」と説明できない場合や「業務改善はしたが導入・運用コストも同じくらい上がった」場合は更に説明に苦戦します。

【ボーナス制のデメリット】支給タイミングと退職届けの連動

ボーナスを貰ってから辞めることの是非というのは話題になりやすいです。

労働者からすると「当然の権利だ」と捉える人が多く、経営層からすると「どうかと思う」と捉える人が多くなります。

中には意思決定のスケジュールを知り尽くし、査定が決まった頃合いで退職届けを出す人も居ます。

この当たりの妙な駆け引きは決して健康的なお話ではないなと捉えていますし、ボーナス支給タイミングで複数離職に繋がるのもリスクがあります。ボーナスを貰ったから次も頑張ろうと思える人材が多いのか、ボーナスを貰ったからここには要はないと思う人材が多いのかをしっかりと把握しないといけません。

【ボーナス制のデメリット】年俸制人材の中途受け入れ

前職が年俸制だった人材をボーナス制で受け入れる際には注意が必要です。同等の年収で転職をすると月収がダウンします。理論年収の14ヶ月割などであれば月々約15%のダウンになります。「この条件では暮らせなくなります」「ローンが払えません」という理由で辞退するケースはいくつか遭遇しました。

ボーナスは付加的なものである捉える人の場合、年収が15%ダウンすると捉える人は少なくなく、内定辞退に繋がるケースが多々有りました。結果として提示金額はボーナスを除いて前職と同等以上で提示するとようやく検討して頂けるレベルになります。

逆に理論年収の「理論」の部分を読み飛ばす人してサインする方も居るのですが、後々になってボーナスが上下することに怯える展開になるのでこれも定着の足かせになります。

入社時期によってはボーナス支給対象となる在籍日付より後になることで初回支給が半年以上後になるケースもあり、「年収って何ですか？」という疑問も頂きやすいです。オファー面談時に初回支給日を示さなければトラブルになります。

【ボーナス制のデメリット】同僚の横のラインで金額が筒抜けする

いくら「金額が個人によって違うので言わないようにしてください」と言っても無理です。国内だろうが海外だろうが人の口に戸は立てられません。

【ボーナス制のデメリット】環境要因、外的要因による目標頓挫時の評価

施策が査定期間に間に合わずリリースできなかったりすると成果評価が0になり、評価を据え置くか、過程を評価するかになってきます。単に開発に関わる問題だけが出てくれば渋い評価も納得感が出ますが、（今回のコロナ禍のような）環境要因や、企画上の頓挫などは「開発者であるあなたは頑張りましたね」で良いのかどうかは議論しなければなりません。

営業や経営の観点から言うと成果至上主義というのは分かりやすいものです。例えば識学。Bizに近いエンジニアからも理解を得られることはあります。

一方で47歳さんの漫画にもあるように「無理なスケジュールに対する残業」「週末の仕事」「個人的にはいい仕事をしていた」というのは成果至上主義の観点からすると「知らんがな」となります。障害や納期遅延の成果だけ見ると「知らんがな」は筋が通っています。

しかし下記コンテンツで紹介をした技術的負債のように、ITエンジニアの成果のうち純粋に当人による功績を語るというのは非常に難しいものです。プロダクトが訳ありで技術的負債を大量に抱えていたら開発速度も遅くなりますし、リライアビリティやスケーラビリティ、セキュリティにも問題はあります。広報担当がプッシュ通知を誤って設定したことで障害になることだってあります。

成果が「仕様どおりに動く」「リリースが早い」というものであったとして、過程であるソースコードが汚いと事業の将来に影響があります。

インフラエンジニアの場合には更に難しく、「障害なく動く」が普通だと思われると「良好な成果」はコストカットしかないようなケースもあります。安定稼働のために当たっている過程に相当する通常業務に焦点を当てなければなりません。過程と通常業務を切り分けることは難しいため、勢い障害発生時のマイナス評価はあれどもプラス評価をするシチュエーションがほぼ無くなります。

成果は重要ではあるものの、過程を無視して評価するというのはDevサイドについては違うのではないかと思います。

ボーナス制度と企業、社員双方の納得感

各社のVPoEやEMと話していても評価とその報酬は企業と社員が双方で納得するのがゴールです。

ボーナスへの期待値調整がしっかりとできていれば概ね問題はないでしょうが、伝統的な大手を除くと厄介事が増える火種になっているところをよく目にします。

どのみち採用ができないと、フリーランスやSESを準委任契約で月額支払いすることになりますし、年俸制で良いのではないかと考えています。

評価について謝る評価者はNG

47歳さんの漫画は最終回を迎えました。ここでGMが謝るシーンがあります。プラスの評価は簡単です。マイナス評価をしなければならない反面辞められると困るというシチュエーションが大変で、後からマイナス評価したことを謝るような姿勢は不信感に繋がります。ひいては他の同僚にも伝搬するので厄介です。「GMの姿勢に感動した」というコメントもありましたが、これは感動の光景ではありません。

ドラマ「逃げるは恥だが役に立つ」に出てくるIT業界では「社員を一人減らせ」と言われた上で一人を選ばなければならず、結果的にスキルが高くサバイブできそうな主人公が選ばれました。こうしたシチュエーションであれば「ごめんね」もあるかと思います。

こうした状況でない限り、送り出す際の言葉は「今までありがとう」一択です。