0. 事前の準備

業務プロセスを設計（定義）する際、事前にどんな準備が必要なのでしょうか？

• 業務プロセスの目的
• 業務プロセスのオーナー
• 業務プロセスの関与者
• 業務プロセスをシステム化する目的
• 業務システムに是非とも欲しい機能
• 業務システムの稼働スケジュール
• などなど……

たしかに世の中、どんな Plan（企画）も「事前の準備」は大切です。

しかし、、、 “業務プロセス” を設計する際、事前にアレコレ深く考える、、、はオススメしません。たとえば “例外ケース” や “エラーケース” といった枝葉末節を列挙しはじめるとキリがないのです。気が付けば「誰も読まない分厚いマニュアル」を作ってしまいかねません。何より “メインフローを検討する時間” が減ってしまいます。

筆者自身は「むしろ深く考えないほうがイイ」、「”インプット” と “アウトプット” だけを決めて、さっさとモデリングを始めるべきだ」と考えています。

• 業務プロセスのインプット（≒トリガー）
• 業務プロセスのアウトプット（≒成果物）

なお、この2つ、”インプット” と “アウトプット” については、何時間でも、何日でも、「確信が持てる」まで、深く深く考察すべきだと考えています。（←散歩しながら考えるのが好きです。）　言い換えれば、、、もし「確信が持てない」ようであれば “業務プロセス定義” に着手すべきではない、、、と考えています。”インプット” と “アウトプット” の想定なく、業務プロセスの設計を始めると「ロクな結果」にならないのです。（ただの経験則ですが…）

と、偉そうなことを書いていますが…、 業務プロセス設計の途中で “インプット” と “アウトプット” を変更してしまいたくなる事は、マレにあります。特に、寝て起きて、リフレッシュした頭で「設計途中の業務プロセス」を見返したときに、「うっ…コレ…チガウ…」と思ってしまうのです。まぁ、カンペキだと思っていた業務プロセス定義も「諸行無常」（←この世のものはたえまなく変化し続けてしまう）なのでしょう。あるいは「スキー場の恋愛」（←ゲレンデで見かけた異性は3割増しでステキに見えてしまう）みたいなものなのかも知れません。なので、日々のレクチャー活動や大学での講義では、「最初の10本は駄作しかできないと覚悟しておいてください」とクギを指すようにしています。

1. 業務プロセスの命名

“ワークフローアプリ” を［新規作成］し、業務プロセス定義に着手します。そして “アプリ名” を付けます。

業務プロセスの名前（”ワークフローアプリ” の名前）としては、『アウトプット』（≒成果物）を印象付けるネーミングがオススメです。

たとえばこの設計動画では、『社内報メール送信プロセス』と命名されています。こういった業務プロセス定義名にしておけば、他部署メンバが見ても、新入社員が見ても、誰が見ても、業務プロセスの目的（ゴール）をイメージできます。（社内報がメールで送信される業務プロセスだ！）

ネーミングは、とても大切です。何より業務プロセス定義の “長大化” を防ぎます。絵画や建築で言えば “ラフ・スケッチ”（下絵）みたいなものだと思っています。プログラミングで言えば “関数名と引数と戻り値” みたいなものでしょう。いずれにせよ、とても大切です。”業務スコープ” や “プロジェクト・スコープ” を表しているといっても過言ではありません。

2. 処理者の検討

続いて、業務プロセスの “登場人物” について考察します。（”スイムレーン” と呼ばれるハコを配置します）

この設計動画のようにシンプルなワークフローの場合は悩むことなく設定できるでしょう。基本的には『申請者』や『申請者の上司』のように “相対的に設定” するのがオススメです。ポイントは「業務上のロール名」で設定している点です。

しかし、この “相対的に設定” がアダになって混乱を招いてしまうケースがあります。たとえば、「メンバの申請」と「課長の申請」で経路が異なる業務プロセスでは「『申請者の上司』って誰だ？」といった無駄な停滞を招く場合があります。そのようなケースでは、『メンバ』や『課長』や『部長』といった「組織上のロール名」で “絶対的に設定” するのがオススメです。

ちなみに、組織を横断するワークフロー（組織横断型の業務プロセス）などでは、単に『管理部』や『マーケティング部』といった「組織名」を指定すれば足りる場合もあります。

