コンシューマ製品開発における 要求管理プロセスの継続的な改善活動

㈱東芝 ソフトウェア技術センター

○藤原聡子、小森真紀

e-mail： satoko.fujiwara@toshiba.co.jp

SQiP2014

目次

はじめに

弊社における取り組み

コンシューマ製品開発における要求管理の難しさ

改善のステップ

3つの改善の取り組み ① スケジュールの認識共有の取り組み ② 仕様合意の早期化への取り組み ③ 変更の抑制への取り組み

まとめ

2

SQiP2014

はじめに

一般的な要求管理 要求管理とは 要求定義、要求分析、仕様化、仕様合意、変更管理などを行なう

要求管理に対する取り組み 体系化が進められており、分析手法、仕様化の観点、仕様の記述

方法、文書テンプレートなどがさまざま提案されている

弊社における要求管理の課題 組織や担当者により、手法の導入や実践の度合いには差がある 標準的なプロセスを統一的に導入することが難しい 役割や責任、権限が組織毎・製品毎等で異なる場合がある 仕様合意までの進め方などのプロセスが独自の文化になっている

3

組織・製品・プロジェクトをパターン分けし、 パターン毎に取り組みを推進

SQiP2014

部品 ソリューション

コモディティ化 差異化

BtoB

BtoC

パターンA パターンB

パターンC パターンD

標準化しやすい

標準化困難

要求最適化

課題解決

コンセプト実現

差分仕様明確化

弊社における取り組み

4

項目 パターンA パターンB パターンC パターンD売上向上の要因 案件数 案件規模 効率的展開 魅力的商品要求の粒度 詳細 課題 要望 コンセプト開発費 PJ単位 PJ単位 組織単位 組織単位要求に対するROI 明確 明確 不明確 不明確見積り精度と利益 直結する 直結する 直結しない 直結しないステークホルダ 顧客 顧客 営業／販社 商品企画ステークホルダ数 少ない 少ない 多い 多い要求仕様まとめ 本社サイド 工場サイド 本社サイド 工場サイド設計部門へのインプット 詳細 抽象的 詳細 抽象的仕様標準化 可能 困難 可能 困難ステークホルダのタイプ エンジニア 非エンジニア 非エンジニア 非エンジニア

BtoBの特徴 BtoCの特徴

標準化可能の特徴 標準化困難の特徴

要求管理ガイド (*)

パターンに当てはまらない特有の課題については、 個別の事情に応じた改善

ビジネス要因によってパターン分けし、 それぞれに適した要求管理のプラクティスを提供

顧客

営業

本社SE

アフタSE

PJL

設計

• 仕様書を作成し、仕様書にて顧客に合意を取る• 打合せでは、必ず議事録を取り、議事録にて承認を得る

ユーザ要求検討

仕様書作成

仕様書

仕様書確認

アフタSE作業見積り

議事録作成

変更・加分の再見積り、仕様変更、合意

仕様書

仕様書

仕様説明会

議事録

変更要求

長所：曖昧さが減り、要求の漏れや認識の齟齬による後戻りが減る短所：より多くのコミュニケーションコストの発生

顧客

アフタSE

本社SE営業

他の顧客

売込み 要求

仕様

仕様

要求

•要求のスコープと開発費を調整する

•顧客に対して窓口となる•受注活動が主な業務

•要求を仕様化する

•仕様を顧客に説明し、合意を獲得する

PJL

主にお金

主に技術

•見積もりする•設計をする

要求まとめ

開発費の工面

長所：アフタＳＥの技術力を生かし、実現性を踏まえた顧客交渉がしやすい要求フェーズから設計フェーズへの移行がスムーズ

短所：本社ＳＥの製品知識低下のリスクがある

工場サイド

該当するパターンから プラクティスを参考にする

(*) 「要求管理の為の組織パターン分類の提案」、プロジェクトマネジメント学会誌、2014年2月号

SQiP2014

コンシューマ製品開発における要求管理の難しさ

要求管理の作業負荷が高い 多数の関係者と常に調整・確認作業が必要 終盤まで、度々発生する変更への対応が必要

