新卒エンジニアが「開発だけ」をやめたとき、仕事は圧倒的に面白くなる

※この記事は、2024 Speee Advent Calendar14日目の記事です。昨日の記事はこちら

tech.speee.jp

はじめに

　こんにちは！2023卒で入社し、今はイエウールという自社サービスのWebサービスの開発をしている、木俣と申します。周囲からはきまっちゃんと呼ばれています！この記事が、「Speeeのエンジニアになると「開発」の他になにができるようになるか」知りたい方に届くと嬉しいです。

　突然ですが、Speeeでは、働くうえでの指針となる15のカルチャーが存在しています。

Speee Style - 株式会社Speee

　これは、Speeeメンバーが持つ共通の価値観であり、これを深く浸透させるため毎朝数人が自分なりのカルチャーの解釈と体現している人を発表します。ありがたいことに、仕事で関わった幾人かのチームのメンバーからこのカルチャー発表で、次のようなことを褒めていただけました。

期待＋α

期待されているレベルを超えた成果は、当事者意識によって創出され、成果者の成長を加速させる。私たちは、常に期待以上の価値を提供する意識を強く持っている

　実際にいただいた評価：「きまっちゃんは、開発物を待っているだけでなく、依頼者の視点では出せなかった細かい仕様の穴を埋める動きがあります。さらに、既存の機能を使った開発のショートカット方法や、開発の順番を工夫することで早くプロジェクトを成功させるアイデアなど、想定していた以上の情報を出してくれます。実際にプロジェクト成功のための会話を毎日のように重ねた結果、当初の見立てよりも早く成果を出すことができました」

Execution

プロフェッショナルは実行にこだわる。成否の分かれ道は、シンプルに完遂力に依存している

　実際にいただいた評価：「数値目標と差分がある中で、開発だけを行う存在ではなく、このままプロジェクトを進行させてよいのか質問をしたり、その数字を埋めるためにこういった策があるのではないかと提案してくれます。開発ではなく、プロジェクト成功を目的としているからこそ、意味のある実行ができています」

　このように、チームのメンバーから信頼を得られるようになったのですが、実は、１年ほど前まで私は、誰かが解釈したドキュメントをいわれるがままに開発するというスタンスでした。そんなカルチャーとは遠かった私ですが、先輩のアドバイスをもとに、目標との差分を常に意識する開発スタイルに変えた結果、チームから信頼されるようになり、仕事が圧倒的におもしろくなったので紹介させてください。

イエウールでの開発について

　本題に入る前に、今の私の開発環境について書かせていただきます。イエウールはサービス開始からすでに10年が経過しています。それだけ経てば、すでに開発の余地はないのではと思う方もいらっしゃるかと思います。しかし、そんなことはなく、10年間という重みを活かし、一つの施策で到底個人ではなし得ないような大きな価値を生み出し続けようと様々なチームが模索を続けています！そのため、私達のチームにも毎月開発しきれないのではと感じるほどの開発依頼が飛んで来ています。

　一方で10年間積み上げてきたコードはそれだけ複雑であり、誰かが書いたドキュメントを読んでその通りに開発しているだけだと、開発体験はどんどん悪くなって行きます。この状況から脱却するための工夫については、下記の記事がとても参考になります!

tech.speee.jp

変化のきっかけ

　1年ほど前、当時の私は先輩やマーケターに開発する意味の解釈をまかせ、その内容をいわれるがままに開発していました。言い換えると、いわれたものは開発できるものの、そこが限界という状態でした。そんな私でしたが、ありがたいことに環境が変わり今までよりも一歩難度の高いプロジェクトへアサインされました。そのプロジェクトは、一つ上の先輩を除くと新卒２年目のマーケターと私の若手二人が主導していました。さらに、そのプロジェクトは目指したいゴールがあるものの、ゴールに至るまでに何が必要なのか、さらには、ゴールに設定しているものが本当に正解なのかも分かっていません。当時の私は、到底そのプロジェクトを成功させることはできないだろうと考えていました。

　しかし、先輩からとあるアドバイスをもらったことで、プロジェクトを成功に収めることができ、さらに圧倒的に楽しく仕事ができるようになりました。そのアドバイスとは、チームで追っている目標と現状の差分を問いつづけるといった話です。未来のことがわからなくても、これから開発するものが正しそうかは現時点で判断できる。そういった考えのもとで

目標に対して作る機能は十分なのか？
十分でないなら、どうやって埋めるのか？
埋めるための行動は、いつまでに誰がやるのか？

これらのことを、マーケターの人と議論し続けるということです。このように、目標から逆算した議論を積み重ねていけば、最終的には、「目標に対して今日はこの機能を開発します！」と自信を持って言えるようになるという理論です。

成果を出すサイクルに入るために

　アドバイスをいただいたはいいものの、すぐに実践できるようにはなりません。MTGではできたと思っても、いざタイピングを始めたときに足りていなかった情報がいくつも浮かんできます。私の場合、ここで諦めないことが重要でした。
　話足りないと感じたら、すぐに会話が必要な相手のもとに直接出向き議論を続けます。この行動を繰り返していると、次第に目標そのものに対しても向きあえるようになり、最初はスケジュールと数字目標の差分でしか話していなかったことが、

「いまは、このサイトのこの機能を使うユーザーを増やしたいフェーズなんですね？その要求であればこっちのほうがもっと簡単に実現できそうです」
「一ヶ月後の目標はわかったのですがでは、一年後はどうなっていたいですか？」

といった感じで、上流の要件定義やプロジェクトの本質をついた話ができるようになりました。さらにプロジェクトを進めていく中で、チームメンバーと互いに信頼関係を築くことができ、チームメンバーからも

「こういった機能を付ければユーザーにとって便利だけど、どのくらいで開発できそう？」
「新たに、社内のオペレーションが煩雑になり破綻するリスクがでてきたから追加の機能を作れないか？」

といった相談をしてくれるようになり、チーム一丸で目的に向かって力を発揮できる環境を作ることができました。　

　こうして目標にこだわり続けることができるチームに変化していったことで、最終的には無理だろうと考えていたプロジェクトを成功させることができ、その成果は年に一回の全社表彰の場となる、総会でも認めてもらうことができました。今ではこの成功体験を基にさらに難度の高いプロジェクトにチャレンジするという成長のサイクルに入ることができたと考えています。