ジョブレベル
呼び方は組織によって違うが一般的にジョブレベルは
- ジュニア（新卒・インターンなど）
- ミッド
- シニア
- スタッフ -> シニアスタッフなど/マネージャ -> シニアマネージャ
のように分けられてます。実例を見るとwiseはこのようにキャリアマップを作っています
シニアに到達するとその次はICのトラック（スタフ、プリンシパル）を続けるかピープルマネジメントトラック（エンジニアリングリード、シニアエンジニアリングリード、ディレクター）に移すか選択できる。もちろんシニアのままにいるのも企業によって可能だったりします。シニアエンジニアは１人前でタスクをこなせたりプロジェクトをリードしたりできると期待されているでしょう。チームメイトのメンターシップも必要があれば手伝えます。シニアに到達するには 3 ~ 10年かかると言われてます。
ゴール
この記事はシニアエンジニアに到達するまで必要になってくるスキルや考え方をまとめます。読むと人より早くシニアエンジニアに到達するかもしれないです。中には僕がソフトウェアエンジニアをやってきた中先輩たちからもらったアドバイスややってよかった、やればよかった話が入っています。
シニアエンジニアとは
これも企業によりますがopensalaryを見ると10年目の中央値が950万で75th percentileが1200万円です。10年目はシニアと呼んでもいいでしょう。実力的にはおそらく差がそんなにないが国内企業と外資企業どちらかで働いているかによって年収乖離が出てきます。差分が出てます。この記事では10年目のエンジニアのような年収をもらうのに何を意識すればいいか話します。
ジョブレベル歴
今まで自分のソフトウェアエンジニアのジョブレベルは概ね
- 1~2年目：スタートアップでアルバイト
- 3年目：新卒で日経web企業（400人弱、エンジニアは100人以上）に入り
- 4年目：ミッドレベルに昇格
- 5年目：シニアレベルに昇格
- 8.5年目：外資IT企業（3000人以上、エンジニアは1000人以上）に転職。ジョブレベルはミッドレベル（降格！）
- 9年目：外資IT企業で１回目のパフォーマンスレビューにてシニアレベルに昇格
見せびらかすつもりなくサクサクと昇格できたのはチームメイトやマネージャーに恵まれていたからです。それと仕事中に何度も何度も以下に述べることを意識していました。
マインドセット
ロール
ソフトウェアエンジニアの一番重要な仕事は他の職種と同じくビジネスを成長させることです。コードはただの一つの手段でありもっと大事なのでどうやってコードでビジネスに価値を加えていくことです。PM（プロダクトマネージャー）、営業、デザイナーなどと同じくプロダクトへの影響力が同等であるべきです。ソフトウェアエンジニアはコードに一番近いのでコードがビジネスのポテンシャルやリミットがPMと違う角度で見えるはずです。プロダクトのオーナーであり自分の書いたコードをリリースして価値をユーザーに届くまでがのなげれとても大切です。バグがある時もオーナーシップを持って自分達で修正してパッチをデプロイする。その繰り返しがあってからこそいいエンジニアになれます。プロダクトマネージャーからビジネスへ少ししか価値を出せないが、コードベースには大きな負債となる機能依頼がきたら断るべきですし、セールスチームから売上増大のためにグレーエリアの機能依頼が来た時はリスクを考慮しながら議論すべきです。わかりますよね？コード書けるということは世の中に対してポジティブなインパクトは出せるがその逆を防ぐのも我々の仕事です。
ただのコーダーでプロダクトへのオーナーシップがない場合は一旦技術だけにフォーカスする。転職をすぐ視野を入れましょう。オーナーシップという感覚を最初から理解しとかない後々難しくなります。
コード
コードを書くのが一つの手段でコードがどれだけ綺麗に書けるとしてもビジネスに対して価値がなければただの負債だ。あと書いたコードがデプロイされてなければそれも同様に価値がゼロに近い綺麗なコード書きたいなら仕事以外で書け。仕事ではメンテナンスしやすさが大事。
make it work → make it fast → make it maintainableの順番でコードを書く
make it work: これがないと何も始まらないのでまずは動くものを作りましょう。workの定義ですがcorrectlyとsecurelyが入っても良いという考えです。いわゆる正しく、安全に動くものを作りますmake it fast: スピードは一つの機能として考えていい。スピードが上がればサーバーコストの節約やユーザー体験の向上などにつながるので大きな価値になります。
make it maintainable: コードを書く時間より読む時間の方が圧倒的に多い。しかも読む人数のが多いからメンテナンスしやすさの効果もその数の倍になる
リリース
リリースしないとどれだけ綺麗なコード書いても価値にならないです。コードを書くのと同じくリリースが大事です。組織にリリースの問題があればまずそれを直しましょう。リリースするのにすごく手間がかかってストレスな環境なら優先的にそれを直すべきです。理想なリリースのプロセスはエンジニア誰でもボタン一個押すかmasterブランチにマージするかだけで終わらせたいですね。リバートも同じ手順であるべきです。
リリースはあくまでユーザーやビジネスに価値を届ける手段でありその真の価値を理解することが大事です。理解した上でスコープの再定義ができるわけです。スコープが大きすぎるとリリースまで時間がかかるのでユーザーからのフィードバックが遅くなるリスクになります。
上の図のようにスコープを再定義することによってリリースしていくのがオススメです。
エラーメッセージ
エラーメッセージはギフトです。エラーメッセージを理解できるエンジニアは確実にデバッグ力が違ってくるのでエラーをすぐ無くそうとしないでなんでそのエラーが発生したのか理解すべきです。やっていくうちに分かると思うがエラーメッセージは本当にその数パターンしかなく大体StackOverflowに解説があるのでそれを学ぶです。
本番環境でこういうランタイムエラーが起きてます
java.lang.NullPointerException: null
at com.example.api.v1.services.ClassA.find(ClassA.scala:138)関係ありそうなコードはあえて見せないけどエラーから推測したいです。ここであり得そうなのはfindかClassAがnullと推測してます。findというメソッドがnull: findでないならランタイエラーではなくコンパイル時に例外になるはずだが発生してなかったです。コンパイルとランタイムのバージョンが違えば論理上発生する可能性があります。ランタイムエラーにしてもコンパイルエラーにしてもfindがnullの場合おそらくNullPointerExceptionではなくMethodNotFoundExceptionになるので一番大きな可能性はClassAがnullです。
こうやってエラーメッセージに慣れるとデバッグ力が強くなります。
コードのリファクタリング
新卒の時から先輩に教わった最も大事なリファクタリングの話：リファクタリングはビジネスに対して価値がなければやりません。リファクタリングのためのリファクタリングするのはやめましょう。
Refactoring -- Not on the backlog! が本当に素晴らしい記事で一度読んでほしいです。そのまとめですが：
コードベースが小さいときはこういうふうに左から右までサクサクと行ける。早くデプロイできてユーザーに価値届けられる。素晴らしい
そのうち使われてないクラスなのか重複しているコードなのか手動でのハードコーディングなのかみたいなのが出てくるよ。それが邪魔となり左から右まで行くのに以前より遠回さないといけない
上の状況が悪化して。ユーザーに価値を届くのに時間がかかる。いざどうするか
コードベース全部をリファクタリングはしない。すると時間が掛かるしいいリファクタリングになるかは、誰にも保証出来ません。左から右に行くのに通らないといけない道だけのリファクタリングをします。
リファクタリングはメインタスクではなくメンテナンスしやすさを保ちつつやるサブタスク的な考えで良いです。なのでPR(プールリクエスト)もそのように分けるべきです。機能を足すPRと一緒に足すのではなくリファクタリングだけのPR出してマージされてから機能を足すPRを出すとレビューがスムーズです
優先順位
タスクはインパクト対エフォートで考えられます。low effort high impactはタスク的に難しくないがビジネスへのインパクトが大きい。high effort low impactがその逆。
- low effort high impact：新規プロジェクトならこれを選びたいがコスパが一番良いので一番早く完成される
- high effort high impact：計画したはずのタスクなのでやればいい
- high effort low impact：コスパ的に良くないのでやらない判断になりそう
- low effort low impact：snackingともいいやってもいいが慣れてしまうとビジネスもエンジニアとしても成長がしなくなるので避けるべき
エンジニアとしては1、２をなるべくやって3と４を避けるべきです。
新規プロジェクト
新規プロジェクトはビジネスに新たなインパクトを与えるポテンシャル一番高いので携われるようにしたいです。マネージャーにやりたいのをアピールしたりパブリックチャンネルで興味を示したりしておくのが良いです。
新規プロジェクトをやる場合新たなコードベースから始めらるからユーザーに価値を届けるスピードが違ってきます。下の状態です
比較的に簡単にインパクト出せて昇格につながります。
レガシープロジェクト
レガシーコードとの向き合い方は
- コードはすぐレガシーになってしまうので無くすよりどう延命できるのか考える
- レガシープロジェクトはビジネスに新たな価値を付与しないので頑張らない方向に持っていきたい
- 触らなくてもいいところは触らない
- テストコード無いならテストコード追加してから作業しましょう
- コードを削除したい気持ちはわかるがなんでそのコードが最初にあったのか理解するのが大事。Chesterton’s Fenceというやつ
プロジェクトは完成させましょう
「メインな機能をリリースしてバリューを出したがまだ小さなタスクが残って重要ではないしやる気もあまりなく次の面白いことやりたいね」と思ったことないでしょうか。GitHubのブログに出てたjQuery移行の話だがこれも100%移行できていい話でした。99%と100%は1%の差しかないがそのインパクトが全然違うので完成させるのが大事です。
もちろん全てのプロジェクトがそういうわけにはならないのでコミュニケーションととって完成のスコープを再定義して切り替えるのも一つのスキル。メタissueを閉じて残りのタスクを別のissueにまとめるのはよくやってました。
議論
チームで働くとみんな違う背景持っているし当然意見が合わないときもあります。ここで自分の意見が反対されても大事なのはdisagree and commitです。理由は議論に時間を使うより早くアイディアを検証してフィードバックをもらうことが大事からです
Ask for help
現職（外資IT）に入ったとき最初からマネージャーに言われたのは「You are not supposed to know everything, so does everyone. Ask for help」。チームが大きくなるやることがはっきり決められて他チームの仕事の関わりが少なくなりました。なので他チームの仕事を理解する必要が出てきたら「Ask for help」が一番良いアプローチですね。
Swinging the pendulum
組織はKPIがあってそのKPIを達成するためにセールス、運用、サポート、エンジニアなどが動いています。ただしいつまでもKPIを達成するために働いているかというとそうでもないです。時にはKPIと全く関係ない（ように見える）仕事をしているときなかったですか。これはShopify社内ではSwinging the pendulumと呼ばれてます（source）。
場合によっては機能をたくさんリリースする時期もあれば機能をリリースを全く考えない（整備などにシフト）時期もあります。長期的に見るとバランスの良い結果になります。