概要
こんにちは Speee エンジニアの中嶋（@nyamadorim）です。
これまで社内の Wiki に、仕事の内容に関する振り返り記事を年単位で書いてきました。これらの記事を改めて振り返ると、個別具体の技術的なこと（例: オブジェクト指向設計）より、仕事や対人コミュニケーションの仕方のほうが収穫が多く、仕事で成果を出す上ではこうした学びこそ大切にする必要があると思いました。
この記事では、新卒 5 年目の私が、仕事の仕方や対人コミュニケーションにおいて学んだことを 3 つに絞って紹介したいと思います。これから紹介するものは、具体的なプラクティスというより、感じてきたことベースでつらつらと書いているのであしからずご了承ください。
対象読者
- 過去の自分に向けて
- これから入ってくる新卒エンジニアに向けて
- ジュニアエンジニアに向けて
新卒当時の筆者のスペック
- 17 新卒でイエウールの開発チームに配属。小さい開発チームの中で自分でできることを見つけながら、小さいタスクをこなし、イエウールのシステムをキャッチアップ
- リーダブルコード、クラス設計への強いこだわりなどがエンジニアから一定評価されていた
- 技術に多少自信はあったが、仕事の仕方、チーム開発での振る舞い方は全然身についていなかった
当時と今のギャップ
当時思っていたこと
何でも技術で殴ればええやろと思っていました。例えば、（今思えばオレオレな）Ruby のメタプログラミングやクラス設計を駆使して、より短くコードを書く、より柔軟な設計を目指すなどです。そういう技術的な知識が、エンジニアにとって最も大事であり、それを活かす仕事の仕方をしたいと思っていました。まあとにかくコードが書きたかったわけです。
当時に対して今思っていること
今思えば、何でも技術で殴るのは常に正しいやり方ではなかったと思います。それに、メタプログラミングやクラス設計のような個別具体のエンジニアリングの知識よりも、仕事やコミュニケーションの仕方のほうが圧倒的に学びとしては大きかったですし、仕事で成果を出す上ではむしろ最も重要な点でした。
これは技術がいらないというわけではなく、技術のバックグラウンドにあるもの（今動いているシステムやそれを作った人との向き合い方や、技術の使い方など）についても欠かせなかったという気づきです。そうした気付きによって、技術だけに偏らず、人・チームへの向き合い方を考えながら仕事をしないといけないし、むしろそうしたいと思うようになりました。コードを書くことがだけがエンジニアの仕事ではないのです。
この記事では、そうした学びの中から特に大事に思ったものを 3 つ紹介します。
大切だと思った 3 つのポイント
これまでに作られたシステムと作った人をリスペクトする
入社当時のイエウールのアプリケーション構成は、非常にカオスでした。PHP で書かれたアプリケーションが徐々に Rails にリプレイスされていったものの、実装の各所に PHP 時代の名残が残っていたり、アプリケーションが複数に細かく分かれているなど、あまり Rails っぽくない構成でした。
当時の私は、そうした経緯を知っている先輩エンジニアが近くにいるのに、自分の感覚で、ここのコードが分かりづらいとか、きれいじゃないとか、そういうことをよくぼやいていたように思います。具体的に誰かにフィードバックするというか、単にぼやくみたいな感じです。
ぼやき自体は、ある観点においては正しい意見だったと思います。直すべき場所もあったと思います。しかしそれでも、そうしたアプリケーションが事実として間違いなく利益を生んでいるわけですし、当時の状況や思想を汲み取らず、これまで作られてきたものをただ貶したりすることは良くないです。
幸い、そういう私に対して、360 度評価でフィードバックをしてくれたり、周囲のエンジニアが注意してくれたりして、自分の悪い癖に気をつけるようになりました。これまでに作られたシステムや作ったエンジニアをリスペクトした上で、文句をいうぐらいならそれを原動力に私が直そうと思うようになりました。
それから数年後、自分の過去のまずい仕事に行き当たるようになりました。当時の自分としては最善だと思っていたが、今振り返ると微妙だったこともあります。能力不足を悔いることもありましたが、だからといって当時の私に悪意はなく、最善を尽くしたはずです。自分も含め誰でも、悪意なく微妙なコードを書いたり、微妙な行動をしてしまうものです。善意を仮定することで、相手に優しくなれるし自分も楽になれることに気づきました（どうすれば、もっとよくできたかは振り返りたいですが）。
直感で突っ走らない
「文句を言うぐらいなら私が直そう」という思いはあったものの、この設計でいけると直感的で突っ走って、リファクタリングしたり、大きなスキーマ変更をして痛い目にあったこともありました。例えば、直感にしたがってしばらく突き進んだが、課題だと思っていたことが実は課題ではなかったことや、筋の良いソリューションではなかったことにあとになって気づくようなことです。突き進んでしまったからこそ、ここまでの作業を捨てる意思決定ができず、もやもやしながら作業をし続ける経験もありました。
そうした作業のすべてが無駄だったわけではありませんし、学びもあったと思います。しかし、直感で突っ走る前に少し時間をかけて調査をすれば、直感の間違いに気づき、正しい方向に軌道修正できたかもしれません。もやもやした思いをすることもなかったでしょう。
このことに気づいてから、当初は半年かかると言われた PJ でも、事実を整理しながら方針を決めていくことで、実はもっと短期間で終わると自信を持って見立てることができるようになりました。
振り返れば、自分が関わっていなかった PJ でも、直感で突っ走って痛い目にあったケースが過去にあったように思います。直感に従ってえいやで意思決定することは楽ではありますが、それが大きなプロジェクトの場合は茨の道です。既存実装の調査のような地道な作業は、コードを書くのに比べて楽しくないように見えるため避けてしまいがちですが、そういう作業を避けずにきっちり取り組んだほうが結果的にはうまくいくのではないか、そう思うようになりました。
強調しておくと、失敗がいけないわけではありません。失敗は常に歓迎です。しかし、ちょっと調べるだけで気付ける失敗なら早めに気づいたほうが絶対にいい、それだけのことです。
みんな違って、みんないい
チームを持つようになって、考え方ややり方が違う相手とぶつかるようになりました。知らず知らずのうちに、自分の考え方を押し付けていたりもしました。開発環境の好みはそれぞれなのに、モブプロ本に書かれた内容をここでも直感にしたがってそのまま採用し、単一 PC、単一エディタで開発させてチームメンバーにしんどい思いをさせたこともありました（モブプロ本のやりかたは極端であることも理解しました）。
考えがぶつかる相手だったとしても、腹を割ってちゃんと話せば、同じ目的・目標を持って仕事をしていることがほとんどです*1。むしろ、相手の意見のほうが現実的だったり、優れていたりすることも多々ありました。
私の性格上、自分が考える理想的なやり方を押し付けてしまうことがよくあり、その性格にハマって失敗することもありますが、そうしたバイアスにはまらないよう、色んなタイプの人がチームにいたほうが良いと思うようになったし、チームを持つことで自分だけではできない仕事があることにも気づきました。いろんな考えの人がチームにいる中で自分と違う考えに遭遇すると、防御的になってしまうことがありますが、そうした気づきを得てから、別に自分を否定しているわけではないのだと、落ち着いて相手に向き合えるようになったと思います。
チームを持つ中で、活躍の仕方は人それぞれという気づきもありました。私のように難しいプロジェクトをまるっと任されることで燃える人もいれば、近くで働く方の感謝をベースに輝くエンジニアもいます。私には私なりの、彼らは彼らなりの活躍の仕方があります。育成においては、自分のパターンに当てはめるのではなく、その方なりの活躍の仕方を見極めて、育成する必要があると強く思うようになりました。事業のミッション・ビジョンやカルチャーに対して合ってさえいれば、みんな違ってみんないいのです。
ここまで記事を書いて思ったこと
同じ会社に長くいないと気づけないことがある
もしもっと早く転職していれば、自分の過去の仕事に直面して自分でハマったり、誰かがハマったりして、自分の過去の仕事を振り返る機会はなかったでしょう。無理して同じ会社に居続けるべきではないですが、同じ会社に長くいるメリットはこういうところにあると思います。過去に時間を戻して、仕事をやり直せるわけではありませんが、少なくとも過去の歴史を振り返って、次に活かすことはできます。
社内 Wiki へのアウトプット大事
曲りなりにでも、自分の考えや仕事の振り返りを言語化し、社内 Wiki に投稿したり、分報に自分の考えをつらつら書いていったことによって、自分の経験が整理され、学びに変わったのだと思っています。内向的な性格で表立った発言が苦手でも、社内の Wiki なら考えを自分のペースでテキストにまとめることができます。知らない人からまさかりが飛んでくることもありません。
こうした執筆作業は、業務上の成果とすぐには結びつかないため、どうしても時間を取って書くのを遠慮しがちですが、後で思い出して書くのは難しいので、時間を取ってでもなるべく早めに書いたほうがいいです。完璧でなくても社内の Wiki にとりあえず出して書き溜めていけば、雑であっても自分のポートフォリオとして残ります（そして、社外に向けて発信できれば最高です）。
私が今考えるリードエンジニアの役割
当時のメンターや上司との 1on1 からの率直なフィードバックがなければ、こういう気付きは得られなかったと思いますが、それ以上に大きな気づきを得られたのは、リードエンジニアとしてチームを持つようになってからでした。
私はこれまで、自分の想定通りになるようメンバーに考えを押し付けたり（特にジュニアエンジニアだと思っている相手に対して）、衝突を避けて考えを引っ込めたり（特に自分により経験のあるエンジニアに対して、あるいは一度衝突したエンジニアに対して）、この両軸の間でこれまでゆらゆらと揺れてきましたが、その両端に正解はありません。本当に必要なのは、チームメンバーがジュニアもシニアも関係なく平等に意見を交わせるようにし、ときにチーム外のエンジニアを巻き込みながら、正しい方向にチームを向けるようなチームの触媒になることだと思います。直感で突っ走るチームを止めて、少し考える時間や調べる時間を作ることも必要でしょう。その上で、責任を持って意思決定しより大きな成果に向けて前にすすめることが、チームワークにおけるリードエンジニアの役割だと考えています。
結び
この記事では、仕事の仕方や対人コミュニケーションにおいて学んだ以下の 3 つのポイントについて紹介しました。
- これまでに作られたシステムと作った人をリスペクトする
- 直感で突っ走らない
- みんな違って、みんないい
これらは少なくとも私にとって、個別具体の技術的な学びより多くの収穫があり、かつ仕事で成果を出す上で重要でした。
私を含めエンジニアは、その界隈で流通量の多い具体的な技術プラクティスばかりに目が行きがちですが、技術のバックグラウンドにいる人やチームに目を向けることも大事です。コードを書くことだけがエンジニアの仕事ではないのです。
*1:エンジニア同士だけではなく、上司、PdM、他部署の方々に対してもそうです
