360 件のレビューを殺す: どうやって人を評価するのをやめて仕事の管理を始めたのか

こんにちは！ 私の名前は Vitalina です。SToFU Systems のアカウント マネージャーです。

私たちは、プロセスが動き始めてから名前やルール、大人の監督が与えられるような会社です。 当初、私たちは独自のマネジメントスクールを持っていなかったので、「みんなが真似する」ものを真似していました。 借用した管理習慣の 1 つは 360 フィードバックでした。

紙の上では、360 は公正で成熟したもののように見えます。多くのソース。偏見が少なくなります。 「客観性」。うーん！

実際には、それは別のものに変わりました。私たちにとって、360 はチームを強化するツールではありませんでした。それはチームを静かに引き離すツールだった。形式的には正しいように見えましたが、実際の作業では間違った方向に進んでしまいました。そこで、それを切り出しました。一歩ずつ進んでいきましょう。

360とは何ですか？

360 とは、人に関するフィードバックを収集するときのことです 「あらゆる側面から」: マネージャー、同僚、隣接するチームメイト、そして場合によってはクライアントから。 いつもの これは、評価と次のような質問が含まれるアンケートです。 「何がうまくいくのか」「何が邪魔をしているのか」「何を変えるべきなのか」。

私たちもそうしました。私たちはアンケートを送信し、回答を集めて集計し、推奨事項を作成しました。 形式的には、すべてがきちんとしているように見えました。データポイントがありました。結論が出ました。そこには「開発計画」があった。

私たちがどのような種類の「アンケート」について話しているのかを明確にするために、360 で通常尋ねられる内容の非常に単純化された例を示します。 これはフォームからの一言一句の引用ではなく、典型的なロジックです。

たとえば、「人は何をし続けるべきか？」 次に、「人は何を始めるべきですか?」 次に、「人は何をやめるべきですか?」 そして、いつも無邪気に見えるもう 1 つの質問は、「やり取りが困難だったときの状況とその理由を説明してください。」です。

そして、その要約は多くの場合、全体を見渡す目から見た小さなレポートのように見えます。おおよそ次のようになります。

長所: タスクをすぐに見つけ、他の人を助け、レーダーから消えません。 リスク: 「準備ができている」は「ほぼ準備ができている」ことを意味する場合があり、会議での議論は鋭く、チャットでは断片的に応答することがあります。 次に行うべきこと: 完了の定義に同意し、期待値を同期し、エスカレーション形式に同意します。

紙の上ではすべて問題ありません。美しい、均一です。 ただし、詳細が 1 つあります。 日々一緒に働いている人たちによって書かれています。 そして、匿名性を追加するか、遅延すると、 フィードバックは「後で」、開発ツールではなくなる そして自分だけの人生を歩み始めます。 プロジェクトチームを想像してください 5人のうち。すると誰かが「匿名のフィードバックです」と言いました。 匿名。 5人チームで。 そして、この現実の中で、360はその本当の顔を見せ始めます。

なぜ 360 がチームを引き離すツールになったのか

1. ポイント 1。賞賛 - 一行、批評 - 3 巻の小説

物事が良いとき、人々は簡単に書きます。 「すべて大丈夫です。」 「快適な仕事」。 "よくやった"。学校のノートに貼られたシールレベルのフィードバックです。いつ 何かが間違っている、文学が始まります。詳細については、 例と感情を交えて。そして技術的にはこれは正常です: 負の方が正よりも指定しやすいです。しかし、360度には 問題は、この「小説」全体が、一般化されたものとして一人の人の手に戻ってくるということです。 チームからの評決。

どんなに優しい言葉をかけても、人間の脳は このように書かれています：「私たちは皆集まって書き留めました。 どうしたの？」そしてそれだけです。その後は、どんな試みも 「建設的なフィードバック」は法廷での審問のような感じがします。あなたが望んでいた 開発ツールを開発し、集団裁判を受けました。

私たちは、本当に何をしようとしているのか、と正直に自問しました。 この練習？はい、それはフォーマットを規律しますが、 それは信頼を破壊します。

