派生開発でUSDMとUSDMとDRBFM
DRBFMをミックスしてをミックスして一気通貫で品質確保する
気通貫で品質確保する～ おめさん、なじらね？ ～２０１１年２月１８日
NECソフト株式会社 新潟支社
酒井 賢

おめさん、なじらね？
▌ 「おめさん、なじらね？」は新潟弁で次のような意味があります。
▌ おめさん[omesan]
【意】あなた、お前さん【意】あなた お前さん「おめ」より丁寧ないい方です。
▌ なじ[naji]
【意】調子・様子・具合
新潟弁の基本で相手を思いやる 相手を気づかうこと
新潟弁の基本で相手を思いやる・相手を気づかうことを代表する言葉です。
© NEC Corporation 2011

目次
▌ １．自己紹介
１ 自己紹介▌ ２．プロジェクト概要▌ ３．プロジェクトのおかれた状況 （２００６年当時）▌ ４．プロジェクトの問題点▌ ５．抽出した課題▌ ６．課題を解決するための施策▌ ７．スケジュールと施策のタイミング▌ ８．施策１
施策 変更要求仕様書（変更要求仕様書（２００６年～）年 ）▌ ９．施策２ 心配点シート（２００８～）▌ １０．まとめ
１０ まとめ▌ １１．今後の課題▌ １２．最後に
１２ 最後に１．自己紹介▌ １９９３年入社で、今年１８年目です。
１９９３年入社で 今年１８年目です テスターを２年経験して、プログラマー５年を経験しました。
 そのあとサブリーダーを経て２０００年からプロジェクトリー
そ あとサブリ ダ を経て２０００年からプ ジ クトリダーをやっています。
▌ 初めてさわったパソコンはＰＣ－６００１でした。
初めてさわ たパソ ンはＰＣ ６００１でした▌ 主にプリンターのユーティリティソフトの開発に携わ てきました携わってきました。
 入社して最初に与えられた仕事は、
Wi dWindows
NT3.1のプリンタードライバーのテストでした。
NT3 1のプリンタ ドライバ のテストでした▌ この１０年間で４０案件程度を担当しました。
 大規模なシステムの一機能を担当するというものではなく、大規模なシステムの 機能を担当するというものではなく多いときでも５名程度のメンバーで、設計からテストまでを通して行うような形態の開発だけをやってきました
通して行うような形態の開発だけをやってきました。
Page 4© NEC Corporation 2011

２ー１．プロジェクト概要（１）▌ オフィス機器（ハードウェア）に添付されるＷｉｎｄｏｗｓ上で動作するユ ティリティソフトウェアの開発
作するユーティリティソフトウェアの開発▌ ソフトウェア単体では用をなさず、ハードウェアと通信を行うことで利用することができる▌ 要件の仕様化から製造、テストまでの工程を担当▌ お客様が新規開発を行い、当方が保守という形で２００３年
お客様が新規開発 行
当方が保守と う形
年に引き継いだ▌ 機種対応開発の他に、メンテナンスリリース、特定用途向けの開発がある

いわゆるPage 5© NEC Corporation 2011

派生開発

２ー２．プロジェクト概要（２）

派生開発とは
既存製品（システム）のソースコードがあって既存製品（システム）のソ スドがあ て新しい機能を追加したり既存機能の－部を変更したりして新しいバージョンのソフトウェア製品として開発する形※ソフトウェア・ピープルVol.8 「失敗しない派生開発」 (株)システムクリエイツ清水吉男氏の定義を引用しています
Page 6© NEC Corporation 2011

３．プロジェクトのおかれた状況 （２００６年当時）▌ 引き継ぎ段階で提供された以下の成果物からリバースエンジ
ニアリングした仕様書
 ソースコード 実行モジュール ヘルプ▌ サポートＯＳ 日本語版／英語版あわせて１２エディション▌ 規模：１２０ＫＬ▌ 開発言語
開発言語：ＶＢ６／ＶＣ
ＶＢ６／ＶＣ++６▌ モジュール数：２１モジュール▌ メンバーン：４名
４名 （（モジュール別に担当を割り当て）
ジル別に担当を割り当て）▌ サポート機種種別：日英で１２機種▌ 全ＯＳ、全機種対応のシングルソースコード、 機種対応Page 7© NEC Corporation 2011

