ソフトウェア病理学第２章：共通のソフトウェアリスク

森　龍二

1

導入部• リスク認識と実証データを集めるために監査やアセスメントを実施

• 数百のプロジェクトから百超のリスク要因を分析

• この本では約６０個のリスクについて扱う

2

訴訟リスク• 従業員の不当解雇

• 著作権違反

• 契約上の義務の不履行

• 不当に抜かれた代金の返還

• 従業員の服務契約違反

• 企業秘密の不正流用

• 役員に対する信認義務違反

• ソフトウェア瑕疵による損害賠償

• 契約した仕事の責任範囲を巡る係争

日本でも活発化

3

６つのドメイン(1)経営情報システム(MIS)

(2)システムソフトウェア

(3)市販ソフトウェア

(4)軍用ソフト

(5)請負契約またはアウトソースのプロジェクト

(6)エンドユーザによるソフトウェア

4

(1)経営情報システム(MIS)

5

経営情報システムとは

6

• 経営情報システム(MIS;Management

Information Systems)とは組織内で使われるコンピュータベースの情報システム

• 60～70年代に流行

• 保険のクレーム処理、経理、受注処理など

Wikipediaより

経営情報システム(MIS)のリスク

7

要件の拡大

納期のプレッシャー

低品質

赤字

構成管理の失敗

0% 25% 50% 75% 100%

50%

55%

60%

65%

85%

該当プロジェクトの割合

MISリスク詳細• 「要件の拡大」：月に１％以上の変更量

• 「納期遅れ」：通常より2割以上短い

• 「低品質」：１FPごとに0.5個以上のバグ(年間)

• 目安：１FP≒40～100LOC(Java)※

• バグの除去と予防ができていない

• 「赤字」：平均で15%の予算超過

• 「構成管理の失敗」：設計書、ソースコードの管理ミス

8

※「ソフトウェア見積もり」（スティーブ・マコネル）

(2)システムソフトウェア

9

システムソフトウェアとは

10

• 物理デバイスを制御するためのソフト

• コンピュータのOS

• 電話交換機のソフトスイッチ

• 自動車の燃料噴射制御の車載ソフト

• 高品質・高信頼性が要求される

システムソフトウェアのリスク

11

長い開発期間

コスト見積もり失敗

過度な文書作成作業

バグの偏り

プロジェクトの中断

0% 25% 50% 75% 100%

35%

50%

60%

65%

70%

該当プロジェクトの割合

システムソフトウェアリスク詳細• 「長い開発期間」：＞３年

• 「コスト見積もり失敗」：見積もりツールの未使用

• 「過度な文書作成作業」：３つの条件

1. ドキュメントの種類が50以上

2. 事務作業のコストがプロジェクト全体の５割以上

3. １FPあたり2000ワード以上のドキュメント

• 「バグの偏り」：IBM OS/360では4%のモジュールに38%のバグが集中

• 「プロジェクトの中断」：

1. １年以上の遅れ、50%以上の予算超過

2. パフォーマンスと品質の基準をクリアできなかった

12

(3)商用ソフトウェア

13

商用ソフトウェアのリスク

14

ユーザドキュメントの不備

不満なユーザ

投入時期が遅い

競争相手からの危害

高額な訴訟費用

0% 25% 50% 75% 100%

30%

45%

50%

55%

70%

該当プロジェクトの割合

商用ソフトウェアリスク詳細(1/2)• 「ユーザドキュメントの不備」：原因

1. 新しいソフトの最初のリリースは難しい

2. 優秀なライターやイラストレータを雇う金がない

3. 最先端のソフトは未熟で変わりやすい

• 「ユーザの不満」

1. 低品質

2. 欲しい機能がない

3. コマンドが難しい

4. 学習曲線が緩やか

5. インストールがやっかい

6. カスタマーサポートが貧弱

7. やたらとディスクやハードを食う15

商用ソフトウェアリスク詳細(2/2)

• 「投入時期が遅い」：開発に３年以上かかると市況が変化する

