エンジニアキャリアの歩き方
自分のキャリアを棚卸しする「スキルマップ」の作り方
次に何を勉強するか、毎回決められない
新しい技術の話を見かけるたびに気になって、少し触って、また別のものが気になる。学習が続かないのではなく、選ぶ基準が無いまま毎回ゼロから選び直しているのが原因です。
基準を作るには、まず今持っているものを外に出す必要があります。頭の中にあるうちは、できることは過小に、できないことは過大に見えます。書き出して並べると、思っていたより持っているものと、思っていたより手を付けていないものが、両方はっきりします。この作業を棚卸しと呼びます。
まず、評価しないで全部出す
最初の段階でやることは一つだけです。触ったことがあるものを、上手い下手を判断せずに全部書き出す。
「少ししか使っていないから」と手を止めると、ここで半分が消えます。判断は次の段階でやるので、この段階では網羅を優先します。分類は、言語、フレームワーク、データベース、インフラや基盤、開発を回す道具、くらいの粗さで十分です。
とはいえ、何もない状態から思い出そうとしても、直近の数か月分しか出てきません。手がかりになるのは、自分が残してきた記録のほうです。コミットの履歴、閉じたチケットの一覧、カレンダーに残っている会議の名前。これらを古いほうから順に眺めていくと、忘れていた仕事が次々に出てきます。記憶ではなく記録から拾うのが、網羅するための一番早い方法です。
書き出す対象は技術だけではありません。人に教えた経験、仕様を詰めた経験、障害の対応をした経験、外部の担当者とやりとりした経験も同じ紙に並べます。数年経ったときに他の人との差になるのは、こちらの側であることが多いからです。関わってきた業界の知識も忘れずに入れておきます。
使える度合いに、目盛りを付ける
全部出したら、それぞれに目盛りを付けます。細かくすると付けられなくなるので、判定できる文で区切ります。
| 段階 | 判定の目安 |
|---|---|
| 1 | 調べながらなら書ける。仕組みは分かっていない |
| 2 | 指示があれば、よくある機能は一通り作れる |
| 3 | 一つの機能を設計から公開まで一人で通せる。人のコードを見られる |
| 4 | 詰まったときに原因を追える。全体の構成を決められる |
| 5 | 選定の判断を任され、その理由を組織に説明できる |
ここで大事なのは、3 と 4 の間に一段深い溝があることです。1 から 3 は使った時間で上がりますが、4 から先は「なぜそう動くのか」を追った経験でしか上がりません。目盛りを付けてみて 2 と 3 ばかり並んでいるなら、数を増やすより、どれか一つを 4 まで持っていくほうが、次の一手としては効きます。
実績は、前と後をセットにしないと残らない
技術の一覧だけでは、何ができる人かは伝わりません。裏付けになるのは、実際に手を動かして何が変わったかです。書き留めるときは、状況、課題、やったこと、結果の 4 つの見出しで並べると、後から使える形になります。
このとき、結果の欄を空けたまま先へ進まないようにします。埋まらない場合、その仕事の効果を自分が把握していないということなので、確かめに行く価値があります。数字が取れないものは、前の状態を一言添えるだけでも構いません。
出来上がったものは、3 か月ごとに見直します。半年も置くと、何をやったか思い出せなくなり、また一から書き直すことになります。更新しやすい場所に置いておくのが、続けるための唯一のコツです。並べたものを眺めれば、次に時間を使う場所は自然に浮かんできます。
復習ミニクイズ
実績を第三者に説得力を持って伝えるための「STARメソッド」に基づいた記述として、最も適切なものはどれですか?