第567話：2017年、業務自動化の元年？！

2017年の振り返り

本年も１年間、「ワークフローサンプル」のご愛読、ありがとうございました。

ブログ8年目となる2017年も、一週も欠かすことなく、52本の記事を投稿することができました。これも読者の皆様からの「いいね」や「シェア」のおかげです。

早速ですが、本年の「アクセス数上位記事」を調べてみました。結果は以下の通りとなりました。

1. 第515話：契約書の承認はワークフローで！（改善編） (2016-12-26)
2. 第462話：稟議書を回す（基本業務パック） (2015-12-21)
3. 第471話：オレの申請に「決裁」は要らぬ！ （by 部長） (2016-02-22)
4. 第463話：物品購入依頼を回す（基本業務パック） (2015-12-28)
5. 第510話：もう経費精算フローの中で「事後承認」すればイイ (2016-11-21)

ぬぬぬ。。。寂しいことに「2017年の記事」がありません。 （←この一年間、ワレワレは、何をやっていたのでしょう？？）

2017年記事に絞ったランキング

ということで、（気を取り直すべく？）、2017年の発信記事に絞った「アクセス数上位記事」についても調べてみました。

1. 第531話：テレビ番組表の自動検索 (2017-04-17)
2. 第519話：業務プロセスの自動化とは？（その２） (2017-01-22)
3. 第520話：業務プロセスの自動化とは？（その３） (2017-01-30)
4. 第521話：業務プロセスの自動化とは？（その４） (2017-02-06)
5. 第539話：時刻が来れば自動的に「受け取った」ことになる工程 (2017-06-12)

むむむ。。。 やはり「自動」がキーワードですね。（当ブログのミッションは「具体的な業務サンプル」を提供することではありますが）、2017年の結果として「抽象度の高いテーマ」が人気になっています。

[サーバサイドで乱数を発生させるプロセス]

第566話：人事異動に伴うアカウント情報の変更を予約する

 

業務：ユーザの所属情報

「管理部」「営業部」「開発部」、、、

たとえば、ホームページの問い合わせをトリガーに発生する「見積作成依頼に対応する」というタスク。自動的に「営業部の誰か」に対してオファーされるが、当然ながら、「営業部に所属していないユーザ」は永久に引き受けることができない。

やはり、ワークフローシステムの運用においては、「組織」の所属メンバが最新状態にメンテナンスされていることが極めて重要だ。もし、こういった基本情報がきっちりメンテナンスされていなければ、プロセスオーナー達の日々の業務プロセス改善も徒労と化してしまうだろう。

※ もちろん、「申請のたびに "上司：田中" と入力させる」といった業務プロセスも定義できる。しかし、それでは効率が悪い。。。（と言うか、違反や不正が常態化してしまいそう。。。）

※組織ツリーのサンプル

課題：組織ツリーにない集団

メンバの「所属情報」については、API を使った追加予約や削除予約で自動化されている。（参照：第565話：自動化で実現するIT全般統制）。

しかし、「情報セキュリティ資格保有者」「研修中社員」「テニス同好会」、、、（ん？？）、といったユーザの集まりはどうしたものか？？？　これらを「組織」と呼ぶに、はばかられる。そもそも、組織階層のツリー構造において、どこに位置づけられるべきか分からない。。。たしかに「テニス同好会」はオフィシャルな会社業務を担当しないのでメンテナンスする義理もないのだが、、、「情報セキュリティ資格保有者」や「研修中社員」といったユーザ集団はプロセスオーナーによっては「引き受けルール」の設計に活用したいと思うかもしれない。。。

[アカウント発行およびML登録-予約更新]

第565話：自動化で実現するIT全般統制

業務：ユーザ管理

「社員さんの所属部署変更」が発生したら、情報システム部門の雑務が増える。（風が吹けば…的な？）

例えばイチローさんが『営業部』から『カスタマーサービス部』へ異動するという辞令ケース。。。 Google Group で言えば、『ichiro@example.com』というメールアドレスを『sales@example.com』からメンバ削除し、『cs@example.com』にメンバ追加する処理をしなければならない。

ただし、こういった場合「引き継ぎ」を考慮し、加入組織へのメンバ追加は4月1日に、脱退組織からのメンバ削除は4月30日にセットする、というオペレーションを取っている。

課題：所属情報変更の自動化

Google Group 設定については、『第544話：Google Group 連携で、ラクラクML管理(2)』の業務テンプレを使って、自動化できている！　「API 連携」でタイマー処理についても自動化されているため、ミスやヌケモレはほとんど発生しない。

しかし、、、他にも「グループ設定の変更」は沢山あるのだ。（ディレクトリ・サービスは万能ではない）

あれれ？　ワークフロー基盤の組織所属設定も自動変更したいのだが、、、どうやって？？

[アカウント発行およびML登録-IT全般統制]

第564話：受信ファックスを無制限クラウドへ

業務：FAXでの受注処理

FAX で注文を受け、受注の判断をする。

一昔前なら「人間がやって当然だったこと」も、クラウド時代の今日では「省力化・無人化の対象」だ。

