用語解説 – Glossary
プロセスマイニングに関する用語を簡潔に説明しています。
プロセス – Process
プロセスマイニングにおける、「プロセス」とは、明確な始まりの活動と終わりの活動がある一連の活動全体を意味します。
また、プロセスの始まりの活動と終わりの活動の間をつないでいる活動には、基本的には「望ましい業務手順」が存在します。ここで「望ましい手順」とは、価値を生まない無駄な手順がない、手戻りや繰り返しの活動がない、トータルリードタイムが最も短い、プロセス遂行に係るコストが最も小さい、とった条件に該当する手順です。
プロセスマイニングの分析対象となるプロセスは、明快な業務手順が存在し、個別の案件ごとに、ほぼ同じ手順が繰り返し実行される「定型業務」です。たとえば、経理部門で請求書を受けとってから支払いを行うまでの手順は明快であり、典型的な定型業務です。
こうした定型業務は、最終成果物は基本的に均質ですので、そこに至る手順をできるだけ標準化し、例外処理を減らすことが重要です。また効率（生産性）を追求することが求められます。したがって、プロセスマイニング分析を行う意義のあるプロセスだと言えます。
一方、企画書の作成プロセスは、課題の整理→情報収集→企画書内容検討→企画書作成といったおおまかな流れは存在するものの、明快な手順は存在せず、個人差も大きい「非定型業務」です。非定型業務は、最終的な成果物となるアウトプットの質が重要であり、そこに至るプロセスの標準化やリードタイムの短縮はさほど重要ではありません（そうしたことを目指すことが、創造性を阻害し、アウトプットのクオリティを低下させるリスクがあります）
したがって、非定型業務とみなせる業務プロセスは、プロセスマイニング分析を行う意義はあまり高くありません。
リードタイム – Lead time
リードタイムは日本語では「所要時間」と訳すことができます。プロセスマイニングでは、リードタイプは一般的にプロセスの開始から終了までの総所要時間を言います。この場合、「スループット」と同義になります。
同時に、リードタイムは、プロセスを構成する任意のアクティビティからアクティビティまでの時間を指すこともあります。例えば、「見積もり依頼」から「見積もり受領」までのリードタイムは？という言い方もできます。
したがって、プロセスの開始から終了までの総所要時間を意味する場合（＝スループット）は、「トータルリードタイム」と呼んで、アクティビティ間のリードタイムと区別したほうがいいでしょう。
スループット – Throughput
スループットは、製造業の生産部門でよく使われる表現で、リードタイムと同様、プロセスの始まりから終了までの総所要時間を指します。ただし、プロセスの任意のプロセスとプロセスの間の所要時間のことをスループットと呼ぶことは基本的にありません。ただし、ある活動のサービス時間と待ち時間の合計を「アクティビティスループット」と呼ぶ場合もあります。なお、基本的には「サイクルタイム」と同義です。
サイクルタイム – Cycle time
サイクルタイムは、あるプロセスの開始から終了までの所要時間を意味します。プロセス全体のリードタイム、あるいはプロセス全体のスループットと同義です。サイクルタイムは、常にプロセスの最初から最後までの所要時間のみを意味します。なお、基本的には「スループット」と同義です。
プロセスモデル – Process model
実際の業務プロセスの流れをフローチャートの形で表現したものをプロセスモデルと呼びます。イベントログからツールによって発見したプロセスは、「as isプロセスモデル」であり、BPMNなどの表記法に準拠して作成したあるべきプロセスは、「to beプロセスモデル」です。
現実をできるだけ忠実に再現したものが「モデル」ですが、理解のしやすさを優先して詳細手順を端折り、抽象度を上げることもあります。
コントロールフロー – Control flow
フローチャートの形でプロセスの流れを表したものを「コントロールフロー」と呼びます。プロセスマイニングやBPMの英語文献ではしばしばこの表現が使われますが、「プロセスモデル」とほぼ同義です。
実務では、コントロールフローは、プロセスを表現した「フローチャート」と同義とみなして問題ありません。
as isプロセス – As is process
イベントログから、プロセスマイニングツールにより描き出されたフローチャート、すなわち「プロセスモデル」が、現状を再現した「as isプロセス」です。プロセスマイニングによる分析の第一歩は、このas isプロセスを描画する「プロセス発見（Process Discovery」を行うことです。
プロセスマイニングツール上で、as isプロセスとto beプロセスを比較分析する作業は「適合性検査（Conformance Checking）」です。
to beプロセス – To be Process
マニュアルなどに定められた、あるべき手順を踏んだプロセスを表現したものが「to beプロセス」です。to beプロセスは通常、BPMN準拠のフローチャートをゼロから手作業で作成します。プロセスマイニング分析を開始するに当たって、to beプロセスが存在しない場合、社内で検討して理想手順を策定し、フローチャートを作成するか、あるいは、as isプロセスのバリアントの中から、「理想プロセス」と見なせるものを用いて、「to beプロセス」に昇格させる方法があります。
ハッピープロセス – Happy process
ハッピープロセスは、企業の業務プロセスの場合であれば、法令に遵守した、また社内ルールに則った正しい手順で行われており、かつスループット（総所要時間）が短く、非効率なプロセス、ボトルネック、繰り返し業務などが存在しない「理想的」なプロセスです。
プロセスマイニングにおいては、イベントログから発見されたas isプロセスの様々なバリエーション（バリアント）の中から、優れたものを「ハッピープロセス」として認定することが可能です。
あるいは、as isプロセスのバリエーションの中から、ハッピープロセスが見出せなかったとしても、ハッピープロセスに近いものがあれば、それをベースに加筆修正して「ハッピープロセス」を仕上げればいいのです。実は、これが「プロセス強化」のアプローチのひとつです。
プロセス発見 – Process discovery
プロセス発見は、プロセスマイニングの最も基本的なアプローチです。プロセスマイニングツールにおいても核となる機能であり、この機能を備えていないツールはプロセスマイニングツールでありません。
ITシステムから抽出したイベントログに基づいて、プロセスの流れを「見える化」するのがプロセス発見です。それまでブラックボックスだった業務が、フローチャートの形で手に取るように把握できるので「プロセス発見」と呼ばれます。
プロセスマイニングツールのアルゴリズムにより、イベントログから自動的にフローチャートを描くことができることから、「ABPD（Automated Business Process Discovery：地頭的なビジネスプロセス発見）」とも呼ばれます。
ABPD – Automated Business Process Discovery
Automated Business Process Discovery、すなわち、「自動的業務プロセス発見」は、Gartnerが名付けたもので、プロセスマイニングにおける「Process Discovery：プロセス発見」と同意です。
Gartnerが、プロセスマイニングを確立された市場として認識したのは、2018年に発行された「Market Guide for Process Mining 2018」であり、それ以前は、BPMの枠組みにおいてプロセスマイニングが語られていました。
具体的には、BPMにおける業務プロセス可視化のための従来の分析手法、インタビューやワークショップに基づく業務プロセス作成が、多大な負荷と手間がかかる割に主観的で断片的な情報しか得られず、信頼性の低いプロセスモデルしか描けなかったのに対し、イベントログデータに基づいて自動的に業務プロセスを可視化するプロセスマイニングの優位性がGartnerによって示されたのです。
適合性検査 – Conformance checking
適合性検査は、イベントログに基づいて発見された現実のプロセス、「as isプロセス」と、あるべきプロセスの流れを規定した理想プロセス、すなわち「to beプロセス」を比較し、to beプロセスを基準にして、現実のプロセスにおける逸脱をあぶり出すことです。
適合性検査は、プロセスマイニング の基本的なアプローチのひとつですが、プロセスマイニングツールの機能としては備えていないツールも存在します。
プロセス強化 – Process enhancement
プロセス強化は、イベントログからの現行プロセス、すなわち「as isプロセス」のみえる化によって浮き彫りになった、ボトルネックなどの様々な問題点や、理想プロセス、すなわち「to beプロセスとの比較分析を行う適合性検査によって明らかになった逸脱プロセスを是正し、より優れたプロセスを生み出すアプローチです。
運用サポート – Operational support
プロセスマイニングは、プロセス発見、すなわち過去の、完了済みプロセスのイベントログからas-isプロセスを把握することが出発点です。さらに、適合性検査やプロセス強化によって、新たな業務プロセスを定義し、新業務プロセスべーすでの運用を始めたら、その後は、着実に、逸脱なく、新業務プロセスが実行されているかを継続的にモニタリングすべきでしょう。
運用サポートでは、現在走っている「未完了のプロセス」のデータをプロセスマイニングツールにリアルタイムで流し込み、完了までの推定リードタイムを予測したり、逸脱した手順や過度の業務集中、ボトルネックの発生を捕捉し、関係者に通知、即時の是正を図るものです。
サービス時間 – Service time
サービス時間は、プロセスを構成する各活動（「請求内容登録」などシステム上の操作）に対する処理時間のことです。サービス時間は、イベントログに存在する各活動の開始時間、および終了時間の２つのタイムスタンプがあれば集計可能です。
サービス時間、すなわち各活動ごとの処理時間が算出できれば、業務処理の生産性を測定することができます。想定される平均処理時間よりも一件あたりの処理時間が長くなっている場合、何らかの理由で業務処理スピードが遅いといえ、非効率な活動が存在しているとみなすことができます。
しかし、現実にはタイムスタンプは終了時間（または開始時間）しか記録されていないため、サービス時間が算出できないケースがあります。この場合でも、活動から活動までの経過時間の算出は可能ですが、この経過時間は、サービス時間と待ち時間の合計時間となります。
待ち時間 – Waiting time
待ち時間は、前活動が終了してから、続く次活動が始まるまでの間の文字どおり「待ち」の時間です。業務量が短期的に増加した場合など、現状の担当者数（リソース）では捌ききれないような時、待ち時間は長くなりがちです。すなわち、ボトルネックが発生しがちだということがわかります。
活動 – Activity
活動は、一連のプロセスを構成する一つ一つの作業を意味します。購買プロセスであれば、「購買依頼」、「購買承認」、「見積もり依頼」、「検品」などがそれぞれ活動です。こうした活動がシステム上で行われる場合、タイムスタンプと共に記録される単位となり、システム的には「イベント」と呼ばれます。「イベントログ」とは文字通り、プロセスを構成する一つひとつが詳細に記録されていることから「イベントログ」と言われるわけです。
タイムスタンプ – Timestamp
タイムスタンプは、プロセスを構成する活動、すなわち何らかのシステム操作が行われた時刻を記録したものです。
タイムスタンプが記録されるタイミングはシステムによって異なりますが、多くの場合、「保存」「更新」などのボタンを押下した時点であり、活動（操作）の終了時刻と考えることができます。そして、基本的に、この終了時刻のみのデータしか記録されておらず、活動（操作）の開始時間が記録されているシステムはあまり多くありません。
プロセスマイニングの分析の視点からは、活動（操作）の開始、および終了時刻が記録されていることが望ましいです。なぜなら、活動（操作）ごとの処理時間、すなわちサービス時間の集計・分析が可能になるからです。
文脈的データ – Contextual data
文脈的データとは、プロセスマイニング分析の結果をより深掘りするための各種属性データです。プロセスマイニングを行うために必須のデータ項目は、ケースID（案件ID)、活動（アクティビティ）、タイムスタンプの３つ。さらに標準の分析項目として、リソース（担当者）、およびロール（担当者の所属部署、役職など）があります。
文脈的データは上記必須３項目と標準２項目以外のデータです。たとえば、購買プロセスの分析を行う場合には、サプライヤ名（商社名）、購買品目、購買価格、購買数量、対象製品などが文脈的データとして有効でしょう。
プロセスマイニングツールには、文脈的データも併せたイベントログをアップロードすることができます。
根本原因分析 – Root-cause analysis
根本原因分析は、イベントログから見える化された「現行プロセス（as isプロセス）」を検証する中で発見された「非効率プロセス」や、業務が滞留している「ボトルネック」などの問題箇所について、「なぜこのような問題が発生しているのか？」という原因を深掘りする作業です。
たとえば、購買プロセスにおいて、全体のリードタイムが想定より長くなっている場合、文脈的データである「サプライヤ名」で掘り下げると、特定のサプライヤの納入において時間がかかりすぎており、その結果全体のリードタイムに影響を与えていた、といったことがわかります。このように、プロセスマイニングツールにおける根本原因分析では、文脈的データを活用して分析を深めていきます。
もちろん、データからは原因が明確に突き止められない場合には、現場担当者へのヒアリングや、観察調査など、従来の業務分析手法を援用する必要があります。
タスクマイニング – Task mining ＊RPDと同義
タスクマイニングは、「Robotic Process Discovery（RPD）」とも呼ばれています。プロセスマイニングの分析対象である「イベントログ」では把握できないタスクレベルの分析を行うアプローチです。分析対象は、PCの操作履歴ログです。
ITシステムから抽出するイベントログで把握できるのは、「購買要求」、「購買承認」、「見積もり依頼」といった粗いレベルの活動です。現場では、これらの活動の間にファイルを立ち上げる、データをコピーするなど細かいタスクが実行されています。
こうした詳細なタスクは、ITシステムには記録されていないため、詳細なPC操作履歴が必要となります。ただし、PC操作履歴は一般に記録されていないため、PC操作を捕捉するためのエージェントソフトを対象PCにインストールする必要があります。
すなわち、タスクマイニングを実行するためには、まず分析対象のPCにエージェントソフトをインストールし、エージェントソフトを通じて収集されたPC操作履歴を蓄積することから始めなければなりません。
蓄積されたPC操作ログは、データ前処理を施した後でプロセスマイニングツールでの分析が行えますが、ITシステムから抽出するイベントログとデータ内容が異なるため特殊な処理が求められます。このため、一般的なプロセスマイニングツールは、基本的にPC操作ログデータの分析は困難ですが、一部のプロセスマイニングツールは、ニーズの高まりに呼応して「タスクマイニング機能」を追加してきています。
RPD – Robotic Process Discovery ＊タスクマイニングと同義
RPDは、タスクマイニングと同義です。PC操作ログの分析を通じて、RPAによる業務自動化を図ることが主な目的であることから、このように呼ばれることがあります。RPD、タスクマイニングともアプローチは同一ですので、詳細は「タスクマイニング」の説明をご覧ください。
BPMN – Business Process Modeling and Notation
BPMNは、業務プロセスをフローチャートの形でビジュアルに表現するための表記法です。BPMN以外にも様々な表記法が存在しますが、国際標準であり、またデフォルトスタンダードとなっているのはBPMNだけです。
ほとんどのプロセスマイニングツールでは、イベントログデータから独自の表現でプロセスモデルを描画しますが、BPMN準拠のフローチャートへと自動変換する機能を備えています。
DMN – Decision Model and Notation
DMNは、業務プロセスにおいて何らかの基準に基づいて分岐（承認or非承認など）が発生する場合、そこにどのようなビジネスルール（判断基準）が存在しているかを表す表記法です。
たとえば、銀行における住宅ローンの処理プロセスでは、ローン申請者からの申し込みの受付を開始業務として書類などを揃えてもらった後、ローン審査」という活動において、「ローン承認」と「ローン非承認」の２つに分岐が発生します。ここでは、ローン申請者の年収や勤続年数、家族有無など、審査に必要な情報に基づいて、承認・非承認の判断が下されているわけです。そこで、DMNでは、判断に必要な情報と判断の基準を踏まえて分岐の詳細を表記します。
DMNは、BPMNではカバーしきれないプロセスの分岐を表現できるため、BPMNとともに活用することができます。プロセスマイニングツールの中には、BPMNに加えて、DMNを扱えるツールも登場しています。
ETL（Extract, Transform, Load)
ETLは、データの前処理に用いるツールです。業務システムからイベントログを抽出し（Extract）、プロセスマイニングで分析可能なデータフォーマットへとデータを変換し（Transform）、プロセスマイニングツールや、BIなどにデータを乗せる（Load）することが基本機能ですので「ETL」と呼ばれます。
プロセスマイニングツールには、ETL機能は基本的に含まれていません。したがって、データの前処理を行うためには、ETLツールを用いる必要があります。私が推奨しているETLツールは、「KNIME」です。英語のインターフェイスのみですが、オープンソースであり、豊富な機能を備えています。
なお、ETL機能は、データ分析の最初の段階であることから、統計解析ツール（SASやSPSS)などにも標準で実装されている機能です。（KNIMEにも、実はデータ前処理だけでなく、様々な分析機能も備わっています）
また、データの前処理は、データ量が少なければExcelでも実行できますし、エンジニアの方であれば、SQL、Python、Rなどのスクリプトで処理を行うほうが簡単かもしれません。
カスタマージャーニーマイニング – Customer journey mining
「カスタマージャーニー・マイニング」は、顧客がWebサイトやリアル店舗などに訪問した際に記録される「行動履歴ログ」を対象に、プロセスマイニングの手法を活用して、顧客のWebサイトやリアル店舗内の回遊状況の見える化を行うものです。
Webサイトの場合は、サイトの訪問履歴である「Webアクセスログ」がWebサーバに自動的に記録されますので問題ありません。しかし、リアル店舗等の場合は、店内にビーコンを設置し、顧客が持つスマートフォンとの通信を行って店内の回遊行動を逐次、「行動履歴ログ」として記録することでプロセスマイニングの適用が可能となります。
プロセスマイニングというと、一般には、企業・組織で働くスタッフが、ERPやSFA、CRMなどのシステム、アプリケーションを操作して業務を行った記録である「イベントログ」に対し、プロセスマイニングツールを駆使して分析を行うものです。この場合、業務プロセスを可視化することで、ムダな業務やボトルネックを発見し、リードタイム短縮や、業務コストの低減を図ることが目的になります。
一方、Webサイトやリアル店舗等での顧客の「行動履歴データ」を対象とするプロセスマイニングは、「顧客の行動プロセス」、すなわち「カスタマージャーニー」を可視化することで、顧客の行動パターンを理解し、早期離脱を防いだり、適切な販売・販売促進施策の立案に役立てます。
BPM – Business Process Management
BPM、すなわち「ビジネスプロセスマネジメント」は、文字通り、ビジネスプロセス、ひらたくいえば「業務の手順、流れ」を適切にコントロールすることであり、その基本目的は、収益の拡大、コスト削減、顧客満足度向上などを通じて事業の継続的運営、成長を目指す取り組みです。
BPMは以下の３つのアプローチで構成されます。
１ プロセス開発 – Process development
新しい事業を開始する時、自社製品・サービスをどのように顧客に届けるか、また製品・サービスを調達するための購買活動をどのように行うか、などの視点から、様々な業務プロセスを設計し、業務手順をマニュアル化したり、運営体制を確立したり、ITシステムの開発に取り組む必要があります。これがプロセス開発です。
２ プロセス運営 – Process operation
業務プロセスの開発が完了したら、プロセス運営段階です。円滑に製品・サービスが提供されているか、購買活動が適切に行われ、原材料不足などによって欠品が生じていないかなど、プロセス運営状況は継続的に監視（モニタリング）を行うことが求められます。
３ プロセス変革 – Process change
プロセスを運営する中で生じている非効率な箇所、業務が滞留しているボトルネックなどの問題はできるだけ速やかに解決する必要があります。場合によっては業務手順を大きく変更する必要があるでしょう。
また、外部環境変化により、これまではうまく回っていたプロセスではうまく適合しなくなることも起こります。こうした場合にプロセスの見直し、組み直しを行うのがプロセス変革です。
これら、プロセス開発、プロセス運営、プロセス変革は、 外部環境変化への対応、また継続的プロセス改善のため、ぐるぐるとサイクルを回し続けることが必要です。
BPMS – Business Process Management System
BPMS、すなわち「ビジネスプロセスマネジメントシステム」は、ビジネスプロセスの実行、管理を支援するITシステムです。
BPMSとしての機能を備えたソリューションは多数存在し、ソリューションによって搭載している機能が異なりますが、BPMSの核となる機能は以下の３つだと言えるでしょう。
１ ビジネスモデリング機能
業務プロセスの手順、流れを新たに設計したり、あるいは現行プロセスを把握するために、BPMNの表記法に準じて、フローチャートを作成・編集できる機能です。フローチャートを作成するのは基本的に、手作業であり、元となる情報は、マニュアルや業務定義書、関連システムの要求仕様書、現場担当者に対するヒアリングなどになります。
２ モニタリング機能
業務プロセスの実際の遂行状況をデータとして捕捉し、問題が生じた場合にアラートを出すなどの設定が行えます。
３ ビジネスルール機能
業務の中でなんらかの条件に基づく判断（プロセスの分岐）が行われる場合のビジネスルールを多くの場合、「決定表（Decision table）」の形式で管理し、自動実行を行うなどの設定ができます。
その他、一連の業務の確認・承認・決裁の手順をシステム上で組み立て、着実な実行を促すワークフロー機能を有しているものもあります。
なお、BPMSで捕捉しているデータに基づく分析機能も標準機能のひとつと言えますが、BI的な集計・表示であり、プロセスマイニングツールが行う、イベントログに基づく「プロセス発見機能」は備えていません。（備えているツールもあります）
デジタルツイン – Digital twin of an organization
「デジタルツイン」とは、文字通り、双子のうち、デジタルの片割れのことです。、もう一人の双子の片割れは、あえて対比的に言うなら「アナログツイン」であり、物理的なリアルに存在する方です。
具体的には、アナログツインの形態なり行動をデジタルデータとして捕捉し、適切に処理・分析することで、デジタル的に、よりわかりやすく言えばコンピュータ・ディスプレイ上に、アナログツインとそっくりに再現したものがデジタルツインです。
デジタルツインは、アナログツインの生き写し、そっくりさんですが、物理的な存在でないため、いろんな視点で分解、すなわち分析してつぶさにその特性や仕組みを観察することができます。
また、デジタルツインの一部を変更したら、全体としてはどのように見た目や動き方が変わるかをシミュレーションできます。
デジタルツインは、様々な分野に適用されていますが、を企業・組織に当てはめたのが「Digital twin of an organization」です。人々が様々な形で属し、協働して働く企業・組織は、非常に複雑な構造や仕組みで動いています。
オフィスという実体はあり、働く人々もリアルに存在していますが、近年では、リモートワーク化も進み、必ずしもスタッフ全員がオフィスに居るわけではありません。また、RPA化により一部の業務は人ではなく、プログラムとしか存在しないロボットが遂行しています。業務自体も、多くが業務システム上で行われるようになり、企業の事業活動の「ブラックボックス化」が進んでいます。
事業活動のブラックボックス化の進展は、そのコントロール、マネジメントが困難になることを意味します。従業員がどのように仕事を進めているのか、ちょっと観察しただけではわからず、業務が効率的なのか、滞っている箇所はどこなのかという現実を把握することができないからです。
こうしてブラックボックス化した組織、業務を「見える化」できるテクノロジーが「プロセスマイニング」です。業務システムから抽出したイベントログから、様々な業務プロセスがどのように遂行されているか、「プロセスモデル（フローチャート）」として、まさにデジタルツインを生み出せます。
すなわち、プロセスマイニングは、デジタルトランスフォーメーションを促進し、デジタルツインを実現するために不可欠なソリューションです。
プロセスモデリング – Process Modeling
プロセスモデリングとは、対象とするプロセスの流れ、およびプロセスを構成する各アクティビティの担当者や部署などを基本的にはフローチャート図の形で明確化することです。
上記の説明までは「プロセスマッピング」とほぼ同意となりますが、プロセスモデリングではより分析を深めて、現状プロセス（as isプロセス）を修正したり、改善された望ましいプロセス（to beプロセス）を設計することも含まれます。
また、新たな業務を開始するにあたって、ゼロから業務プロセスを設計し、フローチャートとして描く作業もプロセスモデリングです。
プロセスモデリングでは、基本的にプロセスモデルを表記する国際標準であるBPMN準拠の作図が行えるツール（モデリングツール）を用います。モデリング機能は、BPMSでは基本機能のひとつです。また、プロセスマイニングツールでも、モデリング機能を備えたものがあります。
プロセスマッピング – Process Mapping
プロセスマッピングは、基本的には、対象とするプロセスの現在の流れ、プロセスを構成する個々のアクティビティと担当者、部署などを把握し、フローチャート図の形で明確化するものです。
プロセスモデリングと異なり、あくまで現状プロセス（as isプロセス）の把握が主目的であり、あるべきプロセス（to beプロセス）を設計することはプロセスマッピングとは呼びません。
業務分析を行う際に、しばしばワークショップスタイルで関係者が一堂に会し、どのように業務を進めているかを話し合い、個々のアクティビティを記入した付せんをホワイトボード上に時系列に並べていく作業は、典型的な「プロセスマッピング」と言えるでしょう。
なお、プロセスマイニングツールによっては、イベントログから発見（再現）したフロー図を「プロセスモデル」ではなく、「プロセスマップ」と呼ぶものもあり、実務上は、プロセスマッピングとプロセスモデリングの違いを明確に区別する必要はありません。大事なことは、どちらもばくぜんと捉えている業務の進め方をフローチャートのような形で「見える化」する作業であるという点です。