2019.02.22
本コラムでは、前回内容から続いて、自治体へＲＰＡを導入する時の注意点、要諦について述べていきます。
今回が一連のシリーズの最後になりますが、前回のコラムを参照したい方は以下をご覧ください。
前回、前々回のコラムでは、自治体におけるＲＰＡ導入のポイントとして、
「ＲＰＡを入れる前に業務フローを変えよ」と
「手書き申請からの脱却≒入力時点での電子化を図るべし」という点について述べさせていただきました。
いずれもＲＰＡを導入する前の下準備の大切さを訴えた内容です。
通常のＢＰＲの視点やタブレットなどのＩＴツールを含めて、よりＲＰＡの効果が増大するための土台を整えておくことが重要です。
今回のコラムでは、いよいよＲＰＡを導入する段階になった時の話になります。
ＲＰＡプログラミングの細かいテクニックは別コラムに譲るとして、
ここではＲＰＡ開発をする上でのシステム設計やメンテナンスを含めた人員体制といった「仕組み作り」に特に焦点を当てています。
もちろん、これだけがＲＰＡ導入の成功の鍵であるわけではありませんが、
特に自治体で取り組む際の重要ポイントとして詳述していきたいと思います。
自治体にＲＰＡを導入する際の重要論点として、メンテナンスのしやすさを考慮した人員体制およびシステム設計の重要性について言及したいと思います。
こちらについては、ＲＰＡの開発・メンテナンスを誰が行うかによって変わってきます。
ＲＰＡはそもそもの由来として、大規模システム開発案件の対象となりにくい日々の細々とした定型業務にスポットをあてたツールであり、
思想としてユーザーサイドで自主的に開発・メンテナンスが行えるようなＵＩを謳っています。
ただその割には多少のプログラミング知識が求められるため、
いきなりゼロから自社職員で開発を遂行するのが難しく、最初の期間はベンダーに依頼するケースが多いのが実情です。
こと主要都市圏以外の地方自治体におけるＲＰＡ導入に目を向けると、
開発・メンテナンスの人員体制およびシステム設計の方向性は下記2つのいずれかの方針にすることを推奨します。
これは、現在ＲＰＡを手掛けられるベンダーが主に首都圏をはじめとした主要都市に未だ限定されているため、
追加開発や改修のたびにその地方自治体にベンダーを呼び寄せることが中々困難である事に起因します。
参考： 自治体ＲＰＡにおける人員体制・システム設計
自治体の場合、セキュリティーポリシーの関係上、
ＲＰＡロボットをローカルＰＣ端末もしくはオンプレミスの庁舎内サーバーに置かなければならない場合、
「誰がエラー時に改修対応するのか」という点が非常に重要になります。
前述しましたとおり、現在ＲＰＡに熟練したベンダーは都市部に存在することが多く、
それらの企業を頻繁に呼び寄せることは現実的ではありません。
仮にできたとしても、ベンダーのエンジニアが訪問するまでに日数がかかり改修のリードタイムが長引くことになります。
そのようなロボット配置≒システム体制の場合、簡易的な改修や追加開発は職員自らの手でできるようになることが最善の策となります。
こちらの方針では、最初の開発についてはベンダーのサポートを受けながら行いますが、
その期間中、一部のＩＴリテラシーのある職員を特命大使としてＲＰＡ研修を積ませ、
最終的には自社リソースで追加開発や改修作業ができるようにもっていく事を狙います。
この場合、ベンダーに対して、ＲＰＡ開発だけでなくトレーニングを含めた契約を予めしておくことが肝要となります。
それでもやはり、自庁舎職員でメンテナンスをしていくのに不安を感じる自治体もあると思います。
その場合は、ベンダーとの契約で予め、自治体地域在住のエンジニアを育成しメンテナンス業務にあたらせることを盛り込んでおくことをお勧めします。
首都圏などにいるベンダーとしては、個別自治体に自社エンジニア、特にＲＰＡエンジニアを最初から抱えてはいないはずです。
よって最初の段階は既存エンジニアに出張させ常駐させますが、それと同時に地域内で採用活動をし、
開発後のメンテナンス人材を準備しておくことを自治体側としても意識して契約仕様を設計するのです。
自庁舎職員でＲＰＡ人材候補を見つける自信のない自治体にとっては検討の価値のある施策だと考えられます。
先ほど、自治体においてはロボットを庁舎内に配置することが求められるケースがある、と述べましたが、
全ての自治体がそうであるとは限りません。
セールスフォースのＰＡＡＳが自治体内でも存在感を示している通り、
最近では自治体側としてもクラウドサービスの利用にオープンなところも少なくありません。
その場合、民間企業のＲＰＡ事例では実際にあることですが、
ベンダーが管理できる場所（ＡＷＳ等クラウドのケースが多い）にロボットを配置し作業させることができます。
遠隔のクラウド上にあるロボットに自治体庁舎内にあるＰＣやサーバー内システムにアクセスさせる方法は幾つかありますが、
庁舎内にあるローカルＰＣを遠隔操作する場合はリモートデスクトップの技術が使われます。
（但し、リモートデスクトップについては既存の庁舎ネッワークによって可否が変わるため事前の検証が必要です）
上記のようなシステム体制ができれば、例えベンダーがその自治体近辺の会社でなくても、
比較的容易にメンテンスをすることが可能になります。
実際には、細かい設定などは現場ＰＣ上での動作等を参照する必要があるのですが、
少なくとも最小限のコストでメンテナンスを賄うことができ、
地方自治体にとっても都市圏にいるＲＰＡ熟達ベンダーに自分たちのＲＰＡ活用を任せられるという安心感を得ることができます。
今回、自治体におけるＲＰＡ開発・メンテナンスの人員体制・システム設計について方策案を提示させていただきましたが、
何もこれらが唯一解ではなく、自治体の状況によって他のパターンがありえます。
ただ、ここで言いたいのは、
「開発後のメンテナンスについて何の方針もなく、徒に導入を進めてしまうのは非常に危険」
ということです。
「一度ＲＰＡを作ったら、メンテナンスなど要らないのではないか」という意見をお持ちの方もいるかもしれませんが、
これは断言できます、多くのＲＰＡプログラムには恒常的なメンテナンスが必須となります。
それは、ＲＰＡというものが、もともと既存のシステムやOS、アプリなどの「橋渡し役」として使われることが多く、
故にそれらの外的要因に強く依存してしまうからです。
例えば、既存の庁舎内システムの改変があれば、もちろんそこにアクセスするＲＰＡロボットも改修が必要になり、
またインターネットサイトの構成が変われば、その情報を扱うロボットは修正を求められます。
従って、ＲＰＡ導入を決めるのと同時に「メンテナンスをどうするか」というのはセットで考えるべきものなのです。
このコラムでは、特に地方自治体においてＲＰＡを導入する上で気を付けるべき点を挙げさせていただきました。
自治体のＲＰＡ普及は正に始まったばかりで、今後ますます浸透していくことが予想されます。
もともと自治体業務はＲＰＡと非常に相性が良く、
自治体職員の負荷低減およびそこで産まれた余剰時間をより重要な対市民へのサービスに回すための理想的なソリューションとも言えます。
今後ますます発展する自治体ＲＰＡ化ですが、本コラムで書いたような要点を抑えることで、成功の確度を少しでも上げる事ができれば幸甚です。
弊社では、RPA導入のご相談を承っております。
RPA導入についてご検討の方は、東京ビッグサイトで開催されるRPA導入無料相談会にてご予約ください。
2019.02.21
本コラムでは、前回コラムの内容から引き続き、自治体におけるＲＰＡ導入のポイント、最大限の効果を狙うための要諦について述べていきたいと思います。
前回のコラムを参照したい方は以下をご覧ください。
前回のコラムでは、自治体におけるどのような業務がＲＰＡの対象となりうるのか、「窓口業務」と「内部管理業務」に分けて列挙し、
また、ＲＰＡ導入におけるポイントの一つとして「ＲＰＡを入れる前に業務フローを変えよ」ということを述べさせていただきました。
一見、ＲＰＡ導入となると、「現行の業務フローをそのままにロボットに移管できる」という妄想に囚われがちになりますが、
ロボットと人間、それは勿論、特性が違います。
その人間とは異なるＲＰＡロボットなるものの性向、得意分野に合わせて人間側が業務フローを再設計する工夫が求められます。
もちろん、業務フローを変えずともＲＰＡの導入は原理上可能ではありますが、
その場合、効率化の果実、つまり人間側で生まれるはずの余剰時間が限定的になってしまい、
人間にとってもロボットにとってもハッピーな結果とはなるとは言えません。
現行の業務フローを変えることは確かにリスクです。
ただ、その苦しみを乗り越えないと、ＲＰＡの果実は萎んでしまう、
それは厳然たる事実であり、自治体側においてもその覚悟をもってＲＰＡ導入を図るべきだと考えます。
では、今回のコラムでは、それ以外の点で、特に自治体にＲＰＡ導入する際に気を付けるべき点を述べていきます。
自治体業務では、市民、法人などの様々な所から、多種多様な申請を受けることになります。
これらの「申請書」について、現状は手書きで書かれることが多く、職員の方々がその申請書を読み取って、システム等に登録していきます。
その業務をＲＰＡロボットにさせようとする場合、OCRの技術、つまり画像として文字を電子上のテキスト情報に変換する技術が必要になってきます。
実際に、金融業界が先鞭をつけた、日本におけるこのＲＰＡ化のトレンドにおいても、
まずは消費者からの契約書関連の入力業務がＯＣＲの導入とセットで取り上げられることが多かったものです。
ただ、ここで注意が必要です。現行の技術ではOCRの精度は100％ではなく、必ず職員による目視チェック業務が発生します。
確かに、このＯＣＲの技術は日進月歩であり、ＡＩ技術と合わさることによって手書き文字の認識率も随分と向上しました。
しかし、それでも認識率は100％では無いために、必然、人間による目視確認チェック工程が入ります。
また、ＯＣＲと申請書等帳票の相性にもよるのですが、精度を上げるためにチューニング作業であったり、
学習データの蓄積といった作業が必要になるケースもあります。
その場合、ＯＣＲ精度を上げるためにかかる労力が甚大になるため、
例えば扱う帳票種類が膨大な数となった場合、リードタイム非常に長くなってしまいます。
従って、これは何もＲＰＡに限ったことではないですが、省力化・自動化の取り組みをするのであれば、
入力時点で電子化させるのが何よりも一番効率的になりますし、手っ取り早いです。
具体的には、タブレット等の端末を用意してそちらに市民の方に入力してもらう施策が考えられます。
中には押印が必要なものもあると思いますが、
それはテキスト入力後印刷してその上に押すことで済ましたり、タブレット上での署名で代替するなど解消方法はいくらでも考えられます。
もちろん、中にはタブレット端末の操作に不慣れなご高齢の方もいるでしょう。
そのような場合は、特別対応として、職人が代替して入力してあげればよいのです。
ただ、この特別対応が蔓延すると、職員の負荷増大になり本末転倒になりますので、基本的には自力で入力するように促すことが求められます。
この申請・帳票類のペーパーレス化は、民間企業でもトレンドとなっています。
分かりやすい例で言えば、来訪者の受付記入業務のペーパーレス化です。
近年、ACALLに代表されるような商談や入管管理の電子化ソリューションが普及していますが、
そこでは今まで来訪者が紙に社名、名前、商談対象者などの情報を記入して受付に提出していたのが、
タブレット上で入力できるようになりました。
参考： ACALL 受付アプリの画面（出所： https://www.acall.jp/features/reception/）
この機能により、来訪者はタブレット上から面会対象者を探して選択し、かつ電子上で自社や自身の情報入力を済ますことになります。
この来訪者受付のペーパーレス化によって、（今まで受付の社員が行っていた）来訪者情報の入力作業が全て自動で電子化されることになり、
人間による紙からの手打ち業務の削減に繋がっています。
同様の受付業務ペーパーレス化は防衛省等の官公庁でも取り入れられています。
ここで取り上げた事例はあくまで来訪者の受付業務の話ですが、
同様の思想は自治体の申請書・帳票受付業務にも敷衍できるものであると考えられます。
タブレットやアプリの初期費用がかかることになりますが、それにより、ＯＣＲの導入コストが抑えられます。
また、最初の市民の方々からの入力時点で電子情報となっているので、ＲＰＡでのシステム登録も正確にでき、
職員によるチェック工数の削減に繋がり、より大きな効率化効果が望めることになります。
実際に、現在様々な自治体でこの窓口業務におけるペーパーレス化・タブレット活用が取り組まれています。
会津若松市等、まず手始めとして行っている自治体で多いのが、
住民票の写し、印鑑登録証明書、戸籍事項証明書におけるタブレット申請の取り組みです。
マイナンバーカードや住基カードを用いて申請ができます。
参考： 会津若松市におけるタッチパネル受付サービス
（https://www.city.aizuwakamatsu.fukushima.jp/docs/2014022700037/）
特にマイナンバーカードは、2017年3月時点で、交付枚数は1,000万枚を超え、国としては更なる利活用を進めています。
その一つの方策として、自治体窓口における証明書交付等の入力負荷低減として、マイナンバーカードの活用に着目しています。
この会津若松市の事例も、まさにそのトレンドに沿った施策と言えます。
ただ、住民票写しなどの申請省力化は、特に新規性のあるものではなく、
一部の自治体では既に専用機械を導入、印鑑登録カード等を活用して同様の仕組みは実現していました。
そこで近年では更に、出生・転入・転出・転居・結婚・離婚・死亡といった際の届出・申請にまで踏み込んだ取り組みも出てきました。
例えば、ＤＮＰが２０１７年５月にプレスリリースした情報では、
出生・転入・転出・転居・結婚・離婚・死亡といったライフイベントにおける届出・申請に対応するプロトタイプシステムの開発を発表しています。
マイナンバーカードをから、氏名・住所・性別・生年月日の基本4情報を取り出し、
届出・申請書に入力、その内容を自治体の基幹システムと連携させることもできることを目指しています。
参考： ＤＮＰによる自治体への申請手続き支援システム
（http://www.dnp.co.jp/news/10135590_2482.html?from=rss）
このような取り組みがもっと進展すれば、多種多様に存在する自治体の紙による届出・申請は、
ペーパーレス、つまり電子入力に切り替わっていくことが予想されます。
もともと自治体の届出・申請書は紙による手続きが残っている分野ではあり、今までの慣習を変えるのは大変骨の折れることではあります。
しかし、よくよく考えれば紙への書き込み作業は、市民にとって負荷でありますし、
そして何よりも窓口職員にとっても多くの市民に接しサービス提供する機会を棄損することにもつながります。
そこで、ＲＰＡ導入を検討されている自治体におきましては、
この機会に「紙からの脱却」も併せて検討することでＲＰＡ効果の最大化を狙うことをお勧めします。
次回コラムでは、自治体におけるＲＰＡ導入について、最後の重要なポイントを述べていきたいと思います。乞うご期待ください。
2019.02.20
本コラムでは、２０１７年頃から活発化し、
まさに近年大きなトレンドとして勃興している自治体向けRPAの導入Tipsについて述べていきたいと思います。
実際の地方自治体の導入事例については以前書いたコラムをご参照ください。
そちらではつくば市や京都府といった先進的な自治体における取り組み事例について報道資料を基に考察しています。
今回のコラムは、その自治体において具体的にどのような業務が対象になっているのか、
またＲＰＡ導入する際にどのような点に特に注意すべきかをまとめていきたいと思います。
そもそも確かにこの自治体業務というものは定型作業の宝庫であり、潜在的にRPA化できる余地は非常に大きいのが特徴です。
ただ、一般の民間企業のＲＰＡ導入と違って使用しているシステムがクラウド型ではなくオンプレのシステム、
さらには旧型のスクラッチ開発した独自システムも現存していることも多いです。
また、内部事務処理のバックオフィス業務だけでなく、フロントの窓口業務での活用も求められ、
即時対応できる、フロントの人間とリアルタイムで協業できるようなロボットの設計が必要です。
まず、具体的にどのような業務が自治体においてＲＰＡ対象になるのでしょうか。
そのためには、自治体の業務を大きく「窓口業務」と「内部管理業務」に分ける必要があります。
窓口業務は、市役所等庁舎に訪れた市民に対して行うサービスです。
近年では住民票や戸籍謄本などの証明書発行業務は機械による自動化がなされていますが、
各種の届け出等についてはまだ人間の事務員が対応しています。
一部の例にとどまりますが、具体的な業務を挙げますと以下があります。
特徴としては、実際に市民の方に相対しての業務となっており、自動化するにしても即時対応が求められることです。
ＲＰＡがよく活用される民間事例に例えると、コールセンターでの導入に近いかもしれません。
ロボットが定刻にバッチ処理のように起動するようなやり方は、通常フローを遵守するのであればここではできません。
次に、内部管理業務について述べます。市民の方と接する窓口業務とは別に、自治体業務には事務所内で行われる様々な定型業務が存在します。
こちらについては各自治体個別の業務ももちろん多く存在するのですが、
一般的に多くの自治体で行っているもので特にＲＰＡに向いている定型業務を挙げると以下になります。
ここで取り上げた業務は、自治体に存在する事務処理の一部でしかありませんが、
自治体では、法人、市民問わず多くから各種申請を受けています。
その入力作業であったり、審査、そして契約手続き等、多岐に渡った定型業務が存在します。
また、調達関係は特定の課で事務処理をまとめていますが、補助金関係になると各担当部署に事務作業が分散する傾向にあります。
それでは、実際に地方自治体にＲＰＡを導入するに際して、どのような点を特に考慮する必要があるでしょうか。
これらの点は正直、自治体特有のものだけではなく、民間企業でＲＰＡ導入する際にも言える事も含まれています。
ただ、やはり、今までのコンサルティングの経験上、自治体でのプロジェクトでこれらの点は特に顕著に言えるのではないかと考えられます。
まず初めにこれは声を大きくして訴えたいところですが、
ＲＰＡを導入する前に、ＢＰＲに多くの労力をかけたほうが断然、効果が高まります。
ここでは例として、先ほど説明した「窓口業務」についての事例を紹介していこうと思います。
一般的に、窓口業務は、市民の方からの申請受付をしたあと職員がそのままシステム入力をして、
その入力結果を終えて、市民に各種証明書等の交付するフローを取ります。
この場合、申請書の種類によっては交付が必要ないものもあります。
また、窓口対応終了後、事後に事務所内で再チェックをするケースも多いです。
凡そのフローをまとめると以下になります；
＜窓口業務の一般的な業務フロー＞
一般的に、自治体の窓口業務では、この窓口受付から証明書等の交付までを毎件一連の業務として行います。
このような「一件ごとに一連の流れで最後まで行う業務」というのは、実はＲＰＡに差ほど適した領域ではありません。
本質的に、ＲＰＡが一番業務効率化の貢献ができるのは、複数件を定刻にまとめて処理する「バッチ処理系」になります。
もちろん、上記のような「一件ごとに一連の流れで最後まで行う業務」でもＲＰＡを導入することはできます。
ただ、この場合、ＲＰＡによる業務効率化効果が限定的になってしまう恐れがあります。
ロボットをシステム上のどこに置くのかにも影響を受けますが、一件ごとに職員とロボットがシームレスに連携して流れ作業を行う場合、
理想となるのはローカルの職員が扱っているＰＣの中にロボットを入れる形態です。
ただ、ここで問題が生じます。
そのロボットが動作している最中、職員はそのＰＣを操作することができず、
結果、その職員は他の活動ができず実質待機の状態になります。
これでは、ロボットにより生まれた余剰時間を有効活用できているとは言えません。
もちろん、ロボットによる１件の作業自体が、職員が行うより高速であれば、
例えその間職員は待機であったとしても処理時間の短縮は図れます。
これはコールセンターの例になりますが、コールセンターのオペレーターは、
電話をしたきた顧客の情報の精査、与信の計算など複数のシステムに即時にアクセスして情報処理をする必要があります。
この「複数システムを使用する」手間を省くためにＲＰＡでコンソールを作り、
ロボットが自動で複数システムにアクセスして結果を返す事例があります。
その場合、確かに、人間のオペレーターが作業するよりも時間の短縮が望まれ、
結果、１オペレーターあたりの処理速度・件数の増加の効果があります。
ただ、このような接客中に複数システムにアクセスしなければいけないような事例は果たして自治体の窓口業務でどれほどあるでしょうか。
そこで、自治体でＲＰＡの導入効果を最大にしたいと思うならば、業務フローの再設計、つまりＢＰＲの取り組みが事前に必要となります。
要諦となるポイントは、ロボットが最も効率的に動けるように、「複数件まとめて一気に片付ける（≒バッチ処理）」様な業務フローに再設計することです。
証明書の交付をその場でしないといけない業務については、システム登録を１件１件個別に済ます必要があるかもしれませんが、
そうではなく、申請の受付だけでその場は完結する、もしくは完了の通知は後日でも良い業務についてはシステム登録業務を後日にまとめてしまい、
ＲＰＡによるバッチ処理（手書き申請書であればＯＣＲの技術も必要ですが）にしてしまう方策が考えられます。
交付が必要な申請についても、本当に即日、その場での交付が必要なのか、後日郵送でもいいのかは真剣に検討する必要があります。
内容確認の必要については、後日の電話・メールで処理することもできます。
実際に民間の契約関連ではそのようなケースも多いのが事実であり、
自治体としても「何か何でも窓口受付のその場で完了まで済ます」というポリシーを見直す必要があるのではないでしょうか。
自治体におけるＲＰＡ導入ポイント１：業務フローの改善（ＢＰＲ）
次回コラムでは、更に自治体におけるＲＰＡ導入する上でのポイント・コツについて言及していきます。乞うご期待ください。
RPA導入についてご検討の方は、東京ビッグサイトで開催されるRPA導入無料相談会にてご相談いただけます。
弊社のサービス・お問い合わせはこちら。
次の記事：
2019.02.19
「RPA」という言葉を聞いて、どのようなことをイメージしますか？
実際に「RPA」に関わっている人は具体的なイメージを持っておられるでしょうが、
初めて「RPA」という言葉を聞く人からすれば、
「また新しい言葉が出てきたけど、もてはやすだけもてはやして、今回もきっとそのうち消えていくのだろう」
と思っている人がいるかもしれません。
確かに「RPA」という言葉自体はこなれていないイメージがありますが、
その実態は、今後の仕事の現場においてかなり浸透していく可能性を秘めています。
例えば、交通費を計上する場面を想定してみましょう。
「交通費」は、大企業や中堅企業だけでなく、中小企業をはじめ、個人商店や個人事業主でも、仕事をしている限り、ほぼ確実に発生する「経費」です。
つまり、ほとんどの人が関わっているとても身近な「経費」と言えます。
交通費の代表例として「通勤手当」が考えられますが、ここでは「通勤手当」以外の交通費を考えていきます。
月末（または翌月初）に交通費伝票を提出するルールを導入している企業を想定しています。
それでは、営業部の社員の立場と、経理部の社員の立場にわけて、それぞれのホンネを探っていきましょう。
商談先へ向かう途中、どのような話をするか、どのようなことを聞かれ、どのように答えるかを考えることで精いっぱいで、
とても交通費のことまで考える余裕はないかもしれません。
また、取引先からクレームが入り、「すぐに来い！」と言われた場合、
取引先までの交通費の計算を考えている余裕があるでしょうか。
なぜクレームになったのかを反省し、どのようにお詫びするか、
どこまで会社として対応できるかを事前に確認しておくことに集中せざるを得ないのではないでしょうか。
さらには、新規開拓することが仕事の営業社員の場合はどうでしょうか。
上司から「回る件数が少ない！数字が上がらないのは、動いていないからだ！もっと数を増やして回れ！」とプレッシャーをかけられていた場合、
果たして交通費のことを考えながら営業候補先を一日に何件も移動することができるでしょうか。
このように、営業の仕事に取り組んでいると、なかなか交通費のことまで頭が回らないのが正直なところではないかと思います。
でも、月末になると交通費を申請しなければならないとしたら、果たして正確に移動区間の交通費を申請することができるでしょうか。
もちろん、移動区間を毎日しっかりメモに残し、正確に交通費を申請する社員がいるかもしれませんが、
「こんな感じじゃないかな？」という内容で申請せざるを得ない社員も中にはいるかもしれません。
新幹線をはじめとする長距離の移動や、タクシー代等を除き、
交通費は領収証の添付を求められることはないでしょうから、「自己申告」をすることになります。
そのため、どうしても正確な申請をすることが難しくなってきます。
また、「月末のこの忙しい時期に、なぜいちいち交通費伝票を書かなきゃいけないのか！」と思うこともあるでしょう。
そうなると、ますます正確な交通費の計上は難しくなっていきます。
経理部で働いていると、会社が動かしている「お金」を正確に計上していく必要があります。
億単位の手形決済をはじめ、すべての「お金」は正確な数字しかなく、出金・入金のどちらにおいても、
金額に誤差が生じた場合は、その原因を追究していく作業が待っています。
出金や入金をはじめとした内容を一つずつ把握し、それぞれの動きを仕訳して正確な経費計上、売上計上、
原価計上等をしていくわけですが、一円でも金額が一致しなければ、その原因を探っていかなければなりません。
どうしても誤差の原因が把握できず、誤差の金額が少額である場合は「使途不明金」として「仮払金」や「仮受金」として計上せざるを得ないこともあるでしょう。
でも、「使途不明金」が積み重なっていくと、どうしても管理が甘くなっていくことから、
その都度全力で原因究明を求められるのが経理部の社員としての立場ではないでしょうか。
そのような緊張感で仕事をしているとき、月末（あるいは翌月初）に営業部をはじめとする各社員の「交通費伝票」が回ってきます。
交通費伝票を１枚ずつチェックし、計算は合っているか、区間と申請金額に大きな誤りはないかなどを見ていきますが、
中には正確性が疑われるものも混じっているかもしれません。
上司の印鑑やサインがない伝票があるかもしれません。
その場合は、その社員にその旨指摘し、伝票の再提出を要請せざるを得ないのですが、
「今は忙しいから、上司のサインはそっち（経理部）でもらっておいてよ」
と言い返されることもあるのではないでしょうか。
経理部としては、普段から正確性を要求される業務に取り組んでいるにもかかわらず、「交通費」だけは少し色合いが異なります。
全体の経費のうち、交通費の占める割合が軽微であれば、上司の印鑑やサインがあれば「有効」とみなし、
そのまま計上せざるを得ないのが現状かもしれません。
さらには、せっかく社員一人ひとりに交通費の申請をしてもらっているにもかかわらず、
最終的には会社としてのその月の交通費、あるいは部署ごとのその月の交通費の合計金額を把握することに追われ、
社員一人ひとりがどのような動きをしてきたのかということまでは把握する余裕がないのも事実ではないかと思われます。
交通費計上において、このような事態に陥っている会社に、「RPA」を導入することを想定してみましょう。
まずは、営業部の立場から考えてみます。
いろいろな取引先を回る際、「いちいち交通費を計算している暇はない」というホンネを取り上げ、
「RPA」で問題解決を図っていきます。
例えば、「交通費専用メールアドレス」を設け、移動するごとにスマートフォンで「出発駅」と「到着駅」を入力し、
「交通費専用メールアドレス」に送信すればよいこととします。
営業部の社員とすれば、いちいち交通費を計算する手間も省けるし、月末にその月の移動区間をまとめて思い出す必要もなくなります。
営業部の上司としても、担当する営業社員の交通費伝票が一人１枚ずつ回ってくるわけではなく、
「交通費専用メールアドレス」に送信され、「RPA」が自動集計した社員ごとの交通費一覧表が経理部から回ってくるので、チェックする作業が簡略化されます。
また、一覧表を確認することで、社員一人ひとりがその月にどのような移動をしていたのか、
誰が多く移動し、誰があまり移動していなかったのかなどをチェックしやすくなります。
次に、経理部の立場から考えてみましょう。
社員一人ひとりが「交通費専用メールアドレス」に移動のたびにメール送信し、
「RPA」が自動集計していきますので、他の経費と同じように、より正確な金額を把握していくことが可能となっていきます。
また、社員一人ひとりの交通費伝票をチェックする手間からも解放され、部署ごとの上司にその月の交通費一覧表を提出し、
まとめて１枚にサインしてもらえれば済みますから、作業自体がかなり簡略化されます。
さらには、それまでは「全体の交通費」の金額を把握するために社員一人ひとりに交通費伝票を提出してもらっていたわけですが、
「RPA」を通して社員ごとの移動区間が比較検討しやすくなりますので、
「今月は、〇〇さんが一番動いていたのだな」といったことや、
「〇〇さん、だんだん移動が少なくなってきているけど、大丈夫かな？
もし、疲れていたり、やる気をなくしていたりしたらいけないから、
早めに上司に報告しておいたほうがよいかもしれないな」
といったことが見えてきます。
このように、「RPA」を通して交通費計上の数値を、社員ごと、月ごとなどで比較検討することが可能となり、
そのデータをもとに考える余裕が出てきます。
「RPA」という言葉自体はあまり馴染みがないかもしれませんが、
その実態は社会のインフラのような存在になる可能性を秘めています。
今回は「交通費計上」について「RPA」の導入を考えてみましたが、
何か新しいことを始めなければ「RPA」と関わりを持つことができない、というものではありません。
今、目の前にある課題を解決できる可能性を秘めていることから、誰にでもお馴染みな存在になり得るのが「RPA」なのです。
2019.02.15
業務システムの導入を検討しているみなさんは、
おそらく繁雑で複雑な業務をコンピューターにやらせて楽したい！って想いがあるかと思います。
そこで、業務システムを導入する前にやっておいたほうが良いことについて、書きたいと思います。
業務システムを作る際のフローは大まかに、以下の工程に分解されます。
上記1～3をお客様の言う通りにシステム化しても何の問題もないように思えます。
しかし、その手作業でおこなっている業務に無駄な作業や、実はやらなくてもいい作業が含まれていたらどうでしょう。
システム化した際にも同じようにシステムにも無駄が残ります。
このような不具合が起こるケースとして2種類あります。
例えば、ＲＰＡのプロジェクトで、何かの情報ソース（Ｅｘｃｅｌ等）から、一件一件情報を参照して、システムに入力する作業を自動化するプログラムを組むとします。
その場合、人間の既存の作業工程だと、一件Ｅｘｃｅｌから情報を見たら、それをシステムに入力していくことになりますが、
これはロボットの動作ロジックとしては効率的ではありません。
ロボットで動かす場合、まずＥｘｃｅｌ等の情報ソースから「全件」情報を取得してしまい、
それを一気にシステムに入力するほうが効率的ですし、ロボットの処理速度も速くなります。
このような点は些細なことに思えるかもしれませんが、処理件数が膨大になると致命的な問題になりえます。
だがしかし、このような処理のプロセスの詳細までは、お客様側としては、差ほど注意をしておらず、結果だけを見る傾向です。
なので、重要なのは、お客様が仕様で伝えたことをそのまま鵜呑みにせずに、
ＳＥの観点からシステム上で動作に適した処理プロセスを提案していくことです。
過去に、お客様からの依頼で、既存のシステムの改修を頼まれて、コードを見ることがありますが、
意外とそのような配慮がなく、（プログラム上最適ではなくても）お客様が言った通りの処理ロジックにしてしまっているな、、、という感じを受けることが多々ありました。
（２）人間側の作業プロセスを頑なとして変えないケース
また、システム開発をしても、人間側の作業は多少なりと残ることになりますが、
その人間側のフローをシステムに合わせて変えるのではなく、今までのやり方を頑なに踏襲してしまうケースもあります。
例えば、受付業務に対してＲＰＡを導入するケースで、もともとの既存の業務フローでは、
1件1件訪問者からの申請書類を受付担当が目視チェックし、システムに入力していました。
ただ、この業務をＲＰＡで自動化する場合、本来もっとも効率がいいのが、
受付では一旦紙での申請書受領に留め、1日の最後にバッチ処理のようにＲＰＡがＯＣＲをかけてまとめてシステム入力処理をする方法になります。
この場合、業務フロー自体の変更が求められるわけですが、お客様側としては、今までのフローを変えるのに抵抗があり、
本来ＲＰＡの観点からすると最適なやり方に変えきれないケースが多いです。
ただ、それだと本来ＲＰＡを含めたシステム導入の目的である、効率化の効果が限定的になってしまいます。
このあたりは、システム導入するまでに業務を行う現場側でしっかりと意識合わせをするのが重要なのではないでしょうか。
まぁ、お客様がそれで満足するならそれはそれで良いのではありますが。。。。
しかし、後になってから無駄作業を取り除きたい！となった場合、人に対しては口頭で言えば済みますが、コンピュータは万能ではありませんので、
いったん作ってしまったシステムを修正するには、多くのお金と時間が必要になります。
現在ベンダー経由でシステム構築をされた企業様においも、このような理由で本来必要のなかった改修を行わざるを得なく、多大な改修費用が発生しまったケースをよく聞きます。
そこで、システム化する前に業務フローの見直しをしてみましょう！という提案です。
少なからず 1.のタイミングで意識しなくても、それっぽい業務フローの見直しは行われるかとは思いますが、改善や効率化とまではいかないのではないでしょうか。
改善や効率化を考えた業務フローの見直しは、なかなか難しいし、めんどうですが、システム化を機に取り組むチャンスです。
システム化する作業の担当者は、自身の行っている業務がベストだと考えている場合も少なくありませんので、
開発プロジェクトに参加するSEやPGは客観的にロジカルに物事を整理することが得意な人たちですので、
彼らの能力をフルに活用し、業務フローの見直しを行ってみてもいいかもしれませんね。
外部の意見も聞きながら業務フローを見直すことで、新しい発見もあるかもしれません。
ですが、SEやPGはシステムを作ることについてはプロですが、その業務については無知識です。
実際に作業される方がその業務において、プロですから、あくまでも参考程度でしょうけどね。
1.の部分で必要な業務の手順を整理出来たら、次は2．のどの部分をシステム化するかです。
例えばシステム化対象の作業の、この部分は自動化したほうがいいな、この部分は人の手が入ったほうがスムーズだな、などに切り分けをします。
専門用語で1.と2.は仕様決めですかね。何を作るか？のフェーズです。
次に3.ですが、画面はどういった画面でどのように遷移するや、出力結果を誰々にメールするや、出力結果をほかのシステムに投入する、などどういったことを技術的に検討します。
ここではどうやって作るか？のフェーズになりますので、設計のフェーズですね。
ここまできて、システム化が現実味を帯びてきます。実際に作っていくフェーズですね。
本当であれば、1.で、業務フローを見直した後に、手作業による運用を行い、
手順などの検証をしてからシステム化したほうが、リスクも抑えられて、良いシステムができるような気がしますが、
この後は作りながら、直しながら作っていくことになるでしょう。
こうして完成した業務システムをテスト運用していただいて、初めて完成となります。
こうした業務フローの見直しをせずに、開発した場合、すくなからず、意思疎通がおろそかになり、プロジェクトがうまくいかないことがあります。
お客様の頭の中のイメージと実際出来上がったシステムの乖離が大きい場合ですね。
作り手は言われたとおりにもちろん作ります。
でも実際はお客様のイメージとは違う場合があるんですね。
こうしたことにならないよう、我々SEは提案するための選択肢を多く持ち、
物事を決定してから作業に取り掛かる必要があるでしょう。
ただ、合理的に考えれば、そうなるはずなのですが、実際のシステム開発現場では、
往々にして合理的な判断にならないことが多いのも事実です。
それは、しがらみというか、業務を行っている現場の人たちが本質的に「変化」を忌避する性向があるからです。
合理的に正しかろうが、間違っていようが関係なく、今までの自分のやり方を変えたくない、
今のやり方がベストプラクティスだ、、、そういう偏見をもともと持っているのだと思います。
高いお金と時間をかけて開発する業務システムです。
無駄の少ないシステムを作ったほうが、発注側も受注側もお得なのではないでしょうか。
2019.02.14
2018年上半期（1月～6月）の全国の企業倒産は、件数が4,148件、負債総額が7,466億300万円でした。
倒産件数は前年同期比2.7%減（119件減）で、上半期としては9年連続で前年同期を下回り、
1990年（2,948件）以来の低水準に留まりました。
都道府県別では前年同期を上回ったのが22府県、減少が18都道府県になり、
地区別では全国9地区のうち、5地区（東北、中部、近畿、四国、九州）で前年同期を上回りました。
また、産業別では10産業のうち、7産業で前年同期を下回りましたが、
サービス業他（前年同期比0.1％増）が3年連続の増加、
小売業（同0.5％増）が上半期としては2007年以来11年ぶりに増加に転じるなど、
個人消費関連業種を中心に今後の推移が注目されます。
上半期倒産企業の特徴は次のとおりです。
従業員5人未満の構成比が74.49%で上半期では過去20年間で最高の水準となっている一方で、
負債10億円以上の大型倒産が28年ぶりの100件割れ、資本金1億円以上の倒産が過去20年間で最少となるなど、
企業規模によって倒産の傾向が異なっています。
東京商工リサーチによる2018年上半期の「人手不足」関連倒産のコメントは以下のとおりです。
“ 2018年上半期（1-6月）の「人手不足」関連倒産は184件
（前年同期比12.1％増、前年同期164件）で、前年同期を上回って推移している。
内訳をみると、「後継者難」型が145件（前年同期比11.5％増、前年同期130件）、
「求人難」型が19件（同18.7％増、同16件）、「従業員退職」型が10件（同25.0％増、同8件）、
「人件費高騰」型が前年同期同数の10件になり、「後継者難」型が約8割（構成比78.8％）を占めた。
2018年上半期（1-6月）の産業別では、最多がサービス業他の50件（前年同期比25.0％増、前年同期40件）。
次に、卸売業35件（同75.0％増、同20件）、建設業32件、製造業31件、小売業14件の順。
2018年上半期の地区別では、全国9地区のうち関東（71→81件）、中部（17→23件）、
東北（8→15件）、四国（4→8件）、北陸（1→2件）の5地区で前年同期を上回った。
一方、減少は近畿（23→17件）、中国（10→9件）、北海道（12→11件）の3地区。
九州は前年同期同数の18件。“
2015年の年間の人手不足倒産件数の内、
「後継者難」型の割合は87.7%、2016年は88.8%、2017年は78.7%、2018年上半期は78.8%となっています。
後継者不足による、「後継者難」型の割合は低下している一方で、
「求人難」型・「従業員退職」型の割合が増加しています。
人手不足が叫ばれる中、人手不足による影響が具体的な数字となって表れてきています。
1.「後継者難」型
代表者、役員の死亡・引退などに際し、事業承継者（後継者）がいないことによる廃業・倒産
2.「求人難」型
人手確保が困難で事業継続に支障が生じ、廃業・倒産
3.「従業員退職」型
中核社員の独立、転職などの退職から事業継続に支障が生じ、廃業・倒産
4.「人件費高騰」型
賃金等の人件費のコスト増から収益が悪化し廃業・倒産
代表者等の高齢化に伴う「後継者難」型の廃業・倒産は引き続き高い水準で推移すると思われますが、
今後は「求人難」型・「従業員退職」型・「人件費高騰」型の廃業・倒産割合が増加していくことでしょう。
1. 生産年齢人口の減少
国立社会保障・人口問題研究所の発表によると、日本の総人口は2015年10月時点で約1億2709万5000人。
そのうち、15歳～64歳までの生産年齢人口は約7728万2000人となっています。
しかし、少子高齢社会の影響により、この数字は今後急激に減少すると予測されており、
2040年における生産年齢人口は約5977万7000人、
2100年には約3073万7000人にまで減ってしまうと考えられています。
2. 求人倍率の上昇と失業率の低下
2018年6月の有効求人倍率は1.62倍と高い水準となっています。
また完全失業率は2.4%となっています。
求職者の選択の余地が増えることで労働環境やイメージが悪い業界はより人手が不足する状況になります。
3. 賃金の向上が期待できない
厚生労働省は7月10日、今年の中小企業の賃金上昇率が1.4％だったと発表しました。
今年度の最低賃金の引き上げ幅の目安を決めるうえで重要な参考データとされるもので、
人手不足を背景に前年を0.1ポイント上回りました。
ただし、政府が目指す最低賃金の引き上げ幅の年率3％程度と比べると、伸びは小幅なものとなりました。
大企業に比べ財務基盤が弱い中小企業が人件費に投下できる資金は限られているため、
賃金向上に期待が持てなくなった社員が退職したり、
採用の優位性を保つことができず人材の確保で難しい状況になり、人手不足の状況となります。
今のままで仕事は回っているのに、なぜ業務効率化が必要なのでしょうか。
業務効率化は企業活動において必要事項で、これを怠ると徐々に会社の業績が悪化してしまいます。
社会や経済は日々動いており、顧客のニーズも速いスピードで変化します。
その変化に対応できる企業が生き残っていき、成長もしていきます。
このような環境下で利益を積み重ねていくためには、現状維持では企業価値が低下していきます。
業務効率化を図ることで、業務効率を最適化し、利益を最大値まで引き上げることができます。
最大化された利益を元に資金調達を行い、そのキャッシュを次の投資に回し、
投資回収することで魅力ある企業となり、採用優位性を高めたり、
人材の流出防止につながることが期待できます。
業務効率化に着手する際に効果的なシステムとして「SaaS」や「RPA」などがあります。
SaaSは、各業務の作業をシステム化し、人がそのシステムをクラウド上で利用します。
業務領域は業務特化されており、人がシステムに合わせるといった特徴があります。
メンテナンス等は全てSaaS提供会社によるものであるため、
自社でその必要はなく、常に最新の機能を搭載した状態で利用可能です。
RPAは、人がマウスやキーボードを使用した作業をRPAに覚えさせて対応させます。
基本的にすべてのオペレーションを自動化できるため、どの業務領域にも適応でき、SaaSに比べ柔軟性は高いです。
大量に同じことを繰り返すPCオペレーション作業についてはコストメリットを享受できます。
ただし、Web上のボタン位置が変更になるなど、
動作ルールが変更になった場合には適宜メンテナンスを行う必要があります。
中小企業では手作業で行われているアナログ作業もまだまだたくさんあるのが現状です。
SaaSやRPAの特徴を踏まえ自社に最適な業務効率化システムを導入することで、
人材不足への対応を図ることができます。
SaaSやRPAなどのITツールの導入に際しては、
経済産業省で行っている「IT補助金」を活用することで、最大50万円が国から補助されます。
IT補助金で、SaaSやRPA導入の心理的・資金的ハードルは下がると思いますので活用をおすすめします。
人手不足倒産の「求人難」型、「従業員退職」型、「人件費高騰」型は、今後増加していく見込みです。
人手不足によって、徐々に自社の財務内容が棄損し倒産に近づく前に、
RPA等を導入した業務効率化に取り組むことを考えてみてはいかがでしょうか。
2019.02.13
◆RPA化において考慮すべき点
人間が行っているような単純作業においては絶大な威力を発揮するRPA化ですが、
システムを導入するにあたって、利益の追求や効率化を計るだけではなく、
他にも考えないといけないこと、というのはたくさんあります。
その中の一つにシステムのリスクマネジメントがあります。
多くの場合はロボットの性能や効率化に重きを置きがちで、
ITガバナンスの確立を忘れがちですが、ここはとても重要なポイントになってきます。
これは少し余談ですが、プログラミングに慣れている人と初心者の人で違う点は
エラーの数だとよく言います。
プログラミング経験者もすべてのエラーを追えるわけではないですが、エラーの対処をある程度は組み込んでプログラミングすることができます。
実際、プログラミングを全くしたことのない人でもUiPathやWinActorなどのRPAのツールを簡単に使うことは出来ます。
しかし、全体像を把握し、そしてある程度のエラーにおける対処ができるようになるためには
何かしらのプログラミングをできるようにすることをオススメします。
このようにリスクマネジメントは非常に重要なファクターになってきます。
今回は、システムの簡単なリスクマネジメントと共に
一般的なセキュリティ面の注意点を見ていきたいと思います。
◆ITガバナンスの確立に向けて
みなさんはITガバナンスと言う言葉について知っているでしょうか。
「ITに関するルール」のようなものだと思っている人もいるかと思いますが、それは間違いです。
「ITに関するルール」はあくまでもITガバナンスを確立するための手段の一つでしかありません。
そもそもITガバナンスというのは経済産業省で以下のように定義されています。
“
企業として、ITに関する企画などの運営を行う際に情報資材に関わる機密性や完全性、可用性のリスクを管理するための仕組みを組むこと。また、その仕組みのこと。
”
（経済産業省 「情報セキュリティガバナンス導入ガイダンス」参考
http://www.meti.go.jp/policy/netsecurity/downloadfiles/securty_gov_guidelines.pdf）
この定義から分かることは、
「組織の目指すべき姿へ向けて行わなければならない仕組みを全体になじませること」
がITガバナンスを確立するうえで大切になってくるということです。
企業の理念や経営戦略に向けての仕組みとして、「ITに関するルール」が存在しているのです。
この際に、注意してかないといけない事は大きく分けて三つあります。
１、世間の環境や経営戦略などの変化に応じて臨機応変なIT戦略の仕組みの作成
２、ITの戦略を実行していく上でのセキュリティ面の確保
３、仕組みを円滑に実行するための組織力の向上
今回は特にセキュリティ面についてみていきたいと思います。
以下の三つは先ほどのITガバナンスの定義にも出てきましたが、
情報セキュリティの三要素と呼ばれているものです。
「機密性」・・・許可のないアクセスには情報を渡さない
「安全性」・・・情報が常に安全な状態であること
「可用性」・・・許可されたアクセスには必要なときに情報の利用が可能なこと
これら三つががシステム構築の目的になることが多いです。
◆共通フレーム 2007
以上のようなITガバナンスを確立するのを助ける仕組みとして、
SLCP(Software LifeCycle Process)と言うモデルが用意されています。
SLCPとは開発・運用・保守などのソフトウェアの工程全体を標準化した枠組みのことです。
とても簡単に言ってしまうと、色々な人が色々な言葉を使うと誤解が生じたりするので、このモデルを標準としよう、としたものです。
ここには言葉の定義や各工程の内容などが書かれています。
ここで定義された用語によって、システム開発者と委託者の相違を避けることができるのです。
では、どのようなものがあるかと言うと、
「ISO/IEC 12207」
「SLCP-JCF (Japan Common Frame：共通フレーム)」
というものが存在します。
「ISO/IEC 12207」は国際標準化機構によって標準的なモデルとして用語の定義などを行ったものです。
1995年に策定されましたが、2002年と2004年に改訂されています。
さらに、この「ISO/IEC 12207」を日本で使えるようにしたのが「SLCP-JCF (Japan Common Frame：共通フレーム)」です。
情報処理推進機構によって1996年に策定され、1994,1998に改訂され、
今は「共通フレーム2004」が標準となっています。
「共通フレーム」は簡単に言えば、「ISO/IEC 2007」の日本語版なのですが、
共通フレーム は日本でも不自由なく使用するために
日本独自の事情などを考慮して作成した枠組みとなっています。
今では開発から導入、運用、保守までのプロセスを確認していく上では開発側だけではなく、発注側も必要不可欠の知識となっています。
◆リスクマネジメントの流れ
リスクマネジメントとは、リスクを分析してどう対処するのかをまとめたもので、
損失を回避する、または軽減することを図るものです。
リスクマネジメントのプロセスは以下の通りです。
リスクの分析は、以下の項目を考えていきます。
＜リスク分析の範囲＞
守るべき範囲を決定します。
例）社会全体、ユーザー、社内の情報システム課
＜何を守ればいいのか＞
上で決めた対象範囲内で守るべきものを洗い出します。
この際に、その情報の利用者や管理者、保管場所や廃棄方法をリスト化してまとめます。
例）
|
名称 |
利用者 |
保管場所 |
廃棄 |
|
利用者情報 |
顧客 |
自社サーバー |
利用者による申請時 |
＜守るべきものの分類＞
情報セキュリティの三要素である、
機密性・安全性・可用性
にもとづいてレベル分けすることで守るべき情報資材を分類します。
例）
|
名称 |
機密性 |
安全性 |
可用性 |
|
利用者情報 |
3 |
5 |
4 |
ここでは以下のような式にもとづいてリスク値を計算します。
リスク値 ＝ 情報の価値 × 脅威 × 脆弱性
以上が非常におおざっぱではありますが、リスクマネジメントのフローです。
このように、リスクマネジメントを行うことで様々な状況に対応できるようになります。
2019.02.12
前回第4次産業革命について、IoTをはじめとするICT領域のアップデートについて述べましたが、
今回はAIについて最近の動向を交えてお伝えいたします。
【前回記事はこちらから】
AIは、近年で最も技術革新がめざましい領域で、多くの研究・開発が進められています。
将棋やチェスのボードゲームなどでプロを相手に対戦したり、自動車の自動運転技術に用いられたり、
或いは、人と会話ができるロボットが登場したりと、
数十年前に映画やアニメで描写されていた「人類の夢」が、現実の世界に登場しつつあります。
華やか且つ先進性がありアトラクティブなイメージのある一方で、そういったAIの技術が今日の、
特に日本の経済活動の中でどのように活用されているか、イメージが湧かない側面があるのも事実です。
言い換えるなら、「話題性があるが、その実誰も利用方法が分からない。」そんな領域かもしれません。
こと国内のビジネスシーンにおいて活用されているAIとしては、以下のようなものが挙げられます。
【販売予測・需要予測】
とあるホームセンターでは、AIを用いた売上予測システムを導入しました。
ある季節商品の過去3年分の販売実績と気象情報をAIツールに学習させ1日単位で売れ行きを予測させた結果、
売上予測と実販売量の誤差が僅か2個という精度での予測を達成し、
従来人力で行っていた発注業務時間を大幅に短縮するだけでなく、余分な在庫を抱えることもなくなりました。
続けて同社では、生花の仕入れにもAIを活用しています。
生花はつぼみの状態で仕入れれば、長時間店頭に置いて置ける反面、お客さんには魅力的には映らず売上が伸びません。
逆に花が開いた状態で仕入れれば、当然枯れるのも早く売り物になりません。
こうしたジレンマを解消するために、上記の販売予測に組み合わせて用いられたのが「画像認識」でした。
予め従来の仕入れ担当者が販売する花の選別をし、AIに画像を取り込み学習させます。
AIは花の開き方や葉の大きさから4段階に評価して仕入れる花を決定します。
最初は思い通りの精度ではなかったものの、
その都度AIに修正をかけて、制度を高め最適な状態で仕入れすることに成功しています。
また、店頭での在庫管理にも用いられ、花の状態に応じて廃棄・値下げ販売を実施することで、
ベテランの生花担当者だけでなく、園芸に精通していない従業員でも正しく管理を実施でき、
一定の品質を保つことに成功しています。
従来、長年の経験とそこから導き出される勘が頼りだったのが客探しです。
新人や経験の浅いドライバーが売上を上げるのは容易ではありませんでした。
そこで導入したのが、需要予測サービスでした。
過去の運航実績データだけでなく、走行する各エリアごとにリアルタイムで人数を把握します。
最も需要がありそうなエリアを探索し、社内のタブレット端末に通知、進行方向まで指示してくれるシステムです。
このエリア内の人数は、携帯電話の基地局を通じスマートフォンの位置情報をデータとして取り込んであります。
当然ながら、雨の日はそれだけ需要も高まるので、気象状況を加味した予測を立ててくれるというものです。
AIを使った需要予測として以下のソリューションが各社で展開されています。
富士通：需要予測API
店舗などで販売する商品の需要と売上を予測します。
売上予測モデル作成には、
POSデータに加えて天気やカレンダーなどの外部データを学習させ役立てることが可能になります。
NEC：流通・小売り向けAI群
売上最大化を目的とした特売価格のシュミレーションや、
顧客一人ひとりの趣味・嗜好を踏まえたマーケティングの実施や発注ロジックの構築に特化しています。
欠品防止や廃棄ロス削減、在庫適正化をより精度高く実現する多彩なソリューションが魅力です。
docomo：AIタクシー
人の流れがリアルタイムにわかる携帯電話ネットワークの仕組みを利用して作成される人口統計データと、
タクシーの運行データなどを用い、AI技術を利用してタクシーの需要を予測しています。
効率的なタクシー運行の実現により、ドライバーの生産性向上に貢献し、
また、タクシーを利用者が短い待ち時間で乗車できるので、満足度の向上も見込めます。
【ディープラーニング】
従来目視で行っていた特定製品の外観検査は、熟練工の高齢化やノウハウの継承が進まないばかりか、
作業者によって精度のバラツキがあり、品質の均一化に苦慮していました。
同時に、スキャンデータを用いた画像診断を用いていましたが、検査パラメータの設定が高度且つ複雑であり、
その上判定精度もまちまちで不良品の発見率が芳しくありませんでした。
そこで、ディープラーニング技術を用いた画像診断ソリューションを導入しました。
画像を取り込ませることで製品の特徴や判定に必要なパラメータをAIに学習させ、
精度の向上と検査判定の均質化を実現しました。
結果、不良品の検出率を95％以上にまで向上させることに成功し、実用に耐えうるツールとして認識されました。
従来作業員が直接現場に出向きインフラシステムの点検、劣化診断を行っていましたが、
その点検対象は高所や高速道路の橋梁など、常にリスクが付きまとう危険なエリアでの作業が大半でした。
加えて人手不足も深刻化しており、一人あたりの業務負荷量も多くなっていました。
そこで、監視システムやドローンを使って撮影させた画像・映像データを基に、
画像診断による保守点検作業に切り換え、効率的な劣化診断のシステムを構築。
これにより、作業員がわざわざ出向き危険な場所での作業を最低限に留め、
より効率的な保守点検業務を遂行することができました。
当然、慢性的な人手不足も、AIソリューションによって負担軽減が図られました。
各社共、紙媒体としての新聞のみならず、WebニュースやSNSに情報を配信することは、もはや当たり前になってきました。
通常、記事のオンライン版作成の際は、
「配信記事の選定」「メディア編集システムへの送信」「記事要約」「見出し作成」「校閲」
というプロセスを経る必要がありますが、中でも最も時間を要するのが「記事要約」だといわれています。
従来、記事の重要部分を人間の目で判断しながら、
メディアごとに異なる文字数制限に合わせて要約文を作成していましたが、
手間がかかる上に、リリースの多さから大幅な時間をとられていました。
従来から自動要約ツールを用いてはいたものの、
先頭分から指定の文字列を抜き出すために、記事の構成によってはうまく機能しませんでした。
そこで、ディープラーニングを用いた自動要約ツールを新たに設計、導入しました。
「重要な単語を含む文」、「文頭・文末に近い文」「多くの分と類似する文」を重要とみなし、
接続語についても、「すなわち」、「つまり」で始まる文は加点、
「たとえば」で始まる分は減点というように重要項目中質の指標を設定し、重要項目を抽出しています。
これにより記事の構成上、重要文が記事の中程、文末にあっても要素を抽出することが可能にしました。
さらに従来1つ3～5分かかっていた要約の時間も、瞬時に終了し、精度向上にも貢献させることができました。
ディープラーニングを用いたソリューションは以下のようなものがリリースされています。
IBM：IBM Power AI
ディープラーニングの人気のツール(TensorFlow、Caffe、Chainerなど)を
IBM POWER環境向けにコンパイル・最適化したソフトウェアパッケージで、
ツールの組み合わせの調整やビルドの煩わしさがなく比較的スムーズに導入を検討できる
日立：画像認識ソリューションサービス
ディープラーニングソリューション適用のポイントとなる、
データのクレンジングやフレームワークの選定まで一括で手掛けています。
導入事例も豊富で多彩な分野に納入実績があります。
今回は最新の事例を元に、具体的なAIソリューションをご紹介してまいりました。
AIはまだまだ途上の技術であり、今後ますます活躍が期待されています。
AIには前段階、より単純な概念としてRPAがあります。
まずは、こちらを単純作業に導入して効果の程を実感し、AI導入の足掛かりとしてみてはいかがでしょうか。
2019.02.07
AIにより10年後になくなる職業ランキングなるものが繰り返し報道、SNSシェアされています。
しかし、日本のほとんどを占める中小零細企業の社長さんが、
そもそもITリテラシーが低く、いまだにガラケーで電話のコミュニケーションしか取らないと言っている中、
そんな社長さんを相手にする士業がAIにリプレイスメントされるとは、私は思いません。
（社長もどんどん若返っているという意見もあると思いますが、
私の周りの40代社長の多くはいまだにオールドファッション側にいます。
と、いうことは20年後くらいまで中小零細企業の社長はITオンチだと思います。）
AIを云々言うのは時期尚早かもしれませんが、RPAとなると話は別です。
私は、RPAこそ士業にマッチするテクノロジーだと考えています。
業界の方からすると「そんなことは分かっている」と言われそうですが、
あえて他の業界の方にも分かるよう、少し初歩的なことから。
税理士の仕事において、最もミニマムなのは顧問として、決算申告書を作成し税務署に申告を行うことです。
顧問料として、2〜3万円毎月、決算時期には会社の規模にもよるでしょうが、
30万円程の作業料を取るというのが一社当たりの売上です。
まあ最近はWEB使ったお客さんの獲得なども盛んな為、
顧問料はどんどん安くなっていっている傾向があるようですね。
そこに記帳代行や給与計算、振込入力などの毎月のルーチン業務のアウトソーシングが加わり、
プラス5万、10万と月々の一社当たりの売上が増えていく構造です。
ただ、このアウトソーシング業務は、税理士事務所によって捉え方が違うようで、
大きく３つに分かれるようなイメージです。
まず一つ目、出来るだけ顧問料だけでやっていきたい税理士事務所。
古くからある所長が高齢化している事務所はこのタイプが多いですね。面倒はしたくない。
街に必ず存在する管理物件の管理費だけで存続できるから
無駄なことをしたくない超ヒマそうな不動産屋さんと同じ原理ですね。
わざわざバイト雇ってアウトソーシングするにも、その管理も大変だし。
税理士法人化してない個人事務所の場合がほとんどですね。
まあ彼らは、そもそも成長しようという意欲がないので、あまり新技術の導入にもピンとこないでしょう。
残りの二つは、どちらもこれから成長しようという意欲的な税理士さん。
まずはコンサル志向。出来るだけ付加価値の高いサービスを提供したいという税理士法人。
コンサルティングとは、月次決算からの、それをベースにした資金繰り、
また事業成長の為の投資余力や、CF経営の意識づけなど、
クラアント企業がそこそこ大きくなってきて、社長が本気で経営したいという意識が芽生えてきてからのお手伝いです。
彼らにとっての一番の悩みはアウトソーシングの処理。
まずこれから成長しようという税理士は独立したばかりの方が多く、
クライアント企業も新規創業をとっていかざるを得ません。
そうすると、クライアント側に経理などいるはずもなく、勢い全て税理士事務所へ丸投げという状態になります。
社長が何も考えずに使った訳のからない領収書、くしゃくしゃの請求書などが渾然一体と封筒に入れられ送られてく。
それを一つずつ社長に確認するが、適当に処理しておいてよという返事。
理想としていたコンサルティング業務からは程遠い作業に追われ、貴重な時間の90％は消えて行く。
コンサルティングやその為の自分の勉強に割ける時間はほとんど無いのが実情です。
最後が、この面倒なアウトソーシングを全て取っていこうという意欲的な税理士法人。
多くは顧問をメインとする税理士法人に加え、記帳代行や振込入力のBPOを別法人として独立させていたりします。
記帳代行、給与計算、振込入力、請求書発行、たくさんある経理業務も、その全ては恐ろしいほどの単純作業です。
必然的に規模の経済がものをいう世界。どんどんお客さんを獲得し、
どんどん仕事まわしていこうと考えるも、そこで壁にあたってしまうのが、「人不足」。
営業力はまだまだあるのに、人手不足で新規の仕事を全て断っている
という話を何人かのBPOに意欲的な税理士法人から聞きましたが、
まさにここが本記事におけるメインターゲット。
RPAにより大きく飛躍できる士業だと思います。
そもそも士業の先生は、ITリテラシーがそれほど高くない。
これは、致し方ないことであって、
文系の最高分野である士（サムライ）業にとって、自身の分野の知識はまさに剣。
昔のサムライが商いを忌避したように、分野以外の知識がなくともこれまで成り立ってきたのだと思います。
そんな先生たちにAIというと、自分の仕事を奪うかもしれない不穏な奴と思われるかもしれません。
ですが、RPAは違うんです。
RPAこそ、先生たちの強い味方。
AIと違って何にも考えないですが、真面目に単純作業を淡々とこなしてくれる可愛い奴なんです。
当社で開発した「クラウドRPA鉄腕経理」の紹介を兼ねて、お教えしましょう。
「クラウドRPA鉄腕経理」は、記帳代行と振込入力の二つを行います。
（現在、給与計算や請求書発行など他のサービスも開発検討中ですが、
まずはメジャーなこの二つからローンチしました。）
記帳代行機能は、RPAが銀行のシステムから通帳データを自動で取得し会計システムへ入力していきます。
また領収書はデータ化（例えばエクセル）された状態から自動でデータを取得し、自動で会計システムへ入力していきます。
他、クレジットカードならば信販会社のシステムへ自動で入りデータを抽出し会計ソフトへ入力するなど、
パソコン内で完結する作業はブラウザでもメーラーでもオフィスでも各種システムでも
横断的にロボットが自由自在にデータを入手、入力できるのです。
そして、振込入力機能は、この会計システムに入ったデータを
自動的に銀行システムへ振込入力していき、承認の手前まで終えて承認確認をするという機能。
企業によって入力の量なども変わりますし一概には言えません。
ただ、当社の方で税理士法人の中心的なクライアントである1〜3億円程度の中小企業をベースに試算したところ、
だいたい記帳代行が1日程度、振込入力が2日程度の作業量削減となりました。
経理担当者が3日程度楽になる試算ですね。
これが多いか少ないか、一企業にとってはたったの３日？となるかもしれません。
しかし、BPOで100とか300社とかやっている会計法人にとっては、100社×３人日、
300社×３人日です。その業務削減効果は小さくはありません。
またコスト削減効果以上に、このタイミングで業務を標準化し、
RPAによって自動化することの将来的な意味は計り知れません。
新規の業務を何の憂いもなく営業できるトップの安心は、
成長を目指す意欲的な税理士さんにとって最も大切なことでしょう。
当社では、この「クラウドRPA鉄腕経理」導入費無料で税理士法人へ導入してもらっています。
実は、このRPA、導入が一番大変なんです。
導入の際の各種データの標準化、各社ごとの設定が一番の手間となり、
導入するのに数百万円の投資が必要という事も多くあります。何事も良い事ばかりではないですね。
しかし、当社では月々の一社当たりの御社アウトソーシング料の中から、
いくばくかを毎月の払っていただくだけで、初期投資ゼロ円のRPA導入を実現しました。
これからのテクノロジー社会、士業にとっての良質なテクノロジーパートナーでありたいと願って。
2019.02.06
近年、労働人口の減少に伴い、急速に人手不足が進行しているのが接客業です。
実際、東京都における有効求人倍率（2017年11月時点）を職業別に見ると、
「サービス（接客・給仕）」は8.98倍と群を抜いて高く、全職業の1.8倍を大幅に上回っている現状があります。
また、最低賃金の上昇に伴いオペレーションコストが急増。
そのため、
少ない人数でシフトを回す⇒一人あたりの業務負担増
⇒労働環境の悪化⇒雇用の安定化につながらない⇒採用活動が思うように進まない
といった負の連鎖を引き起こしています。
こうした背景から、政府の推し進める「働き方改革」も、接客業の最前線に立つ現場スタッフにとっては、
他人事のように感じてしまうことも多いのではないでしょうか。
今回は、接客業の業務効率化や労働環境の改善に寄与するべく開発された
「接客業向けAI技術」を利活用した事例を基に、今後の接客業動向を探っていきたいと思います。
こと接客業において、人が人に対して行うサービスは多岐に渡り、
AI技術で賄うにはまだ十分技術革新が進んでいるとは言い難いです。
……などなど、現状超えるべき課題は多々あります。
もちろん上記すべてをAIで代替してしまうのは、人同士のコミュニケーションを奪ってしまうことにほかならず、
接客業の本来の良さが失われてしまいます。
AIの求められるのは、「人が行わなくても特段不都合がなく業務負荷が重い業務」を代替し、
その分人が新たなサービスを創出し、より顧客一人ひとりに寄り添ったサービスに
シフトできるようにするといった柔軟性の高い機能なのではないでしょうか。
ここからは実際に接客業の最前線に取り入れられているAI技術について、個別の事例を交えてご紹介します。
今回は、特に小売業にスポットを当てていきたいと思います。
コンビニ大手・ローソンの全店舗で2017年から導入されている「セミオート発注システム」は、
過去の販売実績やその日の天候などを考慮。
そこから導き出される最適な商品数をAIが算出し、ボタン一つで発注できるシステムです。
こういった店舗での発注は、経験に依るところが大きく、それゆえアルバイトに権限委譲することができず、
社員が休日出勤をしたり、残業をしたりして販売動向分析、インベントリー、
販売戦略まで行い対応することが多いようです。
そこでローソンでは、弁当など約400品の発注をセミオートに切り換えました。
従来オーナーや店長が売れ行きに応じ、商品ごとに発注していた時間を短縮することに成功。
また、操作が分かり易く、特別な分析や経験に依る判断を要さなくなったため、
アルバイトに業務を任せることにも成功したといいます。
ユニクロでは、公式アプリ上でAIを活用したチャット自動応答システム（チャットボット）
「UNIQLO IQ」を今年導入しました。
ユーザーからの音声による問い合わせ内容に応じて、AIが回答を自動で返す仕組みで、
店舗の在庫状況の確認、オンラインストアでの購入、
よくあるお問い合わせの確認やカスタマーセンターへの相談といった、買い物の一連の流れをサポート。
また、｢旅行｣｢オフィス｣｢女子会｣｢お花見｣｢デート｣といったシーン別のコーディネート提案や、
｢着やせする｣｢二の腕をカバー｣｢紫外線対策｣｢透けない｣｢雨｣などに対応する商品検索ができるほか、
48時間以内の売上げランキングや、星占いによるラッキーカラー商品の提案、
雑誌掲載アイテムの提案なども備えており、新しいショッピング体験のカタチを提唱しています。
こういった取り組みは、カスタマーセンターの業務削減や24時間即時対応、
販売機会ロスの削減などの業務改善にもつながるため、ユニクロはオンラインチャネルでの販売拡充に注力しています。
顧客の問い合わせにAIがネット上で自動応答する「チャットボット」の活用は、
人手不足に対抗し店舗とネットを融合させる動きに合わせて活用が広がっており、
以前より導入費用が安価に抑えられたサービスも登場してきました。
ティファナ・ドットコムがサービスを提供するAI接客システム「AIさくらさん」。
多言語対応可能な音声会話による接客、コールセンター業務の代替に加え、顧客行動追跡、ビッグデータ解析、
決済連携機能など、接客業の業務効率化に特化した近年導入が進んでいるAIソリューションサービスです。
大手ショッピングモール「イオンモール」は、地方立地の9店舗に「さくらさん」を導入。
対話型案内システムとして、デジタルサイネージを使用した施設案内情報の発信を行っています。
利用客の問いかけに応じて、おすすめやキャンペーンなども通知し、
自動発話によって能動的な接客を行うことで利便性、サービス向上に活用されています。
寝具メーカーの西川では、Webサイト上でお客様からの様々な問い合わせに対して、
24時間365日リアルタイムで回答するコンシェルジュサービスとして導入。
それまでお客様相談室宛に届いていた電話やメールの対応を軽減するとともに、
土日祝日も対応が可能となるため、顧客満足度向上にも繋がったといいます。
また、問い合わせの内容に関する様々なデータを蓄積することで、
どういう属性の顧客がどんな問い合わせをしているのか、目的別に類型化・ライブラリ化して学習することで、
精度の向上とサービス改善に役立てています。
同様に、すかいらーくグループでもWebサイトの利便性向上・顧客満足度向上を目的としてコンシェルジュサービスを導入。
また、スタッフがコミュニケーションをとるタブレット端末には、
社内ナレッジ共有や従業員スキルの向上に役立てられている「会社の生き字引機能」を搭載。
音声によるマニュアル再生や業務の引継ぎ業務パッケージ化を行い、スムーズな業務遂行を可能にしています。
少子高齢化による人材不足のあおりを、他の業界より強く受ける小売業界。
顧客に寄り添ったサービスが肝心要のため、
ロボットやAIですべての業務を代替できるような画一的なソリューションは、未だ登場していないのが現状です。
ただ、今後間違いなく伸長する分野であることは明白で、いずれAIでの接客が当たり前の時代がやってくるでしょう。
いざその時代がやってきたときに、同業他社に出遅れたりアレルギーを起こしたりしないように、
今の段階で一部業務を代替するなどしてある程度親しんでおく必要があるのではないでしょうか。
AIの前段階のソリューションとして存在するのが、RPA（ロボティック・プロセス・オートメーション）です。
RPAは、定型業務を自動で処理するロボット機能であり、
AIよりも多くの企業の経理・人事・総務といったバックグラウンド業務に活用されています。
導入もAIソリューションよりも低予算・短期で行うことが可能なため、
AI導入の前段階として非常に有用なツールであるといえます。
利用者と直接向き合うAIと、バックグラウンドで提携業務をドライブするRPAによる業務効率化の恩恵は、
利用者にとっても新たなサービス、快適性の向上といった点で顕れることが期待できます。
2019.02.05
言うまでもなく、どんな企業にとってもRPAを導入するには、
まず「どんな業務をRPA化する」のかを明確にしなければならない。
つまり、RPA対象業務の選定だ。
RPAが得意なものとして、
パソコンを使った「大量重複している作業」と「ルールが明確している作業」というものがある。
では、企業の中にこの二つの特徴のある作業を洗い出し、
その業務フローも明確化したらRPA開発が先に進められるようになるのか？
もちろんそういうわけではない。
ざっくりのプロセスを言うと、まずRPA化対象業務を選定する。
その次が対象業務をマニュアル化する。
開発にはいる前に、その三番目が開発ではなくマニュアル化された業務をRPAのロジックで「定義をする」ことにある。
何故かというと、RPAはあくまで「ロボット」であり、人間との思考ロジックが全く違うことになる。
RPA開発がうまく行くように、RPAのロジックに合わせて業務を「定義」しなければならない。
今回のコラムではこの「業務定義」プロセスの事例をいくつかを紹介しながら、
その注意点を説明していく。
RPAといったら、エクセルファイルの操作などが絶対出てくる話だ。
人間の操作を真似し、素早く大量なデータ処理ができるというイメージが多くの人がしている。
もちろん、これは間違いない。
ただし、RPAがエクセルを操作するときは人間と比べて、少し異なるところがある。
以下の例を見てみよう。
上記の表は某ECサイト運営会社A社のRPA導入プロジェクトで出た一例だ。
本業務の内容としては、毎日スタッフが社内システムに「Code」を発行申請し、
その後発行されたCodeを上記表1フォーマットのエクセルファイルに貼り付ける。
このエクセルファイルをもとに、別の業務が色々と行われるが、ここでは議論しない。
ここで説明したいのはRPAがどのようなロジックでこのファイルを読み取るかというところだ。
まず、この業務にかんして、人間が行う場合はまずエクセルファイルを開き、
「Code」列を見て、最初に空欄になっている行に基づいて作業を行う。
表1から言うと、黄色で塗りつぶされているセルになる。
そして、この行を見つたら、
「Start date」、「End date」と「配信日付」（実務上、配信日付はRPA稼働日付とは異なる）
の情報を使ってシステムにログインし、「Code」を申し込み。
その後、発行されたCodeをコピーに、黄色セルに貼り付けて完了する。
しかし、RPAが行う場合プロセスは人間と異なる。
RPA開発ソフトによって少し違うかもしれないが、
だいたいのRPAはまず処理しやすくするためにこのエクセルファイルを丸々メモリーに読み取る。
その後、「Code」列が空欄になっているかを一行一行見ていく。
もちろん、何行目から始めるかについてRPAが全く分からないので、一行目からみていく。
表1から見ると、6行目で空欄が出るので、
たいしたことないに見えるかもしれないが、そうではない。
表1は元ファイルの一部を切り取ったことに過ぎなく、実際のエクセルファイルは数万行以上ある。
この場合少し厄介なことになる。
なぜなら、毎回数万行以上のデータを一行一行処理した後に、
空欄行にたどり着くので、無駄な時間が発生する。
また、空欄ではなくても、
「○○につき、作業中止」という何らかの原因でその日業務は行わないということもある。
すると、RPAはまず空欄かどうかを判断し、
もし空欄ではなかったらさらにその内容は「作業中止」が含まれているかも判断しなければならない。
しかも、全ての行に対して同じ処理をすることになる。
RPAは24時間働くとはいえ、この24時間が上限になる。
普通RPA導入するには、高額なRPAソフトのライセンスを購入しなければならない。
大事なライセンスをこの無駄な作業に使うと少々もったいないかもしれないので、
より有効利用するために、方法を変えないといけない。
では、このプロセスにおいて、人間とRPAは果たしてどこか違うのか？
RPAは機械なので、「最初に空欄になっている行」という条件だけでは、普通上記のプロセスになる。
人間の場合、作業員が毎日やっていると、
「何となくこの辺りじゃないか」という情報は頭に残っているため、探すときは極めて速い。
要するに「目標行の情報」の有り無しに違いがある。
そうすると、RPAにも似たような情報を与えると空欄セルにたどり着く時間が短縮できる。
A社は二つの方法を検討していた。
まず、表2のように「RPA稼働日」という列を先に作って、RPAに読み込ませる。
RPA稼働日は「本日の日付」と結びつけ、RPAがこのエクセルファイルを読み取ると、
日付を見て目標行を探せばよい。
ただし、これでも、理論上RPAが「RPA稼働日」列のセルを一つ一つ見て、対象の日付を特定する。
根本的にいうとさほど変わらないので、二つ目の案が出てきた。
表3のように、最初に一行を追加し、「目標行」の情報をあらかじめ記入する。
RPAが稼働し始めたらまずエクセルファイルを読み込んで、
その後すぐ目標行の情報が記入されているセルのデータを込み込む。
表3からいうと「4」になる。
その後すぐ4行目の情報に基づいて作業を行う。
このセルは固定される（例えばB2など）ため、RPAがすぐ特定できる。
すると、たとえ表が何万行あっても一行一行を処理していく必要がない。
作業が毎日行うため、翌日RPAが稼働時「目標行」のデータがずれないように、
作業が終わってエクセルファイルを閉じる前に目標行データに「1」を加算する。
つまり、翌日開くと、このセルは「5」になる。これで処理時間を短縮することができる。
メールを送信受信関連の処理はエクセルと同じく、RPA化で良く検討される業務だ。
例えば同じくA社はメールの受信と分類業務をRPA化検討している。
内容としては、特定なメールアドレス宛に送信されてくるメールを件名や添付ファイルの種類に基づいて
分類をし、それぞれ特定なフォルダーにOutlookのmsgファイルのバックアップを作成する。
メールソフトは当然Outlookを使っている。
そして、これらのmsgファイルはまた別の業務に使われる。
今まで従業員一人が毎日この作業を行っていたが、この単純作業から解放するために、
色々と検討した結果、RPAが最適だと判断した。
RPA化するにはいくつかの問題が残っていた。
まず、A社が使われるRPAソフトはメールの「未読」と「既読」判断は出来なかった。
通常人間が作業を行う場合は毎日対象アドレスの未読メールを見て、
条件に満たしていれば、該当のフォルダーに保存するという流れだが、
「未読」が分からないRPAにとっては少々難しい。
RPAができるのはOutlookの「受信」フォルダーにあるすべてのメールを全部取り込み、
そして一通一通どの条件に満たすかをチェックする。
そうすると、毎回このフォルダーにある過去のメールも全部チェックし、作業が重複さてれしまう。
そこで解決策として、RPAが一通のメールをチェック終わったら、
このメールを別のフォルダーに移動するように設計する。
具体的にいうと、
Outlookの対象メールアカウントに「受信」フォルダー以外に「チェック済」フォルダーを作成する。
RPAがチェック終わったメールをこのフォルダーに移動するように設定する。
そして、毎日RPAが「受信」フォルダーがからになるまで動作をする。
結果は毎回RPAが稼働するとき「受信」フォルダーに未読のメールしか存在しないことになる。
また、細かいところを言うと、
たまにRPAが読み取れないメールや分類不能のメールもあったりするが、
これらも対応できるようにロジックをあらかじめ組めないといけない。
いわゆる「イレギュラー」の対応だが、ロジックも同じだ。
例えば、もう一つ「イレギュラー」フォルダーを作って、
読み取れなかったメールをこのフォルダーに格納し、
RPAが実行終わったら従業員がチェックしに行く方法もある。
今回が紹介したことは基礎的な話だが、実際業務定義段階で結構ある話だ。
これらの問題を事前にできる限り考慮した上でRPA開発をすれば、
開発時間の短縮とRPA実行効率向上の一石二鳥になる。
もちろん、今回紹介した二つの例はRPAソフトによってかなり変わるかもしれないが、
このような考え方があると読者のヒントになれれば幸いである。
2019.02.04
株式会社ディップ（本社：東京都港区、代表取締役社長：富田 英輝、以下ディップ）は日本初の人工知能専門メディア「AINOW」のサイト上にてプレスリリース記事の自動化をRPAソリューションを用いて可能にしました。
「AINOW」は三万件以上のAIに関する記事を配信しているキュレーションメディアで、様々な記事と共にプレスリリースも日々配信しています。
今回焦点が当たるのがこのプレスリリースの部分です。
プレスリリースとは自身のプロダクトをメディアを通して、多く知ってもらうための文章のことです。
報道機関に対して新情報や新商品を発表することで、多くの消費者の目に触れる機会が増え、興味を持ってもらえることが多くなります。
また、近年では紙媒体だけではなくWEBメディアにも焦点が当たって、自身のプロダクトを宣伝する機会も増えています。
近年、ディップではRPA導入を促進しており、以前RPA-BIZ内の記事でも掲載しましたSaaS型のRPAツール「Robotic Crowd」を導入、出資しています。
以前紹介した、「Robotic Crowd」に関する記事は以下からご覧ください。
RPA導入に前向きであるディップは、今回自身の運営するキュレーションメディアである「AINOW」でもRPAを導入しました。
従来のプレスリリースの掲載方法は、メールや専用フォームで受信した内容を編集者が自身の目で確認した後、記事化し、公開していました。
今回ディップは、受信した内容を確認し、記事化するまでの流れをRPAによって自動化することに成功しました。
これにより、編集部の人間が行うことは最終確認のみになり、従来30分かかっていた業務が5分で可能になりました。
さらに、社内業務の構造化にもつながっており、不透明だった業務の見える化にも繋がっています。
参考記事：日本初！RPAでプレスリリース記事を自動作成 記事作成時間の8割削減を実現
2019.02.01
経理業務を行っている方はルーティンワークにかける時間が多くて、企業にとって付加価値の高い業務を行うことがままならない方も多いと思います。
経理業務に充てる時間が減るということは、その削減できた時間で付加価値の高いコア業務を行うことが可能になります。
RPAはデータの入力や出力といった単純作業においては、圧倒的に人間より正確に、早く作業を行います。
経理の場合はデータのチェックや、入力、出力といった作業が多い傾向にあるので、その作業量が多ければ多いほど人間より早く処理を完了することができます。
経理におけるRPA導入目的は以下に分類することができます。
RPAを導入する企業の多くが重要視していることは、導入によって経営資源をコア業務に集中させることです。
コア業務を極めていくことで他社との競争に打ち勝つことに注力し、他社でもできるノンコア業務はRPAに任せ、その分で空いた人材等の経営資源をコア業務に投入することになります。
経理部門で考えた場合、具体的にはノンコア業務に関わっている経理の人材を経理部門のコア業務に振り向けるようにします。
経理部門において何がコア業務で、何がノンコア業務になるのでしょうか。
会社の規模やステージによって、位置づけは異なってくると思いますが、概ね次のように区分できます。
（コア業務）
→未来の数字に関する業務はコア業務としてノウハウを蓄積する
（ノンコア業務）
→過去の数字の整理に関する業務はノンコア業務としてRPAを積極的に取り入れる。
ここからは経理部門・経営企画部門におけるコア業務の一つである管理会計について記載します。
企業会計は、会計情報を主として誰のために作成し報告するのか、つまり何の目的で会計を利用するのかによって財務会計・税務会計・管理会計の３つのタイプに分類されます。
（財務会計）
財務会計とは、株主や銀行、債権者など外部の利害関係者に対して、会社の財務状態・経営成績を正しく報告することを目的とした会計です。
特に上場企業については、一般投資家が存在することもあり、会計基準などで厳しくルールが定められています。
賞与引当金、退職給付引当金、資産除去債務、税効果会計も適用しなければなりません。
（税務会計）
税務会計とは、税金計算を目的とした会計です。
税金を正しく計算するための会計であり、税金計算上、必要な処理は網羅されています。
一方、税金計算に関係しないものについては、会計処理がなされていないものも存在します。
税金計算上、賞与引当金、退職給付引当金などは費用にならないため、税務会計では計上しないケースも多く見られます。
（管理会計）
管理会計は、財務会計のような外部向けの会計ではなく、内部での業績管理、意思決定に使用することを目的とし、企業活動を円滑に進めるために必要となる会計のことです。
管理会計は社内向けの会計であるため、厳格なルールや制限はなく、会社ごとに独自のレポート形式を用いるケースが多いです。
「限界利益率はどうか」、「資金調達のタイミングはいつか」、「事業別、商品別の収益性がどうか」など、管理会計の情報は企業の経営者が経営方針を決める上でとても重要な判断材料となります。
また、組織内部の業績測定、業績評価や人事評価などにも役立てられるため、企業活動において非常に重要な意味をもつと言えます。
会計の種類をまとめると図1のようになります。
10%値下げしたら販売量はどうなるのか？
販売促進のため、販売価格を10%値下げしたとします。
販売量が変わらなければ利益は当然減少します。
それでは、販売量が何%増加すれば値下げ前の利益と同じになるでしょうか。
管理会計では、その答えが見えてきます。
売価等の前提は、図2のとおりです。
管理会計では、すべての費用を変動費（売上の増減に応じて、増減する費用）と固定費（売上の増減に関係なく一定金額の費用）に分けます。
変動費と固定費に分けることにより、販売量の必要増加割合が計算できるようになります。
財務会計・税務会計では、費用は、売上原価と販管費という区分で分けられるのみであるため販売量の必要増加割合ができません。
必要増加割合は以下の計算で求めることができます。
10%の値下げを行った場合、33%(500個)販売量を増加させる必要があります。
10%値下げを行ったからと言って販売量も10%増やせばいいということにはなりません。
同様に20%値下げした場合は、3,000個の販売が必要になりますので、販売量は2倍になります。
ここで重要なのは、販売促進（利益を増加）のための値下げが販売量に与えるインパクトがいかに大きいかということです。
このように管理会計は、経営意思決定をするために非常に重要な意味を持っています。
財務会計・税務会計の損益計算書だけでは判断がつきにくい、撤退すべき部門の経営判断にも管理会計は役に立ちます。
図3は部門A、部門B、部門Cをもつ会社の損益計算書です。
財務会計ベースの損益計算書のままだと、撤退すべき部門の判断がつかないため、図4のとおり損益計算書を部門別に整理します。
図4を見ると、部門Cの営業利益がマイナスであり、撤退すれば損失が減少するため、部門Cを撤退するという経営判断になりそうです。その判断は本当に正しいのでしょうか。
財務会計だけでは判断できないことが管理会計で判断できるようになります。
図5は、部門別損益計算書を、部門Cを撤退させ、管理会計の様式に組み替えたものになります。
図5のとおり、部門Cを撤退することにより、全社の営業利益が△15になってしまいます。
撤退には将来の見通し、外部環境、内部環境など複合的な事象を基に判断することになりますが、短期的な管理会計ベースでは、部門Cを撤退させない方が全社の利益は残ることになります。
なぜそのような結果になるかといいますと、各部門の利益合計が共通固定費（本社経費）を上回っている状態であるからです。
部門利益が共通固定費を回収するエンジンになっている状態です。
図6はその状態を表したものになります。
部門の業績評価では売上高に重点が置かれることが多いが、利益が残らないことには会社は存続できないため利益にも重点を置き予算策定や業績評価を行うことが望ましいと考えます。
財務会計における、営業利益には、部門で管理できない費用も含まれているため部門で管理できる費用とそれ以外を区分し、管理可能利益や部門利益を計算する必要があります。
それぞれの利益を区分した損益計算書が図7のようになります。
ここで重要なことは、部門の評価と部門長の評価は違うということです。
部門の評価とは組織上の評価です。
組織上の評価とは、その部門という一組織が会社という組織全体の経済性に、どれだけ貢献しているかを評価することです。
一方、部門長の評価とは、部門長の管理能力を評価することです。
管理可能利益が部門長の評価となることで、売上高のみならず、管理可能利益を最大化するため管理可能個別固定費についても、部門長自身が考えるきっかけになります。
コスト意識の向上にもつながります。
部門の評価は組織の経済性の評価ですので、評価対象は部門個別の利益であり、評価方法は他部門との相対評価が基本です。
それに対して部門長の評価は人の管理能力であり、評価対象はその人にとって管理可能な利益でなければなりません。
これがフェアな評価になります。
評価方法は予算達成率です。
