がんばるだけの品質向上活動からの脱却

森崎 修司
静岡大学 情報学部
http://twitter.com/smorisaki/
本資料に含まれる研究の一部は文部科学省「次世代IT基盤構築のための研究開発」の委託に基づいて行われたものです。また、本資料に含まれる研究の一部は同省科学研究補助費（若手B：課題番号21700033）の助成を受けま
した。

自己紹介
• 奈良先端科学技術大学院大学 博士後期課程 修了（2001.3）– ソフトウェアの利用品質• エンジニアとして: ソフトウェア開発（2001～）– オンラインストレージサービスの開発、開発管理– 無線ICタグの研究開発（国際標準策定、ソリューション化）– コストカット部門、プリセールス• 研究者として: ソフトウェア工学の研究（2005～）– 文科省e-society基盤の総合開発、経産省 先進的ソフトウェア開発でソフトウェア工学の産学連携の研究に従事– 300社超との相談、18社と機密保持契約ベースの産学連携– @IT, 日経SYSTEMS, ThinkIT等での連載記事• 好きなこと– 講演冒頭等で失敗するかもしれないアグレッシブなネタを仕込んでおく姿勢
2品質向上活動の５つのレベル
0. 品質向上とは関係ない仕事をしている
1. 個々人が思い思いの品質向上活動をしている
2. 関係者が合意した上で品質向上活動ができている
3. 2のうち、他組織ではマネが難しいものがわかっている。
4. 3のうち競争力の源泉となっているものがわかっている。
• ここでの「品質向上活動」は品質向上を目指した活動であり、議論の簡便化のため、必ずしも結果は伴っていなくてもよいものとする。

3

５つのレベル• 0. 品質向上とは関係ない仕事をしている。
• 1. 個々人が思い思いの品質向上活動をしている。
• 2. 関係者が合意した上で品質向上活動ができている。
• 3. 2のうち品質向上活動が特徴づけられているものがわかっている。
• 4. 3のうち、競争力の源泉となっているものがわかっている。
レベル4
レベル3

レベル2
レベル1
4

レベル０ – 品質向上とは関係ない活動をしている• 品質向上につながる活動をしているようにも見えるが実際には効果のない活動をしている。
早く先週の稼働
工数と作業進捗報告を出して！
リーダ

全員分集まっ
た！完成！

リーダ

5

レベル１ – 思い思いの品質向上活動をしている• 各々が品質向上につながると考え、活動をしているが合意・統一されていない。

非機能要件が大事！
非機能要件の定義とテストを重点的にコードの可読性！
読みやすいコードは
バグも少ない。
可読性を高めよう。

標準プロセスの遵守がいいものを作る！
プロセスを遵守しよう。
設計レビューの議事録みれば、ちゃんとレビューできているかわかる。
結果によっては再レビューだ
テストコード大事！
テストコードを書くことを義務化しよう。

6

レベル２ – 合意している（１／２）• 関係者の間で求められる品質が合意できている。
• 合意できた品質の向上に役立つ活動ができている。

レスポンスの良さがもっとも大事たしかに。
設計の前に先行検証しておいたほうがいいかも。
たしかに。
レビューではワーストケースのスループットを注視しよう
たしかに。
負荷テストは自動化してコーディング
フェーズから実施しよう

7レベル２ – 合意している（２／２）• 関係者の間で求められる品質が合意できている。
• 合意できた品質の向上活動ができている。

12/1の法改正に合わせてリリースしな
いといけない

法改正に関わる部分のみ先行して設計、コーディング、
テストできるか？
法改正に関わる部分だけ切り分けてリリースできる？

8

レベル０と１、２の違い• 厳しめに見れば様々なものがレベル0とできるが、明らかにずれた活動でなければレベル1、レベル2とする。
不具合密度が計画下限を下回っているから、不具合を二つに分割して計画下限を上回るようにしよう。
設計レビューの検出欠陥に対応する手間が大きいからドキュメントは修正せず、次工程に早めに着手
しよう
レベル0

信頼度成長曲線の収束具合で今後のテストを追加するか検討しよう。

不具合密度が計画上限と下限の間に入っているし、不具合の検出状況も異常はないからシステムテストに移ろう。
レベル1, 29

レベル３ – 特徴付けられている• どのような活動によって品質向上が実現されているかがわ
かっており、品質向上活動の効果が出ている。
• 競合となり得る他の組織では簡単に模倣することが難しい。

他と比較してかなり使いやすいUIと評
価が高いらしい。

