【アドエビスのうらが「わ」】ACM開発ヒストリー～第10話 9ヶ月かけるはずだった開発期間をなぜ短縮したのか～

弊社の新サービス「AD EBiS Campaign Manager」が、2025年5月に正式リリースとなりました。
構想から約3年、リリースに至るまでのストーリーを公開することでプロダクトへの愛を感じていただき、そして製品開発を行う皆様の参考になればと思い全15話をお届けします。

岩田──制約は削ぎ落とすためにある

2023年7月。初期バージョンの企画案には、9ヶ月先のリリースが想定されていました。
その資料を見たとき、私は直感的に「長すぎる」と感じました。
このタイミングで、私は一つの判断を下します。社員総会が予定されている10月上旬までに、プロダクトをかたちにしてほしい、と。与えられた時間は3ヶ月もありませんでした。

これまで私は「慌てることはない」「しっかりと顧客の課題を検証してほしい」と伝えてきました。それが今回、短期での開発を求めたことに、違和感を覚えた人もいたかもしれません。
けれども、私自身の考えは一貫していました。急がせることが目的ではなく、「削ぎ落とすための制約」を意図的に課したのです。

スタートアップであれば、限られた資金やリソースの中で、最も重要な機能に集中せざるを得ません。対して、社内の新規事業は、そうした切迫感が生まれにくい。特に、既存事業を支えてきたメンバーに、急にスタートアップ的なスピードや緊張感を求めるのは酷でもあります。
だからこそ、経営としてあらかじめ制限を設け、その中で本質的な判断が促される環境を整える必要があると考えました。

吉本──スコープを絞る、決意と不安のあいだで

まず「このままの機能では、到底間に合わない」と感じました。
そこでプロジェクト全体のスコープを大きく見直すことにしました。顧客ジョブに立ち返り、ユーザーストーリーを再定義。機能で何を残し、何を一度脇に置くべきかを、チームで一つひとつ判断していきました。

ここで取り入れたのが、MVP（Minimum Viable Product）という考え方です。
MVPを設定し、最小限の機能でサービスを構築し、市場に投入することで、顧客からのフィードバックを早期に得る事が可能になります。これにより、開発の時間とコストを削減し、失敗のリスクを低減しながら、市場適合性の高いサービスへと成長させることができます。

“完璧を目指すよりも、最小限のプロダクトをできるだけ早く顧客の手に届けることを最優先する。最短でフィードバックを得る事が、結果的に早くプロダクトが育つ。”
その方針をチームと共有すると、自然と整理の動きが始まりました。

スコープを削ったことで、本当にユーザーが受け入れてくれるのか。
自分たちが絞り込んだ“最小限”は、本当に“核”になっているのか──。
迷いは、常に頭の中にありました。チーム内でも、時に判断に詰まる場面があり、決して滑らかに進んだわけではありません。それでも進むしかない。そう思えたのは、時間が有限であることが、逆に迷いを断ち切ってくれたからかもしれません。

土肥──重圧の中で、それでも前を向く

3ヶ月もない期間での実装。仕様は流動的。設計変更が何度も重なり、開発メンバーの疲労感は日ごとに積み重なっていきました。

「MVP」とは言いつつも、その言葉の定義が曖昧なまま進んでいたことも、土肥を悩ませた一因でした。「本当にこれは最小限なのか？」「あとから不要だと言われるのではないか？」──その疑念を抱えながらコードを書き続けるのは、決して軽い負荷ではありません。
当時はまだchatGPTのような支援ツールもなく、すべてが手作業。にもかかわらず、納期は動かない。カスタムレポート機能のように、当初はMVPに必要だとされたものが、後に削除されるという逆転もあった。

「これは本当に今やるべきなのか？」
そう問いながらも、手を止めることはありませんでした。
社員総会というマイルストーンに向けて、やり切るしかなかった。メンバーは誰ひとりとして弱音を吐かず、それぞれが自分の役割を果たし続けたのです。
当時、岩田さんが意図していた「制約を通じて削ぎ落とす」という考えが、開発チームにまで明確に伝わっていたわけではありません。
けれど、MCMという新しい概念をできるだけ早く世の中に出したい──その空気は、確かに現場にも伝わっていたように思います。

岩田──機能を削るという決断

ここまで絞り込んだ初期バージョンで、コア機能として搭載していた「カスタムレポート」は、後のアップデートのなかで削除される判断が下されました。
設計にも時間と手間をかけた機能でしたが、ユーザーの利用実態やプロダクト全体の進化を踏まえて、優先度を見直した結果、「いまは必要ない」と判断されました。
もし9ヶ月の計画通りに開発を進めていたとしたら──私たちはさらに多くの機能を“当然必要なもの”として積み上げていたかもしれません。そして、それらを後から削るという決断には、もっと大きな苦労とコストが伴っていたはずです。

吉本──はじまりを共有できた手応え

社員総会当日。会場にはこれまで関わってこなかった社員も集まり、静かな緊張感が漂っていました。
企画開始から1年。まだ粗削りではあるけれど、初期バージョンをなんとか形にして、社員の前でお披露目できました。
「これ、早くお客様に届けられるようにしたいですね」──発表後、現場のメンバーからそんな前向きな声が聞こえてきたとき、内心少し安堵しました。

それまで何度も迷い、何度も削り、手探りでここまでたどり着いたプロダクト。それを前向きに受け止めてくれる空気が、確かにありました。完成ではなかったけれど、ようやく“はじまり”のスタートラインに立てた、そんな実感がありました。
この制約によって、メンバーには大きな負荷がかかったと思います。判断のスピード、機能の絞り込み、曖昧な仕様の中での決断──日々の積み重ねは、簡単なものではありませんでした。
それでも結果的に、当初想定していた9ヶ月の開発期間を大幅に短縮し、1年足らずでプロダクトの原型を社内に提示できたことは大きな意味を持ちました。

そして、このスピード感は、プロダクトベースで顧客の声を直接ヒアリングし、開発に反映していく次のフェーズへとつながっていきます。

---

次回予告｜第11話 最後のピースがはまった日

9ヶ月を3ヶ月に圧縮して生まれた初期バージョン。
社員総会での発表を経て、プロダクトは「見える形」になった。
けれど、そこで終わりではなかった。
企画・実績の登録は進んでも、「次の打ち手」が生まれてこない──。
そんな静かな行き詰まりの中、吉本たちは“ある欠落”を痛感する。
一方、研究開発チームもまた、焦りと模索を抱えていた。
「データから意味を引き出す」ために、何が必要なのか。
その問いに、生成AIという選択肢が浮かび上がる。
やがて両者は交差する。
プロダクトと研究開発、それぞれの詰まりが、ひとつのピースとなって重なったとき、 長く探し続けた“答え”が、ようやくかたちになり始める──。

---

アドエビスに対するフィードバック、ご意見などはこちらよりご記入ください。

ご意見・ご要望フォーム