実際、クラウド型FAXサービス（インターネットFAX）『eFax』を使いはじめたので、「紙」は存在しなくなった。そして、その受信ファイルもクラウド型ワークフロー『Questetra BPM Suite』に自動的に連携されるようになったので、「注文内容の確認」といったヒューマン処理もオンラインでキチンと記録されるようになった。（単純なメール連携）

もう「紙」を探すことは無い。すでに大きく業務改善されてはいる。しかし同時に、もっともっとカイゼンできそうな気がしている。

課題：FAXファイルの総覧

たとえば、こういった「クラウド化」「デジタル化」が進むことによって、業務監査への対応に意外と困っている。

つまり「注文書FAXファイルの存在」について、会計士や内部監査担当に確認してもらいづらくなった。もちろん、ワークフローシステムにログインしてもらい、モニタリング機能やデータ参照機能を使って見てもらえば良いのだが、、、ワークフローシステムには「彼らにとって不必要な機能」が多すぎるため操作に慣れてもらうに時間がかかる。（いろいろ説明がメンドクサイ）

そして彼らの口から「時代に逆行するような一言」が飛び出した、、、「注文書は紙に印刷して綴じておいてくださいよ」と。。。（ガーーーン）

なんとかして「沢山の注文書FAXファイル」を、総覧しやすい形／探しやすい形にできないものだろうか？？

[受注FAX処理フロー]

第563話：国税庁PDFで年末調整

業務：年末調整

年末の風物詩「年末調整」。

経理部は、1月から11月にかけて概算で徴収してきた『所得税』を、年末12月に精算するのだ。そのためには全社員について「扶養家族の数」や「保険料の支払い」といった情報が必要になる。

去年までは「社員側が開始させる申請ワークフロー」を使ってきた。

• 年末調整の「保険料控除」、ややこしい計算を自動化！ (2015-11-30)
• 年末調整書類の提出はクラウド型ワークフローで！ (2016-11-14)

もちろんこのフロー、、、経理側が黙っていて次々申請されるモノではない。11月中旬に「月末までに申請してくださいよーーー」という社内アナウンスを、２度・３度と実施する必要がある。１割くらいの人が「月末まで」を守らないので、12月に入ればスグに督促活動に入る。そうしないと12月中に精算を終わらせられない。（税理士さんにも迷惑がかかる）

もっとも、あの膨大な入力フォームも、昨年の申請を［再利用してプロセスを開始］すれば、年度情報を「+1」するだけで完成するので、（しかも自動計算機能もあるので）、ヤル気になれば一瞬で終わる作業なのだが。。。

うーむ、気分よく年を越したい。。。（本期限の「1月精算」はミス対応のための予備日）

※ ちなみに台紙PDFは、毎年の変更手間を減らす細工がなされている （Questetraアドオン）

• 平成X年分 給与所得者の扶養控除等（異動）申請書（76フォーム）
• 平成X年分 給与所得者の保険料控除申請書 兼 給与所得者の配偶者特別控除申請書 （157フォーム）

課題：未提出者に対する督促

しかし、、、やはり「社員が開始させるフロー」は「誰が未提出なのか」が分かりにくい。

ただでさえタイトなスケジュールだ。経理部にとっては「未提出者の一覧」こそが重要なのに。。。他の申請と違って、「提出者の一覧」は、どうでもイイ。（優秀な社員の一覧？）

一度、全社員の［マイタスク］に、『年末調整書類の提出』を強制的に流し込むワークフローについても検討してみよう！！　そのやり方であれば、「申請が完了していない社員」を簡単に捕捉できるはずだ。

※ どうやら近い将来、会社での年末調整は廃止されるようだし、（日経新聞 2017-10-16：「政府税調、年末調整の手続きを電子化する方針」）、「プロセス改革」の練習にちょうど良い！？！　ついでに「再提出/再作成が必要なフロー」も整備したいな。。。

[年末調整書類の提出フロー]

第562話：経費精算クラウドを使わない理由(4)

業務：経費の申請と精算

クラウド型ワークフローで「経費申請フロー」のシステム化を実現した！（第559話参照）
多角的な「グルーピング」（クラスタリング分析）の仕組みも導入した！（第560話参照）
経費サマリーが Spreadsheet にリアルタイム追記される仕組みも導入した！（第561話参照）

今では、部長や社長は、暇さえあれば「最新の経費リスト」を眺めているらしい。スマホでも見やすい Google Sheets （Google スプレッドシート）は、管理職者たちを「24時間営業化」させてしまったのかも知れない？？

課題：意外と気づかない日付ミス

しかし「解決すべき課題」は、次々と現れる。。。

経費申請に慣れはじめた３か月目くらいから「入力ミス」が目立つようになってきた。過去データの再利用で申請するケースが多くなってきたからだろうか、特に「日付のミス」が目立つ。

課長が確認し、部長が確認し、経理が確認したハズなのに、、、ナンデ日付がズレているんだ？？（by 社長）

たしかに『立て替えた日』は非常に重要なデータ項目だ。月次試算表の集計月を決定するデータにもなる。とはいえ課長や部長にしてみれば、他にも沢山のチェック項目があるのだ。。。もし「2017-11-20」が「2016-11-20」になっていても、その間違いに気づかず「承認」してしまう。

