1. トップ
  2. フローチャートとは

フローチャートとは

フローチャートにも様々な表記法がありますが、業務改善やDX推進のために初めて業務の可視化に挑もうとする皆様に
ご推奨したい表記法とそのメリットを
ご紹介させて頂きます。

フローチャートとは

物事の進め方や判断基準が複雑な場合、これを文字だけで表そうとすると正確に伝わらないことがあります。このような場合「行動」や「判断」を1ステップ毎に図形化し、流れ図として表すことがあります。これをフローチャートといいます。組み立て式の家具や家電製品の初期セットアップのマニュアルを読むと、1. 同梱物の確認、2. 道具の準備 (〇〇を既にお持ちの方は3へ)… などと、進め方や判断基準が構造的に説明されます。これらもフローチャートの一種といえます。

フローチャートの歴史

フローチャートの起源は、1920年代 ASME(アメリカ機械工学会)の会員であったFrank and Lillian Gilbreth (ギルブレス夫妻)が考案した、作業員の仕事の流れを構造的に文書化する技法であったと言われます。この表記法はGilbrethさんの氏名を逆さにして”Therbligs”と呼ばれたそうです。注目すべきは、その当時からフローチャートを描く目的は、プロセスの無理や無駄を見つけ、生産性の向上を目指すことだという事。生産の現場では、プロセスは互いに密接に関連しあっているので、一箇所を変えると他のいろいろな箇所に影響が及びます。だから全体をグラフィカルに可視化し、みんなが理解できるようにしなければならないと。

その後、プロセスの可視化技法は生産工学の分野から、コンピュータ工学や経営の分野にも拡がり、皆さんも一度は見たことがあるであろうフローチャートの代表的なシンボルが固まってゆきました。

フローチャートの記号

初期のフローチャートの記号は下図のようなシンプルなものでした。行動や処理(Processing)は長方形、処理に対する情報のインプット/アウトプットは平行四辺形、判断(Decision)には菱形、そしてプロセスの開始や終了(Termination)は長円で表し、互いに接続線で結びます。これだけでも十分に処理のロジックやアルゴリズムを表現することができます。フローチャートツールが手元にない時や、紙や白板に手書きする時に、この4種類を適切に使えるとカッコ良いので是非覚えておいてください。

フローチャートの記号

手書きフローチャートのサンプル

手書きフローチャートのサンプル

フローチャートの種類

前述の通りフローチャートには約100年の歴史があり、さまざまな用途・目的別にさまざまな表記法が生み出されてきました。これから自社の業務プロセスの可視化と改善に挑もうとする皆様にとってどの表記法に乗るのが良いかという観点から、代表的な表記法を紹介させて頂きます。

1) 情報処理系

日本工業規格(JISX0121)

日本でフォーマルなフローチャートの書き方といえば唯一、このJIS規格が該当します。但し、用途は”情報処理用流れ図”、”プログラム網図”、”システム資源図”とされており、人の業務プロセスを描くための表記法ではありません。

データフロー図 (Data Flow Diagram, DFD)

データがファンクションを起動し、ファンクションがデータを生み出す。このデータがまた次のファンクションを起動する…というようにデータとファンクションを数珠繋ぎにしてプロセスを表す表記法です。システム設計のシーンではお馴染みですが、基本的にはデータに焦点が当てられており、データに影響を与えない人間のプロセスや、そのプロセスが起動されるタイミング等が表現できないため、こちらも業務プロセスを描くには不十分です。

2) 株式公開・内部統制向け

NOMA方式

日本経営協会 (NOMA) の理事であった、三枝鐘介氏によって考案された表記法。事務プロセスを表記する目的に特化し、比較的シンプルであることが特徴。

産能大式

学校法人産業能率大学によって考案された表記法。”FAX”、”郵便”など、事務プロセスに登場する手段/設備を表す記号が用意され、実情をより具体的に表現できることが特徴。

いずれも企業の株式公開や内部統制対応に必要とされる業務フローの表記法として国内に広く普及しましたが、日本国内でしか認知されていない事、帳票の転記・捺印・保管など紙文化を前提とした記号が多数用意されているが、これを使いこなさないとあまり価値がないことなどから、デジタル化を目指して業務改善を行おうとする現代において、今更覚える必要のあるものではないかと思われます。

