過不足ないプロダクト開発。過剰と不足の原因と対策。

こんにちは。プロダクトマネージャーのたけまさです。

スタートアップにとって時間と資金の関係は、生死を分けるほど密接です。今回は限りある時間を有効に使うために「過不足のない開発プロセス」について紹介します。

そもそも、なぜ無駄な作業が発生するのか？

最初にプロダクトの仕様を決定するために、
「最低限、何に結論をだせばよいのか？」が曖昧なとき、
開発プロセスに過不足が発生します。

メンバーがそれぞれの持ち場で最良手段を考えた結果、過剰投資がはじまることもあります。調査やフレームワークの実行に時間を使いはじめたら注意が必要です。「必要かもしれない」投資にも気をつけましょう。

過剰に使う時間こそがスタートアップにとってリスクです。

過不足を防ぐポイント
・意思決定ために、価値の低い情報まで網羅的に取得しない
・顧客への価値提供に、直接関係のある変数だけをおさえる
・抜け漏れは必ず起きるので、早期にプロトタイプで問題を見える化する
・プロトタイプ検証によるPDCAで、仮説ではなく事実ベースで開発をする

一緒に開発する仲間に最大限のパフォーマンスを発揮してもらうためには、要件作成で「やること/やらないこと」の範囲を定義しましょう。リターンが少ない案件ほど、投資できる人月も小さくなります。

過不足ないプロセスの設計方法
1.課題解決のために「最低限、何に結論をだせばよいのか？」を整理する
2.必要な「結論」に優先度をつける。進捗次第で低優先度は切る判断も。
3.結論たちの裏付けを取るため、最小限必要な手段を選定し、高優先度から実行する

前記事：「投資活動としてのプロダクトマネジメント。ROIを高める2つのポイントとは？」

事業会社は調査や仮説では対価がもらえません。顧客からの対価は成果のみに支払われます。インプットではなく、アウトプットを中心とした高速PDCAが重要です。

よくある過剰と不足のアンチパターン

メンバーを信頼しつつもプロダクトマネージャーは、投資対効果の最大化に責任があります。見込み利益に対して人月投資が膨らめばROIは悪化するためです。

過剰のアンチパターン例
・使われる「かもしれない」機能まで開発する
・BtoBのプロダクト開発でペルソナをライフスタイルまで設定する
・カスタマジャーニーマップを広すぎる範囲で作成してしまう など

使われない機能開発はみんなを不幸にします。ペーパーモックやMVPなどでユーザーと最小工数で検証しながら、必須機能だけ開発しましょう。

ただの仮説にシステム開発は当たらない大博打です。
仮説は事実検証で磨いた上で開発をはじめましょう。

プロダクトを磨くために価値ある情報とは？
・価値：(低) 仮説 < 定性評価 < 定量事実 (高)
・例：かもしれない < 3/5人が使いやすい評価 < 1/5人しか買わなかった事実

BtoBのペルソナ設定でユーザーの休日の過ごし方の話がでたら、フレームワークに振り回されています。ブループリントやジャーニーマップの類も同様で、論点は顧客課題と直接関連する範囲に絞って作成しましょう。

不足のアンチパターン例
・MVP（実用最小限製品： minimum viable product）を、実装視点の最小で機能設計をしてしまう など

MVPにおける最小とはどんな状態か？「ユーザーの課題解決のために必要な最小限製品」として設計しましょう。

意思決定の速度もROIに影響する

開発プロセスのおける意思決定の遅延防止
・「検討します」を根絶する。意思決定を先延ばしにしない。
・情報がないなりに、その時点の結論をだす
・結論は、仮説と事実検証によって更新し続ける

毎日結論をだしましょう。
毎週あたらしい事実を手に入れて成果物を更新しましょう。
結論が更新された回数だけプロダクトも良くなっていきます。

以上
過不足ない開発プロセスを設計するポイントについて紹介しました。

「とはいえ、何から着手すればいいの？」ということで、次回は「最初の1週間の使い方」についてご紹介します。