一方で社長が眺め見る「経費リスト」はダイジェスト・サマリーだ。「６項目」しかない。だから、日付がズレていたらかなり目立つ。。。（困った！）

• A. 立て替えた日
• B. 計上月(YYYY-MM)
• C. 勘定費目分類
• D. 精算金額
• E. 立替人所属組織
• F. 稟議書ID

[経費精算フロー-入力チェック]

第561話：経費精算クラウドを使わない理由(3)

業務：経費の申請と精算

クラウド型ワークフローで「経費申請フロー」のシステム化を実現した！（第559話参照）

しかも「多角的なグルーピング」（クラスタリング分析）を実現するための仕組みも導入した！（第560話参照）

経理チームは、「48時間の滞留で自動的に部長決裁されたものとみなす」というルールが適用された経費申請（案件ステータス115～155）に対して、目を光らせているらしい。

課題：監査法人とのデータ共有

しかし、、、情報量は「多ければ多いほど良い」というモノではない。

ワークフローには、『立替金額』や『計上月』といった基本情報だけでなく『立替申請を行ったヒト・時刻』や『支払を証明する書類』あるいは『プロジェクトの名称』や『取引先企業名』といった関連情報まで、様々なデータが含まれている。たしかに社内の人間であれば、様々なデータから「情報」を抽出することは重要なシゴトと言える。

ただ、例えば、会計監査人にしてみれば「審査過程」や「所要時間」などは無用なデータだ。例えば、社長や会長といった経営トップにしてみれば「誰が多くの経費を使ったか」まで見る時間がない。彼らにとっては「多角的な集計フィルタリング」より、必要なデータが簡潔に一覧されている方が重要なのだ。

う～む、ならば報告用の Spreadsheet を「手作り」するか？？？（悪夢）

[経費精算フロー-Spreadsheet出力]

第560話：経費精算クラウドを使わない理由(2)

業務：経費の申請と精算

クラウド型ワークフローで「経費申請フロー」のシステム化を実現した！（第559話参照）

もともとワークフローシステムには、他にも様々な「業務フロー」が定義されている。なので、立替金の申請だからといって「経費申請のためのシステム」にログインし直す必要はない。

しかも「課長承認」や「部長承認」といった工程での滞留状況が、業務フロー図上に可視化される。申請した社員も、決裁した上司も、取締役達も、、、「どの工程にどんな申請があるのか」を折々に確認するようになった！　そして他人のアウトプットについて助言やコメントが付けられるケースも増えてきた！　やはり「どこで滞留しているのか？」が分かる事って、ホント大事だ！

課題：リアルタイム集計

しかし、、、「決裁一覧や決裁総額が的確に把握されているか？」については、やや疑問だったりする。。。

つまり、申請の中には「経費申請を取り止める」に至ったものも多数混ざっている。全ての申請を単純集計しただけでは「正確な経費の総額」にならないからだ。。。

う～む、精算業務に特化された『経費精算クラウド』を使った方がイイのだろうか？？

[経費精算フロー-案件ステータス]

第559話：経費精算クラウドを使わない理由(1)

業務：経費の申請と精算

いわゆる『経費精算クラウド』は、システム導入がラクだ。

経費（立替金）の精算業務に特化したシステムなので、申請画面も、管理画面も、最初から経費精算業務向けになっている。初期設定についてアレコレ深く悩む必要はない。


一方『ワークフロー・クラウド』でも「経費申請」のシステム化は可能だ。

ただ、ワークフローシステムは汎用システムなので、申請項目を考えたり、上司承認・会計記帳・経理振込といった業務手順を考えたりと、意外と手間だったりする。。。


もっとも、、、実際に申請を行う社員の視点で言えば、『経費精算クラウド』でも『ワークフロー・クラウド』でも同じだ。「特化システム vs 汎用システム、どちらが良いか？」については結局のところ、単に「組織の考え方次第」ということになるのだろうか？？　いやぁ、20世紀末の「ワープロ専用機 vs パソコン」という論争を思い出す。。。（シャープの『書院シリーズ』が好きだった）

※ 当時は、ワープロ機能をROM化して組み込んであるワープロ専用機と、汎用的なパーソナルコンピュータで動作するワープロソフトが、よく比較された。

課題：提出遅れ

しかし問題は、、、経理部から「経費申請が出てない！」と怒られてしまうことだ。

たとえば展示会出展準備を頑張る担当者は、「稟議フロー」（事前申請）で決裁を取るところまでは頑張るのだが、展示会が終了し支出内容について「経費申請」するのは苦手なのだ。

担当者の［マイタスク］画面に、すでに「〇〇展示会への出展」という申請タスクが並んでいればなぁ。。。

経費申請の画面で、すでに「稟議書のID」や「稟議書の決裁概要」が自動的に入力されていればなぁ。。。

[経費精算フロー]

第558話：クレーマーを減らす「受付番号」の採番工夫

業務：「資料請求」の受付

1. 資料請求の受付件数
2. 見積の提出件数
3. 契約件数

