非開発者のためのプロダクト立ち上げtips

はじめまして @shota_kohara です。以前、開発経験のない事業責任者の方に新規事業立ち上げにおけるプロダクト開発について会話して、その時のメモをシェアしてみます。

プロダクト開発にそこまで明るくない起業家や新規事業担当の方が読んで参考になるところがあれば嬉しいです。

全体的に本文の主張は投稿時点までの個人的な経験を元とした仮説であり、偏見や間違えが含まれる可能性がありご容赦ください。

事業領域を見極める

いきなりプロダクト開発と関係は薄いのですが、マーケットが伸びている(または直近伸びる可能性が高い)領域を狙うことは重要だと考えています。

そのほうが生き残りや拡大の可能性が高いからです。たとえ優秀なメンバーが集まっても0からの市場開拓や事業の力だけで実績を積み上げていくことは非常に難しく、示唆が出るまでも時間がかかり死亡しやすいです。逆に狙い所がさえ良ければ、チームが貧弱だったり、優位性が薄く競合比較で成長率低くても、市場の後押しで業績の絶対値は伸びることがあります。

期限を決めて限られた期間の中で示唆が出せて次に繋げられることが継続の前提条件なので少しでも可能性が高いところで戦うのが良いと考えています。死んだら元も子もないので、本気でやりたい事業をすること、の次くらいに大切に考えています。

事業に有効な課題解決方法の方向性をすり合わせる

事業開始前にプロダクトで現実的に解消出来る課題やスケールできる筋を見つけて、事業の実現可能性を見極めたほうが良いと考えています。

これは事業とプロダクトの知識をミックスして考える必要があるので、最低限のプロダクトの知識は自分で持っていた方が判断する上でのコスパが良いと考えています。この知識とは、関連事業の既存プロダクト(=実現可能なソリューション)の機能と解決する課題の関係性を深い洞察を持って説明でき、そこから論理的にオリジナルの価値を仮説できるくらいのイメージです。

高い確度で実現方法をイメージできていれば、事業の背景課題を洞察できずとも技術力を持つ開発者であれば実現可能性を判断できるので、ヒアリングの難易度は下がります。

ただし事業もプロダクトもハイレベルで考えられないと将来的にどちらかが要因となってつまずく可能性が上がるのと、周囲のチームを観測する限り起業家が両方を見続けるのは時間的に難しそうなので、意思決定を移譲出来るバランス良いパートナーをいづれ見つけなくてはならなくなるかとは考えています。

プロダクトの目的をすり合わせチームの目線を揃える

誰のためのプロダクトなのか、なんのためのプロダクトなのか、その辺りの目的は詰めたほうがよいと考えています。

当たり前のことを、、と感じるかもしれませんが、何をするかだけが決まってその裏の仮説やストーリーの軸足が定まって居ないケースは今まで多く観測しました。

立ち上げ初期は仮説のチューニングが必要なタイミングも多く、今かっちり考えなくても走りながら決めればええやんという主張を聞くこともありますが、仮説が明瞭なほど学習効率が高くチューニングしやすいので初めから考え抜いたほうが良いと考えています。

また時間がたてば立つほど方針の変更がコストが大きくなるので初めに想定し切る必要があります。この時の想定の深さ次第で、結果的にプロダクトや事業の器の上限(将来の進化の選択肢)を制限することもあると考えています。

あとチームでコミュニケーションするときは、どこまでが確かな仮説で、どこは変更可能性があるかはっきりさせたほうが仕様などを考える上で軸足を安定させやすいと考えています。無駄に可能性を残していくと全体の思考が浅くなりどっちつかずになるケースが多かったです。

デザインについて

プロダクトの目的を基準にどんなユーザー体験(UX)を満たせば全体の流れを成立させられるか網羅的に言語化して整理します。出し切った後に体験の重要度(大抵は頻度とか、差別化ポイントなどに帰結？)を整理して並び替えます。

その内容をもとに情報設計(IA)を作り、体験の流れを機能として具体化してみる。簡単にプロトタイピングなどしてみる事もできます。

具体的に演出したいトーンをもとにビジュアルのテイストを元とした具体的なUIを作り込みます。(ブランディングも作れるのであれば、表現の方向性はもっとシャープになるかも。)