生活から見るとこんな感じです。 3人いる人に報告が来ます 「すべてが大丈夫です」というフレーズと、「だから大丈夫ではない」というキャンバスが2つあります。 そしてもちろん、脳は「OK」を 3 つではなく 2 つ覚えています。 「大丈夫じゃない」。 それが注意の仕組みです: 痛いので、それは重要です! そしてその時点から、 その人は発展ではなく、自己防衛に向かうのです。彼らは 「それは真実ではない」と証明し始める、あるいは 「それは状況のせいだ」とか、「あなた方も聖人ではない」とか。 そしてこの瞬間、360は誰もが参加する儀式に変わります まるで彼らは良いことを望んでいたかのように、しかしそれはいつも通りでした。

2. ポイント 2。小規模チームにおける匿名性は自己欺瞞である

「匿名のフィードバックは恐怖を取り除く」というよく知られた経営のおとぎ話があります。 匿名？本当に？小規模なプロジェクト チームですか? 実際には、ほとんどの場合、「これを書いた人を推測してみます!」という意味になります。

人はいくつかの不愉快な発言を受け、その後 次のプロジェクト会議に来ると、同じ 3 ～ 5 人が座っています。 彼らは「組織開発」など考えていません。彼らはこう考えます。 あなたの中の一人でしたか?」そしてそれは非常に有害なプロセスを開始します: 皆さん 表面上は礼儀正しいが、その下には不信感が隠れている。

必ずしも露骨な対立に発展するとは限りません。それは単純に チームを冷たくしてしまう。粘着性が低い。手助けする意欲が低い。 そしてなぜ人々は自分たちの問題を共有しないのだろうかと疑問に思う 「初期段階では」。でも、彼らはすでに一度あるので、 共有 - そしてそれは匿名で返されました クレームのリスト。

3. 360 がプロモーションの決定に影響を与えるとすぐに、ゲームが始まります

ここが最も興味深いことでした。そして最も悲しいこと。

調整に関する話し合いの際、私たちは次のことに気づきました。 何か奇妙なこと。礼儀正しく、協力的で、電話対応がしやすい人です。チーム内では彼らは完全な恋人のように見えるかもしれません。その後 あなたは彼らに「他の人を評価」できる「匿名の」アンケートを手渡します。 突然スコアが下がったり、批判が過剰になったりします。 私たち自身もその効果を実感しました。それは誠実さに直接的に反するものでした。

状況を想像してみてください。あなたはチームに「360 件の評価がカウントされます」と伝えます。 昇進」そして同じ秒で、あなたはその一部を回転させます。 チームを同僚ではなくプレーヤーにします。なぜなら、もし システムに「影響」ボタンが表示されると、誰かがそれを押します。 必ずしも悪から来るわけではありません。時々、ただ感じるだけで 不正（「そして、なぜ彼は昇進しているのですか、彼は...」）。時々 競争から。場合によっては、「それが世界の仕組みだ」という理由もあります。 そしてその瞬間、あなたは望んでいたものを手に入れます 政治、ゲーム、「万が一の場合に備えて」成績が低い場合は避けてください。

ちなみに、これは多くの研究者が 実践者は開発のためにフィードバックを共有することをお勧めします 管理上の決定（金銭、成績、昇進）。 CIPD は非常に率直に次のように述べています。 評価や管理上の決定を会話から切り離したほうがよいでしょう。 開発を目的としてフィードバックが提供される場合。 これは証拠レビュー (実践の概要) の PDF です。 www.cipd.org/...​e-review_tcm18-111378.pdf

4. ポイント 4 (私たちの痛ましい洞察)。 360 はマネージャーの仕事を置き換えることがよくあります

いくつかのサイクルを経て、最初は侮辱のように聞こえ、その後は真実のように聞こえるフレーズが完成しました。

マネージャーが 360 度の理解を必要とする場合 人々はどのように働いているのか、どこに問題があるのか​​、そのマネージャー 観測可能な信号のシステムがありません。指標はありません。ありません 定期的な会話。リズムがない。あるいは、それらすべては「どこか」に存在し、 しかし、実際には使用されていません。

そして 360 度が松葉杖になります。「これからアンケートを集めて、最後に 私たちは真実を学びます。」そしてそれでは「真実」はわかりません。 匿名性と推測を掛け合わせた感情的な描写 そして政治的なゲーム。

したがって、これは「私たちにとってうまくいかなかったので、360は悪である」というようには聞こえませんので、参考文献を追加します。