４ー１．プロジェクトの問題点 １▌ デザインレビュー後に仕様の不明点/矛盾が判明
後戻りにつながる▌ どうして今の仕様になったのか経緯がわからない互換性を維持するための譲歩した設計が必要
互換性を維持するため 譲歩した設計が必要▌ ソースコードのどこを変更するとどこに影響するかがわからないデグレ ドが発生デグレードが発生要求を仕様化する技術、変更点の抜け漏れ防止
変更の追跡が必要
Page 8© NEC Corporation 2011

４ー２．プロジェクトの問題点 ２▌ ＯＳに依存する問題が発生する
設計時にすべてのＯＳで動作可能かの判断は難しい
設計時にすべてのＯＳで動作可能かの判断は難しい▌ ハードウェアに依存する問題が発生する
機種によって微妙に仕様が異なる▌ 非機能要件（操作性、性能）が実現できていない
総合テスト時に問題発覚

問題発生の未然防止の必要性
Page 9© NEC Corporation 2011

５．抽出した課題▌ どうやったら要求を正しく仕様化できるのか？
▌ どうやったら変更点を追跡できるのか？

要求の仕様化技術

変更点の追跡▌ どうやったら変更の影響範囲を特定できるの抜け漏れ防止か？
▌ どうやったら問題発生を未然に防止できるのか？

解決できるのか？？？
Page 10© NEC Corporation 2011

未然防止

６．課題を解決するための施策▌ 施策１
要求の仕様化技術
抜け漏れ防止変更点の追跡ＵＳＤＭ（Universal Specification DescriptionManner）の表記法を取り入れるメンバ が持ってきた本がきっかけ
メンバーが持ってきた本がきっかけ
私たちは「変更要求仕様書」と呼んでいます。
▌ 施策２
施策
未然防止
「コンサルタントが教失ＤＲＢＦＭ(Design(g Review Based on Failure える戦慄の仕事術
敗しない派生開発
敗しない派生開発」(Software PeopleMode)を取り入れる
Vol.８)
私たちは「心配点シート」と呼んでいます私たちは「心配点シート」と呼んでいます。

どちらも根底には徹底的なレビュ
どちらも根底には徹底的なレビュー
Page 11© NEC Corporation 2011

７．スケジュールと施策のタイミング
2003

2006/１１

2008/06

開発期間
ＵＳＤＭ（変更要求仕様書導入）
ＤＲＢＦＭ（心配点シート導入）要求の仕様化技術
変更点の追跡
抜け漏れ防止

未然防止

メンバ全員
メン全員

メンバ全員
ン 全員

でレビュー でレビュー

手法が成熟した段階で徐々に遂行
Page 12© NEC Corporation 2011

８－１．施策１ 変更要求仕様書（２００６年～）要求の仕様化技術

変更点の追跡

抜け漏れ防止▌ ＵＳＤＭ：Universal Specification Description Manner
(株)システムクリエイツ(株)システムクリエイツ 清水吉男氏が開発。
日本情報システム・ユーザー協会(JUAS)が表記法として「要求仕様定義ガイドライン」で取り上げている▌ システムに対する要求の階層構造を表形式で記述し、仕様漏れを防ぐ記法
1つの表に全ての要求・仕様を記述する
1つの表に全ての要求仕様を記述する
要求を2～3段の階層構造で定義する
各要求に対して、その要求が必要な理由を併記する
最下位の要求に対して仕様(その要求を実現するためのシステムの振る舞いＨｏｗ)を記述する
要求・仕様にはユニークなＩＤを付与する
もうひと工夫モジュール単位に列を作成してトレーサビリティマトリクス化

Page 13© NEC Corporation 2011

８－２．施策１ 変更要求仕様書 導入▌ 4プロダクト同時開発▌ 早速、本を数冊買ってきてメンバーに配布▌ 勉強会を実施▌ 見よう見まねでシートを作成して、やってみた変更要求列は本の通りに作成
トレーサビリティマトリクスはソースファイルを列にした▌ 効果はあった。同時開発自体は遂行。
ただし、
ただし▌ なかなか理由が書けない。要求から理由が導き出せないお客様を巻き込む必要性を痛感▌ ソースファイル単位では列が多すぎて結局、影響が追い切れない

カイゼ
カイゼンの余地あり
余地あり
Page 14© NEC Corporation 2011

８－３．施策１ 現在の変更要求仕様書の例①要求の階層構造をインデントで表
現②各要求に対し、必ず理由を併記③ユニークなIDを振る④要求に対する仕様を記載する。
Where ではなくHowを記載する

⑥総規模

⑤影響する
モジュール
列に改造規列
改造規模を記入「要求仕様定義ガイドライン」（日本情報システム・ユーザ協会(JUAS))および「入門十実践要求を仕様化する技術・表現する技術一仕様が書けていますか？」清水吉男箸（技術評論社）© NEC Corporation 2011
Page 15を参考に作成

