5th長崎QDG AFFORDDコラボセッション「要求開発のニューノーマル　～フルキットを実現するUSDM～」

要求開発のニューノーマル
派生開発推進協議会
古畑慶次
xddp@nifty.com
～フルキットを実現するUSDM～
＜AFFORDDコラボセッション＞
All Rights Reserved, Copyright Keiji Kobata, 2020
5th 長崎 QDG 2020年 10月 31日於：CO-DEJIMA
要求開発のニューノーマル～フルキットを実現するUSDM ～

自己紹介 1 / 28
古畑慶次（こばたけいじ）
＜所属＞：派生開発推進協議会 (AFFORDD) ／ (株) デンソーコアスキル開発部
－博士 (数理情報学) / 産業カウンセラー（JAICO認定）
＜業務＞：技術支援・指導、研修開発、講師
－派生開発､要求開発､システム設計､プロセス設計の技術支援・指導
－高度ソフトウェア専門技術者研修の企画、運営
－産業カウンセラーとしてカウンセリングも行う
1988年：名古屋大学大学院電子機械工学専攻修了
(株) デンソー入社研究開発部配属
1990年：基礎研究所・・・音声認識、デジタル信号処理
1994年：通信技術部・・・ソフトウェア設計 / ハードウェア設計
2002年： ITS 技術部・・・プロセス改善 / 現場支援
2004年：デンソー技研センター技術者育成、技術・現場指導
2015年：南山大学大学院数理情報研究科数理情報専攻修了
2019年：デンソーコアスキル開発部＜現在に至る＞
＜略歴＞
携帯電話
PHS
ナビゲーション
CMM

書籍ｰ日科技連出版社－
▪ ５ゲン主義現場リーダーの心得（2018年4月20日発刊）
▪ デンソーにおける
人づくり､価値づくり､ものづくり（2013年9月26日発刊）
2 / 28
▪ 古畑慶次［著］
▪ 主要目次
第１章５ゲン主義の定義と理念
第２章５ゲン主義の継承から再考へ
第３章５ゲン主義の実践
第４章管理
第５章問題解決
第６章人材育成
▪ 今枝誠・古畑慶次［著］
▪ 主要目次第５章価値づくり
第１章時代の大きな変化第６章ものづくり
第２章日本流のものづくりの原動力第７章デンソーにおける
第３章日本のものづくりの課題ものづくり研修の実際
第４章人づくり第８章次世代への提言

▪ 第5回世界ソフトウェア品質会議（2011年＠上海）
清水吉男氏－ USDM の発案者－ 3 / 28
筆者 (左) と清水吉男氏 (右)

派生開発推進協議会 4 / 28

Agenda
１．要求開発の昔･今
～ソフトウェア開発の問題を振り返る～
２．USDM：フルキットの実現
～ニューノーマルな方法論とは何か？～
３．まとめ
5 / 28

１. 要求開発の昔･今～ソフトウェア開発の問題を振り返る～
▪ プロジェクト遅延の要因
▪ システム開発に及ぼす要因
▪ アジャイル開発の現実
▪ 要求開発のソリューション
6 / 28

1.1 皆さんへのご質問
▪ ご自分の経験から考えてみて下さい
(1) プロジェクト遅延の主な原因は何でしょうか？
(2) システム開発に影響を
及ぼす要因は何でしょうか？
(3) アジャイル開発で (1)(2) は改善されましたか？
7 / 28

1.2 プロジェクト遅延の要因 (1) 8 / 28
出典：山下博之, 失敗しない要件定義とリスク対策～システム(再)構築上流工程の強化に向けて～, IPA/SEC, 2017

要求開発工程の不具合はプロジェクトに大きな影響を与える
＜件数比率＞＜修正工数比率＞
▪ 要求開発の問題
• 上流工程の不具合混入の数は少ないが、
プロジェクトに膨大な手戻り工数を発生させている
▪ 不具合原因（工程別）
29%
71%
出典：萩原賢一, IEEE830-1998に基づく要件定義の実践, SPI-Japan, 2011.
78%
22%
企画～ソフトウェア要求定義
ソフトウェア実装～総合テスト
開発

