ブログ

なんでも最新版！

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

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

こんにちは！矢作です！

クラウド型ワークフロー「Questetra BPM Suite」を提供する我が社（クエステトラ社）は、ワークフローに関する相談をたくさんいただきます。

そのお客様特有の変わったご相談から、よくあるすぐに解決できるものまで様々なものがあります。しかし、中には「こんなワークフローはイヤだ」とぼやきたくなるものもあります（苦笑）。

本記事では「こんなワークフローはイヤだ」とぼやいてしまうものの中から「部下しかスタートできない」ワークフローをピックアップし、その課題や解決方法について考えます。

部下しかスタートできないワークフロー

「オペレーションミス報告」業務を例に考えます。ワークフロー図の例は次の図のとおりです。

現場で発生したオペレーションミスを集約し、組織として対応すべき案件を見過ごさないようにすること、集まった情報を分析し業務改善を検討すること、を目的としています。

現場でオペレーションミスが発生した時、担当者がその内容を「報告」します（報告書作成）。上司は、報告内容を「確認」し、問題がなければ完成とします。報告内容に曖昧な点があったり、原因や改善案が曖昧な場合には差し戻すことができます。（報告書確認）

上司が「確認」を終えると、業務監査チームに「報告」内容が届き、業務監査視点での何らかの対応（本記事では触れない）を行います。（監査対応）

この業務フロー（ワークフロー）の問題点は、いつまでたっても報告がされない可能性があること。

ミスを報告するという業務は、ミスをした担当者にとってメリットが感じられません。評価が下げられるかもしれないという不安があるので、積極的に取り組もうとしない気持ちが働くのも自然なことです。（このようなことが現場では起こっているという話をよく聞きます。オペレーションミス報告業務はうまくいかない…と。）

しかし、現場を統括する上司としては、組織に対してきちんと報告させなければなりません。そんな時、部下がいつまでたっても報告フローをスタートしないというのは困りものです。

こんなふうに、上司にとっては「部下しかスタートできないフロー」って、イヤな場合があります。

上司にもスタートさせてあげて！

オペレーションミス報告に限らず、営業の案件報告や企画業務など、部下の能動的な開始に任せるのではなく、上司から指示してスタートさせたい、ということは少なくありません。

次のように上司もスタートできるように変更します。

ワークフローのスタートマーク（専門用語では “開始イベント” と呼んだりします）をひとつ追加し、部下の「報告書作成」工程との間に「報告書作成の指示」という工程を置いています。

こうすることにより、「報告書作成の指示」工程で、上司は部下が報告すべきオペレーションミスのカンタンな情報（日付、概要、何らかの管理番号など）をまとめ、担当者に「報告書作成」を促すことができるようになります。

様々なスタートを想定する

ワークフロー図を書く時、基本的な流れ（今回の例だと部下からスタートする）以外に、他のスタートがないか考えると、いくつかいいことがあります。

• 業務に関わる人は、どのようなスタートがあり得るのかを理解できる。
  • 今回の例だと上司からのスタートはイレギュラーにはならない。イレギュラーに伴う無駄な議論や調整が不要になる。

• ワークフローシステムなどの進捗管理を行うシステムを構築（設定）する時、様々なスタートを想定することができる。

「オペレーションミス報告」ワークフローの場合は、上司だけでなく業務監査チームがスタートする、という方法も考えられますね。次の図のように、上司のスタートと同様にもう一つスタートマークを配置し、業務監査チームが報告を指示する、ことができるワークフロー図を書くことができます。

また、今回のワークフロー図に基づいて構築（設定）されたワークフローシステムを利用すると、次の図のような業務進捗の表現が可能です。

まとめ

本記事は「部下しかスタートできないなんてイヤだ！」という気持ちから始まりましたが、最終的には「スタート（業務の開始）」の考え方に関する内容になりました。

ワークフロー図を作成する時、どのような「スタート」があるのか、固定観念にとらわれず考えを巡らせてみると、よりうまく業務を進める環境を構築できる（業務改善）ようになります。

本記事でちらりと紹介した、ワークフロー図上に業務の進捗状況が表示される仕組みはクラウド型ワークフロー「Questetra BPM Suite」を利用しています。「Questetra BPM Suite」はワークフロー図を書けば、ワークフロー図通りに業務を進めていく環境が自動構築され、進捗状況や実績がわかりやすく表示されるシステムです。

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

最後に宣伝を交えました（笑）が、今回はここまで！

こんにちは！矢作です！

我が社（クエステトラ社）は、業務フロー（ワークフロー）改善のためのツールを提供しているので、お客様からいろんなタイプの業務フロー改善の相談をいただきます。そのような相談の中で、お客様が描かれた業務フローの中には思わず「こんなワークフローはイヤだ！」と唸ってしまいそうになるものがあります。

