この記事の目次
YOUR MOVE / こんなとき、どうする？
新規事業なのに、最初の会議で全と納期を決めることになりました。
いま固定してよい前提と、まだ試すべき前提は何でしょう？
探索と実装の違い、要件を固定する前の検証を整理できます。
本文で判断の手順を読む ↓判断の流れを、一枚で。
- 01共通の目的
- 02役割の違い
- 03判断の境界
- 04連携の合意
| 観点 | ここで止めない | 次に確かめる |
|---|---|---|
| 比較軸 | 肩書きの違い | 責任・成果・時間軸で比べる |
| 境界 | 誰が何でも担当するか | 判断者と実行者を分ける |
| 連携 | 担当を押しつける | 受け渡す情報と期限を合意する |
要件定義の前に、事業仮説がある
既存業務の効率化では、現行業務とを起点にできます。新規事業では、顧客、課題、提供価値、価格が未確定です。未検証のを詳細仕様にしても、間違いを精密に作るだけです。
進め方の違い
どちらも技術を使いますが、成功条件が異なります。
| 観点 | プロダクト開発 | システム開発 |
|---|---|---|
| 起点 | 市場との | 業務・要件 |
| 成功 | 利用・収益・利益 | ・品質・納期 |
| 変更 | 学習に応じてを変える | 変更管理で範囲を制御 |
| 終了 | 継続・成長・撤退 | 導入・検収・完了 |
新規事業での正しい接続
の検証、販売検証、を経て、繰り返し価値を出す工程が見えたらシステム化します。システムは事業の代わりではなく、価値提供を速く、安く、再現可能にする手段です。
要件は固定物ではなく、検証済み前提の束
要件ごとに、どの、どの事業指標、どのに紐づくかを記録します。根拠が崩れた要件は、開発着手済みでも見直します。
この記事の学習目標・次に試すこと
この記事でできるようになること
- 01プロダクト開発とシステム開発、要件を固めてよいのはいつ？の要点を、自分の言葉で説明できる
- 02自社の案件で、使う場面と使わない場面を区別できる
- 03自分の役割と、いま決められる範囲を一枚に書く
読んだ内容を、仕事へ移す。
画面を閉じる前に、資料を見ずに答えてください。思い出すことで、理解の抜けと次の行動が見えます。
30秒で答える：この記事の結論は？ ＋
システム開発は合意された業務・要件を実装する活動、開発は・解決策・収益性そのものを探索しながら事業を育てる活動です。新規事業では要件を固定する前の検証が不可欠です。
自社で試す：今日つくるものは？ ＋
自分の役割と、いま決められる範囲を一枚に書く。完成度より、次の会話や検証に使える状態を目指します。
この記事の学びを残す
自社で学ぶ → 方法を選ぶ → 必要なところを相談する
プロダクトマネジメント。次は、自社の課題で試す。
顧客課題・コンセプト・検証・優先順位を、実務の成果物で学ぶ。
手順・比較・記入例を学ぶ →まず自社でできる3つの整理
- 事実と仮説を分け、顧客の課題を一つに絞る
- 何が分かれば次へ進むか、判断基準を書く
- 試した結果と、次に変えることを記録する
どこまで自社で進める？
自社で進める目安小さな検証と振り返りをチームで続け、意思決定者と責任範囲を揃えられる場合。
プロへ相談する目安判断が属人化する、顧客検証が進まない、チーム共通の進め方や伴走が必要な場合。
分からないところから、相談できます。
相談前は「対象の事業・商品／チームの課題／判断したいこと」の分かる範囲だけで構いません。資料が揃っていない場合も、その旨をお知らせください。
日本プロダクトマネージメント合同会社が支援できる範囲を確認します。相談の送信だけで有料契約は始まりません。実施範囲・費用・日程は個別に確認します。
PRIMARY SOURCES
参照資料
定義・研究・公的情報は、可能な限り発行元または原著へリンクしています。
読者のコメント 0件表示
まだコメントはありません。