ユーザビリティラボでのノウハ
ウが設計にフィードバックされているから。
ユーザ入力からの反応を数ミリ秒単位での調整を重視しているから。
10

レベル３ – 特徴付けられている• どのような活動によって品質向上が実現されているかがわ
かっており、品質向上活動の効果が出ている。
• 競合となり得る他の組織では簡単に模倣することが難しい。

Xの業務フローに関してかなり深いノウハウがある。

顧客の業務部門よりも詳細に業務が把握できているし全体像もわかるからテストケースを適切に選択できる
業務フローの変更によって、どの程度のシステム改変が必要かが高い精度で見積もれる。
11

レベル２と３の違い• 2 関係者が合意した上で品質保証活動ができている• 3 品質保証活動が特徴付けられている

他ではできないことがわかっている。

意味ある品質向上活動に取り組んでいると関係者が感じている。
レベル4
レベル3
レベル2
レベル1
12

レベル４ – 競争力の源泉となっている（１／２）• 品質が競争力の源泉となっており、その品質に対して顧客やユーザが価値を認めて対価を支払っている。
• 特定のソフトウェア、サービス、製品のプライスリーダになることができる。

このレベルの負荷テスト
や稼働中のモニタリングの方法をこの価格帯で実現できるところはない。

先行検証してから作り込むので、設計、実装とも大きく変更することはなく、開発効率が高い。
これまでの運用実績で品質を左右するパラメータ設定が何かがわかっていて、それを自身で解決できる顧客はいない。
13

レベル４ – 競争力の源泉となっている（２／２）• 自組織の強みが何かがわかり、方法がわかっている。
• 強みが顧客にとって高い価値を生み出している。

このレベルでセキュリティを維持できないと、この情報をネットワークを介してやりとりできず、物理的な運搬が必要になる。

セキュリティ事情に詳しいメンバがいて、組織外のキーパーソンとも十分に情報共有できていて、コーディング、
テストでの留意点がわかっている。

緊急度に応じた脆弱性対応のための体制があり、検証や影響範囲の確認が即座にできる。
14

レベル３と４の違い• 3 品質保証活動が特徴付けられている• 4 品質保証活動が特徴付けられており、競争力の源泉となっている
他で簡単に模倣できないことがわ
かっているが、競争力にはなっていない

他では簡単に模倣できないことがわかっていて、競争力と認識されている。
レベル4
レベル3
レベル2
レベル1
15

レベル０からの脱却• ふりかえりによって、活動を見直す。
– 全体を見直す場を設定する。
– 他での事例を示す。
– 時間がかかることを覚悟する。

• レベルの移行– レベル0、1からは2への移行を目指す。
– レベル2からの移行と比較して難易度が高い。
– レベル2への移行とレベル2からの移行は種類が異なる。

16

レベル０からレベル１へ

レビューで誤字脱字・表記の誤りの検出を控える• 試行手順– 1. レビュー1回目: いつものやり方でレビューする。
– 2. 誤字脱字の検出が最終的なシステムの品質向上に役立たないことを確認し合意する。
– 3. レビュー2回目: 誤字脱字を検出しないよう依頼する。

• レビュー対象– A4 4ページ（日本語で記述）の簡単な仕様書 × 2• 1回目: テニスコート予約システム• 2回目: 社内勉強会参加申込みシステム• 被験者– 実務者32名– 1回目、2回目とも、1人で20分程度欠陥検出してもらう。
出典： 森崎修司「意味あるレビューに改善できる？」日経SYSTEMS 2011年3月号,
pp. 50-55（2011）17レベル０からレベル１へ

レビュー試行での合意の結果• 誤字脱字、表記に関する指摘が大幅に減少した。
– レビュー1: 24.4%– レビュー2: 6.7%

• 誤字脱字表記以外の指摘が増え、本質的な指摘が増えた。
– 主要機能の記載漏れ– システム利用時の業務フローの問題• レビュー指摘によって得られるメリット（修正コストの低減）を理
解し、合意できた効果と考えられる。
– 「レビューの効果は修正コストの低減である」という合意が得られた。
– 誤字脱字、表記に関する指摘に使う時間を本質的な欠陥の検出に使えた。
出典： 森崎修司「意味あるレビューに改善できる？」日経SYSTEMS 2011年3月号,
pp. 50-55（2011）18

レベル０からの脱却の注意点

ルールの増加、強調はギリギリで守る人を増やす• ルールを遵守することを強調するとルールを守っていれば大丈夫という人を増やす。
• ルールを増やしていくとそれ以外は気にしなくてもよいという人を増やす。

あるべき姿

ルールは許容範
囲ギリギリから作成されることが多い。

