※この記事は、2025 Speee Advent Calendar17日目の記事です。 昨日の記事はこちら
こんにちは、SpeeeリフォームDX事業部に2025年新卒で入社したエンジニアの小町です。 普段はリフォームの会社探しサイト「ヌリカエ」などを運営する同事業部にて、ビジネスオペレーションを技術で改善する「BizOps開発」チームに所属しています。
今回は、私がBizOps開発でやらかしてしまった「言われた通りに作ったのに、現場では全く使えない仕様だった失敗談」と、そこから得られた学びをお話しします。
「要件通り完璧に実装したのに、解くべき課題のスコープを見誤ったために、全く使えないものを作ってしまった」
設計以前の、しかしエンジニアにとって最も重要な「課題定義」における失敗です。
前提：ビジネスの仕組み
最初に私が開発を担当していたサービスの仕組みについて説明します。
当時私が担当していたのは、事業部の新規領域として展開していた「みんなのリペア」というサービスです。これは住まいの修理を検討しているユーザーへ建物修理会社を紹介するサービスです。 みんなのリペアではユーザーを紹介した時点ではなく、加盟店がユーザーと実際に工事契約（成約）を結んだ時点で、初めて売上が発生する仕組みになっています。
フローが多いため、省略している部分が多いですが、基本的なフローは以下の通りです。
- 紹介： みんなのリペアがユーザーを加盟店に紹介する
- 成約： 加盟店がユーザーと工事契約を結ぶ
- 報告： 加盟店がみんなのリペアに「成約しました」と報告する
- 請求： その報告に基づき、みんなのリペアから加盟店へ手数料を請求する
今回の話は「3. 報告」の部分です。 ここが正確かつスピーディに回らないと、事業部の売上が計上できない（請求が漏れる）ことになります。つまり、ビジネスの根幹に関わる極めて重要なプロセスです。
実装：「言われた通り」の機能
当時の要件はシンプルでした。
要件：管理画面（Admin）に、成約金額を入力・保存するフォームを作ってほしい
「なるほど、今のDBには成約金額を保存するカラムがない。だからRailsの標準的なやり方で、入力画面と保存処理を作れば解決だ」
技術的な迷いはなく、実装もスムーズに進んでいました。
現実：コードは動くが、使えない
しかし、受入確認（動作確認）の段階で、現場から残酷なフィードバックが返ってきました。
「これ、今の業務フローじゃ使えません」
コードは正常に動いています。エラーも出ていません。 しかし、この機能は「現場の課題」を解決できていなかったのです。
なぜなら、私が作った仕様で運用するには、以下のフローが必要でした。
- 運営担当者が、加盟店に連絡を行う
- 「あの案件、いくらで成約しましたか？」とヒアリングする
- 聞いた金額を、運営担当者が管理画面に代理入力する
私は「データの入力（CRUD）」という機能要件しか見ておらず、そのデータを取得するための「情報の伝達コスト」や業務フロー自体を考慮できていませんでした。 多忙な運営チームにとって、この機能は「業務効率化」どころか、「連絡と入力作業」という新たなタスクを課すだけの代物だったのです。
分析：「解くべき問い」のズレ
この失敗を振り返ったとき、当初は「確認不足だった」「コミュニケーションが足りなかった」と反省していました。 しかし、エンジニアとしてより深く分析すると、本質的な原因は「解決したい課題（Issue）の定義」そのものにありました。
私が解いた課題と、本来解くべきだった課題には、致命的なスコープのズレがあったのです。
1. 私が解こうとしていた課題（Task）
- 課題定義： 「DBに成約金額を保存する場所がない」
- 解決策： 「運営担当者が入力できるフォーム（CRUD）を作る」
- 結果： 保存はできるようになった。しかし、ボトルネックである「アナログな情報伝達」は解消されなかった。
2. 本来解くべきだった課題（Issue）
- 課題定義： 「成約情報の取得コストが高く、リアルタイムに把握できていない」
- 解決策： 「情報の発生源（Source of Truth）である加盟店が、直接入力できる仕組みを作る」
- 結果： 運営の電話工数がゼロになり、データが即座に同期される。
これを図解したのが以下の画像です。
左側（Before）が、当初の私が見ていた世界です。「システムと運営の間」しか見ておらず、その手前にある「加盟店との電話連絡」という最大のコスト（波線部分）がスコープから漏れていました。これが「局所最適」の罠です。
右側（After）があるべき姿です。情報の発生源である加盟店から、直接システムへデータが流れる設計にすることで、運営の介在をなくし「全体最適」を実現しています。
解決：情報の「発生源」を押さえる
この「問いのズレ」に気づいた私は、コードを修正するのではなく、実際の業務フローの再確認と実装方針の修正を行いました。
具体的には、運営担当者が代理入力するのではなく、加盟店向けツール（Partnerツール）に「成約報告機能」を実装しました。 さらに、加盟店が報告を行うと同時に、Slackで運営担当者に通知が飛ぶ仕組みも構築しました。
- 加盟店： Partnerツールで金額を入力（情報の発生源が直接入力）
- システム： DBに即時保存
- 運営担当者： Slack通知で状況を把握（能動的なヒアリング不要）
これにより、「言われた通りの機能（代理入力フォーム）」ではなく、「本来あるべき情報の流れ」を実現するシステムへと生まれ変わりました。
学び：コードではなく「フロー」を書く
この経験から、私はエンジニアリングに対する姿勢を大きく変えました。
以前の私は、言われた要求・要件を「正解」だと信じ、それをいかに綺麗にコードに落とし込むかばかりを考えていました。 しかし、今の私はこう考えます。
「提示された要件は、課題解決のための『仮説』に過ぎない」
要件には「フォームが欲しい」と書かれていても、それが真の課題解決になるとは限りません。 「その機能によって、誰のどんな業務が減るのか？」 「情報の発生源はどこにあるのか？」
私たちBizOpsエンジニアの仕事は、プログラムを書くことではなく、 ビジネスオペレーションという巨大なシステムの、ボトルネックを解消することであり、時にはコードを書く範囲を超えて、業務フローそのものをリファクタリングする視点が必要なのだと痛感しました。
おわりに
「使えない機能」を作った悔しさは、私を「作業者」から「エンジニア」へと成長させてくれる貴重な糧となりました。 また、Speeeにおけるエンジニアの面白さは、技術力と業務理解を掛け合わせ、事業の成長を加速させることにあると改めて認識できました。
「言われた通り」を作るのではなく、ビジネスのあるべき姿を描き、技術でそれを実現する。そんなエンジニアになるための第一歩を、この失敗から踏み出せた気がします。
まだまだ道半ばですが、これからも事業にとって不可欠な存在になれるよう精進していきます！
さいごに、Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています！
新卒の方はこちらより本選考に申し込みが可能です！ キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！
