Yahoo! JAPAN

チームの成長を左右するエンジニア採用、手探り状態での新人の受け入れ、名ばかりになりがちなOJT……開発組織を率いるリーダーやマネジャーたちが担う業務は、どれもこれも難しいものばかり。自分の判断や対応のミスがチームのパフォーマンスに影響すると思うと、その責任から目を背けたくなることもあるかもしれない。

そんな時にぜひ手に取ってほしいのが、2025年6月11日に発売された出石聡史さんの新著『エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた』（翔泳社）。発売に合わせて、エンジニアtypeでは本書内のエピソードを特別に転載して紹介した。

【試し読み】開発組織のリーダーたちに贈る、マネジメント“失敗”の教科書！ 書籍『エンジニア育成現場の「失敗」集めてみた。』https://type.jp/et/feature/28548/

ここでさらに、二つのエピソードを紹介しよう。今回紹介するのはエンジニアの「評価」をテーマにしたエピソードだ。

目次

はじめに成果がはっきりしない「ほんわか目標設定」 ーーできたできないの押し問答結局成果は上がったのか？評価はリーダーの心をむしばむ憂鬱イベント年の功で成果が得られるわけではない成果があやふやな成果主義「動詞」の成果目標には要注意問題しか見えない「バグチケット起票型上司」 ーー問題を指摘するのが仕事失敗ばかりを突き付けられる問題ばかりを指摘する上司成果をアピールしない部下「減点法」の魔力に屈してしまう「いいとこ探し」をしよう書籍情報

はじめに

本書で扱う架空の組織とプロジェクトについて

本書ではエンジニアの採用や育成の失敗を追体験できるよう、架空の開発組織とプロジェクトを舞台にしたエピソードを紹介します。また登場人物も明らかにフィクションであるとわかるように、全員ロボットにしています。ただ、それ自体重要な要素ではありませんので、あまり気にせずに読み進めていただければと思います。

成果がはっきりしない「ほんわか目標設定」

ーーできたできないの押し問答

技術者にとって自分の評価は気になるところです。自分の技術で事業に貢献した部分は組織からも認めてほしいものですが、その素晴らしい成果が誰によって成し遂げられたのか、組織が正確に理解していないこともあります。俺の成果だとわかるだろ？ それぐらい察しろよ、なんて言っても無理です。リーダーは上司にわかりやすく部下の成果をアピールしないと、部下の頑張りに報いることができません。

結局成果は上がったのか？

ロボチェック社では半年に1回、従業員の業績評価を行い、ボーナスを出すことになっています。従業員それぞれ半期の間に出した成果に応じてランクを決め、そのランクに応じてボーナスが決まる仕組みです。

開発部全員のランクは最終的にブチョーさんが決めるのですが、ハルさんのチームに関しては、メンバーの活躍をよく知るハルさんがまず一次評価を行います。今日はその一次評価のための個人面談です。

ハル：シンテクさん、半年間お疲れ様。今日はボーナスを決めるための面談です。いつものように目標シートで成果を説明していただけますか？

ロボチェック社は4月に各自の業務目標を決め、目標シートに記載します。これをもとに9月末までの成果を記載して提出することになっています。

シンテク：えーとまずスキンチェッカーの開発っス。目標は測定部の作成で予定通りっス。それから……。

ハル：ちょ、ちょっと待って。そんな目標だった？ 測定部の作成？ 測定部ってもうできていたっけ？

シンテク：このシートは4月に書いたものっスよ。測定部もできているっス。えーと、時々止まるのと、原因不明のビット欠けがありますけど。

ハル：できてないじゃん。いや、まー目標が「測定部の作成」というなら、作成はやったと言えるのだろうけど、測定部にはまだ問題が残っているよね……。

シンテク：でも目標は達成っス。ボーナス出たら新しいPC買う予定っス。というかボーナス見越してもう発注済みっス。

シンテクさんはそう言いますが、この問題で1か月の遅れが発生しているため、ハルさんの感覚だと、目標を満額で達成できたとは思えません。確かにシート上は目標を達成したように見えるのですが。とりあえず、シンテクさんのシートは一旦このままにして、引き続きノビシロさんとも面談です。

ノビシロ：測定アプリの目標は外注完了でした。ただまだなんのリリースも受け取っていませんので、目標は未達成です。