マルチソースフィードバックに関する研究があります。 その結論は基本的に「魔法を期待しないでください」です。 24件の縦断的研究のメタ分析で、スミザー、ロンドン、ライリーは、その後の改善を書いています。 360 度のフィードバックは通常控えめなものであり、大きな反響は期待しないでください。 1 回のフィードバックを経て「大規模アップグレード」。 人が本当に変化する必要があると感じたとき、改善の可能性は高まります。 フィードバックを受け入れ、それは変えられると信じ、具体的な目標を設定し、 「PDF を読む」だけではなく、実際に何かを実行します。 そして先に進みます。」 テキスト自体は次のとおりです (PDF): www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

わかりました。360 は削除されました。何が置き換えられたのでしょうか?

チケット数による人数の計測をやめました

1 枚のチケットで 1 週間分の調査が可能ですが、難しい決断でした。 10 回の呼び出しとわずか 20 行のコード。別のところで— AI エージェントの 1 回の実行から実際に得られた 50 の機能 20分以内に。

チケットを測定しているだけなら、実際に測定していることになります 仕事ではなく、プロセスがどのように仕事を削減するか ばらばらに

そのため、質問を変更しました。 「完了したタスクの数は何ですか?」ではありません。しかし： 何が提供され、どのような価値が生み出され、品質は何でしたか、予測可能でしたか、ステータスは正直でしたか?

管理劇場なしで「結果」をどのように定義したか

私たちはシンプルなフレームワークに収束しました。

成果とは、価値が提供され、品質が許容範囲内で、チームが予測可能で、進捗状況が透明である場合です。

値は「コードが書かれている」ではありません。 それは、「ユーザーまたは顧客がより良い結果を得ることができた」または「チームにとって作業が容易になった」です。 システムをサポートするためです。」

品質とは「あなたのコードが好きです」ではありません。これらは、製品のバグ、インシデント、リビジョンなどの結果です。

予測可能性とは、「常にうまくいく」ということではありません。 それは、「私たちは自分に時間が何にあり、何に時間がないかを正直に理解しています。 そして私たちはそれについて自分自身に嘘をつきません。」

透明性とは、「ほぼ完了」が人生哲学にならない場合のことです。

メトリクス

「メトリクス」という言葉を聞くと、すぐに多くの人がそう思うでしょう。 過去の経験からわずかにトラウマを負った労働者を思い出してください。 数で頭を殴られた人。

指標はムチであってはなりません。メガネであるべきです。これらがなければ、マネージャーは盲目になってしまうことがよくあります。 そして経営者が盲目になると、アンケートに「客観性」を求めるようになる。まあ、わかりました。

ほとんどの問題はシステム的なものであるため、指標はチーム レベルのままにしました。 そして、犯人を探すのではなく、プロセスを正したいのであれば、プロセスを測定する必要があります。

正直に言うと、私たちはここで何も発明しませんでした。 DORA (DevOps) 研究と評価）はすでに非常に実用的なものを推進しています。 一連の配信メトリクス: どれだけ早く変更を配信するか そして、変化がうまくいかなかったときの失敗はどれほど痛ましいことか。 クイック ガイドは次のとおりです: dora.dev/guides/dora-metrics。

確認しておきたい重要な発言もあります KPI メトリクスを作成したいと思ったことのある人には、次のようなメッセージがあります。 「指標を目標にしてはいけない」! なぜなら、 「1 日に N 回デプロイする必要がある」と言うのは、 チームは価値ではなく数値のデプロイを開始します。これは古いものです 指標が目標になると、目標ではなくなるという話 インジケーター。 DORA はグッドハートの法則を明示的に参照しています そして典型的な落とし穴について説明します。こちらは「4・5の鍵」についてのページです。 簡単に言うと: dora.dev/...​s/dora-metrics-four-keys

そして、DORA が通常強調しているもう 1 つの重要な点: コンテキストが重要です。これらの指標は 1 つの範囲内で表示するのが最適です チームやサービスを比較するのではなく、時間の経過とともに メインフレームを使用したモバイル アプリケーション、または小規模なチーム 200人用のプラットフォームを備えています。

技術チームでない場合でも、ロジックは同じです。の代わりに 「デプロイ」すると、「クライアントが結果を受け入れた」可能性があります。の代わりに 「インシデント」では「エスカレーション」が発生する可能性があります。 「ロールバック」の代わりに「やり直し」 ポイントは同じです。どれだけ早く値を移動するかです。 システム経由でのエラーとそのエラーによる損害額を確認します。