８－４．施策１ 変更要求仕様書 導入（２）▌ Excelを使用する。１つのファイル（シート）にすべての要求と仕Elを使用する １つのフ イル（シ ト）にすべての要求と仕様（振る舞い）を記載する▌ 変更要求仕様書の要求事項、理由、仕様は、必ずプロジェクト
変更要求仕様書の要求事項 理由 仕様は 必ずプロジェクトリーダーが書く▌ 影響モジュ
影響モジュール、規模の見積もりは各モジュール担当が記入す
ル、規模の見積もりは各モジュ ル担当が記入するLine単位で記入する▌ お客様も交えてメンバー全員でレビューを行う
お客様の理由や思いを正確に把握するため
正確に仕様化されているか確認するため
変更点・影響範囲に漏れがないか確認するため
仮に、変更要求仕様書完成後、変更要求があったらその都度追記し、お客様も交えてレビ交えてレビューを行うを行う▌ 変更要求仕様書が完成するまでは設計に手をつけない▌ 各フェーズの成果物のレビュー毎にその機能が取り込まれているか照らし合わせる
Page 16© NEC Corporation 2011

８－５．施策１ 変更要求仕様書の効果要求の仕様化技術

変更点の追跡

抜け漏れ防止▌ 要求の真の理由を把握することで、適切な仕様化ができた後戻りがなくなった▌ 一覧化されていることで、どの派生開発でどの変更が入ったかわかるようになった▌ モジュールのトレーサビリティマトリクスで、変更に対する各モジュ ルへの影響がわかるようになった
ジュールへの影響がわかるようになったデグレードが発生しなくなった思わ 副産物
思わぬ副産物

メンバー全員がレビューに参加することで、自分の作業範囲だけでなく、その周辺も意識するようになった

変更要求が怖くなくな た
変更要求が怖くなくなった
Page 17© NEC Corporation 2011

９ー１．施策２ 心配点シート（２００８～）
未然防止▌ ＤＲＢＦＭ(Design Review Based on Failure Mode)とは
トヨタのＧＤ
ト タのＧＤ３（ジー・ディー・キューブ）の一翼をなすもの（ジ デキブ）の 翼をなすもの
吉村達彦氏の造語▌ 未然防止の手法
問題解決－現実に起こってしまった問題の原因を究明し、解決すること
再発防止－その問題が再度起きないように、防止するがこと
未然防止－まだ起きていない問題の発生を予測し、それが起きないように未然に防止すること
Page 18© NEC Corporation 2011

９－２．施策２ ＤＲＢＦＭ：未然防止手法とはＤＲＢＦＭ：とは変更点・変化変更点
変化
点と機能に着目

レビューによって心配点の発掘・探索◆ Ｇｏｏｄ Discussion（よいディスカッション）◆ Ｇｏｏｄ Design Review（よいデザインレビュー）（よいデザインレビ）

変更要求仕様書と親和性が高い
Page 19© NEC Corporation 2011

叡智を集め対策を作り込む◆ Ｇｏｏｄ Design（よい設計）

９－３．施策２ 心配点シート導入（１）▌ 本に書かれた通りのフォーマットを使用して導入
Excelで１行につき１つの心配点を記入
Excelで１行につき１つの心配点を記入▌ 記入やレビューに、とても時間がかかる▌ 穴を埋めて行を増やすだけの形骸化が見受けられた

プロジェクトのサイズを意識する必要あり
表は「トヨタ式未然防止手法ＧＤ３ いかに問題を未然に防ぐか」吉村達彦著 （日科技連）を参考に作成
Page 20© NEC Corporation 2011

９ー４．施策２ 心配点シート導入（２）▌ いろいろ試行錯誤し、DRBFMシートより簡素にし、必要十分な情試行錯 しト簡素にし 必 十分 情報のみを記入するようにフォーマットを変更－「心配点シート」▌ 変更要求仕様書に大要求単位でシートを追加する
「要求事項」
「理由」
 変更するに当たっての心「変更するに当たっての心配点」