ハル：いやいやアプリはもともと12月にα版リリースじゃなかった？ 今9月だから予定通りじゃないの？ というか「外注完了」が目標なら、達成できているんじゃないの？ でも発注だけで達成ってのもおかしいなあ。

4月に各自と面談を実施し目標を決めたはずでしたが、今になってその目標自体があやふやなことがわかり、目標が達成できたかどうか判断できません。

ハル：まいったなあ。目標が達成できたのかどうかわからないぞ。プロジェクトとしては遅れているけど、一方で各自プラスの業務を実施しているような気がするし。どうしたらいいんだ……。

評価はリーダーの心をむしばむ憂鬱イベント

リーダーにとって期末の評価は最も憂鬱なイベントでしょう。そもそも他人を評価するなんて、おこがましいにも程があります。下手に高い評価を付ければ上司から根拠を尋問され、むやみに悪い評価を付ければ部下が納得するまで面談バトルが待っています。とはいえ自分のチームメンバーにはできるだけよい評価を付け、できるだけ高いボーナスをあげたいので、ここはひとつ頑張るしかありません。上司が成果を評価し、成果に応じてインセンティブを提供するのが成果主義の仕組みだからです。

年の功で成果が得られるわけではない

その昔、企業では年功序列といって、勤続年数や年齢の上昇に従って高い給料や高いボーナスがもらえるという仕組みが採用されていました。そのため、評価や査定といったプロセスの重要性も薄く、特別なことといえば功労者に特別ボーナスを出す程度のものでした。

しかし、現在では多くの企業で、成果主義が取り入れられています。年功序列では無理に高い成果を出さなくても、最低限の業務をこなせばよいと考える人もいて、従業員の成長や挑戦する意欲をそいでしまいます。「なんであの窓際で毎日新聞読んでいるだけの上司が、アタシより給料もらっているのよ！　というか、なんでアタシがお茶出さないといけないのよ！　自分でやれムキー」と不満が爆発していたはずです（たぶん）。

従業員が成長しなければ、企業の業績も成長しません。企業としてできることが増えないからです。そこで企業は成果を出せば出すだけ報酬が得られる、成果主義をこぞって導入するようになりました。

成果があやふやな成果主義

成果を出した人ほど認めてもらえる。お金が儲かる。それっていいじゃない？ むしろ公平じゃない？ とみんな思っていたのですが、実際に成果主義を導入してみると次のような課題がいろいろと出てきます。

・評価基準が不明瞭（成果って何？　何ができたら成果なの？）
・業務による差（プログラマーと庶務はどっちが高評価？）
・タイミングの問題（まだ開発途中なので失敗以外に成果がない）
・個人主義（チーム全員で頑張ったのに、なぜリーダーだけ高評価？）
・評価対象以外の業務を軽視（やっても評価されないことはしない）
・結局相対評価（原資が限られているから全員高評価はムリ）
・働きすぎ（量で成果をアピール）
・もとからできない目標（これぐらいできないとプラス評価はやれん！）
・評価者によるバイアス（あいつはダメなやつだ）
・被評価者と評価者のずれ（成果出したVSそんなの成果ではない）

何より問題なのは「何ができたら成果と見なせるのか」という点です。成果が何かもわからないのに、評価もへったくれもありません。そのため多くの企業では期初に「成果の目標」をすり合わせし、その目標が達成された場合に成果が出たと評価できるようにしています。ところがこの目標を設定すること自体が難しく、第三者的に測定可能な目標になっていないことも多いのです。そのため、評価の時期になって、「達成した」「いや達成していない」という押し問答が始まってしまいます。

ここが今回の失敗ポイントです。目標の設定を測定可能かつ達成可能な「成果物」として定義しなかったため、評価にあいまいさを残してしまいました。評価があいまいだと、リーダーは高い評価を付けたくても上司に明確なエビデンスを示すことができません。一方、評価されるメンバーもこんなに頑張って仕事したのに評価されない、認めてもらえないという、承認要求を満たせない状況に陥ります。技術者にとっては、お金をもらえたとしても、自分を認めてもらえなければ満足できませんし、そんな組織にはいられません。

ハル：しまったなあ。期初の目標すり合わせを侮っていたよ。なんで成果を定量的にアピールできるように設定しなかったのかなあ。

「動詞」の成果目標には要注意