19

レベル０からの脱却の注意点

ルールの増加、強調はギリギリで守る人を増やす• ルールを遵守することを強調するとルールを守っていれば大丈夫という人を増やす。
• ルールを増やしていくとそれ以外は気にしなくてもよいという人を増やす。
あるべき姿を示す場合

ルールを示す場合
ルール

あるべき姿

20

レベル１からレベル２へ： 事例• 対象プロジェクト– 経済産業省「先進社会基盤構築ソフトウェア開発事業」– 交通情報を中心としたセンサネットワークシステムのサーバサイドロジック– 自動車会社の要求をもとにNTTデータがマネジメント、デンソー、日本電気、パナソニック、日立製作所、富士通がベンダとして開発した。

• C/C++で330KLOC（流用込み）、約1年 × 2回
• 初年度と次年度で我々の研究グループがマネジメント企業
とともに技法の活用や検証に取り組んだ。

参考： IPA SEC Books, ソフトウェアエンジニアリングの実践、エンピリカルソフトウェア工学の勧め
http://sec.ipa.go.jp/publish/index.html

21レベル１からレベル２： 事例

初年度• 構成管理ツールからソースコードの規模遷移を時系列に可視化し、問題のありそうな部分をヒアリングした。
• 質問とフィードバックは事後に実施した。
開発開始

初年度
ふりかえり

コーディング～テスト

ベンダ

PJ-1
PJ-1

80
80
70
70
60
60
50
50
40
40
30
30
20
20
10
10
0
0
2006/6/17
2006/6/17

0.9
0.9
0.8
0.8
0.7
0.7
0.6
0.6
0.5
0.5
0.4
0.4
0.3
0.3
0.2
0.2
0.1
0.1
0
0
2006/10/30
2006/10/30

[3]
[3]

[1]・[2][1]・[2]

研究グループ

構成管理ツール
不具合管理ツール

2006/8/1
2006/8/1

2006/9/15
2006/9/15

[1]:更
[1]:更
新回数
新回数

[2]:削
[2]:削
除大の
除大の
回数
回数
[3]:削
[3]:削
除大の
除大の
回数/
回数/
更新回
更新回
数
数

22

レベル１からレベル２： 事例

２年度目• 週次ミーティングの前に、ソースコード規模遷移、不具合管
理表のデータをもとに問題点の有無を確認することを合意• 研究グループとマネジメント会社がデータの上で問題なしと認めた場合、週次ミーティングの一部を省略するルール
開発開始

コーディング～テスト
・・・

構成管理ツール
不具合管理ツール・・・

2006/9/15
2006/9/15

PJ-1
PJ-1

[1]・[2][1]・[2]

[2]:削
[2]:削
除大の
除大の
回数
回数
PJ-1
PJ-1

[3]:削
[3]:削
除大の
除大の
回数/
回数/
更新回
更新回
数
数

80
80
70
70
60
60
50
50
40
40
30
30
20
20
10
10
0
0
2006/6/17
2006/6/17

0.9
0.9
0.8
0.8
0.7
0.7
0.6
0.6
0.5
0.5
0.4
0.4
0.3
0.3
0.2
0.2
0.1
0.1
0
0
2006/10/30
2006/10/30

[3]
[3]

2006/8/1
2006/8/1

[1]:更
[1]:更
新回数
新回数

[1]・[2][1]・[2]

0.9
0.9
0.8
0.8
0.7
0.7
0.6
0.6
0.5
0.5
0.4
0.4
0.3
0.3
0.2
0.2
0.1
0.1
0
0
2006/10/30
2006/10/30

[3]
[3]

研究グループマネジメント企業[1]・[2][1]・[2]

PJ-1
PJ-1

80
80
70
70
60
60
50
50
40
40
30
30
20
20
10
10
0
0
2006/6/17
2006/6/17

2006/8/1
2006/8/1

2006/9/15
2006/9/15

[1]:更
[1]:更
新回数
新回数

80
80
70
70
60
60
50
50
40
40
30
30
20
20
10
10
0
0
2006/6/17
2006/6/17

0.9
0.9
0.8
0.8
0.7
0.7
0.6
0.6
0.5
0.5
0.4
0.4
0.3
0.3
0.2
0.2
0.1
0.1
0
0
2006/10/30
2006/10/30

[3]
[3]

ベンダ

2006/8/1
2006/8/1

2006/9/15
2006/9/15

[1]:更
[1]:更
新回数
新回数

[2]:削
[2]:削
除大の
除大の
回数
回数
[3]:削
[3]:削
除大の
除大の
回数/
回数/
更新回
更新回
数
数