• 例：OS/2とWindows

• 「競争相手からの危害」：

1. ネガティブキャンペーン

2. ウソの宣伝文句

3. あからさまな著作権違反

4. ルック＆フィールの模倣

5. 特許・商標権違反

6. 食い合いの価格競争

• 「高額な訴訟費用」：訴訟確率が50%を超える（99年までに)16

ｃ MacとWindows

アップルとサムスン

Officeの低価格化

(4)軍用ソフトウェア

17

軍用ソフト？

18

• 日本じゃ関係ないイメージ→No!

• DoD-STD-2167A：米国国防総省の開発標準

• 2167：ウォータフォール（＋インクリメンタル）

• 2167A：がちがちのウォーターフォール

DoD-STD-2167Aのプロセス図

軍用ソフトウェアのリスク

19

過度の文書作成作業

低生産性

長い開発期間

要件の拡大

未使用・使用不可

0% 25% 50% 75% 100%

45%

70%

75%

85%

90%

該当プロジェクトの割合

軍用ソフトウェアリスク詳細• 「過度の文書作成作業」

• 文書タイプ：～100種類

• 6ページ/FP(400語/Adaプログラム１行)

• 全体工数の約52%(実装は25%以下)

• 「低生産性」：米国平均は5FP/人月、軍用は3FP/人月

• 「長い開発期間」：５年を超えたら危険

• 「要件の拡大」：機能の50%～60%が変更されたもの

• 「未使用・使用不可」：開発期間の長さが主な原因

20

(5)請負契約またはアウトソース

21

請負契約・アウトソースのリスク

22

高い維持管理費

請負会社と顧客の摩擦

要件の拡大

不測の受け入れ基準

成果物の法的所有権

0% 25% 50% 75% 100%

20%

30%

45%

50%

60%

該当プロジェクトの割合

請負・アウトソースのリスク詳細• 「高い維持管理費」

• 米国平均：$125/FP、請負：$200/FP

• 一人が維持管理可能なFP：500～1500

• 高い原因は実装の詳細を知らないこと

• 「請負会社と顧客の摩擦」：法的争いに発展しがち

• 「要件の拡大」：追加費用でもめがち

• 「不測の受け入れ基準」

• 最初の契約になかった受け入れ条件を後から入れられること

• 「成果物の法的な所有権」：契約時に必ず確認すること

23

スルガ銀行とIBM

(6)エンドユーザによるソフトウェア

24

エンドユーザソフトのリスク

25

引き継げないアプリ

隠れたエラー

維持管理不能

冗長なアプリ

成果物の法的所有権

0% 25% 50% 75% 100%

20%

50%

60%

65%

80%

該当プロジェクトの割合

エンドユーザソフトのリスク詳細

• 「引き継げないアプリ」• 作者本人しかわからないUI、ドキュメント不在

• 「隠れたエラー」：レビュー、品証活動なし• 「維持管理不能」：担当者が退職すると終わり• 「冗長なアプリ」• 同時並行：同じ仕事をする従業員が同時に同じアプリを開発• 時系列：任期のある職場で、その期間内で同じアプリを開発• 「成果物の法的所有権」：退職時に所有権を主張するケースなど

26

共通のソフトウェアリスクを防ぐには

27

要求の拡大

28

• 実証済みの方法論を使う

• プロトタイピング、Joint Application Design(JAD)

• Information Engineering

• Funtion Point

• FPベースの契約にする

• 自動化

• 要件定義でFP数算出→見積もりツール→CASEツール

• 要件の再利用

スケジュールに関するもの• スケジュールリスクを減らす技術

1. スケジュールの評価・計画を改善する

2. スケジュール遅延を減らす

• 納期予測ツールが正確でも顧客や経営層の意向に沿わないと簡単に無視される

• スケジュール遅延を減らす方法

29

A 再利用（設計・コード・その他成果物）B オブジェクト指向分析・設計・実装C CASEツールD Information Engineering, Rapid Application Development

