新卒入社から5年、自分が失敗から学んだ4つの「大切なこと」

新卒でSpeeeに入社後、いくつかのプロジェクトへの参画を経て、今は新卒エンジニアの育成に関わりながら、新規SaaSプロダクトの開発とテックリードを担っています。

小中学生の頃は、科目で言うと図画工作や美術が一番好きでした。その流れでなにか動くものを作りたいと思い、中学生の頃にプログラミングを始めました。大学の就職イベントでSpeeeを知り、いい意味でキラキラしすぎない社風と、Speee で働く方々の「内なる熱さ」を感じて入社しました。それから5年間、様々なことがありました。ここでは、新卒入社後の5年間、失敗を経て気づいた「エンジニアとして大切なこと」についてお話ししようと思います。

意気揚々と始めた新規事業で、理想状態を追い求めた結果――大幅なプロジェクト遅延。作ることに集中しすぎたことで、コミュニケーションが不足して「本当に必要なもの」が何かを見失い、ひたすら増えていく機能と複雑になっていくコードと格闘する日々が待っていました。理想を描き、良いコードを書くことに全力を出すことがエンジニアの仕事だと考えていた私にとっては、大きな挫折でした。この失敗から、私は4つの学びを得ることになります。

1.「本当に必要なものはなにか」を考える

当時、ものを作ることに集中するあまり、「理想状態」だけが先行して「本当に必要なものは何か」を考えられていませんでした。開発初期は、ユーザーからのフィードバックを得られないため、プロダクトの検証ができません。エンドユーザーに価値があるどうかもわからないまま、机上の空論に等しい大きな理想状態を掲げて走った結果、価値あるものを生み出す、という本来の目的から外れてしまいました。

2.ビジネスとの関わりを持ち、こまめに軌道修正を行う

先ほども伝えた通り、私もプロダクトチームは慢性的なコミュニケーション不足でした。これも、作ることにのみ集中しすぎてしまったための失敗です。エンジニア同士だけではなくビジネスチームとも関わりを持ち、さまざまな人と話し合いをして、問題が発生した場合の素早い軌道修正が大切だと学びました。

3.短期的な目線にならず、長期的な価値を生み出すプロダクトを考える

「技術を使うことそのものが楽しい」というタイプの私は、できることから考えてシステムの理想形を大きく広げてしまいました。たしかに新しいものを生み出すのは、それだけで楽しいことです。しかし、「それは本当に必要？」「目的はどんなものだった？」ということを常に考えないといけないことを学びました。短期的な開発の楽しさだけをとって、長期的なプロダクトの価値を犠牲にするのは避けるべきだと痛感しました。

4.常に現状に疑問を持つ

誰が使うプロダクトか、本当に必要な機能なのかをエンジニアも常に考える必要があります。ビジネスサイドのメンバーが技術のことに詳しくない以上、技術に責任を持つのはエンジニアです。要件よりも前に作る目的からビジネスメンバーと分け隔てなく日々コミュニケーションをとっていないと、建設的な指摘や議論が生まれないですし、互いの関心領域について知ることもできません。日々のコミュニケーションの中から生まれる疑問を見逃して、自分のなかで収めてはいけないことを学びました。

エンジニアとして、技術を追い求めたり、良いコードを書くことは大切な役割です。ただ、それだけでは駄目です。良いものを作りたいと思うからこそ、事業や組織を理解し、ものづくりを立体的に捉えることも、技術と等しく大切です。

「理想」を追い求めた結果、本当に必要なものを見失い、ひたすら増えていく機能と複雑になっていくコードと格闘するのは辛いことばかりでした。そこから立ち直れたきっかけは、、少し先の未来について考えたことだったと思います。ビジネスメンバーから「こういう目的でこういう機能がほしい」、「プロダクトをこんな風にしていきたい」と相談を受けるなかで、考えが切り替わったんだと思っています。誰のために、何のために、を見失ったまま作り続けるのは苦しみの連続でした。メンバーとのコミュニケーションの中で、目的を正しい方向に再設定できたからこそ、立ち直ることができたのだと思います。

