当社の中でも最近POC（Proof of Concept）として、実証実験サービス作っても失敗ばかりだから、もうPOCはやめた方がよいのでは？
なんて意見も出ているようです。
まぁ、POCの定義の問題だけとは思いますが…
当然プロトタイプ作って、市場に出して検証します！って形なんですが…
「検証サービス投入」
→「機能検証」
→「フィードバック」
→「機能改修」
→「本サービス」
って計画にして始めないといけない様になってるんですよね。。
これだと、基本的には市場に受け入れられてあと少し機能が足りないって企画じゃないと成功したって言えない条件設定にしてるので結果失敗ばかりと捉えてしまうのです。
そう、機能検証のイメージで計画してるので『失敗感』がでちゃうんです。
POCにするくらいなんで機能的にはある程度利用者が便利になるってわかってるはず。
問題はその便利さの広げ方なんです。
うまく広がらない理由を機能に求めると、
「さらにお金かけて機能的追加するか？」
「その時はちゃんと広がるのか？」
との判断をせざる得なくなってみんな苦しくなってきます(T_T)
だから、イメージ的には機能検証じゃなくて、有用性検証とでも言うのか…「利用者に対して便利さを拡げれるかどうかの検証」を行った方がよいです。
検証サービス投入
→【有用性検証】
→【進め方・機能再検討】
→再度市場へ投入
→ 繰り返し
こんなサイクル(^^)
POCとして最初に作ったあと、結果を踏まえて次に考える事は
「どうしたらより使ってもらえるか？」とかの『広げかた』の方で、その方向性で検証した結果、機能はそのままでもよかったりします。
または、POCやってみて機能は今作っているものじゃなくて、全く別の機能の方がいいんた！間違ってた！
ってわかったりします。
その時は、その新しい気付きのあった機能のプロトタイプを作って再度勝負です。
一個目のPOCは失敗じゃなくてアップデートです(^^)
この場合一個目はムダだとかの意見もでますが、天才かとんでもな強運の持ち主以外、無駄なくピンポイントで売れるサービス作るとかは出来ません。
文句言う人はやってみろ！って感じです(^^)
ただ、会社の資金は有限だし、気持ちではドンドンやらせたいけど、ムダ使いはできないのは確かですよね。
ムダ使いが多いときは…
①POCの数を減らす
②一つのPOCにかける費用を下げる
しか無いのですが…
これは迷いなく②とすべきです(^^)
POCにかける費用とにかく安くしてもよいです。プロトタイプは工作レベルでやればよいのです。
手術の内視鏡の道具の開発では、ガンタイプの道具が便利との意見があった時に、洗濯ばさみと紐とテープでプロトタイプ作って、それで一気に意見の収集を行ったようです。
何か思いついたものは工作レベルで作ってみる。
そこから始まりで、それが、POCで良いのです。
ただシステムを世にだそうと思うと、工作レベルというレベル感ってどんなもの？って感じですよね？
これは私もわからない…
こんなコラム書いておいて何ですが、
私が今やってるプロジェクトも、POCですがまぁまぁちゃんとしたもの作る予定です。（笑）
言うが易し状態で企業の中でやるには難しいですね。
でも
一人で3日間くらいで作ってしまったシステムとか…
そこから始まる物語はきっとあります(^^)
それを企業として普通に推奨できるようになることを目指していきます(｀･ω･´)ゞ
※やり方は知らんけど…（笑）
0コメント