PoCの要件定義とは？RPA・DXで「試して決める」進め方

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

PoCの要件定義とは？いつもの要件定義と違うところ

PoC（概念実証）は、本格導入の前に小さく試して、実現できるか、効果があるかを確かめる取り組みです。

いつもの要件定義（RD：Requirements Definition）は、作るものを決めて合意する工程ですよね。

一方でPoCは、作る前の段階で「そもそも作る価値があるか」を確かめる場なんです。

だからPoCの要件定義では、機能の一覧よりも、確かめたいことと合格の基準が主役になります。

要件定義そのものの意味は、要件定義とは？意味をわかりやすく解説で確かめられます。

RPA・DXとの関係

RPAは、パソコン上の決まった操作をソフトウェアのロボットで自動化することです。

DXは、デジタル技術で業務やビジネスのやり方そのものを変えることを指します。

RPAもDXも、いきなり全社に広げず、まずPoCで小さく試してから進めることが多いですよね。

そのため、PoC・RPA・DXの要件定義は、まとめて考えるとつながりが見えやすくなります。

PoC・RPA・DXは「試して決める」部分が多い：検証のゴール設定表

『PoCなんだから、やってみてから考えればいいのでは？』と思う方も多いはずです。

半分はその通りです。ただ、何を見れば判断できるかを決めずに試すと、結果の受け取り方が人によってばらばらになってしまいます。

そこで使いたいのが、次のような検証のゴール設定表です。

「合格の基準」は、数字で言えるなら数字で決めます。

数字で言いにくい時は、上の例のように「手入力と比べて」など比べる相手を決めておくと、判断がぶれにくくなります。

ゴールが決まっていない時の会話

ゴールが決まっていないと、PoCの終わりにこんな会話になりがちです。

「一応読み取れました。精度もそこそこだと思います」と開発側が報告します。

「そこそこ、というのは、本格導入していいということですか？」と発注側が聞き返します。

この会話を防ぐのが、試す前のゴール設定なんです。

PoCの要件定義の進め方と、PoC計画の記入例

PoCの要件定義は、次の流れで進めるとまとまりやすくなります。

5番目の「最低限の機能と品質の条件」は、本番ほど細かく決めなくて大丈夫です。

ただ、使うデータの扱いだけは、試すだけでも本番と同じ慎重さで決めておきましょう。

PoC計画の記入例

ここでは架空の題材として、「設備の手書きの点検記録を、写真から読み取って入力する仕組みをPoCで試す場合」で書いてみます。

「作らないもの」を書いておくと、試している途中で機能がふくらむのを防げます。

『あれもついでに試したい』という声は、たいてい途中で出てきます。そんな時は「次のPoCの候補」として別にメモしておくのがおすすめです。

PoCの期間と体制は、どう決める？

PoCの期間は、確かめたいことを確かめるのに足りる長さで決めます。

例えば点検記録の読み取りなら、晴れの日と雨の日、慣れた人と慣れていない人の記録がひと通りそろう期間が要りますよね。

体制は、作る人だけでなく、試しに使って意見を出す利用部門の担当者を入れておきましょう。

利用部門が入っていないPoCは、技術的には合格でも、現場で使われるかどうかが分からないまま終わってしまいます。

PoCの後、本番の要件定義にどうつなぐ？

PoCで合格しても、そのまま本番に使えるわけではありません。

PoCでは作らなかった権限の管理や連携、非機能要件は、本格導入の要件定義で改めて決めます。

本格導入の進め方は、システム導入・構築の要件定義でも詳しく扱っています。

RPAの要件定義と、RPAの要件定義書の書き方

RPAの要件定義は、普通のシステムの要件定義よりも、操作の手順に近い細かさが必要になります。

ロボットは、人なら自然にできる「いつもと違うから確認しよう」という判断ができないからなんです。

『手順書があるから、それを渡せば大丈夫では？』と思うかもしれません。

ただ、人向けの手順書には、慣れた人の判断が書かれていないことがよくあります。要件定義でRPA化する時は、その判断を言葉にするところから始めましょう。

RPAの要件定義書の記入例

ここでは架空の題材として、「毎月、取引先ごとに請求書のファイルを作り、決まった宛先に送る作業をRPAで自動化する場合」で書いてみます。

