📖
経営管理、特にソフトウェア開発の分野では、従業員がより高い効率と生産性で目標を達成できるよう動機づけるためにインセンティブが設計されています。ただし、インセンティブが適切に策定されていないと、スタッフの意図しない行動を助長するなど、望ましくない効果が生じる可能性があります。
経済学者のゲイリー・ベッカーは、人はインセンティブに反応するという主張のおかげで、1992年にその分野でノーベル賞を受賞した（もちろん、それに関して彼が行ったすべての研究も）。ベッカーによれば、この犯罪は不合理、精神疾患、または単なる社会的影響によっては説明されず、犯罪者は利用可能なインセンティブに反応した単なる合理的な行為者であったという。
この現象は最近、開発者の Santiago L. Valdarrama 氏によるバイラルなツイートで簡潔かつユーモラスにまとめられ、表面的な指標に基づいてプログラマーの仕事に報酬を与えようとすることがなぜ失敗につながるのかを説明しています。
ヴァルダラマ氏は、同じ会社がこの分野で起こり得る間違いをすべて経験するという寓話として自分の事例を紹介しています。もちろん、通常はそんなことは起こりませんが、これらのいずれかに該当する企業の例を見つけるのは簡単です。
最初の間違い: バグに注目すること
それはすべて、「より多くのバグを修正した人にはもっとお金を支払おう」という一見論理的な措置から始まります。
これは単純なアプローチであり、最も勤勉な開発者に報いるようです。ただし、ツイートの投稿者が指摘しているように、この戦略はすぐに会社に不利になる可能性があります…
…なぜなら、バグの原因を考慮せずに、解決されたバグの数だけを報酬とすることによって、一部の開発者は、後でバグを修正してその後の報酬を得ることができることを期待して、コードに意図的なバグを導入する誘惑に駆られる可能性があるからです。
したがって、システムはソフトウェアの品質を向上させる代わりに、意図的なエラーの生成を奨励します。
有名な事例
実際には、明示的なインセンティブ ポリシーが含まれていない場合でも、開発者は自分でバグを生成し、それを解決しなければならないという誘惑が常に存在します。
少し前に、ペンシルバニア州のシーメンスで働いていた 62 歳のソフトウェア開発者、 デビッド A. ティンレーのケースについてお話しました。彼はスプレッドシート システムに (「ロジック爆弾」を使用して) 障害をプログラムしました。同社は電子機器の注文を管理し、電子機器を「修理」して料金を請求できる唯一の企業であることを確認していたこと、
問題が発生したとき、シーメンスはティンリーに問題の修正を依頼し、彼はコード内のカウンターをリセットするだけで、今後のエラーと自身の再雇用を確実にしました。この不正により、ティンリー氏は2014年から2016年までその職に留まることができたが、同年5月にティンリー氏が休暇中に緊急事態が発生したため、シーメンス社がパスワードを要求した。
同社はコードにアクセスすることで不正行為を発見した。そして最終的に、ティンリーには懲役6か月と罰金7,500ドルが言い渡された。
2 番目の間違い: 「新機能」に焦点を当てる
この寓話の中での管理者の次の（悪い）アイデアは、 「より多くの新しい機能を開発する人にはもっとお金を払う」というものだった。
一見すると、これは以前のものよりも合理的なインセンティブのように聞こえるかもしれません。結局のところ、新機能は製品に価値を追加します。ただし、実際には、何が「新機能」であるのか、何がそうでないのかについての明確な基準がないため、一部の開発者は小さなタスクを大きな進歩として再解釈する可能性があります。
したがって、インターフェイスの小さな変更や些細な調整は「イノベーション」として提示される可能性がありますが、時間、労力、計画を必要とするより複雑で重要なプロジェクトは追い出されます。
Googleの例
ただし、会社がプロジェクトをどのように管理するかによって、これは異なる影響を与える可能性があります。つまり、新しい機能は確かに関連性があります…しかし、その機能を維持することに溶媒は誰も興味を持っていません。
Google の開発者が「LPA サイクル」（「ローンチ、プロモーション、放棄」と呼ぶ）と呼んでいるものに対して Google が経験した社内批判については、少し前にすでにお話ししました。これは、Google におけるプロフェッショナルとしての進歩が、何よりもまずベースにあることを意味します。リリース (または、せいぜい「メジャー リビジョン」) に参加することはできますが、「『メンテナンス』や『壊れたものを修正する』ことで昇進する人は誰もいません」。
「経験豊富で野心的なエンジニアは全員、立ち上げ後すぐにプロジェクトを離れ[…]、昇進のためにより多くの単位を獲得できる新しいプロジェクト/チームに移ります。残っているのは、他のチームに簡単に移ることができない人たちです。 、経験が浅い、または単に平凡なエンジニア。
3 番目の間違い: コードの行数で測定する
取るに足らないタスクが奨励されているという不満から、 「より多くのコードを書いた人にはもっとお金を払う」という別の問題解決策が浮上した。
ここでの推論は、コードの量が増えるほど作業量と生産性が向上すると解釈することです。ただし、現実はさらに複雑です。質よりも量を優先することで、開発者はプロジェクトに冗長なコード、空白行、または不要なコメントを埋め込むことができます。コードは効率化する代わりに量が多くなり、保守が困難になり、長期的にはシステムに過負荷がかかり、製品品質の低下につながります。
4 番目の間違い: コミット数より優れた指標はありません。
公平な報酬方法を見つけようと必死になっているマネージャーは、業界で最も使用されているコード リポジトリである GitHub へのコミット数に基づいて開発者に報酬を与えることを決定しました。ここでもまたすぐに問題が浮上します。
プログラマーは作業を小さな部分に分割し始め、 「1 行のコード、1 つのコミット」という小さなアクションごとにコミットを行います。その結果、実際の進歩を反映していない小さな変更が際限なく繰り返され、生産性統計が水増しされています。
5 番目で最後の間違い: 指標なんてクソだ、レビューに目を向けよう
一連の失敗の後、会社は最終的に、より腐敗しにくいと思われる解決策を選択します。それは、 「同僚の評価 (つまり、従業員の同僚の意見) に基づいて、より多くの報酬を支払う」というものです。このアイデアは、同僚が各開発者のパフォーマンスを評価する共同作業環境を促進することを目的としています。
しかし、多くの企業では、この種の戦略は社内政治への扉を開きます…政治が腐敗するのは難しいと考えていることを想像してみてください。もちろん、えこひいきや権力闘争によってコードの品質はすぐに脇に追いやられますが、戦略的提携を結んで批判を回避する能力が成功の真の指標となります。
問題の根本
この話の教訓は、定量化可能で適用しやすい指標の探求は夢物語だということです。なぜなら、それは通常、ソフトウェア開発者の仕事に内在する複雑さの見落としに基づいているからです。コードは、開発者が実行する単純な一連のタスクではありません。数値または速度で測定できます。