ポジション別エンジニアに必要なスキルまとめ--経験年数ではなく、「何を任せられるか」で考えるIT人材のスキル地図

ITエンジニアに必要なスキルとは何だろうか。

• 設計力

• テスト力

• コミュニケーション力

• マネジメント力

• ドキュメント作成力

• 調整力

• 品質意識

• ビジネス理解

こうして並べると、いくらでも出てくる。

ただ、ここで難しいのは、IT業界では必ずしも

にならないことだ。

3年目でもチームを前に進められる人はいる。
10年目でも限定された作業しか任せづらい人もいる。
15年目でも現場の実装者として非常に強い人もいる。
逆に、役職名は立派でも、実際には判断も調整も品質管理もできていない人もいる。

つまり、エンジニアのポジションは、単純な年数では測れない。

本当に見るべきなのは、

• どの成果物に責任を持てるか

• どの範囲を自律的に判断できるか

• どの程度、他者やチームの成果に影響を与えられるか

• どのレベルの曖昧さやリスクを扱えるか

ではないかと思う。

この記事では、ポジション別にエンジニアに必要なスキルを整理しつつ、あわせて「そのスキルをどう育てるか」「どう測るか」「どれくらいの期間・コストがかかるのか」についても考えてみる。

なお、本記事は私個人の経験だけではなく、以下のような公的・準公的なスキル標準も参考にしている。

• IPA「iコンピテンシ ディクショナリ（iCD）」

• IPA・経済産業省「デジタルスキル標準（DSS）」

• IPA「ITスキル標準（ITSS）」

• SFIA Foundation「SFIA」

• IEEE Computer Society「SWEBOK」

• NIST「NICE Framework」

• PMI「PMI Talent Triangle」

• ISO 10015:2019

• Kirkpatrick Model

もちろん、これらを完全に網羅・厳密適用するものではない。
あくまで、現場感のあるキャリア整理として使いやすい形に再構成したものである。

1. 経験年数ではなく、責任範囲で見る

まず前提として、エンジニアのスキルは年数だけでは測れない。

経験年数は、あくまで「経験する機会があった期間」にすぎない。
その期間に何を任され、何を考え、何を改善し、どのような責任を持ってきたかは、人によってまったく違う。

たとえば同じ5年目でも、

• 詳細設計から実装・単体テストまで一人で回してきた人

• テスト設計と品質分析を中心に経験してきた人

• 小規模チームのリーダーを任されてきた人

• 指示された作業だけをこなしてきた人

では、身についているスキルは大きく異なる。

ここで参考になるのが、SFIAの考え方である。

SFIAでは、デジタル・ICT領域のスキルを、単なる知識や経験年数ではなく、責任レベルとして整理している。そこでは、自律性、影響範囲、複雑性、ビジネススキル、知識といった観点が重視されている。

この考え方は、かなり現場感がある。

エンジニアのポジションを考えるときも、

だけではなく、

で見るほうが実態に近い。

2. エンジニアに必要なスキルは3階層で考える

エンジニアに必要なスキルは、大きく3階層に分けられる。

ここで重要なのは、上位ポジションになるほど技術が不要になるわけではない、ということだ。

むしろ逆である。

上位ポジションでは、自分でコードを書く時間は減るかもしれない。
しかし、技術理解がないまま判断するリスクは大きくなる。

技術がわからないPMは、リスク判断を誤る。
設計がわからないPMOは、品質指標を形だけで扱う。
実装や運用がわからないPdMは、現場制約を無視した優先順位をつける。
非機能がわからないアーキテクトは、未来の保守担当者から呪われる。

つまり、ポジションが上がるほど必要なのは、

ではなく、

だと思う。

3. 全ビジネスパーソンに必要なスキル

まず、エンジニア以前に、ビジネスパーソンとして必要なスキルがある。

3-1.文章力

エンジニアの仕事は、意外なほど文章に依存している。

• 仕様を書く

• 設計を書く

• 調査結果を書く

• 障害報告を書く

• 課題票を書く

• レビュー指摘を書く

• 会議メモを書く

• 顧客向け報告を書く

このすべてに文章力が関わる。

ここで必要なのは、文学的な美文ではない。
必要なのは、

である。

文章が曖昧だと、解釈が分かれる。
解釈が分かれると、実装がズレる。
実装がズレると、テストで燃える。
テストで燃えると、だいたい誰かの目が死ぬ。

3-2.論理的思考力

実務で必要な論理的思考力とは、難しいフレームワーク名を暗記することではない。

• 事実と解釈を分ける

• 原因と結果を分ける

• 問題と対策を分ける

• 優先順位をつける

• 判断基準を明確にする

• 抜け漏れを確認する

こうした地味な能力である。

これが弱いと、会議が「お気持ち発表会」になる。
気持ちは大事だが、気持ちだけではバグは減らない。

