大企業とのPoCの期間は、検証したいこと、開始に必要な準備、自社が使える工数をそろえて決めます。PoCは本格導入や連携に向けた小規模な検証であり、他社が何か月実施したかだけでは、自社の必要期間は分かりません。
スタートアップが特に確認したいのは、終了日だけでなく、期間中にどの担当者がどこまで対応するかです。「期間内なら何度でも相談できる」という認識が生まれると、同時に進めるプロダクト開発や顧客対応を圧迫します。
工数は、その仕事に使う作業時間です。一人が作業する時間と、複数人が同時に参加する会議の時間を分け、同じ単位で集計して見積と実際を比べます。
期限と工数の上限を置き、情報の提供が遅れた場合や、追加の検証を求められた場合の見直し方まで相談しましょう。ここでは、料金の提案ではなく、自社の開発時間を配分するための計画を扱います。
目次
期間を決める前に、終える仕事を一つに絞る
終了日を決めるには、何が終われば今回の検証を区切れるかが必要です。分かるかどうかを確かめたいことと、確実に行う作業を分けます。
例えば、物流現場の問い合わせ対応を支援するサービスを検証するとします。これは編集部が作成した架空のモデルで、実際の支援案件や標準的な検証期間を示すものではありません。
今回の問いは、「指定した問い合わせについて、担当者が業務に使えるか」です。すべての問い合わせへの対応や、他拠点への導入まで同じ検証へ入れると、準備する情報と評価する作業が増えます。
最初の計画では、対象の問い合わせ、利用する現場、評価する人、提出する結果を固定します。検証中に別の用途が見つかったら、次に検討する候補として記録し、今回へ追加するかは別に判断します。
準備・試行・報告を分けると、待ち時間が見える
検証にかかる期間と、自社が実際に作業する時間は一致しません。大企業側の情報提供や現場の準備を待つ時間も、日程には影響します。
| 区間 | 必要な仕事 | 次へ進むための条件 |
|---|---|---|
| 準備 | 対象の確定、情報提供、利用環境と担当者の確保 | 合意した情報と環境が使える |
| 設定・確認 | サービスの設定、使い方の確認、評価方法の共有 | 現場で試せる状態になる |
| 試行 | 合意した業務で利用し、状況を記録する | 必要な対象と条件で試行できる |
| 整理・報告 | 結果と未確認の条件を整理する | 合意した結果を提出し、次の判断を相談する |
どの区間にも、開始条件と担当者を置きます。「契約した日から検証期間を数える」とする場合も、必要な情報が届く前に何ができるかを確認してください。
例えば、前述の問い合わせ支援では、対象とする問い合わせの記録が提供されない間に、自社が設定を完成させることはできません。資料が届く予定日と、受け取った後の確認作業を計画上で分けます。
公正取引委員会・経済産業省の指針は、PoCの目的と、何が報告されれば仕事が完了するかを明確にする方向性を示しています。共同研究開発へ進む技術検証の説明を、今回の区切りを考える参考として使えます。事業連携及び出資に関する指針
期間の相場や、すべてのPoCに共通する工数が、この指針で決まるわけではありません。自社の提供方法と、相手の準備に合わせて計画する必要があります。
開発工数に、会議と問い合わせの時間も入れる
見落としやすいのは、作る仕事の外側にある対応です。確認の会議、データの不足を聞く連絡、現場からの問い合わせ、結果の説明も担当者の時間を使います。
経営者は、担当者へ「開発に何時間かかるか」だけでなく、「この案件を進めるために、期間全体で何を担うか」を聞いてください。社長が参加する調整の時間も、自社の負担から外さないようにします。
以下は、問い合わせ支援サービスの検証に使う工数表の記入例です。各欄には自社の見積を記入し、実績値や業界の標準値として扱わないでください。
| 活動 | 自社の担当 | 工数を見積もる前提 | 上限を変える条件 |
|---|---|---|---|
| 対象・情報の確認 | 事業担当と開発担当 | 対象業務と提供資料の範囲 | 問い合わせの種類や資料の形式が増える |
| サービスの設定 | 開発担当 | 必要な設定と確認項目 | 個別の機能開発が追加される |
| 現場からの問い合わせ | 事業担当 | 受付方法、対応時間、確認する内容 | 利用者や対象拠点が増える |
| 定例会・説明 | 事業担当 | 開催回数と準備する資料 | 別部門向けの説明が追加される |
| 評価結果の整理 | 開発担当と事業担当 | 合意した評価項目と報告形式 | 追加分析や詳細な報告を求められる |
表の空欄をすべて同じ日に埋める必要はありません。不確実な作業は、どの情報があれば見積もれるかを記し、相手へ確認してから計画を更新します。
自社で確保できる工数から、無理な終了日を逆算しないことも必要です。担当者が別の顧客対応を抱えている場合は、その予定と両立する計画かを社内で確認します。
例えば、開発担当者を実際の試行に集中させたいなら、日程調整や一般的な問い合わせは事業担当が受ける方法があります。その分担で処理できる内容と、開発担当へ渡す必要がある内容を決めてください。
待っている間に、別の仕事を無償で積み増さない
相手の準備待ちが生じたときは、先に進める仕事と、今は着手できない仕事を分けます。待っている間の追加分析や別のデモが、自動的に元の対応範囲へ入るわけではありません。
予定より情報提供が遅れた場合は、「受領後に必要な確認があるため、試行開始と報告の日程を見直したい」と伝えられます。終了日だけを据え置くなら、対象や報告する内容を調整する必要がないかを相談します。
自社が担当者を空け続けることも、他の案件に使えない負担です。いつまで待てるか、再開時に同じ担当者を確保できるかを社内で確認し、必要なら着手予定を再調整しましょう。
イノベーション総研は、相手の返信を急かすだけでなく、予定変更がどの仕事に影響するかを示すことを勧めます。実施日と担当者の手配が結びついていると分かれば、相手も社内で確認する理由を説明しやすくなります。
上限に近づいたら、終える前に選択肢を出す
工数の上限は、使い切った後に知らせるだけでは機能しません。残った仕事と、使える工数を比較する確認の機会を置きます。
確認では、予定していた時間、使った時間、終えるために必要な時間を活動別に見ます。時間を使った原因が分からないまま、総工数だけを追加しても、同じ追加対応が続く可能性があります。
例えば、設定が予定より重い場合は、必要な資料が不足したのか、自社の想定が合わなかったのか、対象が増えたのかを分けます。工数の記録は担当者を監視するためではなく、次の範囲を決めるために使います。
前述のモデルで、対象外の問い合わせも評価したいと言われた場合を考えます。既存の評価を終えるための時間と、新しい対象を試す時間を分けたうえで、次の選択肢を示せます。
- 今回は合意した対象で終え、別の問いは次の検証に回す。
- 優先度の低い作業を減らし、追加したい対象へ工数を移す。
- 期間・作業・費用を変更し、追加の発注として進める。
いずれを選ぶかは、検証の目的と、相手が判断したいことによります。変更を決める人と、発注・契約上の手続きを確認し、現場担当者の依頼だけで上限を広げないようにしてください。
経営者は、期間より「自社が何に時間を使ったか」を見る
検証が長引いたとき、期間だけでは原因を判断できません。開発・試行・報告に使った時間と、相手の確認を待っていた時間を分けて振り返ります。
想定外の工数が、サービス自体の問題によるものか、個別の要望によるものかも確認します。同じ顧客以外にも使える改善なら、プロダクトへの投資として扱う判断もできますが、相手の専用対応は案件の採算として見ます。
次の検証計画には、終了日だけでなく、開始条件、活動別の担当、工数上限、変更を判断する機会を書きましょう。見積として相手へ提示する方法は、公開コラムの有償PoCの提案方法で確認できます。