要求を明確にするための勘どころを聞いてきた！

８月２３日、ＩＰＡのセミナー

「ユーザのための要件定義ガイド」に基づく要件定義品質の向上
～要求を明確にするための勘どころ～
に行ってきたのでメモメモ（途中からです）

---

■第１章、２章（途中から）

・要求→要件が抜ける→コンピュータ化するとき抜ける→あいまいな解釈
　　→運用、テストで要求漏れが発覚

・今回のスコープ
　企画フェーズ
　要件定義
　開発フェーズの非昨日要件あたり

・機能要件の合意形成ガイド

・要件定義において考慮すべき１０ポイント
（１）要件定義：経営課題解決→いままではビジネスのサポート
（２）ＩＴリスクは経営に直結するリスク
（３）今のシステムは使われているか・・・現状分析
（４）無駄なものは全社視点で排除
（５）合意形成には時間がかかる。利害関係者（ステークホルダー）
（６）要求は膨らむ（止まることはない）。納得感のある削り方
（７）要件定義に十分な工期、工数を割り当てる
（８）品質向上により、後工程の手戻りも抑止
（９）準委任を基本、一括にする場合はクリエイティブな部分が捨てられる
（１０）投資効果の評価指標と、取得方法

■第３章
３．１　経営や業務に貢献するＩＴシステムの構築
・経営の価値に貢献するか→もう、業務はＩＴになっている。なぜ作り直す？
・要求の整理・分析
　　要求：～したい　→目的と手段
　　　その背景
　　源泉（なぜ）：問題、ニーズ、課題

・問題：負のギャップ　事実
　課題：何をすべきか→事実と解決すべきことは違う チャレンジ
　要求：
　　　目的：状態変化
　　　手段：どんな手を打つか

・目標：マイルストーン→ＫＰＩの設定
　　ＫＰＩ：行動が正しいか
　　ＫＧＩ：ゴールを達成しているか

・目的の体系化
　→目的には、階層がある
　　　経営レベル：大体いっしょ
　　手段の妥当性を検討する→手段の充分性（新たな手段）

・なぜなぜ分析；社風　なぜ５回、パナソニックは７回？３回でもやったほうがいい
　　真の原因を見極める→最適な課題（テーマ）を見つける

３．２　膨らむ要求のコントロール
・要求は必ず膨らむ
　勘所
　　要件定義内でコントロール
　　だんしゃり
　　定量化

・要求
　　はじめ：膨らませる
　　後半：収束させる
　→設計工程ではだめ

・過剰要求を捨てる：だんしゃり
　捨てるポイント：
　　　充分性、妥当性
　　　定量的に測れるように→算出根拠
　　　実現性：技術的実現性、難易度
　　　必要性：ＭｏＳＣｏＷ（もすこー）
　要求を定量化

　要求量のベースラインを合意

３．３　業務の複雑さを軽減
・柔軟なシステム
　　フレームワークで柔軟；要件定義に書かれていない
　→業務が複雑：なんとかしないと・・・

・勘所
　　バリエーションの整理
　　バリエーション減らす
　　パッケージ

・管理対象（エンティティ）
　　管理対象：番号を振って管理したくなるモノ
　　組み合わせ：ルール→もと（エンティティ）を減らせば、バリエーション減る

　ダブりなく、もれなく整理する→複雑さを減らす

　不要な分類を整理する
　　なくせば、どこに影響があるかわかる

・業務プロセスの整理　４つの観点
　　集約
　　並行化→これが柔軟！
　　廃止
　　連結

・パッケージに業務を合わせる
　　→シンプルすることの近道
　　　失敗することもある
　　　　　開発量をへらしたいなら失敗する→２０％ちがうなら新規開発
　　　　　業務改革のために使う

３．４　非機能要求
・非機能難しい
　経営問題：要件定義
　勘所
　　非機能要求グレード

・非機能要求グレード
　　せっかくあるので、使ってみましょう！
　　２３６個、きめなさい
　ステークホルダー別に振り分け（Tri-Shaping）
　　ビジネス領域
　　ソリューション領域
　　テクニカル領域

・注意点：整合性
　　制約・前提　＋現在の状況→整合性の判断
　　　　依存関係
　　　　トレードオフ
　　　　矛盾関係

３．５　多様化するステークホルダーの合意形成
　コンシューマーとかも
　勘所
　　もれなくステークホルダーを洗い出す
　　合意形成