5

社内の関係者

仕様担当

商品 企画

ソフトウェア設計部隊

評価 部隊

ハードウエア開発部隊

営業

委託先

品質 保証

他製品 開発部隊

デザイン部隊

法務

認証 担当

現地 法人

その他

サービス 提供会社

知財

事業 団体

SW開発 部隊

社外

社内

製品開発 部隊

要求の ヒアリング

仕様の調整

仕様の調整

仕様の確認

仕様の調整

仕様の調整

仕様の調整

問い合わせ 対応

SQiP2014

改善のステップ

6

課題の 洗い出し 優先度付け 詳細な調査 施策検討 適用PJ選定

スケジュール策定 関係者への

説明 適用・

サポート 振り返り

施策の評価

(1) (4) (5) (6) (7) (8) (2) (3)

・詳細ヒアリング ・文献調査 ・データ分析

課題

リスク

緊急度、重要度、 適用タイミングから 優先度付けする

開発

改善 検討

施策の導入

施策の運用

施策の運用時期に 合わせて

改善検討の日程を組む

改善施策の確実な実践 施策適用前後の比較による評価

施策検討の メンバ

PJでの 運用メンバ

運用メンバを含め、 実践可能な施策を

検討する

施策検討段階で 適用対象PJを選定 着実な改善

SQiP2014

3つの改善の取り組み

仕様合意 時点

残件件数

時間

件数 合意件数

現状

目標

残件の扱いが曖昧で決定が遅れる

要求・仕様が決まらない

7

①スケジュールの 認識共有の取り組み

②仕様合意の早期化への取り組み

仕様変更が頻発する 変更の対応が漏れる・遅れる

③変更の抑制への取り組み

仕様変更・追加件数

SQiP2014

施策① スケジュールの認識共有の取り組み

課題：設計工程に入ってからも要求の変更が多く、要求・仕様がなかなか決まらない

施策： スケジュールの認識を共有する 標準工期を示すことで、適切な作業工期を確保する 作業を見える化することで、適切な時期に作業が着手・実施される

設計工程以降も変更が多く、要求・仕様が決まらない

ソフトウェアの変更は容易だと勘違いされている

作業の進め方や必要な工期・工数などを互いに知らない

要求・仕様の合意が不十分 本当の要求の理解不足

実現性の考慮が不十分

8

SQiP2014

施策①-1 - 標準的な作業工期とプロセスの定義

中項目 期間

1-A. 要求定義 ○ 週間

1-B. 要求合意 ○ 週間

1-C. 仕様策定 ○ 週間

1-D. 仕様合意 ○ 日

大項目 期間 1. 要求・仕様合意 ○ ヶ月

2. 設計 ○ ヶ月

3. 実装 ○ ヶ月 4. 総合検査 ○ ヶ月

テーラリング 規模や開発体制など に応じて調整する

テーラリング • 必要な追加作業・不必要な作業を見直す • 作業順序の入れ替えや代替手段を検討する

標準的な作業工期の定義 • 着手すべき時期、確保すべき工期を提示し、計画の参考にする

適切なリソースの見える化 作業の担当者と成果物の明確化

標準的なプロセスの定義 • 作業の担当者と成果物を明確にする

9

SQiP2014

中工程 期間

1-A. 要求定義 ○ 週間

1-B. 要求合意 ○ 週間

1-C. 仕様策定 ○ 週間

1-D. 仕様合意 ○ 日

施策①-2 - 作業の担当と成果物・期限の合意

中工程 1-A. 要求定義 1-B. 要求合意 1-C. 仕様策定 1-D. 仕様合意

期間 *週間 *週間 *週間 *日

イベント

○○ 部門

仕様 担当

設計 部隊

要求提示

ヒアリング ・認識共有

工数 見積り

社内展示会(mm/dd)

要求提示期限(mm/dd)

要求・仕様 調整

合意期限(mm/dd)

工数 見積り 結果

仕様 詳細化

A社と商談

要求変更 依頼

追加要求受付期限(yy/mm)

