※この記事は、2025 Speee Advent Calendar6日目の記事です。
昨日の記事はこちら
はじめに
挨拶と現在の業務内容について
皆さんこんにちは。株式会社Speeeに25卒で入社いたしました、エンジニアの白戸と申します。社内では「ユリタニ」のあだ名で呼ばれています。
4月に入社してから私は弊社の運営する不動産一括査定サイト「イエウール」の開発に携わっております。具体的には、イエウールのユーザ様に向けたUI実装や、ご参画いただいている企業様に向けた新規機能などの実装を行っています。
この記事で伝えたいこと
この記事を通じて皆さんにお伝えしたいことは、「エンジニアが技術だけでなくユーザ価値とビジネス的成果に対して主体的に立場をとる環境があること」「Speeeでは新卒エンジニアがその環境での学びをすぐに実践する成長環境が用意されていること」です。それぞれについて、私の入社前後での学びを軸にお伝えしたいと思います。
Speee入社のきっかけ: ユーザ価値と事業成果を軸にした文化
私がSpeeeに入社した理由は、社員同士がユーザへの価値提供に対し共通の認識を持ちつつ、互いを尊重して成果を上げようとする文化に共感したからです。
学生プロジェクトで学んだユーザ価値の重要性
私は学生の頃の開発プロジェクトの経験から、ユーザ価値を軸にして開発を行うことを重要視していました。私の出身大学では「プロジェクト学習」と呼ばれる科目があり、1年間かけて他大学と連携してモバイルアプリケーションを開発し、企業へのプレゼンを行いました。求められるクオリティに対して時間的制約が厳しいプロジェクトでしたので、「アプリが提供する機能は、新規性があり、価値のあるものに集中する」という姿勢を取り、メンバーと議論を交わしたうえで、コア機能は実装して実演まですることができました。
価値提供のための連携を学んだインターン
Speeeとの出会いは、大学院に入学してすぐの逆求人イベントでした。上記の価値提供に対する価値観が合致し、当時の12daysインターンへ参加することとなりました。そのインターンでは、3人のチームでビジネス的な目標やKPIを開発要件に落とし込み、新規プロダクトを開発するという内容のワークに取り組みましたが、前述のプロジェクトよりも時間的、人的制約が厳しいものでした。ビジネス的な要求に対する認識が合わずチームで軋轢が生じましたが、私は実装する機能の価値と目的をすり合わせることは継続して行いました。
インターン中にメンターの社員の皆さんを見ていて感じたことは、エンジニア、ビジネス職関係なく、活発なコミュニケーションができていることでした。また、メンターや人事の方々からは私が行ったチームで目線を合わせる姿勢を評価してくださいました。ほかの企業のインターンにも参加していましたが、この社風が決め手となり、内定をいただき入社することとなりました。
入社して感じた学生と社会人の開発の違い
技術起点ではなく価値提供起点の発想が必要
入社後に感じた学生時代との違いは、開発プロセスが「技術を使ってどうやって作るか」ではなく「どんな価値を提供し、その価値によってどんな成果を残すか」という発想を起点に進められていることでした。学生時代は、自分自身が技術を学び習得することや、モノを作る楽しさを味わうことがモチベーションになるため、どうしても「どういう技術を使うか、どういうアーキテクチャを採用するか、どうコードを書くか」ということが議論の中心になりがちでした。ですが、社会人では技術に対してある程度見識があることは前提として、その技術の使い方がユーザへの価値や事業にどう跳ね返ってくるかを主眼におく必要があります。
学生時代からユーザ価値は大切ということを自覚はしていましたが、実際の業務では「何ヶ月後にどれくらいの収益を見込むのか」「今これをやらなければ事業に対してどれくらいリスクがあるのか」というより具体的な目標が設定されています。この目標に沿うように開発の機能要件が決定されていくため、実装する機能の仕様も時にはかなり複雑、かつ具体的になります。加えて、期日が明確に決められているため、1日もしくは1週間、1ヶ月の行動計画でどこまでを達成するかという実行計画と戦略にも具体性が求められます。
計画と振り返りの機会が多い
Speeeの組織体制で最も効果的で価値のある取り組みが、チームと個人での計画と振り返りです。1週間、1ヶ月、半期といった節目ごとに、チーム・個人でそれまでの成果の振り返りと、次の開発における取り組み方の見直しをします。「目標と自分の達成した成果との差分はどれくらい生じたのか」「うまくいかなかった要因、うまくいった要因は何か」を徹底的に言語化し、「次にアクションを取る時にはどう工夫を加えるか」を話し合います。ここでのポイントは、うまく行った・いかなかった要因を個人だけに帰結させるのではなく、組織全体で成果を残すために本人と周りがどのように動けば良いかという仕組みを考えていることです。そのため、振り返りは2者ではなく3者以上で行うことが多いです。
意思決定過程の綿密さが必要
学生のうちは、とにかく技術を学ぶこと、動くモノを作ることが正義、という価値観の下で開発を行うことが多く、作った後のことはあまり考えることはありませんでした。しかし、業務での開発では、実装したアーキテクチャによって変更が難しくなり、ビジネス的な施策展開が遅くならないか、ということや、実装がわかりやすく開発メンバーが変わったとしても継続して保守をしていける構造であるか、といったことが重要になります。つまり、事業としての機動力と持続可能性を維持し続けるために「このコードで今後事業に支障が出ないか」という目線によるコードの保守性・変更容易性が重要視されます。
開発への向き合い方を変えた、2つの悔しい経験
入社してからの6か月間で、私の開発に対する価値観を学生時代から変えた出来事は2つあります。
成果につながらなかった施策の悔しさ
1つ目は、せっかく苦労して実装した施策が世の中に出ても成果につながるとは限らないことを実感した悔しさです。いくつかのプロジェクトでは、私が慣れていない技術を用いつつも、ビジネスサイドの方との連携を綿密に行ったうえで時間をかけてデプロイした成果物がありました。一つはユーザ様向けの新機能、もう一つはイエウールにご参画いただいている企業様向けの機能でしたが、成果としてあまり結びつきませんでした。社会人での開発は学生のころとは違い、売り上げ、ユーザ体験の改善、もしくは組織の中長期的な生産性の向上といった特定の成果や狙いを達成することが求められます。自己満足で済ませられません。結局ビジネスサイドの方と私の苦労は何だったのか、私が何かもっと主体的な働きかけをしていれば変えられたのかもしれないと思う反省点もありました。
要件の認識齟齬による手戻りと遅延
2つ目は、必要な要件の洗い出しが十分でないまま開発を進め、手戻りや遅延を起こしてしまったことに対する反省です。イエウールのご参画企業様向けの機能で、一部要件定義からリリースまで担当したプロジェクトがありました。そのプロジェクトでは、動く画面上の機能はすべて実装し終わり、完璧になったかのように思えましたが、裏方で使う社内での分析用の機能に関する考慮が漏れており、手戻りが発生してしまったことがありました。ほかの施策でも、ビジネスサイドの方の要件をうまく理解することができず、何度も手戻りを発生させてしまった施策もありました。のちの振り返りで出た反省点は、要件定義や設計の段階で、ビジネスサイドの方とのコミュニケーションが「何を実装すればいいか」という表層的なものであった点、そして開発物に必要とされる要件とは何なのか、その施策の目的とは何なのかといった根本的理解や、その認識をビジネスサイドの方本人とすり合わせることができなかったという点でした。
8ヶ月間で得た、エンジニアとして重要な3つの価値観
こういった経験から得られた学びは3つあります。
①脱・御用聞き: 施策の実現に結びつく主体的アクションを取ること
1つ目の学びは、開発に対する要件は決められたものではなく、エンジニアが主体的立場をとることでより良い方法を見いだせるということです。
Speeeには大切にする15のカルチャーというものがあり、その一つに「脱・受け身」というものがあります。与えられた仕事をこなすのではなく、自ら責任領域を広げることで高い成果を得られるという価値観です。
エンジニアは自分が書いたコードによって成果が生まれるため、何の技術を使ってどう実装するか、という思考にはまりがちです。しかし、本当の成果とはそのコードがユーザにどのように使われ、それを使ったユーザが私たちのサービスにどう価値を感じてくれるかに結び付いているのです。したがって、自分が実現する開発が本当に価値を生むものかどうかを考えなければなりません。
こう書くと、「ビジネス的な成功を担保するのはビジネスサイドの役割ではないか」と思うかもしれません。確かに、ビジネスサイドの方々の仕事は、ビジネス的成果を残す戦略を考えることです。しかし、ビジネスサイドの方々は技術の専門家ではないため、自分たちの戦略をどんな開発物で実現するのが最適かは知らないのです。そのため、最初にビジネスサイドの方々から示された仕様がエンジニア目線ではビジネス的に最適ではない、ということはたまに発生します。
Speeeカルチャーの「脱・受け身」をエンジニアが体現する機会は、このようなお互いの専門領域の間にある隙間に、エンジニア自身が染み出していくことで「この技術をこう使えば、ビジネス的な価値につながる」というアイデアでより良い解決方法を導き出すことだと考えています。
与えられた要件を額面通りに受け取るのではなく、自分の技術知識を用いることで「この施策は、要件をそのまま実現しなくても、過去施策の開発物を再利用すれば同じような成果が得られるな」とか「ここで表示するデータはちょっと形式を変えたほうがユーザ体験を変えずに工数が削減できるな」といった提案ができるようになります。
②過不足ないQCD達成：ビジネス要件に応じた最適なバランスを探ること
2つ目は、必要な成果水準を達成するために、施策の実現までに「必要な期日」と「品質水準」を過不足なく満たすことです。 私はこの中で「期日」を厳格に守ることが苦手でした。例えば、入社してからの半年は実装するUI要素のマージンや色味、画面遷移時の異常系を網羅した実装が必要かなど、細かいところを気にして期日感をおろそかにすることが多くありました。
ここでのポイントは、開発において細部の品質を守ることは必要なことですが、すべての施策において細部にこだわるべきではないということです。 同じサービスの開発でも、狙っているビジネス要件によっては細部の工夫を削ってでも期日の遵守を優先すべき場合があります。
品質を重視すべき状況となる例は、クライアント様の支払いや請求関連など、バグが発生した場合に影響範囲が大きい機能や、恒久的に使われることがわかっている機能です。逆に、期日を重視すべき状況となる例は、SEOによるサイトの順位向上を狙う施策など、正解がなく高速な仮説検証を必要とする機能などです。施策の性質によって、品質か、期日か、どちらを重要視するべきかというバランスが違います。
期日か品質かの正しいバランスを把握するには、ビジネスサイドの方との綿密なコミュニケーションが不可欠です。期日と品質に求められるバランスを知るには、施策本体が達成したいビジネス的な目標や、施策が一般ユーザ様やクライアント様にどのように使われるのかといったビジネス的な側面への理解が必要になってきます。そのような施策本体の戦略についてはビジネスサイドの方々が専門なので、自分から情報を取りにいかなければなりません。
ただし、ここで一つ注意しなければならないのは、前述した「御用聞き」にはならないよう気を付けるということです。ビジネスサイドの方々は、いろいろな気遣いからかエンジニア側に寄り添ったコミュニケーションをとってくれる場合があり、そのときに「こういう風に動く機能が欲しい」というように具体的な指示をくれることがあります。しかし、前述のとおりビジネスサイドの方々は開発物でどのようなことを実現したいかについては知っていますが、それを実現する最適な開発方法は知りません。この前提を踏まえずに「この機能のこの部分はどうしたらいいですか」とか「いつまでに実装を終えればいいですか」といった表層的な質問をし、ビジネスサイドの方の答えを額面通りに受け取ると、その言われた内容が絶対の要件であるかのように錯覚してしまいます。私たちエンジニアがビジネス的な戦略の立て方を知らないように、ビジネスサイドの方も機能の詳細や進め方について絶対的な正解を知っているわけではないのです。
いつまでに、何を開発するべきか決めるには、ビジネスサイドの方とのコミュニケーションと合意が必要です。まずはミーティングにおいてビジネスサイドの方の要求（要件ではない）をエンジニア側で言語化し、その実現方法をいくつかエンジニア側で提案します。ビジネスサイドの方から具体的な開発物の要件が示されている場合は、それを議論のたたき台にしてどれくらいの工数がかかるか明示し、その実現方法でビジネス的目標を達成するために問題になりそうなことがあれば意見します。「この施策で大事なのはここですよね?であればここの順番を変えたら開発すればもっと早くできますよ」とか「示していただいた案では工数的にこれくらい膨らみそうです。ここを省略すれば工数を縮めて同じようなことができませんか?」というような意見です。
③認識の開示とすり合わせ：プロジェクトを遅らせないための連携をとること
3つ目は、プロジェクトの達成方法に対する認識をステークホルダー間ですり合わせるために、認識を開示しあうことです。
密な連携が必要なプロジェクトでは、必ず当事者間の認識齟齬が発生します。上記のように、ビジネス的目標に対して期日・品質ともに過不足なく開発物を作るには、ビジネスサイドの方々を含めたステークホルダーの連携を密に行う必要がありますが、そのような連携においては、「この前のミーティングで私はこう伝えた、それに対してあなたはこう言っていたのだから、これくらいのことをしてくれるんだと思っていた」というような認識齟齬が発生します。
プロジェクトにおける認識齟齬は、開発物の価値が棄損されたり、手戻りによって遅延が起きたりするリスクになります。 ステークホルダー間で認識齟齬が発生すると、「相手にはこういうことをしてもらえるはず」というお互いへの期待がずれた状態になります。この期待のずれを解消しないままプロジェクトを進めると、いざ成果物ができたというときに、「ここが想定と違うから修正してください」という手戻りになります。そして、認識齟齬の根本原因を探って解消しないと、「修正しろと言われたから直します」という表層的な意思疎通が繰り返されてプロジェクトの遅延が起きたり、最後にできたものが想定と違って期日的にもう修正もできない、という事態を招きます。
このような認識齟齬を防ぐには、「どういう開発物が、なぜ期待されているのか」という内容をエンジニアが言語化して、なおかつその認識内容があっているかをビジネスサイドの方々と改めて確認する場が必要です。正直、この確認プロセスはややコミュニケーションのコストが大きいのですが、開発の要所要所でこのような場をコストを払ってでも設けたほうが、結果的にプロジェクトの遅延を防げる、ということがわかってきました。当然、開発物の事細かな仕様すべてを事前に確認しなければいけないわけではありません。しかし、定期的に大小さまざまな事柄について「ここはこれであってますか?」という確認を取ることで、お互いに対する認識の像のようなものがだんだんはっきりとしてきます。確認したら思ってたのと違ったということが多ければ、その差異を知ることで「なぜここはこうなるべきなのですか?」という根本的な考えから聞きに行くことでその際を埋められます。
Speeeにおける開発体制の良さ
Speeeに入社してよかったと思うことは、上記のような開発プロジェクトにおけるノウハウと学びの蓄積を支援する場があること、そしてその学びを新卒の段階から実践できることです。
定期的な振り返りによる個人・チーム両方へのフィードバック
前述のとおり、Speeeでは週ごと・月ごとに定期的な振り返りを個人・チーム両方の面で行います。その振り返りではマネージャーやシニアトレーナーの方が同席します。個人の学びについては経験のある方々からアドバイスをいただくことができます。チームでの振り返りでは、個人の行動をチームでの話題として取り上げ、問題を個人で完結させずにチーム全体の行動として改善する動きを取っています。このような振り返りを行うことによって、エンジニアが個人としても、チームとしても成長していけるような組織体制をとっています。
新卒エンジニアが直接他領域と主体的に連携できる裁量の広さ
加えて、エンジニアが得た学びは、新卒でもすぐに実践して次のプロジェクトに生かすことができます。イエウールのコアプロダクトチームでは、私のような新卒を含め全員がプロジェクトで直接ビジネスサイドの方々とミーティングを行い、互いの認識合わせやビジネス的目標を達成するための打ち手を一緒に考えることができます。Speeeの大切にするカルチャーには「他部署への尊重・感謝」があり、社内にそのカルチャーが浸透しています。そのため、ビジネスサイドの方々も新卒の私の言葉を真摯に聞いていただいています。最初から他領域との連携を主体的に行える組織体制があることで、開発に対して受け身にならず、他領域との主体的連携の重要さを身をもって学ぶことができます。
まとめ
私が入社した8ヶ月間は、今までの人生の中で一番学びと刺激の多い濃い8ヶ月間となりました。Speeeの開発組織では、このように「ユーザへの価値と事業成果」という共通の目標を共有し、エンジニアだけではなく、プランナー、デザイナーといったさまざまな領域の社員同士が綿密に連携する組織体制が取れています。この印象は、私がインターンをしていた頃から今まで変わることはありませんでした。この綿密な連携の中で、個人の技術だけではなくチームとしてプロジェクトを進めるための大小様々な学びがインプットとなっていると感じます。私はまだ技術的な知識もプロジェクトを推進する力も足りない部分が多いですが、ここまでの学びをあますところなく次に活かし、ユーザ価値と事業成果に貢献できるエンジニアとなれるようにこれからも頑張ります！
おわりに
Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています！
新卒の方はこちらより本選考に申し込みが可能です！
キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！
