必ず知っておきたい要件定義でやるべきこと#4.1

必ず知っておきたい要件定義でやるべきこと#4.1

「要件定義でやるべきこと」ということをメインテーマに情報システム開発の中でも現場に関わる部分の業務プロセス要件の明確化すなわち、「目的を達成するための活動」の明確化のノウハウをこの項には詰めています。どうぞ一読お願いします。

改めて「業務プロセスとは?」

本書で述べる「業務プロセス」とは、「経営の目的を達成するための活動」を指します。業務プロセスでは何らかの「入力」を元に、何らかの出力(成果)を行います。

例えば、「検討する」といったように、成果を測定できない行為は本来プロセスではありません。時間ばかりかけてダラダラと何も決まらない会議は、成果を伴わないのでプロセスではないのです。

ビジネスルール

業務フロー図を描いていくと、様々なビジネスルールが浮かび上がってきます。逆の言い方をすれば、ビジネスルールに基づいた業務プロセスを表すように、業務フローを描かなくてはいけません。ビジネスルールは判明した時点で、その時に明白になっている事実を書き出しましょう。

このビジネスルールの集まりは、業務フローによるプロセスモデルの特度を高める意味を持ちます。そしてビジネス要件、業務要件、システム要件を網羅するものになります。

改めて業務フローを階層化

プロセスモデルとしての業務フロー図は、階層化して作成し、管理していきます。経営方針=ビジネス要件(ビジネス要求を満たしうるもの)から業務要件に落とし込む際に、業務フロー階層の最上層で、ビジネスモデルとの整合性とともに、経営トップの「思い」を表現します。業務フロー階層は「ビジネス要件」と「業務要件」に基づいてブレイクダウンしていきます(要件とは要求を元に盛り込むべきもの)。

必然的に最上層のフローはプロセス関連図に近いものになります。当然、上層のフローは「システム要件」以外の「ビジネス要件」「業務要件」をより強く満たすフローになります。これは、システム稼働日までに「ビジネス要件」「業務要件」を満たす形にならなければ、システムが稼働しないことを意味します。

業務プロセスとしての業務フロー

トップダウンとボトムアップの両方から業務プロセスを炙り出して業務の流れを確立していきます。トップダウンモデリングを基本としつつ、ボトムアップモデリングで業務プロセスを明確化するのです。さらにToBeを基にAslsを踏まえて新ToBe フローを作成することにより、プロセスモデルの価値は増大します。

こうして作成した「きちんとしたToBe業務フロー」は、それ自体が企業組織にとって貴重な財産になり、以後、立派なAsls業務フローとして活用できるようになります。現場の問題点や課題を解決するためだけに、業務を整理した業務フローを最初から作ってはいけません。あくまで、トップダウンの視点で枠組みを作成し、ボトムアップで肉付け、が大前提です。

トップダウンでプロセスを見直すことにより、現場が問題と認識しているプロセス自体がそもそも必要でなくなることもあります。現場の力は大きいですし、大切にすべきではありますが、引っ張られすぎてはいけません。小手先の解決を図ろうとすると、労力ばかりかかって、結果が出ないという事態に陥りがちです。

パッケージ使用時の業務フロー

パッケージ導入の場合、パッケージに用意されたUIやマニュアルを基に、業務フローを作成します。AsIs とのフィット&ギャップではなく、ToBeを作り上げていくような姿勢が望ましいでしょう。いずれにしても、パッケージの仕様に「業務プロセスを寄せていく」努力は必要になります。

現場の人間を惹き込む

プロセスモデルとしての業務フローは、現場の人間の視点に立って業務を表現し、その表現を共有していきます。業務フローの作成者(開発者)は「ストーリーテラー(司会や語り手)」である必要があります。そしてユーザー(現場)との間でコミュニティの物語を共有していくのです。

具体的には、物語のイメージを共有すべく、業務の流れを表す線を開発者が赤ペンでなぞって、業務フローの一つ一つの線をユーザーとともに確認し、確定していきます。そのようにして、現場ユーザーを主人公とする業務の物語を作り上げるのです。難しいことのように思われますが、やってみるとそれほどではありません。

ある程度、業務フローの物語に巻き込んだら、ストーリーテラーは登場人物達がストーリーラインからそれないように注意するだけで、物語は動き出します。その際、注意点が二つあります。

ひとつは、ストーリーの結末をきちんと決めておくことです。これにより脱線事故を防ぐことができます。その際ストーリーテラーには、物語の最後にハッピーエンディングを用意しておく気持ちが求められます。

もうひとつは、物語をつくる上で、シーン(エピソード~プロセス)ごとの主人公と、フロー全体の主人公(プロセスの固まり、フロー単位のオーナー)、登場人物(プロセスのオーナーまたはユーザー)を明確にしておくことです。

物語に有効なITを使った業務ブロセスを提示し、登場人物の間で共有しながらプロセスを固めていくのです。利用部門の担当者に、業務フローを遂行する「主人公」の視点に立ってもらうように、図の内容に引き込む工夫が必要です。

コツは以下の二つです。

①これからチェックする業務の前提を伝えること。詳細な状況設定をすると、新業務フローのイメージを具体的に持ってもらうことができ、仕様の漏れが見つかりやすくなります。まず、物語の背景を伝えた上で、物語に入っていくのです。

②利用部門の担当者に新業務フローの内容を説明する際、業務の流れを示す矢印を、鉛筆やペンで辿りながら話すことです。物語を共有しつつ進めていくのです。順を追って説明することで、図で示されている業務の流れを、利用部門の担当者が具体的にイメージでき、仕様漏れを指摘しやすくなります。

 

テックカテゴリの最新記事