ブログ

業務プロセスの改善サイクルを回すのは容易ではない。ホントは毎月毎週のようにコツコツとPDCAを回したい。しかし、現状把握（Check）や対応（Act）に時間が取れないのが実情？ 業務プロセス定義をバージョンアップする（Re-Plan）なんて夢物語？？ ここでは「少しの工夫」で「小さな改善」を繰り返す方法について提案してみたい。

1. 集計も自動化！

自動開始（毎週や毎月）の「集計＆通知」が好き。

要は、業務データを無人で期間集計してくれる（そして通知してくれる）業務プロセス。ソレは「業務プロセスに流れたデータを集計する業務プロセス」というコトになる。（ヤヤコシイ…）

平たく言えば “自動レポート機能” だ。

たとえば、、、『立替金精算プロセス』に対して『前月立替金の集計プロセス』、、、のように集計用の業務プロセス（ワークフロー アプリ）を作るのだ。それらは勝手に始まり（タイマー開始）、途中の処理工程も全て無人で、そして勝手に終わる。そして、最下流に「関係者へのメール通知」や「タイムライン投稿」が配置されるのがオキマリとなる。

222-立替金精算

• 222-notice-前月立替金の集計と通知　（←毎月・スタッフ別集計）
• 222-cross-前月立替金の集計　（←毎月・全社集計）

242-出退勤報告

• 242-notice-前週の出勤簿の通知　（←毎週・スタッフ別集計）

242b-アルバイト出退勤報告

• 242b-cross-アルバイトの前月勤務時間集計

216-Flexible-Billing-Cycle

• 216-notice-Flexible-Report（などなど）

▼多用しているデータ抽出工程『Questetra BPMS: 案件, 指定データTSV一括抽出』

日付フィルタされた複数の案件データを複数行のTSV文字列として抽出します。抽出項目は “string:0,date:2,select:3″ のようなCSV書式で指定します。Tabコードと改行コードは、自動的に削除されます。”ファイル型” はファイル名が、”選択型” は選択された選択肢の表示テキストが抽出されます。

2. ソレって、モニタリングでわ？

確かに、わざわざ “集計用のプロセス” を実装する必要なんてナイ。業務データの期間集計をしたければ、その時々に「モニタリング機能」を使えば良い。いつでも、様々な角度から、過去のデータを集計できる。

そう。。。”集計プロセス” たちは、その「モニタリング」を自動化して、（通知して）、いるに過ぎない。

だがシカシ！、、、だが然し！！、、、なのだ！？！

3. いつでもデキル＝永遠にシナイ

「集計の無人化」をアレコレ実践してみて、改めて思う。

人間にとって「自分の意志で情報を見に行く」っていうのは、実は “とてもシンドイコト” なのだ。

• 興味がない訳ではない
• モチベーションが湧かない訳でもない

が “過去データを振り返ること” はあまりしたくないのだ。

単に「振り返りたくない」と表現してしまうと語弊があるので、掘り下げて考えてみたい。

むしろ “振り返るコト” は、”目の前にある新しいシゴト” に比べれば、大概はラクだ。（見て眺めれば良いだけ、なのだから…）　それでも人間は、“A: 振り返るコト” を “B: 目の前にあるシゴト” と比べてしまうと、ついつい「後で…」と考えてしまう生き物なのだ。　それは「今すぐヤル」ということ自体にメリットが無いのだ。「後でやっても同じ」→「後でやろう」。そして、その繰り返しで、結局 “集計データ” を見る機会が少なくなってしまう。

もし「KPIを集計し報告すること」それ自体が仕事なのであれば、きっと “後回し” にはしない。しかし、そのような場合、集計作業が完了した時点で「振り返り見るパワー」が残っていない。　たしかに、（ウマく言えないが）、KPI情報は「見る」のかも知れない。しかし、きっと「観ることができていない」のだろう。そして「診ることもできていない」のだろう。そして何の改善（PDCAサイクル／BPMサイクル）にも繋がらない。

そもそも “いつでも見ることができるモノ” と思ってしまった瞬間に、“いつまでも見ないモノ／めったに見ないモノ” にしてしまうのは、人類の必然なのだろう。

神戸に20年間住んでたクセに、一度も「異人館」に行かなかったようなものだ。。。（違）

４.Check のキッカケを作ろう！

つまるところ、、、責任者自身が『今すぐ実行しよう』と思える機会がなければならない。

キレイに集計された業務データを眺め見れば（業務の様子を振り返れば）、誰だって意見したくなる。少しは改善したくなる。

• 取り締まるコトが仕事である「取締役」、、、
• 監査するコトが仕事である「監査役」や「会計監査人」や「内部監査室」、、、

彼らがキッチリと “振り返り” を行えるのは、きっと「チェックすべき書類や報告」がルーティーンに届くから、だ。

