• 検索結果がありません。

ソフトウェア品質マネジメント能力を高めれば組織は強くなれる

N/A
N/A
Protected

Academic year: 2021

シェア "ソフトウェア品質マネジメント能力を高めれば組織は強くなれる"

Copied!
38
0
0

読み込み中.... (全文を見る)

全文

(1)

ソフトウェア品質マネジメント能力を

高めれば組織は強くなれる

東洋大学経営学部 野中 誠

2012年3月13日

Prowise Business Forum in Tokyo(株式会社日立ソリューションズ)

「第57回 組織的に取り組むソフトウェア品質マネジメント」

(2)

野 中 誠

http://www.se.mng.toyo.ac.jp/profile/ • 所属 – 東洋大学経営学部経営学科 准教授 • 背景 – 工業経営/経営システム工学、ソフトウェア工学、品質管理 – 学生時代は、オブジェクト指向を中心にソフトウェア開発技術も頑張った • 主な学外活動 – 日本科学技術連盟 SQiPソフトウェア品質委員会 副委員長 – 日本SPIコンソーシアム 外部理事 – 国立情報学研究所 特任准教授 (トップエスイーでメトリクスの講義を担当) – IPA/SEC 定量的管理基盤WG 主査、定量データ分析WG 委員 – 情報処理学会ソフトウェア工学研究会 運営委員 など • 主な書籍 – 共著 『ソフトウェア品質知識体系ガイド-SQuBOK Guide-』 オーム社 (2007) – 野中・鷲崎訳 『演習で学ぶ ソフトウェアメトリクスの基礎』 日経BP (2009) • 専門分野・主な関心事 – ソフトウェア品質管理(特にメトリクス) – ソフトウェア品質へのシステム思考の適用 • Twitter, email @MakotoNonaka nonaka-m@toyo.jp

(3)

講演概要

ソフトウェアのプロジェクトにおいて、品質・コスト・納期の

バランスがよく議論されます。

これらのうち、コストや納期から考え始めると、

品質は良くならず、組織の品質マネジメント能力は停滞します。

品質を第一に考え、品質マネジメント能力の強化に取り組むことで、

はじめて、コストや納期が管理可能になります。

この基本原則を軸に据えて、ソフトウェア品質の開発・管理技術の

改善に向けて組織的に取り組まなければ、ソフトウェアビジネスの

事業継続は難しくなるでしょう。

この講演では、ソフトウェア品質マネジメント能力を高めるために

必要なステップを概観し、とくに定量的管理やレビュー技術に焦点を

当てて、その手法や事例を紹介します。

(4)

Contents

1. イントロダクション

– 品質にしっかりと取り組めば、組織は賢く、強く、幸せになれる

2. プロジェクト管理に活かすソフトウェア品質技術

– 欠陥の数え方・分類 – 欠陥除去能力を表すメトリクス、工程移行判定に用いるメトリクス – fault-proneモジュール予測

3. レビューに活かすソフトウェア品質技術

– レビュー目的の明確化 – チェックリストの選別、連想キーワードの選定

4. プロセス改善/要求定義に活かすソフトウェア品質技術

– 技術者行動の構造を理解した上でのプロセス改善 – ビジネス構造を理解した上でのIT導入(要求定義)

5. おわりに

(5)

一番お伝えしたいこと

品質にしっかりと取り組む

– ソフトウェアを通じて顧客に提供する価値は何か、これを定義する – その価値によって、高いレベルの顧客満足を維持し続けられるために 組織にとって「必要な活動」は何か、これを定義し、実践する

必要な活動

– 顧客価値を提供/創造できるソフトウェアは何か、これを考える – ソフトウェア開発のスピードを加速させる/低下させないために、 欠陥の検出・除去・混入予防に必要な活動を定義し、継続的に実践する

組織が賢く、強くなる

– 価値を提供した結果を評価し、「必要な活動」へとフィードバックする – 欠陥に学び、 「必要な活動」へとフィードバックする – 価値評価/欠陥の経験があるからこそ、意味あるフィードバックができる – 一連のフィードバックを積み重ねることで、組織は賢く、強くなれる – 賢く、強くなれた組織は、幸せになれる

2012/3/1 Makoto Nonaka, Toyo University 5