「心配点を取り除くためにどんな検討/設計をしたか」▌ 変更要求仕様書のレビュー
時、各フェーズの成果物のレビュー毎に確認する。
心配点の追加があるかどんな設計対処をしたか
Page 21© NEC Corporation 2011

９ー５．施策２ 心配点シートの効果
未然防止▌ 設計段階で検出できる問題が増えた
後戻りがさらに減った
思わぬ副産物▌ 今までのレビューにプラスアルファされるだけなのでメンバーの負担が少ない▌ 問題発見の探索的な作業なので、メンバーが楽しんでできた▌ メンバーのコミュニケーションが活発になった▌ ベテランの経験が若手に伝わるテランの経験が若手 伝わる▌ ナレッジがどんどんたまっていった

未然防止に効果あり
Page 22© NEC Corporation 2011

１０ー１．まとめ：変更要求仕様書と心配点シートの位置づけ

要件書

設計

レビュー

確認＆
フ ドバ クフィードバック
レビュー
確認＆フィードバック

テスト
スト
Page 23

レビュー
レビュ© NEC Corporation 2011

変更要求
仕様書

製造確認＆
フィードバックレビュー１０ー２．まとめ：問題は解決したのか
No
No.

課題

テ マテーマ１

どうやったら要求を正し 要求の仕様
く仕様化できるのか？ 化技術

２

どうやったら変更点を追跡できるのか？
追跡できるか？

変更点の追跡３

どうやったら変更の影
響範囲を特定できるのか？

抜け漏れ防止４

どうやったら問題発生を未然に防止できるのか？

未然防止参考にした手法

・ＵＳＤＭ
変更要求仕・トレーサビリ 様書
ティマトリクス・ＤＲＢＦＭ解決できた！
Page 24© NEC Corporation 2011

呼び名心配点シート成果

１１．今後の課題▌ メンバー全員レビューが不可能な場合の方法を考えるメンバーが多い場合
拠点分散開発の場合
規模が大きくて機能が詳細に分割されており担当者が専任に者が専任になっているような場合
場合使うにはプロジェクトのサイズの考慮が必要

Page 25© NEC Corporation 2011

１２．最後に▌ システムやツールや手法はたくさんありますが、ソフトウェア開発は最後は 人」が主役だと思います。
フトウェア開発は最後は「人」が主役だと思います。
▌ 開発完了時に完成した最終版の「変更要求仕様書」と「心配点シ ト」は メンバ の叡智の固まり書」と「心配点シート」は、メンバーの叡智の固まりであり誇りです。
▌ そこには、気づき、コミュニケーション、チームワーク、経験、助け合い、なじらね など、人にしかできことがつまっています。
▌ 品質の向上は最終的にはそこにあると思います。
品質の向上は最終的にはそこにあると思います

Page 26© NEC Corporation 2011

おまけ▌ どちらも２０１１年１月２７日

東京
Page 27© NEC Corporation 2011新潟

おまけ １▌備えPage 28© NEC Corporation 2011

おまけ ２▌未然防止▌危険予知（危険予知（KYKY））▌経験Page 29© NEC Corporation 2011

おまけ ３▌助け合いPage 30© NEC Corporation 2011

おまけ ４▌気づきPage 31© NEC Corporation 2011

おまけ ５▌思いやりおまけ ６▌状況に合わせたツール

Page 33© NEC Corporation 2011

おまけ▌ 品質向上は雪かきに似ている▌ ほっておくと家がつぶれる▌ 玄関からも出られなくなる▌ やっても、やっても切りがない気がする▌ でも、春は必ずやってくる。
▌ 明るい、生き生きとした春を迎えたい。

参考文献▌ 「入門十実践要求を仕様化する技術・表現する技術一仕様が書けていますか？」が書けていますか？
清水吉男箸（技術評論社）▌ 「要求の仕様化入門」(Software「 求 仕様化(People Vol.4))
(株)システムクリエイツ 清水吉男箸▌ 「コンサルタントが教える戦慄の仕事術 失敗しない派生開発」(Software People Vol.８)
(株)システムクリエイツ 清水吉男著▌ 「トヨタ式未然防止手法ＧＤ３ いかに問題を未然に防ぐか」吉村達彦著 （日科技連）Page 35© NEC Corporation 2011

人と地球にやさしい情報社会をイノベーションで実現する
グロ バルリ デ ングカンパ
グローバルリーディングカンパニー

NECグループビジョン2017