その機会（キッカケ）のためには、やはり「外部トリガー」が重要なのだろう。自己管理がカンペキな人であっても、全てのタスクを「自己トリガー」（自分の意志）で開始することは容易ではない。（そもそも存在自体を忘れてしまう事だってある）

• “振り返り” を行えるのは、今しかない！
• “振り返り” を効率よく行えるのは、今だ！

そう思わせてくれるキッカケを自分自身に与えなければ、いつまで経っても振り返りを行うことができない、、、かも知れない。

データが、定時に、キレイに集計されて、届く。。。少なくともワタシにとって、この「自動集計通知」は、心地よいセルフ・マネージメント・ツール（ペースメーカー）になっている。。。 （今のところｗ）

▼二軸で集計の例

TSV文字列, 数値合計のクロス集計

▼単純集計の例

TSV文字列; 数値列の総和

▼集計の前段階でのデータフィルタ例

TSV文字列, テキストフィルタ

国民的な？徒歩ゲーム！

『ドラクエ・ウォーク』してますか？ （※ SQUARE ENIX社のスマホアプリ）”ドラクエ・ファン” な我が家では、ワタシ（46♂）だけでなく、子供達（9♂・7♂）も、歩きまくってます。（俺たちは勇者だ！）そもそもワタシは毎日の通勤が徒歩です。なので、子供達より圧倒的に有利です。 （父はいつでも強くなくてわナリマセン？） しかも最近では、コッソリ “遠回り” しています。（えっ？ 姑息？？）

自動計測アプリ（Google Fit）の集計で見ても、『ドラクエウォーク』のリリース日（9月12日）以降は、よく歩いています。特に、子供達がオフルのスマホにインストールした日（9月14日）以降は、毎日の「歩数」が倍増していました。（下図のカレンダ表示参照）

※ 最近の Android や iPhone にはジャイロセンサー・加速度センサー・GPS などが搭載されているため、スマホ単体でも歩数や移動距離などを自動で計測できるのです。かなり正確です。そこで活躍するアプリは「アクティビティ・トラッカー」とも言われます。

業務報告にも活用？

ある日、歩いていると、、、「この Fitness データ…、もっと活用できるんぢゃね？」
「たとえば “働き過ぎの検知” とかにも、使えるんぢゃね？？」などなど、、、いろんな妄想が止まらなくなりました。

つまり、、、たとえば、、、『“運送会社の配送員” が、会社スマホを持ち歩いた歩数』といったデータが、もしこの世の中にあるとすれば、、、、それは会社が管理すべき対象なのではないでしょうか？？ （←いかにも真面目風）（他にも、旅行会社の添乗員の歩数とか、外回り営業マンの移動距離とか、訪問メンテナンス作業員の血圧変化だとかｗｗ）たしかに「プライベートな時間のデータ」も含まれているので取り扱いが難しいところです。うーん。うーん。うーん。しかし、就業時間だけを切り出せば、（任意の時間で切り出せれば）、使ってもイイような、エエような、イイような。。。（そもそも健康管理は会社の義務／安全配慮義務？　監視社会・監視企業？　ブラック企業？？）

そもそも賃金（労働対価）を時間だけに依存している現状労基法には無理がある。ましてや “生産性” を語るなら尚更だ。いっそ「”１日１万歩” を超えたら “歩き過ぎ割増賃金” を付けちゃう」とか…（暴論）

REST API で実装！

ということで、、、　「利用シーン」についてはダンダンどうでも良くなってきたので、、、「利用シーン」については後回しにすることとして（！）、、、早速作ってみました。上の超シンプルな “ワークフロー図” と “データ入力画面” を見て頂ければ、何となく解かると思いますが、、、、
つまるところ『任意時間の「歩数データ」を切り出してくる』という工程が自動化される仕組みです。（自動処理工程名：Google Fit データセット 歩数集計 via “Fit REST API”）

要するに、、、たとえば、、、

• 「9～17時の歩数」のレポートメールが、翌朝、自動的に届く！
• 「日報にかいた業務時間の歩数」が提出した日報に自動加筆される！

といったことが実現できるようになりマス。
さらに、〔2.上司承認〕のような上司工程を後置すれば、立派な（？）企業ワークフローに！？ワタシ自身が “歩き回る仕事” ではないので有用性がワカラナイ（検証しづらい）ので、、、もし何処かの会社の、何かの業務の自動化に貢献できそうなら、是非ご一報ください。万が一にも強いニーズあれば、自動処理の仕様についても積極的に改変させて頂きたいと思います。よろしくお願いします。

追伸１：

ちなみに “Fit REST API (v1)” は、とてもクセのある API でした。（実装 Script などはリンク先を参照してください）Request Json を POST する形式（aggregate）は、Slides API や Sheets API （batchUpdate）などと同じ仕組みなのですが、