(6)

品質に取り組むことで、組織能力と深層の競争力を強化する

• 組織能力と深層の競争力が、表層の競争力やビジネスの成果を生み出す • 品質にしっかりと取り組むことで、深層の競争力が強化される • 品質にしっかりと取り組むことで、組織能力が培われていく 深層の競争力 (エンジニアリング) 表層の 競争力 ビジネス の成果 環境要因 組織能力 -製品の訴求力 -広告・プロモーション -販売チャネル -・・・ -収益性 -安定性 -効率性 -・・・ -開発技術 -品質技術 -プロセス ー プロジェクト管理 -知識・経験 -行動様式 -組織文化 -価値観 「品質にしっかりと取り組む」ことで直接的に強化できる領域

(7)

品質に取り組めば、コストは下がる

品質に取り組む効果の発現順序

1. 外部失敗コストの低下 – 評価に関する活動に投資し、 外部失敗を内部失敗へと振り分ける 2. 内部失敗コストの低下 – 評価と予防に関する活動に投資し、 欠陥を早期に除去できるようにする 3. 評価活動の効率向上 – 評価活動の改善と予防活動に投資する – 評価活動を戦略的に「間引き」する – 予防コストの安易な削減はしない 4. 総品質コストの低減・安定化 – 評価活動の戦略的な「間引き」が機能 不全に陥らないよう、予防活動に投資

Makoto Nonaka, Toyo University 7

• 一定の品質コストはつねに必要、しかし、その効率向上を追求し続ける必要がある • 安易な品質コストの削減は、取り返しのつかないところまで組織能力を衰退させる 2012/3/1 品質マネジメント能力の成熟度 プロジェクトに占める品質コスト 外部失敗コスト 内部失敗コスト 評価コスト 予防コスト

(8)

講演の全体像

欠陥の記録・測定 《失敗の記録》

<定量データ> <定性データ> <リッチ情報>

プロジェクト

管理

レビュー

要求定義

プロセス改善

欠陥に学ぶ 《失敗からの学習》

ソフトウェア品質技術

(9)

2. プロジェクト管理に活かすソフトウェア品質技術

2012/3/1 Makoto Nonaka, Toyo University 9

レビュー

要求定義

プロセス改善

欠陥に学ぶ 《失敗からの学習》

・欠陥の数え方、欠陥の分類

・欠陥除去能力を表すメトリクス、工程移行判定に用いるメトリクス

・fault-proneモジュール予測

プロジェクト

管理

欠陥の記録・測定 《失敗の記録》

<定量データ> <定性データ> <リッチ情報>

(10)

市場流出欠陥のベンチマークデータ

項目 インド 日本 米国 欧州他 合計 or 平均 調査対象のプロジェクト数(件) 24 27 31 22 104(合計) 新規コード行数(KLOC, 中央値) 209 469 270 436 374 出荷後の欠陥密度(中央値) 0.263

0.020

0.400 0.225 0.150

日・米・欧・印のパフォーマンス比較

(Cusumano et. al., 2003)

Cusumano, M., et. al., “Software Development Worldwide: The State of the Practice,” IEEE Software, Nov/Dec 2003, pp.28-34.

皆さんの組織での市場流出欠陥は、このデータに比べてどうですか?

そもそも「出荷後の欠陥密度」は、信頼できるメトリクスですか?

(11)

欠陥の測定と、測定精度確認の実態

SQiPソフトウェア品質保証部長の会での調査(N = 21)

2012/3/1 11 25% 20% 45% 0% 10% 品質部門が粒度を定義している 粒度は開発メンバーに一任だが、 測定精度は品質部門が確認している 粒度と測定精度は 開発メンバーに一任している 設計仕様の欠陥は数えていない その他 20% 15% 40% 10% 15% 品質部門が粒度を定義している 粒度は開発メンバーに一任だが、 測定精度は品質部門が確認している 粒度と測定精度は 開発メンバーに一任している ソースコードの欠陥は数えていない その他

設計仕様の欠陥

ソースコードの欠陥

定量的品質管理の基礎として

欠陥の測定がある

しかし、その粒度定義と、

測定精度の確認を行っている

企業は少ない

