.svg)
実証実験は成功した。それから動いていない。
報告書は出ました。経営にも説明しました。それから一年、そのままになっています。原因は技術ではないことがほとんどです。止まる理由は数が限られていて、たいてい最初の設計に埋まっています。
- PoC（実証実験）
- PoC とは Proof of Concept、実証実験のことです。技術的に実現できるかを小さく確かめる段階を指します。本番運用とは求められるものが違い、そこに落差が生まれます。
止まる理由は、だいたい5つです。
どれも実証実験の最中には見えません。見えないように設計されているからです。
合格の基準が「動いた」だった
画面が出て、それらしい答えが返ってきた。それは技術の確認であって、業務が変わるかどうかの確認ではありません。何時間減るのかを最初に決めていないと、続ける根拠が出せません。
きれいなデータで通した
実証実験には整った資料を用意します。本番に来るのは、書式がばらばらで、抜けがあって、古い版が混ざったものです。ここで精度が落ち、話が止まります。
運用する人が決まっていない
誰が索引を更新し、誰が問い合わせを受け、誰が精度の低下に気づくのか。情報システム部と現場のあいだで宙に浮いたまま、静かに使われなくなります。
既存システムとの接続が後回し
実証実験では手作業でデータを入れます。本番では基幹システムや文書管理とつながないと使われません。この工数が最も読みにくく、見積りが二度手間になります。
間違ったときの責任が未定
明らかに誤った出力が出たら、誰が止めるのか。承認はどこで挟むのか。これが決まっていないと、本番の稟議は通りません。技術ではなく、この一点で止まっている案件をよく見ます。
ついでに言えば
この5つは、実証実験を始める前に決めておけるものばかりです。あとから足すのが難しいだけで、最初に置いておけば費用はほとんど変わりません。
続けるか、やめるか、順番を変えるか
止まっている案件をすべて動かす必要はありません。業務への効きめと、実装の確からしさで並べ直します。
すぐ本番へ
足りないのは接続と運用体制だけです。数週間で動き出します。ここから着手します。
検証をやり直す
実データの例外を入れて、精度がどこまで落ちるかを先に見ます。落ちどころが分かってから設計します。
あとで
作れることは分かっています。急ぐ理由がないので、順番を下げます。
やめる
ここに入るものは畳みます。やめる判断を出すのも仕事のうちです。
7つの段階
各段階の終わりに、続けるかどうかを決められます。途中で止めても、そこまでの成果物はお渡しします。
段階を分けているのは、途中でやめられるようにするためです。まとめて発注してしまうと、途中で気づいた不都合を口に出しにくくなります。
相談
今どこで止まっているか。前の実証実験の資料があれば拝見します。
見極め
効きめと確からしさで並べ直し、着手する順番を決めます。
設計
合格の基準、停止条件、運用の担当者をここで文書にします。
実装
例外を含む実データで作ります。接続は最初に済ませます。
レビュー
現場の方に実際に使っていただき、直すところを洗い出します。
検収
段階3で決めた基準に照らして確認します。基準はあとから動かしません。
運用
手順書をお渡しし、貴社の担当者に操作していただきます。
実証実験のときに、先に決めておくこと
公開している3件は、いずれも運用中です。
実証実験で終わったものを事例として出すことはしていません。掲載しているのは、引き渡しが済んで、お客様側で動いているものだけです。
会議の記録を扱う仕組みは、書き起こしから担当者の割り当てまでを毎日処理しています。多言語のナレッジ検索は、日本語とタイ語の資料を横断して使われています。イベント運営の仕組みは、実際の催行に使われています。
ケーススタディの一覧に、それぞれの構成と数字をまとめています。
5つの問い
止まっている案件について、この中の3つに即答できない場合は、設計から見直す価値があります。
- 何がどれだけ減れば成功でしたか。数字で決めていましたか。
- 本番のデータで試しましたか。用意した資料ではなく、現場にあるままのもので。
- 運用する人は決まっていますか。部署名ではなく個人まで。
- 既存システムとつなぎましたか。手作業でデータを入れていませんでしたか。
- 誤った出力が出たら誰が止めますか。その手順は書かれていますか。
PoCから本番へ：よくある質問
あわせて読む
止まっている案件を、そのまま見せてください。
30分あれば、続ける価値があるかどうかの見立てはお出しできます。畳んだほうがよい場合は、そう申し上げます。