• 許諾（OAuth2 Scope）内容に関わらず、デバイス Raw データには参照させない…、とか
• データ生成クライアントのみが参照できるようにIDの一部が難読化されている…、とか
• ミリ秒ではなく、マイクロ秒でもなく、ナノ秒で記録されている…、とか （マバタキは何ナノ秒なの？）
• 集計の境界時刻をまたぐウォーキング（歩数や距離など）は、そのどちらにも合算されてしまう…、とか

なんともオモムキ（？）がある API です。さらに、（現時点では自身のデータしか取得できませんが）、将来的には “他人のデータ” も取得できそうな Parameters 設計になっていること、も新鮮でした、にも驚きました。ま、「Google Fit Web サイト」の類似サービスが復活することはなさそうですが、それ以外の周辺サービスの動向については、今後もウォッチし続けていきたいと思っています。

let requestObj = {};
    requestObj.aggregateBy = [];
    requestObj.aggregateBy[0] = {};
    requestObj.aggregateBy[0].dataTypeName
                              = "com.google.step_count.delta";
    requestObj.endTimeMillis   = numEndTimeMillis;
    requestObj.startTimeMillis = numStartTimeMillis;
    requestObj.bucketByTime = {};
    requestObj.bucketByTime.durationMillis = numDurationMillis;
let apiRequest = httpClient.begin(); // HttpRequestWrapper
    apiRequest = apiRequest.bearer( token );
    apiRequest = apiRequest.body( JSON.stringify( requestObj ),
                                  "application/json" );
const apiUri 
      = "https://www.googleapis.com/fitness/v1/users/me/dataset:aggregate";
engine.log( " AutomatedTask Trying: POST " + apiUri );
const response = apiRequest.post( apiUri );

＃超個人的には「血圧」と「体重」（←とっぷしーくれっと？）を手入力し続けている（←イイ機器あったら買いたい）ので、”朝昼晩での増減傾向” などを分析しようかな、とか、思ったり思わなかったり。。。

追伸２：

ちなみに『ドラクエ・ウォーク』の進捗は。。。現時点で配信されているストーリーは全て終了しています。”第５章クリア” は Lv48 でした。ええ、無課金デス。（←子供達の手前、仕方ないのデス）「ゲームがなかったら運動できへんのか～い？・健康管理できへんのか～い？」と言われれば返す言葉もないのですが、、、まぁ、もうしばらくは、子供達と一緒に、”ウォーク” を楽しもうと思っています。（俺たちは無課金勇者だ！！）

こんにちは！矢作です！

クラウド型ワークフロー「Questetra BPM Suite」を開発・販売する我が社（クエステトラ社）には、大変ありがたいことにワークフローについて多くの相談が舞い込んできます。

ご相談の中には素晴らしいアイデアが盛り込まれていて感心するものもあれば、「こんなワークフローはイヤだ」と見ないふりをしたくなるようなものまで様々なものがあります。

本記事では「こんなワークフローはイヤだ」と面食らってしまうものの中から、「ノイズにも対応せざるを得ない」ワークフローを選び、その課題や解決方法について考えます。

ノイズにも対応せざるを得ないワークフロー

「問い合わせ対応業務」を例に考えます。

ウェブサイトの問い合わせフォームなどから問い合わせが届いたら、問い合わせ窓口がその内容を確認します（「問い合わせ内容確認」工程）。

確認を終えたら問い合わせへの回答を作成したり、回答に必要な知識を得るために関連部署に助言を求めたりします。

このワークフローの問題点は、問い合わせの内容が何らかのサービスの売り込みであったり、問い合わせ者の連絡先（返信先）に明らかな誤りがあって返信できなかったりなどの場合に、「問い合わせ内容確認」工程で止まらざるを得なくなることです。そんなノイズのような問い合わせには対応したくないのですが、何らかの形で対応せざるを得ないのです。

「ノイズにも対応せざるを得ない」ワークフローはイヤですよね？

ノイズ認定して終了！

このような「ノイズにも対応せざるを得ない」ワークフローを改善するのはカンタンです。

問い合わせ窓口の「問い合わせ内容確認」工程で、”問い合わせ内容がノイズであると判断される場合に終了に向かうフロー” を引きます。

カンタンですね。このカイゼンにより「問い合わせじゃないよね」という問い合わせが入った時に、それをノイズとして終了させることができるようになります。

業務はスタートしたけど、途中で停止せざるを得ない、という場合は少なくありません。

• （今回のように）問い合わせの内容がノイズである
• 企画検討業務で起案したものの、何度も差し戻されたから取り下げる
• 締切になってしまって先に進められなくなる

などのシーンが考えられます。このような場合には通常の終了とは別の場所に終了マーク（終了イベントと呼びます）を置き、分岐を設けてそこに仕事のボールを流して終わらせるようにする、という方法が役に立ちます。

