キャリアにおける「気づき」と経験学習
先日、いま一度エンジニアのキャリアについて語ろう というイベントでモデレーターを務めさせていただきました。役割上、話を聞く方に集中していたため自分自身の話はあまりしませんでしたが、私自身聞いていて勉強になる内容でした。(そのうち公式のイベントレポートが掲載されると思います)
そんなこともありながら、年末ですし良い機会でしたので自分のキャリアも振り返ってみました。
キャリアの大きな流れ
自分のやってきたことと、それぞれの時に考えていたものをまとめると以下のようになりました。(タグは思いついたこと並べたので粒度はバラバラです）
全体を通してみると、ありがたいことにキャリアを通して新規のもの、「初」のものに携わらせていただく機会が多かった、と感じています。
まず何よりも周囲の人、タイミング含め運に恵まれてはいたと感じます。ただ自分としても「迷ったら飛び込むこと」と「飛び込んだらどんな形でもやり切る」ということは常に意識して行動していました。そのことによってチャレンジできた「初」も多かったです。
これは、前述のイベントで、パネラーの方々もおっしゃっていた「変化を恐れない」という部分に通づるところはあります。
そしてもう一つは、「正解がない中で自分の意志で決める」ということを早いタイミングで気づき、実践してこれたのは良かったと感じています。
迷ったら飛び込む・飛び込んだらやり切る
諺で「虎穴に入らずんば虎子を得ず」というものがあります。虎の住む穴に入らなければ、その中にいる虎の子を捕まえることができない、つまり、危険を冒さなければ、大きな成功を得ることできないというたとえです。
LIFULLでの挑戦は、虎穴に入るように直接的に命が危険にさらされることはありません。それでもやはり未知のものに飛び込むときにはハードルを感じていました。
例えば、2009年のiOSアプリの開発は社内での公募PJでした。当時私は新卒2年目で、部門の業務では一定のことができるようになっていた(と当時は思っていました)ものの、利用言語はPHPが中心でメモリ管理(当時はObjective-C)が必要な言語で業務レベルのアプリケーションを書いたことがありませんでした。そんな中、かなり不安はありましたが、飛び込むこと決め公募に手をあげました。
他にも、iOSアプリの開発が終わり、サイト開発に戻った後、API基盤刷新のプロジェクトを始めたときも、当時の上長の「興味ある人」という問いかけに対して手を上げたものでしたし、そのAPI基盤刷新PJの後、事業系システムのクラウド移行PJに参画する際も自ら志願して加えてもらいました。
確かに、今までの慣れている、勝手知ったる環境からやることを変えるとスキルセットも使えるものばかりではありませんが、それでも幅を広げていきたいと思っていたのでやっていました。
スキルセットを広げるために環境を変える、という観点では転職という選択肢があること自体はもちろん知っていましたが、私は『LIFULLのビジョンに共感して入社している』ということと、『その時々のチーム・上司・仕事含む自分の状況から周囲も巻き込んだうえで、自分と周囲の状況を変えていけないと今後の自分の中での再現性が生まれない』という考えがあったので、その選択肢をとることは考えていませんでした。(ここはあくまでも私個人の考え方です)
飛び込むことを繰り返していく中で、新しいものに対する不安な気持ちは0にはならないのですが「飛び込んだ先でどうにかできるだろう」という楽観的な気持ちは持つことができるようになりました。
正解がない中で自分の意志で決める
これも入社当時から今までの周囲の方々に感謝しかありません。
入社1年目のときに、システム設計の相談を先輩に「これは、AとBの方法が考えられるのですが、どちらが良いでしょうか？」と質問したとき「長沢くんはどう思うの？」と聞かれました。
当時は「自分は1年目だし、先輩に判断してもらったほうがいいんだろうな」と思っての質問だったのですが、「これは、物事の判断を仰ぐにしても、自分なりの結論とその結論を出した理由を持っていかないといけないな」という気づきがありました。
また、2年目のiOSアプリの開発において、社内でもベテランのエンジニアの先輩たちと一緒にアプリケーションの設計について話しているときのことです。前述のとおり、飛び込んこと自体も不安なところだったのですが、1年目の気づきを活かし「このパターンならこちらの設計のほうがいいと思うのですが、どうですかね？」というようなコミュケーションをとっていました。
すると、その中にいた先輩の一人に「長沢くんは提案するけど決めないよね」と言われました(厳しい言い方ではないです)。個人的に、これは良い意味で衝撃でした。1年目のときと似ているのですが「こんな凄い先輩たちとみんなで作っていこうと言っているものの方針を自分が決めてはいけないのではないか？」と一人で勝手に思っていたのです。
ここで、『たとえ相手が誰だったとしても、自分がいいと思ったものは「こうしましょう！」と意志を持って決めていかないとな。そして、もし、もっといい案があれば他の人が言ってくれるだろう』 と気づきがありました。
そんな気づきを得ながら迎えた4年目の後半には、全体で利用しているAPI基盤の刷新を始めることになります。もともとは違うPJだったのですが、そこから派生して手分けしてすすめることになったので、一人ですすめることになりました。
それまではPHPが主流だったLIFULLでは初めての言語(Ruby)ということもあり、フレームワーク、アーキテクチャも自分で考えていく必要がありました。途中何度も「これってこんな全体に今後も長く関わる部分（今後含めたAPIを利用するシステムと、開発していくエンジニア全体の生産性に多大な影響を及ぼす）部分なのに、全く何もないところから自分で方向性すら決めていっていいのか？」と思いました。もちろん周囲にも意見をもらいながらやりましたが、自分で決めなくてはいけません。
実際にそれはプレッシャーでした。
ただ、今までの経験から、「(もちろん周囲にも相談しますが)最終的には自分で方向性も決めて、それを正解に近づけるようにやりきっていくしかないんだろうな」みたいな気持ちがありました。ここは「何かあってもLIFULLのみんななら一緒に良い方向にするために協力してくれるだろうな」という安心感があったのでそういう気になれたとも思っています。
それらの気づきがあったおかげで事業系システムのAWS移行や、LIFULLで各種CxOポジションが新設された際のCTOにも任命頂いたときも、迷うこともありながらも、自分なりの方向性も決めていくことができたんだろうな、と思っています。
経験学習
ここで少し話は変わりますが、私自身そんな経験をしながら、その自分の実体験にも近いものが「経験学習」というものでモデル化されていることを知りました。
米国の経営コンサルタントである、マイケル・ロンバルドとロバート・アイチンガーは「人はおよそ70％を経験から学び、20％は観察学習や他者からのアドバイスによって学び、残りの10％は研修や書籍などから学ぶ」という「7・2・1の法則」を語っています。
また、デイビット・コルブは単に経験するだけでなく、経験を次に活かすためのプロセスが重要であると説いています。
具体的経験：その人自身の状況下で、具体的な経験をする。
省察：自分自身の経験を多様な観点から振り返る。
概念化：他の状況でも応用できるよう、一般化、概念化する。
試行：新しい状況下で実際に試してみる。
自分の経験で当てはめてみると、前述にあるような具体的経験をした後に、周囲からの意見などももらいながら自分はもっとこうしたほうが良かったかもしれない、という気づき(内省的考察)と、「次回から同じようなケースはこういう考えで行動しよう」という概念化をたどり、次の同じようなケースで施行・実践していくということなんだな、と改めて感じます。
上記の内容は 経験学習入門 というこちらの本がわかりやすく整理されていました。この記事で書いてきた内容も、上記のフレームで整理していくと、より解像度高く理解できたのでおすすめです。
さいごに
お付き合いいただきありがとうございました。様々なポイントで気づきはありましたが、自分の性格としては「相手が何を考えてるのかを気にしすぎる」という部分や「相手の言葉の言外の意味を気にしてしまう」というのは根本であるので、より気づきは得やすいのかもしれません。もちろん、良いことばかりではなく、余計な心配をしすぎて落ち着かなかったり、杞憂に終わることも多いです。
今年も一年ありがとうございました。
LIFULLのエンジニアの成長に関しても前述の経験学習としての考え方も活かしながら、来年もまた、みんなでより良い文化を作っていきたいです。
LIFULLはエンジニアを募集してます！カジュアル面談も随時実施しておりますので興味持ってくださる方は以下ご覧いただければと存じます。
来年もよろしくお願いいたします！
この記事が気に入ったらサポートをしてみませんか？