「ソフトウェア品質保証部長の会」からの情報発信「第1部:SQiPソフトウェア品質保証実態アンケート2010(プレ調査版)」 SQiPソフトウェア品質シンポジウム2010講演資料 http://www.juse.or.jp/software/200/attachs/file917-2.pdf

(12)

上流工程での欠陥除去率に関する期待外れな行動

例:「上流工程での欠陥除去率 75% を目標としましょう」

上流工程での欠陥除去数: 1件 予測された欠陥混入数: 4件 欠陥除去率の予測値: 1/4 = 25% いま、上流から下流工程への移行判定をしようとしている 欠陥の粒度は、技術部門に委ねているとする 「少なくとも、欠陥をあと2件見つけないと次に進めません」 と、技術部門に指示した 出荷を急ぐ技術部門が取り得る対応 ・ 除去済み欠陥を3件にスプリットする (!) ・ 見かけ上の欠陥除去率は、3/4 = 75% (!!)

欠陥の粒度のガイドラインを定めておく必要がある

(13)

Q1:何件の欠陥と数えるか?

設計レビューで、設計仕様書の誤記を発見した。

当該個所

1個所

を修正したのち、これに伴って変更を要する

2個所

(設計仕様書内)を修正した。

Makoto Nonaka, Toyo University 13

設計仕様書 … … … … … × … … … … … … … … …

この場合、何件の欠陥として

カウントしますか?

1? 2? 3? それ以上??

2012/3/1

(14)

Q2:何件の欠陥と数えるか?

結合テストで、プログラムの振る舞いの問題を発見し、

原因が設計仕様にあることが分かった。

設計仕様書の当該個所

1個所

を修正したのち、

これに伴って変更を要するソースコード

2個所

を修正した。

設計仕様書 … … … … … × … … … … … この場合、何件の欠陥としてカウントしますか? 1? 2? 3? それ以上?? ソースコードA … … … … … … … … … … … … … … ソースコードB … … … … … … … … … … … … … … … … … … … … …

(15)

Q3:何件の欠陥と数えるか?

(続き)その後のシステムテストで、

(2)と同じ対応をし忘れたソースコード

2個所

を発見し、

これを修正した。

Makoto Nonaka, Toyo University 15

この場合、全体として何件の 欠陥としてカウントしますか?

1? 2? 3? 4? 5? それ以上??

設計仕様書 … … … … … × … … ソースコードA … … … … … … … … … … … … … ソースコードB … … … … … … … … … … …… … … … … … … … … … ソースコードC … … … … … … … … … … … … … … … … … … … … ソースコードD … … … … … … … … … … …… … … … … … … … … … (2)での対応の範囲 2012/3/1

(16)

参考:SQiPシンポジウム2010

メトリクスSIGでのアンケート結果(N = 30)

19 1 3 2 1件 2件 3件 目的により異なる 17 3 5 1件 2件 3件 8 11 1 1 3 1 1件 2件 3件 4件 5件 目的により異なる ・数え方は組織によって様々、 結果がばらつくのは当然 ・しかし、同一の組織の中で これだけばらついていたら、 欠陥の測定に基づく管理は 有効に機能するだろうか?

Q1

Q2

Q3

野中(2010)「ソフトウェア品質の定量的管理における曖昧さ-ソフトウェア欠陥測定の原則-」『経営論集』pp.99-109,東洋大学経営学部

(17)

IEEE標準における欠陥関連用語

Makoto Nonaka, Toyo University 17

用語 定義(筆者訳) 出典のIEEE標準 欠陥 (defect) 障害(fault)または故障(failure)のいずれかを言及できる一般的用語。 982.1-2005 障害 (fault) (1) ハードウェアデバイスまたはコンポーネントの欠陥(defect)。 (2) コンピュータープログラム内の,不正確なステップ,プロセス, またはデータ定義。一般には,エラー(error)やバグ(bug)をこの意味に 用いる。 610.12-1990(R2002) 故障 (failure) システムまたはコンポーネントが,指定された性能要求の範囲内で要求 された機能を果たせないこと。 610.12-1990(R2002) エラー,

誤り (error) (1) 正しい結果と,観測された結果の相違。狭義のerror。 (2) 不正確なステップ,プロセス,またはデータ定義。狭義のfault。