この方法は、イレギュラーに対応しやすくするものでもあります。細かく多くのイレギュラーを想定し、それら全てに対応できるようにフローを引くと見づらいワークフロー図になってしまうリスクもあるので注意が必要です。

工程の分岐は権限を示す

問い合わせ内容がノイズと判断されたら、ノイズとして対応を終了するというフローを作る、というカイゼンには、他にも価値があります。

このフローの存在により「問い合わせ内容確認」工程で “問い合わせ窓口” が、何をするべきなのか、何を任されているのか、がより明確になるということです。

”問い合わせ窓口” は、問い合わせ内容を確認し、

• それがノイズであるのかどうかを判断しなくてはならない。判断して良い。
• ノイズと判断したら、対応を終了させなくてはならない。終了させて良い。

ということが、この工程の分岐を見るだけで分かります。この分岐には、工程を処理する人の “権限” が示されているということです。

今回のカイゼンは、単にイレギュラー対応がしやすくなったということに留まらず、その工程において「すべきこと」「して良いこと」を明確にすることにつながっている、ということにも目を向けていただければと思います。

まとめ

今回は、問い合わせ対応業務を例に、それ以上前にすすめることができないワークフローをカイゼンする方法を紹介しました。

通常の終了とは別の場所に終了ポイントを作り、そこに仕事のボールを流すことができるようなフローを作る、というものでした。このカイゼンを通じて工程に「分岐」が作られることになり、その結果、当該工程における “権限” がより一層明確になります。

ワークフロー図を書き、更に今回のようなカイゼンを行うと、その業務に関わる人たちの間で業務の進め方に対する共通の認識を持ちやすくなります。是非、身近な業務についてワークフロー図を書いてみてください。

最後に宣伝ですが、ワークフロー図を書くなら、クラウド型ワークフロー「Questetra BPM Suite」を是非ご利用ください（60日間無料お試しあり）。

今回はここまで！

こんなワークフローはイヤだシリーズ

差し戻しできない – こんなワークフローはイヤだ（１）

誰もチェックしてくれない – こんなワークフローはイヤだ（２）

部下しかスタートできない – こんなワークフローはイヤだ（３）

順番にしか処理できない – こんなワークフローはイヤだ（４）

なんでも最新版！

貴様、、、業界人なんダロ。。。

Questetra 社のウェブサイトは “WordPress.com” 上で運用されています。

ええ、「Wordpress 5.0 への移行」は、2018年12月に強制的に行われました。。。そして、その日から “5.0 の新エディタ”（Gutenberg Editor）が Questetra 社の「標準エディタ」となっています。

はい、そうですネ。。。かなり従順です。とは言え「クラウド メジャー」の製品は、好むと好まざるとにかかわらず、まずは “体験するコト” に意義があるのデス。。。（←誰と喋っとんネン）

もちろん正直なトコ、不安しかなかったのは事実です。が、どんなクラウド製品も、（特に SaaS CMS は）、実際に利用してみないと分かりません。まさに「習うより慣れよ」です。体験して初めて「流行動向」を認識できるのです。あるいは「連携」を模索することができるのです。

案外すんなり移行

6年くらい慣れ親しんだ旧エディタとサヨナラ

そんな “衝撃の日” から、早いもので9カ月。。。。

今となってはミンナ、新しいビジュアルエディタ（Gutenberg Editor）を使いこなしています。オフィシャルサイトでも、サポートサイトでも、、、社員さんも、バイトさんも。。。基本的に、以前のエディタ（クラシックエディタ）よりは、「簡単」で「直観的」なんだと思います。（WordPress 5.2.2 なう）

「HTML？、、、 漢（オトコ）なら、ジカガキだろ」

とか言ってしまう20世紀的な古い人間（ワタシ）すら、今となっては、複製や並べ替えを “Block 操作” で行うようになって しまいました います。

強いて「困ったコト」と言えば…、『困ったことがあっても Google 先生の答え（ネットの情報）が古いというコト』でしょうか。。。（禅問答的）

自由が足りない？

Visualエディタなのに Short Code 現役続行？

しかし、最近になって、

「えっ、ワタシの原稿、シンプルすぎ？」

という意見も。。。（←つまり簡単でシンプルだから「ウェブサイトとして味気ないかも」というハナシ）

たしかに『就業規則』のような情報ページですら、様々な “レイアウトデザイン” を適用したくなるものです。

定義リスト（dl dd dt）で「条文」を列挙したい・・・
ボックス囲みで「注釈」を挿入したい・・・
いっそアコーディオンで「定義の説明部分」を開閉できるようにしたい・・・

そして、そんな時は仕方なく、、、 “ショートコード開始” （［su_foo］）と “ショートコード終了” （［/su_foo］）を「ショートコード Block」で書き、”ショートコード中身” を「段落 Block」で書くことになるワケです。。。ナンテコッタ、ぱんなｋ。。。

