はじめに
ChatGPTを含む生成AIが2023~24年にかけて一気に普及し、とりあえず社内に配ってみるというフェーズから、企業内の具体的な取り組みで利用されるケースが多くなってきました。
まずはRAG等でのスポット的な社内情報の問合せへの適用が多いかと思いますが、やはり業務プロセスの自動化の文脈で使えるとインパクトがあり、今後は一定の業務範囲を任せるエージェント的な使い方がどんどん増えてくると思います。
RPAが登場した時の文脈で言えば、いわゆる定型業務にしか対応できなかったものが、LLMによって思考・言語能力も持つようになったので、いよいよ本格的なデジタルレイバー(仮想労働者)の活用フェーズに入ったとも言えると思います。
今回は、私がコンサルファームに転職した時からずっと自動化したいなと思っていた「業務ヒアリング」について、AIエージェントによる自動化を検討していきたいと思います。
そもそもなぜ業務ヒアリングを自動化したいのか？
いわゆるDX系のプロジェクト、特に業務系のBPRや自動化系のプロジェクトを進める場合、必ず必要になるのが「現状の把握（AsIs把握）」になります。
というのも、誰が今何をやっているのかというAsIsがわからないと、課題整理やToBe検討・ギャップ分析を含め、そもそも何も進められないからです。
効率化のための改善や抜本的な刷新、どちらの場合にも「今どうなっているのか」を把握する必要があります。
「自社の業務なんだからみんな把握してるんじゃないの？」と思う方もいるかもしれませんが、欧米のようないわゆるプロセスオフィス的な機能を持つ企業は少なく、実態としては、かなり実作業に近いレイヤの人しか実際の業務プロセスを把握していないというケースは多々あります。
実際、プロジェクトの組成フェーズにクライアント企業(管理職レイヤ)とディスカッションを始めるものの、その場にいる誰も現状がよくわかっておらず「AIを使って効率化できないか」など、抽象度の高い話に終始するという事はよくあります。特に総合職の方が、様々な部署をローテーションするケースなどではこの傾向が顕著になります。
この業界にいる人であれば「現場に聞いてもらわないとわからない」というセリフを何度も聞いた事があるのではないでしょうか。
業務がきちんと棚卸・管理されていて、業務マニュアルも一通り整備されていれば良いのですが、残念ながら多くのケースではこういった物が存在せず、実際に業務を実施されている方に聞かないとわからないというケースがほとんどでしょう。
こうして、業務のDX・自動化プロジェクトは、華やかなイメージのあるテクノロジーの活用検討ではなく、そもそもの現状を把握するために、現場の人達一人一人にヒアリングをして回るという、非常に泥臭い業務ヒアリングのプロセスから始まります。
非常に大変なこのAsIs把握のための業務ヒアリングですが、ここで重要な事は「AsIs把握自体は付加価値がゼロ」だという事です。
というのも、ToBeを検討・実装し、現状が改善するからこそ価値があるのであって、現状把握の段階では何も付加価値は生みだしていないためです。
本来、時間をかけるべきは付加価値を生みだすToBeの検討・実装プロセスであるものの、事実確認でしかないAsIs把握に大きな労力がかかっており、それ自体は付加価値を生まないこのプロセスは、あらゆるプロジェクトにおいて極力省力化、可能な限り自動化が望まれます。
もう少しこのモチベーションに対する解像度を上げるために、プロジェクト関係者のそれぞれの立場、①企業側のプロジェクト管理者、②コンサルティングファーム、③ビジネスアナリスト、④ソリューションアーキテクトの視点から見ていきましょう。
業務ヒアリングに関するそれぞれの立場
①企業側(プロジェクト管理者)の視点
企業側としては当然、それ自体に付加価値はない、この現状把握プロセスのコストは抑えたいと考えています。一方で、既に現業を抱えている社員にそれを追加でまとめさせる余裕はないケースも多く、また業務整理や業務フロー作成のノウハウがない現場の人達に可視化を依頼すると、成果物の粒度感がバラバラで、蓋を開けてみると、抽象度が高すぎたり逆に細かすぎたりと、必要な情報がわからないという事もよくあります。
指示された現場側としてもなんとなくは整理できるけど、これで良いのかどうか正直よくわからないというケースが少なくないでしょう。
AsIsの整理状況は、ToBe検討の品質にも直結するため、工数やスキル面含め、今一つ自分達では実施しきれないケースでは、業務の可視化・棚卸も含めてコンサルティングファーム等に依頼する事になります。
しかし、いわゆる大手のコンサルティングファームに頼むと、若手ですら一ヶ月数百万といったレンジになるので、ToBe検討や実装と違い、そこまで高度な専門性が必要なわけではない現状把握・整理のこのフェーズに、なぜこれほど高いコストがかかるのかという事が悩みの種になってきます。
②コンサルティングファーム側の視点
では、仕事を受ける側のコンサルティングファーム側としてはどうかというと、率直に言ってしまえばこれは「一番おいしい案件」になります。
というのも、コンサルティングファームはあくまで人月商売なので、会社として売上を上げるためにはビジネスモデル上、どれだけ多くの人をプロジェクトに入れられるかという事が常にポイントになってきます。
そして、優秀な人材は当然限られているので、人月商売である以上、なるべく未経験の若手や採用した中途人材を多くプロジェクトで稼働させたいというモチベーションになります。
少数精鋭型のファームはこうではありませんが、売上・規模拡大路線のファームにおいて、優秀な人材は自然と売れるかクライアント企業側がそもそも離さないので特に論点にはならず、経営課題は常に、規模拡大のために新規採用したあまり経験のない人材をどうプロジェクトに参画させるかという事になります。
そして、この観点において、一定の規模のDX・BPRプロジェクトの業務ヒアリング(現状把握)はうってつけだという事です。
なぜなら、そこまでの専門性はいらない上に単純に人手がかかるため、一定の専門性・経験のある人材をPMとして立て、新規採用したあまり経験のない人材を複数名メンバーに入れる形でプロジェクトを組成できるからです。
こういったケースでは社会人1-2年目の若手や、コンサル未経験の転職者がメンバーとしてアサインされるケースが多く、企業側としても成果物の品質に不満が出たり、現場から直接クレームが出るケースも少なからずあります。
一方、この人手がかかる工程を企業側が自分達でやりきる事はできないので、一定の不満を抱えながらも、コンサルティングファームに相応のコストを払って業務ヒアリングを実施するという事が、ある種この業界の伝統芸能のようにずっと続いています。
とはいえ、やはり付加価値があまりないので、実施するコンサルティングファーム側としても、クライアントからの訴求が厳しく、プロジェクトとしては苦しくなるケースは少なくありません。
③ビジネスアナリスト側の視点
先ほどはコンサルティングファームの企業としての視点についてでしたが、そこで働くビジネスアナリスト、プロジェクトのPMを担う人材の視点ではどうでしょうか。
こちらに関しては、会社側の都合を抜きにして率直に言ってしまえば「非常に面倒」という事になります。会社の業績や評価の視点では確かにメリットはあるのですが、残念ながら個人の仕事やキャリアという側面では、あまり面白みのない案件と言えます。
というのも、ビジネスアナリストとしても、腕の見せ所は業務分析や示唆出しの所なので、そもそもの現状の可視化はクライアント企業側で終わらせておいて欲しいというのが本音になります。
業務分析や示唆出しという高付加価値業務に時間を使いたいものの、実態としてはゼロからの業務ヒアリングの全体を管理する立場のため、先ほど記載したように、プロジェクトメンバーである若手や未経験者の指導・マネジメントに奔走する事になり、対応品質が低い人員に対するクライアントからのクレームの火消し等も必要になります。
その上で、精神的にかなりきついのが、こういった案件はプロジェクトメンバー側からの文句も少なくないという事です。
というのも、コンサル未経験者や若手は特に、いわゆるコンサルに期待していたイメージとは異なり、現場の担当者への業務ヒアリングという非常に泥臭い業務をさせられるので、「こんな事をするためにコンサルファームに入った(転職した)訳じゃない」と突如プロジェクトを抜けたいと言ってくる人もしばしばいるためです。
こういった際の人員の入れ替えやクライアントへの謝罪等も含めたマネジメント業務が多く、この手の案件は、案件の性質上あまり優秀な人材がアサインされない事がビジネスアナリストもわかっています。
会社側としてのメリットは理解しつつも、ほとんどがコンサルティングというよりはマネジメント業務になるため、当人としては(優秀な人は特に)、進んでやりたくはないと思っているケースが少なくありません。
④ソリューションアーキテクト側の視点
では、ToBe検討の要となるソリューションアーキテクトの立場としてはどうでしょうか。
私自身もそうですが、ソリューションアーキテクトの立場での強い要望としては「勝手に業務ヒアリングを進めないで欲しい」という事です。
というのも、業務ヒアリングはビジネスアナリスト達だけで実施される事も多いのですが、ビジネスアナリスト達はいわゆる業務コンサルなので、特にメンバークラスは、IT周りの細かい所についてはそもそもあまりよくわかっていないという事が少なくありません。
つまり、ヒアリング結果を見ても、業務側の事はよく書いてあるのですが、利用システムや権限・開発環境の有無、入出力周りの技術者視点での基本的な情報がヒアリング内容から落ちているという事が少なくない上、ユーザーから技術的な事を色々と聞かれた際に、なるべく期待に応えたいという想いもあり、安易に「できます！」とコミットしていて期待値がやたらと上がっているという事もよくあります。
「現状のヒアリングが終わったので、これでToBe検討お願いします」と言われても、「いや、これじゃわからないよ・・」という事も多く、手戻りの発生や誤った期待値コントールをされるぐらいであれば、ヒアリングに最初から参加させて欲しいというのが本音になります。
ただ、もちろんヒアリングに全て参加したいわけではなく、ヒアリングに参加せずとも必要な情報については既に可視化されていて、ToBe検討・ディスカッションからすぐに入れるという状態が理想になります。
以上のように、あくまで現状把握である業務ヒアリングのプロセスは、非常にアナログかつ工数がかかる上に、それ自体に付加価値はないため、ビジネスモデルとして利点のあるコンサルティングファームの企業的な側面を除けば、全員が省力化したいと思っています。
私自身、コンサルティングファームに転職して最初に業務ヒアリングを実施し、ソリューションアーキテクトとして働くようになってからずっと、この点を何とかしたいなと思っていました。
AIエージェントに業務ヒアリングをさせるメリット
それではこの業務ヒアリングプロセスをAIエージェントで自動化できるようになると何が具体的に嬉しいのでしょうか。
大きくは、以下の3つがあります
①エキスパートの知見の再利用
②品質の標準化とスキルの蓄積
③人的コストの削減
それぞれ見ていきましょう
①エキスパートの知見の再利用
先ほどのプロジェクトの例で言えば、経験のあるビジネスアナリストが何に時間を割いているかというと、部下を指導・マネジメントして自分の分身を作ろうとしているという事です。
つまり、本当は自分で全部やれれば一番効率が良いものの、自分一人では工数的にやりきれないために、自分の知見やノウハウをメンバー達に伝えて自分の代わりを務めさせているという事です。
仮に、このビジネスアナリストの知見をAIに教え込む事ができれば、エキスパートレベルのスキルを関係者全体で再利用できるようになります。
また、ビジネスアナリストだけでなく、ソリューションアーキテクトの視点、クライアント企業側のルールやお作法、社内用語や組織・システム情報等も教え込む事ができれば、それぞれの知見をOR取りする事ができます。
エキスパート達は基本的に忙しいものの、AIに落とし込んだスキルに関してはいつでも再利用する事ができるため、上記で言えば、ある種全ての業務ヒアリングをビジネスアナリスト、ソリューションアーキテクト、企業側のPMの視点で実施できるという事です。
②品質の標準化とスキルの蓄積
業務ヒアリングの品質は当然ヒアリングの実施者に依存します。それはメンバークラスだけでなく、エキスパートクラスであっても同様です。
一方で、AIエージェントに知見を集約させる事ができれば品質を標準化する事ができます。
人間での実施の場合、内容の聞き忘れや、別の人間の視点からすると「そのケースだったら、この観点も聞いといてよ・・」という事が少なからず発生しますが、AIエージェントの場合は、聞き逃しのようなうっかりミスをするという事がなく、いくらでも複製できる上に同一の品質を担保してくれます。
特に、一定の規模で業務ヒアリングを実施する場合は、大きな利点となるでしょう。
また、人間の場合は、異動やプロジェクトの終了などで、また新しい人に一から教える必要があり、いわゆるゼロリセット的な側面がありますが、AIエージェントであればスキルを蓄積しておく事ができます。更に、再現性が高いので、特定の時点をベースラインとして関係者でPDCAを回していく事で、更にそのスキルも磨いていく事もできます。
新しく異動してきた企業側のPMの方などにとっては、これまでの知見が蓄積されたAIエージェントがいる事は、非常に心強い味方となるのではないでしょうか。
③人的コストの削減
これはある種一番わかりやすいのですが、いわゆる人に関わるコストを大幅に削減できます。
まず、AsIs把握の業務ヒアリングを実施するだけのメンバークラスの人員が不要になります。
エキスパートもAIエージェントにAsIs把握を代替させる事で、多くのマネジメント業務から解放され、業務分析やToBe検討のディスカッションに時間が注げるようになるため、マネジメントコストの削減とともに、高付加価値業務にシフトできます。
また、ビジネスアナリスト、ソリューションアーキテクト、企業側のPMの視点が既に入っていて、標準化されている事により、関係者間の報告やコミュニケーションのコストも下がります。人で実施する場合は、同じような指示や指摘を複数名に実施する必要がありますが、AIエージェントの場合は指示は1回でよく、また、一度指摘された事は繰り返しミスをする事はありません。
そして、実はかなり嬉しいのがヒアリングにおける日程調整が不要かつ並列実行が可能だという点です。総じて、現場で実務を実施されている方達は忙しいので、そもそも日程の調整が大変な上、こちら側も同時にヒアリングができるのは1案件のみのため、関係者の日程を見ながら上手くパズルをはめるようにスケジュールを組んでいく必要があり、これだけでも一苦労になります。
一方、AIエージェントの場合は、「この期間内でいつでもいいのでお願いします」とさえ依頼してしまえば、実務担当者は自分の好きなタイミングで実施できる上に、同時並行も可能という事です。
例えば、人手でヒアリングする場合は、1ヶ月で100件捌くには相当の気合と一定の人員数が必要になりますが、AIエージェントの場合は、こちらの工数と日程調整は無視できるので、担当者側の都合さえつけば、例えば1日で100件捌けるという事です。
このように、それ自体に付加価値のないAsIs把握をAIエージェントに代替させる事で、①エキスパートの知見の再利用、②品質の標準化とスキルの蓄積、③人的コストの削減というメリットが出てきます。
もちろん、チャレンジングな取り組みのため一足飛びには行かないですが、業務ヒアリングをAIエージェントに任せる事で、プロジェクト関係者がToBe検討・ディスカッションに集中できるようになるというのは理想的な状態ではないでしょうか。
【コンセプト図】
AIエージェントの実装
では、AIエージェントの実装を見ていきましょう。
AIエージェントへのインプット
構成要素としては非常にシンプルな形で、AIエージェントの動きを規定する業務指示書(指示プロンプト)を定義し、AIエージェントに読み込ませます。これは要するに、ほぼ人間と同様で、優秀な人材に「この通りにヒアリングして」と依頼するイメージになります。
この形式の利点は、ヒアリング内容を変更したい場合に、プログラム側は触らずに、業務指示書だけアップデートすれば良いという事です。ヒアリング項目を1つ追加したい場合や、ヒアリングの順番を変えたい場合等、プログラムを変更せずに、企業側のプロジェクト管理者やビジネスアナリストも、人間に指示するように自然言語で直接修正する事ができます。
また、社内用語やシステム情報、よくある質問等も定義しておけば、ユーザーからの個別の質問にもその場で答えてくれるようになります。
わからない事に対しては、「わからないため後日回答します」と返答するように指示しておけば、勝手な事は回答せずに、上手く回答できなかった質問に関係者が後日回答しつつ、AIエージェントに読み込ませるよくある質問を更新していけば良いでしょう。
格納場所はAIからアクセス可能な場所であればどこでも良いのですが、今回は使いやすいケースとしていつでも更新できるようにSharePointに置いておき、AIエージェントにインプットとして読み込ませます。
SharePointでの配置イメージ
業務指示書の構成要素は以下のような形で定義していきます。
- 役割の提示
- 前提条件の指定
- ヒアリング全体の流れの指示
- 各ヒアリングステップの詳細
- ヒアリング項目の一覧
- ヒアリング後のユーザーへの依頼事項
- アウトプット生成の指示
- よくある質問一覧
- 社内用語一覧
※ヒアリング項目一覧のイメージ
基本的な情報を聞きながら、プロジェクト特有の共有しておきたい内容、よくある質問等も参照可能な形にしておく事で、プロジェクトに合わせたAIエージェントの動きを規定します。また、社内用語等も記載しておく事で、ヒアリングの中での専門用語にも対応できるようになります。
AIエージェントのアウトプット
今回は、ヒアリングのアウトプットとして「①ヒアリングのサマリ」「②ヒアリングの全文」「③簡易業務フロー図」を出力させます。
ヒアリングのサマリで主要項目を確認できるようにしつつも、必要に応じて参照できるよう、ヒアリングのやり取りの全文も出力させておきます。加えて、業務の流れの概要が把握しやすいように、簡易的な業務フロー図も自動生成させます。
各ヒアリング毎にアウトプット格納用のフォルダを自動で生成させ、その中に上記のアウトプットを出力させます。
今回は上記の形式ですが、アウトプットはもちろんプロジェクトの成果物に合わせれば良いので、PowerPoint形式で出力させたり、直接SharePointリスト等に項目レベルで書き込ませて一覧で管理したりという形でも良いと思います。
AIエージェントのツール
AIエージェントに渡すツールとして以下の4つを定義しておきます。
【ツール1】日付取得
当日の日付を取得。フォルダやファイル名の生成時に使用。
【ツール2】フォルダ生成
SharePointのライブラリ上に任意のフォルダを作成。アウトプット格納フォルダの作成に利用。
【ツール3】Word出力
テキスト情報をワード形式で出力し、SharePointの指定のパスに格納。ヒアリングのサマリ・全文の出力でそれぞれ利用。
【ツール4】業務フロー出力
簡易的な業務フローを描画し、SharePointの指定のパスに格納。業務の流れの可視化に利用。
これらのツールを定義しておく事によって、AIエージェントが必要なタイミングでアウトプットを生成し、SharePoint上に任意のフォルダを作成、及びアウトプットの格納が可能な形にしておきます。
このツール部分の変更で、出力ファイル形式やファイル入出力先の変更(例えばGoogleDriveやBox等)に対応できるよう、業務指示書とは独立した形にしておきます。
AIエージェントによる業務ヒアリングデモ
今回はAIエージェントをLangChainで実装し、Flaskのチャットアプリに載せたものをAzure上にWebアプリとしてデプロイしました。
以下のように、ブラウザからアクセスすると業務指示書の内容に従って、AIエージェントが業務ヒアリングを自動で進めていきます。
ヒアリングが全て終わると、事前に渡したツールを用いて、SharePoint上に自動でフォルダを作成し、指定のアウトプットを格納します。
SharePoint上に生成されたフォルダとアウトプットファイル
<ヒアリング結果フォルダ>
<ヒアリング結果フォルダ内>
<ヒアリング結果サマリ(wordファイル抜粋)>
<ヒアリング結果全文(wordファイル抜粋)>
<簡易業務フロー(自動生成)>
<受領資料>
ヒアリングの最後に関連資料の格納を依頼し、ユーザーが資料を格納するためのフォルダも自動で作成しておきます。
フローチャートに関しては、個人的に入出力ファイルの情報まで欲しいケースが多いので、今回はシンプルにスイムレーンで区切る形にしましたが、BPMNやMermaid等、プロジェクトに合わせた標準記法で書いたり、そのまま編集できるようにPowerPoint等で出力させても良いと思います。
ヒアリングの中で特に深堀りたい観点や、もっと粗くてよい点なども業務指示書にベストプラクティスとして蓄積していけばAIエージェントのレベルも上がってくると思います。
対面だと少しデリケートになる話題や期待値コントロールの点であらかじめ言っておきたい事などは、AIエージェントのほうがむしろ伝えやすい(ユーザーとしても質問しやすい)という利点もあるかと思います。
実際にやってみた所感としては、上手く汲み取ってくれる所はありつつも、柔らかくしておくべき所と固めるべき所のバランス(設計)がポイントになるなと特に感じました。
汎用性と確実性はトレードオフなので、プログラムでガチっと固めると逆にそれ以外は対応できなくなり、一方でプロンプトエンジニアリングだと処理が安定しないというケースもあり、AIエージェントに対して、プログラムやツールで定義する箇所と、汎用的に対応させるためにプロンプトで制御する箇所のバランスがテーマになってくるかと思います。
これはマイクロマネジメントするか、ある程度任せるかに近く、この辺りの悩みに関しても少しずつ人間の文脈に近づいて来たなと感じます。
今後のアップデート
今回はあくまで初版としてのデモでしたが、今後いくつかのアップデートを入れていきたいと思います。
ファイル格納チェック
今回、ヒアリングの中で動的にフォルダを作成し、利用ファイルやマニュアル等の参考情報を格納してもらうように依頼していますが、実際に業務ヒアリングをやった事のある方はわかるかと思いますが、ユーザーがいつの間にか対応を忘れていたという事はよくあります。
そして、翌日かまたその数日後に「参考ファイルの格納をお願い致します」とユーザーに何度も督促するのがある種定型業務のような形になるので、ファイル格納がない場合はユーザーに督促し、ファイルが格納されたタイミングで管理者に通知するという形にする事で、この督促業務も自動化する事ができます。
これによって、プロジェクトメンバーはヒアリング結果と参考ファイルが揃ったタイミングからスタートする事ができます。
これは業務ヒアリングのエージェントとは別に、監視エージェントを作成し、業務ヒアリング結果を渡して、督促させるという形が良いかもしれません。
ToBe検討
今回はあくまでAsIs把握がメインでしたが、次のステップのToBe検討も少しずつAIエージェントで代替していく事ができるのではないかと思っています。
というのも、ToBe検討もある種、一定のフレームワークに沿った意思決定プロセスであるため、業務見直しのBPRの視点や、利用できる自動化ソリューション(RPA/AI/BI/ETL/ワークフロー等)などの特性を整理しておけば、AsIsを踏まえたToBeの素案まで出してくれるようになるでしょう。このタイミングで過去の自動化事例も参照できると思います。
AIであればいくらでも候補は出せるので、いくつかの切り口とメリデメも踏まえたToBeの方向性の素案も提示させ、そこから関係者が検討を始めるという形が良いかもしれません。
またToBe検討に際して必要となる初歩的な質問「この部分は紙をデジタル化できないか」「この承認プロセスは排除、または代替手段がないか」等については、業務ヒアリングの後半に含めておき、ユーザー側の所感も先に聞いておけば、更にToBe検討がスムーズになるでしょう。
応用先
今回は業務ヒアリングが題材でしたが、やっている事は要するに「ユーザーとやり取りしながら必要なアウトプットを作る」という事なので、色々と応用ができると思います。
いわゆるRAGの問合せ検索とは違い、アウトプットまで出させる所がポイントになります。
例えば、プロジェクト計画書の雛形と優秀なPMの知見をまとめておき、AIエージェントの回答に答えていけば、プロジェクト計画書のドラフトを一定の精度で出力できるようにしたり、RFPの作成や提案書の作成等の場合は、一定のテンプレートと作成ルールに加え、社内規則も参照させるようにすれば、必要なアウトプットを作成しながら、リアルタイムでコンプライアンスチェック等もできるかもしれません。
ユーザー側としても、テンプレートと作成ルール、各種規則等はあるものの、どこを参照していいかわからず様々な資料で目が泳いでしまうという事がよくあると思いますが、こういったアウトプット作成や申請プロセス等をAIエージェント化してしまえば、詳しい人(AI)にその場でサポートしてもらいながら、様々な書類を参照する事なく、1つの画面でタスクが完結するので、アウトプットの生成がかなり楽になるかと思います。
「マニュアルや説明資料はこちらにありますので、こちらを参照しながら対応して下さい」と言われるよりも「このURLにアクセスして進めて下さい」と言われるほうがユーザーとしても有難いのではないでしょうか。
まとめ
いかがでしたでしょうか。
今回は、兼ねてから自動化したいなと思っていた業務ヒアリングの自動化について検討しました。
AIエージェント化する事で改善を積み重ねていけるので、AsIsヒアリングだけでなく、ToBe検討時の思考プロセスを落とし込めば、ToBe検討結果を概ねそのまま採用できるようになる日がそう遠くないような気もしています。
今回は題材が業務ヒアリングでしたが、RAGによる問合せ検索から、次のフェーズへ移る検討の一助になれば幸いです。
(補足) プロセスマイニング・タスクマイニングは？
今回、業務ヒアリングの文脈で気になった方もいるかと思いますので、簡単にこちらの話題にも触れておきたいと思います。
というのも、今回はヒアリングの実施者側の自動化であるため、ユーザー側(ヒアリングされる側)としては、経験の浅いメンバーにヒアリングされるよりは明らかに楽になるとは思いますが、自動化というレベルには達していません。
そこで、プロセスマイニング・タスクマイニングを使って、業務ヒアリングをせずに、業務プロセスの可視化を自動化できないかという事です。
ここからは私の主観的な意見が少し大きくなりますが、これに関しては「コンセプトとしては正しいものの、フィジビリティが低い」と言わざるを得ないかと思います。
というのも、RPAが一気に普及した2018年代辺りから、業務の可視化が課題である事が顕在化し、そのコンセプト上、プロセスマイニングやタスクマイニングが大きく注目されました(私自身も検討や提案に何度も入りました)。
しかし、それからしばらく経った現時点において、事例含め、プロセスマイニングやタスクマイニングという言葉をあまり聞く事がない点を見ると、多くの人が当初想定していた期待値とは大きな乖離があったと言わざるを得ないでしょう。
業務プロセスは、複数のシステム・アプリを利用する事も多く、途中で人のアナログな対応も入ります。
プロセスマイニングの文脈で言えば、システム・アプリ毎にログの粒度や形式も違う上に、アナログ対応は当然追えないため、ログをベースに業務を横断的に自動で可視化するというのは実際のところ非常に難しいと言えます。
そもそも、SaaS系のツールを利用している場合はログが見れないという事も少なくないですし、利用するツールも頻繁に入れ替わるので、プロセスマイニングの準備を整えるまでに膨大な工数がかかる上、その賞味期限もあまり長くないという自体になってしまいます。
これはプロセスマイニングが悪いという話ではなく、当初の期待値が高すぎたという話で、実際はSAP系の事例がほとんどであるように、基幹システム等、ログが取れる勝ち筋が見えている特定のシステムの範囲に絞って可視化するという形が良いかと思います。
タスクマイニングについても、人がどのような意思決定をしているかはわからないので、業務プロセスの可視化というより業務量調査の文脈で、どのシステムやアプリをどの程度使っているのかという全体感の把握の範囲で利用するのが良いでしょう。
一方で、操作ミスや途中で別の業務を挟んだり、アナログな対応の部分が一気に飛んだりと、業務プロセス可視化の文脈で言えば、材料にはなるかもしれませんが、あまりにノイズが多すぎるので、業務プロセス可視化の自動化という観点では精度が及ばないでしょう。
プロセスマイニングについては基幹系システム、タスクマイニングについては業務量調査の文脈で有用ではあるものの、多くの方が想像する、いわゆる業務プロセス可視化を自動化できるという期待値に到達する事はおそらくないかと思います。
どちらかと言えば、完全に自動化された後の業務管理・可視化においては生成AIで一定可能なのではないかと思っています。
自動化後のシステムやRPA, BI, AI等の、ログというよりプログラムを読み込ませて、生成AIに説明させれば、マニュアルに明記されていないような例外処理等も含め、そのシステム・アプリが何をしているのかをいつでも可視化できるようになるかもしれません。
ただ、あくまで完全なデジタル化・自動化後の話なので、もちろん部分的には既に可能なものの、このフェーズに本格的に入るのはまだまだ先かと思います。
コンセプトとしての耳ざわりが非常に良いので「プロセスマイニング・タスクマイニングで業務プロセス可視化を全て自動化できないか？」と安易に発言される方も多いのですが、仮にその期待値を達成できるのであれば、既に市場にはプロセスマイニングとタスクマイニングが溢れているはずなので、使い所はもちろんありますがそれほど簡単な話ではないという点については留意が必要になります。