Slide 1
Slide 1 text
サラリーマンソフトウェアエンジニアのキャリア
Yuhei Nakasaka
1
Slide 2
Slide 2 text
前提
2
Slide 3
Slide 3 text
対象
この文章は サラリーマンソフトウェアエンジニア(以下、エンジニア) を対象としてい
る。あえてサラリーマンと書いているのは以降で述べているキャリアや技術力といっ
たものが全てのソフトウェアエンジニアに必ずしも当てはまるとは限らないためであ
る。なお今回はサラリーマンの中でも特に中規模以上の企業で働く人を想定してい
る。
3
Slide 4
Slide 4 text
背景
エンジニアのキャリアを考える際は言語・フレームワークやフロントエンド・バック
エンドといった具体的な技術領域によって語られがちである。しかしサラリーマンと
して働くエンジニアのキャリアを考える上ではそうした観点だと安易に履歴書駆動開
発で行動し、ジョブホッピングを重ねることこそが最適解という考えに陥ってしま
う。
今回は、そうした技術領域から語るのではなくサラリーマンのキャリア構造を踏まえ
た上で、
「判断と責任」 という観点からエンジニアのキャリアについて自分なりに整理
してみたい。
4
Slide 5
Slide 5 text
サラリーマンのキャリア
5
Slide 6
Slide 6 text
キャリアの基本構造
サラリーマンのキャリアは、以下の循環によって形成される。
仕事が与えられる → 取り組む → 実績を上げる → 実績に基づいて信用が貯まる → 信用
に基づいて、より重要な仕事が与えられる → 取り組む → …
6
Slide 7
Slide 7 text
この循環は職種を問わず成り立つ。
個々の仕事は、誰かの 「期待」 から生まれる
実績 は、 期待に対する回答 である
信用 とは、 「次も任せてもよい」という判断材料の蓄積 である
7
Slide 8
Slide 8 text
管理職も例外ではない
一見すると管理者は「仕事を与えられる側ではない」ように見えるが、管理者にも上
司や組織があり、
組織運営
人のマネジメント
成果責任
という管理の仕事が期待として与えられている。
8
Slide 9
Slide 9 text
サラリーマンのキャリアとは、
期待 → 実績 → 信用 → 次の期待 の連鎖である。
9
Slide 10
Slide 10 text
エンジニアのキャリア
10
Slide 11
Slide 11 text
エンジニアのキャリアも基本構造は同じ。
エンジニアに対する期待 は、次のような具体的な仕事の形を取る。
仕様や要望を技術的に実現可能な形に落とすこと
複数の実装・設計案を比較し、妥当な選択をすること
技術的な制約やリスクを事前に説明すること
変更や拡張が入ることを前提に構造を考えること
将来の障害や運用コストを見越した判断をすること
11
Slide 12
Slide 12 text
これらはすべて、
「どう作るか」
「どこまで作るか」
「今やらないことは何か」
といった判断を伴う仕事である。
12
Slide 13
Slide 13 text
したがってエンジニアのキャリアとは、
ただ コードを書く量が増えることではなく、任される技術的判断の数と重さが増えて
いく過程
と捉えることができる。
13
Slide 14
Slide 14 text
エンジニアに必要な能力
14
Slide 15
Slide 15 text
大前提として、 高度な判断は深い技術理解がなければ成立しない。よってコンピュー
タサイエンスやソフトウェア工学、その他技術的な知識やスキルは必須である。
その上で、以下ではどのレベルの判断と責任を引き受けられるかという観点で、エン
ジニアに必要な能力を整理している。
15
Slide 16
Slide 16 text
理解力（Why を定義する力）
定義
技術・事業・人の文脈を理解し、
「なぜそれをやるのか」を判断の前提として扱え
る力
この力が不足すると起きる問題
要件通り作ったのに「違う」と言われる
背景変更に気づけず、手戻りが発生する
技術的には正しいが、事業的価値が低い判断をする
16
Slide 17
Slide 17 text
課題分析力（What を定義する力）
定義
現状（As-Is） を把握し、あるべき理想（To-Be） を描いたうえで、そのギャップ
として解くべき課題を定義する力
この力が不足すると起きる問題
表面的な要望をそのまま実装してしまう
局所最適の改善を繰り返し、全体が悪化する
「頑張っているのに評価されない」状態になる
17
Slide 18
Slide 18 text
技術力（How を決め、責任を持つ力）
定義
課題を解決するために必要なエンジニアリング手段を理解・選択・組み合わせ、
その選択がもたらす影響（品質・保守性・運用・将来コスト）に責任を持つ力
この力が不足すると起きる問題
トレードオフを理解せずに選択する
「流行っているから」
「慣れているから」で技術を選ぶ
将来の変更・運用コストを見誤る
障害やパフォーマンス問題の真因に辿り着けない
18
Slide 19
Slide 19 text
実行力（決めたことを完遂する力）
定義
不確実性や制約を織り込んだうえで、やると決めたことをやり切り成果を出す力
この力が不足すると起きる問題
期限が守れない
信用が積み上がらない
「能力はありそうだが任せにくい」と判断される
19
Slide 20
Slide 20 text
リーダーシップ（影響を与える力）
定義
チーム・プロジェクト・人の判断や行動に影響を与え、全体を前に進める力
この力が不足すると起きる問題
問題が分かっていても誰も動かない
議論が停滞する
個人の範疇を越えられず、シニア以降で期待値を超えられない
20
Slide 21
Slide 21 text
職位別に期待される責務と判断
21
Slide 22
Slide 22 text
各職位においてどの範囲の技術的判断を任され、その結果に責任を持つのかを明確に
する。単なるスキルの有無ではなく、判断の粒度・影響範囲・失敗時のコストに着
目。
22
Slide 23
Slide 23 text
ジュニアエンジニア
任される判断の範囲
既存の設計・方針の中での実装判断
明確にスコープが切られたタスク単位の判断
技術力の使い方
既存コード・設計の意図を理解し、それを壊さずに変更する
言語・フレームワークの基本機能を正しく使う
変更がどこに影響するかを意識する
23
Slide 24
Slide 24 text
責務として期待されること
「決められていることを正しく守る」ことに責任を持つ
分からないこと・判断できないことを早めに共有する
自分の実装がチーム全体に与える影響を過小評価しない
失敗時の影響範囲
局所的（修正可能・学習コストとして許容される）
24
Slide 25
Slide 25 text
ミドルエンジニア
任される判断の範囲
機能・モジュール単位での設計判断
複数の実装・設計案の比較と選択
技術的制約を踏まえた実現方法の決定
技術力の使い方
責務分離・依存関係を意識した設計
テスト容易性・可読性・将来の変更を見据えた構造の選択と実装
パフォーマンスや運用への影響を意識した判断
25
Slide 26
Slide 26 text
責務として期待されること
局所最適ではなく、チーム視点で妥当な判断をすること
なぜその設計・実装を選んだのかを説明できること
技術的負債を生み出す判断を自覚的に行うこと
失敗時の影響範囲
チーム内（一定期間の手戻り・保守コスト）
26
Slide 27
Slide 27 text
シニアエンジニア
任される判断の範囲
チーム全体に影響する設計・技術選定の判断
構造・方針レベルでの意思決定
短期成果と長期健全性のトレードオフ判断
技術力の使い方
システム設計・アーキテクチャに責任を持つ
技術選定において、将来の変更・運用・スケールを考慮する
技術的負債・障害・性能問題といった長期にわたる課題を管理対象として扱う
27
Slide 28
Slide 28 text
責務として期待されること
技術的判断の結果に、長期的に責任を持つこと
チームの技術判断の質を引き上げること
判断の背景・トレードオフを言語化し、共有すること
自分がいなくても妥当な判断が行われる構造を作ること
失敗時の影響範囲
プロジェクト・プロダクト全体（回復コストが高い）
28
Slide 29
Slide 29 text
シニアエンジニアの先のキャリア
※
企業ごとに実際の役割は混在しているので、役職名とその実情に一貫性はそれほどないことが
多い。あくまで参考までに。
29
Slide 30
Slide 30 text
シニアエンジニア以降のキャリアは、
「より難しい技術を扱う」 というより、 「より
広く・重い判断に責任を持つ」 方向に分岐する。
キャリア選択という観点で重要なのは、どの判断に責任を持ちたいかである。
30
Slide 31
Slide 31 text
マネジメントラダー（EM / 部長等）
本質的な責務
人と組織を通じて成果を出すこと
技術ではなく「意思決定の場」を設計すること
判断の対象
誰をどこにアサインするか
どのチーム構成が最も成果を出せるか
評価・育成・制度をどう設計するか
「技術判断をしない」 ではなく 「技術判断を誰に任せるか」 に責任を持つ
31
Slide 32
Slide 32 text
ICラダー（スタッフ / プリンシパル等）
本質的な責務
技術的判断によって組織全体の成功確率を高めること
判断の対象
技術的方針・標準
共通基盤やアーキテクチャの方向性
チームをまたぐ設計の整合性
「一段上のシニア」 ではなく 「組織単位で判断を引き受けるIC」
32
Slide 33
Slide 33 text
※
テックリードについて
テックリードは職位ではなくロール
大抵はチームレベルの技術判断に責任を持つ役割
シニア / スタッフ / EM が担うこともある
33
Slide 34
Slide 34 text
必要な能力を手に入れるためには
34
Slide 35
Slide 35 text
基本方針
ここで挙げた能力は机上で身につけるものではなく 、 判断と責任を引き受ける過程 で
獲得される。
35
Slide 36
Slide 36 text
判断の理由を言語化する
なぜその案を選んだのか
なぜ他の案を選ばなかったのか
その判断のリスクは何か
→ 言語化できない判断（なんとなくの判断）は、引き受けていない判断と同じ
36
Slide 37
Slide 37 text
判断の結果を引き取る
障害・手戻り・負債から逃げない
「想定外」で終わらせない
次の判断に反映する
→ 運用や失敗こそが技術力を鍛える
37
Slide 38
Slide 38 text
判断の粒度を一段ずつ上げる
いきなり上位の判断はできない
今の職位で「一段上の判断」を引き受ける
→ キャリアの中で 実装判断 → 設計判断 → 構造判断 → 方針判断といった具合に一段ず
つ粒度を上げていく
38
Slide 39
Slide 39 text
長期視点を持つ
半年後・1年後にどうなっているか
誰が保守するか
変更はどれくらい入りそうか
→ 長期視点は才能ではない。訓練により身に付く。
39
Slide 40
Slide 40 text
決めないことのコストを意識する
判断を先送りすると何が起きるか
チームのアジリティが鈍化
先延ばしにより技術的負債が加速度的に増えるリスク
→ 判断しないことも、判断である。
40
Slide 41
Slide 41 text
まとめ
エンジニアのキャリアはただの能力の積み上げではない
任される判断と責任の拡張こそがキャリア
サラリーマンエンジニアに必要な技術力とは、具体的なエンジニアリングスキル
を基礎として現実的な制約の中で判断し、その結果に責任を持つ力
職位別に期待される責務と判断を踏まえた上で、どの判断に責任を持ちたいかを
描くことがキャリア選択
技術力がなければ良い判断はできないしそれに責任を持つことはできない。よっ
てどの職位になっても技術的な研鑽は必要。
41
Slide 42
Slide 42 text
参考資料
エンジニアのためのマネジメントキャリアパス - O'Reilly Japan
ソフトウェアエンジニアガイドブック - O'Reilly Japan
CV Driven Development (CDD) | Martin Jee's blog
42