ほなPluginヤロ！

Theme ベンダが公開しているPluginを採用

というコトで、Questetra 社の WordPress 環境にも “Block Plugin” がインストールされました。

Brainstorm Force @ India
Ultimate Addons for Gutenberg
Extends the Gutenberg functionality with several unique and feature-rich blocks

え、「どんなイケてるデザイン Block があるのか」、、、ですか？？　ええ、、、ハイ、、、ですから、、、今まさに、 この Blog で色々テストしている真っ最中でゴザイマス。。。（慣れてきたら追記するかもデス。スミマセン）

こんにちは！矢作です！

クラウド型ワークフロー「Questetra BPM Suite」を開発・販売する我が社（クエステトラ社）には、いつもワークフローに関する相談がたくさん届きます。

ご相談の中には、見事な業務改善を実現されていてすっかり感心してしまうものもあれば、思わず「こんなワークフローはイヤだ」と叫んでしまいそうになるものまで様々なものがあります。

本記事では「こんなワークフローはイヤだ」と叫んでしまったものの中から、「順番にしか処理できない」ワークフローを取り上げてその課題や解決方法について考えます。

順番にしか処理できないワークフロー

通信販売業における「商品企画」業務を考えます。

通信販売業では、商品が商品カタログに掲載されるまでに多くの「評価」がされます。商品そのものが良いものであることは当然なのですが、他にも以下のような視点での「評価」が行われます。

• 生産者（企業・個人）の信用（反社会的勢力でないか？債務超過でないか？）
• 生産体制（一定の質・量を安定して生産できるか？）
• 物流体制（安定してお客様にお届けできるか？）

これらの「評価」が確実に行われるワークフローの例は次の通りです。

商品企画担当が新たな商品の企画を立案したら、3つの「評価」が順番に行われます。「生産者の評価」「生産体制の評価」「物流体制の評価」が確実に遂行されます。最後の「決裁」を行う際には全ての「評価」が済まされていることになります。

このワークフローの問題点は、3つの評価が「順番」にしか処理されないということ。

「生産体制の評価」は「生産者の評価」が終わらないと着手できません。また、「物流体制の評価」は「生産体制の評価」が終わらないと着手できません。

これら3つの「評価」がそれぞれ依存関係にない場合には、「商品企画立案」工程が処理されたらすべての「評価」にすぐ着手できます。それにも関わらず、それぞれの「評価」工程を順番にしか処理できないと、「立案」から最後の「物流体制の評価」工程が終わるまでの時間が長くなってしまいます。

こんなワークフローはイヤですよね！？「立案」が終わり次第、全ての「評価」に着手したいですよね！？

評価工程を「並列化」

「商品企画立案」工程が処理され次第 3 つの「評価」工程に一斉に着手できれば、「決裁」工程までにかかる時間が最も短くなります。これを実現するには、次のようにワークフロー図を変更します。

ワークフロー図をこのように変更すると「商品企画立案」工程が処理された後、3つの「評価」工程にすぐに着手できるようになります。

「商品企画立案」工程の下にあるグリーンのダイヤの形をした記号（※）が、重要な役目を果たします。中に “＋” マークが書かれています。
※「並列ゲートウェイ」と呼びます。

この記号は、ここに届いた「仕事のボール」が出て行く矢印の数に分裂することを示します。

今回の改良後のワークフロー図について説明します。

「商品企画立案」工程の時点では「仕事のボール」は一つです。これが「並列ゲートウェイ」を通過すると、ここから出ていく矢印の数に「仕事のボール」が分裂します。今回の場合は、矢印の数が3つなので、3 つに分裂することになります。

分裂したボールが、それぞれ「生産者の評価」「生産体制の評価」「物流体制の評価」工程に届き、それぞれの工程の処理を行える（着手できる）ようになる、ということです。

仕事のボールの待ち合わせ

仕事のボールが 3 つに分裂することで、3 つの「評価」を同時に着手できるようになりました。

一方で、仕事のボールが「商品企画決裁」工程に届く前に、分裂した3つのボールが待ち合わせをして、全て揃ったら仕事のボールは１つに戻って（１つに結合して）から「商品企画決裁」工程に届くようにしなければなりません。

ワークフロー図の中に、3つの「評価」工程の後、かつ「商品企画決裁」工程の前に何も書かれていない、グリーンのダイヤ型をした記号（※）が置かれています。
※「結合ゲートウェイ」と呼びます。

「結合ゲートウェイ」は分裂したボールが待ち合わせをして、全てのボールが揃うと１つに結合することを示します。

今回のワークフロー図では、「生産者の評価」と「物流体制の評価」が「生産体制の評価」よりも先に終わっても、「結合ゲートウェイ」で仕事のボールが停まります。