RPAの要件定義書では、特に「例外の扱い」と「止まった時の扱い」の2行が大事です。

ここが空欄のままだと、ロボットが止まった時に、誰も気づかないまま月末を迎えることにもなりかねません。

慣れた人の判断を聞き出す会話例

人の判断を言葉にするには、手順を聞くだけでなく「いつもと違う時」を聞くのが近道です。

「請求書を作る時、手を止めて確かめることはありますか？」と開発側が聞きます。

「宛先が変わったと連絡があった取引先は、一覧を直してから送っています」と利用部門が答えます。

この一言から、「宛先の一覧を直す作業が先に終わっていること」が、ロボットを動かす前の条件だと分かります。

自動化に向く作業、向かない作業

RPAの要件定義に入る前に、その作業が自動化に向いているかを見ておくと手戻りが減ります。

向いていない作業でも、手順をそろえたり判断の条件を決めたりすれば、向く作業に変えられることがあります。

その場合は、RPAより先に業務の見直しを要件として決めておきましょう。

DXと要件定義：業務の変え方から決める

DXと要件定義の関係で迷う方も多いですよね。

DXの要件定義でつまずきやすいのは、今の手作業をそのままデジタルに置き換えて終わってしまうことです。

例えば、紙の申込書をそのまま画面に写しただけでは、記入の手間も確認の手間もほとんど変わりません。

DXでは、「そもそもこの確認は要るのか」「誰がいつ入力すれば一番手間が少ないか」から考え直すんです。

今の業務と目指す業務を比べる方法は、要件定義の業務分析（As-Is/To-Be）で詳しく解説しています。

DXの要件定義で先に決めること

IPAの「ユーザのための要件定義ガイド 第2版」でも、DXの流れの中で、業務部門の利用者が主体的に要件定義に関わる必要が増している、という問題意識が書かれています。

DXの要件定義の記入例

ここでは架空の題材として、「紙の申込書で受けている会員登録を、オンラインの受付に変える場合」で考えてみます。

画面に写すだけで終わらせないために、今のやり方と変えた後のやり方を並べて書くのがコツです。

『入力の画面さえ作れば、それでDXなのでは？』と思われがちですよね。

ただ、表の「やめる作業」の行が空欄のままなら、手間はほとんど減っていません。やめる作業が書けているかを、DXの要件定義の確かめどころにしてみてください。

業務を一番よく知っているのは、業務部門の担当者です。開発側に任せきりにせず、業務部門が「どう変えたいか」を言葉にしていきましょう。

よくある相談に答えます

SE職ではないのに、開発資料を作ることになった

業務部門の担当として、運用の仕組みを作る資料を任されて悩んでいる、という相談があります。

『専門の書き方を知らないから、作れる気がしない…』と感じるかもしれません。

結論から言うと、最初に書くのは専門的な設計書ではなく、「何に困っていて、どうなれば良いか」です。

この記事のゴール設定表や、RPAの要件定義書の記入例の項目を埋めるだけでも、開発側が読める資料になります。

マクロやVBAから離れたい時は、何から決める？

表計算ソフトのマクロやVBAで作った仕組みが増えすぎて、作った人しか直せない、という悩みもよく見かけます。

まず、今あるマクロを一覧にして、それぞれ「何の業務の、どの作業を助けているか」を書き出してみてください。

その上で、残すもの、やめるもの、別の仕組みに置き換えるものに分けます。

置き換える先がRPAなのか、業務システムなのかは、上の「自動化に向く作業、向かない作業」の表で考えると決めやすくなります。

RPAの開発を続けているが、この先に要る経験は？

RPAのロボット作りを続けているが、キャリアのためにどんな経験を積めばいいか、という相談もあります。

RPAの経験を生かすなら、作る作業だけでなく、要件定義に関わる経験を増やしていくのがおすすめです。

利用部門から作業の手順と例外を聞き出し、RPAの要件定義書にまとめる経験は、他のシステムの要件定義にもそのまま生きます。

要件定義の力を身につける順番は、要件定義のスキルを未経験から身につける方法でも紹介しています！

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

プロジェクトの要件定義とは？システム導入・構築で詰めること

要件定義のAs-Is/To-Be分析とは？業務分析のやり方と記入表