[2]:削
[2]:削
除大の
除大の
回数
回数
[3]:削
[3]:削
除大の
除大の
回数/
回数/
更新回
更新回
数
数

23

レベル１からレベル２： 事例

２年度目： 電子メールによるフィードバック
IPAソフトウェア
エンジニアリングセンター

開発担当組織グラフ化と指摘事項

奈良先端科学技術大学
院大学・大阪大学の研究グループ

電子メールによるグラフと確認事項の送付

マネジメント組織
前週までの実績をもとに毎週5社分
出典： 松村知子, 勝又敏次, 森崎修司, 玉田春昭, 大杉直樹, 門田暁人, 楠本真二, 松本健一, 自動データ収集・
24
可視化ツールを用いたリアルタイムフィードバックシステムの構築と試行,
奈良先端科学技術大学院大学テクニ
カルレポート TR2007001 （2007/2）

レベル１からレベル２： 事例

規模遷移のグラフ

出典： 松村知子, 勝又敏次, 森崎修司, 玉田春昭, 大杉直樹, 門田暁人, 楠本真二, 松本健一, 自動データ収集・可視化ツールを用いたリアルタイムフィードバックシステムの構築と試行, 奈良先端科学技術大学院大学テクニカルレポート TR2007001 （2007/2）
25

レベル１からレベル２： 事例

プロダクト規模遷移を用いた開発リスク早期発見• 機能、サブシステム単位で規模遷移をモニタする。
PJ-1

60

15

40

10

[1]:ファイ
ル数

[2]

20

[1]

80

20

[2]:プログ
ラム 行数（KSLOC）

5

0
2006/6/21

0
2006/8/5

1. ファイル数、行数
1

8000

0.8

6000

0.6

4000

0.4

2000

0.2

0
2006/6/17

2006/8/1

2006/9/15

0.8

60

0.7

[1]:更
新回数

0.6

50

0.5

40

0.4

30

0.3

20

0.2

10

0.1
2006/8/1

2006/9/15

0
2006/10/30

[2]:削
除大の
回数
[3]:削
除大の
回数/
更新回
数

[1]:追加行数[3][1]・[2]10000

70

2. 更新頻度

PJ-1

1.2

0.9

0
2006/6/17

2006/9/19

12000

80

[3]

25

[1]・[2]100[2]:削除行数[3]:削除行数/追
加行数0
2006/10/30

3. 更新量
出典: 松村, 森崎, 勝又, 玉田, 吉田, 楠本, 松本 “問題の早期発見・改善を支援するインプロセスプロジェクト管理手法の実プロジェクトへの適用”,
電子情報通信学会論文誌Vol.
26
J92-D, No. 11, pp. 1974～1986 (2009)レベル１からレベル２： 事例

適用結果• 対象ソフトウェアに関する知識が少ない、研究グループのメンバがプロダクト規模推移にもとづいて問題を指摘• 問題が確認されない場合には進捗会議を短縮した。
• 当学のメンバも進捗会議に参加し、技法の洗練に努めた。
研究グループによるリスク指摘
全指摘 異常指摘 問題の顕在化
に寄与
件数

136

83

27

割合

100%

61%

20%

出典: 松村, 森崎, 勝又, 玉田, 吉田, 楠本, 松本 “問題の早期発見・改善を支援するインプロセスプ
ロジェクト管理手法の実プロジェクトへの適用”, 電子情報通信学会論文誌Vol. J92-D, No. 11, pp.
1974～1986 (2009)27

レベル１からレベル２へ参考になる議論： DevOps• Webを通じてサービスを提供する技術者の間で問題とされ議論されている。
– Dev: Development (開発)
新しい機能をリリースしたい。
– Ops: Operations (運用): QAを含んでいることもある。
安定してサービスを提供したい。

• 開発と運用の間で相反する意図や言い争いを減らし、ユー
ザに価値を届けるために必要な仕組みやマインド– 活動の透明性を高める。
– 頻繁なリリースによって抵抗を小さくする。
– ツールを活用する。
28

レベル１からの移行の注意点

背景・状況を合意する• 結果や表層的な情報だけではなく、背景や状況を含めて合意する。
1KLOCあたりの不具合が0.5～2.0件の範囲を出たら再レビューということではい

品質保証担当開発担当

結果や表層的な情報だけで合意対象の品質が低い、テストが適切でない可能性があれば相談しましょう。
1KLOCあたりの不具合が0.5～2.0件の範囲を出たら必ず相談ということで。

