■ この記事はこんな人におすすめ
- エンジニアとして働き始めたばかりで、成長の方向性がわからない人
- 「なんとなく仕事はこなせているけど、次のステップが見えない」と感じている人
- 年収アップやキャリアアップを真剣に考えているエンジニア
- 自分のレベルを客観的に把握したい人
■ この記事で得られること
- 自分の現在地（レベル）を6つの能力軸で正確に把握できる
- レベルアップのための具体的なネクストアクションがわかる
- 「明日・来週・1ヶ月」単位で取り組むべき行動を設定できる
1. 結論
エンジニアとしての成長は、「技術力だけ磨けばいい」という話ではありません。
設計力・専門性・推進力・組織貢献・顧客理解・情報発信という6つの能力軸でバランスよく成長することが、結果的に年収と市場価値を高めます。
まず自分のレベルを正直に把握し、次に「どの行動を取るか」を具体的に決めることが大切です。
⚠️ 以下の年収推移はあくまで筆者の独断と偏見によるイメージです。
| ステップ | 達成条件 | 年収目安 |
|---|---|---|
| ① | 技術スキルをL2以上 | 400万円以上 |
| ② | 全能力をL2以上 | 400〜500万円 |
| ③ | 特定分野でL3以上 | 500〜600万円 |
| ④ | 全能力をL3以上 | 650万円以上 |
| ⑤ | 特定分野でL4以上 | 800万円以上 |
上記の詳細な考え方については、下記の記事でまとめています。
👉 エンジニアが年収600・800・1000万円の壁を突破するための6つの能力とキャリア戦略
2. 自分のレベルをチェックしよう
6つの能力軸ごとに、L1〜L3のチェック項目を用意しました。
正直に「できているか」を確認してみてください。
3. レベルアップのためのネクストアクション
チェックの結果を踏まえて、具体的にどんな行動を取ればいいかをまとめました。
■ 設計力・実装力
L1 → L2 にするために
- 担当機能の実装前に、クラス構成・DB設計・API設計を図や文書に起こす習慣をつける
- 設計レビューで「なぜその構成にしたか」を必ず言語化して説明するようにする
- 他メンバーの設計レビューに積極的に参加し、懸念点や代替案を1つ以上コメントする習慣をつける
- 障害・バグ発生時は、応急対応だけで終わらず根本原因と再発防止策をドキュメントに残す
- 仕様変更が発生したとき、影響範囲を自分でリストアップしてチームに共有する練習をする
L2 → L3 にするために
- 半年規模以上のプロジェクトで、アーキテクチャ設計の起案役を自ら買って出る
- 技術選定の場面で、選択肢のトレードオフを表や文書にまとめてチームに提示する習慣をつける
- 既存コードベースを定期的に読み返し、技術的負債の候補リストを作って管理する
- 技術的負債の解消提案をする際、ビジネスリスクや工数削減効果など定量的な根拠を添えるようにする
- 設計判断のログ（なぜその選択をしたか・当時の制約）をADR（Architecture Decision Record）などの形で残す習慣をつける
ADR（Architecture Decision Record） とは、技術的な設計判断を記録するための文書フォーマットです。
「何を決めたか・背景・選択肢・決定理由・結果」を残すことで、後から第三者が判断の経緯を理解できるようになります。
項目 内容 タイトル 何を決めたか（例：「認証方式をJWTに統一する」） 背景 なぜその判断が必要になったか 選択肢 検討した選択肢とそれぞれのトレードオフ 決定 最終的に何を選んだか 理由 なぜその選択をしたか 結果 この決定によって生じる影響・制約
■ 専門性の深さと広さ
L1 → L2 にするために
- 担当領域の技術選定をする際、「なぜこれを選んだか」を必ず言語化してドキュメントに残す習慣をつける
- バグやトラブルが発生したとき、修正して終わりにせず根本原因を調査してチームに共有する
- 隣接領域のコードやインフラ設定を、週1回など定期的に読む時間を意識的に確保する
- 隣接領域のメンバーが参加するレビューや設計議論にオブザーバーとして参加し、使われている言葉や概念を把握する
L2 → L3 にするために
- 担当領域の技術ブログ・公式ドキュメント・カンファレンス資料（例：JSConf・AWS re:Inventなど）を定期的にチェックする習慣をつける
- キャッチアップした技術を、実際に手を動かして検証するスパイクタスクを自分で設定する
- 担当領域について「社内で一番詳しい」と言える範囲を1つ決め、そこを重点的に深掘りする
- 隣接領域のタスクを、担当メンバーに頼りすぎず自分でやりきる経験を意図的に作る
- 担当領域と隣接領域にまたがる問題を自分で切り分けられるよう、両領域の基本的な仕組みを図にまとめてみる
■ 推進力・プロジェクト貢献
L1 → L2 にするために
- タスクの見積もりと実績を毎回記録し、ズレの原因を振り返る習慣をつける
- 複数タスクを抱えているとき、優先順位と着手順をチームに明示してから動くようにする
- タスクの仕様・要件を受け取ったとき、抜け漏れがないか自分でチェックリストを作って確認する
- 自分の作業が他メンバーに影響するタイミングを事前に把握し、1日前には声をかける習慣をつける
L2 → L3 にするために
- プロジェクトの関係者（他チーム・PdM・デザイナーなど）を自分でマッピングし、誰が何を決める権限を持っているか把握する
- プロジェクトが停滞していると感じたとき、原因と次のアクションをセットにして自分からミーティングをセットする
- プロジェクトのリスクを週次で棚卸しする習慣をつけ、早期に関係者へ共有する
- 開発フローの非効率を感じたとき、改善案をドキュメントにまとめてチームに提案する
- 提案した改善を導入後、1ヶ月後に効果を振り返る機会を自分でセットする
■ 組織貢献
L1 → L2 にするために
- チームの目標や方針を確認し、自分の直近タスクがどれに貢献しているかを週次で言語化する習慣をつける
- 得た情報（仕様変更・障害・技術情報など）をSlackやドキュメントに残す際、「誰に関係するか」を意識して共有先を選ぶ
- 困っていそうなメンバーに気づいたとき、声をかけることを習慣化する（週1回以上を目安に）
- 自分の作業手順や気づきを、他のメンバーが再現できる形でドキュメントに残す習慣をつける
L2 → L3 にするために
- チーム内で意見の対立が起きたとき、「どちらが正しいか」ではなく「チームとして最善は何か」という問いを自分から投げかけてみる
- コードレビューやフィードバックで指摘する際、必ず「なぜそうすべきか」の理由をセットで伝えるルールを自分に課す
- 後輩や経験の浅いメンバーへのサポートを、答えをすぐ教えるのではなく「どう考えたか」を引き出す形に変えてみる
- メンバーが良い成果を出したとき、具体的に何が良かったかを本人に伝える習慣をつける
- メンバーの成長を長期視点で考え、「今この人に積ませるべき経験は何か」を意識してタスクの依頼や相談をする
■ 事業・顧客貢献
L1 → L2 にするために
- 担当プロダクトのKPIや事業指標を調べ、自分の担当機能との関係を図や文章で整理してみる
- 顧客からのフィードバックや問い合わせを、開発改善のヒントとして蓄積するメモを作る
- 機能の実装方針を決める際、「顧客にとって使いやすいか」という問いを必ず1回挟む習慣をつける
- リリースした機能の効果を、リリース後1〜2週間後に自分で確認する習慣をつける
L2 → L3 にするために
- 顧客ヒアリングや商談への同席を、自分から上長やPdMに申し出る
- アクセスログ・エラーログ・利用データを週次で確認し、気になる動きがあれば仮説を立てて共有する習慣をつける
- 顧客フィードバックと定量データを組み合わせて、「顧客が本当に困っていること」を自分の言葉でまとめるドキュメントを作る
- 顧客体験の改善アイデアを、月1本以上提案として起票する習慣をつける
- リリースした施策の効果測定結果を、チームへのフィードバックとして定期的に共有する場を設ける
■ 情報発信・プレゼンス
L1 → L2 にするために
- 業務で得た気づきや学びを、Slackの共有チャンネルに週1回以上投稿する習慣をつける
- 調査・検証した内容を、社内WikiやNotionなど（会社のルールに従う）に、他のメンバーが再現できる粒度でまとめる
- 担当領域以外の技術情報にも目を通す時間を週30分確保し、気になったものを共有する
- 社内勉強会に聴衆として参加し、感想や気づきをチームにフィードバックする
L2 → L3 にするために
- 社内LTや勉強会に登壇者として申し込む（まず5分枠・テーマは業務で詰まったことでOK）
- 登壇後に「誰かの役に立ったか」をフィードバックとして集め、次の発信テーマの参考にする
- ベストプラクティスや設計判断の基準を、個人のメモで終わらせずチームのドキュメントに昇格させる
- 社外勉強会・カンファレンスに月1回以上参加し、参加後に学びを社内に共有する
- 社外コミュニティ（connpass・Slack・Discordなど）に参加し、担当領域のトレンドを外部視点でも把握する
まとめ
- エンジニアの成長は技術力だけでなく6つの能力軸で捉えることが重要
- まず自分のレベルを正直にチェックすることで、「できている」「できていない」が明確になる
- 大事なのはチェックした後の行動。抽象的なやる気より具体的なネクストアクションが成長につながる
📝 社内ワークショップを実施してみて
この記事をもとに社内でワークショップを実施しました。その結果と反省を正直に書いておきます。
よかった点： レベルチェックについては、ほとんどのメンバーが最後まで取り組んでくれました。「自分が今どこにいるか」を可視化するという目的は達成できたと思います。
課題： 一方で、ネクストアクションの確認や「明日・来週・1ヶ月でやること」を決めるステップまで取り組んでくれた人は、あまり多くなかったという印象です。
振り返ると、レベルチェックだけでもそれなりのボリュームがあり、そこで集中力や時間が尽きてしまったのだと思います。チェックして「なるほど、自分はここか」で終わってしまうと、成長にはつながりにくい。レベルチェックはあくまで手段であり、ネクストアクションを決めることがゴールなのですが、そこまで完走できる設計としては不十分でした。
次回やるとしたら、チェック範囲を絞る・ネクストアクションを決める時間を明示的にスケジュールに組み込むなど、「行動を決めるところまでセットで完走できる」設計にしたいと思っています。
この記事を読んでくれた方へ： レベルチェックで終わらず、ぜひ「明日やること」を1つだけでも決めてみてください。それが一番大事です。
結局何をすればいいの❓
今すぐ以下の3つを決めてみてください。
- 明日取り組むこと — 例：「設計レビューで一言コメントする」「Slackで学びを共有する」
- 来週に取り組むこと — 例：「バグの根本原因をドキュメントに残す」「隣接領域のコードを読む」
- 1ヶ月で取り組むこと — 例：「LTに登壇申し込みをする」「ADRを1つ書いてみる」
小さく始めて、続けることが一番大切です。
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。