「非」育成論。ジュニアエンジニアを変身させる環境の作り方。

サノくん

主人公。フィヨルドブートキャンプというプログラミングスクールに在籍中、エンペイのバイト募集をみて、2021年2月にジョイン。そのまま社員に。

意外と背が大きい。

naoyaさん

テックリード、認定スクラムマスター。2021年5月にエンペイに入社。

とても背が大きい。以前、youtuberの道に僕を誘ってきた。

町村（@machi_heigh_ho）

エンジニア、インタビュアー。2021年7月にエンペイに入社。

背が低いのと体重が重いのがコンプレックス。

田野さん（@hikoharu06）

CTO。今回、ブログを依頼してきた。

お題は「サノくんというジュニアエンジニアをnaoyaさんがどう育てたか」

意外と背が高くない。

こんにちは。

田野さんに「町村、ブログ書け。あと早く勤怠提出しろ」って言われまして、ちょっとどう書いたらいいかわからんのでとりあえず話を聞きたいんですが。

勤怠は提出しぃや。

こんにちはー。

勤怠は提出した方がいいと思います。

明日やります。

エンペイのエンジニア育成について書くんですけども、naoyaさんがサノくんをどう育ててきたか、聞いてもよいですか？

え、別に育ててへんで。 そんな余裕なかったし。

え。

そうですね、育てられた、という意識は特にないです。

え。え。

……あの、そんなに暗い顔しないでください。 育てられた、という感覚はないんですが、安心して育つことができる環境をいただいた、という感覚はすごくあるんです。

なんだァ 驚かさないでヨォ〜

お金が欲しかったんですよねー。

この頃は、jsの不具合修正やCSSフレームワークの適用、テストの修正など、主に軽いタスクをやっていました。

フィヨルドでは主に「自分が使う」アプリを修正していたのに対し、エンペイでは「お客さんが使う」アプリを修正するので、「どうあるべきか」についてより深く考えるのが大変でしたね。

この期間、わりとnaoyaさんとペアで開発していた印象があるんだけど、実際にどういう感じで仕事をしていたの？

ペア作業をしていたというよりは、naoyaさんが大方針を決めて、その中のタスクについて要件を考えて実装を進める、困ったらnaoyaさんに聞く、というプロセスでした。 特に開発初期は細かいタイミングで質問・仮説出しをして方針をすり合わせていたので、ペアに見えていたかもしれません。

すり合わせることによって、タスクの大きさも調整できたので、能力を大きく超えるタスクは抱えずに済みました。

ここが大変だった、みたいのはありますか？ コミュニケーションでも技術的なことでも。

そもそも「負債」の概念が最初共有できてなくて、人によって何を負債と言ってるのかが違うのが結構大変でしたね。 「具体的に何がつらいか」をそれぞれの人に聞いたり、そこから例えば「状態管理」というキーワードが出てきたらそれについての勉強会をやったりして解決しました。

入社前に、すでに田野に言われとったからな。 「フロントのソースが余命半年やからどないかしてくれ」いうて。 実際に実装していく段になって、一人ではなかなかきついというのもあり、サノさんと一緒に作業してたんや。

まあ実際、大変でしたよね…負債の返済とリニューアルどっちもあって。 やっぱり「育てる」という感じではなかったですか？

せやな。育成のためになにか特殊なことをしたというよりは、一緒に仕事をする中で、必要な時に必要なことを言った、という感じやな。 そもそも「育てる」というメソッドがそんなに俺の中に確立されてへんくて、その辺は手探りな感じやった。

プレリリースに向けて、一人に一機能がアサインされて、並行して作るという方針でした。テーブル構成とか共通の部分に関してはチームで相談して決めましたが、機能の設計・実装に関してはほぼ一人で作り切りました。 自分はユーザ登録の機能を担当していました。 Goを触るのは初めてで、技術的に難しかったですけど、面白い仕事でしたね。

だいぶ「独り立ち」という感じですね。

ですね。大変だったこととして、一ヶ月とか集中して作った後に、事業責任者の人に見せたら「微妙だね」みたいな反応をもらっちゃったことがあります。 フィードバックとしては実際納得できるもので、ユーザの使いやすさとかを考えると確かにそうだな、という部分があったので、大幅に作り直すことになりました。

