キャリアキーノート
業務のフィードバックをいただく中で「これってどこで身につけたんですか」と聞かれたのをきっかけに自分の思考を整理しました。その過程で、ぴったりのフォーマットがあることを思い出したので、キャリアキーノートとして紹介します。
キャリアキーノートとは？？
詳しくはこちらをご覧ください。
前職のCTOと、エンジニアの方によるキーノートの紹介も参考にご覧ください。とてもいい資料です。
ということで私のキャリアについて話します。
エンジニアに興味を持ったきっかけ
<この時やっていたこと>
歯科医療法人の事務局で働いていた時にホームページのリニューアル作業に携わっていた
見積もりを理事長に出すと、毎度毎度「高い！交渉しろ！！」と言われ撃沈😭
妥当な金額とは何かを理解するためにHTMLの本を購入
その本は挫折したが、やっぱりやりたいなと思ったので1年越しくらいにジーズアカデミーに一期生として入学。エンジニアの勉強を始めた
もともとはホームページが作れるくらいになれたらいいなと思った程度だったのが、ジーズアカデミーに入ったことでWeb系エンジニアのオープンな価値観やエンジニアカルチャーに強く惹かれ、エンジニアになりたいと強く思うようになリました。
→漠然とした興味関心でエンジニアを目指し始めた
キーノート
ちょっとした興味や関心からアクションを起こすことが大事
起業家精神、エンジニアカルチャーという今まで想像もしなかった世界と価値観を知ったことで、一気に世界が広がった
自分自身が生まれ変わったように、人は意外と簡単に変われる
ジーズアカデミーを通して学んだ最も大事なこと
これらの価値観に共鳴するジーズアカデミーの同期に出会えて本当に楽しかった。同じ目標を持つ仲間の大切さを知った
ファーストキャリアの選択。強いエンジニア像🦸♂️
ジーズアカデミーを卒業したはいいが、自分の中では不安しかありませんでした。
<この時考えていたこと>
起業する同期のスタートアップを一人目エンジニアとして手伝う自信がない
自分でリスクが測れないのに「決め」ができる気がしなかった
なりたいエンジニア像がはっきりしなくてどういう会社に面接行けばいいかわからない
SIerとかSESは嫌（当時の勝手な偏見です）
とにかく、もっともっと強くなりたい
とにかく強いエンジニアになりたい！という超ざっくりした希望を持ちつつ、まだまだ就職できる実力もないし、、、とモゴモゴしていたおり、GMOペパボが主催する大名エンジニアカレッジの一期生に参加したことで私の中での「強いエンジニア」の解像度が一気に上がりました。 大名エンジニアカレッジで接したエンジニアさんたちは、現場で活躍するエンジニア。やり取り一つ一つが本当に私にとっては衝撃の連続で、「すごいエンジニア像」が私の中で明確になったのがこの時期です。そしてそういうエンジニアに強く憧れるようになりました。
<すごいエンジニアってこんな人 🦸♂️>
とにかくなんでも知っている、質問したらなんでも返ってくる
初心者向けの説明がとにかくわかりやすい
言語化の能力が高いというのはこういうことかと思わされた
強いエンジニア＝怖いというイメージが払拭された
ポジティブなフィードバックが上手だった
ペパボのエンジニアさんはペパボの価値観であるわたしたちが大切にしている3つのことの体現者なので、彼らに憧れた私も自然とそのように振る舞うようになり、結果としてスクールを通してリファラル採用の面接のチャンスをいただき入社することができました。 →とにかく、もっともっと強くなりたい！！！
※（余談）私が憧れたエンジニアさんたちの振る舞いは、ペパボのエンジニアカルチャーとして以下の資料に明文化されています
キーノート
すごいエンジニア、つよつよエンジニアってすごい（語彙力）
ぼやけたイメージで憧れていても何もわからない、実際に接することでより解像度が上がる
なりたい像を身近に目にすることでモチベーションも上がった
ここでも、興味のままにアクションを起こしたのが功を奏した
「なんか知らんけど強いエンジニアがいるらしいし、かっこいいカルチャーを持ってるペパボ」に興味があったので即申し込みした
チャンスがあれば全力で飛びつく
入社が決まったときは嬉しさだけだったが、入社が近づくにつれ不安になった。通用する自信はまるでなかったが、まずはやってみることにした
ペパボ駆け出し期。エンジニア１年目🏃♀️
入社してみてわかったことですが、大名エンジニアカレッジに参加していたのは社内でも「シニアエンジニア」以上の方々でした。憧れてみるのはタダですが、大きな大きな隔たりがあることを日に日に実感していく日々でした。
同時期に入社したエンジニアはおらず、個人開発では使ったことがない開発のツール類、開発のお作法、開発のキャッチアップなどなど、知恵熱が出るかと思うほど、脳みそを毎日フル稼働させていました。
<この時やっていたこと>
日々自分のやっていることを分報形式でSlackにアウトプット（入社時の決まり）
とにかくテキストでアウトプットすると頭が整理される
誰かが見てくれてフィードバックをくれる
後から読み返すと作業ログとして使える
触ったことのなかったコマンドを駆使し、お問い合わせ対応の為にインフラのログ調査に奔走する日々
調査の経過をIssueに残し、ログでわかる事実を元に自分の考察を踏まえて結論を記載するお仕事
ユーザーの申告内容と調査結果は往々にして一致しない（これが重要）
ユーザーの言葉から自分で仮説を立て、課題定義し、調査を始める必要がある
調査の経過と結論に飛躍があると「なぜこの結論に至ったのか」のツッコミがくる
調査の経過をログとして「過不足なく」記載する必要性を痛感
結局後から同じようなことが発生した時にわかりやすい調査Issueは自分の助けになる、かつドキュメントになる
手順を聞いたまま作業としてやっていると調査内容に辻褄が合わなくなる。システム全体のインフラ構成の理解が必要なことを痛感した
同じチームのメンバーに何度も助けられた
インフラ領域のオペレーションは職人たちの仕事だったので暗黙知が大量にあった
これがドキュメントを作るモチベーションにもなった
ドキュメントをとにかく書きまくった
自分の実力のなさに絶望しながら最も早く業務で貢献できる道を模索した結果
自分でドキュメントにまとめることで作業手順の意味に対する理解が深まった
お問い合わせの対応を繰り返す中でユーザー目線を身につけた
unknown-unknownをknown-unknownにするためにインデックスを貼る目的でとにかく本を読み漁った
※unknown-unknownについてはこちら
キーノート
アウトプットするといいことがたくさんある
フィードバックを得られる、頭の整理になる
作業記録として後から読み返せる
意図を理解して作業することの重要性
作業の意図が分かっていないと過不足なく調査内容を記載できない
暗黙知を形式知にする重要性を認識
ドキュメント作成が知識を深めるのに役立つことを実感
構造化してテキストに起こす過程が理解を助ける、理解できていない点、不明点が浮き彫りになる
本を読んだりしてインデックスを貼っておくと複利でのちのち効いてくる
この当時、なんもわからんが「良いコード」とか「良い設計」に関する本も読んでいたのが今結構効いていると思う
できることを愚直にやるとチームメンバーや上長から信頼と評価を得られる
正直インフラの調査業務やドキュメント整備をやりたかった訳ではないが、とにかくチーム内で貢献できる振る舞いを模索し続けた
アプリケーションエンジニアとして。エンジニア２〜３年目🧑💻
個人としてインフラ調査業務が滞りなく一人で対応できるようになってきたが、お問い合わせ件数を削減するための根本的なアクションは取れていませんでした。
根本解決のためにはアプリケーション側の理解を深める必要が出てきましたがチームにはサービスのアプリケーションレイヤーに詳しいメンバーはいませんでした。チームの価値を高めるためにも、自分自身のアプリケーションエンジニアとしての専門性を深める為にも、アプリケーション領域での活動を自ら志願してアサインしてもらいました。
<この時やっていたこと>
コードを読まないと挙動がわからない、仕様がわからない。インフラレイヤーと全く異なる調査の連続
聞いたらなんでも答えてくれるベテランエンジニアの方も「毎回実装読んで答えてます」と言ってた衝撃を忘れない
とはいえ、インフラ調査時代の気づきや学びが横展開できるという成功体験も得た
インフラ構成の理解やログ調査スキルが、アプリケーションエンジニアとして駆け出し状態の私の強みの一つになった
丁寧な調査Issueの作り方などインフラ調査時代に培ったやり方がそのまま評価してもらえた
お問い合わせ対応では常に着地点を意思決定する必要がある
意思決定に必要な内容をどう整理して自分の意思決定の正当性を担保するか
中長期的なインシデント対応の完遂
現実的な落とし所の調整や経理担当者などと影響範囲の調査手法を調整すること
ここでも調整力や粘り強い対応を評価していただけた
→複数の領域で業務をしてみて、いわゆるコンセプチュアルスキルというものについての考え方を身につけた
※コンセプチュアルスキルの中身については諸説ありますが、私はこちらの資料に出会ったので、この資料の「非常に変わりにくい」「可変的だが変わりにくい」とされるスキルに着目するようになりました
キーノート
自分でチャンスを拡げていく。半年前と同じことをやっていないか？？
より好みせずに目の前の仕事でバリューを出し続けることに注力することの大切さ。とりあえずやってみる
インフラ構成の理解やログ調査スキルが、アプリケーションエンジニアとして駆け出し状態の私の強みの一つになった
自分が見えていないunknown-unknownを自分で探すことはできない →仕事として降ってくるものを片っ端からやっつけていく
上記二つは相反するようで、実はそうでもないということ
目の前の仕事でまずは打席に立ち続けること、そこで信頼を築きながらチャンスがあればすぐに手を挙げる準備をしておくこと
チャンスがなさそうでもとりあえず手は挙げておくということ
変わりにくいスキルを意識的に伸ばすことの重要性に気づく
つよつよエンジニアの方達は総じてこのあたりのスキルがとても高いことに気づいた
変わりにくいスキルは汎用性がある
エンジニアの専門性。エンジニア４年目以降🧑💻
エンジニアとしてキャリアを続けることを考えた時の専門性に悩みはじめていました。エンジニアとして、Will, Can, Mustのバランスをどう取っていくかを考え続けていたが、流れに任せていてもWillが増えなかったという反省もありました。
ずっとCanとMustを中心にして勝負してきた感覚があり、2年目以降ずっと課題だった「Willを伸ばす」という課題に向き合いはじめた時期です。
また、社内でキャリアを積んでシニアエンジニアになっていく未来を見つめた時、あそこに到達するのに何年かかるだろうという漠然とした不安を感じてもいました。
<この時やっていたこと>
お問い合わせ対応をメインにしつつ、アプリケーションの少し大きめの機能の要件の整理や実装前調査などから対応しはじめた
社外のエンジニアリソースをマネジメント、協働しながら運用タスクを進めるようになった
既存のアプリケーション運用がメインの環境でエンジニアとして強くなっていけるかという不安
機能追加がメインで、新しく環境を作ったり仕組みを導入するような機会は少ない
要件定義や設計など、エンジニアとして必須のスキルなのにチャレンジできるチャンスが少ない環境に感じた
社内にはさまざまな専門職が在籍しており、ビジネスの要件を整理して機能を提案するのは「ディレクター」のお仕事
エンジニアは要件が固まったあとに「どうやって作るか」を考えるところから
もっとビジネスの近くでエンジニアをやりたくなった
2年目以降ずっと課題だったWillを改めて考えようと思ったとき、実は年々選択肢が増えていることに驚いた
コードを書くだけがエンジニアではないというのを実感として感じられるようになっていた
専門職上長（エンジニアリングリード）との面談を通して「エンジニアリング」をもっと広義で捉えられるようになっていた
素晴らしい上長との出会いを通じて、MTGにおけるファシリテーションのスキルとか上長のマネジメントスタイルに感銘を受けマネジメント領域に興味を持つようになった
自分の強みや興味とエンジニアリングの掛け算で、もっともっと伸ばせる領域があるかもと思いはじめた
ある程度能力を認めてもらった環境の中で、コンフォートゾーンに留まり続けている感覚があり、危機感を感じた
→もっと施策の最初から関わりたい、ビジネスに直結する意思決定にエンジニアリングで貢献できる道はないかと考え転職を決意
キーノート
Willを最初に考えても見える世界が狭くてWillが出てこない。MustとCanを広げることでWillの可能性を拡げておくのが大事
エンジニアリングに対する視野が広がった結果選択肢が増えた
具体的にはWillとCanを拡げていく選択肢に目を向けることができるようになった
まとめ
キャリアキーノートを紹介しました
いろんな人のキャリアキーノートからいろんなエンジニアキャリアを見ることができるので、参考にしていただけるといいと思います
一番伝えたかったのは、私の振る舞いで褒めていただいたことがある部分は、上記で経験してきた業務の中でお世話になったいろんな方がすごかったおかげということです！！