(3) 不正確な結果。狭義のfailure。 (4) 不正確な結果を生み出した人間の行為。狭義のmistake。 610.12-1990(R2002) 不正 (anomaly) 要求仕様,設計文書,ユーザ文書,標準,または誰かの認識もしくは体験など,これらに基づく期待から乖離した状態。 1044-1993(R2002) 1028-2008 文書において,またはソフトウェアもしくはシステムの運用において観 測された,期待から乖離したものすべて。ただし,期待は,検証済みの ソフトウェア製品,リファレンス文書,または指定された振る舞いを記 述したその他の情報源に基づく。 829-2008

欠陥1件の粒度について、IEEE標準やISO規格はとくに言及していない

2012/3/1

(18)

野中が考える「欠陥1件」の数え方

原則 :

プロダクト

の原因部分で集約して1件と数える

 原因部分が1個所のみの場合 → 1件 – 要求仕様書の記述に誤りが1個所あり、要求レビューでこれを除去した  原因部分の修正が、ほかの個所に影響する場合 → 1件 – 仕様の問題個所を修正した後に、関連して修正しなければならない仕様書の記述2個所を 修正した … Q1、Q2のパターン  原因が成果物ではなくプロセスにある場合 → 修正個所を別々にカウント – Q3の例は、デバッグプロセスにおける修正漏れという問題のために、2個の欠陥が 新たに入り込んだと解釈する – Q2で識別した1件と、Q3で新たに識別した2件を合計する → 3件 ※ 開発プロセス全体で欠陥の粒度に一貫性を持たせ、 欠陥除去工程のパフォーマンスを正しく評価したい場合 野中(2010)「ソフトウェア品質の定量的管理における曖昧さ-ソフトウェア欠陥測定の原則-」『経営論集』pp.99-109,東洋大学経営学部

(19)

欠陥の分類:欠陥の数を扱う前に考えなければならないこと

Makoto Nonaka, Toyo University 19

• 欠陥の定量的管理の前提として、欠陥の分類を考えておく必要がある

• 欠陥除去のフロントローディングを議論するときは、機能性欠陥に着目する

• 将来の機能性欠陥につながる発展性欠陥は、早い段階で芽を摘んでおく

• 欠陥の分類に着目して、プロジェクトの状況を把握する

M

äntylä , M. V. and Lassenius, C., “What Types of Defects Are Really Discovered in Code Reviews?,” IEEE Trans. Softw. Eng., vol. 35, no. 3, pp. 430-448, 2009.

大規模欠陥 サポート タイミング チェック リソース ロジック インタフェース 構造 視覚的表現 ドキュメンテーション 機能性の欠如、大幅な追加・修正が必要 構成管理システムの問題やライブラリの欠陥 マルチスレッド環境で生じる問題 妥当性確認ミス、不正な値の検出ミス ライブラリ、デバイス、DB、OS等とのインタフェース不整合 比較演算子、制御フロー、計算などの誤り データ、変数、リソース初期化、解放などの誤り コード構造 コードの読みやすさ コードの説明 コードインスペクション指摘の 約70%は、発展性欠陥を検出 (Mäntylä , 2009) 2012/3/1 機能性欠陥

(20)

ソフトウェア開発プロセス

メトリクス例:工程の/プロセス全体の欠陥除去率(DRE)

~プロジェクト終了後に欠陥除去工程の能力を評価~

・ 品質 - 各工程での欠陥除去数 - 各欠陥の混入工程 測定項目 ☆ 目的 ・ 各欠陥除去工程の欠陥除去能力を把握する ・ 欠陥除去率の低い工程を重点的に改善する ☆ POINT ・ プロジェクト終了後でなければ、測定値は定まらない ・ 各欠陥の混入工程を記録しておく必要がある

・ DRE(Defect Removal Efficiency)は基本的なメトリクス

当該工程での欠陥除去数 当該工程開始時の残存欠陥数

工程の欠陥除去率

