■ この記事はこんな人におすすめ

評価面談で「頑張ってるのは分かるんだけどね…」と言われたことがある人
自分の成長が正しい方向に向かっているのか不安な人
実務未経験からエンジニアとして評価されたい人
チームメンバーの成長を支援する立場になったばかりの人
「気合い」と「根性」以外の武器が欲しい人

■ この記事で得られること

自分の仕事を「数値」で語れるようになります
「変数」と「定数」を切り分け、注力すべきことに集中できるようになります
成長速度を上げるための具体的な行動指針が手に入ります
評価される人になるための「型」が理解できます
短期と長期の両方の視点でキャリアを考えられるようになります

■ 参考書籍

安藤広大『数値化の鬼――「仕事ができる人」に共通する、たった1つの思考法』
https://www.amazon.co.jp/dp/B09PV144BN/

■ 関連記事

同じ著者が執筆した「とにかく仕組み化」と「リーダーの仮面」についても下記の記事でまとめているので興味があれば見ていただけると幸いです。

1. 結論

仕事ができる人になりたいなら、すべてを一旦「数値」に変換して考える。これだけです。

「英語力を上げる」は目標ではありません。「TOEICで800点をとる」が目標です。
「コードの品質を上げる」は目標ではありません。「レビュー指摘件数を月20件から5件に減らす」が目標です。

この違いが分かるかどうかで、成長速度は驚くほど変わります。

なぜなら、数値化されていない目標は評価も改善もできないからです。
今の自分がどこにいて、ゴールまであとどれだけ距離があるのか。それが分からない状態で走り続けるのは、コンパスなしで航海するようなものです。

そして、数値化の本質は「厳しく管理されること」ではありません。
自分の行動を客観視し、正しい方向に修正し続けるための道具です。

2. 具体的にやること

■ ① 日頃の会話に数値を入れる

NG例：

「今回のリファクタリング、かなり良くなったと思います！」

OK例：

「今回のリファクタリングで、該当モジュールの循環的複雑度が32から11に下がりました。テストケースも8件追加しています」

■ ② 「熱意 → 数値」ではなく「数値 → 熱意」の順で伝える

NG例：

「この技術、絶対イケてるんで導入したいです！めちゃくちゃ興味あるんです！」

OK例：

「現状ビルドに8分かかっていて、1日平均12回ビルドするので約96分/日のロスです。この構成なら2分程度に短縮できる試算です。ぜひ挑戦させてください」

■ ③ Pに時間をかけすぎず、1秒でも早くDに進む

NG例：

「どう成長するのが最短ルートか」を悩み続ける。技術書を比較し、ロードマップを眺め、勉強計画を練り直す。1ヶ月経っても、実際に書いたコードはゼロ

OK例：

「まず毎日1つ機能を作る」と決めて今日から始める。走りながら足りないものに気づき、計画を修正していく

■ ④ KPIは「数値化されている」かつ「自分でコントロールできる」ものに絞る

NG例：

KPI：チームの障害発生件数ゼロ（他人の行動に依存していてコントロール不能）

OK例：

KPI：自分の担当PRに対するテストカバレッジ80%以上を維持する

■ ⑤ 「確率」だけで自分を評価しない

NG例：

「今月のPR、5本出して5本ともマージされました。承認率100%です」

OK例：

「今月のPR、40本出して32本マージ、承認率80%でした。落ちた8本から学んだ点は…」

■ ⑥ 「変数」と「定数」を切り分ける

NG例：

「レガシーコードがひどいから成果が出ない」「上司が技術に理解がない」（＝定数に文句を言っている）

OK例：

「レガシーコードの中でも、自分が触る頻度の高いこの3ファイルからテストを書く」（＝変数に注力している）

■ ⑦ 人のアドバイスも書籍も、すべて「仮説」として扱う

NG例：

「〇〇さんが言ってたから」「あの本にそう書いてあったから」で思考停止する

OK例：

「〇〇さんの方法を2週間試す。効果測定の指標はこれ。効果がなければ別の変数を探す」

■ ⑧ 変数を増やしすぎず、定期的に捨てる

NG例：

KPIが12個あり、全部が中途半端

OK例：

KPIは最大5個まで。四半期ごとに見直して、効いていない変数は切り捨てる

3. 各項目の説明

■ なぜ「数値」が必要なのか

書籍の冒頭で語られるのは、公平性の話です。