古典的なマーケティング手法ではあるが「1.資料請求の受付件数」は「3.契約件数」に直結する指標だ。その相関は極めて強い。したがって多くの会社で KPI 設定されている。車会社、保険会社、引越会社、設計事務所、、、規模の大小や業種業態を問わないのだろう。

今どき、スムーズなワークフローを実現すべく、顧客からの申込をクラウド型ワークフローの「フォーム開始イベント」で受け付ける会社も少なくない。ワークフローを使うことで、「宛名印刷」や「配送」といった下流工程もヌケモレなく実行される。

そして「受付完了メール」の自動送信（メール送信イベントの配置）も「王道」と言ってイイ。顧客は「リクエストを受け付けてもらえた」と認知することができる。また、本文には『受付番号』を記述する。そうすれば『受付番号』をたよりに電話やチャットで疑問点を問い合わせることができる。

課題：受付番号だけの本人確認

『受付番号』は「プロセス連番」（#{processInstanceSequenceNumber}）が都合良い。何と言っても KPI 管理がラクだ。

しかし同時に「類推されやすい番号」でもある。たとえば電話やチャットで「申込のキャンセル」が来た際、「本人確認」をせざるをえない状況になりうる。つまり、誠実そうな声で「受付番号123番をキャンセルして下さい」と言われればそのまま受け付けても良いのだろうが、悪意のありそうな方を相手にした際に「エントリの氏名」や「メールアドレス」を聞いて本人確認することになる。これは顧客差別とも言われかねない。

かと言って、「類推されにくい番号」として暗号文のような長い番号にするとイロイロ不便だ。「KPI 管理」がメンドウになるだけではない。電話口で伝えてもらいにくいし、一意であることを担保するのも意外とムツカシイ。うーむ。。。

[資料請求への対応プロセス]

第557話：様々なAPIと通信する全自動請求フロー

業務：大量の月末請求

月末のカード請求業務が、ヌケモレなく実施されるようになった！

それぞれのお客様への「請求金額」について、、、いつ誰が入力し、いつ誰が承認したのか、全てがリアルタイムに捕捉できるようになった。しかも、クレジット会社 API （Stripe API）にアクセスしてくれる「自動工程」のおかげで、ワークフローシステムからダイレクトにカード課金される。つまり、経理システムへの「二重入力」といった二度手間もなくなった。

• 第554話：Web受付、だけどカード情報は非保持(1)
• 第555話：Web受付、だけどカード情報は非保持(2)
• 第556話：月末請求フローに Stripe API

課題：人間依存の低減

しかし、、、この業務プロセス（第556話）は、いまだ「人間のデータ入力」に依存している。つまり、肝心の「課金額」の入力については人間（担当営業）が担当している。

たしかに、「お客様情報」は自動でセットされているし、「カード請求コード」（Stripe CustomerID）だって予めセットされている。更には「請求作業の一覧」もヌケモレなく引き受け待ちリストに表示されているので、複数人で協調して請求作業を行うこともカンタンになっている。つまり「入力の省力化」については、かなり高いレベルで実現できているとは思うのだが。。。

もっとも「課金額」（請求額）の情報は、ワークフローシステムから見て「外部システム」にあたる「売上管理システム」にある。なんとかして売上集計を自動取得させることはできないものか？　（「APIエコノミー」が叫ばれる今日、業務プロセス改善の行きつく先は「無人化」だと思う。。。）

[クレジットカード課金プロセス-再帰呼出＆全自動]

第556話：月末請求フローに Stripe API

業務：毎月のカード課金

月末の請求業務が、大幅に省力化された！

新しいワークフローアプリでは、担当営業が登録した「今月の請求金額」が部長承認されれば、そのまま自動的に「クレジットカード課金」が行われる。経理サイドが「請求書の印刷／押印／郵送」といった作業を行う必要はナイ。当然ながら「銀行入金確認」といった作業もイラナイ。Stripe 万歳！　API エコノミー万歳！　Questetra 万歳！

• 第554話：Web受付、だけどカード情報は非保持(1)
• 第555話：Web受付、だけどカード情報は非保持(2)

ちなみに、お客様にも好評だ。

「請求書の承認」や「振込の手続」といった実作業がなくなった事（！）もさることながら、費用明細が「通知メール」で確認できるのがイイ（！！）、らしい。（ペーパレス）

（「銀行API」も早くオープン化されればイイのに…）

課題：誰に請求してないか？

ただ、、、現状では「全てのお客様に請求できたか？」が分かりにくい。

たしかに『1r.課金額の入力』からワークフローを手動開始（再利用開始）するだけだ。しかし、その開始を「手動」に依存すると、たとえば「前月請求したお客様全員にヌケモレなく請求する」が実現しづらいのだ。

請求件数が増えれば、いつの日か「請求し忘れ」が発生するだろう。。。（ハテサテ）

[クレジットカード課金プロセス-再帰呼び出し]

第555話：Web受付、だけどカード情報は非保持(2)

業務：登録カードへの課金

「クレジットカード登録」の仕組みはできた！ （前回記事参照）