大事なことは目標を測定可能な成果物にすることです。特に目標を動詞で表現している場合は要注意です。事例のように「作成する」なんていうのは問題外です。また動詞を体言止めにしているのも要注意です。「バグの修正」とか「仕様書作成」とか、それだけ書かれてもどこまでできれば修正が完了し、作成が終わるのかわかりません。例えば、次のように何をどこまで作成するのか明確にすることが大事です。

■クライテリアを満たしたα版の作成が完了している（9月末）
・上記の目標に向けた日程計画を利害関係者間で合意できている
・状況に合わせて都度日程計画を更新し、利害関係者間で合意できている（更新がない場合はその旨の共有と合意を得られている）

面談ではクライテリアの定義（例：α版として定義された機能の動作がステークホルダーに受け入れられていること）、プラス評価の目安（例：β版の作成日程も見直されている）などをすり合わせておきます。お互い納得がいけば、これら完了の定義やプラス評価の目安も目標シートに追記しておくと、忘れなくていいでしょう。

［図］目標を測定可能な成果物で設定する

成果主義をきちんと機能させるためには、高い成果を上げた若手技術者を、いかに正しく評価するかが大切です。そうすることで、評価の高い若手から刺激を受けて中堅技術者も活躍する、という望ましい流れが生まれます。納得のいく成果を出した人材を正当に評価することで、組織に対してプラスのフィードバックがかかるのです。そのためにもメンバー各々の目標を測定可能な形で定義し、誰もが納得のできる成果を狙えるよう、期初から仕込みを入れていきましょう。

問題しか見えない「バグチケット起票型上司」

ーー問題を指摘するのが仕事

ソフトウェア開発は日程の遅れや技術的な問題がつきものです。しかし、そのたびに評価が下がるのであれば、メンバーほぼ全員ボーナスカットとなってしまいます。リーダーは問題ばかりに目を向けていると、本来評価すべき重要な貢献を見逃してしまいます。メンバーは裏で、不具合を防止するために構造を見直していたり、他部署の要望に応えてツールを作っていたり、よい成果を上げているかもしれません。

失敗ばかりを突き付けられる

ハルさんによる一次評価は、他のリーダーやカチョーさんブチョーさんともすり合わせを行い、調整します。評価者によるブレや不均衡がないようにするためです。今日はその評価をすり合わせるための会議です。

ハル：ということで、シンテクさんはプラスマイナスなしの標準評価にしました。頑張ってくれたので、できたらプラスにしたいのですけど。

ブチョー：頑張りではなく成果で評価するのじゃ。聞けばシンテクさんの作ったコードに問題が出て、外注先や他チームにも迷惑をかけたそうじゃないか。それなら評価はマイナスでもいいんじゃないか？

確かにシンテクさんが不具合を出したことは間違いありません。とはいえ、今期は想定外の業務を引き受けたり、他チームの困りごとを率先して助けたり、新人のガクさんの相談にも丁寧に答えたりと、よい活動をしてくれました。

カチョー：いやシンテクさんは標準でよいかと思います。確かに遅れは出ていますが、シンテクさんなりの工夫で重要機能にめどを立てたこと、自分の業務外にもかかわらず、積極的に周囲を助けてプロジェクト全体の進捗に寄与したことを加味すれば、マイナスをカバーする成果が出せたといえます。今回賞与としては標準ですが、来年の昇給にプラスしたいですね。

シンテクさんの成果を、ブチョーさんにどうアピールすべきか悩んでいたハルさんですが、うまくカチョーさんが助け舟を出してくれました。

ハル：続いてノビシロさんですが、2年目にしてしっかりと外注管理を行い、今のところ予定通りに進んでいますので、プラス評価でどうかと……。

ブチョー：予定通りなら標準じゃ。それも外注が頑張った結果じゃろ？ 予定通りといってもこっちで仕様書をミスして、結局作り直してもらったはずじゃ。追加で予算もかかっとるし、マイナスでもいいんじゃないか？

また失敗を指摘されてしまいました。確かにコミュニケーションミスがあって、外注先に作り直してもらったのは事実です。ただ先方とは双方にミスがあったと合意が取れており、対応費も折半にできたことはノビシロさんの大きな成果です。このことをどう説明しようかとハルさんが悩んでいると、再びカチョーさんが助け舟を出してくれました。

カチョー：ノビシロさんはプラスでよいでしょう。早々にミスに気づき、外注先とお互いに問題があったという合意を取り付けてくれました。これは若手でなくても難しい課題だったはずです。しかも遅れに対するリカバー策も提案し、予定の日程に戻せたのであれば十分プラスの成果があったと評価できます。