品質保証担当はい

開発担当

背景や状況を含めて合意
29

レベル１からの移行の注意点

背景・状況を合意する• 結果や表層的な情報だけではなく、背景や状況を含めて合意する。
範囲を出たときは再レビューなので、全ての作業を止めてください。

特に違和感がな
いのに範囲を出てしまいました・・

品質保証担当開発担当

結果や表層的な情報だけで合意なるほど。一緒に考えましょう。

特に違和感がないのに範囲を出てしまった。一緒に考えてもらえませんか？

品質保証担当開発担当

背景や状況を含めて合意
30

レベル１からの移行の注意点

ルールの増加、強調はギリギリで守る人を増やす（再掲）• ルールを遵守することを強調するとルールを守っていれば大丈夫という人を増やす。
• ルールを増やしていくとそれ以外は気にしなくてもよいという人を増やす。

あるべき姿

ルールは許容範
囲ギリギリから作成されることが多い。

31

レベル１からの移行の注意点

ルールの増加、強調はギリギリで守る人を増やす（再掲）• ルールを遵守することを強調するとルールを守っていれば大丈夫という人を増やす。
• ルールを増やしていくとそれ以外は気にしなくてもよいという人を増やす。
あるべき姿を示す場合

ルールを示す場合
ルール

あるべき姿

32

レベル２と３の違い（再掲）• 2 関係者が合意した上で品質保証活動ができている• 3 品質保証活動が特徴付けられている

他ではできないことがわかっている。

意味ある品質向上活動に取り組んでいると関係者が感じている。
レベル4
レベル3
レベル2
レベル1
33

レベル２からレベル３へ• うまくいっている理由を深掘りする（成功要因の検討）。
– 期待通り機能している品質向上活動の限界や制約を知る。
– コンテキストを明確にする。

• うまくいっている理由をもとに自組織の特徴と関連づける。
例）– 人事評価にアシストポイントが加味されている → レビューに積
極的– となりの部門であっても口出しして、改善することが阻まれない。→ 問題の早期発見– 失敗事例を共有することが善とされている。→ ノウハウ共有• 既存の技法、技術を再構成しなければならない場合もある。
– 新規に習得する必要は必ずしもない。
– 既存の技法、技術のよい部分は残す。

34

レベル２からレベル３へ「インターネットスピードの開発」というコンテキスト

出典: R. Baskerville, B. Ramesh, L. Levine and S. Slaughter: Is Internet-Speed
35
Software Development Different?, IEEE Software, vol. 20, no. 16, p70-77(2003)

レベル２からレベル３へ「インターネットスピードの開発」 - コンテキスト分析例

コンテキスト
事実（調査結果）

出典: R. Baskerville, B. Ramesh, L. Levine and S. Slaughter: Is Internet-Speed
Software Development Different?, IEEE Software, vol. 20, no. 16, p70-77(2003)36

レベル２からレベル３へ

記事で記述されている事実とコンテキスト• 頻繁なリリース– 事実: スコープを小さくして頻繁なリリースをする。
– コンテキスト: 市場に応じて新しい機能をリリースしなければならない。

• オンサイト顧客– 事実: 顧客は通常の自席から開発ルームにすぐ移動できるようにする。
– コンテキスト: 戦略が適宜変更するためにユーザ要求が頻繁に変わる。

• 保守性の優先度を下げる（保守性を無視する）– 事実: 設計ドキュメントはない。
– コンテキスト: すぐに作り替えられるので保守性は問題になりにくい。

出典: R. Baskerville, B. Ramesh, L. Levine and S. Slaughter: Is Internet-Speed Software
Development Different?, IEEE Software, vol. 20, no. 16, p70-77(2003)37

レベル２からレベル３へ• 少し離れた視点で考える必要がある。
• コンテキストの抽出は考えればわかる場合もあるが、他での事例や状況を知らなければ難しいこともある。
• オープンなシンポジウム、カンファレンス、記事等で・・– 自分達のほうが優れている点はどこか？
– 自分達でもできることは何か？
– 自分達ではできないことは何か？

38

レベル３事例１

見逃し率• レビューにおいて1つ前の工程の見逃し欠陥に上限・下限を設定し、再レビューの契機やレビュー評価に使う。
– 見逃し欠陥がゼロということはないという前提に立つ。
– 1工程前の見逃し欠陥を報告しやすい土壌を作る。
– 最終成果物の品質向上を強く意識する。
要求定義のレビューで見逃した欠陥が基本設計のレビュー
でみつかることもある。

レビュー
要求定義

レビュー

