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