『カード番号』や『CVC』といったカード情報は Stripe 社（決済代行会社）に預けられ、ワークフロー側にはその「預かり番号」としての『Stripe Token』(tok_{24文字})だけが流れる仕組みだ。つまり、日本政府が「2018年3月までにクレジットカード情報の非保持化を！」と言っている要件についても満たすことができたと言える。（非保持化＝カード情報保護のための第一の対策）

コレで「自社システムからカード情報が漏洩するリスク」はゼロになったと言ってもイイ！　安心して Web 登録してもらえる！！

※ Stripe Token は一度の処理にしか使えない仕様（single-use token）となっており、この例では『Stripe Token』から『Stripe CustomerID』(cus_{14文字})への自動変換も同時に行われています。（自動工程「Token to Cus_ID」）

課題：課金オペレーションにおける手作業の排除

しかし、良く考えてみれば、、、実現したのは「カード情報の保護」だけだ。

たとえば『課金金額』を間違えたり、たとえば『課金相手』を間違えたり、、、そんな「課金オペレーション」のミスリスクについては、ゼロになっていない。たとえば「Ｘさんのメールアドレス」に「Ｙさんの名前宛」で課金予告を送ってしまったとか、、、、考えるだけで寒すぎる。「課金業務フロー」における

• お客様の名前
• お客様のメールアドレス
• Token or CustomerID

あたりのデータは、自動的にあらかじめ入力されているようにしたい。そうなっているだけでミス率はゼロに近づくハズだ。下流工程でチェックを担当する「頼りない上司」の負担も、少しは軽減されるだろう。

[クレジットカード課金プロセス]

第554話：Web受付、だけどカード情報は非保持(1)

業務：決済カード登録の受付

「クレジットカード決済」を推進したい…。

サービス利用実績にあわせて自動的に「カード課金」できれば、非常にスムーズな決済が可能となる。もし「明細発行」も電子化できれば、売上回収コストは大幅に低減できるだろう。

電気会社・ガス会社・ケータイ会社のように「カード課金できる体制」を整えたい。

課題：カード情報の漏洩リスク

しかし、セキュリティ要件が厳しくなった今日、「クレジットカード番号を保有すること」は大きなリスクらしい。

ウチは、電力会社でもなければ、Google Facebook といった大会社でもない。つまり「PCI DSS」が言っているような要件は維持できそうにない。カード会社（アクワイアラー）も言っているが「持たないこと（非保持）が大切」なのだろう。

よし、、、日本政府が「2018年3月までに非保持化を目指す」と言う書類にあるように、PAN PIN CVC といったカード情報等は「決済代行業者」に預けようと思う・・・。（どうやって？？）

• PAN：Primary Account Number （カード番号）
• PIN：Personal Identification Number （暗証番号）
• CVC: Card Verification Code/Value （3桁数字。正確にはCVC2。CIDとも）

※参考： クレジット・カード業界データ・セキュリティ標準（PCI DSS Ver.3.2 2016-04）
※参考：EU の法改正（決済サービス指令 2015年）、日本の法改正（改正割賦販売法 2016年）

[クレジットカード情報の受付プロセス]

第553話：脆弱性緊急メールに組織的な対応

業務：脆弱性対応プロセス

「弱点のないソフトウェアはない」、、、らしい（涙）

つまり、無数のソフトウェアが組み込まれているコンピュータや通信機器は「弱点だらけ」なワケだ。それにもかかわらず、会社には沢山のコンピュータや通信機器がある。社員が使うパソコンもあれば、会社ホームページのためのサーバコンピュータもある。売上や給与を管理する業務システムだってある。。。


情シス部による「脆弱性（ぜいじゃくせい）対応」とは、カンタンに言えば「ソフトウェアの補修作業」だ。

具体的に言えば、情シス部は日頃から「IT情報サイト」や「Google Alert メール」で脆弱性情報を収集し、それが会社のコンピュータで使われているソフトウェアに関する情報であれば、「パッチの適用」や「バージョンアップ」といった作業を行うのだ。最近は「自動パッチ」や「自動更新」が行われるソフトも多くなっているとは言え、それでも「手動対応しなければならない事案」は少なくない。

なお、年に１・２度、日ごろの補修作業がキチンと行われているかのチェックをかね、専門業者によるセキュリティテスト（「脆弱性検査」という）が行われる。

課題：属人的な対応

ただ、、、今日では、凄まじい数の「攻撃方法」が毎日毎日発見されている。

古いソフトウェアに関する「攻撃方法」も毎日のように報告される。日々の補修によって「弱点」は克服されていっているハズなのだが、攻撃アイデアや攻撃力も日々向上しているのだろう。永遠に無くなりそうにない。たとえば CVE 公表される「脆弱性」は年間１万件以上にものぼる。（CVE：Common Vulnerabilities and Exposures ／ 脆弱性情報データベース）

もはや、情シス部が全てに目を通せる量ではない。ベテラン社員がその「嗅覚？」と「属人的な情報ネットワーク？」によって機転を利かせて対応しているのが現実だ。

うーむ、、、もう少し組織的に対処できないモノだろうか？

もっと言えば、「緊急を要する脆弱性」について誰がどのような判断をしたのか・しているのか、についてキチンと記録・共有したいものだ。たとえば「ShellShock」や「Heartbleed」といった世間を騒がせた脆弱性に、いつ誰がどのような対応をしたのか、振り返りたいと思うのだが。。。 (OpenSSL, GNU bash)

