みなさんこんにちは、システム部の山下です。前回のブログを書いた時点から、実はわたし、大きく変わりました…！
※前回のブログはこちら「やさしい日本語、はじめました。～海外メンバーとのコミュニケーションをより円滑にするためのトライ～」
なんと、、、GMOリサーチに入社して３年目になりました！！！
えっ、たかが3年目なのに大袈裟すぎるって？！わたしにとっては、大きなことなんです！！
お恥ずかしい話なんですが、わたしは人よりすこーし長く学生をしていたのと、これまで転職を2回したので、人生で初めて、1つの勤務先で3年目を迎えたんです！！
さて、ただの近況が長いよって思われたかもしれませんが、これが今回のブログテーマに繋がりますっ
山下、3年目を迎えて…キャリアに悩みました！！！
ChatGPTやGitHub Copilotの登場で、指示さえ正しく書けば、自分で一から書くよりも速く！楽に！コーディングできちゃいます。
そんな便利な世の中になってきて、この先エンジニアとして、わたしは、どう会社に貢献できるか？それを真剣に考えるようになりました。
今回、そんな私がエンジニアのキャリアについて考えたことを、GMOリサーチの事例を踏まえて書いていこうと思います。
どんなエンジニアを目指すべき？
まず、どんな開発エンジニアを目指すか、を考えたとき、やっぱりエンジニアなんだから、技術分野でなにか得意なことを見つけなきゃって思いました。
たとえば、最新技術のキャッチアップ＆自分で試す、とか、AWSみたいなインフラにも精通している、とか・・・
方向性を考えるために、エンジニアのキャリアについて調べていると、あるものを見つけました。それが、「A framework for Engineering Managers」です。
※なお、下記リンクでは、これを日本語で紹介しています。https://unlearned.github.io/engineeringladders/ja/
A framework for Engineering Managersとは？
A framework for Engineering Managersとは、
- 技術力
- システム
- 人
- プロセス
- 影響力
といった５つの軸から、エンジニアのポジションごとに期待されることをレーダーチャートで視覚的に表現したものです。
これを見て、エンジニアとしての長所は、技術力だけじゃない、むしろ観点は複数あって、しかも複合的なんだってハッとしました。
たしかに、わたしが「かっこいい！」「こうなりたい！」と憧れているGMOリサーチの先輩たちの姿をよくよく思い出すと、先輩たちがやってくれたことは、技術があるからできること、だけではなかったです。
以下にその例を紹介します。
GMOリサーチエンジニアの実例紹介
チームメンバーへのサポートが手厚い
①コードへのフィードバックの仕方
レビューはいただけるだけでとっても有難いんですが、「これってどういう意味？」「結局どうすればいいの？」って悩むときもあります。
でも、GMOリサーチの先輩方がくれるレビューは、
- 修正したほうがいいコード(行数も特定)
- 修正したほうがいい理由
- 修正の具体例（たとえば、メソッド名やテストケース名など）
を添えてレビューしてくれます。
だから、修正方針に悩むことはないですし、整理されたレビューは記憶にも残りやすく、同じ指摘を受けないように注意することができていると思います。
また、自分がもらってうれしいレビューは、相手ももらってうれしいはず！
ということで、レビューの書き方や着眼点も学べています。
②答えだけでなく、考え方や便利なコマンドも合わせて共有
なにか質問をしたとき、その質問に対して答えてくれるだけでも有難いんですが、「その質問をするってことは、そもそもここが分かってないのかも」とか「答えが分かってここをクリアした後、今度はここに躓くかも」など、質問の直接的な答えに留まらず、そこから派生した情報を合わせて教えてくれます。
たとえば以前、調査対象になるデータをDBから抽出したとき、必要なデータがうまくとれず先輩に相談しました。すると、正しいSQLを書くための考え方はもちろん、長くなったSQLを編集するときに便利な、\eコマンド(MySQLクライアントが設定されたテキストエディタを起動する)を教えてくれました。
③質問されたとき答えられなかったら、一緒に答えを探す
そんなスーパーな先輩たちも、「その質問にはすぐに答えられないなあ」ってときもあります。
でも「分からない」で終わることはなく、一緒に調べてくれたり、誰だったら分かるか、エスカレーション先を教えてくれたりします。
進んで改善をする
「これは不便だな」って思ったことがあれば、どんな小さなことでも見逃さず、改善するためのアクションを進んでやられる姿を、何回もみました。
例えば、わたしのチームでは、他部署からMarket Observerの仕様やシステムエラーなどのお問い合わせがあります。
お問い合わせは、Slackのチャンネルメッセージでいただくので、調査に必要な情報を聞き出すため、何度かメッセージをやりとりする必要があり、調査開始までに時間がかかることもありました。
そこで、Slackのワークフロー機能を使い、調査に必要な情報を最初のお問い合わせ時にいただけるようになりました。
自分が「不便」と思うだけではなく他の人が不便を感じることがあれば、それも改善対象になっています。
そんな先輩の態度は、不便であっても「ま、いっか」で済ませていたわたしの態度も改善させました。（笑）
お問い合わせに＋α、業務の方に寄り添った返答をする
3-1.②と似ていますが、この姿勢はお問い合わせへの対応時にもみられます。お問い合わせに答えるときも、直接的な答えでおわるのではなく、それに付随する必要な情報も合わせて提供しています。
また、Market Observerの仕様を説明する際、画面にでてくる用語を使ったり、バックエンドのロジックではなく、画面操作を通して因果関係を説明するなど業務サイドの方に寄り添った答え方をするよう意識されています。
エンジニアとしてキャリアの道を広げるために
上記の先輩たちの行動を一言で言うなら、ホスピタリティだと思います。
（「A framework for Engineering Managers」に沿えば、人・技術力・影響力にあてはまるかもしれません。）
先輩たちのホスピタリティは、チームメンバーのわたしの学びや成長を促し、また他部署メンバーの困りごとの解決、信頼関係の構築につながっていると思います。
このホスピタリティは、エンジニアなら誰もがもっているというものではないため、もしホスピタリティをもって行動できるのであれば、それは、「エンジニアとしての長所」といえるのではないでしょうか。
もちろんエンジニアは、“テクノロジーでなにかを作り出すという役割を担う専門職”※1だという前提は、忘れてはいけません。
ただエンジニアは、その職種の特徴から、技術面での貢献が取り沙汰されることが多く、そうした状況の中で自分の将来を見つめたとき、わたしのように、キャリアの道を狭く感じる人もいるかもしれません。
流行りの技術をいち早く取り入れたり、処理スピードを○%アップさせたり、みたいないわゆるエンジニアらしい、技術的な活躍は、華々しいし憧れます。ただ、AIの進歩が目覚ましく、技術的な仕事がある程度任せられるようになってきた今、これからさらに、エンジニアは技術だけではなく、多様な長所が評価される仕事になっていくのではないでしょうか？
わたしは「A framework for Engineering Managers」との出会いにより、技術力に固執せず幅広い観点で自分の長所がなにかを考え、その長所と開発業務を結び付けることで、自分がなりたいエンジニア像が見つけられるかも、と思うようになりました。
みなさんも「A framework for Engineering Managers」を参考に「技術力」だけでなく自身の＋αの部分を考えてみることで、自分にしか作れないキャリアを形成することができるかもしれません。是非一度、多様な方向性からキャリアについて考えてみてはいかがですか。
以上、読んでいただきありがとうございました。
※1 引用：聴くエンジニアtype Vol.20『テックトレンドに興味がない…情報収集が苦手なエンジニアはどうしたら？』
