第1回　デジタルシフトにアナログな「業務フロー図」作成が必要なのか

　みなさま、はじめまして。世の中のデジタルシフトをあらゆる方向からサポートさせていただいている、株式会社デジタルシフトウェーブでデジタル推進を担当している島津です。

　私は2011年の新卒時から、IT業界へ就職しネットの世界で揉まれてきました。途中、リアル流通業のエッセンスを吸収しながら、ECサイト立ち上げ等、システム開発の上流工程に関わってまいりました。

　デジタルシフトウェーブでは、数多くの企業様のデジタルシフトをご支援させていただいております。そんな中、私はデジタルシフトのための業務改革をご支援させていただいております。

　「業務改革」の道のりはとても長いものです。全ての工程が問題なく、順調に進んでいくとは限りません。中には苦い経験をする場合もあります。

　多くの「業務改革」プロジェクトに関わらせていただく中で、プロジェクト成功のための重要なプロセスがあることに気が付きました。それが、「業務フロー図を作成する」というプロセスです。業務フロー図を作成することだけで、プロジェクトが順調に進むわけではありませんが、私がプロジェクトを進めていく上では、とても重要なプロセスだと考えております。　

　本連載では、私の考える「業務フロー図」のベストな書き方について、書かせていただきます。少しでも、皆さまのビジネスのヒントやチャレンジのきっかけになれば幸いです。

　「業務フロー図」と聞いてどんなものをイメージされるでしょうか。

　業務フロー図に似たフロー図として、要件定義時に作成される「システムフロー図」があります。「システムフロー図」は、システムが行う処理の流れを図式化したもので、業務フロー図とは全く異なるものです。

　「業務フロー図」は、業務の流れや作業手順などを、線や図形を使って時系列に沿って洗い出し、業務の全体像を可視化するものです。そのため、「業務フロー図」と「システムフロー図」は、図の目的から根本的に違うものであり、それぞれ、以下のように異なります。 【システムフロー図】

・システム間の連携や、処理をシステム視点で表したもの。

　→人は登場せず、主にシステム間の処理を可視化するものです。 【業務フロー図】

　・横軸に人物や、部署、役職といった「人と役割」が並び、業務の流れを記すもの。

　どちらも、「フロー図」という意味で見た目は似ていますが、記載される内容も、目的も全く違うものなのです。

　はじめにも書きましたが、デジタルシフトを推進していく中でも、一番アナログな作業である「業務フロー図」を作成することは、非常に重要なプロセスです。

　私が業務フロー図を作成する際には、下記の2点を最も重要な目的として捉えています。 　①現状の業務を可視化することで業務の改善点、ボトルネックを炙り出す

　②業務フロー図を社内、部署内で共有することで、業務フロー図を社内の共通言語とすることが出来る 　1点目はイメージできると思います。2点目の「社内の共通言語が出来る」ということは「業務に対しての社内ルールが出来る」ということです。業務のルールが出来れば、そのルールに従った業務遂行を徹底することが出来ます。

　また、業務ルールを変えたい場合には、業務フロー図をベースにディスカッションを行い、業務ルールの変更を行うことが出来ます。

　「業務フロー図」には、横軸に多くの人と役割が登場します。そのため、「業務フロー図」を作成する際の一番の注意点は、「一人の担当者へのヒアリングだけでは完成させない。」という点です。同じ会社、同じ部署で同じ業務を行っていても、担当者ごとに業務の進め方や課題感は少しずつ異なります。

　業務フロー図を作成する目的は、「社内の共通言語を作ること」だと先ほど述べました。そのため、業務フロー図を作成する際は、絶対に一人の担当者へのヒアリングだけでは終わらせません。出来る限り多くの担当者に対してヒアリングを行い、対象の業務の最適解をディスカッションし、それを「共通言語としての業務フロー図」として完成させることが重要です。

　では、なぜ「業務フロー図」を作成することが重要なのでしょうか。

　新規システムを構築する場合、システム部門が主導で要件定義が行われ、現場部門は受け入れテストの際に内容を確認するだけ、ということが多いのが現状です。

　しかし、システム部門の視点だけで要件定義を行い、開発を進めていくと実際の現場業務とマッチせず、使いづらいシステムが出来てしまいます。最悪の場合、そのシステムは利用されなくなってしまいます。

　そこで重要になってくるのが、「業務フロー図」です。業務フロー図は現場業務部門と会話をしながら、実際に運用している業務を可視化していくため、現場業務部門とシステム部門の間での共通言語になります。先ほども述べましたが、共通言語が出来ることで、お互いに業務フロー図をベースに会話が出来るため、認識齟齬なく正確なシステム開発が可能になります。

　実際に私も、以前、基幹システム入替プロジェクトを担当させていただいた際に、システム部門主導で「業務フロー図」を作成せずに開発を進めてしまい、受入テスト時に大幅な手戻りをしてしまった経験があります。「業務フロー図」を作成していなかったことで、現場業務部門とミスマッチが起こってしまったのです。

　その経験もあり、今ではシステム部門からどんなに反対をされようとも、必ず「業務フロー図」の作成を行い、現場業務部門を巻き込んで推進していくことを徹底しています。 　次回は、「業務フロー図の描き方（まず初めにやること）」について、書かせていただきます。是非引き続きご覧いただければと思います。