「ゼイジャクセイ、対策しろと、言われても…」（情シス川柳）

[脆弱性対応プロセス]

第552話：働き方改革は「アイデア募集」が大事

業務：カイゼンを社内募集

日本政府は本気で『働き方改革』をさせたいようだ。

たしかにウチの社内にも「誰も見ない書類の作成」や「非効率なヤリトリ」がある。「◇◇業務に〇〇クラウドの導入」とか「IoT活用」とか、、、具体的な「改善アイデア」を、もっと積極的に吸い上げる方法を考えたい。たとえば「中途社員」や「派遣社員さん」が給湯室や飲み会の席でグチってるだけ…なんて、ほんとモッタイナイ。

とは言え、、、社長が「業務プロセスを改善して生産性を高めよう！」と朝礼で叫んだくらいでは、具体的な「改善提案」は上がってこないだろうな。。。


そうだ。まずは、いわゆる「目安箱」のイメージで、『内部監査室』に「アイデア投稿」を受け付けてもらおう。

そして良いアイデアについて「現場ヒアリング工程」や「社長報告工程」に進める、、、そんなワークフローを運用してもらうのだ。（業務改善アイデア受付プロセス）

課題：社内なら誰でも投稿できるフォーム

しかし、ワークフロー基盤への「ログインID」は、全員が持っている訳ではない。

もしアイデア投稿に「ログインID」が必須なら、派遣社員さんやアルバイトさんが投稿できなくなる。（現場の非効率は、きっとアルバイトさんや派遣社員さんに押し付けられてるんだろうに。。。）


ん？、よく考えれば、ある程度の「匿名性」も担保したい。

たとえば「部長の不正リスクを下げる改善アイデア」といった大胆なアイデア投稿も推奨したいものだ。

う～む、「インターネットに完全オープンなWebフォーム」でアンケート募集する、というのも一手なのだろうが、やはりチョット気持ち悪い。。。（URLがサラされたり。。。ゼンゼン関係ない人が提案してきたり。。。）

[業務改善アイデア受付プロセス]

第551話：週報スプレッドシートへのコメント

業務：週次売上報告へのフィードバック

「一週間分の売上」が Google Sheets に書き込まれるようになった。（参照：第550話）

全店長が一つのファイル（例：『売上報告2017-08-27to2017-09-02』）を同時編集するので、

• 各店長は他店を意識するようになった
• 店長同士で誤入力を指摘し合うようになった
• 本部での集計作業は（Spreadsheet任せなので）不要になった
• 役員達もファイルを閲覧し、各店舗の動向を能動的に確認するようになった

などのカイゼンが図られている。つまり、各店長のコメントを含む「売上データ」が、社内でイキイキと活用されるようになった。（これまでは「売上データ」が死んでいた？）

課題：管理職側のコメントがない

しかし、本部マネージャから全店長に「フィードバック」があっても良いのではないだろうか？

セッカク全店長が頑張って報告してくれているのに、本部のマネージャ達から何も感想がないのは寂しい。「目標達成を頼む」の一言でもイイ。マネージャの笑顔を待ちわびる店長達に伝えてやってくれ。。。

そうすれば「実績データについて本部のマネージャ達がどう考えているか／どんな助言をしているのか」を役員達が知ることもできる。

[週次売上報告プロセス-フィードバック]

第550話：スプレッドシート記入という業務の自動化

業務：週次売上報告

各店長には「一週間分の売上」を週次報告してもらっている。

確かに、メールやワークフローを使い、

1. 一人一人の『店長』が報告し、
2. 本部の『マネージャ』が確認する

というシンプルな「売上報告プロセス」を回すのも悪くない。しかし各店長は『本部マネージャの顔色』だけを見てシゴトしているような気がする。


たとえば、もっと「他店の動向データに触れる機会」を作っても良いのではなかろうか？

もし『Google Spreadsheets』であれば、全店長が同じドキュメントを編集できる（※50人まで）ワケだし…。　副産物的な話として、『本部マネージャ』の「集計する」という工程が省力化されるハズだ。「入力ミス」についても、他店とデータ比較されることで店長自身が気づくかもしれない。あるいは店長同士で「入力ミス」を指摘し合うかもしれない！　（更には店舗間のコミュニケーションも活発になり、生産性向上に…悶々）

課題：新しい SpreadSheet の準備がメンドウ

しかし、そうなると誰かが「報告用の Spreadsheets」を毎週準備する必要がある。

本部の『マネージャ』達には無理だ…。彼らは他人には厳しく、自分にはアマイ。たとえば「経費精算」など、今まで締切日が守られたタメシがない…。う～む「毎週キッチリと、新しいファイルを準備して全店長にアナウンスする」という第一工程がネックだなぁ。

[週次売上報告プロセス]

第549話：情報解禁こそ自動的に！

人事情報の発表方法

「人事異動の情報（配置変更や地位変更）を社内に公表する」という業務はフクザツです。

昇格・降格・採用・退職・休職・部署異動・関係会社出向…と、さまざまなパターンがあり、また個別の事情もそれぞれに異なります。