基本設計のレビューでは基本設計で混入された欠陥が検出される

基本設計

出典:清田 辰巳、上流工程における発注者視点からの品質向上への取り組み (特集 ソフトウェアレビュー/ソフト
ウェアインスペクションと欠陥予防の現在) 、情報処理学会 学会誌 Vol. 50, No. 5, p. 400-404 (2009)39

レベル３事例１

見逃し率• レビューにおいて1つ前の工程の見逃し欠陥に上限・下限を設定し、再レビューの契機やレビュー評価に使う。
– 見逃し欠陥がゼロということはないという前提に立つ。
– 1工程前の見逃し欠陥を報告しやすい土壌を作る。
– 最終成果物の品質向上を強く意識する。
レビュー

レビュー

健全な状態
要求定義
レビュー

基本設計
レビュー

要求定義

基本設計
レビュー
レビュー

要求定義

要求定義の
再レビューを検討する

基本設計

出典:清田 辰巳、上流工程における発注者視点からの品質向上への取り組み (特集 ソフトウェアレビュー/ソフト
ウェアインスペクションと欠陥予防の現在) 、情報処理学会 学会誌 Vol. 50, No. 5, p. 400-40440レベル３事例２

FixCacheによる不具合予測の導入• 最先端の研究成果を実際の開発に取り入れる。
• FixCache*1: 過去に修正された不具合と同じような不具合が再発する。
– 7つのオープンソースプロジェクトの変更履歴約200,000件で実証– 「メモリキャッシュ」のアルゴリズムを用いて不具合の可能性の高いソースコードファイルを選出– 選出した全体のソースコードファイルの1割で73～95%の精度で不具合を予測できた。

• Googleでのソースコード更新履歴に基づく不具合予測に応用されている。*2*1: Kim S., Zimmermann T., James E. W., Zeller A., “Predicting Faults from Cached History” In
Proceedings of the 29th international conference on Software Engineering , p. 489-498.
41*2: Lewis C., Ou R. “Bug Prediction at Google” http://google-engtools.blogspot.jp/2011/12/bugprediction-at-google.html

レベル３事例３

世界規模の分散開発• コンウェイの法則「製品の設計は組織のコミュニケーションの構造を反映したものになる」 M.E. Conway, “How Do Committees
Invent?” Datamation, vol. 14, no. 4, pp. 28-31(1968)
http://www.melconway.com/research/committees.html• 商用ソフトウェアの分析によるコンウェイの法則の裏付け– メンバのコミュニケーションが密接に取りにくいモジュールほど品質が低い傾向にある。

42

レベル３事例３

商用ソフトウェアでの裏付け• ソフトウェアモジュールの不具合予測として、組織の構造を使う。
• 編集の75%を超える組織の距離と残存不具合数の関係を調べた。