そして今、非常に重要な「それをしてはいけない」。 これらの指標を個別の KPI に変換しないでください。 なぜなら、人々は製品ではなく数を最適化し始めるからです。 KPI は「デプロイ」ですが、突然、デプロイのためのデプロイが必要になります。 KPI は「サイクル タイム」であり、タスクは「早く終わらせる」ためだけにばかばかしいほどに細分化され、難しい部分は静かに影に消えていきます。 KPI は「インシデント」にあり、インシデントは「特異性」または「予期しないユーザー シナリオ」に名前が変更され始めます。

まず最初に役に立ったのは、予測可能性でした。 単純 質問: 計画時に何を約束しましたか そして実際に与えられたもの。恥ずかしいことではありません。理解のために。 なぜなら、常に 10 と約束して 6 を実行すると、 その場合、問題は「怠け者」ではありません。問題は見積もりにありますが、 優先順位、WIP、ブロッカー、コンテキストの切り替え。つまり、経営において。

2つ目は納期です。タスクにはどのくらい時間がかかりますか? 「職場に持っていく」から「実際に届ける」までの途中。 とても身の引き締まる思いです。判明することが多いので 「コードを書く」のは迅速ですが、「提供する」のは簡単です。 ゆっくり。そして、ボトルネックがどこにあるのかがわかります: レビュー、テスト、 リリース、調整、依存関係。

3つ目はWIPです。チームが同時に「仕事中」の場合 一度に 10 個の問題を抱えていると、誰も実際には何もしません。より正確には、 誰もが一度にすべてを行っています。そして、なぜ進歩を感じるのか疑問に思います 遅くて緊張している。脳が薄く広がると 10 個のタスクを実行しても、生産性は向上しません。それはちょうどなる もっと疲れた。

私たちがより明確に考えるのに役立ったもう 1 つのことは、システムを通じて仕事をより速く進めたい場合、その答えは多くの場合、人々に強く押し付けないことです。それはバッチサイズを減らすためです。変更が小さいほど、レビュー、テスト、リリース、ロールバックが簡単になります。 DORA も同じことを直接主張しています。通常、バッチを小さくすると、速度と安定性の両方が向上します。チームが実際に 1 か月間それを実践してみないと、それは明らかなことのように思えます。

品質: 私たちは「私にはそう見える」と議論するのをやめ、結果を検討し始めました。

アンケートで「品質」を評価するのは悪い考えです。なぜなら「品質」だから アンケートでは、多くの場合、共感、スタイル、趣味が重視されます。

私たちは結果に移りました。

生産に到達した欠陥の数。彼らはどれほど真剣でしたか？トレンドはどのように変化していますか?

どれだけの事件があったことか。回復するまでどれくらいかかりましたか?同じ理由が繰り返されていませんか？

改訂回数。 「渡されて」返されたタスクの数。 「準備ができています」が準備ができていないことが判明したためです。

もう「誰が一番か」について議論する必要はありません。製品で実際に何が起こっているかがわかります。

直観に反する結論: そもそもなぜ人を評価するのでしょうか?

掘れば掘るほど、奇妙な質問に遭遇することが多くなりました。

なぜ人は人を評価するのでしょうか？昇進を拒否するには?誰が「スター」なのかを示すには？人を比較するには？

そしてそれを正直に話したら、こうなった 私たちの本当のニーズのほとんどはランキングに関するものではないということ 人々。それらはチームのパフォーマンスに関するものでした。「私たちは何をしているのか」 約束しました、品質は良いですか、仕事は予測可能ですか、 私たちは燃え尽きているのか、そしてクライアントは何を得るのか 彼らは期待していますか？

つまり、システムについてです。

そうであれば、最初の評価対象はチームとプロセスです。対象となるのは人ではありません。

チームのパフォーマンスが低いため、全体を見直します チェーン: 採用、オンボーディング、タスク定義、計画、レビュー、 テスト、リリース、コミュニケーション、依存関係。これは経営的には もっと難しいです、はい。しかし、それはより正直です。