oh、それはなかなか大変ですな…。 メンタル的にもきたんじゃないですか？

はい。だいぶ凹みました。 naoyaさんは結構メンタルケアをしてくれて、凹んだときに「休め」って言ってくれたり、そうじゃないときもちょくちょく状況を気にかけてくれるのがありがたかったですね。

事業責任者の方とは大体プロジェクトマネージャ（PM）を介して会話をしていたのですが、そのPMさんの存在がかなり大きかったと思いますね。 ビジネスサイドの問題があったらすぐ開発チームに噛み砕いて共有してくれますし、人間的にも信頼できているので心理的な安心感もあります。

こういう時ってビジネス vs テクノロジーみたいな構図になりがちですけど、PMさんが挟まることで三者の関係になって、意思疎通がしやすかったと思います。

最近はどういう開発をしてますか？ 何か技術的に面白いこととか。

最近やったのは、LINEのメッセージ送信に失敗したときにリトライする機構と、それに伴う送信の非同期化ですね。

既存プロダクトのチームにいた時から問題意識はあったんですけど、他の開発作業で使っていた技術を応用できるんじゃないかと思ってやってみました。

おお、それはすごい。 自分で発案してやった感じ？

そうですね。新規プロダクトが運用に乗ったタイミングで、手を挙げてみました。 実装する前にフローチャートを見せて意見もらったりとか、こまめに状況を共有することを意識して開発しました。

ひっくり返された経験が生きている感じがしますね！

ですね。その上で、次に同じような問題意識をもった開発者がでてきたときのために、詰まったところと解決策についてブログを書き、記録を残しました。

※サノさんのブログはこちら

エンペイの育成環境について、どう思いますか？

エンペイに入って「育ててもらった」というよりは「育つ環境の中で一緒に仕事をさせてもらった」という印象が大きいですね。

その中で仕事を任せてもらってやっていくうちに、だんだんやりたいことも見えてきて、手を挙げたら実際にやらせてもらえる。 「期待されて動く」ことと「自分で動く」ことの両輪があるのが、自分の成長にとって良かったと感じます。

具体的にどういう能力が伸びたと感じますか？

自分で要件や仕様を考える中で、将来を見据えてシステムの構造を考える能力は伸びたかな、と思います。 発覚する前にバグる可能性に気づけたり、先回りしてリファクタリングのタスクを立てたりとかですね。 その上で、いろんな視点を入れることの大切さにも気づくことができました。

ありがとうございます。人を巻き込むのは大事だよね。 それを踏まえて、今後どういうエンジニアになりたい、とかありますか？

仕事しているうちに「システムを掌握したい」という欲求を自分の中に発見しました。システムを掌握すれば、不具合の少ない設計とかを考えられるようになると思いますし、他の開発者にタスクを渡すのもやりやすくなって、より大規模な開発ができるようになる、というのもあります。 なので、システムの設計段階にどんどん絡んでいくエンジニアになりたいですね。

なるほど。「依頼する」ことそのもののスキルというのもあるし、そのスキルを伸ばしていくためにはある程度システムを掌握していないとチャレンジもしにくい、という感じですかね。

はい。あと、この記事のタイトルにもつながってきますが「ジュニアエンジニア」と評価されている状況を抜けたい、という健全な焦りもあります。 もうすぐエンペイに入って2年になりますし、キャリアやポジション的にもレベルアップしていきたいです。 そのためにも、「システムを掌握する」というのは鍵になってくると思っています。

少し抽象的な質問になるんですが、サノさんにとって「開発」とはなんですか？

「仕事」ですかね。 やっぱりお金が発生するからやっているという面が大きいです。 趣味でコードを書くこともあるんですけど、突き詰めるためには仕事じゃないときついかな、という感触があります。

なるほど。 自分のモチベーションの源泉がちゃんと認識できてるのはすごいですね。

やっぱり、自分の性質として「これを理解しないとシステムが壊れる」とか「業務に影響が出る」という意識があると、よく動けるところがありますね。

ありがとうございました！これで書けそう！