【BEST TEAM賞インタビュー】

はい。コードを書く、レビューをするのは私含めチーム全員共通の業務として行っていますが、私はさらにチーム内のスクラムマスターのような役割も持っています。具体的には以下の内容です。

”新規事業の成長をシステム面からリードしていく”ということがチームのミッションとしてあって、その中でも実際に機能の開発や改善がメイン業務です。

Wさんはチームの中でもシニアエンジニアのような立ち位置を担ってくださっていて、
開発やコードレビューの他にもシステム設計の領域まで力を発揮しています。例えば新規事業プロダクトの1つであるAdictorのページスピードの改善なども自分で調べてどうやって解決するかまで考えて実行してくださっていました。

一番苦労したのはOPTIOのタグなどを配信するシステムに使っていた言語やフレームワークですかね。それほど経験がないものだったので、キャッチアップするのに苦労しました。

僕がチームに配属されたのが新卒研修終了後の7月頃だったので、上期の中でいうと後半からの参戦となりました。
業務としては主にOPTIOのリファクタリングを行っています。開発がどんどん進むにあたり中の実装がますます複雑になっていたため、長期的な視点で開発スピードを落とさないようにコードを整理していました。

はい。フロントエンドのWeb画面側を扱うところが未着手の状態だったので、フロントエンドのリファクタリングを中心に担当しました。

そうですね。僕自身、学生時代の経験でも確かにリファクタリングを怠っていると、開発が遅れてしまったりしていたので、やっぱりそういったところの整備は大事だなと思います。

正直僕は後半から参戦したこともあり、僕以上に先輩であるお二方の力があったから受賞できたのではないかと思っています。お二人は忙しい中でも数多くの開発をする合間を縫って僕のコードをレビューしていただいたり、ビジネスサイドとコミュニケーションをとって課題解決に向けて迅速に対応していたりして、すごいなと感じていました。

でも岡さんは今年新卒として入社したとは思えないほどキャッチアップが早いですよ！もう一人前のエンジニアとして活躍されています。

ありがとうございます。まだまだ至らない点もありますので、精進していきます！

実は自分としてはもっと積極的にサポートに入っていかないといけなかったと反省しています。ですが岡さんはそこまで手厚くフォローしなくとも充分一人で進めていただけたというのはありまして。元々お持ちの実力でカバーして頂いたような感覚です。

岡さんは問題の解決がしっかりできるエンジニアだと思います。

複数のプロダクト開発を並行して進めていくということが既に大変だったと思うのですが、それを着実にメンバーが進めてこれたというのは、リムさんがチームやタスクをまとめていくのがすごい上手だと思っていて。それが結構受賞理由の中でも大きかったんじゃないかなと自分は思ってます。

そんなことないですよ！至らない点もあって、タスクを小さく見積もってお任せしたら結果的に大きなタスクになってしまうことも何回か発生していました。岡さんにお願いしたタスクも、2日で完了すると思っていたものが2週間かかるものだったということもありましたね。もし良いと思ってくれていた部分があったら、その部分だけ学んで欲しいですね（笑）

優先順位と期待の管理ですね。プロダクトオーナーの期待を管理するのはもちろんですが、それだけではなく自分に対する期待を管理することも大事です。これはちょっと大変でした。

例えば、時間が限られている中でチームとして達成できることは頂く要望の多さに対して少ないと考えると、自分たちがどれだけできるかという期待管理をする必要があるんです。できる限り多く達成したい想いはあるのですが、やはり優先順位をちゃんと立てて優先度の高いことから解決していくことが大事でした。

そうですね。基本的には自分ができることよりも他者からの期待の方が大きくなりがちだと考えています。ただやはり自分の能力や時間にはどうしても限りがあり、この限界点とはちゃんと向き合わないと結果的にストレスがかかりパフォーマンスが下がってしまうと思っています。やりたいこととできることの限界があることの葛藤の中で挑戦していくことは、今振り返ってみると大変だったのかなと思いますね。

受賞理由を説明するにあたり孟子のいい言葉がちょうどいいので、それを使って説明しますね。

私は上の3つの重要度の高い順に並べた時に、人和>地利>天時だと考えています。たとえどんなチャンスを与えられても、チームメンバーの力が足りなかったり努力する姿勢がないと、今回の受賞には繋がらなかったはずです。

コードレビューしてもらうときのマナーやどこにコミットを意識すべきかという細かい感覚は、入社後に学んだことになるのかなと思います。

そうですね。例えばコードを修正するときに、依頼されたところとはあまり関係ないところには手を加えないようにしています。
具体的には、ユーザーページのパフォーマンスを上げてくださいという依頼があったとして、ユーザーページではないトップページやランディングページのコードがすごい気になったとしてもついでに直してはいけないということです。そこを修正した状態も含めコードレビューをすると、ただでさえ忙しい中でレビューの工数が増えてしまいますし、全く関係ないコードに工数をかけていた場合には開発スピードにも遅れが生じてしまいます。

あとは一度にまとめてレビュー依頼をするのではなく小さく分けて細かく依頼をするのもマナーですね。例えば求められている機能があってそれが3段階に分割できるものだとした場合に、タスク期限内で全て完了させることができなくても、求められる最低限の2つについては実装できましたとなれば、この2つを先に本番環境に導入することができます。

そうですね。1回きりにしてしまうと、100点に到達しなかった時に何もできなかったということになってしまうので、保険という意味でもやる価値があると思います。

実はレビューするときってソースコードのどこをどう変えたかというのが一覧で出てくるのすが、そこが段階ごとに分割してあると順を追って理解しやすいですね。やはり小さい段階で早めに依頼を出してもらうと、方向性の修正がききやすいというメリットもあります。

もし1ヶ月間かかるタスクを最後の日までコードレビューがないまま進めたとすると、最後の日に方向性自体が間違っていることが分かったら1ヶ月が丸ごと無駄になってしまいますからね。それを防ぐための工夫をしています。

技術の面では、コードを書いたり最近の動向を追ったりするのはもともと趣味のようなもので生活の一部になっているので、感覚の違和感はありませんでした。一方で、子供が生まれたことによる生活スタイルの変化に適応して、仕事を両立することには難しさを感じました。

仕事との両立については妻の力も大きいですね。在宅勤務が多く調整が効きやすいのもあり、うまくやっていけています。ちょっと抜けて育児をするみたいなこともしやすいですし、あとは単純に通勤時間が片道1時間だったら往復で2時間なくなる計算なので、時間にも余裕ができやすいですね。

新規事業ということもあり、制約が少ない中で選択した技術スタックの上で開発を行えることが一番の面白みだと思います。自分は途中から参加したので技術選定には関わっていないですが、担当者が設計時に最良を考えて選定したモダンなスタックを実際に業務として触れていく中で、新しい技術の実践的な知見を得ることが多くありました。

今後はユースケースに応じて、最適な技術の選択やアイデアを率先して出せるようなエンジニアになりたいです。またエンジニアだけでなく、ビジネス職の方も巻き込んでプロジェクトを計画・推進できるようになりたいです！

ちょっと抽象的なのですが、新規事業の成長によりフォーカスしていきたいですね。単に技術力を提供するだけじゃなくて、それをやることによってユーザーにとってどれくらい良いことがあるのかとか、事業全体を見ながら動いていけるようになりたいです。

まず楽しむことを続けていきたいです。楽しむことができなかったら新規事業を扱うチームとしてはあまりよくないのではと思っています。あとはWさんと岡さんに対しては、将来に自分のチームを持てるエンジニアになってほしいという個人的な野望もあります。

まさにスモールチームだからこそ求められることではないかと思います！