▪ プロジェクト遅延の要因
• 要求仕様の決定漏れ
✓ JUAS・ユーザー企業
ソフトウェアメトリクス調査2016
• 要件定義が長引いた
✓ 日経コンピュータ 2003年
問題は･･･
要件定義

1.3 システム開発に及ぼす要因 (1) 11 / 28
情報システム開発における課題
参考文献：情報サービス産業協会, 平成17年度情報サービス産業におけるソフトウェア開発の実態アンケート調査結果(概要), 2007.

1.3 システム開発に及ぼす要因 (2)
▪ システム開発に及ぼす要因
• 要件定義
✓ 情報サービス産業協会, 平成17年度
情報サービス産業におけるソフトウェア開発
の実態アンケート調査結果(概要), 2007.
• 要件定義
✓ JISA 情報サービス産業における
受託ソフトウェア開発実態
アンケート調査 2005
12 / 28
問題は･･･
要件定義
※ 本講演では「要件定義｣ → ｢要求開発｣とします
要求開発

1.4 アジャイル開発の現実 (1)
▪ 清水吉男氏のコメント
13 / 28
「アジャイル」な方法を使うと仕事が進む (ように感じる) の
は､短納期の中で実現する要求を限定することで､仕様を決定
しやすい状況が作られているからだと考えられます。
もちろん､今回の要求を仕様化 (実現) する中で､数回前のイテ
レーションで実装した仕様との間で矛盾が発生することは避けられ
ず､プログラムの修正が不可欠なものとなるはずです。
もしかすると､ここで昔と同じ混乱が起きる可能性もあります。
引用：清水吉男、要求の仕様化入門、Software People voL.4、技術評論社、2004.5.1

1.4 アジャイル開発の現実 (2)
▪ バックログ･インフレーション
• 要求の仕様化が適切にできなければ
不具合を次のスプリントに持ち越すことになる
14 / 28
プロダクト
バックログ
スプリント
バックログ
A
不具合
出典：永田敦, アジャイルテスティング, アジャイルと品質, SEA-SPIN, SEA-SPIN Meeting, June, 2012.
要求の仕様化技術がなければ
ライフサイクルモデルで問題は解決しない
B
C
D
A
B
C
D
スプリントスプリントスプリントスプリント
陥りがちな
失敗
※ プロダクト･バックログ
からタスクリストである
スプリント･バックログ
を作成する
※
※
※
※
タスク数

1.5 要求開発のソリューション (1) 15 / 28
出典：向山正秀, やっぱり上流からでしょう、第3期第1回ソフトウェア品質保証部長の会－第2期成果発表－、2011

▪ 要件定義の失敗要因：SQiP 品質保証部長の会 2011
• 要件漏れ・不足／要件のあいまいさ・要件のずれ
▪ 根本的な問題
▪ 本日のテーマ
• 設計前に万全の準備 (フルキット*) を提供する手段
USDM
(Universal Specification Describing Manner)
フルキット*：万全の準備（イスラエルの軍隊で語られる軍事用語）
「訓練で汗をかけばかくほど､戦場で血を流すことは少ない」
｢何が実現すればよいのか｣が
分からないまま設計作業に入る
要求開発の
ニューノーマル
現在も通用する
古くて･新しい課題

▪ 要件定義の失敗要因：SQiP 品質保証部長の会 2011
• 要件漏れ・不足／要件のあいまいさ・要件のずれ
▪ 根本的な問題
▪ 本日のテーマ
• 設計前に万全の準備 (フルキット*) を提供する手段
USDM
(Universal Specification Describing Manner)
フルキット*：万全の準備（イスラエルの軍隊で語られる軍事用語）
「訓練で汗をかけばかくほど､戦場で血を流すことは少ない」
｢何が実現すればよいのか｣が
分からないまま設計作業に入る
要求開発の
現在も通用する
古くて･新しい課題
要求開発のレベルを上げれば上げるほど､
開発で混乱することは少ない