「生産体制の評価」工程が処理され、3つ目のボールが「結合ゲートウェイ」が届くと、仕事のボールは1つにまとまり（結合され）、「商品企画決裁」工程にボールが流れます。

並列化の価値

ワークフロー中の各工程を順番にしか処理できないものを、並列に処理できるようにする（並列化）価値は、既にチラリと述べましたが、当該の工程に早く着手できるということです。

下図において、並列化されていないフロー（直列フロー）では、工程Aと工程Bの両方が処理されるのにかかる時間 T1 は Ta + Tb となります。一方、並列化されたフロー（並列フロー）では T2 は Ta または Tb となります。

T1 > T2 となり、並列化することで処理時間が短縮されます。これは、QCD で言うところの D（Delivery=納期）が短縮されることになりますので、業務改善の手法として大きな価値をもたらすものと言えます。

並列化の価値を最大化するワークフローシステム

並列化の価値が最も大きく発揮されるのは「Questetra BPM Suite」のようなワークフローシステムを利用する場合です。（もちろん、ワークフロー図を書くだけでも一定の価値はあります）

ワークフローシステムを使うと、ワークフロー図に書いた通りに仕事のボールが自動的に流れる仕組みを簡単に構築することができます。「並列ゲートウェイ」「結合ゲートウェイ」を含むワークフロー図を書くだけで、仕事のボールが分裂し「結合ゲートウェイ」で結合するような仕組みが、自動的に構築されます。

ワークフローシステム「Questetra BPM Suite」を使うと、ここで書いたようなことを無料で体験できるので、興味がある人は60日間無料の Trial をお申し込みください。専用のご利用環境がすぐに構築されます。

今回はここまで！

こんなワークフローはイヤだシリーズ

差し戻しできない – こんなワークフローはイヤだ（１）

誰もチェックしてくれない – こんなワークフローはイヤだ（２）

部下しかスタートできない – こんなワークフローはイヤだ（３）

ノイズにも対応せざるを得ない – こんなワークフローはイヤだ（５）

消費増税対応（追加請求）もワークフローで！：　とある SaaS ベンダ。2019年の増税によって「消費税の追加請求」が必要となった。よし、ならば。。。この特殊な請求書の生成や送信も、自動化してみようではないか。。。

1. 消費税の追加請求？

2019年10月、ついに消費税が “10%” になる。
ま、「社会保障の安定財源確保」のタメだ、、、シ・カ・タ・ナ・イ（←棒読み）。

で、、、SaaS ベンダの場合、「予定売上高」（前受金売上）について修正する必要がある。平たく言えば、年間契約に対して「消費税の追加請求」をしなければならない。たとえ “すでに入金済み” であっても、関係ない。。。（詳しくは法律 H25-41, H28-85, 86 あたりを参照されたい）

そこで “差額消費税” に関する請求書PDFが、(1)自動生成され、(2)自動送信される、そんなシステムを “開発” したい。当然ながら『Questetra BPM Suite』（SaaS BPMS）で組み上げたい。（←ほとばしる自社製品愛！？！）

［心の中の声］　まぁ、オレ様ほどのモデリング技術があれば、どんな「ビジネスプロセス」でもチョチョイのチョイだ。ずっと改善し続ける「日常業務」だけでなく、ちょっとした「繰り返し作業フロー」だって、速攻で “ワークフロー・アプリ” （自動化されたシステム）を作れてしまうのだ。ガハハハハ。（←誰ヤネン）

業務プロセスを構成する工程の多くは「CSV／TSV の列編集」（エクセル作業的な処理） が中心となるだろう。掛け算する、並べ替える、接尾辞を付ける、数値列を総和する、あたりの “自動処理工程” を Addon しておけば、「大半の工程が自動化された業務プロセス」を組み上げられるハズだ。

2. 請求システム完成

ワークフロー アプリができた。（←中略スミマセン）
業務プロセスの “インプット” は『予定されていた売上伝票』の入力にした。（「ワークフローのトリガー」とも言う）

クエステトラ社の場合、成約時点で全ての『売上伝票』（按分予定分を含む）が Accounting SaaS（マネフォ会計）に投入されている。なので、全ての売上伝票から会社名（ウチの場合「補助科目名」）でフィルタし、TSVコピペ（セル範囲の選択コピー）すればよい。その入力によって、各社への請求プロセスが開始される。

＃細かい話になるが、全ての伝票は Google Spreadsheet にバックアップされているので、そちらのデータを使って “2019年10月以降分” を抽出している。（MoneyForward はコピペしづらい）

プロセス図を一見すると「長大な業務プロセス」にも見える。確かに “自動処理工程”（グレーで表現）は想像以上に沢山ならんでいる。しかし “ヒューマン工程”（水色）はそれほど多くない。今風な Workflow Automation と言っても良い？！　たしかに “ニワカジコミな仕組み” な感は否めないが、”次の増税” までは5年10年かかりそうだし、まぁコレくらいでイイだろう。。。

