PoC（事業検証）の期間と工数ベンチャーの開発時間を守る設計

目次

1. 期間を決める前に、終える仕事を一つに絞る
2. 準備・試行・報告を分けると、待ち時間が見える
3. 開発工数に、会議と問い合わせの時間も入れる
4. 待っている間に、別の仕事を無償で積み増さない
5. 上限に近づいたら、終える前に選択肢を出す
6. 経営者は、期間より「自社が何に時間を使ったか」を見る

期間を決める前に、終える仕事を一つに絞る

終了日を決めるには、何が終われば今回の検証を区切れるかが必要です。分かるかどうかを確かめたいことと、確実に行う作業を分けます。

例えば、物流現場の問い合わせ対応を支援するサービスを検証するとします。これは編集部が作成した架空のモデルで、実際の支援案件や標準的な検証期間を示すものではありません。

今回の問いは、「指定した問い合わせについて、担当者が業務に使えるか」です。すべての問い合わせへの対応や、他拠点への導入まで同じ検証へ入れると、準備する情報と評価する作業が増えます。

最初の計画では、対象の問い合わせ、利用する現場、評価する人、提出する結果を固定します。検証中に別の用途が見つかったら、次に検討する候補として記録し、今回へ追加するかは別に判断します。

短くするだけで、必要な利用の場面を飛ばさない

必要な期間は、作る時間だけでなく、実際に使う機会にも左右されます。月末にだけ発生する業務を試すなら、その時期を含まない短い検証では、実際の使い方を確認できません。

一方、今ある資料と標準機能で確認できる問いなら、現場の本番利用を待たずに先へ進める場合があります。今回何を確かめるかを選び、開発・利用待ち・報告のどこを短縮できるかを考えます。

終了日が先に指定された場合は、その日までに確認できる範囲を返します。未確認の用途まで成功と報告するのではなく、確かめたことと次の利用機会で確かめることを分けましょう。

準備・試行・報告を分けると、待ち時間が見える

検証にかかる期間と、自社が実際に作業する時間は一致しません。大企業側の情報提供や現場の準備を待つ時間も、日程には影響します。

どの区間にも、開始条件と担当者を置きます。「契約した日から検証期間を数える」とする場合も、必要な情報が届く前に何ができるかを確認してください。

例えば、前述の問い合わせ支援では、対象とする問い合わせの記録が提供されない間に、自社が設定を完成させることはできません。資料が届く予定日と、受け取った後の確認作業を計画上で分けます。

公正取引委員会・経済産業省の指針は、PoCの目的と、何が報告されれば仕事が完了するかを明確にする方向性を示しています。共同研究開発へ進む技術検証の説明を、今回の区切りを考える参考として使えます。事業連携及び出資に関する指針

期間の相場や、すべてのPoCに共通する工数が、この指針で決まるわけではありません。自社の提供方法と、相手の準備に合わせて計画する必要があります。

開発工数に、会議と問い合わせの時間も入れる

見落としやすいのは、作る仕事の外側にある対応です。確認の会議、データの不足を聞く連絡、現場からの問い合わせ、結果の説明も担当者の時間を使います。

経営者は、担当者へ「開発に何時間かかるか」だけでなく、「この案件を進めるために、期間全体で何を担うか」を聞いてください。社長が参加する調整の時間も、自社の負担から外さないようにします。

以下は、問い合わせ支援サービスの検証に使う工数表の記入例です。各欄には自社の見積を記入し、実績値や業界の標準値として扱わないでください。

表の空欄をすべて同じ日に埋める必要はありません。不確実な作業は、どの情報があれば見積もれるかを記し、相手へ確認してから計画を更新します。

自社で確保できる工数から、無理な終了日を逆算しないことも必要です。担当者が別の顧客対応を抱えている場合は、その予定と両立する計画かを社内で確認します。

例えば、開発担当者を実際の試行に集中させたいなら、日程調整や一般的な問い合わせは事業担当が受ける方法があります。その分担で処理できる内容と、開発担当へ渡す必要がある内容を決めてください。

計算モデル：4週間の検証でも、担当者の工数は別に数える

以下は工数の数え方を示す架空の数値モデルです。問い合わせ支援の設定を18時間、資料確認を4時間、結果整理を4時間と仮置きします。

定例会を1時間ずつ3回、毎回自社の2人が参加するなら、会議は3時間ではなく6人時です。この例の合計は18＋4＋4＋6＝32人時で、経過期間の4週間とは別の量になります。

この4週間を、次の予定へ仮置きします。週単位の区切りも架空のモデルです。現場の利用機会が週3にあることと、必要な資料が週1にそろうことを前提にしています。

