この記事は 食べログ Advent Calendar 2025 の3日目の記事です🎅🎄
「要件定義書、確認しました。これじゃ作れません」 「え、なんとかこのまま進められない？」
エンジニアなら一度は経験したことがあるであろう、この不毛なやり取り。 かつての私も、「要件を決めるのは企画の仕事、それを作るのがエンジニアの仕事」と明確に線を引き、ボールを投げ合っているだけの時期がありました。
こんにちは、食べログカンパニー飲食店プロダクト開発部予約業務基盤チームの @redpine です。 この記事は 食べログ Advent Calendar 2025 の3日目の記事です。
現在は実装や詳細設計の手を離れ、システムの全体設計や、企画チームとの要件定義・調整をメインの役割としています。 この役割を担うようになったのはここ1年ほどで、それまでは「決まった要件に対して、どう実装するか」に向き合う日々を送っていました。
以前はそのように「作る側の論理」だけで考えていた私ですが、ある苦い経験をきっかけにその線を踏み越えてみたところ、エンジニアとしての価値が大きく変わりました。 今回は、実体験から学んだ「企画と対等に渡り合うための『一歩踏み込むスキル』」について書きたいと思います。
1. 企画者がエンジニアの指摘をわかってくれない
ことの発端は、ある新規プロジェクトの要件定義フェーズでした。 渡された仕様書に目を通した瞬間、私は頭を抱えました。そこに書かれていたのは「正常系」の記述ばかり。「エラー時はどう振る舞う？」「イレギュラーなデータが来たら？」といった、システムが現実世界で動くために必要な記述がごっそりと抜け落ちていたのです。
私はすぐに差し戻しを提案しました。 それは決して、重箱の隅をつつきたかったわけでも、仕事をサボりたかったわけでもありません。むしろ逆です。
「このまま走り出せば、後で必ず手戻りが発生する」
そう痛感していたからです。運用で苦しまない「綺麗なシステム」を作りたいのはもちろんですが、何より今回のタイトなスケジュールを守り切るためには、今ここで仕様を固め、後続フェーズでの迷いをなくすことが「急がば回れ」の最短ルートだと信じていたからです。
「リリースのために、今ここで詰めさせてください」
エンジニアとしての責任感からそう訴えた私に対し、返ってきたのはあまりに冷ややかな反応でした。
「OKです。ただ、一旦今ある情報で開発進められないですか？ いつ開発完了できそうですか？」
言葉を失いました。 こちらの「プロジェクトを成功させたい」という意図は完全に無視され、相手の関心は「いつリリースできるのか」という一点のみ。 私の提案は、彼らにとって「スケジュールの遅延行為」としか映らなかったのです。
「ああ、言葉が通じない」
リリースという同じゴールを見ているはずなのに、決定的に何かが乖離している。 「後で困るのは自分たちなのに」という無力感と、何を言っても響かない徒労感。その瞬間、私の心の中でプツンと何かが切れました。
「もういい、言われた通りに作ろう。なんとか終わらせて、早くこのプロジェクトから解放されたい」
そんな投げやりな感情が、エンジニアとしての矜持を塗りつぶしてしまったのです。
2. なぜ伝わらないのか
作業を進めながら、「なぜこの危機感が伝わらないのか」を考え続けました。その答えとなる失敗談があります。
当時、「事前決済システム」の導入プロジェクトで、外部の決済基盤を使って返金を行う機能を開発しました。 しかし、このシステムの運用中に課題が見つかり、こちらからの返金リクエストを受け取った後も「受け取っていない」かのような挙動をしたり、リクエストは受け付けたものの、いつまで経ってもステータスが「返金中」のまま止まってしまい、完了したのか失敗したのか結果が返ってこない状態が頻発していました。
私は企画に対してこう主張しました。
「本来、返金結果の担保は外部システム側が持つべき役割です。食べログ側で尻拭いをするのは設計として正しくないので、先方に改善要望を出してください」
エンジニアとしては当然の主張です。しかし、企画側の反応は鈍く、事態は大きく動きませんでした。 結果、不整合が起きるたびにエンジニアが手動で調査・対応するという運用が残り、現状に至ります。
なぜ伝わらなかったのか。それは、私が「本来この機能は外部システムが担保すべき」という、「システム的な責務」を軸に会話をしてしまっていたからです。
3. 企画とエンジニアのギャップを埋める「業務軸」
しかし、この問題の本質は「責務の切り分け」ではありませんでした。 本当の地獄は、「月初の売上精算」のタイミングで訪れます。
返金状態にズレがあると、食べログ側と決済システム側で金額が合わなくなります。その結果、月初の締め日に経理担当者とエンジニアが総出でデータを突き合わせ、バタバタと数字を合わせる作業が発生していたのです。
ここで私は、交渉の「軸」を変えるべきだったと気づきました。
「システム軸」ではなく「業務・事業軸」で伝える
エンジニアが「システム的な責務として正しくない」「手動対応が面倒」と訴えても、企画（ビジネス）にとっては「優先度：低」になりがちです。 しかし、これを「業務（オペレーション）のリスク」として伝えていたらどうだったでしょうか。
| 軸 | 伝え方 | 企画側の反応 |
|---|---|---|
| Bad (システム軸) |
「外部システムが結果を返さないのは責務を果たしていません。 設計として美しくないので改善要望を出しましょう」 |
「相手もあることだし、今はなんとか回ってるから後でいいや」 （優先度：低） |
| Good (業務・事業軸) |
「現状のままだと、月初の売上精算時に金額ズレが発生し、経理部門を含めて対応に追われます。 決算処理が遅れるリスクがありますが、それでも手動対応を続けますか？」 |
「それはマズい、経理にも迷惑がかかるし会社の信用問題だ」 （優先度：高） |
このように伝えていれば、企画側も「それはマズい、経理にも迷惑がかかるし会社の信用問題だ」と、自分ごととして優先度を上げられたはずです。
エンジニアがコードや設計の美しさだけでなく、「そのシステム不備が、月次の重要業務（精算）にどう影響するか」まで視野を広げていれば、結果は違ったものになったでしょう。
4. 選択肢には「軸」を持たせる
この経験から、私は企画に提案する際、「何を優先するか」という軸で選択肢を作るようになりました。 例えば以下のようなの三案です。
- 案A（システム都合）： 工数最小。その代わり、異常系は現場の手動フローでカバーする（運用リスクあり）。
- 案B（企画要望）： 要望を100%叶える。その代わり、工数は倍になり投入するリソースが増える。
- 案C（折衷案）： 主要機能は満たしつつ、仕組みを簡略化して工数を抑える。
このようにいくつかの判断軸を提示することで、企画側も「今回はスピード優先だからA」「ここは経理業務を止められないからB」と、ビジネス判断として要件を選べるようになります。
5. まとめ
冒頭で触れた「要件は企画、実装はエンジニア」という線引き。 結論を言えば、この線引きをしていた私自身のスタンスこそが、不毛なやり取りの原因でした。
企画がわかってくれないのではなく、エンジニアである私が「技術」の枠に閉じこもり、相手の「事業・業務」という評価軸へ歩み寄る努力を怠っていたのです。
「作るのが仕事」という線引きを捨てる
コードを書くことは手段に過ぎず、目的は「事業・業務を成立させること」です。
「システム軸 vs 事業軸」で戦わず、自分から歩み寄る
エンジニアこそ「業務軸（オペレーション）」に詳しくなり、そこを共通言語にして交渉する。
もし今、企画からの要件にモヤモヤしている方がいたら、コードや設計書から一度顔を上げて、その先にある「現場の業務」を見てみてください。そこにはきっと、現状を打開するヒントが落ちているはずです。
明日は @osawa-yoshinori の「食べログアプリのXcode 26/iOS 26対応 〜実例集〜」です。お楽しみに!
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
