こんにちは。ネオシステムの高橋です。
今回もウォーターフォール開発における要件定義フェーズでありがちな問題とその解決方法についてまとめました。
今回はその一部の「ビジネス要求の分析編」について詳しく見ていきたいと思います。
「ビジネス要求の獲得編」はこちらをご覧ください。

目次

ビジネス要求定義の位置づけ
ビジネス要求定義の分析
まとめ
参考資料

ビジネス要求定義の位置づけ

タイトルにある「ビジネス要求の分析」とは下の赤枠の範囲を示しています。

この図の詳細についてはこちらをご参照ください。

ビジネス要求定義の分析

ここからはビジネス要件定義で起こりがちな問題とその解決策について紹介します。

要求の体系化

ここでは2つの事例を紹介します。

問題①要求と目的が合致していない

目的に合致しない要求が多くある
もっと効果的な手段がある
膨らむ要求を捨てられない

抽出した要求が全体として効果的かつ必要十分なものになっていない事例です。

問題①の解決策

要求を構造化する

すべての要求を「目的」「手段」に区別して、経営レベルの要求から現場レベルの要求を関係付けて構造化しましょう。

妥当性の観点から真の目的を見極める

「妥当性」とは、構造を下から上に検証することを指します。
以下のいずれかに当てはまっていれば、妥当であると判断できます。

下位の「手段」や「サブ目的」が上位の「目的」に対して妥当な要求になっているか
「手段」や「サブ目的」が達成したい「目的」に対し効果を上げるものになっているか

十分性の観点からより効果的な手段がないか検討する

「十分性」とは構造を上から下に検証することです。
上位の「目的」に対し、下位の「手段」や「サブ目的」が必要十分であれば十分であると判断できます。
以下の観点から目的と手段を見直してみましょう。

抽出された「手段」や「サブ目的」だけで「目的」を達成することができるか
「目的」を達成するために必要な「手段」や「サブ目的」がまだ不足しているのではないか

問題②要求に具体性がない

具体的な数値目標がない
具体的な対策になっていない

問題②の解決策

目標に評価指標を設定する

現状値や目標値を測る物差しを「測定尺度」と呼びます。
目標に評価指標を設定する際、何を測定尺度として設定するかが重要です。

(例)目標を「顧客満足度の向上」とする。

要求の具体化

3つ事例を紹介します。

問題③業務の情報整理ができていない

業務（情報）の整理ができてない
業務の複雑さを低減できない
業務用語を正しく理解していない
業務の構造を把握していない
データモデルは業務部門には難しい

要求を反映した業務の情報構造にならない事例です。

問題③の解決策

管理対象のバリエーションを整理する

管理対象の種類を整理する
- 「ユーザ」「顧客」「利用者」は同じなのか、違うのか、部分なのか、など
漏れなくダブりなく整理する
- ミッシー（MECE：Mutually Exclusive and Collectively Exhaustive）になるように分類する
- ミッシーに分類するとは、相互に重なりがなく、全部集めて漏れがない状態にすることをいう
名前のない分類に名前を付ける
- 「販売先」には契約の仕方によって「得意先」以外に「得意先」でない固有の表現を持たないグループがあることを表している
- この固有の表現を持たないグループに明確に名前をつけることが重要である。（一般販売先など）
用語の定義として共通認識する
- 「顧客」や「ユーザ」という用語を使わず「利用者」という用語で統一する
- 使わないと決めた「顧客」や「ユーザ」は禁止用語とし、仕様書の記述に使わないよう徹底する
企業文化に依存するので注意する
- 管理対象の整理は企業文化に依存するので、結果は企業ごとに異なる
- 各自の思い込みで整理しないように、確認することが重要あり、整理した結果は全員で共有する必要がある

管理対象のバリエーションを削減する

分類の廃止例

現在使用されていないもの
今後使用しないもの
システム対象外のもの

業務ルールと照らし合わせて概念データモデル(ER図)を描く

業務で扱うデータやそのデータに関する業務ルールを調査し、エンティティや関連として構造化することで、実業務の管理過程を表すことができます。
ER図の詳細についてはこちらをご参照ください。

工夫して業務部門と確認する

システム部門やベンダ企業が業務ヒアリングやレビューを行って作成し、業務部門に確認していきましょう。

問題④業務プロセスを標準化できていない

ビジネスプロセスが変わらない
業務プロセスを標準化できない
変革ポイントが分からない
要求が反映されているか分からない

要求を反映した業務プロセスにならない事例です。

問題④の解決策

問題・課題、要求と照らし合わせてプロセスモデルを描く