人間が処理するヒューマン工程は、具体的に以下のような処理が行われる。（大した作業ではない）

1. 対象売上伝票のInput： 請求先企業ごとに「10月以降の売上伝票」（売上予定伝票／前受金売上伝票）を入力する。
2. 生成PDF全般チェック： 自動生成された請求書PDFを確認する。（必要に応じて詳細データ部を２段組にする）
3. 入金日請求日の確認： 担当営業の視点で入金日・請求日がデフォルト設定のままで良いか判断する。
4. 入金確認： 請求した金額の銀行着金を確認する。

ちなみに、「どうしても郵送が必要」というクライアントには “要郵送” の属性が与えられている。そのフラグが立っているプロセスは、第3工程が完了し次第、『紙の請求書』が事務所プリンターから自動的に出てくるような仕組み（Google Cloud Print）になっている。（←あとは “窓付封筒”に入れるだけ）

別途、会計システム（MoneyForward クラウド会計）のため「修正伝票」（新しい売上伝票・赤伝・入金予定伝票）も自動的に生成される機能も搭載している。（入金予定伝票だけは “未実現” フラグを入れてインポートされる）

【会計知識ある方のための補足】　 “年間契約” の売上高は、契約期間の各月に按分 （万一端数あれば初月に加算） され、各月1日付にて売上計上されている。当該売上伝票のCSVは、受注対応フローにて自動生成され、Google Spreadsheet に自動連携（自動追記）されている。（翌朝に “Money Forward にインポートすべき情報” が自動集約される）　この場合、会計年度をまたぐ情報（次年度以降の売上）も必要となるため、（Money Forward ではなく）、Google Spreadsheet を参照せざるを得ない。

3. 請求システム運用

さてさて、全ての “年間契約” について、早い段階で第3工程「入金日請求日確認」が終了されなければならない。いろんなクライアントの事情を考えると「早いほうが良い」と思う。とりあえず「請求日」のデフォルト値は “2019年9月1日” に、「入金期限」のデフォルト値は “2019年10月31日” にしてみた。（進捗モニタリング、大事）

まぁ、色々なトラブル・問い合わせが発生するのだろう。

たとえば「請求金額が小さいケース」は “柔軟な対応” が必要だ。小規模ユーザの場合は「年契約の金額」も少額であり、契約期間によっては「新旧消費税の差額」が数百円となってしまうケースすらある。今のところ、「入金期限を次の請求書」とか、「次の契約の話を前倒しする」みたいなアイデアが考えられるが、、、うーむ、ナカナカに悩ましい。

つまり、担当営業氏にしてみれば、（or パートナー氏にしてみれば）、「そんな面倒な話をするくらいなら、オレがポケットから出すよ」なんてことにもなりかねない。うーむ、もっと良いコミュニケーションがあるような気もする。。。

ナンにせよ、まだまだ「暗中模索」といった感じだ。何かオモシロイコト（？）が起きれば、続報したい。
＃ていうか、国の根幹制度（特に税制）は、もっとシンプルにして欲しいんだけどなぁ。。。

皆さんは大きな目標があるとき、その目標を達成するために、どんな計画をして行動しますか？

会社にも、必ず達成しなければならない目標があります。本記事では、企業が大きな目標を達成するための方法について考えます。

大きな目標を細かく分けて行動に移す

先日、元水泳オリンピック選手のセミナーに参加したのですが、そのセミナーで、オリンピック選手を夢見る子ども達への下記のメッセージがとても印象に残りました。

”今は漠然としていて夢のような目標だけれど、その目標を細かく分けてそれを達成できるようにしてみてください。例えば、次の大会ではこのタイムを切ろうとか、小学生、中学生、高校生での目標タイムを作ることです。すると、やがて毎日の練習も大きな目標への大切な一日で、その日やるべき練習内容とその意味が分かってくるようになります”

”大きな最終目標を細かく分けて行動に移す”

この方法は、大谷翔平選手の目標達成シートが有名です。最終目標、細かく分けた目標、日々の行動、に分かりやすく分類されています。

この図のように、大きな目標だけでは今行動に移すべき手段をイメージしにくいですが、その目標を細かく分けてみると、そのための手段が明確になり迷うことなく行動に移すことができます。

しかし、これらの方法はスポーツ選手だけではなく、私たちが取り組む仕事でも似ているところがあります。

最終目標のKGI

仕事では、組織や企業が達成すべき最終的な大きな目標をKGIと呼びます。”Key Goal Indicator”の頭文字をとったもので、定量的な指標で表したものです。いつ、どの指標がどのレベルに到達したら目標達成とみなすのかを定義します。