システムテスト工程 <上流工程> <テスト工程> 基本設計 基本設計レビュー 基本設計工程 機能設計 機能設計レビュー 機能設計工程 詳細設計 詳細設計レビュー 詳細設計工程 コーディング コードレビュー コーディング工程 統合テスト工程 単体テスト工程 システムテスト項目 基本設計仕様書 機能テスト項目 機能設計仕様書 単体テスト 項目 詳細設計 仕様書 コード一式 コード一式 コード一式 受入テスト 要件定義 要件定義レビュー 要件定義工程 要件定義書 受入テスト項目 コード一式

Laird, L. M. and Brennan, M. C., Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006 (野中誠, 鷲崎弘宜訳:演習で学ぶソフトウェアメトリクスの基礎, 日経BP社, 2009).

(21)

欠陥除去率の計算例

Makoto Nonaka, Toyo University 21 Laird, L. M. and Brennan, M. C., Software Measurement and Estimation: A Practical Approach, John-Wiley and Sons, 2006

(野中誠, 鷲崎弘宜訳:演習で学ぶソフトウェアメトリクスの基礎, 日経BP社, 2009).

Kan, S. H., Metrics and Models in Software Quality Engineering, 2nd ed., Addison-Wesley, 2002 (古山恒夫, 冨野壽監訳, ソフトウェア品質工学の尺度とモデル, 共立出版, 2004). 混入 除去 定義 要求 機能 設計 詳細 設計 コーディ ング テスト 単体 テスト 結合 テスト システム 運用 合計 DRE 機能設計 インスペクション 49 681 730 74.4% 詳細設計 インスペクション 6 42 681 729 61.3% コード インスペクション 12 28 114 941 1095 54.8% 単体テスト 21 43 43 223 2 332 36.7% 結合テスト 20 41 61 261 - 4 387 67.1% システムテスト 6 8 24 72 - - 1 111 58.1% 運用 8 16 16 40 - - - 1 81 合計 122 859 939 1537 2 4 1 1 3465 97.7% 例:詳細設計インスペクションの DRE DRE = 729 / (122+859+939 – 730)

欠陥除去能力の低い工程を特定し、重点改善対象の候補とする

プロセス全体 のDRE 2012/3/1

(22)

Total Defect Containment Effectiveness (TDCE)

混入 除去 定義 要求 機能 設計 詳細 設計 コーディ ング テスト 単体 テスト 結合 テスト システム 運用 合計 TDCE 機能設計 インスペクション 49 681 730 79.3% 詳細設計 インスペクション 6 42 681 729 72.5% コード インスペクション 12 28 114 941 1095 61.2% 単体テスト 21 43 43 223 2 332 100% 結合テスト 20 41 61 261 - 4 387 100% システムテスト 6 8 24 72 - - 1 111 100% 運用 8 16 16 40 - - - 1 81 合計 122 859 939 1537 2 4 1 1 3465

例:機能設計の TDCE

=

681

/

859

各々の欠陥除去工程で「除去すべき欠陥」をどれだけ除去できたかを評価

見逃した欠陥に着目し、レビュー技法やチェックリストの改訂を行う

(23)

メトリクス例:上流工程の欠陥除去率

~プロジェクト中に、工程移行の判定に利用~

Makoto Nonaka, Toyo University 23

ソフトウェア開発プロセス (太枠実線は評価用の測定、破線は実績追跡用の測定) システムテスト工程 <上流工程> <テスト工程> 基本設計 基本設計レビュー 基本設計工程 機能設計 機能設計レビュー 機能設計工程 詳細設計 詳細設計レビュー 詳細設計工程 コーディング コードレビュー コーディング工程 統合テスト工程 単体テスト工程 システムテスト項目 基本設計仕様書 機能テスト項目 機能設計仕様書 単体テスト 項目 詳細設計 仕様書 コード一式 コード一式 コード一式 受入テスト 要件定義 要件定義レビュー 要件定義工程 要件定義書 受入テスト項目 コード一式 ・ 規模 - 各仕様書のページ数 - 新規・変更KLOC ・ 品質(評価用) - 各レビュー工程での欠陥除去数 ・ 品質(実績追跡用) - 各テスト工程での欠陥除去数 測定項目 各レビュー工程での欠陥除去数 上流工程での欠陥混入数の予測値

上流工程の欠陥除去率