本記事では、「こんなワークフローはイヤだ！」のひとつである「誰もチェックしてくれないワークフロー」について、その課題や改善アイデアを考えていきます。

誰もチェックしてくれないワークフロー

「問い合わせ対応」業務を例に考えていきましょう。この業務では、受け付けた問い合わせに対して、「回答」を作成して、問い合わせをしてくれた人に「回答」を送ります。

最初に、問い合わせ窓口の人が問い合わせを「受け付け」ます。

「受け付け」工程では、問い合わせの内容を確認して、回答を作成するかどうかを決めます。（問い合わせ窓口には、エンジニアいりませんか？広告出しませんか？セミナーに参加しませんか？など、問い合わせではない問い合わせがちょくちょく届く。）

本来の業務であれば、ここで回答作成の担当者を決定する、ということも考えられますが、ここではカンタンのため、対応するかしないかの判断を行うのみとします。

そして問題は「回答作成 / 送付」工程でのこと。

上の図のようなフローの場合、”回答作成担当” が問い合わせに対する回答を作成し、そのまま送付する、ということになります。

絶対にミスなんてしないなんてことがあればいいのですが、組織で様々な人が関わる仕事では、多かれ少なかれミスは起こってしまいますよね。

作成した回答文章にはどのようなミスが混入することが考えられるでしょうか？

• 誤字脱字
• 不適切な表現
• 誤った内容

などでしょうか。「それも愛嬌」と許される（？）軽微なミスから、お客様からの信頼を失ってしまう重大なミスまで、様々なミスが考えられます。

このようなミスが混入するリスクがあるのに、誰にもチェックされずに作成した回答文が送られてしまうようなワークフロー、これはイヤですよね！？

「チェック」工程を作る価値は大きい

それでは早速、回答文の内容を確認する「回答 チェック」工程を用意しましょう。次のような手順で「回答チェック」工程を配置します。

これまでの「回答作成/送付」工程を「回答作成」とし、ここでは回答を作成するだけで送付はしません。

「回答作成」工程が終えられると仕事のボールは「回答チェック」工程に届きます。

「回答チェック」工程では、”回答チェック担当” が回答文について誤字脱字がないか、不適切な表現がないか、内容に誤りがないか、などをチェックし、問題がなければ（OK）、仕事のボールは「回答送付」に届きます。もし、「回答チェック」工程で回答文に問題があると判断された場合（NG）は、再び「回答作成」に仕事のボールが戻ります。

チェック工程を配置し、作成された回答文が必ずチェックされるようにすることで、ミスが混入した回答文を送付してしまう、というリスクを小さくすることができます。

しかし、「チェック工程」を配置する価値は、単にこのようなリスクを下げるだけにとどまりません。

作成された回答文が 80 点という合格点であっても、これを 90 点にするアイデアをチェック担当者が持っている場合があります。このような時、「チェック工程」でそのアイデアをまとめてから差し戻すことで、回答作成担当者は更に良い 90 点の回答文を作成することができます。

「チェック工程」が置かれたおかげで、リスクの低減に加え、品質の向上も期待することができます。

賢明な皆様は既にお気づきかもですが、作成担当者への教育・指導の機会を創出することにもなっています。

まとめ

特に小さな組織では、チェックしてくれる人がいないままに仕事が進んでしまうことがあります。このような業務フローでは、成果物を提出する前に、その成果物をチェックする「チェック」工程を配置することで次のような効果が生まれます。

• ミスの混入などのリスクを下げることができる
• アウトプットの品質を向上させることができる
• 教育・指導の機会を創出することができる

誰もチェックしてくれないワークフローは意外と多くの場面で遭遇します。チェックするコストとのバランスも考慮する必要がありますが、本記事で述べた効果を期待して、是非、チェック工程を配置する改善を試みてください。

「チェック」工程を置けば良い、ということに気づくためにも、最初に示した問い合わせ対応業務のワークフロー図のように、現状をワークフロー図に書いて見ることが大切です。私（矢作）の会社（クエステトラ）ではワークフロー図を書くことができるサービス（クラウド型ワークフローシステム「Questetra BPM Suite」）を提供しています（宣伝です）。

ワークフロー図を書いてみよう！と思った方は、是非、クラウド型ワークフロー「Questetra BPM Suite」をお申し込みください（60日間無料お試しあり）。

今回はここまで！

こんにちは！矢作です！

ありがたいことに、我が社（クエステトラ社）に業務改善の相談をお客様からたくさんいただきます。

その相談の中で、多くのワークフロー（業務フロー、ビジネスプロセス）を目にするのですが、その中には「こんなワークフローはイヤだ！」と叫んでしまいそうになるものがあります。