人事担当者の気持ちとしては、たとえば「信任の厚いベテラン社員が晴れて定年退職される」というケースなら何か月も前から周知しておきたくなるかも知れません。しかし一方で「競合他社に転職する」というケースなら秘密にしておきたいと思うかも知れません。また「家族介護のために休職する」といったケースでも、同僚や関係者に対して（守秘義務違反に配慮し）積極的に事前連絡しようとする人もいれば、黙っていたいと考える人もいるでしょう。

基本的には『既定の解禁ルール』にのっとって、粛々と「人事部内秘の情報」を「社内公知の情報」に切り替えるべきなのでしょう。（人事通達）

業務上の課題

公表方法として「社内掲示」という手法がとられている会社は少なくありません。

しかし、紙に印刷して「掲示板」や「壁」に張り出すという手法では、外出が多い人、長期休暇中の人、あるいはリモートワーカーにとっては見る機会が非常に少ないものになってしまいます。他方、人事部門としても「決められたタイミングで掲示作業を行う」や「決められたタイミングで掲示を終了させる」といった業務は、意外と大きな負担となります。

また「朝礼での口頭発表」という手法がとられている会社もあります。

しかし、これもまた長期休暇中の人やリモートワーカーは、朝礼出席者と同じだけの情報量を得ることは難しいと言わざるを得ません。さらに、口頭であるが故に「異動の日付」や「異動部署」などが正確に伝わらないリスクもあります。

[人事異動情報の公表]

第548話：月曜朝の Analytics API リクエスト(3)

アナリティクスいわく「○×工務店さんが困ってマス!?」

前々回記事と前回記事では、「先週のWebアクセス動向」が社内通知される（ほぼ無人の）ワークフローを紹介しました。

この業務プロセスが運用されれば、社員は毎週月曜日の朝、「Google Analytics Reporting API」を通じて得られた最新情報について、メールで確認できるようになります。その結果、日々の「サポート業務」や「セールス業務」は、より効率良いものになるでしょう。

ただ、もう少し欲を言えば、「Analytics に無い情報」も併記しておいてもらいたいものです。つまり、

• 先週火曜日、プレスリリースを配信した
• 先週木曜日、ユーザ向けセミナーを実施した（○×工務店さんも居た！）

もしこういった Analytics に無い情報も併記されていれば、「流入の多いリンク元」や「特定の顧客が調べているページ」といった動向情報について、もっと深い理解・洞察が可能となるかも知れません。

カレンダー情報も API 取得

以下の業務プロセス定義は、社内カレンダー『広報予定およおび出展予定』（Google Calendar）に書き込まれているイベント（先週分）が、通知メールの文頭に付加される仕組みです。

これにより、通知メールを受ける社員達は、「Webアクセスに影響を及ぼしたかもしれない関連情報」についても、同時に確認することが可能となります。

[自社サイト運用状況報告プロセス３]

第547話：月曜朝の Analytics API リクエスト(2)

人気ページのランキング

前回記事では、『Google Analytics Reporting API』との自動通信によって「週次レポート」が自動的に生成される方法を紹介しました。

ポイントは、

• ディメンジョン： ga:hostname, ga:pagePath, ga:pageTitle
• メトリックス(指標)： ga:pageviews, ga:sessions

というルールで集計データを自動取得する自動工程（サービス工程Addon）です。

この工程では「沢山アクセスを得たWebページのリスト」が複数行テキストとしてまとめられます。もし「フィルタ」に『ga:pagePath=~/blog/』の様な設定をすれば「blog フォルダ以下のWebページ」を対象としたランキングも自動的に取得することが可能です。

これらの文章が挿入された通知メールは、マーケティング・チームにとって非常に有用な情報となるでしょう。

他にも数万パターンの集計方法

しかし Google Analytics のデータは、もっと他の角度からも集計したい所です。

前回例では、上述の「3つのディメンジョン」と「2つのメトリックス」でランキング集計されましたが、Google Analytics には他にも約260のディメンジョンと約230のメトリックスが存在しています。つまり、組み合わせを変えることによって、多種多様な集計が可能となります。

たとえば、サイトコンテンツの視点（『行動(BEHAVIOR)』）だけでなく、『ユーザー(AUDIENCE)』や『集客(ACQUISITION)』の視点で集計すれば、「どんな人がアクセスしているのか？」や「どんなサイトから誘導されてきたのか？」といった情報も抽出できるハズです。

参考： ディメンジョン名とメトリックス名

[自社サイト運用状況報告プロセス２]

第546話：月曜朝の Analytics API リクエスト(1)

分析ツールなのか、集計ツールなのか

Web 業界に関わる人であれば、誰でも『Google Analytics』の存在を知っています。

改めて説明するまでもありませんが、『Google Analytics』（グーグル・アナリティクス）とは、自社サイトのアクセス数や訪問者数などが分かるサービスで、「人気ページ」や「不人気ページ」を確認したり、「ネット広告の投資効果」を確認したりと、「その道の人」には無くてはならないツールとなっています。

しかし一方で、多くの人にとっては「多機能すぎるツール」とも言えます。