予測 ・ 品質 上流工程での欠陥混入数の予測値 (規模を基準に、過去実績に基づいて予測する) ☆ 目的 ・ レビュー工程全体での欠陥除去能力を把握する ・ レビューを終えてテスト工程に進んで良いかどうかを判断する ☆ POINT ・ 欠陥混入数の予測モデルが妥当か、実績データにより評価する ・ 予測モデルは、定期的に見直す 2012/3/1

(24)

「この工程の欠陥除去能力を高めましょう」

とだけ言って/言われて、正しく対処できるだろうか?

IPA/SEC「重要インフラ情報システム信頼性研究会」報告書(2009)に見る、 再発防止のための指示 ・重要インフラ情報システムの障害事例の収集(約100事例) ・原因の分析 (ソフトウェア欠陥 / 運用ミス / … ) ・問題構造の分析 (障害事例の当事者ではないが、専門家が時間をかけて議論) ・再発防止のポイントを分類・整理 例:「複数の経験者によるレビューを徹底し、仕様、プログラムなどを 充分レビューする」 http://sec.ipa.go.jp/reports/20090409.html

重点評価/改善すべき箇所を特定できるソフトウェア品質技術が必要

現場では、「徹底」「充分」とだけ言われても困る

(…という人もいる)

(25)

fault-proneモジュールの予測のイメージ

Makoto Nonaka, Toyo University 25 ソフトウェア開発プロセス (V字モデル)のコーディング/ 単体テストが終わった時点で、 機能テスト/システムテストで 欠陥が見つかりそうなモジュールを、 ソースコード等から測定可能な プロダクトメトリクスや プロセスメトリクスを用いて、 欠陥がありそうな度合いによって モジュールを色分けして、 優先的/重点的にレビューしたり テストしたりすることで、 レビューやテストの効率/効果を 高めたい 2012/3/1

(26)

欠陥修正の有無を、何らかのメトリクスで予測する

f (LCOM, WMC, CBO) = 

1 + exp (‐2.21 + 2.34*LCOM + 0.0704*WMC + 0.243*CBO)

1 LCOM:凝集度の欠如度合い WMC:複雑度重み付き規模 CBO:結合度 1. 0 ) 修正なし(予測) 修正あり(予測) 欠陥修正有無の予測結果 0. 8 予 測値(確率 ) 修正なし(実績) 30 12 修正あり(実績) 12 48 適合率と再現率 ずれも80 0. 4 0 .6 デ ル式による 予 適合率と再現率:いずれも80% 複雑度重み付き規模、結合度、凝集度の欠如 により 欠陥修正の有無を高い精度で予測できた 0 1 0. 2 モ デ により、欠陥修正の有無を高い精度で予測できた 実績データの分析結果に基づいて、 0 1 修正有無の実績 (0:なし 1:あり) 実績 分析結果 、 ソフトウェア開発技術の道理を踏まえた上で、 重点評価/改善すべきモジュールを指示できる

Makoto Nonaka, Toyo University 26

2012/3/1

(分析対象のデータ)オープンソースソフトウェア Twitter4J

(27)

メトリクスへの取り組みで忘れてはいけない基本姿勢

“I‘d rather be vaguely right than precisely wrong.” 

g

y g

p

y

g

精密に誤るよりも、漠然と正しくありたい

John Maynard Keynes  

私たちのメトリクス利用は 「精密に誤って」 いないか?

(自戒の念も込めて) 

私たちのメトリクス利用は 「精密に誤って」 いないか?

(自戒の念も込めて)

手法や理論モデルの洗練/詳細化が目的になっていないか

細かい議論に深入りし過ぎて、現実の問題から目が離れていないか

「漠然と正しい」 情報が得られているか?

意思決定に役立つレベルの精度を持った情報が得られているか

2012/3/1 Makoto Nonaka, Toyo University 27

(28)

3. レビューに活かすソフトウェア品質技術

要求定義

プロセス改善

欠陥に学ぶ 《失敗からの学習》

・fault-proneモジュール予測

・レビュー目的の明確化

・チェックリストの選別、連想キーワードの選定

プロジェクト

管理

欠陥の記録・測定 《失敗の記録》

<定量データ> <定性データ> <リッチ情報>

レビュー

(29)

このようなバグの再発は絶対に避けたい

