業務フローってどう描くの？

拙著「エンジニアじゃない人が欲しいシステムを手に入れるためにするべきこと」のご紹介第２回です。まだ第１回をご欄になっていない方はこちらからご一読ください。

新システムの企画は業務フローから

さて、DX室に "無理矢理" 配属された主人公のマサト君は、ある新システム企画の一環として業務フローを書くように命じられます。業務フローはシステム化対象となる業務の流れ、誰が何をして、次には誰が何をするかといったことを図示したもので、大体、以下のようなものが書かれます。

AS-ISのフロー

この業務フローは通常２種類書かれて、まずは現状の業務のフロー(AS-IS)を書いて、そこにどんな問題があるのかをあぶり出します。「この業務の実施に時間がかかりすぎるから、結局お客様への見積もり回答が遅れて失注してしまっている。」とか、「ココとココは、実は作業の重複が多いから、どちらか一つの部署で集中してやった方が良い」とか、そんな問題点を明らかにしていくわけです。まさにシステム作りの具体的な目的を明らかにする大切な作業です。極端な話、これだけをベンダーに示して、良い解決策を提案してもらうこともできますので、ユーザーとしてはこれを正しく書くことは非常に大切ですし、こういうことができることは、個人としても非常に価値ある能力ということになります。

TO-BEのフロー

さて、このようにしてAS-ISがかけたら、書きながら出てきた問題点の解決方針を考えます。時間のかかる業務なら、AIにやらせて数分で終わるようにしよう。業務の重複は、部門の役割分担を変更しよう、システム化はいらない、なんて感じです。
そうして考えた解決策を入れて作るのが、将来的な業務フロー(TO-BE) です。これを書くことで、業務の中でシステム化(デジタル化)すべきところと、新システムの基本的な機能が明らかになるほか、それ以外のこと、組織や役割分担の変更、業務に携わる人に必要なスキル、彼らが持つべき責任、必要な情報とそのやりとりのタイミングなど、実に様々なことがわかってくるわけです。このTO-BEの業務フローは新システムの企画資料としてだけではなく、経営自体の企画資料としても非常に有効なものになってきます。

他人任せにはできない

これそのものは特にITの知識がなくてもかけますし、逆に業務に対する正確な理解が必要となりますので、原則的にはユーザーサイドが書くことになります。(そもそも、この時点ではまだベンダーに発注していないケースも多いです。)　もちろん、こうした図を書くことを外部の専門家に頼む場合もありますが、そうして書かれる業務フローは、外の人間が書いたものですので、不正確な部分や抜け漏れがあるのが普通で、最終的にはユーザーサイドの厳密なチェックが必要です。書くのは誰であれ、ユーザーサイドがその正確性・有効性には責任を持たなければならないというわけです。
本書ではシステム開発経験のない方に向けて、ごく簡単な業務フローの書き方とシステム開発に使えるフローを書くためのポイントについて解説しています。

正確だけど正解ではない？

さて、マサト君は外資系コンサルからやってきたコンサルタントにコーチをしてもらいながら業務フローをなんとか書き上げます。しかし、これを役員の前で説明した彼は思わぬ駄目出しを受けます。「このフローは正確だけど正確ではない」だと、そんな禅問答のようなことを言われてマサトは混乱します。おまけにコーチしてくれたコンサルに質問しても「そこは自分で考えてください」と木で鼻をくくったような答えしかしてくれません。すっかり迷ってしまったマサト君でしたが、意外な人物の言葉がヒントになります。さて、どんな言葉だったのか、結局、正確であり正解でもある業務フローとはどんなものであるのか、そのあたりは是非、本書をご覧いただければと思います。一つヒントを差し上げるなら、コンサルが一言だけ言った「業務フローは汚してナンボ」と言った言葉でしょうか。

真野マリアって何者？

この物語に出てくるコンサルタントは真野マリアという25,6歳の女性ですが、実は正体が不明です。本当にコンサル会社からやってきたのか、いえ、そもそも実在する人間なのかすらわかりません。この真野マリアがどこからやってきたのか、それもこの物語の一つのメッセージに関わる重要な部分ではありますが、そのあたりは、この章を読み進めながら、想像していただくのも良いかと思います。(了)

次回は「ユーザーの要件定義へのかかわり方」についてお話ししたいと思います。

...