　ステークホルダーを洗い出す
　　　お金を出す人だけではないよ
　　　運用の人、経営者・・・

　　モニタリング
　　要求抽出ワークショップ：ファシリテーションするのに

　プロジェクトの最後の判断ポイント：ステアリングコミッティ、意思決定機関
　　　→なにかあったら、すぐ投げる

３．６　業務システムの把握
　いかに現行業務を把握するか
　勘所
　　可視化：俯瞰ドキュメント
　　フィールドワーク：ドキュメントだけではだめ、リラーン（再学習）
　　共通意識：ウォークスルー

→ユーザーだけでは要求定義はできない

目的を体系化するの例→５章

■第４章
・ドキュメントの観点：抜けもれ
　お話：大きく３つ
　　きちんと計画をたてましょう
　　作成の留意点：１２のドキュメント
　　成果物共通の留意点

・個々のドキュメントで勘所
　相互の関係を明確に

４．１作成計画時の留意点
・機能要件の合意形成ガイド
　　前後のプロセスの目的を踏まえて、成果物をマッピング

・ドキュメントの関連図
　　→正誤表を確認のこと

・異なる目的のために作成される
　前後のプロセスの目的

・一覧：完全性が求められる場合

・粒度を決める

・分担を明確に

４．２　個々のドキュメント
　大きく３つ
　　プロセス系
　　データ系
　　その他

●プロセス系
　ビジネスプロセス関連図を最初に見ましょう
　　１枚で表す
　業務機能構成表
　　３段階
　ビジネスプロセスフロー
　　as-isとto-be

・抜けもれ提言の観点
　　５Ｗ２Ｈ
　　例外、特殊処理
　　
・新しいビジネスプロセスを作り上げる意識を持つ
　　　ボトムアップより、事業戦略・方針のトップダウン

・画面帳票レイアウト
　　標準化
　　全部は作らない

・業務処理定義書
　　業務ルールの明確化
　　　表形式で抜けもれ

●データ系
　（ＣＲＵＤもいれて）
　概念データモデル

・概念データモデル：絵を書いて説明
　エンティティ定義書、データ項目定義書
　　→ＮＵＬＬを許すかポイント

・ＣＲＵＤ
　　エンティティ：矛盾
　　データ項目：検証→使い分け

●その他
・総合テスト仕様書
・システム移行計画書：要件定義の段階
・運用・操作要件書
・非機能要件書

４．３　成果物に共通の留意点
・第三者による公式なレビュー：インスペクション
・未決定事項：リスクを共有、要件が定義できない事案は廃棄する
・品質向上：図表、プロジェクト内での策を併用

まとめ
・何のために使うんだっけ→品質向上へ

アカデミックのゴール指向要求分析の話と近いところにあると感じました。ゴール指向要求分析だと、目的（状態遷移としていますが状態変化）を目標であるマイルストーンに分割し、各マイルストーンの目標状態を細かな部分にすることで状態の分析（データ構造の分析）にするという手法（ＫＡＯＳ）があり、それは、「不確か」な状態には、そのままでは適用できないので、どうするかというのが、アジャイル等に関連してきますが、ちょうど、そのあたりが、課題になっているのかなと感じました。

■５章：事例
・ビジネスに貢献する要求を見極める事例
　リザルトチェーン
　　　ＩＴしさく、ＯＰＰしさく
　作り方
　　２．ＩＴしさく→ＩＴ成果　３．業務成果　　１．ビジネス成果
　　　　４．ＯＰＰ
　　　　５．マイナス影響

・要件量を可視化する
　要件量管理手法の全体フロー
　要求量：ファンクションポイント、機能数などで定量化

・業務バリエーションの整理
　　業務パターンの可視化：業務シナリオマトリックス
　　２０％　８０％ルール

・非機能要件の進め方（Ｔｒｉ－ｓｈａｐｉｎｇ）
　　要求の獲得
　　要求の整理
　　要件として定義

　要求の獲得のイメージ

・ステークホルダー分析
　ステークホルダーの特定：影響度、対立関係
　合意形成のやり方
　要件定義１０箇条

・要求の定量化による合意形成と膨らむ要求の制御の事例
　生産物力変換係数

・見積もった結果で予実管理

・手戻り防止のためのレビュー　
　
・レビュープロセス成熟度

・要件定義文書の品質向上

まとめ
　みんなやってるよ！