フロー系成果物は精度を上げて具体的に記載すればするほど量が多くなるため、対象をすべて記載するところまでで精一杯になり、内容に対する議論が疎かになる傾向にあります。
そうならないように、作成者が経営的視点でビジネスプロセスを改革、改善するという意識を持って、業務フロー図などのプロセス系成果物の作成に臨むことが重要です。

要求との紐付けをする

業務フロー図上に問題点・課題や要求のマッピングを行い、現状の課題の共通認識や新しい業務の検討に業務フロー図を用いましょう。
そして、前出している要求との照合も実施しましょう。

業務プロセスのバリエーションを整理する

業務プロセスの廃止を検討する
業務プロセスの集約を検討する
業務プロセスの連結を検討する
業務プロセスの並列化を検討する

業務パッケージの適用を検討する

パッケージ導入を検討する際は以下のことを念頭に置きましょう。

カスタマイズ量に注意する
- カスタマイズが20％以上あると新規開発と変わらないと言われている
業務をパッケージに合わせるという意識を強く持つ
業務パッケージの導入に対する現場の反対をコントロールする
- 業務をパッケージに合わせるという意識をプロジェクトメンバに周知させておかないと失敗する
経営トップが参画する
- 経営トップが積極的に参画するか、プロジェクト責任者に業務変更権限を明確に与えないと成功しない
パッケージ導入の是非を再度判断する
- 要件定義工程で新たな要求が明確になった時点で、もう一度Fit&Gap分析を行い、パッケージ導入が適切であるかを判断し直す

問題⑤情報と業務プロセスの整合性が取れていない

情報と業務プロセスの整合性がとれていない
業務パターンが多い

情報と業務プロセスの関係が複雑で不整合が発生している事例です。

問題⑤の解決策

相互作用のモデルを描き、情報、業務プロセスの両面から業務の実現性を確認する

相互作用モデルを作成することで、管理対象（エンティティ）のライフサイクルを表現できます。
相互作用モデルとは、業務上のイベント（プロセス）によりエンティティがある状態から別の状態に変化することを明確にした図のことです。
このモデルの作成によりエンティティと業務プロセスの関係が明確になり、双方に矛盾なく業務が遂行されるかどうかが検証できます。

業務パターンを削減する

「業務を標準化したい」「幹となる業務と枝葉である業務を切り分けたい」といったニーズも多く上がることがあります。
業務プロセスを標準化したりバリエーションを減らしたりすることは、システムのシンプル化、規模削減に大いに効果があります。

実際、業務パターンの上位 20％で実際に発生する業務の80％をカバーできると言われています。
しかしシステム開発では、利用する頻度が少ないものでも同等に開発しなければなりません。
上位20％のパターンよりも、利用頻度の少ない残りの80％のパターンの方が、開発難易度が高く品質確保が困難な業務であることも多いため、本当にシステム化が必要な業務パターンなのか確かめましょう。

どのような時にどのプロセスを辿るのかをトレースしていくと、似たようなパターンが見えてきます。
各パターンの業務上の発生頻度や重要度などから以下を検討してみてください。

パターンそのものを止められないか
滅多に発生しないパターンを統合できないか
業務運用でカバーできないか

優先順位付け

2つの事例を紹介します。

問題⑥要求の優先度付けができていない

優先順位付けができていない
絞り込み時ステークホルダの合意がとれない
すべての要求を正確に判断するのに時間を要する

限られた工期やコストの中で要求を絞り切れない事例です。

問題⑥の解決策

客観的な判断基準を明確に定義する

以下の評価基準の総合評価により優先順位を決めましょう。

有効性：目的、目標にどれだけ貢献するか（達成効果）
目標の数値だけでなく、その数値の算出方法、算出根拠も必要である。

必要性：法制度対応、内部統制、社会的責任、将来性などの観点で必要か
目的外であったり、効果が低くても実施しなければならないものもある。

法律が変わるので対応しなければならない
セキュリティ事故が起こったので対策を講じなければならない　など

緊急性：急を要するかどうか
ビジネス上の施策の納期が明確なものもある。

4月1日に法律が変わるのでそれまでに対応が必要
物流倉庫の運用が 4月1日に決まっている　など

費用：実現するのにどれくらい費用がかかるか（費用対効果）
実現にかかる費用、運用にかかる費用などを評価する必要がある。

実現性：使用する技術や人材で本当に実現できるのか（技術実現性、人的実現性）

技術的実現性：先進技術の適用などのリスクがある場合や、本当にこの技術を適用して期待していることが実現できるのかというリスクに対する評価
人的実現性：実行できる人材が育っていない、集められないといったリスクに対する評価

新たな問題：この手段を実現したときに発生する新たな問題はないか
新たな問題が発生するならその対処方法も検討する必要がある。

大きな判断と詳細な判断を使い分ける

