同じ技術力なのに、評価が分かれる理由
同じプロジェクトで、同じ程度の技術力を持つ二人のエンジニアが、まったく違う評価を受けることがあります。
一人は「仕事が正確で安心して任せられる」と言われている。もう一人は「あの人がいるとプロジェクトが前に進む」と言われている。どちらも悪い評価ではありませんが、後者のほうが大きな仕事を任され、キャリアの広がり方が明らかに違う。
この差を生んでいるのが、いわゆる「提案力」です。エンジニアの提案力とは、技術的な知見をもとに「こうしたほうがいい」と声を上げる力のことです。
「言われたとおりに作る」はなぜ評価が止まるのか
まず、「言われたとおりに正確に作る」こと自体は非常に重要なスキルです。
しかし、このスキルには一つの限界があります。それだけでは「この人でなければ」という存在にはなりにくいということです。
仕様どおりに作ることは、極端に言えば「仕様書が正しければ誰がやっても同じ結果になる」仕事です。もちろん品質や速度の差はありますが、プロジェクトの関係者から見ると、個人の貢献が見えにくい。
一方、「こうしたほうがいいのではないか」と声を上げるエンジニアは、その発言自体がプロジェクトに個人の痕跡を残します。提案が採用されなかったとしても、「この人はプロジェクト全体を考えている」という印象を与えます。
PMやPLの立場から見ると、「自分で考えて動ける人」と「指示を待つ人」では、任せられる仕事の範囲が根本的に異なるからです。指示を待つ人に何かを任せるには、誰が・何を・どこまでやるかを細かく定義して渡す必要があります。一方、自分で考えて動ける人には「この方向でお願いします」と伝えるだけで成立する。任せる側のマネジメントコストが、桁違いに違うのです。
エンジニアの提案力は3つのレベルに分かれる
「提案力」と一口に言っても、実はレベルがあります。
レベル1：問題を指摘できる
最初のレベルは、「これ、このままで大丈夫ですか」と声を上げられることです。
設計レビューで違和感を覚えたとき。テスト中に仕様と矛盾する動きを見つけたとき。顧客から来た追加要望が、既存の設計と整合しないことに気づいたとき。
これらの場面で「黙って自分の作業を続ける」のか「PMやPLに共有する」のかの違いが、提案力の第一歩です。
一見すると当たり前のことですが、実際のプロジェクトでは「自分の担当範囲ではないから黙っている」「言って波風を立てたくない」「忙しくて他のことに構う余裕がない」という理由で、この一歩が踏み出せないエンジニアが少なくありません。
問題を指摘するだけでも、チームにとっては大きな貢献です。要件定義の段階で見つかる問題と、リリース直前に見つかる問題とでは、対処コストが10倍以上違うことも珍しくありません。早く声を上げる人がいるだけで、プロジェクトの体力は守られます。
レベル2：代替案を出せる
問題を指摘した上で、「こうすればいいのでは」と代替案を添えられるのが次のレベルです。
「この設計だとパフォーマンスに懸念があります」だけではなく、「一覧画面でN+1問題が起きそうなので、関連データを先読みする方式にしてはどうでしょう」と具体的な代案を示す。「このバッチ処理は本番だと数時間かかりそうなので、非同期キューに分けて並列実行する構成を検討しませんか」と具体名で投げかける。
ここで大事なのは、完璧な案を出す必要はないということです。たたき台としての案があるだけで、議論の質がまったく変わります。「問題がありそうです。どうしましょう？」と投げかけるだけだと、受け取った側が一から考えなければなりません。しかし「こういう案がありますが、どうでしょう？」と投げかければ、「その方向でいこう」「いや、ここはこう変えたほうがいい」と具体的な議論が始まります。
完成度50%のアイデアでも、方向性を示してくれるエンジニアは、プロジェクトの意思決定を加速させる存在として評価されます。
レベル3：聞かれる前に動く
最も高いレベルは、誰にも頼まれていないのに、プロジェクトにとって必要なことを自分で見つけて動くことです。
たとえば、テスト工程が近づいているのにテスト環境の構築が手つかずであることに気づき、自分から準備を始める。次のフェーズで使う技術の検証が必要だと判断し、空き時間に検証環境を作って結果をまとめておく。顧客が次回の打ち合わせで聞きそうな質問を予測して、事前に回答を準備しておく。
これらは「指示されていない仕事」です。しかしプロジェクトにとっては確実に価値がある。こうした動きができるエンジニアを、PMやPLは「自分の代わりに考えてくれる人」として信頼し、より大きな裁量を与えるようになります。
いま自分がどのレベルにいるかを意識するだけで、次の一歩は見えてきます。レベル1で止まっているなら、まず会議で一度「気になっている点」を口に出すところから。レベル2にいるなら、次は誰にも頼まれていない動きを一つだけ足してみる。提案力は性格ではなく、習慣として積み上げていけるものです。
提案力は「営業スキル」ではなく「技術の使い方」である
エンジニアの提案力は、営業やコンサルのスキルとは別物です。
営業の提案は「相手に買ってもらう」ことがゴールで、プレゼン力やネゴシエーション力が求められます。一方、エンジニアの提案は**「プロジェクトをより良い方向に動かす」**ことがゴールです。
その提案の根拠になるのは、口のうまさではなく技術的な裏づけです。
「この構成のほうがいい」と言えるのは、過去のプロジェクトで似た構成の失敗を見てきたから。「この機能は不要ではないか」と言えるのは、データの流れと業務の実態をわかっているから。「このスケジュールでは厳しい」と言えるのは、実装の工数を肌感覚で知っているから。
つまり、エンジニアの提案力とは**技術力の「出力方法」**です。頭の中にある知見を、適切なタイミングで、適切な相手に、適切な粒度で伝える力です。AI時代の文脈でも、現場マネージャーが「変わらず求められる」と挙げる5つの力のうち「設計の意図を、自分の言葉で語る力」は、本記事のレベル2〜3と本質的に同じものです。詳しくはAI時代のエンジニアに変わらず求められる5つの力で扱っています。
提案が「出過ぎた真似」にならないために
提案力の話をすると、「でも、余計なことを言って嫌がられたことがある」「出過ぎた真似だと思われないか心配」という反応がよくあります。
実際に、提案の仕方を間違えると逆効果になることはあります。しかし、それは提案そのものが悪いのではなく、伝え方の問題であることがほとんどです。
避けるべきは「それ、違うと思います」「こうすべきです」という断定的な物言いです。特に、自分よりも経験が長いPLやPMの判断に対して、公の場で否定するような形になると、相手の面子を潰してしまいます。
代わりに効果的なのは、疑問の形で投げかけることです。「この部分、こういう懸念があるのですが、検討済みでしょうか？」「別のアプローチとしてこういう案もあると思うのですが、どう思われますか？」
疑問の形であれば、相手は「ああ、それは考慮済みだよ」と返すこともできるし、「いい指摘だね、検討しよう」と受け入れることもできる。どちらに転んでも、関係が悪くなりにくい。
提案は、自分の正しさを主張する行為ではありません。プロジェクトにとっての最善を、チームで一緒に考えるきっかけを作る行為です。その姿勢が伝われば、「出過ぎた真似」と受け取られることはまずありません。
まとめ
エンジニアの提案力とは、営業スキルではなく、技術的な知見をもとに「こうしたほうがいい」と声を上げる力です。問題を指摘できるレベル1、代替案を添えられるレベル2、聞かれる前に動けるレベル3。段階的に身につけていくもので、いきなり高いレベルを目指す必要はありません。
同じ技術力でも「あの人がいるとプロジェクトが前に進む」と言われるエンジニアと、そうでないエンジニアの違いは、ここから生まれます。
スーパーソフトウエアが大切にしている「提案できる力」
スーパーソフトウエアが「任されるエンジニア」に求める力の一つ目は「提案できる力」です。言われたとおりに作るだけでなく、技術的な知見から「こうしたほうがいい」と声を上げられるエンジニアを、私たちは高く評価します。
実際、当社でPL・PMとして活躍しているメンバーを振り返ると、最初から完成された提案ができたわけではありません。新人時代に「これ、大丈夫ですか？」と一言声を上げるレベル1から始まり、現場の経験を通じて代替案や自発的な動きへと、少しずつ習慣を広げてきた人がほとんどです。
それは、顧客に対しても、チームに対しても、社内に対しても同じです。技術力を持ったうえで、その力をプロジェクトの成功のために自ら発揮できる人。そういうエンジニアが、結果的に最も大きな仕事を任されるようになっていきます。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — 公開中の求人一覧
- AI時代のエンジニアに変わらず求められる5つの力 — 現場マネージャーの観察視点で見る5つの力
- これからのPLに求められる「翻訳力」とは — PLが日々向き合う3つの翻訳の解説
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
