読み込み中...
投稿日
更新日
事業計画立案ステージ ― 事業計画・収支計画の作成方法
はじめに
ここでは、新規事業立ち上げのプロセス「ステージ・ゲートプロセス」における「事業計画立案ステージ」を解説します。
※上図の各ステージをクリックすることで対応記事にジャンプできます。
新規事業立ち上げの全体概要を掴みたい方は、まず新規事業開発 ― ステージ・ゲートプロセスによる新規事業立ち上げを一読頂くことをお勧めします。
事業計画立案ステージとは
事業計画立案とは、どのくらい投資をして、どのくらい儲かりそうかを検証するステップです。
決裁者に対して、意思決定に必要な情報をわかりやすく伝達できるように、これまで準備してきた情報を整理することに加えて、収支計画を策定します。
| アクティビティ | 概要 |
|---|---|
| 事業計画策定 | 事業のロードマップ及びKPIを設計するステップです。 「ロードマップ」という形で、今後どのようなスケジュールで事業を推進するかを大枠で示します。 「KPI」では、新規事業は売上や利益といった成果が出るまでに時間がかかるため、売上・利益を担保するための重要な指標をKPIとして設定します。 これまで検討してきたマーケティング戦略、セールス戦略も含めて検討します。 |
| 収支計画 | いつ、どの程度の収支・投資対効果となるかを可視化するステップです。 |
| 事業計画レビュー | 審査観点に従って、事業計画を審査するステップです。 |
事業計画策定
概要
決裁者から意思決定を引き出すために必要な事業計画書を作成するステップです。事業計画書は、事業を思考するための道具であり、思考の伝達の道具でもあります。そして、事業計画書を適切に用いて、決裁者の意思決定を引き出します。
実施手順
事業計画書は、一般的に以下の1から15で構成されます。
1. 目指す世界観
事業アイデアの検証を通して最終的にどのような世界を実現したいか描きます。「企画検討」の内容や「顧客インタビュー(PSF)」「PoC・テストマーケティング・セールス」を通じて得られた検証結果を踏まえてまとめます。
2. 事業概要
事業アイデアの骨子となる顧客、商品・サービス概要、提供価値・メリットなどを紹介します。
「PSF」「SPF」を通じて検討した商品・サービスの内容、「PoC・テストマーケティング・セールス」を通じて検証した提供価値などを踏まえてまとめます。
この時に、大事なのは、半永久的にどのように事業を継続するかの視点です。
立ち上げたら終わりではありません。
参入障壁が何か、特異点が何か、初期アイデアの商品・サービスをどのようにアップデートさせていくかなどの視点が重要です。
JV設立や新たな事業部の設立など、事業の推進体制についても言及します（後のアクティビティ「事業化準備」で再度具体検討します）。
3. 技術実証
事業アイデアの信憑性・実現性を担保するために技術面での証明が必要な場合、先行研究や事例などのエビデンスを用いて説明します。
例えば、論文ならCinii、特許技術ならJ-PlatPat、技術トレンドならGartnerなどがあります。
4. ビジネスモデル
ステークホルダーを含めたヒト/モノ/カネ/情報の流れを整理し収益を生み出す仕組みを整理します。
5. ステークホルダー整理
事業を実現するにあたって絶対に必要な役割を検討し、巻き込むべき組織を把握します。
6. 市場分析
市場の規模/成長率/トレンドをふまえ市場の魅力度やリスクを分析します。「市場競合・調査分析」の内容を踏まえてまとめます。
7. 競合分析
競合他社の商品ラインナップや顧客基盤、技術・ノウハウをふまえ自社の競合優位性を分析します。こちらも「市場競合・調査分析」の内容を踏まえてまとめます。
8. KPI設計
新規事業は売上や利益といった成果が出るまでに時間がかかるため、売上・利益を担保するための重要な指標をKPIとして設定し、重点的に状況を把握します。ここまでのアクティビティであまり触れていない点ですので、以下の設計の手順をご覧ください。
KGIを設定
まず、最終目標となるKGIを設定します。KGIは数値で測れて、達成可能な目標を設定することが大切です。
KGIからKPIを設定
各KPIは「検索流入数月間100人」のように具体的な数値化をして設定します。
KPIツリーを作成
KPIを細分化して、達成するための行動をわかりやすくするために、KPIツリーを作成します。これにより、目標の達成には何が必要なのか一目で全体像を把握できるようになります。
9. ロードマップ
計画達成に向けた進め方の合意を得るための大まかなスケジュールを整理します。こちらもここまでのアクティビティであまり触れていない点ですので、以下の作成の手順をご覧ください。
マイルストーン設定
- 事業推進に際し、マイルストーンとなる時期・状態をトップダウンで設定
- 出口に関連する、事業部設立やJV設立などの重要な節目を含めて検討
- 例：市場先駆者となるためには3ヶ月以内のβ版ローンチ必須、法改正となる1年後までに正式版をローンチすべき、等
主要実施事項の洗い出し
- マイルストーンに向け必要な事項を洗い出し、それぞれの必要事項に掛かる期間をボトムアップで積み上げ
ロードマップ全体調整
- マイルストーン（トップダウン）及び主要実施事項（ボトムアップ）の整合性を取るべく、ロードマップ全体を調整
10. マーケティング戦略
どのような場所（メディア）でどのような施策を実施すると、商品・サービスへの認知獲得から購買検討まで顧客の感情を押し上げることができるかを考えます。「PSF」「SPF」を通じて検討/精緻化した「マーケティング戦略」を踏まえてまとめます。
11. セールス戦略
ビジネスが成功するためのシナリオを描き、目標達成するための計画を策定します。「PSF」「SPF」を通じて検討/精緻化した「セールス戦略」を踏まえてまとめます。
12. 収支計画
事業目標を実現するために必要な売上や獲得ユーザー数、発生コストなどを3~5年の計画として策定します。この後のアクティビティ「収支計画」で詳細を説明します。
13. 自社との親和性
「自社のビジョン/戦略と合致していること」「経営リスクの分散/既存事業の強化につながること」「自社の強みを活かせること」などの観点で、事業化する意義を考えます。
14. リスク要因
これが満たされないと事業として存続できない点を洗い出します。
法務/技術/経済的観点などで、様々な事例を把握します。
例えば、法律でNGになることはよくあります。また、特許技術などでこの会社と組まないと実現がかなり厳しい、などが考えられます。
15. 今後のアクションプラン
いつ、どのような実施事項を行うかを整理し、実施事項間のつながりや、大まかな役割分担を明確化します。
ロードマップを踏まえ、直近で対応が必要なタスクを列挙します。
コツ/注意点
ロードマップでは、細かなタスクを作らないこと
ロードマップは目標達成までの全体的な道筋や方向性を捉えることを意識して、詳細や個別的な細かいことはプロジェクトの計画段階に委ねましょう。
人によって解釈が変わる内容やあいまいな目標などはKPIとして設定しない
誰が見ても同じ内容で理解・解釈ができるように数値を使用することが大切です。
リスク要因で、リスクが見つからなかった場合は…
成功に必要な条件の視点で考えてみてください（例：●●の特許を取得する / サイト投稿者を自動的に集める仕組みの構築 など）。
収支計画
概要
いつ、どの程度の収支・投資対効果となるかを可視化するステップです。
前のアクティビティ「事業計画策定」の中でも重要な一要素です。
大きな支払いがあるために一時的に資金がマイナスになってしまう月があったとしても、事前にわかっていれば、支出を見直したりするといった対策ができます。
実施手順
以下の流れで算出していきます。
1. 収入の試算
- 収入を構成する要素を洗い出し、各要素がいつどのような水準になるかを試算
- 顧客数×単価×利用回数などの大きな要素から、必要に応じ細分化することが必要
2. 支出の試算
- 支出を構成する要素を洗い出し、各要素がいつどのような水準になるかを試算
- 固定費（生産量や販売量の増減に関わらず一定にかかる費用）・変動費（売上（生産量・販売量）に比例して増減する費用）ごとに費用項目を細分化することが必要
- 開発費用の見積もりについては後述するプロダクトの言語化を参照。
3. 累計収支算定
- 収入・支出を基に、累積収支がいつマイナスからプラスへ転じるか等を表記
- この際、自社の投資基準（例：投資回収3年以内等）に合致するか、合致させるために何をどう見直すかを検証することが必要
収支計画
コツ/注意点
収入・支出試算に際し、いきなり細かな項目を洗い出さない
大きな項目（顧客数や単価など）洗い出し、その後、必要に応じて項目を細分化することがポイントです。
複数のシナリオで収支をシミュレーションしてみる
収支計画は基本となるシナリオ（ベースケース）を作った後、顧客数や開発費用、広告宣伝費などの重要な数字を変動させてベストケースとワーストケースを作成し、とてもうまく行った場合のシナリオと、最も悪い場合のシナリオの数字を確認しましょう。
ベストケースを目指した活動の検討や、ワーストケースを避けるための対策・対応の検討に役立ちます。
ロードマップとの整合性を担保する
こういうマーケティング施策を打ったらこういう効果が出る、といった繋がりをここで担保しましょう。
プロダクトの言語化
何らかのアプリケーションを必要とする事業において、支出を試算する上で最も大きな割合を占めるのは、多くの場合開発コストとなるでしょう。
事業計画策定で整理してきた項目はビジネス面の話が中心です。
そのため事業の全体像をよく把握している事業オーナーが主体となって進めることができました。
しかし収益計画を立てるにあたり、収益に大きな影響を与える開発コストを高い精度で見積もるためにはエンジニアが主体的に動くことが欠かせません。
開発見積もりを行うためには、どのようなプロダクトが必要なのかをまず明確にする必要があります。
しかし、新規事業では多くの場合、直接参考にできる既存のプロダクトは存在しません。
事業としてどのような世界観を目指しており、誰にどのようなユーザー体験を通してどのような価値を届けたいのかという観点に基づいて必要な要件や機能を洗い出し、見積りを進めていく必要があります。
これらの観点に基づいてエンジニアが主体的に考え、さらに次のステージ以降で開発に携わる新規着任者にも共有するためには、事業オーナーとエンジニアが協力し、事業として目指す世界観や目指すプロダクト像を言語化して認識を共有することが欠かせません。
そこに認識の齟齬がある場合、求めていたものとは違うプロダクトが出来上がってしまったり、予想以上に開発コストが膨れ上がる要因となり得ます。
プロダクトの言語化を行うにあたっては、事業面と技術面双方の事情を考慮した上であるべき姿を定める必要があります。
また、プロダクトのあるべき姿は一度定めて終わるものではなく、顧客フィードバックや市場環境の変化を受けて常に見直し続ける必要があります。
新規事業においてプロダクト開発を円滑に進めるためには、プロダクトオーナーとしてこうした役割を継続的に担える、事業面と技術面双方の視点を備えたメンバーが必要です。
もしこの役割を担えるメンバーが現時点でチーム内にいない場合は、本ステージのうちに要員の追加を検討するか、または普段から事業計画関連の打ち合わせや顧客訪問などにエンジニアを巻き込むなどして既存メンバーを育成する計画を立てておきましょう。
言語化すべきもののうち、事業として目指す世界観については事業計画策定で事業計画書として整理しました。
目指すプロダクト像をどのように言語化するかについては、以下の図に示すドキュメントを用意するのが望ましいと考えています。
成果物フロー
上記の図では、事業計画立案ステージにおいて必要なドキュメントと、それらのドキュメントの依存関係を表しています。
これらのドキュメント作成の過程を通じて、プロダクトのあるべき姿を段階的に言語化していきます。
上下に並んでいるドキュメントは、並行して細部を検討していくことを想定しているものです。
新規事業ではスピード感をもって進めるため、機能を一括でリリースするよりも優先度の高い機能を順次個別リリースする方が望ましく、そのためにはユーザーストーリーの単位でそれぞれの要件定義や設計を並行して進めていく必要があります。
またそれぞれのドキュメントの検討を並行して進めることで、仕様の考慮漏れに早い段階で気づきやすくなります。
事業計画立案ステージの時点ではプロダクトの要件は不確実性に満ちています。
最初は必要だと考えていた機能を、顧客の声を聞いた結果見直すことになるかもしれません。
開発途中に市場環境が変化し、より優先度の高い別の機能が必要なことに気づくかもしれません。
事業を成功させるためにはこうした不確実性に基づくリスクをなるべく早い段階で検知し、その都度プロダクトのあるべき姿を見直す必要があります。
そのため、図中で示した成果物の多くは一度作成して終わりではなく、継続的なアップデートが必要不可欠です。
完璧なドキュメントを用意することよりも、メモ書きでも良いので更新し続けることを重視しましょう。
また、決定事項だけでなく何故そう判断したのかの経緯も併記しておくと、後から方針の見直しが必要となった際に役立ちます。
次項からは、上記の成果物フローの図中に記載したものの中から、この事業計画立案ステージで言語化しておくことが望ましい個々のドキュメントについて説明します。
ユーザーストーリーマップ
見積もり・スコープ決定において最も大事なのはこれから作ろうとするサービスの全体像を掴むことであり、そのために必要なのはユーザーストーリーマッピングです。
ユーザーストーリーマッピングで作成するアウトプット(ユーザーストーリーマップ)はユーザーに何を提供するのか・その目的が何かを表した図であり、「事業オーナー」と「エンジニア」「デザイナー」がそれぞれ議論しながら以下の順で作成します。
- サービスのユーザーが誰なのかを洗い出す
- それぞれのユーザーが商品・サービスを使いはじめてから使い終えるまでのユーザーのアクティビティを、時系列順で横に並べる
- そのアクティビティをシステムで実現する際に考えられるバックオフィスの業務も記載する
- 個々のアクティビティに必要となる機能を優先度順で縦に並べる
ソフトウェアの機能的な要求にばかり目を向けないように注意しましょう。可能であれば「ドメインエキスパート」に参加してもらうことで、事業におけるユーザーストーリーの価値をより深く議論できるでしょう。
ユーザーストーリーマッピングにより、サービス開発に関わる全員がどのようなサービスを作るべきかを理解できるようになります。
その上で、どこまでを最初のリリース対象とするのかの線(リリースライン)を引きましょう。このリリースラインに含まれる機能が最初の「開発スコープ」になります。
このリリースラインは、サービスの価値を実現する「必要最小限」の機能をリリースできるように引くのが望ましいです。
空想上のユーザーではなく実際のユーザーからのフィードバックを生かすほうが、サービスの成長につながるためです。
一方で開発規模やスコープを狭めることも時には必要です。
リリースラインを決めるには、事業の本当の価値の源泉はどこなのか、それに紐づく最小限の要件になっているのか、複雑・高機能なものを本当に最初から作り込む必要があるかを問うことが重要になります。
プロダクトとして何を作るか
プロダクトの骨格を形作るには、後述する「プロダクトバックログ」「概念データモデル」「非機能要件」「画面遷移図」「業務フロー」の5つのドキュメントが必要です。
これらはプロダクトの言語化で示した成果物フロー図の示す通り、プロダクトの言語化に必要であり、次のステージにおいても継続的にアップデートされるドキュメントになります。
プロダクトバックログ
大前提として、もっとも情報が少ないサービス開発当初から、プロダクトバックログを明確に詰めることは不可能です。
このため、我々はユーザーストーリーという「ソフトウェアの機能が顧客にどのような価値を提供するかを示す」抽象度の高い機能記述を要件として扱います。
ユーザーストーリーは、ユーザーストーリーマップのリリースライン内に存在する機能から抽出し、記述を洗練させましょう。
再掲しますが、具体的なユーザーストーリーの例1が以下です。ユーザーの分類(役割)、ユーザーの目的、その理由を具体的に記述します。
このような形でユーザーストーリーの意図と本質を捉えた文章を記述することにより、プロダクトバックログを作成できるようになります。さらにこのユーザーストーリーを活用して、チームは後段でより詳細な議論が可能になります。
ユーザーストーリーの雛形
概念データモデル
概念データモデル設計では、開発チーム・事業オーナーでユーザーストーリーを満足できるデータモデルを作り上げます。また、画面遷移図や全画面のワイヤーフレームを固めておくと、サービスの解像度が飛躍的に高まるとともに
見落としているアクティビティにも気づきやすくなります。見積もりの解像度を上げるためにも、ぜひ実施してください。
概念モデル設計の具体的な実施手順は以下のようになります。
- 序盤にどういったモデルが登場するかを挙げていきます。それらのモデルを使って業務フローを回す想定をし、モデルの追加や削除をしていきます
- 中盤ではそれらの間のカーディナリティ（多重度＝１対１、１対多、多対多か）を確定させていきます。この多重度は自由度が高いとシステムは複雑化し、低いとシステムの制約になります
- 終盤では概念データモデル図を作成します。概念データモデル図の変更は、業務のモデルや業務フローだけでなく実際のシステムの画面設計、API仕様やデータベースのテーブル構成と連鎖し、手戻りのコストとなります。可能な限り精度を高めて行う必要のある重要なプロセスです
商品購入と利用ユーザーの例の紹介になりますが、概念データモデル図は、以下の画像のような図になります。
モデルをグルーピングしてドメインとして扱うと分かりやすくなります。
実際の事例では、概念データモデルから、エンティティリレーション図を作成しました。開発前の段階で80近いテーブルがあり、4か月で50回程度の修正が行われ約90のテーブルになっています。
大規模な変更が発生する変更は行われておらず、概念データモデル図としてはまずまずの精度だったと思っています。
非機能要件
非機能要件はシステムアーキテクチャに大きな影響を与え、時に不可逆な判断が必要になります。
このためこの段階で、非機能要求グレードを参考に、事業オーナーと非機能要件を定義しましょう。
一方、非機能要求グレードで定められる全項目について非機能要件を定義するのは、スモールスタートを目指す新規事業に対してはオーバースペックです。
この非機能要件定義を軽量化するために、以下のような進め方を行いましょう。
- 非機能要求グレードに含まれるモデルシステム3種を参考に、システムが機能低下/利用不可能な状態になった場合の影響の程度、システムの役割として開発対象プロダクトにもっとも近いモデルシステムを選択する
- 選択したモデルシステムと開発対象プロダクトとの非機能要件の差を、事業オーナーと確認する
- 非機能要求グレード中の「重要項目」2を対象に、それぞれの項目に対する非機能要件を事業オーナーと合意する
モデルシステムのイメージ(非機能要件グレード3より引用)
画面遷移図
プロダクトバックログでは、ユーザーストーリーに対してユーザーの分類(役割)、ユーザーの目的、その理由を具体的に記述することで、チームでより詳細な議論ができることを紹介しました。サービスを具体的に言語化するアウトプットの1つが画面遷移図です。
画面遷移図により、サービスをより具体的なものとして感じ取ることができます。
注意しなければならないのは、ここでは「ユーザーインタフェースの設計」を目的とするわけではなく、サービスのイメージを共有することが目的です。そのため、デザインを重視するようなユーザーインタフェースではなく、サービスのコアとなる部分が表現されるようにします。
システムに詳しくない事業オーナーもいます。そのような場合、たとえば後述の概念データモデルに関して事業オーナーと認識を揃えるのは難しいでしょう。この場合であっても、今回の画面遷移図や画面のワイヤーフレームをベースに説明することにより、効率的に概念モデルの認識合わせも行えます。
業務フロー
業務フローを作成することで、機能の洗い出し、システム化する範囲を明確化できます。プロダクトを使って、誰がどのように業務を進めるのかを表現し、事業オーナーと開発者が認識合わせをすることで両者にとっての「事業イメージ」の食い違いを防ぎます。また、要件定義や画面デザインなどのインプットになります。
業務フローを作成する際には、情報の粒度を揃え、全体の書き方に統一感を持たせることで関係者間での理解がしやすくなります。
業務フローの成果物イメージについては、業務フローサンプルをご参照ください。
プロダクトをどう実現するか
前項では、プロダクトとして何を作るかを言語化する方法を説明しました。この項では、そのプロダクトをどう実現するかをアプトプットする方法を説明します。
システム構成図
プロダクトをどのような構成で実現するかを考え、図として表現したものがシステム構成図です。この図は、今後見積もりを作成する際の重要なインプットになります。プロダクトバックログ、非機能要件定義書をベースに、必要な機能を洗い出し図に表します。
プロダクトをどこで実現するかも大事な要素になります。クラウド環境なのかオンプレ環境なのか、それともSaaSを利用するのか、あるいはそれらを組み合わせて利用するか等もシステム構成図に落とし込みます。
例えば、ユーザーからの問い合わせを受けるコールセンターを作ることになったとします。バックログアイテムに、ユーザーとの通話を録音するというユーザーストーリーがあるかもしれません。その場合のシステム構成図の例は以下のようになるでしょう。
なお、クラウドやSaaSに代表される外部サービス、あるいはソリューションを利用する場合には、そのサービスの利用許諾を確認することも忘れないようにしましょう。
方式設計
システム構成図を書き起こすとともに、大まかな方式設計を実施します。ここで方式設計をしておく理由は、以下になります。
- 方式設計を考えられていないと機能の実現イメージがわかず、各機能に対する見積もりの信頼度が下がってしまう
- システム構成図が描いた内容と整合性が取れず、後のステージで構成から再検討することになってしまう
機能の実現方式がまったく見えないままでは、そもそも機能の見積もり自体が困難でしょう。
また、実際に開発を進めた際にこのステージで実施した見積もりと大きく乖離するリスクが高まり、事業計画に大きな影響を与えかねません。
特に事業のコアとなりえる機能に対して実現方式が不透明であったり、方式設計での選択が見積もり結果に大きく影響するようなケースでは、方式設計を実施する必要性はより高まると考えます。
この時点で方式設計を詳細に行う必要はありません。機能の実現イメージを持ち、見積もりができる程度の方式設計ができれば十分です。
アーキテクチャ設計・インフラ工数見積もりに記載しているアーキテクチャ設計も活用するとよいでしょう。
実施した方式設計の結果は簡単でもよいので方式設計書として残しておき、開発時に詳細を詰めていきます。
サービス開発に要する期間及び工数の算出
この時点でサービス開発のための要件が固まっていると思います。そのアプトプットを利用してサービス開発に要する期間や工数を算出します。
開発見積
開発見積の最大の目的は以下の2点です。
- リスクを検知し、対策を計画に組み込むことでプロジェクトの成功可能性を高める
- 実際に開発した場合、どのくらいの期間や予算、体制が必要になるのかを知る
見積作業により、内在するリスクについても見えてきます。
- 利用したことのないSaaSとの連携
- 特定の業務フローの解像度の低さ
こういった点は、リスクの大きさをチームで検討し、適切な対策あるいはリスクに備える時間を開発見積に反映する必要があります。この方法については見積もりの進め方を参照ください。
開発見積は、開発一式でいくらといったような出し方はせず、ユーザーストーリーごとに算出します。ユーザーストーリーごとに算出するのは、後述する開発スコープの調整において大事な役割を果たすからです。
開発見積を出す上では、開発工数を算出した後、どの程度のスキルセットのエンジニアがどの程度の期間必要になるのか要員計画を立て、そこから人件費の算出をします。
また、体制を検討する際は、バックエンド・フロントエンド・インフラ・運用のスキルセットをもつチームを少人数で組成します。
そして、UIデザインの解像度が低い状態で多数のエンジニアをプロジェクトに参画させることは避け、
デザインがおよそ見えてきてからエンジニアの人数を増やしてください。
一連のUIデザインができ上がらない状態で開発を始めてしまうと、デザインなしで画面開発を進めざるを得なくなるなど、無理のある開発になってしまうからです。
見積もりに関する注意点
アーキテクチャ設計・インフラ工数見積もり
必要なインフラアーキテクチャは事業ごとに万別であり、事業ごとに設計し見積もる他ありません。
一方、本書で扱う技術に示したように、我々はSPA+REST API構成でのサービス提供を基本として考えています。
これらのアーキテクチャ例は、DevOps環境構築キット Eponaで提供しています。
- SPAのサーブ
- REST APIサーバーのサーブ
- SPA静的コンテンツ用のデプロイメントパイプライン
- REST APIサーバー用のデプロイメントパイプライン
また、AWS上でインフラを実現する際のベストプラクティスはAWS Well-Architected フレームワークで示されています。
これらを意識した構成を検討してください。
インフラ運用費用見積もり
少なくとも1年間、出来れば5年間のインフラ運用費用の見積もりを算出します。
この費用の算出に影響がある要素の例をいくつか列挙します。
| 項目 | 影響範囲 |
|---|---|
| ユーザー数 | RDSのディスクサイズ |
| アクセス数 | ECS Fargateのスペック、同時起動数 RDSのスペック、インスタンス数 Cloud Watch Logsへのログ量 |
| ユーザーによるデータアップロード | S3バケットのストレージ使用量 |
| ユーザーによるデータダウンロード | CloudFrontからインターネットへの転送量 |
計画作成
ここでは「事業計画書」と「プロジェクト計画書」を作成します。
事業計画書については、事業計画策定を参照してください。なお、見積もりおよびインフラ運用費用見積もりの内容や、見積もりの過程で見つけた技術的なリスクも反映しましょう。
事業計画が事業の世界観やロードマップ、KPI等を表現するのに対し、プロジェクト計画はプロダクト開発に携わるメンバー・関係者に対する共通理解のために記述します。
スコープとしては、1st. リリースが対象になるでしょう。
プロジェクト計画には、概ね以下の内容が必要になります。
- 背景/課題/目的
- 成果の目標
- アプローチ
- プロダクトの強みを明らかにし、実現する手段を記載します
- 成果物
- スケジュール
- 体制
- 外部の要員も含め、開発に必要な人員のアサインと要員計画を記載します
- 課題やリスク
- Kenneth S. Rubin、『エッセンシャルスクラム』、翔泳社、2014。↩︎
- どれが重要項目なのかについては、非機能要求グレードに含まれる「05_樹形図.pdf」をご参照ください。↩︎
- 「非機能要求グレード2018利用ガイド」より引用。↩︎