２. USDM: フルキットの実現～ニューノーマルな方法論とは何か？～
▪ USDMの基本
▪ ｢5W1H｣を満たす項目
▪ 要求･仕様の構造化
▪ 仕様漏れを防ぐメカニズム
18 / 28

SQiP2019 併設チュートリアル
演習で学ぶ！要求の仕様化～USDMの基本を4時間でマスターする～
▪ USDMとは？
• 清水吉男氏が提案した要求を仕様化する方法
✓ USDM: Universal Specification Describing Manner
▪ USDMの構成
• 要求と仕様を階層構造で表現する
• USDMの3要素
✓ 要求：実現したいこと
✓ 理由：実現したい理由
✓ 仕様：具体的なやり方
2.1 USDMの基本 19 / 28
Req.1
理由
説明
Req.1.1
Req.1.2
Req.1.5
Req.1.6
要求
仕様
要求を仕様化する技術
表現する技術
清水吉男著
技術評論社 2010/5/1要求
仕様仕様仕様
要求
仕様
仕様
仕様

2.2 USDMの基本構造
▪ USDMの３要素
• 要求： What：実現したいこと＝最終的に実施すること
• 理由： Why ：実現したい理由 = なぜ､要求で示したことをしたいのか？
• 仕様： How ：要求を実現するために具体的にすること
20 / 28
理由
理由
What
How
具体化 Why
要求
理由
仕様
USDMの
基本構造
＜要求仕様書＞

2.3 ｢5W1H｣を満たす表現
▪ 要求の構造とUSDM
• ５W１Hによる整理
✓ 現実世界および要求を5W１Hの観点で整理する
– 複数の視点で複雑な現実世界や要求を漏れを少なく記述する
▪ USDM：要求仕様の表現方法
• 5W1H を要求･理由･仕様で階層的に整理する
21 / 28
＜5W1H＞＜要求仕様書の要素＞＜USDM＞
Why
（なぜ）
Who
（誰が）
What
（何を）
When
（いつ）
Where
（どこで）
How
（いかに）
要求
仕様
理由 Req.1
理由
説明
＜グループA>
Req.1.1
Req.1.2
＜グループB>
Req.1.3
Req.1.4
要求
仕様
参考: JISA REOK企画WG, 要求工学知識体系(REBOK) , 近代科学社, 2011

2.4 USDMによる要求仕様書
▪ USDMの要求･理由･仕様
• 要求､理由から仕様を作成する
• 要求の範囲が広い時は要求を階層化して仕様に展開する
22 / 28
Req.1
理由
説明
＜グループA>
Req.1.1
Req.1.2
Req.1.3
＜グループB>
Req.1.6
Req.1.7
Req.1.8
要求
仕様
• 実現したいことを
抽象的に表現する
• 要求の範囲を示して
仕様を引き出す
• 機能要求は
｢入力－変換ー出力｣
で表現する
その理由があると
・何が嬉しいのか？
・何が困るのか？
要求の具体的な
処理を記述する
＜要求＞
＜理由＞
＜仕様＞

This information is the exclusive property of DENSO CORPORATION. Without their consent, it may not be reproduced or given to third parties.
Req.1
理由
説明
Req.1.1
Req.1.2
Req.1.3
Req.1.4
Req.1.5
Req.1.6
要求
仕様
2.5 要求･仕様の構造化
▪ 要求・仕様の階層表現
• ピラミッド構造／MECE
• グループ化
✓ 要求､仕様を内容に合わせて
分類（仕分け）してまとめる
23 / 28
Req.1
理由
説明
仕様
仕様
<グループC>
Req.1-2-1
Req.1-2-2
要求
説明
Req.1-2
理由
<グループA>
<グループB>
要求
<グループD>
Req.1-1-1
Req.1-1-2
Req.1-1-3
Req.1-1-4
Req.1-2-3
Req.1-2-4
<Group 2>
要求
説明
Req.1-1
理由
<Group 1>
要求
仕様
仕様
・ピラミッド構造*
・ MECE **
ピラミッド構造*：
複雑なものを何段階にも小さく分けること
MECE** : 漏れなく、ダブりなく
(Mutually Exclusive Collectively Exhaustive)

