数字を使う技術

技術顧問先での社内講演の資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. 数字を使う技術 2026/8/12 株式会社アトラクタ 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. 数字を使う技術 適切でない指標を使うと、問題を新たに作り出す ▸ 売上件数を評価する ▸ 利益の薄い小口案件が量産される。大型案件を分割して件数を稼ぐ営業も現れる ▸ 残業時間の少なさを評価する ▸ 残業が減るのではなく、無申告の残業が増える。仕事を家に持ち帰る ▸ バグ件数の少なさを評価する ▸ バグが減るのではなく、バグを報告、起票しなくなる。「仕様です」が増える ▸ ベロシティを目標にする ▸ 開発生産性は変わらないまま、ストーリーポイントの見積もりだけが膨らむ ▸ コミット数を評価する ▸ 1つの変更が複数コミットに分割される。リポジトリのログは賑やかになるが価値は不変 4
5. 数字を使う技術 5 「適切でない指標のせいでおかしくなる」とわかっていて、なぜ過ちを繰り返すのか ▸ 客観的に見える ▸ 「主観ではなく数字がそう言っている」と言えると、判断の責任を自分から数字にすげ変えられる ▸ 公平に見える ▸ 全員を同じものさしで測っているという体裁にできる（測られる側の納得は別問題） ▸ 比較と集計ができる ▸ チーム間、期間、個人を横並びに比較できる。上位への報告とかに載せやすい ▸ 管理している安心感が得られる ▸ ダッシュボードやExcelが埋まっていると状況を把握できている気分になって、なんとなく安心 ▸ 数字は、測られる側のためではなく、測る側の不安によって増殖することが多い
6. 数字が悪いのではなく 数字の使い方を間違えている
7. 数字を使う技術 本日のテーマ：どう設計すれば、数字は壊れないのか ▸ 「KPIは危険だ」で終わらせるのは無理。そもそも数字を捨てられる組織は存在しない ▸ となると、数字の壊れ方の原理を理解して、壊れにくい指標を設計する技術を身につけるしかない ▸ 内容 ▸ 第1部： なぜ数字は壊れるのか （数字にまつわる2つの法則と1つの諺） ▸ 第2部： 壊れない指標の設計原則 （壊れない指標を作る6つの原則） ▸ 第3部： 原則の実装 ー OKR、人事評価、経営報告 7
8. 第1部 なぜ数字は壊れるのか
9. 数字を使う技術 観測された統計的規則性は、制御の目 的で圧力をかけられると、崩壊する傾 向がある チャールズ・グッドハート（1975） 原文: "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes."
10. 数字を使う技術 10 グッドハートの法則の出自 ▸ もともとは英国の金融政策の文脈で生まれた指摘 ▸ マネーサプライ（世の中に出回っている通貨や預金の総量）と物価には安定した相関があった ▸ 中央銀行がマネーサプライを操作対象にした結果、市場の行動や制度が変化し、相関自体が崩れた ▸ 観測しているだけなら正しかった関係が操作した瞬間に壊れる。これこそが法則の核 ▸ 金融の話に限らず、測定と制御があるところではどこでも同じことが起きる
11. 数字を使う技術 指標が目標になると 良い指標であることをやめる マリリン・ストラサーン（1997） ※ グッドハート本人の言葉として広まっているが、実際は人類学者ストラサーンによるパラフレーズ（英国の大学評価制度を論じた論文より）
12. 数字を使う技術 12 なぜ数字が壊れるのか：目的→数字→行動の短絡 ▸ 本来の構造： 目的 → 数字 → 行動 ▸ そもそも数字を測るのは、目的そのものは直接測れないから ▸ 「顧客に価値を届けられているか」は測れないので、売上やNPSという代理変数を測る ▸ 数字が目標になった瞬間： 目的が消えて 数字 → 行動 に短絡する ▸ 代理は必ず本体とズレている ▸ 数字が目標になると、そのズレの部分（数字は上がるが目的には貢献しない行動）が発見され、数値だけが最 適化されるようになる
13. 数字を使う技術 13 ベロシティを目標にすると何が起きるか ▸ 見積もりの基準が自然と動く ▸ 以前なら3ポイントだった作業が5ポイントと呼ばれるようになる。誰も嘘をついているつもりはない ▸ リファインメントが交渉の場になる ▸ 「これは複雑だから8では？」という会話が増え、見積もりの目的が精度から数字稼ぎに変質する ▸ 完成の定義が歪められる ▸ スプリント内で「完成」させるために、テストやリファクタリングが完成の定義から落ちる ▸ 結果：グラフは右肩上がりなのに顧客に届く価値は横ばい（どころか下がることもある） ▸ そして経営層はそのグラフを見て安心している
14. ベロシティは速度計であって アクセルではない 速度計の針を手で回しても 車は1メートルも進まない
15. 数字を使う技術 定量的な社会指標が意思決定に使われる ほど、その指標は腐敗圧力にさらされ、測 ろうとしていた社会プロセス自体を歪める ドナルド・キャンベル（1976）
16. 数字を使う技術 16 キャンベルの法則 ▸ 教育評価の研究から生まれた ▸ グッドハートとは別の分野で、ほぼ同時期に、独立に到達した結論。派生ではない ▸ 教育の実例 ▸ 標準テストの点数で学校を評価すると、教育がテスト対策に置き換わる。点数は上がるのに学力は上 がらない ▸ 行政の実例 ▸ 犯罪件数で警察を評価すると、犯罪が減るのではなく、被害届が受理されにくくなる ▸ グッドハートより一歩踏み込んでいる ▸ 指標が壊れるだけでなく、測ろうとしていた現実の側が壊される
17. 数字を使う技術 17 2つの法則の違いは「報酬」 ▸ グッドハートの法則 ＝ 指標が目標になると行動が歪む ▸ 悪意は不要。善人が合理的に振る舞うだけで指標は壊れる。ベロシティのインフレに悪人はいない ▸ キャンベルの法則 ＝ 指標が評価や意思決定に強く使われるほど、指標だけでなく現実が歪む ▸ 数字を作る、報告を歪める、測定自体を妨害する。ここまで来ると文化も崩壊 ▸ 2つの法則の違いは、数字が何に影響するかへの言及 ▸ グッドハートは「目標になる」まで。キャンベルは数字が評価、処遇、資源配分に影響する状況を扱う ▸ 本セッションでは、この影響の強さを「数字と報酬の距離」という言葉で表す
18. 数字と報酬の距離が近づくほど 人は成果を改善するより 数字そのものを作り始める
19. 数字を使う技術 ハノイのネズミ買取政策（1902） ▸ フランス統治下のハノイで、ペストを媒介するネズミが大発生 ▸ 行政は駆除の証拠として「ネズミの尻尾」に報奨金を出した ▸ 第1段階：尻尾のないネズミが街を走り回るようになる ▸ 市民は尻尾だけ切って、ネズミ本体は野に放していた（次の世代を産ませるため） ▸ 第2段階：報奨金目当てのネズミ養殖業者が出現 ▸ 駆除のための予算が、ネズミの生産に投資されていた ▸ 結末：政策は中止され、ネズミは政策前より増えた ▸ 目的「ネズミを減らす」ではなく、指標「尻尾を持ってくる」だけが最適化された ※ 有名な「コブラ効果」（英領インドのコブラ買取の逸話）は歴史的事実としては確認できず。ハノイの例は記録あり 19
20. 数字を使う技術 20 買い取るものを間違えると、それが養殖される ▸ ハノイの話は現代の組織でも起こる ▸ 問い合わせ対応件数を測る → 1件で済む問い合わせが複数のチケットに分割される ▸ バグ検出数を測る → 表記ゆれなどの軽微なものが大量に起票され、重大バグを探す時間が消滅 ▸ PR数を測る → 1つの変更が多数のPRに分割されて、レビュアーの負荷だけが増える ▸ レビュー件数を測る → 中身を読まないLGTMが連打される。件数は増えるが、問題は残る ▸ 共通の構造：行動の証拠を買い取ると、証拠だけが生産される
21. 数字を使う技術 数字は嘘をつかないが、 嘘つきは数字を使う 作者不詳の諺 fi "Figures don't lie, but liars gure." — マーク・トウェインの言葉として広まっているが典拠はなく、 記録上はCarroll D. Wright（米国の統計学者）が1889年に「古くからの言い回し」として引用したのが最初
22. 数字を使う技術 この諺は半分は正しく、半分はミスリード ▸ 諺は原因を「嘘つき」という人格に置いている ▸ ここまで見てきた過去の知見が示すのは逆 ▸ ベロシティのインフレにも、テスト対策授業にも、嘘つきは登場しない ▸ 普通の善人が、悪い設計の指標の下で、合理的に数字を作り始める ▸ 嘘つきが数字を使うのではなく、数字の使い方が嘘つきを作り出す 22
23. 数字を使う技術 「数字を作る」5つの手口 ▸ 期ずらし： 翌期の案件を前倒しで計上する。今期の障害を来期に起票する ▸ 合計は変わらず、評価のタイミングだけが操作される ▸ 分母の操作： 稼働率や成功率は、分子を増やすより分母を絞る方が簡単 ▸ 「対象外」「例外扱い」の定義がだんだん広くなっていく ▸ 定義の変更： 「完成」「対応済み」の定義が有利な方向に変化。定義の変更履歴は残ら（さ）ない ▸ 選別： 成功しやすい案件、簡単なチケットだけを選んで引き受ける ▸ 分割： 1つの仕事を複数件に刻んで件数を稼ぐ。PR分割、チケット分割、小分けのデプロイ ※ 嘘を報告するのではなく、現実か測定ルールのどちらかを加工し、報告そのものは正確なままにするのがゲーミングの本質 23
24. 数字を使う技術 24 ゲーミングを検知するシグナル ▸ 目標値への張り付き ▸ 目標ラインよりすこしだけ上に数字が分布。達成率98〜102%への集中は疑う ▸ 説明のつかない改善 ▸ プロセスも人も変わっていないのに数字だけ良化。原因を語れない改善はゲーミングの筆頭候補 ▸ 数字と現場の空気の乖離 ▸ ダッシュボードの数字は好調なのに現場の雰囲気が暗い。定性情報との矛盾は信頼できる警告 ▸ 指標間の矛盾 ▸ 速度は上がっているのに障害や苦情が増えている。ペア指標を置いていれば自動的に浮かび上がる ※ ゲーミングは制度設計の失敗の症状であり人格の問題ではないので、シグナルを検知して個人を裁いてはいけない
25. 第2部 壊れない指標の設計原則
26. 数字を使う技術 26 6つの設計原則 ▸ 1. 数字より目的を先に置く：測れるものから測り始めるとグッドハートの法則の罠に片足を突っ込む ▸ 2. 数字は必ず対にする：速度には品質を対にする。単独の数字は壊れるのでしわ寄せの行き先を測る ▸ 3. 先行指標と遅行指標を区別する：速いが操作されやすい数字と、遅いが確かな数字を使い分ける ▸ 4. 改善用と評価用を混ぜない：とにかく最重要。改善の数字を評価に流用したらその数字は死ぬ ▸ 5. 指標に寿命を設定する：指標は消耗品。壊れる前に捨てる ▸ 6. 定量は定性で三角測量する：数字は健康診断。異常値は診断結果ではなく問診の開始点 ※ 原則1〜3と6は代理のズレ（グッドハート）への、原則4は数字と報酬の距離（キャンベル）への対抗策。原則5は両方に効く
27. 数字を使う技術 原則1：数字より目的を先に置く ▸ 「何のために測るか」を言語化してから、それをいちばんよく代理する指標を選ぶ ▸ 目的が先、数字が後。逆順（測れるものから測り始める）がグッドハートの入口 ▸ ツールが吐く数字を並べただけのダッシュボードは目的に答えられない数字の典型 ▸ North Star Metricの発想 ▸ すべての指標が一つの目的に従属する構造を作る ▸ 意味のある指標かどうかを判定する質問：「この数字が動いたら、私たちは何をするのか」 ▸ 指標を追加する前にこれに答える。答えられない数字は見なくていい数字 27
28. 数字を使う技術 原則2：数字は必ず対にする ▸ ガードレール指標 ▸ メインの指標を追うことで犠牲になりそうなものを、あらかじめ対の指標として置いておく ▸ 速度 × 品質： リードタイムを縮めたければ、障害率を隣に置く ▸ 速度だけ追うとレビューやテストが削られて、歪みが品質に現れる ▸ 量 × 質： 商談件数を追うなら受注率を隣に ▸ 獲得 × 継続： 新規ユーザー数を追うなら継続率を隣に ▸ 獲得だけ追うキャンペーンは翌月解約するユーザーを買っているだけ ▸ ゲーミングのしわ寄せが行く先を先回りして測っておくのがペア設計 28
29. 数字を使う技術 29 良いペア設計の例：DORAの5指標 ▸ スループット ▸ 変更のリードタイム：コミットから本番稼働までの時間 ▸ デプロイ頻度：本番へのデプロイの頻度 ▸ 失敗したデプロイからの復旧時間：旧MTTR。2023年に改名して再定義 ▸ 不安定性 ▸ 変更失敗率：変更が障害を引き起こす割合 ▸ デプロイ手戻り率：バグ修正のための計画外デプロイの割合。2024年追加の5つ目 ▸ 重要な事実：速度と安定性はトレードオフではなく、優れた組織は両方高い ▸ 対で読む前提。「デプロイ頻度を2倍に」と単独で切り出した瞬間、小分けのデプロイが量産されて壊れる ※ 以前は指標は4つだったが、後に5つに変更された。なお個人評価に使うのは誤用
30. 数字を使う技術 原則3：先行指標と遅行指標を区別する ▸ 遅行指標：売上、NPS、解約率、障害件数など ▸ 結果そのものに近いので操作しにくく、確か。ただし動いたときには手遅れのことが多い ▸ 先行指標：商談数、デプロイ頻度、テストカバレッジなどの行動やプロセス指標 ▸ 早く動かせるが、結果との因果は仮説であり、操作されやすい ▸ 使い分け：遅行指標で方向性が正しいかを確認し、先行指標で日々の動きを決める ▸ 逆にすると、遅すぎる数字で日々を管理し、ゲーミングされた数字で戦略を判断することになる ▸ 帰結：操作されやすい先行指標にこそ原則2のガードレールを付ける ▸ 先行指標をそのまま目標にするのがとにかく危険 30
31. 数字を使う技術 31 原則4：改善用と評価用を混ぜない ▸ 同じ数字でも、誰が何のために見るかで性質がまったく変わる。指標を作るときは必ず用途を宣言する ▸ 改善用： チームが自分たちの実験のために見る ▸ 監視用： 経営がシステムの健全性を見る ▸ 評価用： 個人の処遇を決める ▸ この原則が6つの原則のなかで最重要だと考えてよい ▸ 「数字と報酬の距離」を直接制御できるのがこの原則。距離を決めるのは指標の中身ではなく用途 ▸ 改善用として導入した数字が、いつのまにか経営に報告されたり、評価面談に登場したりしたら最悪
32. 数字を使う技術 数字と報酬の距離を離すには ▸ 明文化して宣言する ▸ 「この指標は改善用であり、評価には使わない」と文書で宣言する。暗黙の運用は流用を防げない ▸ チームの数字はチームのもの ▸ 指標の第一の読者は当事者であるチーム。チームに断りなしに経営向けなどに転載しない ▸ 集計単位を個人にしない ▸ 個人単位にすると評価の香りがして防衛行動が始まる ▸ 集計単位を上げるほどゲーミングの動機は薄まる 32
33. 数字を使う技術 原則5：指標に寿命を設定する ▸ 指標は消耗品 ▸ どんなに上手く設計しても、使い続ければゲーミングの方法が発見され、学習され、共有される ▸ 「壊れない指標を探す」のではなく、発想を転換して、壊れる前に捨てる ▸ 四半期の棚卸しで問うべき3つのこと ▸ この数字はまだ目的と関連があるか ▸ ゲーミングの兆候（説明のつかない改善、目標値への張り付き）はないか ▸ この四半期で、この数字は実際に意思決定に使われたか ▸ 使われなかった指標は収集をやめる ▸ 測定にも認知にもコストがかかっているので、「せっかく取ってきたのに」は続ける理由にならない 33
34. 数字を使う技術 34 原則6：定量は定性で三角測量する ▸ 数字は健康診断 ▸ 健康診断の数値が悪くても、いきなり手術はしない。問診や詳細な検査で原因を探ってから治療する ▸ 異常値は診断ではなく問診の開始点 ▸ 「リードタイムが急増した→『サボっている』」は診断の飛躍 ▸ レビューで滞留したのか？テスト環境のせいか？承認プロセス？組織変更の影響？…などを問う ▸ 数字だけで結論を出す行為は、問診なしで手術するのと同じ ▸ 数字が急激に良化した場合も同じで問診する ▸ 説明のつかない改善は、ゲーミングが存在する可能性を示す
35. 数字を使う技術 35 SPACEフレームワークの例： 生産性は単一のDimensionでは測れない ▸ Satisfaction & Well-being：満足度と健康 ▸ 燃え尽きているチームの高生産性は長続きしない。離職や品質低下で数か月後に反動が来る ▸ Performance：成果。書いたコードの量ではなく、届いた価値 ▸ Activity：活動量。コミット数、PR数など ▸ 最も測りやすく、最も誤用されやすい ▸ Communication & Collaboration：協働。レビューの質、知識の流れ ▸ E ciency & Flow：中断されずに仕事が流れているか。待ち時間、手戻り ffi ※ SPACEでは「5つのDimensionから複数（2〜3）を組み合わせて見る」ことを推奨しており、Activity単独での測定は止めるよう明言している
36. 数字を使う技術 36 数字の読み方：「平均」という罠 ▸ リードタイム「平均5日」は説明としてはあまり役に立たない ▸ 大半は2〜3日で終わり、少数が30日かかる。平均は外れ値に引きずられる ▸ パーセンタイルで語る ▸ 「85%の作業は7日以内に終わる」の方がはるかに役に立つ。予測にも使える ▸ 外れ値こそが読むべきところ ▸ 30日かかった1件は平均の計算では異常値だが、それこそが改善すべき場所（ボトルネックがある） ▸ 平均は改ざんなしで嘘をつく ▸ 集計方法の選択だけで印象を正反対にできる。読む側のリテラシーも指標運用の一部
37. 数字を使う技術 37 ケーススタディ： バグ件数を評価のKPIにすると ▸ 原則1違反：目的と指標が遠い ▸ 目的は「品質向上」のはずが測っているのは「起票バグの数」。検出を頑張るほど悪化して見える ▸ 原則2違反：対がない ▸ 件数だけ追うと、起票の抑制、「仕様です」、重大度の過小評価を誘発するが、検知する指標がない ▸ 原則4違反：報酬との距離がゼロ ▸ 用途を設計せず数字を個人に直結させた。バグを「見つけない」インセンティブが最大化される ▸ 予想される結末 ▸ バグ件数は減少して数字上では品質は向上しているはずが、本番障害や問い合わせが増える
38. 数字を使う技術 38 ケーススタディ： 6原則を踏まえて再設計する ▸ 目的を言語化する（原則1） ▸ 「ユーザーが障害に遭遇せず価値を受け取れている状態」を目的とし、そこから逆算して指標を選ぶ ▸ ペアで測る（原則2、3） ▸ 本番障害数（遅行）× 変更失敗率 × 検出フェーズ比率。起票を抑制すると数値が悪化して見える構造 にする ▸ 用途を宣言する（原則4） ▸ チームの改善用と明文化し、個人評価には使わないと宣言。集計単位はチーム ▸ 寿命と問診（原則5、6） ▸ 四半期ごとに指標自体を棚卸しし、数字が動いたらチームで問診してから対策を打つ
39. 数字を使う技術 39 生成AI時代の生産性測定（話すと長くなるのでサマリーだけ……） ▸ コード量やコミット数の意味が消滅した ▸ コードを書くコストがほぼゼロになったので、たくさん書いたことが成果を意味しなくなった。単にレビュー 負債を引き起こしただけということも ▸ ゲーミングのコストもゼロになった ▸ 指標を与えればそれを最大化する成果をAIが無限に生成できる。指標が壊れるまでの時間が劇的に短縮 ▸ 重心がアウトカムと品質に移動 ▸ 測る価値が残るのは、届いた価値、変更失敗率や復旧時間などの品質、回復力、意思決定の質 ▸ 原則は変わらないが、見直しのサイクルは変わる ▸ 指標が壊れる速度が上がったぶん、原則5（寿命）の見直しサイクルを速く回す必要がある
40. 第3部 原則の実装 ー OKR、人事評価、経営報告
41. 数字を使う技術 「Objectiveがあるから」ではまったく不十分 ▸ よくある説明：「KRの上にObjectiveがあるから目的が失われない」 ▸ これは主張であってメカニズムではない ▸ Objectiveを掲げたままKRをゲーミングすることは可能 ▸ つまり、目的が存在するからといって、その目的が機能するとは限らない ▸ 機能しているOKRとObjectiveという飾りのついたただのKPI管理の違い ▸ 両者を分けているのは思想ではなく、3つの運用条件 41
42. 数字を使う技術 42 OKRが機能する3つの運用条件 ▸ (1) 報酬と切断する（原則4の実装） ▸ KR達成率を賞与、昇給、評価に直結させない ▸ 報酬と切り離すことで、野心的なKRを置きやすくする ▸ (2) 100%必達を前提にしない ▸ ストレッチ型のKRでは100%達成を前提にしない ▸ 必達にすると、最初から達成できるKRが選ばれたり、期ずらし、分母操作などのゲーミングも誘発する ▸ (3) 四半期ごとに見直す（原則5の実装） ▸ KRがまだObjectiveを適切に代理しているかを確認する ▸ ズレやゲーミングの兆候があれば変更したり廃止したりする
43. 数字を使う技術 43 3条件を満たさないOKRは単なるKPI管理に退化しやすい ▸ KRを賞与に連動させると？ ▸ キャンベルの法則。サンドバッギング（達成可能な低い目標だけ置く）が始まり、組織の目標水準が 下がっていく ▸ 100%必達を求めると？ ▸ KRはチャレンジのための道具から操作対象に変わる。期末に「達成」の定義を巡る交渉が始まる ▸ 同じKRを何年も使い回すと？ ▸ ゲーミングが学習されつくして、数字と実態が乖離していく
44. 数字を使う技術 44 人事評価では数字をどう使うか ▸ 複数ソースで見る ▸ 数字＋マネージャーの観察＋360度フィードバック＋成果そのもの＋周囲への影響 ▸ 単一ソースの評価は、そのソースへのゲーミングを誘発する ▸ 数字は会話の入口 ▸ 入口として使えるのは、本人が背景を語ることができる成果に近い遅行指標だけ ▸ 面談で数字は「結論」ではなく、「この数字の背景で何があったのか」を語ってもらう入口として使う ▸ 「数字を評価から完全に排除しろ」という話ではない ▸ それは主観と政治への逆戻り。数字を唯一の根拠にするなという話
45. 数字を使う技術 経営に数字を求められたら ▸ 拒否は悪手 ▸ 「数字は危険なので出せません」は通らないし、信頼を失うだけ。経営の要求自体は正当 ▸ 監視用として設計して渡す ▸ 個人やチームの比較ではなく、システム全体の健全性を示す形に集計してから渡す ▸ 説明と一緒に渡す ▸ 数字だけ渡すと、受け取った側で勝手な解釈が起きる。変動の背景と打ち手の説明を添える ▸ ランキングは断る ▸ 他チームとの比較ではなく、代わりに自分たちのチームのトレンドを出す 45
46. 数字を使う技術 46 よくある反論と、それに対する再反論 ▸ 「数字で評価しないなら、何で評価するのか？」 ▸ 数字を捨てるのではなく、唯一の根拠にしないだけ。数字単独評価の方があてにならない ▸ 「ゲーミング前提で設計するのは性悪説では？」 ▸ 逆。善人が合理的に振る舞うだけで指標は壊れる、というのが過去の知見。性善説に立つからこそ、人 を責めずに制度を設計する ▸ 「うちは数字がないと人が動かない」 ▸ まず「動かすための数字」と「理解するための数字」を分けるところから始める ▸ 「ここまで運用する工数がない」 ▸ 最初の一歩は指標を減らすこと。運用コストは指標の数に比例する
47. 数字を使う技術 本日のまとめ ▸ 数字は答えではなく、問いを生む道具 ▸ 数字が動いたら、まず「何が起きたのか」を問う ▸ 目的を先に置き、数字はその代理として使う ▸ 数字そのものの達成を目的にしない ▸ 数字は単独で見ず、しわ寄せの行き先も測る ▸ 速度には品質、量には質を対にする ▸ 改善用の数字と評価用の数字を混ぜない ▸ 報酬に近づくほど、ゲーミングの圧力は強くなる ▸ 指標は定期的に見直し、必要なら捨てる 47

Comment

No comments...