評価されるリードは何が違う？──技術より効く意思決定の型

リードになった。あるいは、リードっぽい立ち回りをしている。
なのに評価が伸びない。むしろ疲れる。責任だけが増えて、手触りのある前進が少ない。

この状態にいる人は多い。
そして多くの人が「もっと技術を磨かないと」と思う。でも僕は、ここがズレやすいポイントだと思っている。

評価されるリードの差は、技術力そのものより 意思決定の質と再現性 に出る。
極端に言えば、実装が強い人は多い。だが、チームやプロジェクトを前に進める“決め方”が強い人は少ない。

今日は、評価されるリードが無意識にやっている「意思決定の型」を、現場でそのまま使える形に落として書く。

リードの仕事は「作る」より「決める」に寄っていく

中堅までの成長は、作れるものが増えるほど加速する。
でもリードに入ると、仕事の中心は変わる。

• 何を作るか（スコープ）

• いつ作るか（優先度）

• どう作るか（設計・技術選定）

• どこまで守るか（品質）

• 誰がやるか（分担・育成）

ここで問われるのは、正解を当てる力よりも、納得できる決め方と事故らない決め方だ。

評価されないリードは、技術が弱いのではなく、決め方が属人化していることが多い。
逆に評価されるリードは、決め方が「型」になっている。

評価されないリードがハマる3つの落とし穴

1) 「全部自分で判断」してしまう

速い。正確。だから自分で決めた方が早い。
でもそれを続けると、あなたがボトルネックになる。

• 周りが判断しなくなる

• 問い合わせが集中する

• あなたの不在で止まる

• そして燃える

評価されるリードは、自分の判断を減らすのがうまい。
「判断の仕組み」を作って分散する。

2) 重要な意思決定が「口頭」で流れる

会議で決まった気がする。チャットで流れた気がする。
けど後から「そんな話は聞いてない」「前提が違う」が起きる。

意思決定が口頭だけだと、プロジェクトは必ず揉める。
揉めた瞬間、リードの評価が落ちる。理由は簡単で、説明責任を果たせないから。

3) 「正しさ」で勝とうとして疲弊する

リードになると、技術的に正しい選択をするだけでは足りない。
ステークホルダーは、コスト、期限、リスク、政治、体裁…全部を背負っている。

正しさだけで押すと、対立が増える。合意形成が遅れる。
結果として、プロジェクトが停滞し、あなたが消耗する。

評価されるリードは、正しさの押し付けではなく「比較軸」と「落としどころ」で前に進める。

技術より効く「意思決定の型」：7つのテンプレ

ここからが実務編。
この7つを“書ける状態”にすると、リードの仕事が軽くなるうえ、評価も上がりやすい。

型1：目的を1行で固定する（Decision North Star）

意思決定は、目的がズレると全部ズレる。

• 今回の目的は何か

• 何が達成されれば成功か

• 何を犠牲にしないか

例：

• 「速度改善」では弱い

• 「p95を◯秒以下にし、問い合わせ起因のクレームを月◯件以下にする」まで落とす

目的が1行で言えるだけで、技術選定も優先度もブレない。

型2：選択肢を必ず3つ出す（Option Set）

評価されないリードは、最初から答えを決めてしまう。
評価されるリードは、必ず選択肢を並べる。

• A：短期で早い

• B：中期で堅い

• C：長期で強い（ただし重い）

選択肢があると、会話が意思決定になる。
選択肢がないと、会話が説得になる。説得は疲れる。

型3：比較軸を5つに固定する（Comparison Axes）

比較軸が揃うと、議論が荒れない。
おすすめはこの5つ。

• コスト（開発・運用）

• 期限（いつまでに）

• 品質（何を守るか）

• リスク（事故る可能性と影響）

• 変更耐性（将来の拡張・保守性）

この5軸で表にすると、反対意見が「好き嫌い」から「軸の違い」に変わる。

型4：前提と制約を明文化する（Assumptions & Constraints）

意思決定が後から覆る一番の理由は、前提が共有されていないこと。

• 同時接続は最大◯

• 予算は増えない

• 人員は2名固定

• 監査要件がある

• レガシーとの互換が必要

前提を書かない決定は、未来で必ず壊れる。

型5：リスクを「起きたら痛い順」に並べる（Risk Register）

リスクは列挙するだけだと役に立たない。
重要なのは順番。

• 起きやすい × 影響が大きい

• 起きにくい × 影響が致命的

さらに、各リスクに「検知方法」と「回避策」をセットする。

• どうやって早期に気づくか

• どうやって起きないようにするか

• 起きたらどうするか（切り戻し・停止条件）

これがあるリードは、炎上耐性が高い。

型6：撤退条件（やめ時）を決める（Exit Criteria）

撤退条件がないと、プロジェクトはズルズル死ぬ。
リードの評価も一緒に沈む。

• 性能がこのラインを超えないなら方式を変える

• 工数が◯人月を超えたら縮退する

• エラー率が◯%を超えたらロールバックする

「やめ時」を決めるのは弱さじゃない。強さだ。

型7：決定ログを残す（Decision Record）

最後に、決定そのものを残す。

• 何を決めたか

• いつ、誰が

• なぜそう決めたか（比較軸・前提）

• 何を捨てたか

• 次に見直す条件は何か

このログがあると、後からの揉め事が激減する。
そして何より、リードとしての説明責任を果たせる。評価が安定する。

意思決定の型を入れると、仕事がこう変わる

• 会議が「説得」から「選択」になる

• 変更要求が来ても、目的と比較軸で整理できる

• 反対意見が“感情”ではなく“軸”になる

• あなたがボトルネックになりにくい

• チームが育つ（決め方を共有できるから）

つまり、リードの仕事が「気合」から「設計」に変わる。

最後に：評価されるリードは、正解を知っている人じゃない

評価されるリードは、正解を当て続ける人ではない。
不確実な状況で、みんなが納得できる決め方で前に進める人だ。

そのために必要なのが、意思決定の型。
型があると、あなたの負担が減る。プロジェクトが安定する。チームが強くなる。結果として評価が上がる。

——あなたの現場で、いま一番「決め方が曖昧」なのはどこだろう？
技術選定？スコープ？品質？優先度？
まず1つだけ、決定ログを残すところから始めてみない？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
気に入って頂けたらマガジンのフォローもよろしくお願いします！