0
◆DXとPoC
今までに経験のないDX（デジタル・トランスフォーメーション）のような新しいシステムでは、システム企画とPoCが重要です。
AIやIoTその他のテクノロジーを活用するのは初めてという企業や団体も多いので、それらの有効性を検証するPoCは必須の活動です。
PoCはProof of Concept（概念実証）の略称です。以前は実証実験や仮説検証などと呼ばれていました。
ここでは、PoCを成功させるための考え方、進め方、手順などを、やや難易度の高いIoTシステムを例として解説していきます。
◆システム企画とPoC
システム企画は要件定義の前に位置する工程です。
細かく分けると、システム全体の「システム化構想立案」、開発工程の詳細を計画する「システム化計画」、それら以前あるいは並行しての「業務分析」があります。
PoCはシステム企画のなかでも重要な位置にあり、システム企画と並行して進めます。初めて利用するデバイスやソフトウェアなどであれば、事前の学習も必要です。
それぞれのプロセスは以下のとおりです。
・業務分析（ビジネス企画）
現行の業務や将来の業務の想定をして、適切なシステム構成、デバイス、ネットワーク、サーバー（クラウドやオンプレミス）の検討や選定をします。
必要なデータと取得の方法、取得したデータの活用法などの見極めもします。
新たなサービスやビジネスを検討しているのであれば、この時点でビジネスの企画が見えている必要があります。
・システム化構想立案
システムの対象となる範囲、どれくらいの期間利用するか、投資額とコスト、目指すところは何かなど、基本的ですがきわめて重要な項目を明らかにします。
・システム化計画
業務分析とシステム化構想立案にしたがって、システム開発や運用の計画を立案します。
なお、それぞれの工程での検討や判断の根拠としてドキュメントを作成して残しておくことが重要です。
◆PoCの目的
PoCの目的を簡単にいえば、やりたいことが実現できるかどうかの確認と検証です。
結果的に実現できないこともありますが、それを許容しつつ実現できる手段を見つけるのもPoCの醍醐味です。
PoCを必要とするような新たなシステムの企画の初動では、「おそらくこのようなしくみで実現できるだろう」という仮説から入ります。
◆「おそらく」であることの理由
PoCに着手する前に、このおそらくとなることの理由を明確にしておくことが重要です。仮説や憶測になるには以下のような理由が考えられます。
あらかじめ、どの理由あるいは状況に近いかを確認して、PoC以前の問題には対処するようにします。
・デバイスや関連する技術の把握ができていない
PoCの実施に関して最も多い理由です。実際の現場で性能が出せるか、現実に設置が可能かなどです。候補となるデバイスや技術の事前学習である程度の解決は可能です。
・実際の現場や利用シーンを見ていない
システムを求めるユーザー、企画者、開発者など、それぞれ立場が異なるので、実際の現場を見ていない、あるいは現場に行ったことがないと自信はもてないものです。
・ユーザーの要求が不明確
ユーザーの要求が部分的に曖昧である、全体としてよくわからないなどのケースです。この場合はPoCよりもユーザーの要求を明確にすることを優先すべきです。
・業務そのものを知らない
システムを企画・開発する側が、業務を理解していないというケースです。これも事前に学習することで対応はできます。
・アイデア形成のヒントとして利用
上記の4つとは別の観点です。まずはPoCを実施して、その結果をもとにして考えるという進め方です。ただし、この手法ではPoCだけで終わってしまうことが多いので注意が必要です。
◆PoCで検証したいこと
PoCの検証は、「やりたいことが実現できるか」、「実現できるとしたときに要求とそれを満たす手段は」の順に進めていきます。
重要なのは、やりたいことでとどまらずに、具体的な要求にブレークダウンすることです。この例では10秒という仮説を持っていますが、具体的な基準値がないと前に進めることができません。
◆検証のポイント
ここまでを踏まえて、検証のポイントは以下のとおりです。
(1)要求を実現できるかできないか
(2)実現できるとした場合にどれくらいの性能が出せるか
（レスポンス、処理量、エラー率、ほか）
ただし、実際のシステム化を考える場合には、次のポイントも重要です。
(3)そのシステムは本当に必要か
現行システムに手を加える、あるいは別の方法のほうが簡単に実現できることもあります。例えば、人を若干名増やすほうがシステム化するよりもトータルコストがはるかに安いこともあります。
(4)実際にシステムとして長期にわたって動作するか
ユーザーの業務にどれくらいの影響があるか、既存設備との整合性、環境、開発の可否と難易度、稼働後のメンテナンス、費用などの視点で確認します。
（IoTシステムなどでは、電力や配線の問題、現場の温度とデバイスの動作温度、保守スペースなど、細かく確認します。）
PoCで検証するという考え方だけで見ると、(3)と(4)の2つは忘れがちなポイントです。
PoCはシステム企画に対して修正をかけることができる最後の砦でもあるので、このようなポイントも重要です。
◆検証項目の例
IoTシステムを例として、検証項目を確認しておきます。現場での実施は1日や2日で行うことが多いので効率的に進めます。
◆準備作業の例
現場でのPoCをスムーズに実施するためには準備作業が不可欠です。現実には各種のシートやチェックリストなども作成して持ち込みます。
◆PoCのスケジュール
PoCは見た目にはごく短期に感じられますが、それは現場での検証が1日や長くて2，3日であることによります。
しかしながら、現実には前工程としての準備作業、後工程としての分析や評価があります。
スケジュールの例は次のとおりです。
頭の中にこのような線表を持ちながら、先ほどの検証項目や準備を進めてください。
◆PoCの評価
重要な視点は検証のポイントで解説しました。
システムの企画者や開発者の立場になると、システムとしての動作や性能に注意がいきがちです。
しかしながら、動作して性能が発揮できるとしても、日常的に運用できるかどうかは別の話です。
最後に、必ず忘れないように運用できるかどうかの視点で評価します。