3-3.報連相・エスカレーション力

報連相は新人だけのスキルではない。
リーダーやPMになっても、むしろ重要度は増す。

特に大事なのは、悪い情報を早く出すことだ。

悪い報告の例はこうだ。

良い報告はこうだ。

違いは明確である。

良い報告は、相手が判断できる。
悪い報告は、相手を不安にさせるだけである。

3-4.段取り力

仕事は気合いでは終わらない。

• 何をやるか

• いつまでにやるか

• どの順番でやるか

• どの品質で出すか

• 誰に確認するか

• どのリスクを先に潰すか

これを考える力が段取り力である。

実装力が高くても、段取りが弱いと「強いけど任せづらい人」になる。
逆に、段取りが強い人は、周囲から見て安心して任せやすい。

3-5.調整力

調整力という言葉はふわっとしている。
しかし、実務ではかなり具体的な能力である。

• 関係者を特定する

• 期待値を合わせる

• 認識齟齬を潰す

• 優先順位をすり合わせる

• 反対意見を処理する

• 合意内容を記録する

• 決定事項を次の行動に落とす

これができる人は強い。

エンジニアリングは技術の仕事である。
しかし同時に、かなりの割合で「認識合わせの仕事」でもある。

4. エンジニア共通で必要なスキル

次に、エンジニアとして共通して必要になるスキルを整理する。

4-1.IT基礎

全員がすべての領域に詳しい必要はない。
しかし、会話についていけるだけの地図は必要である。

• OS

• ネットワーク

• データベース

• Web

• API

• 認証・認可

• セキュリティ

• クラウド

• ログ

• バッチ

• 外部連携

• 運用監視

このあたりの基礎がないと、設計・レビュー・障害対応・リスク判断で詰まりやすい。

4-2.設計理解

設計理解とは、単に設計書を読めることではない。

• 要件が設計に落ちているか

• 処理フローが自然か

• データの流れが説明できるか

• 例外処理が考慮されているか

• 外部連携の前提が明確か

• 非機能要件が抜けていないか

• 後続工程でテスト可能か

• 運用時に困らないか

こうした観点で見られることが重要である。

設計は、作るためだけの資料ではない。
テスト、保守、運用、障害対応のための資料でもある。

4-3.品質意識

品質意識とは、「バグを出さないように頑張る」ことではない。

それは祈りである。
祈りも悪くはないが、品質保証としては弱い。

品質意識とは、

• 欠陥が入りやすい場所を予測する

• レビュー観点を持つ

• テスト観点を設計する

• 仕様の曖昧さを検知する

• リスクに応じて確認密度を変える

• 重要機能と軽微機能を区別する

• 後工程の手戻りコストを考える

といった能力である。

品質は、根性ではなく、構造・観点・基準・仕組みで作るものだと思う。

4-4.レビュー力

レビュー力は、誤字脱字を見つける力ではない。
もちろん誤字脱字も直したほうがよいが、それだけでは弱い。

レビューでは、以下のような観点が必要になる。

• 要件との整合性

• 処理の網羅性

• 例外・異常系

• データ条件

• 画面/API/DB間の整合性

• セキュリティ

• 性能

• 運用影響

• テスト可能性

• 保守性

良いレビューとは、単に指摘が多いレビューではない。

である。

5. ポジション別に必要なスキル

ここからは、ポジション別に必要なスキルを整理する。

なお、ここでいうポジションは、会社ごとの正式な職位ではなく、実務上の役割として扱う。

5-1. PG / 実装担当

PGの主な役割は、設計やチケットをもとに、正しく実装し、単体レベルの品質を担保することである。

必要なスキルは以下である。

PGで重要なのは、

である。

良いPGは、言われた通りに作るだけではない。

• この仕様だと例外時に落ちる

• この条件が未定義

• このデータパターンが考慮漏れ

• この設計だとテストしづらい

こうした違和感を出せる。

つまり、良いPGは小さな設計者でもある。

5-2. SE / 設計担当

SEの主な役割は、要件を実装可能な設計に落とし込むことである。

SEで重要なのは、

である。

要件がふわっとしていても、設計では逃げられない。

• どの画面で

• どの項目を

• どの条件で

• どのDBに保存し

• どのAPIと連携し

• エラー時にどう振る舞うか

まで決める必要がある。

SEは、業務と技術の翻訳者である。

ここが弱いと、PGは迷い、QAは困り、PMは燃える。
非常に美しい連鎖爆発である。美しくはない。

5-3. QA / テスト設計担当

QAの主な役割は、仕様・設計をもとに品質リスクを見つけ、テスト観点やテストケースを設計することである。

QAは、テストケースを書く人ではない。

本質的には、

であり、

である。

