NCDCは、システムアーキテクチャの設計や業務システムの開発、UX/UIデザインなど、DX（デジタルトランスフォーメーション）に関連する領域で、コンサルティングから実装まで幅広いサービスを提供しています。
システム開発の上流から下流まで幅広く対応できるのがNCDCのひとつの特長ですが、下流工程（開発やテスト）だけを受託するようなケースはあまりなく、多くの場合、上流工程から関わらせていただいています。
業務システムの開発／改善に上流工程から参加する場合、まず業務プロセスの理解（可視化）が欠かせません。
この記事では、NCDCのコンサルタントが提供しているサービスのひとつでもある業務プロセスや既存システムの可視化について、その準備段階で知っておきたいポイントを簡単に説明します。
目次
目的は業務プロセス・システムの現状理解
先日、コンサルティングを行っているお客さまのご依頼を受けて、「業務・システムの可視化」というテーマで勉強会を開催する機会がありました。
この勉強会が企画された背景を知ると、なぜ企業がこうした「可視化」に取り組むのか、その目的やステップを理解しやすいと思うので、ここで簡単にご紹介します。
お客さまが社内で「業務・システムの可視化勉強会」を行った背景
- DXを推進する上で、既存システムの刷新や新規システムの構築の必要に迫られているが、関係者が共通認識をとれるような現状の業務マップ、システムマップが十分に揃っていない
- 今後の議論や検討に備えて、関係者が理解できる標準的な「可視化」の方法を確立しておきたい
要約すると、システム改修プロジェクトの準備段階で「現状を知るための資料が不十分」「いくつかの資料はあるが書き方がバラバラ」という課題が出てきたため、まず現状の「可視化」に取り組むことにした。しかし、事前にやり方を標準化しておかないと関係者が相互に理解できるものにならないため、まず勉強会が企画されたということでした。
程度の差はあっても、これと似たような課題は多くの企業が持っているのではないかと思います。「あるお客さまの事例」として取り上げましたが、決して、このお客さまだけの特殊な事情ではありません。
とくにレガシーシステムを抱えているような企業では「現状を知るための資料が不十分」というのはシステム刷新の際に必ず直面する問題ではないでしょうか。
なぜ可視化（現状理解）が必要なのか？
現行システムに関する資料がないのはおかしいのではないかと思う方もいるかもしれませんが、経済産業省の「DXレポート」でも指摘されているように、「長年の改修で巨大化・複雑化してしまった」「開発ドキュメントが存在しない」「システムが属人化した上に担当者が退職してしまった」など、さまざまな理由で既存システムがブラックボックス化してしまったケースは少なくありません。
（実際、NCDCでも「現行のシステムのことがよくわからない」という相談をよく受けます）
こうした状況では、システムの刷新を検討しようにも、問題点が正確にわからないため改善の方針を立てることすら困難です。
こうした課題を解決するためのアプローチの一つが、業務プロセスや既存システムの可視化です。
システム開発といってもIT部門だけの問題ではなく、そのシステムを使う部門があり、社員がいます。また、パートナー企業が使うこともあるため、業務システムには多種多様な関係者（以下、まとめてステークホルダーと表記します）がいます。
ステークホルダーによってシステムの使い方、改修への期待が異なることもあるでしょう。
多くのステークホルダーが共通認識を持てる形で業務プロセスやシステムを可視化することで、あらためて問題点を見出し、最適化のための方針を導き出すことが可能になります。
なお、よりシステム開発の現場に近い側での可視化の取り組みとしては、現行システムに関するドキュメント、ソースコード等をかき集めてエンジニアが分析し、全体像を把握する方法もありますが、今回のテーマとは少し離れるのでこの記事では触れません。
可視化の方法
可視化とは「人の目には見えない事物や現象を、映像やグラフ・表などにして分かりやすくすること。（出典：デジタル大辞泉）」です。
上記の通り、映像やグラフ・表などさまざまな可視化の方法があるので「可視化＝図示」ではありませんが、業務プロセスの可視化といえば、一般的には業務の流れをフロー図などで表現することを指します。
単にフロー図といっても、実はこうしたものは表記のルールなども定められており、体系化されたさまざまなモデルがあります。
ここではモデルの違いに関わらず、業務プロセスや既存システムの「可視化の原則」として知っておくと良いポイントを3点説明します。
可視化の原則（3つのポイント）
①ある視点を持って可視化する
先に挙げた「多くのステークホルダーが共通認識を持つために可視化する」という話と矛盾するようですが、誰がどのような視点から見ても完璧にプロセスが可視化された資料をつくることはほぼ不可能です。ひとつの資料で表現できるのは基本的にひとつの「関心事」だと考えてください。
万能なものをつくろうと考えるのではなく、関心事によって記述の仕方は変わるものだと割り切って、目的を達成できる資料をつくることが重要です。
たとえば下記の2つは別の「関心事」だといえます。
- 業務システムにおけるデータの処理の流れを明らかにする
- 業務システムのさまざまなユーザーの関係性と各自の作業手順を明らかにする
「関心事」が異なるので、同じシステムを可視化しようとしても上記の２つは別のものになるはずです。
ひとつの資料で表現できるのはひとつの「関心事」という原則の理解は、既存の資料を読む際にも重要です。既存の資料を解釈する場合は、まず、その資料は何を見るために作られたものなのかを知ることが大切なのです。
上の例で説明すると、業務システムにおけるデータの処理を明らかにするために作成された資料だけを見て、そのシステムのユーザーが誰で、各自が行うべき作業は何かということまですべて理解したつもりになるのは危険です。
業務プロセスやシステム上のデータの流れなど、目に見えない事象を可視化する際は、この原則を理解した上で表現、解釈していくことが大切です。
②標準的な方法を用いる
先にもフロー図の書き方はさまざまなモデルがあると書きましたが、「可視化」した資料が他の人に理解できないと意味がないので、標準化されたフォーマットが存在します。
（建築家が書いた設計図を工事現場で関係者が理解できないと困るのと同じで、図面だけを見て他者が理解できる標準ルールが必要なのです）
たとえばシステム刷新のために業務プロセスの可視化資料を用意したのであれば、事業部門とシステム部門が同じように解釈できる必要がありますし、システム開発を外注していれば異なる会社でも同じ理解が必要になります。もしかしたら国を跨いで同じ資料を用いることもあるかもしれません。
そう考えると、自分の都合だけで可視化の方法を選ぶのではなく、皆がわかる標準的な方法で記述することの必要性がよくわかるのではないでしょうか。
業務プロセスの可視化方法でもっとも有名なのはBPMN（Business Process Model and Notation ビジネスプロセスモデリング表記法）で、国際標準となっています。
他にも国内では産能大式フローチャートが有名ですが、特に理由がなければ国際標準であるBPMNを用いるのが良いと思います。
メジャーな方法を用いることにはさまざまなメリットもあります。
たとえば、BPMNはユーザーが多いので、書き方に迷った時に調べればすぐに情報が見つかります。
BPMNをつくるためのツールは国際標準故に世界中にたくさんあり、選択肢が大変広いです。加えて、表記をXML形式で出力して別のツールに取り込むようなことも可能です。また、BPMNを描くだけでなく、シミュレーションをかけて業務のボトルネックや改善効果を実験できるツールなどもあります。
③複数のレベルに分けてつくる
業務で使うシステムの設計準備として業務プロセスを可視化するようなケースでは、最終的には現場の細かい作業手順まで可視化していく必要があるでしょう。
しかし、実際問題として詳細な業務プロセスの可視化資料がすぐにつくれるわけではありません。すべての作業手順を明らかにするような詳細資料の作成には時間もコストもかかります。
そこで可視化に取り組む手順として、まずは「現段階で本当にひとつひとつの作業まで可視化する必要があるのか、もう少し粗い粒度でも目的を果たせるのではないか？」と検討することも大切です。
たとえば、経営層に各部署の業務プロセスをざっと説明するようなシーンでは、詳細な（現場の細かい作業手順まで載った）プロセス図を見せてもかえって理解が難しくなるので、もっと粒度の粗いものが必要となります。
経営層の承認を得て、次に各部署の方針を詰めていく段階になると、もう少し細かい粒度の可視化が必要になるでしょう。
現場の細かい作業手順まですべて可視化した資料は、こうした上位階層の承認を経てはじめて意味を持つものかもしれません。
このように可視化の目的（誰が、何のために見るのか）によってどこまで細かく表現すべきなのかは変わるので、最初から「目的に応じて複数のレベルに分けて可視化する」ように設計しておくことが必要です。
各レベルをどの程度の粒度にするべきなのかは、google検索などで調べてみると簡単に参考となる例が見つかるのではないかと思います。
ただし、「可視化の階層化はこうあるべきだ」という明確なガイドラインがあるわけではないですし、他社の例を真似てつくったものが必ずしも自社の目的に適しているとは限りません。
どの階層向けにどのレベルの資料を用いるのか、階層化の最終的なルールは自社で定義するべきものです。
まとめ
長くなってしまったので、最後に簡単にまとめます。
可視化が必要になる背景
既存システムの刷新や新規システムの構築に際し、現状の業務やシステムを把握できる資料が十分に揃っていないことが多い。
現状の問題点がわからないと改善の方針を立てることすら困難なため、現状理解のアプローチの一つとして「可視化」に取り組むケースが多い。
「可視化の原則」として3つのポイントを知っておくと良い
- ひとつの可視化資料で表現できるのは基本的にひとつの「関心事」
- 皆が理解できるように標準的な方法を用いる（特に他の方法を選ぶ理由がなければ、国際標準のBPMNを選ぶと良い）
- 目的に応じて複数のレベルに分けて可視化する
「可視化」が求められる背景から、少し実践的な3つのポイントまで解説しましたが、これから実際に可視化の作業に取り組む人は、より具体的な「BPMN図の書き方・使い方」にも関心があると思いますので、そのあたりも後日、別の記事で説明したいと思います。
「基礎知識はわかった。実践は外部の専門家に任せたい」とお考えの方はぜひ一度NCDCにご相談ください。
NCDCでは、業務プロセス・システムの可視化コンサルティングから、可視化によって抽出された課題を解決するシステムアーキテクチャの設計や、業務システムの開発まで、幅広いサービスを提供しています。
