ビジネス要求定義における問題と解決-ビジネス要求の獲得-

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

# 目次
- ビジネス要求定義の位置づけ
- ビジネス要求定義の獲得における勘どころ
- まとめ
- 参考資料

# ビジネス要求定義の位置づけ
タイトルにある「ビジネス要求の獲得」とは下の赤枠の範囲を示しています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599668/19fd0a15-c96b-1bcf-d6ec-3f6e2436c3dc.png)

## ビジネス要求定義とシステム要求定義
要件定義は「ビジネス要求定義」と「システム要求定義」に分けられます。
ビジネス要求定義では、「どんな状態を実現したいか」「どの課題を解決するか」を明確にします。
一方システム化要求定義では、「そのために何をするか」「何をつくるか」を明確にします。

## ビジネス要求定義のステップ
ビジネス要求定義では3つのステップがあります。

### 1. ビジネス要求の獲得
ここでは「実現したいこと」を把握する作業にあたります。
以下の作業をする必要があります。

　　　1.1 現状の把握
　　　1.2 問題・課題の抽出
　　　1.3 ゴールの抽出
　　　1.4 手段の抽出
### 2. ビジネス要求の分析
ここでは「実現したいこと」を精査して合意をとります。
以下の作業をする必要があります。

　　　2.1 要求の体系化
　　　2.2 要求の具体化
　　　2.3 優先順位付け
　　　2.4 要求の交渉
### 3. ビジネス要求の文書化
最後に「実現したいこと」を可視化します。
以下の作業をする必要があります。

　　　3.1 文書化



# ビジネス要求定義の獲得における勘どころ
ここからはビジネス要件定義で起こりがちな問題とその解決策について紹介します。

## 現状の把握
ここでは2つ事例を紹介します。
### 問題①現状把握ができない
- 既存ドキュメントが陳腐化しておりそのまま利用できない
- 業務を理解している人材が減っている
- 対象業務やシステムが複雑、広範囲で理解し難い

現行業務やシステムを理解するのが困難で、正確な現状把握ができていない事例です。

### 問題①の解決策
#### 現行システムから可視化する
開発部門が現行で動いているデータベースやプログラムコードを読み解き、現状を把握しましょう。
#### 全体像を可視化する
複数のシステムと連携している場合は、広い視野を持って俯瞰的に整理する必要があります。
システム間関連図、システム構成図、概念データモデル、画面遷移図、業務スケジュールなどを使って可視化すると良いでしょう。
#### 現行業務を再学習する
業務部門が現行システムの調査や実際の操作方法、利用されている現場の観察を行いましょう。
#### 埋もれている既存資料を発掘する
操作説明資料、運用マニュアル、契約書などから情報を読み取りましょう。
#### 実態と照らし合わせて可視化する
現行システムの操作シナリオを作成し、業務担当者へインタビューします。
実作業を観察し、第三者から見て無駄な作業がないか、なぜその作業が必要なのかを確認します。

### 問題②システム全体を把握できていない
- 自分が担当した部分を他の誰もわかっていない
- 全体を把握している人がいない 
- 業務運用担当者が理解していない 

現状業務やシステムの分析をしたが、分析結果や全体整合の結果が正しいかどうかがプロジェクトとして判断できない事例です。

### 問題②の解決策
#### プロジェクト全員での共通認識プロセスを実施する
作成した業務シナリオのプロジェクト全員での読み合わせを行う。
関係者間での認識違いを浮き彫りにするなどをして、お互いの認識を再確認する。

#### 業務運用時の人材育成を要件定義から始める
安定的に業務を運用するために、業務を運用する体制をどのように構築するか、その人材をいかに育成していくかを、要件定義の段階から検討し始めましょう。
現状の体制と運用担当者の人材について、共通認識を構築することが大切です。

## 問題・課題の抽出
2つ事例を紹介します。

### 問題③ステークホルダを見誤る
- 詳細な問題・課題がたくさん出てきて収拾がつかない 
- 真の問題・課題が出てこない 
- 問題・課題の抽出に漏れがある

ステークホルダを見誤り、必要な要求が抽出されない事例です。

### 問題③の解決策
#### ステークホルダを漏らさない
ステークホルダを漏らさないようにドキュメントを作成。
- 対象業務の運用者 
- 対象システムの運用者 
- 対象業務・システムの最終利用者（お客様やエンドユーザなど） 
- 業務の結果で評価される人（経営層など） 

#### 各ステークホルダの問題・課題認識の違いを認識する
- 経営層・事業部門長
    - 理念、長期ビジョン、社会的な問題意識 他社比較 戦略、利益拡大 など
- マネージャ・リーダー 
    - 全体俯瞰の視野 リスクの回避、防止 判断のタイミング など
- 実務スタッフ
    - 個人起点の発想 定型業務 ムダ・ムラ・ムリの改善 

#### ステークホルダ間の対立・関連を見極める
目的に照らし合わせた重要課題の深堀りや解決策の導出を行うことで、ステークホルダとの合意形成・調整をスムーズに進めましょう。

### 問題④真の問題・課題の抽出ができていない
- 効果的な要求（対策）にならない
- 他にもっと効果的な対策を講じられる要求はないのか不安になる
- 現場は本当は何に困っているのか、本当の問題は他にあるのではないか

### 問題④の解決策
#### 問題と課題の違いを意識する
**問題**：「あるべき姿と現状との負のギャップ」であり「解決を要する事実」 
**課題**：「問題を解決するために何をすべきか」であり「解決すべきテーマ」

