本記事は
マネージャーWeek
1日目の記事です。
⚖
イベント告知
▶▶ 本記事 ▶▶
2日目
⚜
こんにちは、喜早です。
脈絡全然ないですが、最近本出しました。
GoogleのBIツール、Lookerの日本唯一(現時点)の入門書となります。 気になった方はぜひ。
さて、宣伝はこのくらいで。 今回はマネージャーウィークでのエントリーです。 ビッとした内容はこの後の皆さんが書いてくれると思いますので、私はライトにPoCの話でも書いてみようかなと思います。
Proof of Concept、略してPoC。 新しいアイディアや技術のフィジビリティ確認や効果について、実際にプロトタイプを作ったり、施策の展開範囲を限定して検証することを指します。 ポックと読んだりピーオーシーと読んだり呼び方は諸説あります。(私はピーオーシー派)
幸運なことに、私は過去、おもしろいPoCのプロジェクトにも色々携わらせてもらってきました。今回はその経験で得た知見を簡単に整理してみようかなと思います。
PoCのタイプ
ひと口にPoCといっても、その置かれた立ち位置によって大きく2つのタイプに分かれます。
- 事業化ロードマップ上の1フェーズ
コンセプト検討段階ですでに事業としては立ち上げたいと考えているものの、本当にモノが作れるのかどうかわからないからPoCとしてやってみる、というタイプのPoCです。この場合は、ある程度の制約がついたとしても、概ね狙い通りのものができそうな場合は事業化となります。
- 技術検証寄り
技術的にどんなことができるのか、どこまでできるのか、ということを検証するという目的でPoCを行う、R&Dに近いパターンです。業務に新しく技術やデバイスなどを取り入れようとする際の検討材料として行います。
PoCにおいて留意すべき点
どちらのパターンのPoCも経験してきましたが、良いPoCにできた場合に共通していたポイントを3点ほど挙げます。
目的を明確化する
PoCは色々実験的に行うことが多いために、つい、あれもこれもと試したくなってしまいがちです。しかし、殆どの場合、PoCは期間と予算が通常のプロジェクトよりも限定されています。そのため、その気持ちの向くままに進めていってしまうと、発散してしまい、本来の目的が検証できないアウトプットになってしまいがちです。そのため、検証内容を決める際には、常々、何を検証するためのPoCなのかということを意識し、発散のしすぎを抑制してくことが必要となります。
できるだけ早く触れるモノを作る
やはり人間はなにか具体的に触れる物があると一気にイメージが湧きます。事業化のロードマップ上にある場合はどういう物を作ればよいか具体化しやすいですが、技術検証の場合は難しいことが多いかもしれません。それでも、仮でもいいので、なにか事業や業務などをイメージして具体的なモノを作り、そこから派生させていったほうが、報告書だけのアウトプットよりも次の展開に広がりやすくなるでしょう。
PoCで作ったもの ≠ 製品版として出せるもの
PoCでの成果が認められたり有用だと判断されて、いざ事業化しようとしたときのことです。PoCで作ったものがあるからそれを使えば安く早く仕上がるのでは？ということをよく聞かれます。ですが、PoCは限られた期間内でコンセプトを検証することを目的に構築することがほとんどです。そのため運用を見据えたり、ソースコードの保守性を犠牲にして作ることが多々あります。要件としてはPoCで作ったものを拡張していけばできるものでも、事業化後も長くエンハンスしていくことを考えると、大なり小なり作りを見直し補修する必要があります。（ちなみにイラストは香港の九龍城砦です。保守性を犠牲にし続けるとこのビル群のようなガタガタなソースコードになってしまいます。写真のほうがもっと実感が湧くので興味がある方はググってみてください。）このあたりも計算に入れて、コストや期間の見積もりを行うと、ローンチ後の苦労を減らすことができるでしょう。ちなみにこのような技術的負債は早く返すほうがコストは小さく済みます。
PoCは新しいものへの挑戦ですので、やっている側としても楽しいのですが、やはりビジネス上の投資の一つでもあるので、成果も意識する必要があります。ここで書いたことがPoCに取り組まれる方の参考になれば幸いです。