期限の合意

アウトプットと 担当の合意

要求 仕様書

担当と成果物 の合意

要求調整

作業の担当者と成果物を合意 期限を明記し合意

イベント

作業

成果物

期限の合意

プロセス 定義

作業の遅延や無駄な後戻りを低減

10

SQiP2014

効果の計測：仕様書の変更ページ数を指標とした

評価結果

施策① - 効果

11

仕様合意を強化 仕様の変更数や 変更の規模が低減

仕様書の変更ページ数、 変更ページ数の比率が低減

各仕様書の変更ページ数の 比率の平均が約14%低減

仕様合意後の 仕様書の変更ページ数の平均が約20%削減

過去PJ 今回のPJ

過去PJの平均比率 ：30％

今回のPJの平均比率 ：16％

SQiP2014

施策② 仕様合意の早期化への取り組み

課題：仕様の合意が明確でなく、仕様調整の残件の扱いが曖昧になり、仕様変更や決定完了の遅れが発生する

施策：合意すべき仕様の項目をテンプレート化し、残件管理を確実に実施する 関係者間で必要十分な仕様を確実に確認する 残件の管理を明確に実施する

仕様調整の残件の項目や状態が曖昧

合意すべき項目が曖昧 残件管理の方法が曖昧

すべての仕様の決定完了が遅い 仕様変更が多数発生する

確認・合意が不十分

12

SQiP2014

施策② - 施策と効果 要求リスト 要求概要書

機能一覧

機能概要

機能仕様書

×簡潔すぎてイメージが伝わらない

すべての機能を記載

重要な機能について 概要仕様を各1頁で説明

変更点のみ 記載

×記述が詳細すぎて、 全体を把握しきれず 合意が困難

•商品企画等と設計との早期合意 •イメージの共有で コンセプトの具現化を確認

必要十分で最適な粒度の仕様テンプレート

効果：残件を解決するまでの期間が 過去プロジェクトと比較して半減

残件項目、 残件となった理由、

残件を解決する担当者、 残件を解決する期限

を合意

・背景／コンセプト ・ユースケース・システム構成 により理由や利用イメージ

を確認

13

SQiP2014

課題：変更管理が不十分なため、安易な仕様変更が頻発する、変更の対応が漏れる・遅れる、などの混乱が頻発

施策：チケットによる変更管理の導入 変更に関する情報を共有化する ルールに則った変更管理を実施する

施策③ 変更の抑制への取り組み

変更の影響の見積もりが 不十分

変更の対応が漏れる・遅れる

変更の対応可否が適切に判断されていない

必要な関係者に適切なタイミングで情報共有されていない

変更に対する対応者やステータスが曖昧

安易な仕様変更が頻発

変更管理のルールがない

14

SQiP2014

施策③ - 施策と効果

効果： 過去プロジェクトと比較して、開発後期の安易な要求・仕様変更を

1/4程度に低減 情報共有不足による開発の混乱を低減

変更 依頼元 変更

依頼 PM

確実に情報を Inputする

安易な 変更が減る

プロジェクト管理ツール Redmine

対応判断のために 必要な情報共有や作業が

確実に実施される

設計リーダー

仕様担当

設計チーム

すべての変更 が共有される

担当が 明確になる

15

SQiP2014

まとめ

コンシューマ製品開発の要求管理における課題の改善に取り組み、仕様合意の早期化や開発の混乱を低減

今後の取り組み 施策の横展開 関係者の多い製品開発では、SwimLane形式のプロセス定義やスケ

ジュールの合意の取り組みは有効 仕様合意早期化のための文書テンプレートやチケットによる変更管理

は、他製品開発にも適用可能 開発事情に応じた新たな課題への取り組み

16

取り組み 効果 ①スケジュールの認識共有の取り組み 仕様合意後の仕様書の変更ページ数の

平均が約20%削減 ②仕様合意の早期化への取り組み 残件を解決するまでの期間が半減 ③変更の抑制への取り組み 開発後期の安易な要求・仕様変更を

1/4程度に低減

SQiP2014