本記事では、そんな叫びをしてしまいそうになるワークフローの一つである「差し戻しができないワークフロー」について、その課題や改善のアイデアを考えたいと思います。

差し戻しができないワークフロー

題材として「求人Webページ制作」業務を考えます。これは、例えばアルバイトなどの求人情報を掲載するサイトを運営する会社の業務で、居酒屋などのクライアントから依頼を受けて、求人情報をWebページに仕上げる業務です。

1. 制作担当者が Web ページを制作する
2. チェック担当者が Web ページのデザインをチェックする（見た目、誤字脱字、表現）
3. 法律チェック担当者が、法律視点でチェックする（不適切な表現がないか）

このワークフロー図では、チェック担当者が Web ページを確認したときに、誤字などの修正すべき事項を発見しても、制作担当者に差し戻すことができません。ミスに気づいてしまったチェック担当者が泣く泣く対応するか、見て見ぬふりをするか、というイマイチな処置にならざるを得ません。

こんなワークフローはイヤですよね^^

差し戻しできるようにすればいいじゃない！

では「差し戻しできるようにしよう！」

このようなワークフローの改善アイデアとして、次の2つが考えられます。

• パターンA：上流の工程に戻すフロー（矢印）を引く
• パターンB：差し戻しに対応するための工程を作り、そこに導くフロー（矢印）を引く

前者は珍しいアイデアではありませんが、後者は少し理解しづらいかもしれません。それぞれ詳しく見ていきます。

パターンA：上流の工程に戻すフローを引く

誰もが最初に思いつくシンプルなパターンです。「制作」→「チェック」という流れで来たものを、「チェック」→「制作」という流れで差し戻します。

このような流れを作ることにより、チェック担当者は「チェック」工程でミスなどを発見した場合に、指摘事項を添えて「制作」工程に差し戻すことができるようになります。制作担当者は、チェック担当者の指摘事項を確認の上、自分が制作したものを改良して「制作」工程を終えます。

この差し戻しの流れがあることで、制作担当者に自分の成果物（Webページ）に改良するべきことがあったことを知らせることができます。指摘の内容によっては制作担当者に対する教育を行うことができます。

パターンB：差し戻しに対応するための工程を作る

「制作」→「チェック」という流れで来たものを、「制作」に戻さず、別途用意された「差し戻し対応」に流すというものです。

これも前節「パターンA：上流の工程に戻すフローを引く」と同じように、チェック担当は気づきを指摘事項として制作担当に伝えることができます。しかし、こちらのパターンBはパターンAよりも優れている点があります。

それは、「差し戻し対応」中であることが明確になるということです。”仕事のボール”（以下、ボールと呼びます）が「差し戻し対応」にあるとき、それは「制作」中ではなく間違いなく「差し戻し対応」中である、ということです。

当たり前じゃないか、という言葉が聞こえてきそうですが、パターン A の場合は「制作」にボールがあるとき、1回目の「制作」なのか、「チェック」工程で差し戻されたあと、つまり2回目以降の「制作」なのか、が区別できません。

ワークフロー図を書いただけでは、この違いはあまり価値を発揮しないかもしれません。しかし、書いたワークフロー図通りに仕事を進め、現在の仕事の状況を見えるようにして運用するレベルになると、今この瞬間、「制作」中のものが多いのか、「差し戻し対応」中のものが多いのか、一目瞭然になります。

この見えてきた状況を踏まえて、人の配置を変えたり、対応する仕事の優先度を変えたり、より大きな成果を上げるための施策を打つことができるようになります。

”仕事のボール” という言葉を特に説明せずに使いましたが、なんとなく分かりますよね！？

まとめ

差し戻しができないワークフローはイヤだ！ということで書き始めた記事ですが、差し戻しの方法には大きく2つのパターンが考えられることを説明しました。

• パターンA：上流の工程に戻すフロー（矢印）を引く
• パターンB：差し戻しに対応するための工程を作り、そこに導くフロー（矢印）を引く

通常、パターンAについては、誰でも思いつく方法ですが、パターンBの方法が存在し、私たちのお客様の多くで利用されている方法です。こんな差し戻しパターンが存在することを頭の片隅においていただき、今後のワークフロー改善の参考にしていただけると嬉しいです。

ちなみに、自社のサービス紹介で恐縮ですが、ワークフロー図を書くことができるサービス（クラウド型ワークフロー「Questetra BPM Suite」）を提供しています。６０日間、無料でワークフロー図を書くことができるTrialモードもございます。

興味がある人はお申し込みくださいませ。

今回はここまで！

参考：[マニュアル] M401: 申請と差戻対応の工程を分け “手戻り” をモニタリングしやすいように設定する