ハルさんは、チームメンバーの成果をうまくアピールできていない自分に対してふがいなさを感じると共に、改めて評価の難しさをかみしめました。

ハル：そりゃソフトウェア開発は失敗だらけだから。失敗だけを見たらマイナスの評価しかできないよ。もっとよい成果にフォーカスしないと……。

問題ばかりを指摘する上司

人はどうしても悪いところを見てしまいます。問題が大きいほど、騒ぎも大きくなり、失敗に関わったメンバーは目を付けられます。問題を出したチームや担当者に対し、評価者はどうしても厳しい評価を向けてしまいます。

一方、問題を出した本人は、やらかした負い目もあり、自ら責任を持ってリカバーしていたりします。大災害のようなひどい状況を知恵と工夫と協力と体力で乗り切り、「なんとか解決してやりましたよ、俺！」という達成感を持っています。「この問題を放置していたらこんな遅れでは済まなかったはず。俺がアクションしたおかげでなんとかなったよ。すごいぜ、俺！」という自負もあるでしょう。そして、これだけ活躍したのだから評価はどう考えてもプラスだろうと考えます。

しかし、評価者はいかに頑張ったかではなく最終的な成果を見ます。当初の予定より遅れている、もしくはいらぬ問題を発生させ、追加コストもかかってしまった場合には「こいつはいったい誰がやらかしたんだ？　マイナスの成果を出した者にはマイナスの評価を！」と見てしまいます。いかにリカバーしようが、最終的に遅れが出ていたのなら、マイナスなのです。

このように評価者と被評価者の思いが食い違った場合、低評価を受けたメンバーから「納得がいかない！　組織は俺を認めてくれない！」という不満が噴出する事態に発展します。

成果をアピールしない部下

メンバーによっては、自分の成果を自分からは全くアピールせず、やたら低い自己評価を持ってくる場合もあります。「ええ、今回遅れも出ましたし（マイナス1）、期初設定した目標も達成できませんでした（マイナス2）。そのうえ、問題を起こしてしまってすみません（マイナス3）」みたいな感じで、成果が出ているのに圧倒的に低い評価を持ってきます。

残念なことに、この低い自己評価をそのまま上司に提出すると、その低い評価のまま通ってしまいます。提出された上司も「そう言われたら、まーそうだなあ」と考え、切ない評価のまま確定されてしまいます。

多くの場合、組織の中では全員一律で高い評価を付けるわけにはいきません。ある程度評価を高く付けた人がいるなら、そうでない人も決める必要があります。そのため、本人が低い評価でいいならこれ幸いと都合よく受け入れる、いただけない上司がいるかもしれません。しかし、十分な事実確認を行わず、自己申告通りの評価にしましたというのでは、評価者としての仕事を放棄しています。

自己評価はともかく、実際はその人の尽力があって、他の大きな課題を解決できたかもしれませんし、進捗が遅れている理由はその人自身ではなく、外部の要因だったのかもしれません。期初に立てた目標もそうした外部の状況変化を受けて、本来は期中に見直すべきだったのかもしれません。

記載したシート上の目標に到達していないからといって、成果を正当に評価しない上司は、いつしか信用されなくなります。本人もどうせどんなに頑張ってもまたマイナスだろうと、組織に期待しなくなっていきます。

ハル：そもそも問題は出るものだし、一度は失敗しないと成功もしないよね。失敗だけを見て評価していたら、やる気もなくなるよ。失敗から工夫して立ち直ったことは成果として評価したいなあ。

「減点法」の魔力に屈してしまう

評価者は加点より減点をしてしまいがちです。良いところより、悪いところを指摘するほうが誰にとってもわかりやすく、かつ課題を指摘しているうちに自分自身が偉くなった気分もしてくるものです。あいつはこういうところがダメだとか、あいつはほんとにできないやつだ、と口に出すだけで、指摘できる俺って優れている、俺はできるやつだという優越感に浸ることもできるでしょう。

さらに、メンバーの評価を上司に伝えるときも、できていないことは説明がしやすいのです。彼はこんなにすごい成果を上げました、というと「本当に彼がやったのか？」とか「お前がサポートしたんじゃないのか？」といった尋問に答えねばなりませんが、彼はこんなにできませんでした、といえば「そうか。次回頑張ってもらおう」で終了です。上司とのトラブルや面倒な説得作業を避けられます。被評価者からすれば、そんなことで評価が決まってたまるか！　と思ってしまいますが、それほど「減点法」の魔力は強力なのです。