3) 最新のグローバルスタンダード

BPMN (Business Process Modeling Notation)

数ある業務フロー表記法を統一することを目的にアメリカのBusiness Process Management Initiative (BPMI) が開発、標準化団体であるOMG (Object Management Group) が保守している表記法。2013年に国際規格 ISO/IEC 19510:2013になりました。BPMNで表記されたフローはXML形式のファイルにダウンロードし、ツール間の受け渡しが可能です。描いた業務フローがコード化(プログラム言語化)されるということは、その構造を機械的に比較分析したり、ITの実装にシームレスに繋ぐことができる等の夢に近づきます。完全性にかけてはこれまでにない、素晴らしい表記法だと言えます。

一方で、IT実装に連携できるよう正しく表記するには一定の習熟が必要です。BPMNを元にしたワークフロー実装ツールは高価ですし、顧客が自分でBPMNを描けないことにつけ込んで、教育や代筆で儲けようとする風潮もあり、早急に飛びつくのは注意が必要です。BPMNで描きましたという業務フローをお客様に見せて頂くと、長方形が線で繋いであるだけの絵をよくお見かけしますが、それでは前述の100年前のフローチャートの方が情報量は多いということになり、BPMNを活かしているとは言えません

4) 業務部門の方が業務改善のために自分で描くならこれ

EPC図 (Event driven process chain diagram)

1980年代にドイツで考案され欧州を中心に広まった表記法。ERPで有名なSAPの普及期に、そのリファレンスモデルを表記するために使われていたため、古いSAPユーザーはご存知かもしれません。業務部門の方が純粋に業務プロセスを表記し、課題を議論することに特化しています。使う記号の種類が少なく、BPMNのようにIT知識を前提としないことが特徴です。

EPC図のイメージ (RanabaseではEPCを採用しています)

EPC図のイメージ (RanabaseではEPCを採用しています)

Ranabaseにおけるフローチャート記号の凡例:

https://lp.ranabase.com/support/online-m/legend.html

上図の通り、役割はレーンで区別し、時間軸は上から下に流れます。四角形の箱が「業務ステップ」、六角形の箱が「イベント」と言い、業務ステップの開始条件を表します。業務を開始する条件を明確に表記することが “Event driven process chain”という名の由来です。ITと違って人のプロセスは何をトリガーにして開始するのかが曖昧です。だからこそ、「あなたが思う開始条件を書きなさい」という所がミソになります。曖昧なのであれば、まずは「〇〇を開始すべきだと気づいた」と書きましょう。「それはどういう場合なのか?」と、改善の議論が自然に生まれてきます。また、EPCでは各業務ステップ毎に必ずインプットとアウトプットを書きなさいというルールになっています。「インプットやアウトプットがないとはどういうことか?」「それは仕事なんですか?」と、改善の議論が生まれます。

フローチャートの作り方

1枚のフローチャートを描く際には、まずそのスコープ(始点と終点)を考えます。そして、その始点から終点までの間に登場する人(役割)を想定してレーンを用意します。あとは業務ステップをラフに置いてゆきます。EPCの場合はさらにイベントを各業務ステップの間に置き、開始条件を記述し、線で繋いでゆきます。最後に、各業務ステップに対するインプット、アウトプットを記載します。

慣れた方でも上から下まで一発で書けることはまずありません。描いてみてから、足りないステップや分岐に気づいたり、異なるパターンがあることに気づいたりします。多少の手戻りは厭わず、記述/修正を繰り返しましょう。また、事実がどうなのかわからないという事も多いと思います。その場合は仮説/妄想で大胆に描いておき、現場を知っている方にレビューしてもらいましょう。フローチャートは一人で描いてしまっておくものではありません。社内のより多くの人に叩かれれば叩かれるほど、価値が上がってゆきます。

  • 1. 業務ステップと
    イベントの記述

  • 2. 分岐と合流の表現

  • 3. イン/アウトと
    利用システムの表現