具体的に分かりやすく数値化できない抽象的な理念や目的は、KGIとしてそぐわないので使われることはありません。それは、さまざまな価値観をもった関係者全員が目標を共有しにくく、その目標と実績を比べ、達成できたかどうかの判断も価値観によりさまざまで評価しにくいからです。また、その企業や組織がどうなりたいのかという目的が明確になっている必要があります。それを実現するために、期限を設けて何をどれくらいという数値目標で設定します。

KGIは、企業や組織が最終的に達成すべき長期的な目標です。KGIの設定だけでは、日々の業務でやるべき事や手段がすぐには明確になりにくく漠然としています。そこで、最終的な目標に到達するために、その前段階としてまずはこの目標を達成しようという中間目標（KPI）を設定するのです。

最終目標を適切に分解したKPI

KPIは、”Key Performance Indicator”の頭文字をとったものです。

企業などの組織において最終的な目標に到達するために、その前段階としてまずはこの目標を達成しようという中間目標を表す指標です。つまり、まず最終目標であるKGIが明確になっている上で、その目標を適切に分解し中間目標であるKPIを設定します。それから、その分解された中間目標のための手段を決め行動に移します。そして、その手段が正しく成果に向かっているかどうかの進行状況を定期的にモニタリングし、確認するためのものがKPIなのです。

目標達成までの過程にはさまざまな工程がありますが、それらの工程でそれぞれの目標数値を設定しておくことで、どこで問題が起きているかの原因を検証しやすくなります。

KGIは最終目標が1年、5年といった長期間を対象とするのに対し、KPIは短期間で結果のわかる数値を指標とする違いがあります。具体的に、次にアクセサリーを扱うネットショップのKGI、KPIと手段の関係図を例に挙げます。

最終目標だけでは今行動に移すべき手段をイメージしにくいので、中間目標であるKPIを具体的な数値とともに設定するのです。

すると、やるべき手段が明確になり迷うことなく行動に移すことができます。KPIをチームで共有することは、メンバの目標に対する意思の統一ができます。更に、共通の評価基準を作ることもできるのです。

しかし間違ったKPIを設定すると、そのKPIを目標とした手段も間違ったものになります。最終目標に対して返って逆効果になるので、KPIの設定は慎重に行う必要があります。

KGI、KPIを業務改善の材料に

KGI、KPIを定め、それに基づいて業務を進めて行くことは、業務改善の材料になります。実際に以下のような流れで業務改善を進めていくことができます。

・KGIの設定

• 成功か失敗かの判断ができる・・・1
• KPIを設定することができる・・・2

・KPIの設定

• 手段に問題がないかの確認ができる・・・3
• KPIの設定自体に問題がないかの確認ができる・・・4

まず、KGIを設定することによって、

1. 何が成功で何が失敗かを判断できる

例えばネットショップで年1000万円売り上げたとします。この場合、KGIを定めていないと成功か失敗かも分かりません。つまり、業務改善する必要があるかどうかも判断できないのです。

2. KPIを設定することができる

最終目標のKGIを達成するために、適切に分解された中間目標（KPI）を定めることができます。これにより、中間目標を達成するためにやるべき業務、移すべき行動を明確にすることができるのです。

次に、KPIを設定することによって、

3. 手段に問題がないかの確認ができる

もし定期的なモニタリングでKPIを達成できていなければ、まずは手段に問題がないかを考える必要があります。

例えば、先ほどのアクセサリーを扱うネットショップの図のKPI（サイトのページビュー数1か月3万）に対し、毎日のFacebook投稿を手段とする場合を考えてみます。この場合、意味のない内容の投稿を毎日行ってもあまり効果はありません。また、サイトのページ数を増やすという手段においても、ただページ数を分割するだけではかえって読みづらいサイトになります。

この場合は、手段である業務に問題があることが分かり、手段を改善する必要があるのです。

4. KPIの設定自体に問題がないかの確認ができる

定期的なモニタリングでKPIを達成できていなければ、次に、KPIの設定自体が現実とかけはなれた数値になっていないか、もしくは最終目標に対して的外れな中間目標になっていないかを考える必要があります。KPI自体が間違ったものであれば、それをめざす手段（業務）も間違ったものになるからです。

このように、KPIの設定、定期的なモニタリングは、手段である業務の問題点の発見、目標設定が適切であるかの確認も定期的にでき、素早く問題点に気づくことができるのです。

KGIの設定は慎重に

やるべき仕事、改善すべき業務の手段を決め、行動に移すためには、中間目標（KPI）が具体的で現実的な数値でなければなりません。その中間目標（KPI）を具体的で現実的な数値にするためには、KGIも具体的で現実的でなければなりません。

そのためには、KGIを定める人は、チームが取り組むそれぞれの業務の内容、特性、手順、ルールをしっかり見極め、理解しておく必要があるのです。

関連記事はこちら

今年こそ設定したい「KGI」と「KPI」

企業の成長に欠かせない「KGI」や「KPI」の設定。その重要な3つのポイントとは？ <…