解放賞に必要だったエンジニアとしての成長

はじめに

こんにちは、キャディで原価計算システムのバックエンドエンジニアをやっている高橋と申します。

この記事は、CADDi Advent Calendar 2021の14日目にエントリーしています。

ありがたいことに、前Qに「解放賞」という社内賞を頂けまして、私もこの企画に参加させてもらうことになりました。解放賞の説明や受賞の経緯は、こちらの記事を是非ご参照下さい。
https://caddiinc.com/n/nb979dd7d80a5?gs=109443834838

そこでこの記事では、上記の記事に含まれていない話を書こうと思います。それは、私がWebエンジニアにキャリアチェンジしてから、初めてプロダクトの立ち上げを任せてもらえるようになるまでの話です（この仕事が上手くいったので受賞できました）。

私は今の仕事が初めてのWeb開発なので、そのような仕事を任せてもらえるようになれたことは、とても意義のあることです。そこで、そうなる過程で大事だったことや学んだことを振り返ってみます。最初に言っておくと、あまりまとまりはないのでご了承下さい。

初見の分野は薄く全体像をつかむ

キャリアチェンジした当初は、「何がわからないのかわからない」状態でした。この状況を上長に相談したところ、かの有名な「RubyOnRails チュートリアル」を勧められました。これは、コードを写経すると動くものが出来る教材で、Webシステムの基本を一通り学べるようにできています。全体像を掴んだことで、「どのあたりがわからないのかが何となく分かる」ようになりました。すると、段々自分で調べられるようになってきて、効率が上がったと思います。全体像を押さえに行くのは、その後も自習するときの基本スタンスになりました。

日々のレビューで信頼を貯める

ある日のこと、CTOに突然叱られました。嫌ですね。でも内容はこうです。「PRのレビューを1日溜めるってことはプロダクトの進捗止めてる自覚持って下さい。プロダクトの進捗になるのはマージされたコードであって、あなたが今書いてるコードじゃないので。」と。

ここでビシッと一喝してもらえて良かったと思います。基本的なことですし、何よりレビューをちゃんと見ることはエンジニアとしての信頼貯金になると思います（いつも真っ先にレビューのコメントをくれる同僚がいたら、自分のPRのレビュワーにしたいと思いますよね）。一概には言えませんが、こういう貯金があると仕事を任せてもらいやすいのかなと思います。

キャッチアップを発信する

キャリアチェンジしてからはWeb知識の独習をするようになりました。専用のSlackチャンネルを作ってもらって、そこに昼夜問わず勉強に関する呟きを投稿するようになりました。そのようにした理由は、当時の上長に「お前を助けてやりたいが、何で躓いているのか分からん」と言われたので、「じゃあ思考過程を全部公開してみよう」と思ったからです。社内の Webできる人に助けてもらえそう、という虫の良い目論見もありました。社外発信にしなかったのは、単純にSNSが好きでは無いからです。

この作戦は、当初の目論見通り技術的な助言を頂くことにも繋がりましたが、予想しない方向にも価値を発揮します。まず、日々学習の発信をすること自体が「あいつ頑張ってる」とプレゼンスの向上につながって、心理的に楽になりました（これが一番良かったことかもしれない）。それから、自分のスキルが見えやすくなって「こういう仕事を任せても良さそう」という話もちらほら聞けるようになりました。

ちなみに上記のチャンネルは僕が一通り呟いた後、新たなビギナーの方の学習のルートとして参考にされていたりします。エンジニアを目指す人が増えてくれるのは嬉しいですね。

業務で使って身につける

キャリアチェンジしてからは、とにかく仕事で直面するわからないことを調べては潰しの繰り返しでした。僕はわからない分野の本を買って読むことが多いのですが、本って読んでも大体忘れますよね？どんなに丁寧に読んでも、覚えているのは内容のごく一部だと思います。

実際のもので手を動かせば理解が深まって忘れなさそうだと思ったので、仕事でアウトプットすることにしました。そこで、「この本で勉強したので、勉強したことを使える仕事があれば下さい」とお願いしました。その結果、本で読んだことを実際に仕事に適用するときのギャップとかを体感できて、地に足付いた理解になったと思います。

目の前の仕事から広がっていく

私は今のチームで、主にコストロジックの実装に取り組んできました。コストロジックの実装を分かっている人が少ないこともあって、私は主にそこの開発をしていました。当時は視野が狭くて「とりあえず目の前の仕事はきっちりやろう」という感じでした。自分の作業に加えて他の開発者のヘルプや相談にのる他、分析チームに「このロジック変更はこう直したほうが良い」とFBもしていました。

そうすると次第に「あいつはコストロジックを全体的によく分かってる」という評判が立って、コストロジックの分析チームとの間に立って仕様調整したり、チームのプロダクトバックログリファインメントに参加するようになりました。すると必然的に、他のコンポーネントを含むチームの全体的な状況や、他のチームとの連携について意識するようになりました。目の前の仕事できちんと価値を出したことで、そこを軸足に自ずと仕事の範囲が広がっていったのです。

自分の意見を決める

ある日のこと、私はデータベースのマイグレーションを任命されます。これも嫌ですね（好きな人いますか？）。そもそもデータベースの扱いにも慣れていないので、自分の考えをほとんど信じることができていません。そんな中、上長から質問されてつい「経験がないのでわかりませんが、〜ですかね？」のような、あいまいな返答をしてしまいました。すると一喝。「そういう言い方はやめて下さい。責任逃れにしか聞こえません。間違っていてもいいので、ちゃんと判断して自分の意見を決めてくだい。僕はあなたの代わりに決断しません」

今思うと当たり前なのですが、自分で仕事を進めようと思ったら、自分で決められないと話になりません。決めることは勝手に突っ走ることとは別の話で、自分で決めた意見をチームにレビューしてもらえば良いわけです。プロダクトの立ち上げは意思決定の連続ですから、ここでちゃんと指摘されていなければ、自分に任せてもらえることは無かったと思います。

（おまけ）ダジャレを言う

「チームを楽しくする」心がけはあったほうが良いと思います。必須ではないものの、手っ取り早いのはダジャレです。不謹慎でない限り、あなたがスベれば周りは面白いので、技術も不要でお手軽です（ホントか？）。言いまくっていたら、気がつくと私のダジャレを発言する SlackBot が作られていて、チームを超えて広まっていました（これはホント）。

結局の所、チームがギスギスしていると全ての生産性が落ちます。本来は相談すべきところで相談をためらってしまったりとか、率直に問題点を話し合えないとか、そういうことがあるからです。

もちろん私は以上のようなことを考えながらダジャレを言ったことはありません。ですが結果として、今のチームは楽しいし、相談しやすいし、生産性が高いと思います。

さいごに

振り返ってみると、大事なところで適切な指摘やフィードバックをしてくれる方の存在が自分の成長には大きかったなと思います。

キャディのエンジニア組織は評価制度や1on1がしっかりしていてFBを受けやすいです。また、普段の業務中もメンバー同士で率直に話しやすい雰囲気があり、各々がチームで揉まれて成長できる良い環境だと思います。そういう環境の良さに共感してもらえる方がいれば、是非仲間として一緒に働けたらと思います。