0.導入

新規事業開発には、常に課題が山積みです。リソースや資金の確保、タイトなスケジュールなど、挙げればきりがありません。中でも、本日取り上げるのは「プロダクト開発」です。ノウハウがないまま手探りで開発を進めた結果、多額の費用がかかってしまった、というケースは珍しくありません。事業開発のキホン「プロダクト開発」を解説します。

講師は、株式会社東芝でエンジニア出身の連続社内起業家として、複数の新規事業を立ち上げ経験を持つAlphaDrive アクセラレーション・リードの金子祐紀が務めます。

1.「仮説検証プロセス」と「プロダクト開発」の両方を見ながら柔軟に進める

社内の新規事業プログラムの審査を通過し、新規事業の後半戦ともいうべき「アクセラレーションフェーズ（1→10）」までたどり着いた新規事業の起案チーム。これまでは簡単なプロトタイピングで検証を繰り返してきましたが、アクセラレーションフェーズになれば、スマートフォンアプリやクラウドサービスなど、プロダクト開発に本格的に取り組むことになります。

アクセラレーションフェーズにおけるプロダクト開発のポイントは、「ビジネス上の仮説検証プロセス」と、「実際のプロダクト開発」の両方を見ながら、柔軟に進めていくことに尽きます。細部まで仕様が決まっているものを忠実につくればよい「既存事業」とはまったく異なり、まだこの先、開発内容が大きく変わる可能性もあります。

例えば、実証実験で得られた顧客の声を反映して急遽機能を追加することになったり、競合の出現によって開発優先度が変更になったりと、戦略的にプロダクト開発に変更が生じることは珍しくありません。

反対に、時間や資金の面から機能の一部削減が必要になったり、想定していた性能を確保できなくなったりして、サービスの一部を人手で賄うようになるなど、開発の課題がビジネス戦略に影響を与えることもあります。

アクセラレーションフェーズに入ってもまだ、プロダクトもビジネスも不安定な状況は続きます。日々変化する状況にあわせて対応していく柔軟な姿勢が求められます。

2.「開発ベンダーのコントロール」が成否の鍵となる

プロダクト開発の重要なポイントが「開発ベンダーをどうコントロールするか」です。例えば「納品されたシステムにセキュリティ上の欠陥があり、顧客情報が流出してしまった」「想定外の追加コストが発生し、高額になった」「納期が遅れてリリースが半年遅れた」のような問題の多くは、ベンダーをしっかりとコントロールするによって防ぐことができます。

ここでひとつ例を紹介します。ある　新規事業のチームでは、下の図のようにベンダーへの依頼を行いました。

一見、新規事業チームは丁寧に依頼内容を伝えているようです。しかし、これでは全然足りていません。

というのも、「⚫︎⚫︎がほしい」のような「要件」は伝えていますが、優先順位や必要度、機能の閾値や振れの許容範囲といった「詳細」が抜けているからです。これでは、開発ベンダーのコントロールが効かず、ベンダーが“よしな”につくったシステムが上がってきてしまいます。

こうした依頼の結果、起こりがちなトラブルパターンがあります。代表的な6つをご紹介します。

3.ベンダーとのトラブルパターン①
必要以上に高額な見積りになる

１．要件が固まっていないために、ベンダー側は保険のためにバッファを積む

新規事業チームは、必ずしも「技術に詳しい人材」で構成されているわけではないため、開発の要件が曖昧だったり、固まっていなかったり、といったことも珍しくありません。

その状態で依頼を行うと、ベンダーは「依頼の内容なら500万円程度でできるが、要件が定まっておらす追加要件が出てきそうだから、多めに見積もりを出して対応出来るようにしておこう」と、変動に備えてバッファを取ります。その結果、見積りが高額になってしまうのです。

２．技術が分かるメンバーがおらず、高額であることに気づかない

さらに、技術に詳しい人材がチームにいない場合、見積りが高額になっていること自体に気づくことができません。もし開発の発注経験や知識があるメンバーがいれば、「見積もりのこの内訳は、なぜ高額なのか？」といった対話・交渉ができます。誰も分からなければ、バッファの見積もりがそのまま通ってしまいます。

３．技術的に難しい要件が盛り込まれている

「技術的に難しく、コストがかかる機能が要件に入っているため、見積もりが高額になる」ケースもあります。

技術に詳しくないメンバーが手探りで要件定義を行うと「画面表示は0.1秒以内」といった、開発に高い技術や多くの工数が必要になる要件を、安易に盛り込んでしまいことがあります。実際には、その要件の優先度は高くなくても、依頼を受けたベンダーは真剣に要件と向き合い、実現するための費用を見積りに取り込んでしまいます。双方のギャップを解消するには、コミュニケーションが必要です。

