要件定義・設計品質（要件定義とは・設計解釈・出来具合の考え方・進捗重視の弊害）
G-8 上流開発管理 ＞ G. 実行管理（プロジェクト） 元資料: ◆上流工程の品質向上【第2編】後半（9枚）
目的・概要
考え方・観点
- （参考）設計の解釈に関するやり取り
家具の設計士さんに学ぶこと（１）
- テーブルの脚（オーダー品）を下記のように発注したところ、数日後に設計図とともに具体的な寸法を問うメールが送られてきた。
- 【発注内容】
- テーブル脚（2段積み、右写真）をベースに、300mm(W)×300mm(D)×350mm(H)を3段上に積んだ商品の制作をお願いします。
- 【返信メール】
- オーダー品につきまして高さの解釈がいくつかあり得ると思いましたので、簡易的な図ではありますが、お送りさせて頂きます。お考えの物(近い物)をご指示ください。
家具の設計士さんに学ぶこと（２）
- 【送られてきた設計図】
家具の設計士さんに学ぶこと（３）
- 【設計図のやり取りで救われたこと】
- 私は頭の中でBパターンを想定していたが、既存品はAパターンで制作されているとのこと。そして、本品を設置する場所、他の家具との兼ね合いを検討したところ、Dパターンでなければ、高さがフィットしないことが判明。→ 致命的なミスを防ぐことができた→ 加えて、(W)×(D)の解釈の確認も行うことができた
- 【学び】
- 先方は過去のミスオーダー・クレーム（？）の経験から、設計図による確認を行ったのかもしれない
- 解釈の違いにより、“相手が被る問題への配慮”ができているか否かで、その後の安心感が全く変わると思った
- 確認を受けた側からすると、サービスに対する信頼感（元々、普通に売買していたら生じなかったもの）がプラスされたことで、次もオーダーしたい気持ちになった
出来具合＝中身×粒度×深さ
出来具合＝中身×粒度×深さ
- 作る深さ－機能あたり何Page書く
- 要件 Checkする深さ－ページあたりのレビューと数
- 〃 指摘数
- 定義書
- ⇓
- 章立て
- やること
- ⇓
- タスク
進捗重視がもたらすもの
- × 進捗重視→ 手戻り増→ 品質悪化→ 納期遅延 （徐々に失敗リスクが増加）◎ 品質重視→ 手戻り削減→ 生産性向上→ 納期遵守 （進行に従いリスク減）
- 【イメージ図】
進捗重視がもたらすもの
- × 進捗重視→ 手戻り増→ 品質悪化→ 納期遅延 （徐々に失敗リスクが増加）◎ 品質重視→ 手戻り削減→ 生産性向上→ 納期遵守 （進行に従いリスク減）
- 【イメージ図】
- Requirement
- 要求/要件を定義
- ＿＿＿ ・ ＿＿＿
- ＿＿＿ ・ ＿＿＿
- ＿＿ ・ ＿＿
- ＿＿＿ ・ ＿＿＿
- 業ム
- システム
- MW、SW
- データ
- データ・I/F仕様は
- 固まったか？
- 外部
- 業ム要件は
- 固まったか？
- 判断基準
- （クライテリア）
- 技術的/コスト的に
- 実現可能か？
- ・データ
- ・I/F仕
- ・機能要件
- ・非機能要件
- 画面 interface
- バッチ、帳票
- 業ムは回るか？
- 必要十分か？
- テーブル
- 機能
- 非機能
- 変更可能性は
- 極小か？
- これらを一定の解像度で
- 計測→数値化することで
- 仕様確定のベースラインを作る
- 言語化・数値化
- 契約
- 変動を
- コントロール
- 想定・前提
- 外したら交渉
- ここから先は１度作ると
- 引き返し困難なもの増える
- これが狙い/ズレると
- あとでもめる
- 頭でわかっていても
- 先に進めざるを得ない
- ケースが多い
- 前提で縛る必要
- どうしても
- 進めるなら・・・
- 別の理由
イメージ図
手順・進め方
手法・理論
要件定義とは
- 目的とすることに対して 「明らかに要求と言えるもの」 「要求になくても必要なもの」を取捨選択し、一定の粒度に落とし込んで、適切に表現（言語化、数値化、図表化）する行為が要件定義であると考えます。
- 適切に要件定義を行う上で必要なのは
- 要求を引き出す（目的や背景、戦略、実現したい姿・・機能、非機能、技術、その他）
- 理由や問題の本質を掘り下げる
- 表現し提案する（フィードバックを言葉や数値、イメージに落とし込んで、確認）
- 整理・統合する
- 洗練する
- という振る舞い（業務プロセス）です
- 具体的な施策としては、「基本型の整備」にはじまり、事例の蓄積、要件定義スキルの向上、レビュー体制の構築などの「組織的な仕組み作り」を進めることで、底上げを行っていきます。
- 上記がきちんとできて、外部設計における落とし所が8-9割想定できるならば、要件定義後の見積りの精度は非常に高いものとなります。
