カエル塾

カエル塾

仕事を見える化し、
継続的に改善する方法を学ぶ

  1. TOP
  2. カエル塾
  3. コラム
  4. 業務フロー記述ガイドライン “揃えたい5つのポイント”

業務フロー記述ガイドライン “揃えたい5つのポイント”

  • LINEで送る
  • このエントリーをはてなブックマークに追加
業務フロー記述ガイドライン “揃えたい5つのポイント”

業務フローの書き方はツールでもアシストできない部分が多く、人によってバラバラになりがちです。揃えたい5つのポイントをご紹介します。業務フロー記述ガイドラインの雛形としてご利用下さい。

書き方のガイドラインを設ける理由

業務フローを自分のために作り、自分しか見ないのであれば気にすることもありませんが、チームとして共有し、メンテナンスしてゆく場合、書きっぷりについてはチーム内で揃えておく方が良いでしょう。書き方に個性を発揮してしまうと、他の方は手を出しずらくなりますし、時間が経つにつれて作者の意図がわからなくなり、他の方に引き継ぐことが難しくなります。将来にわたり鮮度を保ち、多くの人が日々活用する”活きた業務フロー”とするために、チームとしての「記述ガイドライン」を設けることをお勧めします。本稿では、その雛形をご紹介致します。業務フローを書き慣れた方にとっては”当たり前”のことばかりかもしれませんが、初めて書く方にとってはそうではないこともあります。業務プロセス管理の推進者は、メンバーのスキル底上げのためにも、以下にご紹介するようなTipsを明文化しておくことが重要です。

さて、本稿では業務フローを作成するツールや、記述ノーテーション (BPMN、フローチャート、EPC等の記法) には依存しないようにポイントを挙げてゆきますが、説明の都合上、「役割別のレーン」を持ち「時間軸は上から下へ進む」ような縦書きの業務フローを例にとってご説明します。横書きの場合は「上から下」を「左から右へ」と読み替えて下さい。

 

5つのポイント

レーンの並べ方は依頼元から依頼先へ

役割別レーンの並べ方は、業務フローの主人公から見て、左側に仕事の依頼元、右側に依頼先を並べるようにします。また、主人公と直接的なやり取りをする相手は主人公の近くに、間接的な相手は遠くになるように配置します。一般企業における営業プロセスを例に取ると、主人公は「営業担当者」です。レーンの並びは「顧客」(依頼元)→「営業担当者」(主人公) →「営業上長」(依頼先1: 上司) →「事業部担当者」(依頼先2: 関係部署) →・・・ という順になることが典型的です。「お客様を一番左に置いて、そこから近い順」と言っても構いませんが、企業にはお客様から遠い部署もありますので「依頼元から依頼先へ」と覚えましょう。このルールに沿ってレーンを配置した場合、業務フローは一般的に、左上から始まり、徐々に右下へ広がり、最後には依頼元へ戻ってくるといったルートを描きます。業務の複雑さは、レーンの多さ、レーンを跨って行ったり来たりする線の多さとして現れます。

image-20200802-060040-1024x461.png

 

時間の流れは上から下へ

時間の流れは上から下です。当たり前のようですが、レーンを跨がる時に矢印が上に戻るような配置をしてしまう方が意外と多いのです。業務フローのスペースを節約しようとする心理が働いてしまうのでしょう。業務ステップがA→B→Cとあった時、Bの位置はAよりも下、Cの位置はBよりも下にします。Aの後、BとCが並列となる場合は、BとCの縦位置を揃えるようにします。業務フローの縦軸は時間軸を表していることを意識し、同時に始まる業務は横一線で合わせるよう心がけて下さい。また、矢印 (接続線) は業務シンボルの下から開始し、次の業務の上に刺すようにして下さい。業務シンボルの横から矢印を開始したり、横に刺したりするのも、スペース節約の心理だと思われますが、縦軸は時間軸であるという原則に照らすと、横から出入りするということは、その業務の途中でやり取りがあるのか?という誤解を生みます。Aの完了後にBが開始されるなら、接続線はAの下部からBの上部に引いて下さい。

蛇足ですが業務フローのスペースを節約しようとする心理は、印刷した時の紙のサイズに納まるようにしたいという理由だと思われますが、業務を紙のサイズに合わせるとは、馬鹿げた話です。紙のサイズに合わせようとすれば業務フローの粒度感がページ毎にバラバラになることは必然。フローを書くことが目的化してしまった内部統制 (J-Sox) という制度による弊害かもしれません。改善活動を回すための業務フローとするのであれば、紙のサイズは忘れて下さい。このご時世ですので印刷するのも止めましょう。筆者もプレゼン向けのポンチ絵を書くことはあります。その時はパワポのページサイズに収まるように描きます。ポンチ絵と (本稿で管理対象とする) 業務フローは目的が違いますので区別して下さい。

 

シンボルはデフォルトのまま使う