本当の効果を費用想定で見積もるのではなく、ある程度の感覚や複数人の合意で大まかに決めましょう。

(例) 有効性という指標に対し、「効果が大きい／効果あり／効果が少ない」の 3 段階で判断する。

要求全体の優先度を仮決めして、この段階で要求の取捨選択を行います。
取捨選択の境界線上にあって判断に迷うものは、詳細に調査・分析を実施し正確なデータをもとに判断します。

MoSCoW分析（モスクワ分析）も検討してみてください。

問題⑦要求を捨てることができない

優先順位を付けても要求を絞り切れない事例です。

問題⑦の解決策

要求を捨てる

昨今の情報システムは、環境の変化に俊敏に対応できることが望まれていることから、どちらかというとシンプルでスリムなものが良いという評価に変わってきています。
難しいものは人が運用で対応する方がコストも低減する、また対応力も上がるためです。

要求を先送りにする

初めからすべての要求を実現した100点のシステムを作成せずに、60点の評価が得られる程度の必要最低限の機能だけでシステムをリリースしましょう。
実際に使用してもらってから徐々に機能を成長させていく方が良いものもあります。

要求の交渉

2つ事例を紹介します。

問題⑧上位層にうまく説明できない

経営層、事業部門長などにうまく説明ができない事例です。

問題⑧の解決策

説明相手の視点にあった資料を準備する

経営者向け
今までと何が変わって、何が良くなるのか、そしてそれに対する投資対効果を端的に示しましょう。
3つぐらいの主要なテーマを選んで説明すると経営層には効果的です。
業務部門長向け
要件定義に参加していない業務部門の人に対しても新しい業務を説明し、合意形成を行います。
新しい業務プロセスがどのようになるのか、システムがとのようにサポートしてくれるのかを業務フローで説明しましょう。
作成した業務フローを用いて、As-Is 業務フローであれば問題や課題のありかを中心に、To-Be 業務フローであれば要求によって変わるところを中心に説明すると良いです。

説明資料作成の計画を立てる

設計工程につながるドキュメントは、担当者を決めてスケジュールを作成して計画的に作成されることが必要です。
要件定義は合意形成が重要なので、合意形成のためのプロセスも含めて計画する必要があると言えます。

問題⑨要求絞り込みの交渉ができていない

第三者からの説明に納得感が得られない
声の大きい人に負ける
衝突する要求を捌けない

問題⑨の解決策

当事者意識を持たせる

プロジェクトメンバ全員が我が事として要求を認識・納得し、自分の言葉でプロジェクト外の人に説明する責任を持ちましょう。

　新システムを利用する業務担当者から「どうしてこのような機能が必要なのか」と質問を受けた場合、「☓☓さんが必要だと言ったから」と答えたら業務担当者は新システムに不満を持つことが想定されますよね。。

ワークショップを開催し以下のようなことを実施することで、相互理解や共通認識構築をしやすくできます。

問題、ニーズのブレーンストーミング
模造紙と付箋を使った問題、ニーズの深掘り、課題の抽出
模造紙と付箋を使った目的、手段の構造化、詳細化

声の大きい人に負けない

声の大きい人がいると意見が偏ったり、企業全体よりその人の自組織のことを優先しがちになったりします。
そんなときに備えて、客観的・定量的な指標を設けることで意見の偏りを回避しましょう。

ファシリテータを設けることも重要です。
各メンバの発言時間をコントロールしたり、全員に均等に意見を聞いたりして議論をコントロールする役を作りましょう。
ファシリテータは、ステークホルダの洗い出し時に各ステークホルダの特徴を事前に把握しておく必要があります。
客観的な立場で議論をコントロールできる人が望ましいです。

セレモニーでないレビューを行う

レビューは、要求が自分たちの共通認識に適正に反映されているかどうかを関係者全員で確認する最終イベントとも言えます。
成果物を表面的にレビューして合意書に署名するなどの形式的なレビューには意味がありません。
レビューは要求にエラーがあるかどうかを確認する場であり、エラーの解決策を検討する場所ではないことも頭に入れておきましょう。

ステアリングコミッティを用意する

上位層の判断を仰ぐ必要がある事項や、当事者間の意見の衝突が発生して合意形成に時間がかかるケースがあります。
そのような場合には、上位層に意思決定を委ねてその結果をプロジェクトで共有したほうが早いことがほとんどです。
プロジェクトオーナーと各部門の責任者が議論できる場を事前に用意しておくことが望ましいでしょう。

まとめ

今回は、ビジネス要求の分析でありがちな問題とその解決方法についてまとめました。
要件定義でうまくいかないことがある場合、解決策のヒントとして使ってもらえたらと思います。

参考資料