見たい情報を表示するための操作は、多機能であるが故に複雑な手順を踏むことになります。たとえば「社内週報」を作るために毎週『Google Analytics』にログインしているような方でも、ごく一部の機能しか使わないのが実情です。そこで、毎回の作業を効率化すべく『カスタムレポート』（ダッシュボード）や『カスタムアラート』（メール通知）を使っている人も少なくありません。

今週も集計値に異常なし！

以下の業務プロセス定義は、週次で行われる「自社サイト運用状況報告プロセス」です。

毎週月曜日の朝には、「Google Analytics の集計データがプリセットされた報告文草稿」が用意されます。したがって、マーケティング担当者は一言コメントを入力するだけで全社への報告を完了させることが可能です。特段の変化が発生していない限り『Google Analytics』にログインする必要がありません。

[自社サイト運用状況報告プロセス]

第545話：Google Group 連携で、ラクラクML管理(3)

Google Group 登録者のメンテナンス

前回記事および前々回記事では、『Google Group』のメンバー追加やメンバー削除が自動的に実行される業務プロセス定義を紹介しました。

Google Group を「社内の情報共有ツール」として活用している会社であれば、この自動追加や自動削除といった機能は、「適時更新を保証する仕組み」として非常に有効と言えるでしょう。

求められる信頼性要件の高さ

しかし、この様な仕組みを導入してもなお、「正しいメンバーを維持すること」は容易ではありません。

たとえば、急ぎの依頼を受けて「間違った Group にメンバー追加」（システム管理画面）してしまうケースもあるでしょう。あるいは、ユーザ自身が「退会処理」（ユーザ設定画面や unsubscribe メール）をしてしまうケースもあるかもしれません。その様なケースは、「届くべきでないヒトに情報が届いてしまう状態」あるいは「届くべきヒトに情報が届かないという状態」になってしまいます。

「えっ？　そんな通達、あったっけ？？」

何か月もメーリングリストの情報を受け取らずに仕事をしていた、、、なんかヘンだと思った、、、、といった悲劇は、（非常に恐ろしい事ではありますが）、いつか必ず発生してしまうものです。

[MLメンバー確認]

第544話：Google Group 連携で、ラクラクML管理(2)

※この記事には「改善編」があります

メーリングリストの管理

前回記事では、ワークフローの流れの中で、「メルマガ購読希望者」（のメールアドレス）が自動的に『Google Group』に追加される業務プロセス定義を紹介しました。（資料請求に対応する業務）

これは、１つのメールアドレスが「１つのメーリングリスト」に自動追加される仕組みです。

しかし、社内で運用されているメーリングリストを見渡せば、（いわゆる『チャットツール』の普及によって減少傾向にあるとは言うものの…）、「方針の通達」「部署内限定にしたい情報の共有」「システムアラートの受信」など、様々な業務において、様々な社内メーリングリストが日常活用されていることでしょう。

メーリングリスト管理の観点においては、「複数のメーリングリスト」に一括追加したいケースの方が、むしろ多いのかも知れません。

複数の Google Group に一括登録

以下の業務プロセス定義は「アカウント申請フロー」です。

社内からの『アカウント申請』があれば、「アカウント新規発行」や「LDAPの設定変更」など、情報システム部は必要なシステム設定を行います。

特筆すべきは「複数のメーリングリスト」への追加削除工程が自動化されている点です。（工程の無人化）

すなわち、案件が［Groupメンバ追加］や［Groupメンバ削除］の工程に到達すれば、ワークフローシステムから追加・削除のリクエスト（OAuth2）が送信されます。つまり、「メーリングリストへの追加削除」という作業について情報システム部の担当者は『メンバ追加されるGoogleGroup』（Checkbox）や『メンバ削除されるGoogleGroup』（Checkbox）が正しく選択されていることを確認するだけで良く、『G Suite』の管理画面にアクセスして Group 設定を一つ一つ編集する必要はありません。（Admin SDK Directory API v1）

[アカウント発行およびML登録]

第543話：Google Group 連携で、ラクラクML管理(1)

メールでの情報共有

メーリングリストは便利です。

組織内の「情報共有」に使ったり、お客様への「情報通知」に使ったりと、多くの企業で日常的に活用されています。しかし、その「メンテナンス作業」がオロソカになってしまうケースは少なくありません。

• メールが届くべきではないヒトに届いている（情報漏洩？）
• メールが届くべきヒトに届いていない（新入悲劇あるある？）

そんな状況が、世界中で発生していることでしょう。

購読メンバーの自動追加

以下の業務プロセス定義は「資料請求対応フロー」です。

このワークフローはお客様の「Web申込」によって開始されます。そして、その申込案件が自動工程『メルマガ追加』に到達すれば、自動的に「お客様のメールアドレス」がメーリングリスト（Google Group）に追加される仕組みとなっています。

この様な処理の「無人化」は、G Suite 管理者が管理画面にアクセスして手動でデータコピーする手間を無くすだけでなく、設定ミスやタイムロスによるトラブルを未然に防ぐことにも寄与します。また手動設定では困難だった「アドレス追加の履歴記録」をも実現します。

[資料請求対応]