時々それは非常に現実的であるように見えます。たとえば、次のようなとき 「また時間がありませんでした」、最初の質問は「誰がペースを落としているのか」ではありません。 そして「時間はどこに消えたのか」。時間は消えてしまう可能性があるから 「仕事」ではなく、待機中です。タスクは横たわっています。 レビュー中、テスト中、合意によりブロックされている、または 単にそれらが並行して多すぎるだけです。

誰かが困っているとき、私たちが最初に確認すること

誰かが「引っ張らない」という状況も時々見られます。ただし、アンケートの代わりに簡単な診断を行います。

この問題は常に存在していましたか?もしそうなら、問題はおそらく 採用または新人研修において。その場合は採用プロセスを修正し、 アンケートを持っている人ではありません。

以前は普通だったのに、その後悪くなりましたか？それから 燃え尽き症候群、仕事の変更、役割の衝突などの状況が考えられます。 個人的な事情。これは通常の管理作業のゾーンです。 何が起こったのかを解明し、負担を軽減し、回復を助ける をコントロールし、2 ～ 4 週間の短い回復計画を立てます。

その人は成功とは何かを明確に理解していますか 近い将来っぽい？問題はそうではないことが多いため、 その人は「弱い」ということ。それは私たちが彼らを霧の中に置いたことです そしてそれを期待と呼びました。

そして、もう一つニュアンスがありました。人なら 何度か失敗したため、マネージャーが主観的に値を上げることもあります バー: 「さあ、あなたが失敗者ではないことを証明してください。」 それは潜在意識レベルで働くことが多く、チームにとって悪影響を及ぼします。 通常はその逆を行う方が良いです。範囲を縮小し、タスクを小さくし、 ノイズを取り除き、人にいくつかのことを一貫してうまく行う機会を与える そして自信を取り戻します。これは人にとって難しい仕事です 管理者たち。そしてまさにそれが、私たちが非常に注意深く観察している理由です 私たちが雇うマネージャーで。

結論

もちろん360度でも使えます。大企業では、匿名性が実際に可能です。

チームに直接フィードバックの文化がすでに根付いている場合、 360 は追加の信号であり、メインの信号ではありません "真実"。

私たちにはそれがありませんでした。私たちのチームは小規模で、ペースが速く、不信感という大きな代償を伴いました。

360 は紙の上では大人のツールのように見えました。私たちの中で 現実には恐怖を一箇所に集める仕組みになっており、 推測、競争、そして「集団的判断」。

360 度を切り出し、基本に立ち返りました。 シンプルなチーム指標、オープンな会話、透明性のあるステータス。

資料とリンク (さらに詳しく知りたい場合)

DORA — software delivery performance metrics。 5 つの指標と、それらを誤用したときにチームが陥る罠についての根拠のある説明。

DORA — DORA’s software delivery performance metrics. 過去の「なぜ 4 か 5 か」とメトリクスを含むゲームに関する警告を含むショート バージョン。

DORA Research: 2024 — DORA Report. 完全なレポート (さまざまな言語の PDF をダウンロード)。

Smither, London (2005) — meta-analysis on multisource feedback。 1つの360度の波に魔法のような効果を期待してはいけない理由。

CIPD — Performance feedback: an evidence review (PDF)。フィードバックがどのように機能するのか、機能しないのか、そして「評価」と「開発」を混同することがしばしば有害である理由について。

CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines。それでも 360 度を行う場合は、火災の後ではなく、開始前に考えるべきことがあります。

CCL — SBI feedback model。 「近道なし」フィードバックのための非常にシンプルなフレームワーク。

Google SRE — Postmortem Culture: Learning from Failure。非難のない事後分析と、恥をかくことの文化が学習を台無しにする理由について。

Amy Edmondson (1999) — Psychological Safety (PDF)。チームの心理的安全性に関する主要な情報源。

WEF — Feedforward technique。 「昨日何が起こったか」ではなく「次に何をするか」の方向にフィードバックをシフトする方法について。

Goodhart’s law。 KPI 指標を作成したい人にとって、最も役立つ「反理論」の 1 つです。

コミュニティへの質問

コミュニティは 360 についてどう考えていますか?使っていますか？あなたの経験はどのようなものでしたか？

チームが小さく、全員がすべてを理解している場合、「匿名性」の問題をどのように解決しますか?

そして、実際にきれいなレポートを作成するのではなく、プロセスの管理に役立つ配信/品質指標は何でしょうか?

お時間を割いていただき、ありがとうございました。