業務フロー上で特定の箇所を強調したくなる心理もよく分かります。業務フローレビュー時に確認したいポイントや、当該プロジェクトで変更しようとする業務を、他の箇所とは区別したいということですね。しかし、出来るだけ業務フローを構成するシンボルの大きさ・形は変えないで下さい。区別したいなら、別の表現方法で行いましょう。ツールによっては、自由に丸や四角の図形を配置できると思いますので、強調したい部分は赤い四角で囲むなどのルールを決めましょう。区別する理由がなくなった時点で、その表記を消せば済むようにしておくことがコツです。シンボルの大きさや形を変えると、それを戻す時に業務フロー自体の形を整形し直さなければならなくなります。その修正が面倒になり (またはそのための工数が捻出できず) 強調されたままの姿が残ってしまいます。

 

業務ステップはハンドオフの単位で切る

業務フローにおける業務の1ステップの粒度 (粗さ/細かさ) は、”ハンドオフの単位” で描きます。ハンドオフ(Hand off)とは、手渡しするという意味の英語です。仕事は前工程からの依頼を受けて、何かの作業を行い、次の工程にそのバトンを渡すという行為の連続です。このバトンをもらってから次の人に渡すまでを業務の一単位としましょう、という事です。この基準はGlobalに通用するものです。日本BPM協会のトレーニングコースでもそのように教えています。ハンドオフで切る理由や効果については別のブログでご紹介していますので、そちらをご参照下さい。

カエル塾: 業務フローの粒度感
https://lp.ranabase.com/kaerujuku/column/granuarity

 

用語を揃える

ここまでは業務フローに配置するレーンやシンボルの配置に関する”見た目”のルールをご紹介して来ました。以上4つのポイントが揃っていれば中身の文字を読まなくても、この業務は「長いね」とか「複雑だね」ということがザックりと比較できるようになります。それだけでも価値がありますね。さて、最後は中身の言葉使いについてです。各シンボルに与える名称は下表に示す通り命名規則を決めて揃えて下さい。この業務フローを参照して業務改善の施策が検討されたり、システムの要求仕様書が作られたりします。業務フローを描く時は今後の社内用語を再定義するのだという気持ちで、丁寧に用語を選びましょう。始めから100点を目指す必要はありません。業務フローを整備してゆく過程で、用語の乱れに気づき、再定義の方針をチーム内で議論すれば良いのです。業務用語を統一してゆくことも業務フローを整備する目的の一つと捉えて下さい。

業務の命名規則については、”見積申請起案”のような名詞形とするケースと、”見積申請を起案する”のようなフレーズにするケースで、世間は半々に分かれているようです。筆者は業務上の行為がより明確になる後者をお勧めしています。名詞形で大雑把な名称を付けてしまうと、具体的にどの行為が含まれているのかが曖昧になってしまうためです。

シンボル 命名規則 例 / 補足
業務 [対象] [行為]
または
[対象]を[行為]する
[見積申請] [起案]
[見積申請]を[起案]する
イベント [対象]を[行為]した
または
[対象]が[行為]された
[見積申請]を[受領]した
[見積申請]が[承認]された
その他
(データ、情報、帳票、システム、画面、業務ルールなど)
名詞 ・用語規定があればそれに従う
・システム、画面などはIT部門が管理する正式名称を使う
・業務ルールには規程があるはずなので、その正式名称を使う

 

より詳細なガイドラインを無償でお配りしています

ツールや記述ノーテーションに依存しないような解説を試みましたが、少々抽象的になってしまいますね。実用的なガイドラインとしては、皆さんがお使いのツールやノーテーションを踏まえて、より具体的に示し、セルフチェックシート等も用意しておくと良いと思います。

当社が運営している業務改善ツール Ranabase (ラーナベース) では、業務フローを作成・管理する機能を提供するだけでなく、本稿でご紹介したような業務可視化ノウハウを自習できる教育コンテンツを揃え、サポートサイトから公開しています。こちらの内容はRanabaseの利用を前提として、より具体的に書かれていますので、是非下記リンクからお申し込みの上でご参照下さい。

 

Ranabaseの利用を前提とする業務フロー記述ガイドラインはこちら (下記バナーをクリックして下さい)

執筆者情報:

冨樫 勝彦 (Togashi, Yoshihiko)

1972年生まれ 株式会社ユニリタ クラウドサービス事業本部 ビジネスイノベーション部 部長。Ranabaseプロダクトオーナー。大学卒業後ERP導入に従事、2000年にBPM(ビジネスプロセスマネジメント)のコンサルティングに転向し、国内へのBPM普及展開を推進。2019年からBPMツールの自社開発に着手、"BPMで日本を元気に!" をモットーとして、コンサルに頼らず組織が自ら継続的に業務プロセスを改善してゆくための方法論やノウハウをRanabaseのサービスに込め、BPM市場の裾野を広げる活動を続けています。

 

  • LINEで送る
  • このエントリーをはてなブックマークに追加

サービスを
利用してみる

30日間無料で、スケッチ(図)を無制限で作成できる
「パーソナルプラン」をご利用いただけます。
この機会に、Ranabase(ラーナベース)で継続的な業務改善を始めてみませんか?

サービス紹介やお役立ち資料を無料でご活用いただけます