デジタルプロダクト開発に終わりはあるのか？

こんにちは。Co-Liftのミドリです。

今日は「デジタルプロダクト開発に終わりはあるのか？」という話をしたいと思います。

最初に結論から言ってしまうと、「（ごく一部の例外を除いて）デジタルプロダクト開発に終わりはない」と考えています。

例えば、新しくパンのサブスクサービス（定期購入サービス）を立ち上げるとしましょう。

ビジネス要件として、最初に以下の要件を決めたとします。

＜最初に決めたビジネス要件＞
・月一回2,980円のサブスク（初回1,000円OFF）
・冷凍でお届け。食べる前にトースターで焼くだけで焼きたてのような美味しさのパン
・お届けするパンの種類は「おまかせ便」1つのみ
・ネイティブアプリ（スマホのAndroidアプリやi OSアプリ）は作らず、まずはウェブサービスで展開
・コードが書けないので、ウェブサイトはNoCodeツール（Shopifyなど）で作る

ちゃんとウェブサイトも作って、資金調達も完了し、いざ販売開始！！！

最初のうちは、新規顧客獲得のためのキャンペーン費用がかさみ、なかなか利益を出せなかったが、徐々に軌道に乗ってきた（としましょう）。

お客様からは、日々さまざまな要望や意見をいただき、そろそろ次の展開も考えたくなってきたとしたら・・・？例えば、選択できるプランの増強や、決済方法の拡充、ECモールとの連携をしたくなったら？

もしくは逆に、仮説通りにはいかず、方向転換を余儀なくされたら？

パンサブスクはパン好きな人をターゲットとしていたけど、そもそもパン好きな人って決まったお店で買うよりも、いろんなパン屋を巡って一番を探したいというニーズの方が強く、リピーターとして根付かなかった。

そんなこともあり得ますよね。そしたら、サブスクというサービスのコア部分から変えなければいけないかもしれないのです。

このように最初に描いていた仮説は、仮説でしかなく、思い通りに行かないことが大半です。例えば、マーケティング4PをPhaseに分けて真面目に考え出して、「Phase3のプロモーション費用はどうしようかしら…」とか「フードデリバリーの需要はあるのかしら…」とか色々考えてみたけど、先程の失敗例のようにProductの設定そのものが間違えていたら。

「あの時あんなに悩んでたのは何だったんかい！」ってなりますよね。

サービスを世に出すことは1つのマイルストーンではありますが、ゴールではないんですよね。いや、むしろ世に出してからのほうが大変なことの方が多い。

正解は誰にも分かりません。だからゴールも決められない（「年商XX千万円達成！」みたいなのはゴールではなく、マイルストーン）。どんなサービス／プロダクトであっても、計画通りに進められるようなことはまず皆無で、試行錯誤を繰り返しながら進めていくのです。

「終わりのない課題」＝「オープン・エンド」

さて、Co-Liftではこのような、事前に正解が分からず、あらかじめゴールを定義できないような終わりなき課題を「オープン・エンド」な課題と呼んでいます。

■Open-end（オープン・エンド）とは
プロダクト開発において、終わりのない課題をオープン・エンドと呼ぶ。オープン・エンドな課題に対する正解は、事業者にも顧客にも誰にも分からないため、事業者は仮説を顧客にぶつけながら改善を重ね、最適化を繰り返していくアプローチを取る。

オープン・エンドな課題に取り組むに当たって、まずやらなければならないのが仮説を立てることです。

例えば、先程のパンサブスクの例で言うと、「月額2,980円（≒1日100円）を払って、毎日美味しいパンを食べたいユーザーがたくさんいる」というのがサービス開始時の仮説です。

こうした仮説をもとに、プロダクトを作って市場に問い、その結果から仮説を検証していくサイクルを、何度も何度も繰り返すのです。

新規事業開発はすべてオープン・エンドであると捉えています。正解は事前に明確には判らないけれども、調査や分析を通して得られた仮説をもとに、いち早く市場にプロダクトを投入して、顧客にフィードバックを得ながら改善を続けていくことが重要です。

一方で、事前に正解が明確に定義でき、ゴールがあらかじめ設定できるような課題のことを「クローズド・エンド」としています。

もう少し詳しく紐解いていきましょう。

「クローズド・エンド」な課題とは

■Closed-end（クローズド・エンド）とは
プロダクト開発における課題の捉え方の一つ。企業のHPや基幹システムなど、事前に完成形がはっきりと分かっており、顧客の要件が大きく変化しないため、事前の緻密な計画立案が可能な場合を指す。
ゴールがはっきりとしているため、ゴールから逆算して納期通り・要件通りに完成出来るようアプローチしていく。

ちょうど良い例としては・・・

現在、Co-LiftのHP刷新に取り組んでいるのですが、
・作るべきものが事前にはっきりと定義出来る（概要とサービス紹介と問い合わせフォームなど）
・作るべきものを作ったら、その後は運用保守だけ
・作るべきものは大きく変化しない
という状況なので、これはクローズド・エンドな課題と言えます。

他にも、基幹業務システムや社内向けの業務システムなども、事前に正解（システムで実現したい業務）が定義しやすく、作った後で顧客の要求は大きく変化しにくいため、クローズド・エンドな課題と言えます。

課題によって、マッチする開発手法も違う

今日は、パンサブスクなどを例に、デジタルプロダクトの課題の捉え方についてお伝えしました。

実はこの課題の捉え方をきちんと理解しないと、ソフトウェア開発手法である「アジャイル」や「ウォーターフォール」についても誤解が生じることがあります。

次回はこの「アジャイル」と「ウォーターフォール」について、それぞれの違いなども含めてご説明したいと思います。

ちなみに、パンサブスクは立ち上げる予定はありません。パンは作る派ではなく、食べる派です。

以前パン焼き器を買い、レシピ通りに作ったのですが、「外は岩、中は消しゴム」というバケモノを生み出したことがあります。それ以来怖くてパンは焼いておりません。リアルにホコリ被ってますが、メーカーさんは悪くありません。

今日も読んでくださいまして、ありがとうございました！