メトリクスとデータ活用（数値化ガイド・特性要因図・ベースライン）

F-5 KPI・測定設計 ＞ F. 実行計画（プロジェクト） 元資料: ◆メトリクス、データ活用【第2編】（15枚）

目的・概要

◆メトリクス、データ活用

• #メトリクス・データ活用

考え方・観点

目的と目標、進み具合の関係性

• （大きな）
• 目的
• （目的に対する）やや大きな目標
• 小さな目標
• 「何を・何のために」やるのか
• 「いつまでに・どれくらい」やるのか
• 日々の進み具合や
• 達成レベルを
• どうやって見るか
• （目的に対する）やや大きな目標
• （目的に対する）やや大きな目標
• 目的：到達したいレベルや場所
• 例）目的地・富士山山頂、100歳まで生きる
• 目標：そこにたどり着くためのゴール設定
• 例）1日50km、1日一万歩、健康診断B以上
• メトリクス：ゴールに達するための行動や活動の目安（小さなゴール）
• 例）まず3キロやせる、お酒を減らす、・・
• #メトリクス・データ活用

目的・目標・数値化について

• テーマ（健康、体力増進、人生100年に関して）
• 目的は、(テーマに沿って)誰にでも伝わる「言葉で書かれた(最終)到達点」言葉＞数値5-10%
  • ★あなたは(テーマに対して)(最終的に)何を達成したいですか？
  • 例）80歳まで元気に暮らせる体を作る
• 目標は、目的に照らした「大まかな行動」　／【KGI】・・グルーピングがミソ！言葉＞数値20-30%
  • ★達成したいことに対して、あなたはどんな行動をとりますか？（大まかなレベルで）
  • 例）・健康診断で定期チェックする　・食事に気をつける　・頭をつかう　　 　・趣味を持つ　・友達をふやす・・など
• メトリクスは、目的を達するための「具体的な行動と数値目標」　／【KPI】言葉＜数値60-70%
  • ★目的に向けて、あなたは具体的にどんな行動をとり、どの数値でその結果を確かめますか？
• 例）・健康診断→1日1万歩をまず3か月続ける、・頭を・・→月2冊本を読む、
• #メトリクス・データ活用

身近な例→品質確保における例

• 大目的：SIerとして安定した提供品質を確保する
• ＜中骨＞
• ① お客様やプロジェクトの特性を整理する
• ② 基準づくりのためのデータを収集する
• ③ 品質のよしあしを判断する基準をつくる

---

• ④ お客様が実現したい内容(要求)を正しくとらえる
• ⑤ 要求に沿った段階・工程ごとのチェック項目を整備する
• ⑥ 出荷後も含めた、統合的な品質と顧客満足を可視化する
• #メトリクス・データ活用

目的・目標を伴った数値化ガイド

• #メトリクス・データ活用

曖昧ワードと目標値設定について

• #メトリクス・データ活用

システム開発における特性要因図

• システム開発に関する特性要因を下記に示す
• 1. 人（Man）
• 2. 方法（Method）
• 3. 機械・ツール（Machine）
• 6. 環境（Mother Nature / Management）
• 5. 測定（Measurement）
• 4. 材料（Material / Requirements）
• キー担当者の不在時リスク
• リソース不足による検証時間の圧縮
• 品質基準・合格条件の定義不足
• リスク対応計画が未整備
• バグ管理ツールの活用不足
• 品質検証環境と本番環境の差異
• 外注先の品質管理体制が不透明
• 他部署やベンダー間の品質認識のずれ
• 不具合管理指標の不徹底（重大度の判断が曖昧）
• レポート更新の遅れによる判断ミス
• 要件の不安定さ（変更頻発による品質劣化）
• 外部仕様・API定義の曖昧さによる不具合発生
• システムを計画通りにリリースする
• 品質ゲートの曖昧さ（レビュー・承認が形骸化）
• テスト工程の遅れ／形式的な消化
• テスト自動化ツールの未導入／未整備
• 静的解析／コード品質チェックの不足
• 品質意識の差（レビュー基準の理解不足）
• テストスキル不足（テスト設計が属人化）
• 品質レビューのフィードバックが活用されない
• テストデータの不足／不備
• マネジメント層の品質レビュー不参加
• 品質KPI（不具合収束率、テスト網羅率）の未設定
• セキュリティ要件が後追いで追加
• 品質より納期優先の文化
• ※骨は6Mで構成を行い、やや品質要素に力点を置いて抽出した
• #メトリクス・データ活用

6Mについて

• 6Mは、フィッシュボーン図（特性要因図）を使う際によく使われる、原因を網羅的に整理するためのフレームワーク。6Mを使うことで、「人だけ」や「ツールだけ」といった偏りを防ぎ、原因を多角的に洗い出すことができる
• 製造業発祥であるが、システム開発に当てはめても「Man＝開発者」「Material＝要件やデータ」「Machine＝開発ツール」といった形で置き換え可能。品質管理の場面では、不具合や遅延の原因がどのMに偏っているかを整理するのに役立つ | 6Mの構成要素 | 例示 | | --- | --- | | 1. Man（人）：人材・スキル・役割・モチベーションに関わる要因 | 例：担当者の経験不足、教育不足、リソース不足、属人化 | | 2. Method（方法）：作業の進め方・手順・プロセスの適切さ | 例：レビュー手順が曖昧、テスト計画不足、リスク管理の形骸化 | | 3. Machine（機械・設備・ツール）：使用する機器やシステム、開発ツールの状態や整備状況 | 例：開発環境の不安定さ、自動化不足、バージョン管理の不徹底 | | 4. Material（材料 / インプット）：材料や入力情報、要件やデータの質 | 例：要件が曖昧、仕様変更が頻発、テストデータ不足 | | 5. Measurement（測定）：品質管理・進捗管理の測定指標やチェック体制 | 例：KPI未設定、進捗報告が遅い、品質基準が不明確 | | 6. Mother Nature（環境 / Management）：外部環境や組織文化、経営方針など | 例：経営層の意思決定の遅れ、部署間調整不足、外注管理の不備 |