業務プロセスの可視化と改善の進め方については、Ranabaseのサポートページ > オンラインマニュアル > 進め方(動画解説)で、より詳細に解説していますので是非ご覧ください。

Ranabaseオンラインマニュアル:

フローチャートの活用シーンとメリット

業務改善に際してフローチャートを描く目的は、大まかに分類すると1. 現状把握/課題抽出、2. To-Beの設計/システム導入、3. 実現されたTo-Beの運用/評価 にあると言えます。
いずれのシーンにおいてもフローチャートというビジュアルな可視化手段を使わないと、文字だけでは限界があり、誤解や抜け漏れが生まれてしまいます。フローチャートを活用するメリットをいくつか挙げてみましょう。

As-Isプロセスを可視化し、課題を洗い出す

・対象業務が明確に理解できるので、

  • 時系列に沿って考えることで網羅的な課題検討になる
  • 実行者の立場になった主観的な課題検討になる
  • 全体を俯瞰した客観的な課題検討にもなる
  • 情報の流れや伝達手段の観点からシステム上の課題も見つかる

・課題と業務プロセスの対応関係が明確なので、

  • 業務量や所要時間の観点から課題の重要度・優先度を評価できる

・課題がどのように導き出されたかが明確なので、

  • 納得感を得られやすい
  • 合意形成しやすい

To-Beプロセスに従ってシステムを設計・導入する

・新たな業務が明確に理解できるので、

  • 時系列に沿って考えることで網羅的な課題検討になる
  • 実行者の立場になった主観的な課題検討になる
  • 全体を俯瞰した客観的な課題検討にもなる
  • 情報の流れや伝達手段の観点からシステム上の課題も見つかる

・開発すべきIT機能と業務の関係性が明確なので、

  • 画面や帳票などの開発対象を抜け漏れなく洗い出せる
  • 同じIT機能が複数の業務に使われることが明示され、IT機能の共通化の検討になる
  • それらのIT機能が満たすべき業務要件を網羅的に確認できる
  • 総合テスト/受入検査時のテストケースを網羅的に洗い出せる

・As-IsとTo-Beの差分がわかるので、

  • 現場への説明がしやすい
  • 教育やマニュアル作成のスコープが特定できる
  • To-Be実現による効果を定量的に比較シミュレーションできる

実現されたTo-Beを運用・評価する

・業務フローが整備された状態で運用開始できることにより、

  • 現場の混乱を防止できる
  • 業務マニュアルの整備に繋がる
  • 教育や引き継ぎに使え、属人化を防止できる

・システム設計のドキュメント類を業務フローに対応付けて管理することにより、

  • システム運用担当者も業務を理解できる
  • 稼働後のシステムの改修時に影響範囲を特定しやすくなる
  • システムのブラックボックス化を防止できる

・プロセスの実行頻度や所要時間をシステムからデータ取得できるようにすれば、

  • フローチャートを設計図にしながら業務の改善効果が実測できるようになる
  • その後の継続的改善活動がデータに基づいて行えるようになる

フローチャートツール Ranabase

Ranabaseはフローチャートの表記法としては前述のEPCのみを採用しています。世間のその他のフローチャートツールはより多くの表記法を採用し、どれでもいいですよという汎用性を売りにしていますが、Ranabaseは敢えて一つに絞り、お客様が使い方に迷ったり、部署毎に異なる表記法を採用することを防ぎます。EPCはドイツ発祥ということもあり、ドイツ銀行、ドイツテレコム、ほぼ全てのドイツ車メーカー、シーメンス等に採用されていますので、どうかご安心を。

この表記法に乗って頂けるなら、Ranabaseは前述の活用シーンを想定し、それぞれのメリットを享受できるように各種機能を備えています。またツールだけではなく、これらのシーンにおけるフローチャートの作成方法や活用方法をマニュアルや教育コースとして発信しています。今後もアジャイル開発で機能強化を続けてゆく予定ですので、是非ご検討をお願い致します。

Ranabaseが役に立つ各種の活用シーン:

さらに詳しく知りたい方へ

サービスを
利用してみる

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

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