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

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

必ず知っておきたい要件定義でやるべきこと#4.1での内容の続きとなるページです。もし#4.1をご覧になっていない場合には必ず知っておきたい要件定義でやるべきこと#4.1を先にご参照ください。

UXと業務プロセス

UXはユーザーの体験価値そのものです。UXから、ユーザーシナリオの大枠(使用前後の体験含む概要業務フロー)、業務フロー、業務プロセス、そして使用する UIが明確になります。ユーザーシナリオから当該業務プロセスの前後含めた大きな範囲の業務フローを導き出し、ペルソナを動かしてみることにより、業務プロセスと、業務プロセスを支援する機能、UIが浮かび上がってくるのです。

今回、業務プロセス要件を明確化するにあたり、該当業務フロー以前、以後の体験を想像してみます。(前)気づき→(一業務プロセス一)→(後)感動前後の間を取り持つ業務プロセスはどうあるべきかを想像し、策定していきます。

また、コンシューマー向けシステムの場合は特に、今回開発対象のシステム以外のプロモーション(例えばプッシュメールやSNSSキャンペーン等)を要する場合、それも業務フロー(プロセスの連なり)の一つ(業務プロセス)として表現しておきましょう。気づき(プロモーション)から、ITシステムを使用する業務プロセス及びUIを想定し、ユーザーシナリオの抽出につなげていきます。

使用前後を含むUXを実現するために必要な業務フローを明確にし、その中で有効な業務プロセスの定義(5W2Hの定義)を行い、その5W2Hを満たす機能とUIの定義につなげていきます。

業務プロセスが妥当か調べる〜5W2Hの定義〜

業務フロー上に現れる業務プロセスの定義を行います。「業務プロセスの定義」とは、以下の5W2Hを定義することです。

When :いつ→実施タイミング(事前/開始条件含む)

Where :どこで→ 場所、組織

Who:誰が→ 担当者、ユーザー

What:何を→対象データ

Why:何のために → 目的、狙い、当該プロセスが完了した時点で達成される目的と、事後条件(プロセス完了時に達成できていること)、を含みます。事後条件としては、例えば、受注データが記録されたことにより、「顧客と合意した契約内容が記録されたこと」等が挙げられます。

How:どのようにして→ 実施要領(制約条件含む)(ユースケース記述まで書くのが望ましいが、シナリオ(手順)までは最低でも把握可能なレベルで記述する)

How many: どれくらい→データ量、時間

また、業務プロセスは3つの条件を持つといってもよいでしょう。これらについても、上記した5W2Hのなかで定義していきます。開始条件→ タイミング、トリガー制約条件→例:「お客様が登録するならば」、「伝票にミスがなければ」前提条件→例:「プロセス開始時に必要なインプットが終わっている」等業務プロセスは、成果を評価するときの単位にもなりえます。

プロセス品質の評価(手作業か否か問わず)を可能とするのです。なお、 KPI (key performance indicator :重要業績評価指標)の測定は、プロセスの固まり(連鎖)により可能になります。記述してみて、5W2Hをうまく定義できなかったり、明確でない場合は、その業務プロセスが果たして本当に必要なものかどうかを疑った方がよいかもしれません。

業務プロセスの統合と分割

各業務プロセスの5W2Hの定義が一旦終了したら、Excel等の一覧表形式で出力してみます。一覧にしてみると、同じような5W2Hを持つ業務プロセスが複数あったり、5W2Hを強引にまとめたけれども、実際には別々にした方がよいと思われる業務プロセスが見つかることがあります。

ここは熟考すべき時です。システムの標準化の観点からは、業務プロセスをできるだけ統合し標準化することが望ましいといえます。但し、本当に業務の観点から適切であるのかについて、充分に議論した上で決定しなければなりません。

つまり「ビジネス要件」「システム要件」の観点からは統合を推進すべきであり、「業務要件」の観点からは熟考を必要とする場合です。これは「現場の強み」に繋がり、それが企業組織の存在価値を左右しかねないものが対象である場合があります。

そういった意味では「業務要件」から遡り「ビジネス要件」を再考する必要に迫られることになります。特に、明らかに同一の業務を複数の場所や組織で行っている場合等は、複数の定義を認めることにより、同一プロセスとみなすことができます。

「どこまでを1つの業務プロセスとみなすか」については、開発者、ユーザー含め皆できちんと議論し決定します。システム開発プロジェクトでは様々なことが起こります。混乱が生じることもあるでしょう。主に機能の検証を詳細に行う際によく混乱が生じます。

何らかの理由によりプロセスがブレそうな場合には……「5W2Hに戻る!」これしかありません。該当プロセスの5W2Hを基にUIがデザインされ、機能が定義されているか、何らかの理由により逸脱しているかを確認し、違和感が生じた際には、別プロセスへの分割を検討します。

5W2Hを固めるためのプロトタイ

業務プロセスの5W2Hがなかなか固まらない場合には、簡単なプロトタイプを作成し、画面イメージを基に議論し、詳細を詰めていきます。
画面イメージを基に議論すれば、業務プロセスの「主人公」や「登場人物」達が活動するために必要なプロセスが具体的に浮かび上がってきます。業務プロセス定義と業務フローとの整合性を考慮する上で、以下の2点に留意します。

①業務プロセス単体では品質が高くても、プロセスの固まりを基に策定した業務フローレベルでは、品質が落ちてしまう場合があります。これは全体最適の視点が欠けている場合に起こりえます。その根合、プロセスオーナーが納得する落とし所を見つけ、業務プロセス単体の見直しを行っていきます。サッカーに喉えると、「いいパスを出しても敵や受けての状況により受けきれない」場合もあるのです。

② 業務プロセス単体に問題があることが明白な場合は、オーナーに事実を認識してもらい、プロセス自体の改善を即刻行います。

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