前置き

この記事は何？

自社で評価に使うべく、エンジニアのスキルを体系化してスキルマップを作っていたのですが、作っているうちに、他者の意見を取り入れてエンジニアのスキル業界の共通認識ができたら面白そうだなと思ったのでQiita上で公開してみることにしました。

以下は叩き台と思って下さい。皆さんの意見をお聞きしたいです。

作ったのはどんな人？

大学生時代からプログラミングに携わり、新卒で国内の独立系ITコンサルティング会社に就職。3年勤めて2010年に独立起業し早9年、今は直請けで受託案件をやりつつ自社サービスを作っているような社長兼エンジニアです。

ITコンサル時代は業務系でJavaをガリガリ、独立後はiOS、NodeJSを好んでやっており、要件定義やUXもやります。

スキルマップの前提事項

あくまで（私が考える）エンジニアスキルに絞っています。

• 所謂フロントエンド／バックエンド／アプリエンジニアを想定しています
• ITアーキテクトに分類されるスキルは一部入っています（ドメイン駆動設計に繋がるので）
• 自社サービスを作るプロパーエンジニアか、フリーランスや受託開発会社のエンジニアかというと、後者寄りです（主に上流工程部分が）
• PMスキルは省きました
• DB、インフラスキルは省きました（DBスキルは頑張ればマージできそう）
• 品質的なスキルは入れた方が良い気もしますが抜け落ちています

スキルについて

• 要求分析
• 設計
• コーディング
• テスト
• ドキュメンテーション
• ハマった場合の対処法

を採用してみました。こんな指標もアリでは？というのもコメントもらえると嬉しいです。

エンジニアのスキルマップ

スキル ✕ レベル別エンジニア像 のマトリックスで示しています（以下の画像）。字が小さいので、以下に箇条書きでも書いています。おまけでレベル別に読んだらいい本の議論もできると面白いと思います。

表の元ネタは Googleスプレッドシートで共有 しています。こちらへも直接コメント付けてもらえると嬉しいです。
Lv.の数字は推して知るべしです：）

Lv.なし 駆け出し

• 要求分析
• 設計
• コーディング
  • 構造化パラダイム（≒基礎文法）を使いこなせるようになる
  • （OSの扱い、ライブラリの扱いに慣れていないので）開発環境を整えるまでに苦戦する
• テスト
• ドキュメンテーション
• ハマった場合の対処法
  • エラーメッセージをググるがヒットしたページが自分と同じエラーを指しているか別のものか判断できない

Lv.45〜 独り立ち

• 要求分析
  • 自分が作りたい機能をコード化し始められる
• 設計
• コーディング
  • オブジェクト指向パラダイムを語りだす
  • インタフェースの概念がまだ理解できていない
• テスト
• ドキュメンテーション
• ハマった場合の対処法
  • エラーメッセージをググり、ヒットしたページが自分と同じエラーを指しているか判断できる
  • Stack Overflowで該当の記事を見付けても、✔がないと不安になる

この頃に読むと良い本

- JUnit実践入門

Lv.60〜

• 要求分析
  • 自分が作りたいアプリのMVPくらいの機能を実現できる
• 設計
• コーディング
  • アーキテクチャが決まっていれば、その流儀に沿って設計書の内容をコードにすることが独りでできる
  • インタフェースは自分で作る自信はないが、用意されているものを使って新しいクラスを作ることはできる
• テスト
  • 分岐網羅のテストケースを作れる
• ドキュメンテーション
  • レビューで直される前提なら、一つの詳細設計書を元に、同様の設計書を作ることができる
• ハマった場合の対処法
  • 問題の切り分けができるようになり、解決スピードがあがる

この頃に読むと良い本

- オブジェクト指向における再利用のためのデザインパターン
- プログラミング作法
- 実践テスト駆動開発

Lv.80〜 中堅エンジニア

• 要求分析
  • （Lv.60と同じ）
• 設計
  • 過去のノウハウにあるアーキテクチャを新たなプロジェクトで再現できる
  • MVC論争に口を挟める
  • インタフェースも自分で作成できる
  • クラス図を書くことができる
• コーディング
  • デザインパターンを意識したコーディングができる
  • 知らない言語でもアルゴリズム部分ならアドバイスできる
• テスト
  • 振る舞い駆動テストでテストケースを作れる
  • 異常系のテストケースなどを作れる
• ドキュメンテーション
  • 要件定義フェーズのドキュメントから、画面や機能毎の基本設計書、および詳細設計書を仕上げることができる
• ハマった場合の対処法
  • Qiita／Stack Overflow／ライブラリのコード／GitHub上のISSUE／ユーザーコミュニティでのQAなどを駆使し、ほぼ独りで問題解決できる

この頃に読むと良い本

- CODE COMPLETE 第2版 上／下 完全なプログラミングを目指して
- Web API: The Good Parts

Lv.100〜

• 要求分析
  • 自分が作りたいアプリを自由に実現できる
• 設計
  • MVPやMVVM、Fluxといったアーキテクチャを選別してプロジェクトの雛形を作ることができる
• コーディング
  • 関数型パラダイムを取り入れ始める
  • レビュアーとして活躍できる
• テスト
  • （Lv.80と同じ）
• ドキュメンテーション
  • （Lv.80と同じ）
• ハマった場合の対処法
  • （Lv.80と同じ）

この頃に読むと良い本

- Clean Architecture 達人に学ぶソフトウェアの構造と設計

Lv.120〜 テックリード

• 要求分析
  • （Lv.100と同じ）
• 設計
  • クリーンアーキテクチャのレイヤを意識しながら軽量DDDができる
• コーディング
  • 関数型マスター
  • 利用しているOSSライブラリなどにPullReqを送ったり普通にする
• テスト
  • （Lv.80と同じ）
• ドキュメンテーション
  • 設計ノウハウなどをまとめて、イベントでの登壇なども行う
• ハマった場合の対処法
  • （Lv.80と同じ）

この頃に読むと良い本

- ユースケース実践ガイド

Lv.150〜

• 要求分析
  • 要求一覧からユースケースシナリオを書き出すことができる
  • ロバストネス分析ができる
  • 機能一覧／画面一覧を作成できる
• 設計
  • （Lv.120と同じ）
• コーディング
  • （Lv.120と同じ）
• テスト
  • ユースケースシナリオから振る舞い駆動のテストケースを作成できる
• ドキュメンテーション
  • （Lv.120と同じ）
• ハマった場合の対処法
  • （Lv.80と同じ）

この頃に読むと良い本

- エリック・エヴァンスのドメイン駆動設計
- 実践ドメイン駆動設計

Lv.200〜

• 要求分析
  • ドメインモデルを作ってクライアントと会話ができる
  • ユースケースシナリオ／ロバストネス分析から要求の抜け漏れを洗い出すことができる
• 設計
  • ドメインモデルからクリーンアーキテクチャのレイヤを意識した独自アーキテクチャを導き出せる
• コーディング
  • （Lv.120と同じ）
• テスト
  • （Lv.150と同じ）
• ドキュメンテーション
  • （Lv.120と同じ）
• ハマった場合の対処法
  • （Lv.80と同じ）

あとがき

自分で書きつつ、テックリードとLv.150の関係が微妙です（テックリードは主に自社サービスのプロパーエンジニア向けの称号で、Lv.150〜はITアーキテクトとしてのスキルだからだと思います）。

議論を巻き起こしたいのでどしどしコメント頂けると喜びます。

参考