サラリーマンソフトウェアエンジニアのキャリア

最近少しキャリアについて考えていたので自分用に整理したもの

Transcript

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