Makoto Nonaka, Toyo University 29 横浜市の生活援助員派遣サービス付き高齢者用住宅 で、一人暮らしの60代男性が部屋の中で病死した まま約一カ月間も放置されていたことが分かった。 在宅中でも外からの施錠で「不在」と表示されると いうシステムの不十分さと、業務委託先の市福祉 サービス協会や生活援助員の安否確認の不足などが 原因としている。 (2006/2/10 新聞記事より)

入居者の死亡、1カ月気付かず

横浜の高齢者用住宅

① AM8:25 水道12時間未使用センサーが作動 警備会社に通知 ② AM8:38 警備員が安否を確認 (高齢者は寝過ごしただけ) ③ 警備員が外から施錠 ④AM10:00 生活援助員は「不在」表示を確認 安否確認せず ⑤ 生活援助員は、その後も週二回「不在」表示 を確認するが安否確認せず ⑥ 17日後、生活援助員が市の福祉サービス協会 本部に経緯を報告 ⑦ さらに14日後、親族に連絡して家に入る許可 を得て、死亡を確認 (2006/2/10 新聞記事より) 2012/3/1

(30)

レビューを計画する:3つのポイント

目的は何か

重大な欠陥(安全性の問題など)の除去に注力するのか

客先に成果物を渡す前に、文章表現上の問題を摘出するのか

実現技術の妥当性を確認するのか など

どのレビュー技法を用いるのか

一人一本目チェック技法

インスペクション

アジャイルインスペクション など

どの観点でレビューするのか

利用者/設計者/テスト担当者

品質特性/ドキュメント標準との整合性 など

(31)

チェックリスト② 妥当性

• 状態とイベントの各々の組み合わせについて、システムの振る舞いは妥当か

• とくに「N/A」の組み合わせは、システムとして実現しなくても問題ないか

Makoto Nonaka, Toyo University 31

チェックリスト③ 利用シナリオの網羅性

• 想定できるすべての利用シナリオについて、仕様の妥当性を検討したか

チェックリスト① 安全性

• システム内で認識された状態と観測対象の実際の状態とのあいだにズレが 生じたときに、システムの振る舞いは安全側に倒れる設計になっているか

目的に即した、適切なチェックリストを選ぶ

2012/3/1

(32)

連想キーワードを用いたレビュー

(出典)中尾政之『続・失敗百選』森北出版(2010)

失敗学に見るキーワード例

逆流

塵埃・動物

誤差蓄積

脆弱構造

フィードバック系暴走

フェイルセーフ不良

待機系不良

• 技術者は決して「バカ」ではない • 連想キーワードという刺激により、技術的な着眼点を想起させれば十分 • あとは、知識と経験に基づいた思考により、問題があるかどうか評価できる

飯塚悦功氏 講義

「デキル技術者の頭の中」

(YouTube動画)

あるものを見たときに、

何かを連想するような

チェックリストを作成

バリ、○○加工など、

そのドメインの技術特性に

関連した言葉を抽出

http://www.youtube.com/watch?v=iTOZjfBBf4E

(33)

4. プロセス改善に活かすソフトウェア品質技術

2012/3/1 Makoto Nonaka, Toyo University 33

要求定義

プロセス改善

欠陥に学ぶ 《失敗からの学習》

システム思考の適用

・技術者行動の構造を理解した上でのプロセス改善

・ビジネス構造を理解した上でのIT導入(要求定義)

プロジェクト

管理

欠陥の記録・測定 《失敗の記録》

<定量データ> <定性データ> <リッチ情報>

レビュー

(34)

行動は、構造から必然的に引き起こされる

事象・行動: 例)欠陥記録を改ざんし、見かけ上は目標値を達成できたように振る舞う “実績”の改ざん 目標と“実績”の差 +

B

ごまかしループ ー 欠陥データの 第三者チェック頻度 欠陥測定基準 の整備度 欠陥データの 活用度 ー ー ー

背後にある構造を理解せずにシステムに介入すると、期待に反する

事象や行動が生じてしまうことがある

問題解決には、構造を理解し、構造を変革していく必要がある

構 造: 例)欠陥記録を改ざんしてしまう行動 の背後にある構造(の一部)

(35)

システム思考 (Systems Thinking)

Makoto Nonaka, Toyo University 35

ものごとを「システム」として捉え、システム内に含まれる要素間の