良いQAは、仕様の矛盾、設計の穴、条件分岐の漏れ、外部連携リスク、データパターン不足、運用時の事故ポイントを見つける。

QAは後工程の人ではなく、本来は上流品質を支える人だと思う。

5-4. TL / チームリーダー

TLの主な役割は、数名程度のメンバーを見ながら、作業進捗・品質・課題を管理することである。

TLで重要なのは、

である。

ここでプレイヤー癖が抜けないと、全部自分で抱えることになる。

その結果、

• 自分だけ忙しい

• メンバーが育たない

• 状況が見えない

• 属人化する

• 休むと止まる

という、なかなか味わい深い地獄が完成する。

リーダーに必要なのは、作業能力だけではない。
観察力、早期介入力、任せる力も必要である。

5-5. PL / プロジェクトリーダー

PLの主な役割は、チーム単位ではなく、工程・成果物・関係者を横断してプロジェクトを前に進めることである。

PLは、現場の実行責任者である。

求められるのは、

だと思う。

単に進捗率を見るだけでは足りない。

• 成果物の品質は足りているか

• 未決事項はどこか

• レビューは機能しているか

• 課題が放置されていないか

• 仕様変更の影響は見えているか

• メンバーの負荷は偏っていないか

• 顧客との認識は合っているか

こうしたことを見続ける必要がある。

PLは、現場のレーダーであり、交通整理役でもある。

5-6. PM / プロジェクトマネージャー

PMの主な役割は、プロジェクト全体の目的達成に責任を持つことである。

PMは、管理表を更新する人ではない。

本質は、

である。

PMは常にトレードオフを扱う。

• 品質を上げるとコストが増える

• 納期を守るとスコープ調整が必要になる

• 人を増やすとコミュニケーションコストが増える

• 顧客要望を受けすぎるとチームが死ぬ

• チームを守りすぎると顧客価値が下がる

この矛盾を処理するのがPMである。

PMに必要なのは、単なる優しさでも強引さでもない。

である。

5-7. PMO

PMOの主な役割は、プロジェクト運営を可視化・標準化・改善し、PMや現場が適切に判断できる状態を作ることである。

PMOは、議事録係でも管理表更新係でもない。

本質は、

である。

• 情報が散らばっている

• 課題が見えない

• リスクが曖昧

• 会議で決まらない

• 報告が意味をなしていない

• 品質が感覚で語られている

• プロセスが属人化している

こういう状態を整える役割である。

PMOが強いと、プロジェクトはかなり安定する。
逆にPMOが弱いと、管理資料だけ増えて現場が疲弊する。

Excel神社を建立し、毎週進捗表をお供えするだけでは、プロジェクトは救われない。

5-8. アーキテクト

アーキテクトの主な役割は、システム全体の技術方針・構造・非機能・拡張性を設計することである。

アーキテクトは、単に技術に詳しい人ではない。

重要なのは、

である。

技術選定も、流行で選ぶのではなく、

• 要件に合っているか

• チームが扱えるか

• 運用できるか

• 将来拡張できるか

• 障害時に切り分けできるか

• セキュリティ上問題ないか

• コストは妥当か

を見て判断する必要がある。

アーキテクトは、未来の保守担当者に刺されない設計をする人である。

5-9. EM / エンジニアリングマネージャー

EMの主な役割は、エンジニア組織やチームの成長、採用、評価、育成、働きやすさ、技術文化を支えることである。

EMはPMとは違う。

PMはプロジェクト成功に責任を持つ。
EMはエンジニア組織の健全性に責任を持つ。

• 人が育っているか

• チームが疲弊していないか

• 技術負債を放置していないか

• 評価が納得できるものか

• 採用要件が現実的か

• チームの学習が進んでいるか

• 属人化が解消されているか

こうしたことを見る。

EMに必要なのは、人に優しいことだけではない。
組織をよくするための厳しさも必要である。

5-10. PdM / プロダクトマネージャー

PdMの主な役割は、プロダクトの価値、ユーザー課題、事業性、優先順位に責任を持つことである。

PdMは、要望を集める人ではない。

本質は、

である。

要望は無限に出る。
しかし、リソースは有限である。

だから、

• 誰の課題か

• どれだけ重要か

• 事業価値はあるか

• 技術的に現実的か

• 今やるべきか

• やらない場合の影響は何か

を見て優先順位を決める必要がある。

PdMは、価値と実現性の橋渡しをする役割である。

6. スキルはどう育てるのか

スキルは、すべて研修で育つわけではない。

知識は研修や書籍で得られる。
しかし、判断力、調整力、レビュー力、マネジメント力は、実務経験や振り返りを通じて育つ部分が大きい。

ここで重要なのは、育成を「本人任せ」にしないことだ。