出典: N. Nagappan, B. Murphy, and Victor Basili, “The influence of organizational structure on
software quality: an empirical case study,” In Proceedings of the 30th international conference
on Software engineering (ICSE '08). ACM, New York, NY, USA, pp. 521-530.
43
http://research.microsoft.com/apps/pubs/default.aspx?id=70535

レベル３事例３

商用ソフトウェアでの裏付け（イメージ）• Windows Vistaのモジュールで試した。
• プロダクト、プロセスメトリクスよりも組織構造のメトリクスのほうが品質の予測精度が高かった。

部門B
部門A

モジュールX
の編集組織

75%

部門E
部門D
部門C
部門B
部門A
モジュールYの編集組織

出典: N. Nagappan, B. Murphy, and Victor Basili, “The influence of organizational structure on software quality:
an empirical case study,” In Proceedings of the 30th international conference on Software engineering (ICSE '08).
ACM, New York, NY, USA, pp. 521-530. http://research.microsoft.com/apps/pubs/default.aspx?id=70535
44レベル２から３への注意点

フィードバックの受け方• Software evolutionの法則（リーマンの法則）– 使われるシステムは変わり続ける。
– 対策をしない限り、継続して変更するとソフトウェアがだんだ
ん複雑になる。
– システムの進化はフィードバックの内容やプロセスによって決まる。

• ソフトウェアのライフサイクルを実データをもとに分類した論
文*による（1980）– IBM OS/360の最初の25リリース分を分析した結果– プログラムのライフサイクルを定義し、保守を定義– 観察された現象を法則としてまとめている。
* M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution” IEEE, Vol. 68, No. 9, pp. 1060-1076 (1980)45

レベル３と４の違い（再掲）• 3 品質保証活動が特徴付けられている• 4 品質保証活動が特徴付けられており、競争力の源泉となっている
他で簡単に模倣できないことがわ
かっているが、競争力にはなっていない

他では簡単に模倣できないことがわかっていて、競争力と認識されている。
レベル4
レベル3
レベル2
レベル1
46

レベル３からレベル４へ• 競争力を分析する。
– レベル3の段階でレベル4はある程度視野に入るときもある。
– 「あれ？」と思うところからはじまる。
– 受託であれば失注の原因からわかる場合もある。
– コミュニティ内でのあまり関係のない会話から気づくこともある。

• 品質向上活動のバックグラウンドを考える。
– 体制によるもの– 文化（自然な考え方）によるもの• 以降では特徴的な事例を紹介するので、ご自身のソフトウェ
アや組織であればどうか考えるきっかけにしていただきたい。

47

事例１） ビジネスに大きく影響する品質を早期に作り込む• 株式売買システムのスループットを高めるために開発早期からスループットを意識して作り込む。
– 条件を事前に設定しておき、条件を満たせば売買する「アルゴリズム取引」ではトレーダがスループットを重視する。
– 多くのトレーダが集まれば株式売買システムがより多くの利益を生み出す。

• 要求定義時点から過去の株式売買のパターン（オークショ
ンパターン）をもとに詳細化する。
– 目標スループットの達成– 設計、先行検証、テスト
出典: 宇治 浩明、三澤 猛、 “株式売買システムarrowhead開発事例”, ソフトウェア品質シンポジウム2011,
http://www.juse.or.jp/software/366/attachs/sqip2011_A3.pdf (2011)48

事例２） ビジネスルール・ビジネスプロセスから影響分析• 通常、設計、ソースコード変更箇所からレビュー、テスト箇所を特定する（影響波及解析）。
• ビジネスルール・ビジネスプロセスのみで影響波及解析ができることを示している。
設計、ソースコードの変更による影響波及解析

ビジネスルールによる影響波及解析

変更前

変更後

変更前

関数a

関数a

ビジネスルール1

変更後
ビジネスルール1

依存関係

依存関係
関数b

関数b’

ビジネスルール2

ビジネスルール2’

関数c

関数c

ビジネスルール3

ビジネスルール3

出典: Aryani A., Peake I., Hamilton M., “Domain-Based Change Propagation Analysis: An Enterprise System
Case Study”, Proceedings of the 2010 IEEE International Conference on Software Maintenance, p. 1-9 (2010)49
Slideshare: http://www.slideshare.net/amiraryani/domainbased-change-propagation-analysis-an-enterprise-casestudy-5205028

事例３） 保守・拡張開発のテスト• 顧客が作成した多数のソフトウェアを低コストで運用する。
– 顧客の言い分を聞くと多様なOSやミドルウェアを運用しなければならない。
– 同一のOSやミドルウェアに統一すると顧客が集められない。

• 顧客のソフトウェアを運用する際に顧客が作成したテストコードも同時に預かる。
– OSやミドルウェアは単一バージョンとする。
– バージョンアップ時にテストコードを実行し、問題があれば顧客に知らせる。
– テストコードのカバレージを指定し、カバレージに満たない場合は預からない。
* Fisher S. “The Architecture of the Apex Platform, salesforce.com's Platform for Building On50
Demand Applications”, Keynote Speech International Conference on Software Engineering 2007

事例３） AppExchangeでの方針• 数千を超える顧客に対して同一バージョンを提供する。（個別対応はしない）• 顧客のアプリケーションは一定カバレージ（75%）以上のテス
トコードとともにホスティングする。
• OS、ミドルウェア等のアップデート時には事前テストを実施し、問題があれば修正依頼
インターネット経由でサービスとして利用する
AppExchange提供者

独自プログラムとともにテス
トプログラムも必ず預ける。
カバレージが指定される。

テストプ
ログラム

独自
プログラム

ユーザ
（サービス利用者）

独自プログラム作成者* Fisher S. “The Architecture of the Apex Platform, salesforce.com's Platform for Building On-51
Demand Applications”, Keynote Speech International Conference on Software Engineering 2007

事例４） Twitter ダークモード• 機能を細かく分解し個別に実行を制御できるアーキテク
チャを持つ。
• 部分的に機能を使えない状態にして運用することをダークモードと呼ぶ。
– 頻繁に機能をリリースする（continuous delivery）。
– 問題のある機能のみ一時的に実行できなくする。

• 機能に対してユーザが直接対価を支払わない。

John Adams, “In the Belly of the Whale: Operations at Twitter” , Velocity 2010(オラ
イリーのカンファレンス), http://www.youtube.com/watch?v=_7KdeUIvlvw (2010)52事例５）製品開発の様子をオープンにしている• 現在対応している不具合のリスト

出典: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert （無償のユーザ登録が必要）

53事例５）製品開発の様子をオープンにしている• 対応している不具合のリスト

出典: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert （無償のユーザ登録が必要）

54事例５）製品開発の様子をオープンにしている• 対応している不具合の詳細情報も閲覧できる。

出典: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert （無償のユーザ登録が必要）

55事例５）製品開発の様子をオープンにしている• Rational Team Concert（開発支援環境）のダッシュボード（プロジェクト情報の集約）

出典: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert （無償のユーザ登録が必要）

56事例６） 自動車のモデルベース開発• 自動車の設計においてモデル化により短納期を実現する。
– モデルでシミュレーションを十分に実施してから製作する。
– 試作、実車での試行錯誤、手戻り、調整を省く。
– 制御用ソフトウェアも同様にモデルベースで開発する。

出典: 原田 靖裕「ET2011基調講演よりSKYACTIVテクノロジーの誕生を支えたモデルベース
開発～世界一のため、創造のためのモデルベース開発（MBD）へ～」，SEC Journal vol. 8,
No.2, pp. 79-84(2012) http://sec.ipa.go.jp/sweipedia/catl033/catm047/cats047/56305/
57事例６） 自動車のモデルベース開発• レベル2に関連する記述– サーキットで最速のライン取りをドライバに模倣してもらい、他のドライバが最速と考えるラインよりも速く走れることを示した– 最初はモデルに懐疑的であった開発の最前線の専門家たち
が「このモデルが無ければ、この燃焼は絶対に実現出来なかった」と考えを変える。

• レベル4に関連する記述– すぐに商品展開しない場合でも、技術準備はモデルを用いて着実に進めておき、いつでも展開出来る状態にしておくことが理想状態であると認識している。
出典: 原田 靖裕「ET2011基調講演よりSKYACTIVテクノロジーの誕生を支えたモデルベース
開発～世界一のため、創造のためのモデルベース開発（MBD）へ～」，SEC Journal vol. 8,
No.2, pp. 79-84(2012) http://sec.ipa.go.jp/sweipedia/catl033/catm047/cats047/56305/
58

アンチパターン（べからず集）• 問題を見つけて終わりにする。
– 「～だからダメなんだ。ウチは」と根拠をみつける。
– 「～ヤツがいるからダメなんだ」と線引きする。

• ルール変更の余地を考えず「ルールだから」で終わり。
• 事例、知見、技術を何らかの形で活かさず終わり。

59

アンチパターン： 問題をみつけて終わりにする60

アンチパターン： 問題をみつけて終わりにする• ① 線を引く。

61

アンチパターン： 問題をみつけて終わりにする• ② 自分がいないほうの欠点を指摘し、批判をする。
ルールを守らないんだよ。あいつらは。

62

アンチパターン： 問題をみつけて終わりにする• ③ 安心してすっきりして、終わり。
ほんとに・・・。
ルールをまもればうまくいくのに。

63アンチパターン： 問題をみつけて終わりにする• ② 自分がいないほうの欠点を指摘し、批判をする。
～法を誤って理解している人もいますが・・64アンチパターン： 問題をみつけて終わりにする• ③ 安心してすっきりして、終わり。
ほんとに・・・。
もっと勉強すればうまくいくのに。

65

まとめ• 私の経験にもとづき4つのレベルに分解した。
• 品質向上活動には複数のレベルがあり、単純に技術・技法の延長線だけではうまくいかないことがある。
– レベル1 → 2: 合意– レベル2 → 3: 他との比較– レベル3 → 4: 競争力の分析• 他の事例を聞いてマネするだけではうまくいかない。
• 普段の活動を定期的に見直し、本当に品質向上につながっているか振返る。
• 参考情報– twitter: @smorisaki– ブログ: http://blogs.itmedia.co.jp/morisaki/
66

お知らせ
1. 当研究グループとの具体的な連携（有償の受託・共同研究）を募集しています。
–

詳細な統計データや海外動向との比較ができます。

2. 論文、記事等の公開情報をお知らせするメールニュースご希
望の方はメールアドレスをお知らせください。
– From: 情報をお送りするメールアドレス– To: ismoris@ipc.shizuoka.ac.jp– Subject: 論文、記事等の公開情報のお知らせ希望
– 本文
ご氏名:
ご所属:
– いただいた情報を本来の目的以外で使用することはありません。
67