理想を描きすぎないこと、「作ること」のみにフォーカスせずコミュニケーションを取ること、プロダクトの目的を考えて疑問を持つこと。この失敗から様々なことを学びました。事業の構造、プロダクトとユーザーの関わり、そしてユーザーに対してどんな価値をどうやって届けるのか。それらを常に考えなければ、技術力があっても使い方を間違えてしまいます。技術についても、技術そのものの機能だけではなく、その技術がどういうチームや組織において有効かを見極めることも大事です。

Speeeには「結果責任」と「実行責任」という用語があります。エンジニアに置き換えて考えると「結果責任」は、プロジェクトを達成させる責任のこと（例えば、リリース日までに一定の機能水準を満たすこと）。一方、「実行責任」は、設計やリファクタリングなど目には見えないが、長期的な価値のために日常的に積み重ねていくべきことです。

エンドユーザーに長期的な価値を届け続けるには、結果責任だけではなく、実行責任がとても大事です。例えば、変化する事業にコードも追従していかないと、遅かれ早かれ技術負債となり、普段の機能開発のスピードを落としてしまうからです。

これは事業観点での実行責任の大切さですが、こうした日々の積み重ねを作れないことは、自分のようなエンジニアにとって楽しくはないですし、もったいないと思っています。こんなコードの書き方があるんだとか、こうすれば簡潔でメンテナンスしやすいクラス設計になるんだとか、そういう試行錯誤の時間があるからこそ、自分やチームの学びの機会になるし、それが回り回って事業の資産になると信じています。

一時期、前述の失敗からの反動で、期日に厳密にコミットし、ひたすらリリースし続けるような極端なやりかたに振ったこともありましたが、今となってみれば、残ったコードを見ても、当時のチームの状態を見ても、明らかにいいやりかたではなかったと思います。

「とにかくリリースをすればいい」あるいは「とにかくきれいなコードを書けばいい」そんな両極端に振った単純な話ではありません。期日のような制約を守りながら（あるいは必要に応じて見直しながら）、リファクタリングや設計にかける力加減を見極めながら、結果責任と実行責任を両立する必要があります。加えて、そうした微妙な力加減をエンジニアだけで議論するのではなく、ビジネスメンバーも巻き込んで話すことがエンジニアとしての、私としての責任だと考えています。

理想のエンジニアとは、「難しい要求に対して、最善の解を導き出し、応えられる」エンジニアです。入社当時のメンターだった先輩がそのようなことを言っていたのを覚えています。これを聞いてかっこいいと思ったし、私自身そうなりたいと思いました。

ただ、最善の解は、私一人だけで見つけられるものではないと思っています。知識も限られています。すぐに見つけられるものでもないと思います。常に事業は動き続けるので、最善も動きます。だからこそ、常にビジネスメンバーと話しながら、現状と理想について目線を合わせて、一緒に未来（短期も中長期も）について語り合うことが大事です。

最近は、「難しい要求に対して、最善の解を導き出し、応えられる」ができるエンジニアを増やしたいとも思っています。結局、私一人で書けるコードは限られているからです。そのために、プロダクトの初期開発からしっかり設計を固めていくことや、その設計方針を背景を含めてチームで目線を合わせることをやっていたりしています。そうした地盤固めが後々の開発で生きていきますし、手本となるコードが増えることにもなるので、他のエンジニアにとっても学びの種になります。ドキュメント化に関するいいベストプラクティスがあれば、他のプロダクトチームに広めることもあります。

こう考えていくと理想のエンジニアになるには、やはり外へとつながっていく必要があります。

「作ることが好き。美しいものを作りたい。」というきっかけでプログラミングをはじめましたが、それ自体は今もぶれていないと思います。ただ、それは入社当時の自己完結的な美しいものではなく、自分の外にきっちり繋がっている美しいものを作りたいと、思うようになりました。そうして作られた美しいプロダクトが外につながっていく、そしてそれが誰かの役に立つ、そういう楽しさや美しい部分を多くの人と共有したいと思っています。

外につながっていきたいからこそ、事業のことやユーザのことを知っていないといけないし、もちろん技術を学び続ける必要がある。それらバランス良く丁寧に練り上げた美しいものを、多くの人を巻き込みながら追求し続けたいと思います。