ソフトウェアデータ白書・メトリクス要素の関係性

• #メトリクス・データ活用

メトリクス情報・入出力の関係図

• （既存）
• 維持管理情報
• （終了時）
• PJ属性
• 基本設計
• 終了時点
• で明確に
• なるはず
• （新規）
• 契約時
• （終了時）
• メトリクスデータ
• 更新
• （終了時）
• 属性付加情報
• 参照→取り込み
• ※年1回
• ・・計画チームが更新（？）
• （QUX）
• PJ属性
• マスタ
• システム
• 基本情報
• 参照→取り込み
• #メトリクス・データ活用

メトリクス１レコードの持ち方

• PJ（親）
• PJ（子）
• PJ分析用レコード
• PJ（親）
• PJ（子）
• PJ（子）
• PJ（子）
• ★データ利活用の想定
• ←　ポイントは、ほしい切り口で
• このレコードが分割できているか
• 特性別
• サブシステム別
• 部門別
• 人別？
• 分析
• モデル化
• メトリクス利活用の目的に依存するが、
• レコードイメージとして望ましいのは、
• 品質や生産性を左右する単位
• （＝私の見解は「チーム」）
• で１レコードのメトリクス情報が
• 作られることと思っています
• #メトリクス・データ活用

ベースラインと生成する指標のイメージ

• システム化計画
• 要件定義
• ベースライン
• 実績管理
• 基本設計
• 詳細設計
• 製造UT
• ITaITb
• ST
• UAT
• C/O
• 要求数
• 現状課題,企画案
• RFP, Mtg, Q&Aなど
• 仕様書, Mtg, Q&Aなど
• 要件数
• 機能数（テーブル、処理）、パターン数
• 機能
• 非機能数（性能、互換性、使用性、信頼性、セキュリティー、保守性、移植性）
• 品質
• 必要資源（ハードウェア（サーバー・ネットワーク）、実装アプリ、パッケージ）
• 技術
• Page数、章立て、文字数、etc.
• 成果物
• Input
• Evidence
• メール, 課題表, 各種台帳等
• 指標設定
• 要件定義書
• 外部設計書試験仕様書
• ↓計画に利用
• この解像度が粗いと交渉、進捗・品質判定が難航する
• ◆計画の精緻化→ ◆指標設定→ ◆実績管理
• 契約書／前提条件
• Output
• 要求仕様書
• 内部設計書
• 試験仕様書
• プログラム,テスト報告
• テスト報告
• テスト報告
• 工数、役割別要員数、要員コスト、リスク費用、etc.
• ◆開発前提の明確化　　→ ◆開発規模、技術・品質要件の把握（数値化）
• ■ 外部設計の品質判定の例　→ ドキュメントPage数／機能数　：　設計書密度の妥当性　→ レビュー時間／機能数　：　レビュー時間の妥当性　→ 指摘数／機能数　　：　指摘の十分性（指摘種別により妥当性）　→ データ機能数／処理機能数　：　テーブル定義の十分性　・・など
• ※ 規模（機能）に対するPage数が妥当と判断できれば、　　　「指摘数／ドキュメントPage数」 という指標も有効
• ■ 内部設計以降の見通しの例　　→ 工数予測、リスク予測、コスト算定　　→ スケジュールの妥当性判断　　→ 品質計画、テスト設計　　→ 成果物の妥当性判定　　・・など
• ブレにくいレベルで計測

ベースライン×実測による可視化の例(1)

• 出典： IPA/SEC ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」

ベースライン×実測による可視化の例(2)

• 出典： IPA/SEC ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」

ベースライン×実測による可視化の例(3)

• 出典： IPA/SEC ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」

イメージ図

手順・進め方

手法・理論

定量データが少ない段階でモデル構築を進めるやり方

• データ標本数が少ない段階では、見たい状態を想定し、仮説をたて、仮想モデルを構築することで、現場のニーズに応えていくことが現実的な進め方
• #メトリクス・データ活用
• 何の傾向が
• 見たいか？
• （例）
• 品質
• 生産性
• コスト
• 期間
• の適切性
• 過去のデータ
• 収集
• 分析
• モデル化
• 仮説を
• たてる
• 2次データ
• 仮想モデル
• 構築
• 十分性に
• 課題
• 計測と収集データの
• 構築と改善
• データを使い
• 品質・効率
• の改善、
• コストやリソース
• の最適化に
• 持続的に
• 活かす
• 信頼性に
• 課題
• 改善事項
• 見たい切り口の
• 提供
• 素早くフィードバック
• ←　　　　　　　中長期的に分析・モデル化を進める　　　　　　　→
• ↑重要なのはここ
• 見せ方
• を工夫
• ←検証を進めつつ,短期ニーズにも応じる→

テンプレート・ツール

事例・サンプル

参考リンク

構築中・WIP

顧客別事例