▪ 機能要求：システムや製品に求められる「振る舞い」
• 機能の「振る舞い」と振る舞いの「範囲」を表現する
▪ 振る舞いの表現
• 「入力-変換-出力」で表現する
✓ 入力は「振る舞い」を起動する ”イベント” から始まる
✓ 入力から出力を示すことで範囲を明確に表現できる
▪ 機能要求の例
信号を受信したら､音声を認識し､認識結果を画面に表示する
2.6 機能要求の表現 24 / 28
入力変換出力
イベント
＝振る舞い
機能の｢振る舞い｣に含まれる動詞をすべて表現する

▪ 仕様化
• 要求に含まれる動詞に対する具体的な処理を記述する
✓ 仕様は動詞を「プログラムコード」に変換するために記述する
▪ 機能要求の仕様化
2.7 要求から仕様化へ 25 / 28
信号を受信したら、音声を認識し、認識結果を画面に表示する
「振舞い」の範囲に含まれる動詞をすべて表現し仕様化する
入力変換出力
イベント
信号を受信
受信データ
音声信号
の抽出
表示内容
の表示
結果の表示受信方法音声認識方法
振舞い
要求
仕様化

2.8 仕様モレを防ぐメカニズム
▪ 要求を仕様化してソースコードを作成
• 要求から “抜け漏れなく” ソースコードへ段階的に詳細化する
26 / 28
トレーサビリティを確保しながら詳細化する
動詞
～を～して＜要求＞
＜仕様＞
ソース
コード
動詞
～を～して
動詞
～を～する
動詞
～を～して
＋＋＋動詞
～を～して
＋
イベント
＜仕様グループ＞
・・・・・
・・・・・
・・・・・
仕様
個々の動詞 (～する) に対して
具体的な処理を記述する
仕様をコンピュータ－に処理させるために
プラグラムコードに変換したもの
＜仕様グループ＞
・・・・・
・・・・・
・・・・・
仕様

３. まとめ
▪ ソフトウェア開発の問題
▪ USDM：要求開発のニューノーマル
27 / 28

▪ ソフトウェア開発の問題
• プロジェクトの遅延
• システム開発 (品質) への影響
▪ USDM：要求を仕様化する方法
• USDMの基本構造
✓ 要求・仕様を階層的に表現
– 要求･理由･仕様で
｢5W1H｣を整理する
• 機能要求の仕様化
✓ 要求：｢入力ｰ変換ｰ出力｣で表現
✓ 仕様：要求に含む動詞を仕様化
– 動詞に対する具体的な処理を仕様化する
要求
仕様仕様仕様
３. まとめ 28 / 28
アジャイル開発で
解決したか？
要求開発
何が実現すればよいか
わからない
要求開発の
USDMによる要求仕様書
要求･仕様の階層構造
Req.1
理由
説明
仕様
仕様
<グループC>
Req.1-2-1
Req.1-2-2
要求
説明
Req.1-2
理由
<グループA>
<グループB>
要求
<グループD>
Req.1-1-1
Req.1-1-2
Req.1-1-3
Req.1-1-4
Req.1-2-3
Req.1-2-4
<Group 2>
要求
説明
Req.1-1
理由
<Group 1>

5th長崎QDG AFFORDDコラボセッション「要求開発のニューノーマル　～フルキットを実現するUSDM～」

Recommended

Recommended

More Related Content

Similar to 5th長崎QDG AFFORDDコラボセッション「要求開発のニューノーマル　～フルキットを実現するUSDM～」

Similar to 5th長崎QDG AFFORDDコラボセッション「要求開発のニューノーマル　～フルキットを実現するUSDM～」 (20)

More from NaITE_Official

More from NaITE_Official (20)