本文へ移動
フィリット・コンサルティング

Ctrl / ⌘ + K でも開けます

2文字以上入力すると検索します。

    Philit

    PoCの設計シート

    作り始める前に、確かめたいことと合格条件を書き出す

    PoCは「動くものを作ること」ではなく「分からないことを一つ減らすこと」が目的です。作り始める前に、合格条件を文章にしておきます。

    1. このPoCで確かめたい「分からないこと」を一つに絞る

    PoCがうまくいかない原因の多くは、確かめたいことが複数混ざっていることです。技術的に実現できるのか、業務に馴染むのか、費用が見合うのか。これらは別々の問いで、確かめ方も違います。まずは今回のPoCで答えを出したい問いを一つに絞り、疑問文の形で書き出してください。残った問いは別の機会に回すか、次のPoCの候補として書き留めておきます。

    • 今回答えを出したい問いを、疑問文で一つだけ書く
    • その問いに答えが出ないと、次に何が決められないかを書く
    • 今回は答えを出さない問い(技術・業務・費用のうち残るもの)を書き出す

    2. 問いの種類を見分ける

    問いの種類によって、必要な作り込みも、見るべき結果も変わります。技術の問いは小さな試作で足りることが多く、業務の問いは実際の担当者に触ってもらう必要があります。需要の問いは、そもそもシステムを作らずに確かめられる場合があります。自分たちの問いがどれなのかを先に見分けておくと、無駄な作り込みを避けられます。

    3. 合格条件を数字か観察できる事実で書く

    「うまくいったら本番化する」という合意は、実際には合意になっていません。人によって「うまくいった」の水準が違うからです。合格条件は、結果を見た人が全員同じ判定を下せる形で書きます。数字で書けるものは数字で、書けないものは「誰が何をできたか」という観察できる事実で書きます。この時点で「この条件は厳しすぎる/緩すぎる」という議論が起きるなら、それはPoCを始める前に済ませておくべき議論です。

    • 合格: この数値/この状態になれば、次の段階に進む
    • 不合格: この数値/この状態なら、今回の案は採らない
    • 判定できない: どちらとも言えない場合に何をするか(期間延長か、条件の見直しか)

    4. 検証の期間と使える工数を先に決める

    期間を決めずに始めたPoCは、成果が出ないまま延びていきます。先に終わりの日を決め、その中でできる範囲を設計してください。期間は問いの大きさで決まりますが、数週間から数か月の範囲に収めると、結果が出る前に事業の前提が変わってしまう事態を避けやすくなります。あわせて、社内の誰がどれくらいの時間を使えるかも書き出します。担当者が通常業務の片手間になる前提なら、その分だけ範囲を小さくする必要があります。

    • 開始日と、結果を持ち寄る日(判断の日)
    • 社内で関わる人と、一人あたり週に使える時間の目安
    • 外部に依頼する範囲(費用は案件により異なるため、範囲の合意を先に行う)

    5. 使うデータと環境を決める

    PoCの結果は、使ったデータの質に強く左右されます。きれいに整えたサンプルでうまくいっても、実際の業務データでは通用しないことがよくあります。可能な範囲で、実際に流れているデータに近いものを用意してください。同時に、個人情報や取引先の情報を含むデータをどう扱うかを先に決めます。検証用に匿名化するのか、限られた人だけが触れる環境に置くのか、終了後にどう消すのかまで含めて決めておきます。

    • 使うデータの出どころと、実際の業務データにどれくらい近いか
    • 個人情報・機密情報が含まれるか。含まれる場合の取り扱い方法
    • 検証用の環境をどこに置くか(本番と分けられているか)
    • PoC終了後に、データと環境をいつ誰が片付けるか

    6. 作る範囲を「合格条件を判定できる最小限」に削る

    PoCで作るものは、合格条件を判定するために必要な部分だけで足ります。ログイン画面、権限管理、見栄えの整ったデザインは、それ自体が問いでない限り不要です。逆に、判定に必要な記録の仕組みは省いてはいけません。何をしたか分からないままでは、結果を解釈できないからです。作る範囲を書き出したら、一つずつ「これが無いと合格条件を判定できないか」と問い直してください。

    • 判定に必要な画面・処理だけを列挙する
    • 手作業やスプレッドシートで代替できる部分を探す
    • 記録(誰が何をしたか、処理にどれくらいかかったか)は省かない
    • 本番に流用する前提かどうかを、開発担当者と先に合意する

    7. 判断の場と、その後の道筋を決める

    結果が出ても、判断する場が決まっていなければ宙に浮きます。誰が集まり、何を見て、その日のうちに何を決めるのかを、着手前に決めておきます。あわせて、合格した場合と不合格だった場合に、それぞれ次に何が起きるのかも書いておきます。「合格したら本番開発の見積りを取る」「不合格なら今回の案は取り下げ、別の問いに移る」といった具合です。ここまで書けたら、シートを関係者に配って、認識のずれがないか確認してください。

    • 判断の日に集まる人(決裁できる人が含まれているか)
    • その場に持ち込む資料(記録シート、数値、実際に触った人の声)
    • 合格した場合に、次に着手すること
    • 不合格だった場合に、やめること・残すこと

    この内容で相談したい

    チェックした内容をそのままフォームに貼り付けていただければ、そこから具体的な進め方と概算をお伝えします。

    無料で相談する

    関連するインサイト

    関連するサービス

    監修: フィリット・コンサルティング株式会社公開

    まずは、いま考えていることをお聞かせください

    アイデア段階でも、要件が固まっていなくても構いません。先進性・UX・コストパフォーマンスの観点で、次の一手を一緒に整理します。ご相談・お見積りは無料、通常1営業日以内にご返信いたします。

    無料で相談する

    資料の添付は、送信後に届く受付メールへの返信でお送りいただけます。

    ご相談は無料(30分・オンライン)
    企画書がなくても相談できます

    無料で相談する