ごく稀に「どんな人が処理するのか？」（≒「どんなヒューマン工程があるのか？」）が完璧に列挙できないケースがあります。そのような場合は、”主要な登場人物” だけを設定すれば良いと思います。なお、”相対的に設定” と “絶対的に設定” を、あえて両方使うことによってエレガントにまとめられる業務プロセスもあります。たとえば、「複数の入力フローに対しての差戻工程を一元化する」といったケースが該当します。が、”最初の10本” では、そのような機会に遭遇しません。

3. 先頭工程の設定

業務プロセスの “先頭工程” を配置します。

この設計動画で言えば『1.申請する』です。非常にシンプルなヒューマン工程です。「業務プロセスのインプット（≒トリガー）」となります。コレは、あらかじめ “0.事前の準備” で考えていたことになります。

先頭工程が『1.申請する』となるワークフローは多く存在します。ワークフローシステムによっては『申請』『承認』『決裁』『確認』の流れが固定化されます。しかし現実世界の業務プロセスは『（見積書の）草稿を作成する』や『（アクセス集計の）CSVをアップロードする』など様々です。あるいは『Webオーダー』や『異常検知メール』といった外部トリガーも少なくありません。

4. 途中工程の検討

業務プロセスに必要な工程を配置します。

この設計動画で言えば『2.承認する』や『1x.修正して再申請する』です。いずれもシンプルなヒューマン工程です。

オススメは工程名に数字を付けることです。つまり、上流工程から順に “若い番号” を付けておくことで、ワークフロー図の可読性が高まります。

ちなみに、「途中で経路を分岐させる必要がある業務プロセス」は少なくありません。

• A. ゲートウェイ分岐：
  • ワークフローエンジンに案件内データを参照させて、経路を選択させる
• B. 処理者による分岐：
  • 処理者に『取り下げる』『再申請する』といった “経路ボタン” を選択させる
  • （デフォルトの『処理完了』ボタンは表示されない）

そもそも “フロー分岐” （複数経路から一つを選択）には大きく2つの考え方がありますが、基本的には「B.処理者による分岐」がオススメです。理由は簡単で、処理者が業務プロセスの「流れ」を意識するようになるからです。

しかし、中には「処理者が “業務プロセス全体” を俯瞰することに意味がない工程」もあります。たとえば、「ヒタスラに『翻訳する』の工程を処理するヒト」を想像してください。その場合、翻訳者に “複数経路” を意識させる意味がありません。そのようなケースでは「A.ゲートウェイ分岐」がオススメです。

「小さく始める」（と「継続的な改善」）はコンサルタント達が好んで使うフレーズです。しかし “小さい” という表現はクセモノです。つまり「小さいかどうか？」の判断は人によって大きく異なります。筆者に言わせれば、ヒューマン工程の数が “5” を下回るなら「小さい」と言えます。そして “10” を超えるようなら「大きい」です。そうなるとカイゼンが大変です。もし “20” や “30” を超えるような業務プロセス定義になりそうなら、”定義” する前に “分割” を検討してください。

5. イベントの検討

業務プロセスの途中に必要な “イベント” や “自動処理” を配置します。

業務プロセスにおける “イベント” とは「ワークフローエンジン自身に対処させる “アクション”」のことです。 “小さな工程” といっても良いかも知れません。具体的には『一定時間待機する／指定時刻まで待機する』（タイマーイベント）や『通知メールを送信する』（メールイベント）などがあります。

この設計動画では『タイマー中間イベント』と『メール送信イベント』が配置されています。もちろん、ヒューマン工程として『3.メールを送信する』を設計配置しても良いのですが、この例ではワークフローエンジン自身に『指定時刻にメールを送信する』を実現させる定義になっています。

“ヒューマン工程” を減らして “イベント” や “自動処理” で処理させることを、特に「処理の自動化」と呼びます。初期のワークフローエンジンは「経路に従って業務データを受け渡ししてくれる存在」（≒「受け渡しの自動化」を実現するソフト）だったのですが、近年では人間に変わって様々な処理を担ってくれる存在となっています。つまり、業務プロセス全体で見れば「ミスやヌケモレの撲滅」や「人間負担の軽減」が容易に実現できるようになっています。（サーバサイド処理）

6. 業務データの考察

業務プロセスに必要な “データ項目” を検討します。

もし「すでに紙で業務データを受け渡ししている」や「すでに決まったフォーマットのメールで業務データを受け渡ししている」という業務なら、それらを活用（参照）して定義すべきです。

すべての業務データを “文字型データ” として定義してしまっても構いません。しかし、様々な “自動化” を（将来に渡って）実現するためにも、”数値型データ”、”日付型データ”、”日時型データ”、”選択型データ” など、それぞれの業務データの特性に合わせて細かく定義することをオススメします。

