はじめに
こんにちは。最近まで新規事業の開発エンジニアとしてプロジェクトに携わっていた者です。
「やったるで！」の精神でバリバリ開発に没頭した結果、かなり痛い目を見ました。この経験が誰かの役に立てばと思い、備忘録として記事に残します。
ちなみに、この記事で言う「エンジニア」とは、事業会社で働くエンジニアをイメージしています。あくまで私の経験に基づく主観ですので、ポエムとして酒のつまみにでも読んでいただけると嬉しいです。
結論：私が犯したたった一つの過ち
まず結論から言うと、私は「プロダクトを終わらせないこと」に対する当事者意識が欠けていました。
新規事業プロジェクトで技術的な完成度ばかりに目を向け、そのプロダクトが事業としてどうすれば生き残り、成長していけるのかを考えなかった。その結果、プロジェクトは停止し、費やした時間と努力が文字通り水の泡となったのです。
失敗の構造を振り返る
1. 組織的な問題：不在だった「プロダクトの羅針盤」
私が携わった新規事業では、事業チームは営業に特化しており、エンジニアリングを理解する人がいませんでした。そのため、開発チーム内でPM（プロジェクトマネージャー）を立てざるを得ない状況でした。
PM兼開発者となった私は、スケジュール管理のような「プロジェクトマネジメント」はしていました。しかし、「プロダクトマネジメント」の視点が完全に欠落していたのです。
- そもそも、このプロダクトは何のために存在するのか？
- 事業として継続していくために、本当に必要な機能は何か？
- 誰の、どんな課題を解決するのか？
こうした本質的な問いを立て、事業チームと対話し、プロダクトの舵を取る役割が不在でした。
2. 個人的な問題：線引きしていた「自分の仕事」
当時の私は、PM業務も未知の技術領域も初めての経験で、日々のタスクをこなすだけで手一杯でした。視野は狭まり、事業のことを考える余裕も、意識もありませんでした。
上司に「プロダクトオーナー的な立場が不在で、責任の所在が不明です」と訴えることはありました。しかし、返ってくるのは「そうだよね、検討しなきゃね」という言葉だけ。私も「報告はした」と、それ以上踏み込むことをしませんでした。
正直に告白すると、心のどこかで「誰かがやってくれるだろう」「最終的な売上責任は僕の仕事じゃない」と線を引いていたのです。
転機となった、同僚からの痛い一言
そんな私にとって転機となったのが、他のチームのリーダー（経験豊富なエンジニア）から投げかけられた、この一言でした。
「今君がやってるその開発って、本当に売れると思ってるの？」
何も考えていなかった私は、言葉に詰まりました。その場では正直、腹が立ちました。しかし今振り返れば、これこそが「なぜやるのか？」という、私が目を背けていた最も重要な問いだったのです。
その後の1年間
この一言をきっかけに、私は約1年間、事業側に問い続けました。「このプロダクトは、本当にマーケットに受け入れられるんでしたっけ？」と。
事業側からは「確かに…」という反応はあっても、具体的な方針は決まらない。ピボットもできず、時間だけが過ぎていきました。それでも私は、問い続けることしかできませんでした。
悲しい結末と、たった一つの気づき
そんな中、会社のフェーズ変化に伴い、新規事業へのリソース投下が困難になりました。「何のためにやるのか」という未来が見えないプロダクトから、事業側のキーマンが次々と去っていき、最終的にプロジェクトは停止しました。
「自分の頑張った時間、あの努力は一体何だったんだろう」
この強烈な虚しさの中で、私は一つの重要な事実に気づきました。
エンジニアは、コードや機能という「What（何を）」や「How（どう作るか）」に集中しがちです。しかし、それが「Why（なぜ作るのか）」に結びつかなければ、全ての努力は意味をなさなくなる。
言い換えれば、エンジニアには「プロダクトを終わらせないこと」に責任を持つ姿勢が必要だ、ということです。これこそが、エンジニアが事業に対して持つべき責任なのだと、今は考えています。
なぜエンジニアも事業に責任を持つべきなのか
私たちが書くコードは、それ単体で価値を生むわけではありません。そのコードが解決する課題、届ける価値、そしてユーザーの体験。これらすべてが一体となって、初めて価値が生まれます。
技術的にどれだけ優れたものを作っても、事業として失敗すれば、自分自身の仕事の価値も失われる。逆に言えば、事業の成功にコミットすることで、自分の技術的な努力が最大限に活かされ、本質的なやりがいに繋がるのです。
【実践編】私が「変わるため」に始めたこと
「じゃあ具体的に何をしているのか？」という点についても、現在の取り組みを共有します。
時間配分とマインドセット
現在は、週40時間のうち2〜3時間を、意識的に「事業を理解するための時間」に充てています。
重要なのは、これを一人でやらず、チームメンバーと一緒に行うことです。仕事は一人ではできません。そして、「事業理解」という言葉の定義や解像度は、エンジニア間でも意外と異なります。これは対話して初めて気づいたことでした。
なので、すぐに結論を出そうとせず、半年くらいかけるつもりで、根気強くチームで取り組んでいます。
具体的な段階的アプローチ
また取り組みの全体像として、いきなり壮大な目標を立てるのではなく、ステップを踏んで進めようと考えています。
Step 1：ライトな入り口『疑問点を聞く会』 (←いまここ)
まずは週に1回、チームで「エンジニアの事業貢献ってなんだっけ？」「この機能って、誰がどう嬉しいんだっけ？」「この仕様の背景にある事業的な狙いは何だろう？」といった素朴な疑問を出し合い、議論する会を設けるようにしています。
Step 2：本格的な取り組み『イベントストーミング』
チームの事業への関心が高まってきたら、次はイベントストーミングの導入を計画しています。これは、開発者だけでなく、事業側のドメインエキスパートも巻き込むワークショップです。業務プロセスの全体像を可視化し、チーム全員のコンテキストを揃えるのが狙いです。
Step 3：未来の構想『AS-IS / TO-BE分析』
事業や業務への理解が深まったら、現状（AS-IS）とあるべき姿（TO-BE）をエンジニア視点で議論したいと考えています。プロダクトが長く価値を提供し続けるために、全体最適を考慮した技術的な提案ができるチームになるのが目標です。
あなた自身への問いかけ
ここまで読んでくださった皆さんに、改めて問いたいと思います。
- あなたが今開発しているプロダクトは、誰のどんな課題を解決していますか？
- そのプロダクトが届けたい、本質的な価値は何ですか？
- そのプロダクトを「終わらせない」ために、エンジニアとしてあなたに何ができますか？
もし、これらの問いにすぐに答えられないなら、まずは週に数時間、チームで「疑問点を聞く会」から始めてみることをお勧めします。
おわりに
技術的な完成度の追求は、エンジニアとして当然持つべきプロ意識です。その楽しさは、これからも大切に育てていくべきものです。
しかし、それと同じくらい、自分の技術がどう事業に貢献し、価値を生むのかを自分ごととして捉えること。これこそが、変化の激しい時代でも仕事の意味を見失わず、長く働く上での充実感やインパクトに繋がるのだと、私は失敗から学びました。
この記事が、同じように悩む誰かの助けになれば、そして悲しい経験をするエンジニアが一人でも減ることを、心から願っています。