#### 要求の源泉を分析する
問題、ニーズを明確にするということは、要求を定義した理由、すなわち「なぜ（原因）」を明確にすることであると言われています。
ニーズや問題が明確になったら課題である「解決すべきテーマ」を設定しましょう。
この課題（解決テーマ）が設定できれば目的を明確にして、手段を検討して、現実に即した本質的な解決方法が導かれることでしょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599668/70d7b696-6937-5623-f23a-2ceda57032a3.png)

#### なぜなぜ分析を行い、真の原因を見極める
原因によって対処方法が異なるため、どの問題を解決すべきかを検討することが大切です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599668/415a91e1-197a-8202-00d6-d25ac2113dbe.png)

#### 解決テーマ（課題）を適切に設定する
課題を設定するには、ボトルネックになっている問題、効果の大きな問題などを見極める必要があります。
すべての原因を解決しようとして要求が膨らむことがないようにしましょう。
プロジェクトで本当に解決しなければならない「真の原因（問題）」を見極め、何を「課題」として設定するかを分析、検討しましょう。

## ゴールの抽出
2つ事例を紹介します。

### 問題⑤経営レベルの要求の整理ができていない
- 経営に貢献する要求、経営方針に合った要求が抽出されない
- 経営レベルの要求を収集していない
- 経営レベルの要求を経営層と確認していない 

経営に貢献する要求や経営方針に合った要求が抽出されない事例です。

### 問題⑤の解決策

#### 経営レベルの目的・目標、経営施策を明確にする
要件定義工程では、提示された経営レベルの目的・目標や施策を確認することが必要です。
企画で決定された情報を整理して経営層に確認し、向かうべき方向性を合意しましょう。

#### 経営レベルの目的・目標を見極める
- 品質を上げる
- 納期を守る
- 顧客満足度を上げる
- 安全性を上げる
- リスクを下げる
- 売上を上げる
- コストを下げる
- モチベーションを上げる
- コンプライアンスを守る
- 環境貢献、社会貢献 
など

#### 経営施策（手段）を見極める
経営施策とは、例えば、新たな営業拠点を作る、新たな物流倉庫を作る、組織を変える、などのことを指します。
構想立案などで明示されているはずであるため、洗い出して明確にしましょう。

### 問題⑥業務レベルの目的・目標が明確でない
- 業務として目指すものが不明確
- システム化要求が経営レベルの要求にどのように貢献するかが不明確
- システムの操作性要求が多くなる

経営に貢献するためのサブゴールである業務レベルの目的・目標が明確でない事例です。

### 問題⑥の解決策
#### 目的と手段の違いを意識する
**目的**：「～を改善したい、価値を上げたいという要求」であり「目指すところ、達成したい結果」 
**手段**：目的・目標を実現するために、施すべき対策を実行可能な内容で定義したもの

#### 目的と目標の違いを意識する
**目的**：目指すべき方向でありゴール
**目標**：その目的を達成するためのマイルストーン

目標には、今はこのくらい（現状値）だが、いつまでに（達成時期）、どのくらいの効果（目標値）を目指すのかを示す具体的な時期と指標を持つと言われています。

#### 目的・目標にはレベルがあることを意識する
各ステークホルダにはそれぞれの目的・目標があるはずです。
目的・目標には上位・下位関係が存在することを理解しておきましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599668/d34f11e3-a15d-3591-a68b-e551cc15f13b.png)

## 業務レベルの目的・目標を抽出する
経営レベルの目的・目標を目指した下位（業務レベル）の目的・目標に相当する要求を獲得しなければなりません。

目的・目標の抽出には2つのアプローチがあります。
- トップダウンアプローチ：経営レベルの目的・目標に沿って部門長などが目的・目標を決める
- ボトムアップアプローチ：現場の意見を聞いて現場の課題や要求を実現するために目標・目的を設定する


## 手段の抽出

### 問題⑦効果的な手段が抽出できない
- 経営や業務に目的・目標に効果的な手段が抽出できない
- システム化の手段やシステム操作性の手段が多くなる

### 問題⑦の解決策

#### 手段のレベルを意識する
手段には、経営レベルの手段から実業務上の手段、システム化するという手段、などがあり、目的が関係づいている必要があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599668/31b0544a-f1f6-a45a-7114-34968405982e.png)

#### 手段の十分性から他の手段がないか検討する
目的を達成するためにこの手段で十分かどうかを検討することでより効果的な新たな要求が抽出できます。

(例) 現状の問題：「手作業で集計している」

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/599668/bf5b0fd2-8c16-6734-27bc-b373c4f2a74e.png)

問題を解決する方法として、まず「自動集計するシステムを構築する」が思い浮かぶでしょう。
ここで一度目的に立ち返り、問題を解決することでどんな目的を達成したいのかを考えます。
「情報提供スピードの向上」が目的であったなら、この目的の達成のためにどんな手段が考えられるか検討しましょう。

「集計前のデータでも良いから早くデータを利用できるようにしては？」
「BIツールを導入し、現場が必要とする形で自由に集計できるようにしては？」
といったアイデアが出るはずです。

# まとめ
今回は要件定義のステップと、その中でありがちな問題とその解決方法についてまとめました。
次回は[ビジネス要求の分析編](https://qiita.com/szn-t/items/1d42127c60e1780528f8)を紹介しますので併せて読んでみてください。

# 参考資料
- [ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ](https://www.ipa.go.jp/publish/tn20191220.html)
- [システム開発だけじゃない―もっと“ふだん使い”できる「要件定義」（前編）](https://joins.co.jp/ownedmedia/small-win_yokenteigi1/#:~:text=%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E8%A6%81%E6%B1%82%E5%AE%9A%E7%BE%A9%EF%BC%88BR%EF%BC%89%E3%81%AF,%E5%8C%96%E3%83%BB%E8%B3%87%E6%96%99%E5%8C%96%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%80%82)