4.ベンダーとのトラブルパターン②
機能の追加に、多額の費用と時間がかかる

「途中で機能追加しようとしたら、多額の費用と時間がかかると言われた」というのも、非常にありがちなケースです。しかも、最初から盛り込んでおけば数百万円で済んだはずが、中途の追加だと数千万円規模になることもあります。

さらには、スケジュールとリソースの事情で、追加や変更がかなわず、不本意な形でローンチを迎えなければならなくなることもあります。

この原因は「拡張性についての伝え漏れ」です。あらかじめ機能追加などの可能性を伝えて柔軟性を持たせておけば何の問題もなかったのに、開発が始まってから突然追加することになると、機能を1つ追加するだけでも、大規模な変更が必要になることがあります。「1つ機能を追加するくらい簡単だろう」という考えは、システム開発では通用しないと覚えておきましょう。

5.ベンダーとのトラブルパターン③
開発途中やローンチ後に、個人情報保護に関わる問題が発生する

新規事業開発では、どのような事業分野や業務であっても、個人情報保護の観点が重要です。開発ベンダーには、事前にクリティカルな情報を取り扱うサービスであることを明確に伝えておきましょう。前提の共有がないまま進んでしまうと、個人情報保護のルールに沿わないサーバーを使用してしまうといったことが起こり得ます。場合によっては、サービスを緊急停止やサーバー移転で、数千万円規模の費用がかかるといった事態にもなりかねません。

6.ベンダーとのトラブルパターン④
画面デザインは注文通りだが、画面の表示に時間がかかる

新規事業チームと開発ベンダーの認識のズレから、仕様通りにできなかったパターンもよくあります。例えば、UI開発の際に、技術的な理由から画面表示に1分近くかかるとします。

おそらく、ベンダーは「画面表示までに少し時間がかかるけど良いですか？」などと事前に確認することでしょう。新規事業チームの担当者は「少し」を「1分」とは思わず、安易に「大丈夫です」と答えてしまっているのです。機能以外の要件の伝え漏れが原因であり「具体的かつ定量的な伝達」がトラブル回避の要点になります。

7.ベンダーとのトラブルパターン⑤
ユーザーの増加でサーバーが落ちた

まだサービスを提供し始めたばかりで、ユーザー数が少ない段階では問題なかったものが、ユーザー数が伸びるにつれてサーバーが耐えられなくなるといったパターンもよく起こります。ただ、闇雲にサーバーを増強しても、運用コストが無駄になってしまいます。先々の接続数の推移などを予測しながら、開発ベンダーと一緒にスケール設計を考えていく必要があります。

8.ベンダーとのトラブルパターン⑥
内製化しようとしたが、必要な技術者を確保できない

新規事業では、最初の開発だけをベンダーに外注し、その後の運用・保守を内製化するパターンも珍しくありません。しかしその開発ベンダーが、マイナーな開発言語やフレームワークを使っていたりした場合、社内への引き継ぎが困難になります。その結果、自社では維持・管理できず、最初からつくり直す、あるいは当初のベンダーに依存して内製化が進まない事態にもなりかねません。内製化を考えているならば、そのことを開発の初期からベンダーに伝え、使用する開発環境にまで目を光らせておきましょう。

9.注力すべきは「要件に合ったベンダー選定」と「ベンダーコントロール」

ここまで、開発ベンダーとの間で起こりがちなトラブルパターンを6つ紹介しました。これらは「機能要件・非機能要件（機能以外の要件）、依頼事項を共有できていない」点で共通していることが分かったかと思います。

読者の中には「アクセラレーションフェーズのプロダクト開発では、ビジネス戦略に合わせて、どんどんシステムも変わっていくことが前提ではないか」「最初から要件を細部まで固めるのは困難で、機能追加も仕方ない」と考えるかたもいらっしゃると思います。まさにその通りです。

だからこそ、開発を依頼するタイミングで、ベンダーには「新規事業のため、変更の発生が前提になる」ということを伝えなければいけませんし、そのような開発が得意なベンダーを選定する必要があるのです。技術や予算は大前提ですが、発注側が意図する新規事業開発の要件に向いているベンダーを選定することが、新規事業開発の重要なポイントです。

さらに、依頼の時に注意してほしいのは「依頼する側が丸投げしないこと」です。最初の打ち合わせで抽象的な表現ばかりの「要件」を渡して、「あとはよしなに」では、今回紹介したようなトラブルに発展しやすくなります。

プロジェクトの開始前に、念入りに優良な開発ベンダーを選定したら、目標を実現できるプロダクト開発体制を社内につくり、全てのプロセスを「自分ごと」と考えて、丁寧にベンダーをコントロールしていく。それがアクセラレーションフェーズのプロダクト開発を成功に導く近道であり、最善のルートなのです。