売り上げが「いくら」だったのか
改善行動が「何回」あったのか
期限を「どれだけ」守ったのか

これらが曖昧なままだと、評価は「印象」で決まってしまいます。声が大きい人、上司と仲がいい人が得をする世界です。

逆に言えば、数値化はあなたを守る武器でもあります。
「頑張っているのに評価されない」の多くは、頑張りが可視化されていないだけなのです。

■ 「仕事ができる人」の定義

本書での定義はシンプルです。

評価者から評価を得られる人

冷たく聞こえるかもしれません。しかしこれは非常に実用的な定義です。
「仕事ができる」を人によってバラバラな定性的イメージで語る限り、そこに到達する道筋は作れません。

そして、ビジネスは「過程」より「結果」を重視します。やり方は自由。だからこそ、結果に到達するための「型」 が必要になります。

■ 行動量（D）を極限まで増やす

識学の考え方では、Pに時間をかけず、1秒でも早くDに進むとされています。

ここで誤解してはいけないのは、行動量を増やす＝残業して長時間働く、ではないという点です。

エンジニアに置き換えるなら：

❌ 悪い行動量の増やし方
  - 22時まで残ってタスクを消化する
  - 手を動かした「時間」を成果だと思う

✅ 良い行動量の増やし方
  - 検証サイクルを1日3回から10回に増やす
  - PR を小さく分割して、レビュー回数を増やす
  - ローカル検証で30分かかる処理を自動化して、試行回数を上げる

行動量とは「試行回数」であり、「拘束時間」ではありません。

■ KPIの2つのルール

KPIとは、目標を達成するために数値化された指標のことです。ルールは2つだけ。

ルール	説明	エンジニアの例
明確に数値化されている	誰が見ても達成/未達が分かる	「PRを週5本出す」
自分でコントロール可能	他人や運に依存しない	「レビュー返答を24時間以内に」

そして、KPIを追う上で最も注意すべき罠が 「KPIの達成が目的化すること」 です。

KPIはあくまでP（目標）に到達するための手段。
「PRを週5本出す」というKPIのために、意味のない細切れPRを量産し始めたら本末転倒です。

だからこそ、識学では目標は最大5つまでと定めています。常に思い出せる数でなければ、意識できないからです。

■ 「成約率80%」の罠

本書で最も刺さるのが、この2章の例え話です。

人物	行動数	成果数	確率
Aさん	10件	8件	80%
Bさん	100件	50件	50%

確率だけで評価するとAさんの勝ちです。しかし、成果の絶対量はBさんが6倍以上。

そして最も恐ろしいのは、確率で評価する組織では「チャレンジすることが損」になるという点です。

エンジニアの世界でもまったく同じことが起きます。

確率で自分を守り始めた人の症状

- 失敗しない範囲のタスクしか取らなくなる
- 新しい技術の提案をしなくなる
- 「絶対に通るPR」しか出さなくなる
- 質問しなくなる（無知だと思われたくない）

経験を積むほど「失敗が怖くなる」のは自然なことです。だからこそ、意識的に分母を増やしにいく必要があります。

■ 「変数」と「定数」の見極め

ここが本書の核心です。

変数＝考えるべきこと・変えられること
定数＝考えても無駄なこと・変えられないこと

仕事で重要なのは、この2つを見極めて変数にだけ注力することです。

変数の見つけ方

まずは自分で仮説を立てて検証してみる
仕事を細かく分解し、「行動（D）」を1つに絞って注力する
結果の変化を確認し、成果が小さければ「行動（D）」を変えてみる

これはつまり、「工程」を分解し、「数字」を数えて、「なぜ？」を繰り返すということ。
PDCAでいう「C」と「A」に該当します。

エンジニアなら日常的にやっているはずです。パフォーマンスチューニングと同じ発想ですね。

遅いAPIの改善（＝変数の特定）

1. 工程を分解    → DB接続 / クエリ実行 / シリアライズ / ネットワーク
2. 数字を数える  → それぞれ 5ms / 1200ms / 30ms / 15ms
3. なぜ？を繰り返す → クエリが遅い → なぜ？ → インデックスがない

⇨ 真の変数は「インデックス」だった

これを自分のキャリアや仕事の進め方に対して行うのが本書の主張です。

「人から聞いたこと」もすべて仮説