因果関係の構造を理解することで、システムの振る舞いを分析する。

システムが振る舞うと、システムは、周囲の環境から影響を受ける。

2012/3/1 都市であれ、ハムスターであれ、複雑な社会システムで、合点がいかないと 直したいところがあったとして、何とかしようと首を突っこんで直そうとしても うまくはいかない。 外部から複雑なシステムの一部分だけに干渉しようとすると、ほぼ確実に、 ほかのまったく別の部分で予期せぬ破滅的な事象を引き起こすリスクがある。 何かを直したいなら、まず、システム全体を理解しなければならない。 ジョン・D・スターマン(小田理一郎・枝廣淳子訳)『システム思考―複雑な問題の解決技法』東洋経済新報社(2009)

(36)

「積み残し課題に対処する学生」の構造(因果ループ図)

課題の積み残し 課題が課される ペース させるペース 課題を完成 週当たりの 勉強時間 課題の質 への追求度 課題完成の ひっ迫度 生産性 残り時間 期日 現在の日付

B

夜なべで 仕上げる ループ + + + + + + - - - - - 活力 -

B

手抜きループ +

R

燃え尽き ループ 提出課題 の質 成績 + - + +

B

質の制御ループ 期限延長の 申し出 + +

B

飼い犬が宿題を 食べたループ プロセス改善を進めるにあたり、 技術者行動の背後にある構造を 理解することが必要 施策の導入後、システム全体の 振る舞いを確認し、望まざる副 作用が生じていないか確認する

(37)

新規依頼 依頼取りやめ 会員の 代表者 入会 代表買い 取りやめ 代表者 集約行動 1回の購入数 代表買い 頻度 依頼者 + + 依頼の とりつけ + + 代表者の 評判 + + 新規依頼の とりつけ + + R 新規開拓 会員メリットの 期待度 + + + 地域住民の 高齢化 都市部からの 距離 地域住民の 親密さ + + - 会員カード ポイント数 会員が 得られる メリット + + + R 会員の メリット向上 R 依頼とりつけ + コッコファーム(中小企業IT経営力大賞2010 優秀賞受賞)における 「代表買い」の構造と、IT導入による構造の実現 IT導入により 実現された構造

2012/3/1 Makoto Nonaka, Toyo University 37

IT導入により、ビジネスの構造をどの ように変化させたいのか

顧客のビジネス構造を理解した上で、 顧客価値の向上/創出を目指す

(38)

おわりに

• この命題を共有することが、品質に関わる問題解決の第一歩 • この命題の正しさを検証するのが、この分野に関わる研究者(野中)の使命 • この命題を達成する手段の一領域として、プロジェクト管理/レビュー/ 要求定義/プロセス改善に活かせる品質技術を紹介した • ソフトウェア品質技術には、開拓の余地がまだたくさんある • ソフトウェア品質にしっかりと取り組むことが、自社、顧客企業、さらには 「顧客企業の顧客」の幸せにつながる

品質にしっかりと取り組めば、組織は賢く、強く、幸せになれる

・高いレベルの顧客満足を達成できる

・開発コストを下げられる

・開発スピードを加速できる

参照

関連したドキュメント

物質工学課程 ⚕名 電気電子応用工学課程 ⚓名 情報工学課程 ⚕名 知能・機械工学課程

Q7 建設工事の場合は、都内の各工事現場の実績をまとめて 1

⼝部における線量率の実測値は11 mSv/h程度であることから、25 mSv/h 程度まで上昇する可能性

HACCP とは、食品の製造・加工工程のあらゆる段階で発生するおそれのあ る微生物汚染等の 危害をあらかじめ分析( Hazard Analysis )

脱脂工程 調合 塗布工程 セッティング..

非原産材料 加工等 産品 非原産材料に特定の加工工程がほど こされれば、実質的変更があったとす る基準. ⇒我が国の多くの

従って,今後設計する機器等については,JSME 規格に限定するものではなく,日本産業 規格(JIS)等の国内外の民間規格に適合した工業用品の採用,或いは American

従って,今後設計する機器等については,JSME 規格に限定するものではなく,日本工業 規格(JIS)等の国内外の民間規格に適合した工業用品の採用,或いは American