title | tags | author | slide | published_at |
---|---|---|---|---|
ソフトウェアエンジニアのレベル毎の役割 |
キャリア ポエム |
wawoon |
false |
2022-04-03 |
この文章はソフトウェアエンジニアのレベル毎の役割の違いを文章に起こしたもの。これらはあくまで behavioral な特徴であって、それを満たしていればそのランクだという訳ではないのだけれど、大体こんな感じの役割をしているのではないかと思う。
注意
- これは現職の評価基準とは全く関係がなく、個人的な観測と推測に基づいたレベル感
- あくまで行動レベルの特徴なのでこれができればシニアエンジニアだ、というわけにはならない。
- ここで書かれていることの他に別途で技術スキルが必要。
- 実務レベルに達していない状態
- プログラミング言語の文法や便利な API を覚えて一通りサンプルを実行することができる
- コードの品質はかなり低いが簡単なソフトウェアを自分で作れる
- 単機能のチケットを自分で処理することができる
- 他のエンジニアのレビューや手助けを受けながら一通り作業することができる
- プロダクトの一部のコンポーネントを知っている
- 実装に数日程度かかるチケットを自分で処理することができる
- 他のエンジニアからのレビューを通じてのインプットは不要
- 必要な時に他のエンジニアに手助けを求めることができる
- プロダクト全体は理解していないが、これまで業務で関わった複数のコンポーネントをよく知っている
- 実装に 2 週間程度かかるような比較的大きめの機能の実装を主担当することができる
- ソフトウェアのデザインを行いつつ他のエンジニアからのレビューを受けて自発的に軌道修正することができる
- プロダクト全体のコンポーネントを知っている
- 実装に1ヶ月程度かかるような更に大きな機能の実装を主担当することができる
- 標準的な難易度のソフトウェアのデザインを進めることができる
- ソフトウェアエンジニアでの一般的なプラクティスをすべて実践できている
- プロダクト全体のコンポーネントの歴史的経緯や背後のライブラリまで理解している
- 新しい技術動向やプラクティスについて日頃からキャッチアップしている
- 実装に 1-3 ヶ月程度かかるような大きめの機能を実装できる
- やや複雑なソフトウェアのデザインを進めることができる
- 少人数での開発のリードを行うことができる
- プロダクト全体のコンポーネントの歴史的な経緯を踏まえてどのように改善するべきか適切に判断することができる
- 新しい技術動向やプラクティスについて日頃からキャッチアップし業務に応用できる
- 複雑性が高いシステムのデザインを行うことができる
- 実装に 3 ヶ月以上かかる複雑な開発プロジェクトを実施できる
- プロダクトの部分的な技術的なロードマップを策定できる
- チームの潜在的なボトルネックを解消することが出来る
- チームに必要なプロセスの改善・プラクティスの導入を行える
- 他のチームのコンポーネントについて知っている
- チームの代表として他のチームと対話することができる
- 難易度が高いシステムのデザインを行える
- 複数のステークホルダーが関与し実装に 3 ヶ月以上かかる複雑な開発プロジェクトを実施できる
- プロダクトの技術的なあるべき姿を定義してロードマップを作成することができる
- チームの潜在的なボトルネックをプロアクティブに解消することが出来る
- チームの開発プロセスを向上させるための施策を常に検討し、実施している
- クロスチームの問題についてもプロアクティブに問題設定して解決できる
このあたりから想像が含まれています。スタッフエンジニアの更にその上もあると思うけれど、イメージがつかないのでスキップ。
- 難易度がとても高い開発プロジェクトをリードし成功させることができる
- 難易度がとても高いシステムデザインを行うことが出来る
- 複数プロダクト・組織のあるべき姿を定義してロードマップを作成することができる
- 複数の開発チームのボトルネックを適切に解消し、効率的な開発プロセスを導入できる
- 複数チームにまたがる複雑なアーキテクチャ上の問題をプロアクティブに問題設定して解決できる
Seniority が上がっていくと、その人が把握している空間的・時間的な視野が広くなっていくように感じたので意識して書いた。 空間的というのは、コードを自プロダクトのごく一部から理解し始めて、自プロダクト全体を把握し、次に他チームのコードベースについても把握していくということ。同様に使用されているライブラリや標準などの規格についても詳しくなる。
時間的という点については、文字通り徐々に時間が長くなるのはもちろんなのだけど率いるものの単位が変わっていく、ということを意識した(機能開発 → プロダクトのロードマップ → 組織全体のロードマップ)。