書籍も、先輩のアドバイスも、この記事も、すべて絶対的な成功法則ではありません。

まずは「仮説」として行動（D）し、目標達成に変化があるかを検証する。
自分の成功体験も積極的に公開すべきですが、それは常に 「役立つ可能性がある」という前提 を忘れないこと。

成功のための絶対法則は存在しない。

■ 変数は放っておくと増殖する

改善を続けていると、変数もKPIもどんどん増えていきます。

変数が多い状態は、プレイヤーにとってもマネージャーにとっても管理コストが増え、成果が中途半端になる原因になります。

だから定期的に「捨てる」判断が必要です。
「本当に重要なこと」に注力する。よく言われることですが、実践できている人は驚くほど少ないです。

マネージャーの役割

本書は4章で、マネージャーの仕事を明確に定義しています。

部下がKPIとして設定している「変数」をチェックする
不要な「変数」を減らし、重要な「変数」に気づかせる

そして、こう述べられています。

間違った努力を放置せずに認知させることが「真のフィードバック」である。

優しさから見て見ぬふりをすることは、フィードバックではありません。

■ 短期と長期、2つの視点

1章〜4章はすべて「短期的」な成長の話でした。5章で視点が切り替わります。

「短期的には損でも、長期的には得になる」 という視点です。

エンジニアなら心当たりがあるはずです。

短期的には損	長期的には得
テストを書く時間	変更に強いコードベース
ドキュメントを書く時間	チーム全体の生産性
レビューで丁寧に指摘する	メンバーの成長
新技術の学習	選択肢の広がり

そして長い期間で成果を判断する場合、「行動実績」と「具体的な成果」は分けて評価すべきです。

「行動実績」だけの評価は「やったもの勝ち」につながります。
一方で、成果だけを見ていては、正しい行動を積み上げている人の芽を摘んでしまいます。

マネージャーに求められる勇気と覚悟

5章の最後は、マネージャーへのメッセージで締められます。

目標が達成していなくても「行動」は正しいと判断した場合に背中を押してあげる勇気
仮に成果が出なかった場合でも、自分の指示で続けさせたことに対して 「責任」を持つ覚悟

数値化はメンバーを追い詰めるためのものではなく、正しい行動を守るためにあるという話です。ここが本書で一番好きな部分でした。

まとめ

すべてを一旦「数値化」して考える。曖昧な言葉は評価も改善もできない
「仕事ができる人」＝評価者から評価を得られる人。定性的なイメージで語らない
Pに時間をかけすぎず、1秒でも早くDへ。行動量とは試行回数であり、拘束時間ではない
KPIは「数値化」×「コントロール可能」 の2条件を満たすものだけに絞る
確率で自分を守るとチャレンジが止まる。意識的に分母を増やす
変数と定数を見極め、変数にだけ注力する。工程を分解し、数字を数え、なぜ？を繰り返す
人のアドバイスも書籍もすべて仮説。絶対的な成功法則は存在しない
変数は増殖する。定期的に捨てる。目標は最大5つまで
短期の損は長期の得になりうる。行動実績と具体的成果は分けて評価する

結局何をすればいいの❓

明日から、この順番でやってみてください。

【今日中にやる】

今の自分の目標を紙に書き出す。数値になっていないものに印をつける
印がついたものを、すべて数値表現に書き換える（例：「コード品質を上げる」→「レビュー指摘を月5件以下に」）

【今週中にやる】
3. 書き換えた目標のうち、「自分でコントロールできないもの」を消す
4. 残ったものを最大5つまで絞る。6つ目以降は捨てる勇気を持つ
5. 今抱えている悩みを「変数」と「定数」に仕分けする。定数への文句は今日でやめる

【毎週やる】
6. 週の終わりに、KPIの数字を実際に数える（体感ではなく、実測する）
7. 目標との差分を確認し、「なぜ？」を3回繰り返す
8. 新しい仮説を1つ以上立てて、次の週に検証する

【四半期ごとにやる】
9. KPIを棚卸しする。効いていない変数は切り捨てる
10. 「短期的には損だが長期的に得なこと」に投資できているか振り返る

最初の一歩は「①今の目標を書き出す」だけです。5分でできます。
そこから逃げずに数値化できるかが、この本を読んだ人と読んで終わった人の分かれ道になります。

株式会社シンシア

株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。

※ シンシアにおける働き方の様子はこちら

シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。