UX→IA→UIの順番で後から修正するコストが大きいので、川上ほど慎重に決めたほうが良いと考えています。(UXの根本的修正など走り出したら現実的には不可能なんじゃないかな。)またデザイナーにお願いする際も個々人で得意とする領域は異なるので何をどこまで期待してお願いするかはコミュニケーションできると良いかもしれません。

開発について

上記のプロダクトの目的をもとにどのプラットフォーム(Web・モバイル)の優先度を決めて、インフラ・バックエンド・クライアントなどを実装する。

インフラやCIなどは割高でも運用(デプロイ・管理・スケールなど)に人手がかからないようなサービスや設計にするとユーザーが少ない初期はコスパがよいのかなと考えています。作りきってそこまで頻繁に弄らないことが多い(アプリ周りのCIとかはあれだけど・・)とは思うので、スポットの依頼がしやすいかと考えています。

バックエンドは後から作り替えることが難しいので、なるべく初めから信頼できる人で、事業ドメインを学習していける内製チームを作るほうが良いと考えています。サービスを継続成長させるなら、スポットでとりあえずどこかに作ってもらうみたいなことはやめたほうが良いかと思います。(負債に苦しむチームを見てきました。)

クライアントはリニューアルやプラットフォーム変更などのタイミングでリセットがきくことはある点でバックエンドに比べると将来の負債リスクは少し低いかもしれません。ただクライアントの改善はユーザーへの影響が大きい事が多くリリースのアジリティを求めることも多いので、細かい改善を高速に繰り返すことができる開発体制の優先度は高く感じます。

将来の成功を見据えると、あまり手を抜けるところはなく、基本的には内製開発の体制が作れると良いのでしょう。

ただし初期は一般に資金問題で人数を絞って社員採用するのじゃないかと思います。分業が難しかったり、初期はコミュニケーションや精神性が重視されることも多いと思うので、複数の技術が使えたり計画やコミュニケーションが得意だったりと、一つの専門性よりは総合的なバランスが高い方フィットするケースが多いかもしれません。

数値分析について

プロダクトのログ収集について、基本的にはユーザー情報を紐付けたページビュー・スクリーンビューと、DBのコピーをデータウェアハウスにコピーできていれば最低限のSQLを使った分析ができると考えています。その他、サービスの必要に応じてイベントを追加すればよいですが、例えば firebase analytics などを使ってログ収集していれば多くのイベントを自動で収集してくれるので要件を満たせることも多いかと思います。

全体の傾向を把握する上で、Google Analytics などアクセス解析GUI機能のついたものも入れておくとアドホック分析も楽に行えます。

分析設計についてはプロダクトについての仮説がそこまで育ってなくとも、一般的な知識に基づいてセオリー的にモニタリング環境を作ることはできると考えています。プロダクトによるけど、オンボーディングと継続率、課金など任意のCV関係の数値が適切に追えることが最初の着地点になるでしょうか。その後施策の必要に応じてメンテナンスしていけば良いでしょう。

このやり方の場合、ログ収集の設計と開発、KPIの設計と開発(SQL)が必要です。設計については(プロダクトの)アナリスト経験のある人、実装についてはアナリストかプロダクト開発者であればやっていけると思います。

なお、ログ収集は過去に遡ることができないので、なるべく早い段階で正しく設計したほうが良いと考えています。

立ち上げ後の継続的機能のエンハンス

プロダクトの方針とそれを裏付けるそれぞれの仮説を日々検証して開発戦略を調整したり、それに応じた具体的なデザインや機能要件を詰めて、開発に落とし込みます。

定性・定量に基づく仮説検証とそれに応じた企画と優先度付け、その後仕様の合意と開発プロジェクトの管理(アサインとスケジューリング、またはスクラムなどその運用の設計)あたりの業務を遂行できれば後は開発者、デザイナーとの開発が進行します。

企画・プロジェクトの管理・開発(+デザイン)の責務は分けて分業できる体制を作っておくと、チームが大きくなっても動きやすいかと考えています。

終わりに

プロダクトマネージャーとしての自分の守備範囲の中でわかることを書いてみました。自分の得意ではない領域や実力の至らない点で重要な見落としがあったらすいません。

念の為、上記プロダクト開発全体を推進するスキルは、純粋なコーディング力や開発力とは少し毛色が違うので、エンジニアを採用してアサインする場合、期待値のすり合わせに注意出来ると良いと思います。

最後まで読んでいただきありがとうございました。