E 構造化分析・設計（大規模向け）F レビュー、インスペクション、品質制御

赤字• 赤字防止に必要な３つの技術

1. コスト見積もりを正確にする技術

2. 実際に開発コストを減らす技術

3. コストを正確に測る技術

• Function PointまたはFeature Pointを使え

• Line Of Codeでは曖昧で矛盾を含んでおりダメ

• 海外アウトソース(現実には難しいようですが...)

30

低品質(1/2)• 品質を制御する４つの技術

1. 品質と信頼性の評価ツール

2. 欠陥防止法

3. 欠陥除去法

4. 品質計測プログラム

• 品質評価ツールの数は少ないが成長分野(93年時点)

• 欠陥防止法

31

A 構造化分析・設計技法B プロトタイピングC 高級言語、オブジェクト指向言語

D 手続き型言語で構造化実装法の厳格な適用

E 品質機能展開(QFD)

F TQM法G 品質保証部(SQA)

H クリーンルーム法

低品質(2/2)• 欠陥除去法

• デザインレビュー

• 構造化ウォークスルー

• フォーマルインスペクション→最も欠陥除去効率がよい！

• 形式手法

• あらゆるテスティング

• 品質計測プログラム：特に記述なし

• ファンクションポイントは1991年適用開始

• ISO 9000-9004品質標準

• 標準のクリアと成果物の品質には特に関連なし

• 標準の遵守に時間を浪費する傾向あり→これは今も変わらず32

高い維持管理費(1/2)• 「維持管理」は拡張と欠陥除去の両方を指す

• リスク低減法

• 構造的複雑度の分析ツール

• 再構築ツール(COBOL, C)

• リバースエンジニアリングツール

• リエンジニアリングツール→保守支援ツール

• エラー傾向モジュールの分析と除去

33

高い維持管理費(2/2)• ハートフォード生命の例

• 同業他社の年間予算の50%は維持管理

• ハートフォードは19%以下で低下傾向

• 10年前から複雑度分析、リストラクチャリング、リバースエンジニアリング、リエンジニアリングを実施

• 維持管理費に苦しむ人(予算の50%以上を浪費)でシステムの「老人介護」を行っているのはそのうちの5%

• 維持管理費が25%以下の人のうち65%は対策を行っている

34

制御が困難なリスク要因

35

過度の文書作成作業

36

• 軍関係など、標準に厳格なプロジェクトでは軽減は難しい

• 誰も最適な文書量を知らない• 昔は紙の方が経済的だった• 今は光学ディスクの方が安い(93年ですから)

• →今だとUSB, SD, MicroSD, ...etc.

不適切なユーザドキュメント

• 明確にドキュメントを書ける人は比較的少ない

• ただし大企業で技術文書作成、編集、イラスト化の専門部署を持つところを除く

• マルチメディアの発展がこの状況を変えるかも(93年なので...)

37

ユーザの不満• 全部が難しいわけではないが解決は易しくない

• GUIへの移行は一つの解決策

• サポート、ヘルプ、ドキュメントの改善

• ユーザの満足度調査は増えてきているが、長い期間行うのがおすすめ

38

お客様と契約者との摩擦

• 人間の本質からしかたのないこと

• すぐに状況を改善する秘策はない

• ソフトウェアだけではなく昔からあること

39

法的問題と訴訟費用• 時間の経過とともに大きくなってきた問題• 商用ソフトでは大きな問題• 米国は高価な訴訟のリーダー• 米国はソフトウェア製品に対するリーダーシップを失い、取引のバランスを欠く恐れ

• 技術専門家がフルタイムでQCDを監視し、訴訟の証人となるケースもある

40

まとめ

41

まとめ

42

• リスク管理やプロジェクトアセスは”ソフトウェアエンジニアリング”への近道

• すべてのリスク要因が制御可能ではない• リスク分析とアセス法は大事な問題点を見つけるのに有効

• 問題点さえはっきりすれば何らかの解決法はある