週1の資料提供が遅れれば、週2の設定と、その後の試行・報告も動きます。週3の利用機会を逃すと、次に対象業務が発生する時期まで待つ場合もあります。終了日を据え置くなら、確認範囲の変更と未確認事項を相談します。試行中に自社の個別対応が必要なら、その工数は32人時へ追加して見積もってください。

準備資料が追加されたら何時間増えるか、別部署の会議に何人出るかも同じ単位で足します。自社の予定表では各担当者の時間を分け、社長の調整時間を開発担当の工数へ混ぜないようにします。

この32人時には、未定の追加開発や新しい拠点の問い合わせを含めていません。モデルの数字を見積の標準にせず、自社の実作業と担当者で置き換えることが使い方です。

待っている間に、別の仕事を無償で積み増さない

相手の準備待ちが生じたときは、先に進める仕事と、今は着手できない仕事を分けます。待っている間の追加分析や別のデモが、自動的に元の対応範囲へ入るわけではありません。

予定より情報提供が遅れた場合は、「受領後に必要な確認があるため、試行開始と報告の日程を見直したい」と伝えられます。終了日だけを据え置くなら、対象や報告する内容を調整する必要がないかを相談します。

自社が担当者を空け続けることも、他の案件に使えない負担です。いつまで待てるか、再開時に同じ担当者を確保できるかを社内で確認し、必要なら着手予定を再調整しましょう。

イノベーション総研は、相手の返信を急かすだけでなく、予定変更がどの仕事に影響するかを示すことを勧めます。実施日と担当者の手配が結びついていると分かれば、相手も社内で確認する理由を説明しやすくなります。

まだ分からない作業には、見積の条件を残す

情報の形式や品質が未確認なら、見積を一つの確定値で埋めない方がよい場合があります。「合意した形式の資料を受け取ること」「追加の整理が必要なら作業を協議すること」を前提へ入れます。

自社で予備の時間を確保する場合も、その時間を使えば何でも対応すると相手へ約束しません。予定内の調整に使う枠と、目的や対象が増えたため別途相談する作業を区別します。

「既存の対象を終えるための設定調整は計画内で対応します。新しい問い合わせ分類の追加は、評価項目と必要工数を整理してから相談したい」と伝えれば、依頼の種類と対応を合わせられます。これは編集部作成の交渉例です。

上限に近づいたら、終える前に選択肢を出す

工数の上限は、使い切った後に知らせるだけでは機能しません。残った仕事と、使える工数を比較する確認の機会を置きます。

確認では、予定していた時間、使った時間、終えるために必要な時間を活動別に見ます。時間を使った原因が分からないまま、総工数だけを追加しても、同じ追加対応が続く可能性があります。

例えば、設定が予定より重い場合は、必要な資料が不足したのか、自社の想定が合わなかったのか、対象が増えたのかを分けます。工数の記録は担当者を監視するためではなく、次の範囲を決めるために使います。

前述のモデルで、対象外の問い合わせも評価したいと言われた場合を考えます。既存の評価を終えるための時間と、新しい対象を試す時間を分けたうえで、次の選択肢を示せます。

• 今回は合意した対象で終え、別の問いは次の検証に回す。
• 優先度の低い作業を減らし、追加したい対象へ工数を移す。
• 期間・作業・費用を変更し、追加の発注として進める。

いずれを選ぶかは、検証の目的と、相手が判断したいことによります。変更を決める人と、発注・契約上の手続きを確認し、現場担当者の依頼だけで上限を広げないようにしてください。

経営者は、期間より「自社が何に時間を使ったか」を見る

企業むすびの見解：延長の価値と、専用対応の負担を比べる

私たちは、追加工数の判断では、これから何が分かるかと、誰のための作業が増えるかを合わせて見ることを勧めます。終了直前まで使った時間の大きさだけでは、さらに時間を使う理由にならないためです。

追加の利用機会で主要な問いを確かめられるなら、費用と参加者を合わせて延長を相談できます。毎回別の部署の要望へ対応し、最初の問いの答えが増えないなら、今回を区切って次の案件として検討する方が、製品開発の配分を考えやすくなります。

検証が長引いたとき、期間だけでは原因を判断できません。開発・試行・報告に使った時間と、相手の確認を待っていた時間を分けて振り返ります。

想定外の工数が、サービス自体の問題によるものか、個別の要望によるものかも確認します。同じ顧客以外にも使える改善なら、プロダクトへの投資として扱う判断もできますが、相手の専用対応は案件の採算として見ます。

次の検証計画には、終了日だけでなく、開始条件、活動別の担当、工数上限、変更を判断する機会を書きましょう。見積として相手へ提示する方法は、公開コラムの有償PoCの提案方法で確認できます。