新人PMだった頃、私は「優秀なエンジニア = 技術力が高い人」だと思っていました。
仕様書を読みこなし、コードを書き、難しい問題を解く人。それが優秀さの定義だと、ほぼ無意識に信じていました。
でも、PMとして10年以上現場を見てくる中で、その定義は静かに崩れていきました。
技術力が高くても、現場で頼りにならない人がいます。 逆に、技術評価で目立たないのに、「この人がいないと回らない」と全員が無言のうちに認めているエンジニアがいます。
5年目を過ぎたあたりから、私の中の「優秀さ」の輪郭が変わってきました。
PMの立場で本当に現場を支えていた人たちを思い返してみると、彼らは大きく3つのタイプに分けられました。
この記事は、そのタイプを実際のエピソードを交えて言語化してみる試みです。「こんな人いるよね」と頷けるエンジニアもいれば、「自分はこの軸が足りないかも」と気づくエンジニアもいるかもしれません。
PMの主観であることは最初に断っておきます。これは技術評価の話ではありません。プロジェクトを回す立場から見た、信頼の根拠の話です。
Type 1：カオスを構造に変える人#
どんな人か#
複雑な作業を、「他人に渡せる粒度」まで分解できる人です。
仕事の見えていない部分を可視化して、誰がいつ何をやればよいか整理できる。マネジメントの素養を持ったエンジニア、と言ってもいいでしょう。
印象に残っている2人#
1人目は、40代のベテランエンジニア。物腰が柔らかくて、声を荒げているところを見たことがない人でした。
ある中規模案件で、5人のチームに作業を割り振る場面がありました。仕様の整理がほぼ終わっていない、ふわっとした状態のスタートでした。
普通なら、PMの私が一気に細かいタスクに分解して、各エンジニアに割り振る作業が必要になります。けれど彼は、ホワイトボードの前で30分くらい手を動かしただけで、5人分の作業をきれいに切り分けました。被りもなければ、抜けもありません。
しかも、各タスクの粒度が「やる人が迷わない」レベルまで揃っていました。タスクA、タスクB、タスクC……と並んだそれを見て、私は「これ、私が考えるより分かりやすい」と思ったほどです。
結果として、その案件は予定と実績の差異が驚くほど小さく終わりました。スケジュールが守られただけでなく、チームメンバーが迷わなかったことで、追加の調整工数も発生しませんでした。
もう1人は、配属2年目の若手。華奢で物静かな印象で、声を張るタイプではありませんでした。
その彼女が、ある案件のリーダーに抜擢されました。経験年数からすれば早い登用で、周囲も内心ヒヤヒヤしていたと思います。
でも結果として、彼女は工程管理もスケジュール立ても案件完遂もやり切りました。プレッシャーで潰れることなく、淡々と。
彼女を見て感じたのは、「整理する力」は経験年数と無関係だということでした。
「優秀じゃない人」との違い#
このタイプの逆は、「タスクの粒度が荒い人」「スケジュールと実績がいつもズレる人」です。
タスクが粗いと、PM側が常に追加で分解しなければなりません。実績がズレると、リカバリープランをPM側で持たなければなりません。結果としてPM側の負荷が倍になります。
Type 1の人がチームにいると、この負荷が劇的に減ります。
このタイプの本質#
「自分の手元の作業が見えている」だけでなく、「他人の手元の作業まで見えている」。さらに、それを他人が動ける形に変換できる人。
ここに、私が「優秀」と言いたくなる根拠があります。
Type 2：プレッシャー下でも精度が落ちない人#
どんな人か#
焦り・トラブル・単調作業の中でも、品質が安定する人です。
時間に追われても、繰り返しの作業でも、最後の1個まで同じ精度で仕上げられる人。
印象に残っているシーン#
20代の若手エンジニアが、社内のLAN構築をしていた時のことです。
予定していた長さのLANケーブルが、納品ミスで届きませんでした。仕方なく、裸のLANケーブル（端子のついていない状態のもの）と端子だけが揃いました。
「これ、現場で1本ずつ作るしかないですね」と言いながら、彼は淡々と作業を始めました。
1時間で100本作って、全部繋がりました。
これがどれだけ凄いかは、LANケーブルを自作したことのある人にしか伝わらないかもしれません。1本作るのに最低でも1〜2分かかる作業です。それを1時間で100本、しかも緊急対応の最中で仕上げたのです。
しかも、不良が1本も出ませんでした。
「精度を落とす人」との違い#
普通、こういう作業は途中から精度が落ちます。気が散ったり、雑になったり、確認が甘くなったり。
彼の場合、後で振り返って思ったのは、「休憩の挟み方が良かった」ということでした。
ずっと続けていた印象がありません。10〜15本作るごとに、少し手を止めて、また作業に戻る。リズムが安定していました。
これは技術ではなく、身体感覚です。「自分が集中力を保てるリズムを知っている」という、感覚レベルの能力。
このタイプの本質#
「焦りを行動に変えない」「リズムを作れる」。
緊急対応で投入されたとき、このタイプの人がいると現場の温度が下がります。安心感がチーム全体に伝わるからです。
「誰でもできる作業を、誰よりも安定して終わらせる」──プロジェクトの隠れた屋台骨は、こういう人たちが支えています。
Type 3：チームの「答えの源」になる人#
どんな人か#
質問が集まる人。仕様・知識・経験が引き出せる場所になっている人です。
チームの認識ハブ、と言ってもいいでしょう。
印象に残っている2人#
1人目は、60代のベテラン。インフラ案件で、お客さんの予算が限られている状況でした。
普通なら「この予算では難しいです」と言いたくなる金額でした。でも彼は、ハードウェアもミドルウェアも幅広く知識を持っていて、「この組み合わせなら、予算内で機能要件を満たせる」という具体的な提案ができました。
予算ありきで構成を考えるのは、知識の総量が試される作業です。「これなら使える」「これは古いから避けたほうがいい」「これは安いけど運用コストが高い」──こういう判断を瞬時にできる人は、年齢を問わず本当に少ないものです。
もう1人は、30代後半の中堅エンジニア。人当たりがよく、場を明るくする雰囲気の人でした。
その人は、プロジェクトが発足した最初期から在籍していて、仕様の歴史をまるごと記憶していることが強みでした。
別チームから「この仕様って、なんでこうなってるんですか？」と質問が飛んでくる。彼は3秒くらい考えて、「2年前の要件定義で、こういう経緯で決まりました」と確信をもって即答できる人でした。
仕様への即応性は、情報のストック量 × 検索性で決まります。彼は両方を持っていました。
共通する2つの能力#
この2人を見ていて気づいたのは、「知識を持っているだけ」では足りないということです。
優秀な「答えの源」になる人は、2つの能力を持っています：
- 知識の収集能力──吸収しに行く姿勢、新しい情報をキャッチする習慣
- 人に説明できる能力──吸収したものを、他人が理解できる形で出せる
知識を持っているけど、説明が下手な人は意外と多いです。逆に、説明は上手だけど知識が浅い人もいます。両方持っている人が、本当の意味で「答えの源」になれるのです。
このタイプの本質#
このタイプがチームにいると、チーム全体の認識が揃います。
SIerの現場でよくある「同じ仕様を10人が違って解釈する」という事故が起きにくくなります。なぜなら、迷ったときに聞ける場所があるからです。
これは目に見えにくい価値ですが、プロジェクト全体のリスクを確実に下げています。
3タイプに共通する「優秀さの本質」#
3タイプを並べてみると、技術力とは別の、もっと深い共通点が見えてきます。
Type 2：精度を落とさず最後まで完遂する
Type 3：知識を蓄えて他人に渡せる
──全部に共通するのは、「他人を助けられる」という1点です。
Type 1は、PMやチームメンバーの「割り振り作業」を肩代わりしています。 Type 2は、緊急時の「精度の不安」を取り除いています。 Type 3は、チーム全体の「認識のズレ」を埋めています。
優秀なエンジニアは、自分が突出しているのではなく、チーム全体の総和を底上げする力を持っています。
技術力が高いだけでは、自分の手元しか変わりません。 他人を助けられる人だけが、現場全体を変えていきます。
これが、PMとして10年現場を見てきて、私が辿り着いた結論です。
PMからの感謝──彼らがいた現場の話#
この記事を書きながら、思い出していたことがあります。
紹介した5人のエンジニアたちは、それぞれ違う案件で違う立場にいました。けれど、彼らがチームにいた現場は、例外なく「回っていた」のです。
PMの仕事は、リスクを管理することだと言われます。でも実際には、「リスクを下げてくれる人を見つけること」の方が大きいんじゃないかと、私は思っています。
- Type 1のエンジニアがいれば、私は割り振りの精度に悩まなくて済みます。
- Type 2のエンジニアがいれば、私は緊急対応のクオリティに悩まなくて済みます。
- Type 3のエンジニアがいれば、私は仕様の食い違いに悩まなくて済みます。
彼らは、私の仕事を静かに楽にしてくれていました。
PMとして10年以上経った今、感謝を言葉にする機会がないままでしたが、もしあのときの彼らがこの記事を読むことがあれば、伝えたいことがあります。
あなたたちがいたから、あの現場は完成したんだよ。 と。
あなたへの問い#
──ここから、読んでくれているあなたに問いかけたいです。
あなたがPMOで現場を見ているなら、どのタイプの人と組んでみたいでしょうか？
Type 1の構造化能力に頼りたい人もいれば、Type 2の精度に救われたい人もいるはずです。Type 3のような「答えの源」を、自分のチームに迎えたい人もいるでしょう。
組みたい相手を考えることは、自分のチームに今足りない軸を見つけることでもあります。
もし「うちのチームには、こういうタイプがいる」「自分はこれだ」と思った経験があれば、ぜひお問い合わせフォームから教えてください。
PMOキャリアラボでは、現場のリアルな声を集めて記事にしていく予定です。