ISO 10015:2019では、組織が力量管理と人材開発の仕組みを確立し、実施し、維持し、改善するための指針が示されている。

つまり、人材育成は気合いではなく、仕組みとして設計するべきものだといえる。

7. スキルはどう測るのか

スキル評価で難しいのは、ふわっとした言葉が多いことである。

たとえば、

• コミュニケーション力

• リーダーシップ

• 主体性

• 調整力

• 品質意識

これらをそのまま5段階評価すると、だいたい雰囲気になる。

「彼は主体性がある」
「彼女はコミュニケーション力が高い」
「なんとなくリーダー向き」

これでは評価として弱い。

スキルは、できるだけ観察可能な行動と成果物に分解する必要がある。

ただし、KPIは万能ではない。
数値化できるものだけを見ると、数値化しやすい行動だけが増える危険がある。

そのため、スキル評価では、

• 定量指標

• 成果物レビュー

• 上司・同僚・関係者からのフィードバック

• ケーススタディ評価

• 実案件での行動観察

を組み合わせるのが現実的だと思う。

研修効果測定では、Kirkpatrick Modelの考え方も参考になる。
これは、研修や育成施策の効果を、反応、学習、行動、成果の4段階で見る考え方である。

つまり、

だけでは不十分で、

まで見る必要がある。

8. 育成にかかる期間・コストの目安

スキル育成にかかる期間やコストは、正直かなり個人差が大きい。

前提知識、案件環境、上司やレビュー担当者の質、本人の学習量、担当できる仕事の幅によって大きく変わる。

そのため、公式に一律の期間を断定することはできない。

ただし、実務上の目安としては、以下のように考えられる。

これはあくまで目安であり、絶対値ではない。

特にPL、PM、PMO、アーキテクト、EM、PdMのような役割は、座学だけでは育ちにくい。
実案件で、ある程度の責任と裁量を持つ経験が必要になる。

スキルは、知識として知っているだけでは不十分である。
使える場面に置かれて、判断し、失敗し、振り返り、改善して、ようやく身についていく。

9. 筆者自身の経歴を当てはめると

ここまで一般論として整理してきたが、

というツッコミもあると思う。

そのため、参考までに、筆者自身の経験をこのフレームに当てはめてみる。

あくまで自己評価であり、第三者評価や公式認定ではない。
また、所属企業や顧客案件を代表するものでもない。

筆者自身は、実装専門職というよりも、技術理解を土台に、品質改善・上流レビュー・PMO支援・チームリード領域に強みが寄っている。

過去には開発経験もあるが、現在の主戦場はコードを書くことそのものではなく、要件・設計・テスト工程のつながりを確認し、曖昧さや欠落を検知し、品質改善の仕組みに落とし込む領域である。

一方で、アーキテクトやPdMのように、技術方式やプロダクト価値の最終責任を担う役割については、理解・支援はできても、自身の主戦場とは言い切れない。

その意味で、自分の現在地を一言で表すなら、

に近いと考えている。

10. まとめ：ポジションとは、年数ではなく「任せられる責任」である

エンジニアのキャリアは、経験年数だけで直線的に上がるものではない。

重要なのは、

• 何を作れるか

• 何を設計できるか

• 何をレビューできるか

• どの品質リスクを見抜けるか

• どの範囲を自律的に判断できるか

• 誰を支援できるか

• どの成果に責任を持てるか

である。

ポジションが上がるほど、求められるスキルは変わっていく。

技術だけでも足りない。
ビジネススキルだけでも足りない。
マネジメントだけでも足りない。

必要なのは、ポジションに応じて、技術・品質・人・事業・仕組みをつなげていくことだと思う。

経験年数は、たしかに一つの参考情報である。
しかし、それだけでは人材の実力は測れない。

だからこそ、エンジニアのスキルは、

ではなく、

で見ていきたい。

そのほうが、本人にとっても、組織にとっても、ずっと健全だと思う。

参考資料

• IPA「iコンピテンシ ディクショナリ（iCD）」

• IPA・経済産業省「デジタルスキル標準（DSS）」

• IPA「ITスキル標準（ITSS）」

• SFIA Foundation「SFIA」

• IEEE Computer Society「Guide to the Software Engineering Body of Knowledge（SWEBOK Guide）」

• PMI「PMI Talent Triangle」

• ISO 10015:2019「Quality management — Guidelines for competence management and people development」

• Kirkpatrick Partners「The Kirkpatrick Model」

併せて読んでほしい関連記事：

・【2026年最新】PMI-PMOCP合格への最短ルート：日本語資料がないなら「最強の用語集」を自作するしかなかった話

・【2026年5月時点ので作ったよ】「日本語資料がない」なら自分で作ればいい。PMI-CPMAI対策、用語集DIYでいくことにした。

・資格取得の旅に出よう――知識の地図を増やすということ