先日、新しく導入したwebサービスによる業務処理を現場部署にご説明に行きました。担当者は若い派遣社員2名。普段の業務に関してはてきぱきと要領よく来なしてくれているし、いままでも関連するwebサービスを利用していたので、そんなに苦労するとは思っていませんでした。
もちろん、事前に画面遷移ごとの画像の入った手順書を作成し、これを見ながら説明し、同時に質問があった個所などを補足して再配布するつもりでいました。
ところが、手順そのものよりも、
などの、業務の手順以前のWindowsやブラウザの仕様に対する理解の部分が障害になることに直面しました。もちろん、その場で説明して、そのあと手順書に追記すれば、彼女たちは次からはちゃんと対応できるので、それ自体を問題視しているわけではありません。伺って直接問題を確認できてその場で対応できてよかった、と思いました。そもそもInternet Exploreのサポート切れを前にGoogleChromeへの移行などの対策を社としてとっていなかったというところにも課題があります。
ただ、この出来事は弊社の仕事を進めるうえで重要な示唆があると感じました。
仕事をする上では、組織の中にその業務に対する「共通言語」があることが必要です。それは一般には「業界知識」だったり、「ITの基礎知識」だったりします。ユーザーサイドのIT知識という点では、WindowsとかつてはInernetExplorer,今ではChromeがその「共通知識」の対象であった時期が長く、旧世代に属する私はそこにあまり疑いを持たずに準備をしてしまったのですが、今の「スマホネイティブ世代」は、そこが決して「共通」ではないようです。
たしかに、弊社が関わるECサイトのアクセス元を見ても、あるいは先日もちょっと話題にした中国語での士業のサービスサイトにしても、アクセス元の80%以上がスマホか、スマホアプリからです。スマホのOSはiOSもアンドロイドも非常に完成度が高く、かつセキュリティがしっかりしているため、通常のアプリの利用に際しては、「意図に反する現象が起きる」ということがパソコンよりもはるかに少なくなっています。そのため、「ダウンロードしたら、勝手にダウンロードフォルダにダウンロードされている」なんてことは「常識」ではなくなっているのです。拡張子があることもバッチファイルも昔の常識になっていて、今の一般の人には、すごく難しい話になってしまっています。これは、勉強不足、と言っているのではなく、時代の変化で消費者としての知識体系とサービス供給者としての必要な知識体系にギャップができている時代であるということです。
このことは、単に「きちんと基礎知識からテキスト化して説明する必要がある」というだけでなく、より重大なリスクをはらみます。例えば、「わからないけどなんとなく操作」したことにより、「データが消失」や「データが流出」するリスクが拡大することです。それを防ぐためには、より広範で構造的な知識を身に着けるか、仕組み上それが起きないような構造を実現するかのどちらかが必要です。こういう時に文書だけ提供して、「あとは見ながらやってみてわからなかったら聞いてください。」という姿勢は危険で、結局立ち会って、手取り足取り教えることを繰り返すことが必要になります。
御社のSIerはそこをわかってくれていますか?
さて、こうした事態に際して、近年流行したRPAなどを用いて「完全な自動化」をすることは、一見理想的に思えます。確かに自動化すれば時間が短縮できるだけでなく、人為的エラーも起こりにくくなり、今回のようなユーザーのITスキルがあまり高くない場合には、導入者としては正直助かります。
しかし、この方法論には大きな問題があります。工程改善をし始めると暫くの間はあちこちに改良、変更箇所が見つかり、都度声を掛け合って共有する、そのあと文書化するということがどうしても避けられないからです。また、想定していない「例外」も結局あちこちに発生します。なぜかというと、自分が対応している業務が、どのようなデータがインプットしてきているかを正確に知らないし、知っていてもそれを言葉、文字にアウトプットできないから、教わった工程や条件を元に作っても情報が不足しているからです。これはバカにしているのではなく、現代の業務システムが相手にしているデータは、小さな業務でも相当膨大で多様であり、それを人間は柔軟にその場の判断で対応できるものの、全容を記述することは相当大変なことになっているということです。結局これを防ぐには、その部署に数日居座らせてもらって、あるいはその業務を実際にやらせてもらって、元データを何か月分もすべて目で見て知ることが必要になります。
御社のSIerは、その辺をわかってやってくれていますか?最近は、コストダウンが進んで、「教わった仕様を元に作りますので、それ以外の情報があとから出てきた場合は、別料金になります」と平気で言うような業者も多くいますよ。
そして、この時に、がちがちのシステムを作ってしまうと、すぐに大量の修正箇所が発生する事態を招きます。それがスムーズに修正できればよいのですが、往々にして、時間も費用も掛かります。結局、既存のツールを組み合わせたり、内製でできるものを使ったりしながら、柔軟に変更できることはとても重要です。この時に担当者のユーザーサイドのITスキルが一定以上あると、起きている現象に対して比較的よく反応できますし、要望も具体的な形になりやすくなります。また、中小企業の場合、一つの業務の処理にかかる時間は多くの場合、数分~十数分です。それを短縮するのに高価な投資はなかなか正当化されません。
そういう代替案は概してお金になりません。だからSIerは提案してくれません。依頼する先を間違えていませんか?そう、依頼する先は、当社のような誠実な業務コンサルです。
というわけで、結局丁寧に手順を教える中で、新しいWindowsの用語、新しいブラウザの動作に慣れてもらう機会を作っていくということも、避けては通れないし、結局は会社の力を底上げすることにつながるのだと考えています。