入社時期はほぼ同じ。スキルセットも近い。それなのに、半年経った頃には別人みたいな成長差がついている人たちがいる。
17人の会社で、僕はこれを毎月のように見てきた。
最初は「もともと地頭が違うんだろう」と思っていた。でも違った。"伸びる人"には、再現可能な3つの動き方がある。これに気づいてから、採用基準もオンボーディングの設計も全部変わった。
今日はその3つを、できるだけ具体的に書く。
同じスタート地点なのに、なぜ差がつくのか
K.Platinumは設立3期目、社員17名のITコンサル会社だ。8人が高専出身、残りはトヨタ・富士通・Amazonなどの大手出身者や、独学のSESエンジニアからのジョイン組。バックグラウンドはバラバラだけど、入社後にやることは似ている。要件定義から入る案件もあれば、AWSやAzureの開発実装から入る案件もある。最初の3ヶ月は誰でもキャッチアップに苦労する。
問題は、その3ヶ月をどう過ごすかだ。
ある人は、半年後にプロジェクトリーダーを任されている。別の人は、半年後も同じタスクをひとりで抱えてしんどそうにしている。技術力の差ではない。むしろ入社時点では後者の方がスキルが高かったケースもある。
最初は不思議だった。「やる気の差かな」「向き不向きかな」と思っていた時期もある。でも17人を見続けるうちに、ある共通点が浮かび上がってきた。
伸びる人と伸び悩む人の差は、動き方の設計にあった。
ここで言いたいのは、「マインドが大事」みたいな精神論じゃない。具体的な行動パターンの話だ。順番に書いていく。
共通点①：「答え」より先に「問い」を書く人が伸びる
伸びるエンジニアは、Slackやドキュメントを書くときに問いの設計が異常にうまい。
具体例を出す。
たとえば「この実装でいいですか？」と聞いてくる人と、「この実装はAパターンとBパターンを比較した結果Aを選びました。Bを捨てたのは△△の理由ですが、ここに見落としがないか確認したいです」と聞いてくる人がいる。
前者は答え（=自分の実装）を見せて、レビュアーに丸投げしている。後者は問い（=Bを捨てた判断は妥当か）を絞り込んでから渡している。
レビューする側の負担が10倍違う。当然レビューの質も10倍違う。そして、後者は質問を1回するたびに「Bを捨てた理由」「比較軸の作り方」がチームに共有されるから、本人だけでなく組織全体が伸びる。
伸びるエンジニアは、「自分はどこで詰まっているのか」を言語化できる。そして詰まっている地点を、相手が答えやすい形に整形してから投げてくる。これは技術力よりも、問いを設計する筋肉の話だ。
僕が前職のスタートアップITコンサルにいた頃、初めて尊敬したシニアエンジニアもこのタイプだった。当時は気づかなかったけど、彼の質問はいつも「自分の仮説」とセットだった。仮説があるから、答える側は「その仮説の何が正しくて何が違うか」を返せる。会話のスループットが圧倒的に高かった。
入社1年目のメンバーにも、この習慣だけは最初に共有するようにしている。
共通点②：学習を"公開"する（社内Slackは強力なドーピング）
2つ目はもっとシンプルだ。
伸びる人は、自分が学んだことをチャンネルに垂れ流す。
K.Platinumの社内Slackには、#timeline-{個人名}みたいな自分専用の作業ログチャンネルがある。義務ではないけど、伸びている人ほど活用している。
たとえばある高専卒のメンバーは、毎日こんなログを書いている。
AWS Lambdaのコールドスタート、prod環境で1.2秒→0.4秒に短縮できた。
やったこと：①Provisioned Concurrency、②不要なnode_modules削減、③ESM化。
今日の学び：Provisioned Concurrencyは月額固定だから、トラフィック変動を見て判断する必要がある。
これだけ。でもこれが、3ヶ月続くと圧倒的なアセットになる。
第一に、本人の中で知識が構造化される。書くために整理するから、読み返したときに自分の成長曲線が見える。
第二に、他のメンバーが勝手に学ぶ。同じ問題で詰まった人がSlack検索で過去ログを見つけて、同じ轍を踏まなくなる。
第三に、これが一番でかいのだけど、評価する側（つまり僕や営業部長）が、その人の頭の中を観察できる。
「何を考えて、どう判断したか」が見えるエンジニアと、コードの成果物しか見えないエンジニアでは、次に渡す案件のレベルが変わる。前者には「次は要件定義から入ってみる？」と声がかけやすい。これは贔屓ではなく、判断材料があるかどうかの差だ。
逆に、せっかく良い仕事をしているのに表に出さない人は、どうしても評価のされ方が「アウトプット最終形」だけになる。これは本人にとってもったいない。
伸びる人は、これをドーピングのように使う。1日5分の作業ログが、半年後の役割を変える。
💡 K.Platinumでは、この「学習を公開する文化」を仕組み化しています。1on1も案件選択制も、すべてここに繋がっています。興味があればエンジニア募集の詳細を覗いてみてください。
共通点③：自分の中で"顧客"を1人決めている
3つ目は少し抽象的だ。でも、これが一番効く。
伸びる人は、自分の仕事の"顧客"を1人、明確に決めている。
「顧客」と言っても、エンドユーザーのことだけじゃない。プロダクトの直接ユーザーかもしれないし、隣のチームのPMかもしれないし、社内の経理担当かもしれない。要は、自分のアウトプットを最初に受け取って、最初に喜んだり困ったりする1人のことだ。
これを決めている人は、仕事の優先順位がブレない。
「この機能、A案とB案どっちがいいかな」と迷ったときに、「○○さんならどっちを選ぶか」で判断できる。「このドキュメント、どこまで書けばいいかな」と迷ったときに、「○○さんが読んで誤解しないか」で粒度が決まる。
逆に、顧客が決まっていないと、判断が抽象的な"正しさ"に流れる。「ベストプラクティス」「業界標準」「綺麗な設計」を追いかけ始める。これは一見正しそうに見えて、実は誰も喜んでいないことが多い。
K.Platinumで一番伸びている若手のひとりが、入社3ヶ月目のミーティングでこう言ってきた。
「僕の顧客は、案件先のシステム部の田中さん（仮）です。田中さんが朝、Slackを開いた時に『これなら今日中にレビューできるな』と思える粒度で、毎晩PRを送ろうと決めました」
これを聞いた瞬間、僕はこの子は伸びると確信した。実際、彼は半年後にはサブリーダーになっている。
技術力じゃない。"誰のために動くか"を自分で決められたかどうかだ。
才能じゃなくて、設計の問題
3つ並べて気づくと思うけど、これは全部才能じゃなくて設計の話だ。
- ① 問いを設計してから話す
- ② 学習プロセスを公開する
- ③ 顧客を1人決める
どれも、明日からできる。にもかかわらず、やっていない人が圧倒的に多い。
僕が24歳でK.Platinumを起業して、資本金10万円から3期目で2,000万円までやってきて、毎日17人のメンバーを見ていて思うのは、才能の差は思ったより小さいということだ。差がついているのは、ほぼ全部、動き方の設計の話だった。
そしてもうひとつ大事なこと。これは未経験からでも再現できる。
K.Platinumの高専卒メンバー8人のうち、何人かは正直、入社時点では技術書を1冊も読み終わっていなかった。それでも今は、AWSやAzureの上流から入って客先で意思決定をしている。理由はシンプルで、上の3つを最初の3ヶ月で叩き込んだからだ。
逆に言うと、"伸びるエンジニア"のチケットは、誰の手にもある。
僕からのお願い
ここまで読んでくれてありがとうございます。
もしあなたが「次の半年で、市場価値をもう一段上げたい」と思っているエンジニアなら、K.Platinumの採用ページを覗いてみてほしい。
僕たちは、技術力よりも動き方の設計ができる人を採用したいと思っている。だから入社してから、上の3つを徹底的に磨き込む環境を用意している。1on1も、社内Slackの作業ログ文化も、案件選択制も、全部そのためにある。
「自分はまだスキルが足りないかも」と思っている人ほど、話を聞きに来てほしい。スキルは入ってから伸ばせる。動き方の設計は、自分で決めるしかない。
その「自分で決める」を一緒にやれる人を、僕たちは探しています。
📩 エンジニア募集中！詳しい条件を見る → https://jp.indeed.com/job/%E3%82%A2%E3%83%97%E3%83%AA%E9%96%8B%E7%99%BA%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2-d99f92bb1103fd30
沼田海斗（ぬまた・かいと）
株式会社K.Platinum代表。1998年生まれ、沖縄高専卒。トヨタ自動車を経てスタートアップITコンサルでコンサルタント。24歳で独立し、2023年にK.Platinumを設立。設立3期目で社員17名、うち高専出身者8名。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。