なお、ファイルを添付したい業務には “ファイル型” というデータを用意します。『請求書PDF』『ラフデザイン』『工事現場の写真』など、様々な業務プロセスが想定されます。なお、あえて『ファイルサーバのURL』という “文字型データ” で受け渡しするケースもありますが、利便性を考えると基本的には “ファイル型データ” の方が有用です。もっとも、機微なファイルで「アクセス履歴を押さえたい」や「さらに細かく閲覧権限を制御したい」といったニーズがあれば、その限りではありません。

意外と大切なことは、業務上の「注意事項」や「ヒント」あるいは「入力例」をセットで考察しておくことです。それぞれの “データ項目” の枠外に記載したり、表示専用の “ガイドパネル” にまとめて記載したりします。

実はこの「注意事項」ですが、業務プロセス定義の作業において最も時間を要してしまいます。

もちろんワークフローシステム（ワークフローエンジン）の視点では「あっても無くても構わないモノ」なのですが、「人間による入力ミスを減らすため」にはどうしても不可欠です。もし、入力値に誤りがある案件が流されると、それ以降の下流工程にムダな作業を強いることになってしまうからです。

プロセスオーナーは「入力値にミスがある案件」の発生率に、常に注意をはらうべきです。いわゆる「手戻り」の発生は組織として大きな損失になります。加えて、処理者たちのモチベーション低下を招きます。もし発生率が5%を超えるようであれば「システム化する価値」すら疑問です。もちろん「”ゴミ案件” 流すな！」「”ドロ団子” 流すな！」のような啓蒙も有効ですが、基本的には、分かりやすい「注意事項」や「ヒント」あるいは「入力例」を記載しておくことが大切です。「業務プロセスを憎んでヒトを憎まず」の精神で（！？！）、業務プロセスを改善し続ける必要があると考えています。

7. パーミッションの考察

業務プロセスに流されるデータの “パーミッション” を検討します。

すなわち、それぞれの工程について

• どのデータを参照できるか？ （Read権限）
• どのデータを更新できるか？ （Read/Write権限）
• 閲覧できないデータは何か？ （その存在すら気づかない）

を検討します。

もちろん全ての工程の設定で、全てのデータを「更新できる」としても構いません。「ワークフローシステムとして運用できなくなくはない」と思います。しかし、業務案件をスムーズに流すためには「処理しやすいパーミッション設定」について検討する必要があります。

ここでは処理者視点での「読み書き権限」（Read/Write権限）について記載しています。別途、モニタリング視点での「参照権限」（Read権限）も検討する必要があると言えます。一般論的には、役員や管理職者だけでなく、他部署へも広く「参照権限」（Read権限）を付与しておくことで、部署間のコミュニケーションコストを下げることができます。

8. 処理者についての考察

ヒューマン工程の “処理者” を規定します。

ここで大切なコトは「ワークフローエンジンが理解できるように規定すること」です。つまり “2.処理者の検討” では、”登場人物” について名前を付けただけでしたが、ここではワークフロー基盤の『ユーザ』（や『組織』や『ロール』）をセットします。

“処理者” が1人だけ設定された場合（例：ユーザ “Suzuki”）、流れてきた仕事は、自動的に当該ユーザに［割り当て］られます。しかし複数人が設定されている場合（例：組織 “営業部” の所属者全員）は、そのユーザ達の誰かが引き受ける必要があります。ワークフローエンジンは彼らを “処理候補者” とみなして［引き受け］を促すことになります。

9. ワークフローシステムとして稼働

設計した業務プロセスを、ワークフローシステムとして稼働させます。

この動画にあるように『開発中のバージョン1のリリース』をクリックするだけで、ワークフローシステムとして稼働します。すなわち “先頭工程” から新しい案件を流せるようになります。

※この動画でモデリングされた業務プロセスをダウンロードしたい場合はこちらから。

10. そして改善サイクルへ

昨今「テレワークで停滞する業務を円滑化したい」という声をよく見聞きするようになりました。

このフレーズ自体はたしかに「バックリとしたニーズ」なのですが、つまるところ「あるべき業務の進め方」（To-Beプロセス）が大きく変化しているのだと思います。プロセスオーナーとしては、現状（As-Isプロセス）にとらわれず、勇気をもって、「積極的な改変」に挑戦していきたいものです。

みなさんも、是非、ワークフローシステムを改善し続けてください。No-Code で！！