まさにここが失敗ポイントです。評価に際し、成果を正しく見ずに問題だけを見て減点することで、自分を認めてもらえない、正当に評価されないという気持ちを被評価者であるメンバーに起こさせます。組織から認めてもらえないのであれば組織に対しても期待をしなくなり、認められないのならば頑張ろうとする気持ちもなくなります。

「いいとこ探し」をしよう

対策はずばり「いいとこ探し」しかありません。事実に基づいたよい成果を見つけ出し、アピールすることです。

筆者は評価の面談をする際、必ず本人の自己評価に対してプラスできる点がないかを探します。「遅れが出たけどリカバーしてくれたよね？」とか「バグが想定外に出たけど、他のチームに知見を共有してくれたよね？」とかなんでもいいのです。脳をフル回転させて、いいとこ探しをします。

実際、筆者が実施したメンバーの評価は、平均よりだいたい高めになっていました。いつも上司から「甘すぎる！」と怒られていましたが、負けずになぜ評価が高いのかを丁寧に説明して納得してもらいます。一方、本当に評価しすぎであれば、実際の成果と評価とのギャップを、きちんと本人へフィードバックをします。組織や上司の評価がぶれると信頼感を失います。ギャップがあればきちんと筋の通った説明をしなくてはなりません。

少しでもよい評価を付けるのがリーダーの役目ですから、攻めすぎて怒られるぐらいがちょうどいいのです。たとえ結果的によい評価に結びつかなくとも、「いいとこ探し」をすることでメンバーとの信頼感が深まり、「リーダーはちゃんと自分のことを見てくれているんだ」と安心感を持ってもらえることでしょう。

［図］成果図 が出ていない裏にはよいところが隠されている

書籍情報

エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた（翔泳社）

「リアルすぎる！」と話題を読んだ失敗の教科書・第2弾！
残念なマネージャーにならないための「育成」アンチパターン集！

人材不足の開発現場において「エンジニアをいかに育成するか」は重大なテーマです。しかし、技術の指導や業務の割り振りだけでは、チームも個人も思うようには育ちません。エンジニア育成には、ソフトウェア開発と同じかそれ以上に繊細で複雑な「マネジメント」の力が求められます。

・優先度をつけずに業務を丸投げする「FIFO型業務依頼」で、キャパオーバーを招いてしまった
・「アレと同じに作って」と曖昧な指示を出した結果、意図と違う成果物があがってきた
・レガシーシステムの担当を任せたら、新しい技術を求めて転職されてしまった

などなど、意図せぬ失敗は数多く潜んでいます。最悪の場合、せっかく採用した人材が早期離職してしまうことも、現代のIT業界では珍しくありません。

本書は、そんなエンジニアの育成・マネジメントの現場で起こりがちな「落とし穴」を集めた失敗事例集です。架空の開発現場を舞台に「新人研修」「OJT」「チーム編成」「評価」などで起こりがちな失敗を42篇収録。著者の実体験をもとにした、フィクションとは思えない臨場感抜群のエピソードの数々を通して、失敗をどうすれば回避できるのかを解説します。

発売日：2025年06月11日

＞＞詳細はこちら

【著者】
出石聡史（@sdeishi）

2023 年3月まで、コニカミノルタ株式会社センシング事業本部LD&CA 事業部のソフトウェアリーダー（管理職）を担当。事業部すべてのソフトウェアにかかわり、開発の各ゲートにおける承認責任者として全プロジェクトの進捗をサポートした。各ゲートにおいては詳細設計や実装だけではなく、システム全体のアーキテクチャや、さらに上流の要求要件分析や企画内容にまで踏み込んだレビューを行い、顧客に刺さるソフトウェア開発を推進した。
また教育や育成にも力を注ぎ、販売や生産も含めたセンシング事業本部全体の新入社員教育や、大学生向けのインターンシップ、さらには基幹技術者向けのリーダー教育を企画・実施。技術者全体のスキルやモチベーションアップに貢献した。現在は会社を退職し、これまで培ってきた技術や経験を、若手技術者や新米マネージャー、ソフトウェアリーダーに伝える方法を模索中。著書に『ソフトウェア開発現場の「失敗」集めてみた。』（翔泳社）がある
■note

本記事は、『エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた』（翔泳社）より一部抜粋・転載しております。