ソフトウェア病理学  in  SQiPシンポジウム  2013

2013/9/12  森　龍二(エクサ)

お品書き

•  ソフトウェア病理学とは  •  読書会について  •  読書会で扱った病気  •  病気を作ってみようワークショップ  – プロジェクトや身の回りで経験した病気を挙げる  – マップ上に貼り付ける  – その中から一例について、簡単に病理学の形式でまとめてみる  

•  まとめ  •  告知

自己紹介

•  @mori_ryuji  •  エンプラ系SIer  •  本職はR&D  – テスト技法やらテストツールやら調べてます  

•  QI法による第三者レビューやってます  •  客先常駐はしんどいです  

ソフトウェア病理学とは

ソフトウェア病理学とは

•  Capers  Jones氏の著作  – Assessment  and  Control  of  SoFware  Risks(1994)  

•  ソフトウェアとプロジェクトの失敗を病気になぞらえて分類した本  

•  邦訳「ソフトウェア病理学」は絶版  •  読んでみると20年前とは思えない内容に圧倒  

読書会について

読書会の目的

•  20年前の病気について本から理解し共有する  – 現在と同じところ、違うところ  

•  20年経った現在固有の病気を探し出す  – 本SIGの目的でもある

読書会の経緯

•  開催場所：(株)エクサ会議室(川崎)  •  開催頻度：2月に1回程度  •  参加人数：平均6名程度  •  参加ルール：毎回2名、好きな1章をパワポにまとめてくる宿題あり  

2012 10/31 12/5 2013 2/20 4/11 5/27 9/25

第1回 第2回 第3回 第4回 第5回 第6回

本書の構造

・Preface→病気のテンプレート  ・IntroducPon→SPR社のアセスメントの経緯と概要  ・共通のソフトウェアリスク→業種別リスク分析  ・最も深刻なソフトウェアリスク→深刻度別ランキング  ・病気→具体的な60例の病気  

Preface

IntroducPon

共通

 

最

深刻

 

病気(60個)

病気のテンプレート(1/2) # 原文 和訳 説明

1   DefiniPon   病状 病気の定義

2   Severity 重症度 5段階の重症度の定義 3   Frequency 感染率 感染の割合  4   Occurrence 発病 どういうプロジェクトで罹るか  5   SuscepPbility  and  

resistance 感受性   かかりやすい状況  

6   Root  causes 病原 病気の根本原因  7   Associated  problems   合併症 同時発症しがちな病気  8   Cost  impact 経済的影響 被害額  9   Methods  of  prevenPon   予防法 予防に使うツールや方法論  10   Methods  of  control 治療法 治療に使うツールや方法論  

病気のテンプレート(2/2) # 原文 和訳 説明

11   Product  support   支援ツール ツールの詳細

12   ConsulPng  support コンサルティング 治療に使えるコンサルタント

13   EducaPon  support 教育 どういう教育コースがあるか  14   PublicaPon  support     関連書籍 この病気を扱う書籍  15   Periodical  support 関連雑誌 この病気を扱う雑誌  16   Standards  support 規格 この病気を扱う標準類  17   Professional  associaPons 専門機関 この病気を扱える企業・組織  18   EffecPveness  of  known　

therapies 治療効果 治療法の実際の効き目  

19   Costs  of  known  therapies

治療費 治療に必要なコスト  

20   Long-­‐range  prognosis 将来展望 この病気の未来  

項目が多いので今回は簡略版テンプレートを使います

簡略版テンプレート

項目 説明

名前 病気の名前

病状 病気の定義

病原 病気の根本原因

予防法   新たな発生を抑える方法

治療法 もう罹ってしまったものを治す方法

読書会で扱った病気

読書会で扱った病例

•  第１１章：「欠陥多発モジュール」 •  第３６章：「不適切なソフトウェア工学ツールと技法」  •  第６章：「プロジェクトの中止」 •  第２５章：「不適切な構成管理」 •  第３８章：「再利用性の低いシステム構成」  •  第４１章：「再利用性の低い設計」  •  第５０章：「低生産性」 •  第２８章：「不適切な計測」  •  第５４章：「管理者の不当行為」 •  第１３章：「過酷なスケジュール」

第１１章：「欠陥多発モジュール」

項目 説明

名前 欠陥多発モジュール

症状 1モジュールに対して、1FPあたり0.5個以上バグが出てしまう

原因 (1)計測していない  (2)レビューしていない  (3)教育の問題

予防法   ツールを導入、レビューする、教育する

治療法 とにかく計測してあたりを付けて集中して治す

第３６章：「不適切なソフトウェア工学ツールと技法」  

項目 説明

名前 不適切なソフトウェア工学ツールと技法

症状 要求分析、設計、部品の再利用、欠陥除去、維持管理に方法論や自動化の取り組みがない

原因 (1)必要な方法論やツールがわかっていない  (2)そもそも測っていない  

予防法   コンパイラからCASEツールまで、ツールの機能数ごとに整理

治療法 ツール導入の抵抗感をなるべく減らしてから導入する

第６章：「プロジェクトの中止」

項目 説明

名前 プロジェクトの中止

症状 客先に納品される前に中止になるプロジェクト。コーディングからテスト初期が多い

原因 (1)そもそも計画や見積もりが杜撰  (2)品質が悪い  (3)開発期間が長すぎて状況が変わった  (4)相次ぐ仕様変更

予防法   見積もりツールを使う（２つ以上）

治療法 大量のサービス残業、機能削減、延期  （好ましくはないが）

第２５章：「不適切な構成管理」

項目 説明

名前 不適切な構成管理

症状 開発資料を管理する正式の仕組みがない  （日本の普及率25%）

原因 (1)極めて複雑で人間が扱えるものではない  (2)効果が認識されず、コストとして見積もられない

予防法   要件定義段階から導入する

治療法 ツール購入（他社製品、自社開発、他社のカスタマイズ）

第３８章：「再利用性の低いシステム構成」

項目 説明

名前 再利用性の低いシステム構成(Architecture) 症状 (1)再利用より新規開発を優先  

(2)再利用前提のプロセスになっていない 原因 ソフトウェア工学や製造技術を元に作業してい

ない

予防法   (1)再利用計画を作成し、資金援助する  (2)企業文化として定着させる

治療法 特に有効な治療法はない

第４１章：「再利用性の低い設計」  

項目 説明

名前 再利用性の低い設計

症状 (1)アプリ毎に一般化した設計モデルがない  (2)再利用可能な設計を支援する規格がない

原因 (1)標準設計技術を開発しなかった  (2)部品を簡潔に表す言葉がない  (3)仕様書の量が膨大すぎて使えない

予防法   設計を再利用する利益性に注目する

治療法 最初から再利用可能な設計がないかぎりムリ

第５０章：「低生産性」

項目 説明

名前 低生産性

症状 (1)同種プロジェクトの業界平均より低い  (2)1人月あたり5FP以下  (3)顧客・経営者から生産性低いと言われる

原因 (1)熟練の技が必要  (2)設計・部品の再利用性が低い  (3)定量データが測定されていない  (4)生産性を高める投資が不十分  (5)顧客・経営者が品質を無視する

予防法   再利用を進める。欠陥を管理する

治療法 ツールや方法論を導入する

第２８章：「不適切な計測」  

項目 説明

名前 不適切な計測

症状 (1)不合理・不健全な尺度の採用  (2)プロジェクト要因に影響する測定をしない

原因 (1)ソフトウェアは測定できないという思い込み  (2)測定をいやがる風土  (3)規格の不在

予防法   「事実による管理」を実感、推進する

治療法 (1)測定計画を立てる  (2)欠陥の原因、重大度、除去工程を定義  (3)トライアルを実施  (4)結果はレビューし、改善提案に繋げる

第５４章：「管理者の不当行為」

項目 説明

名前 管理者の不当行為

症状 (1)問題を未然に防ぐ手立てをしない  (2)基本的な管理業務での失敗を繰り返す  (3)欠陥の多いソフトウェアを繰り返し納品  

原因 (1)管理者の業績判定基準がない  (2)管理者教育が不十分  

予防法   管理者教育の徹底。管理者評価基準の設定

治療法 (1)ベストはクビ（日本では難しい）  (2)管理者以外への転向  

第１３章：「過酷なスケジュール」

項目 説明

名前 過酷なスケジュール

症状 顧客・経営者が技術的に不可能な短い期間でソフトウェアを納品・稼働させることを強要する

原因 (1)見積もりの失敗  (2)ゆとりがあると受注できない

予防法   (1)見積もり・計画作成支援ツールの導入  (2)プロジェクトデータの収集・蓄積  (3)再利用可能な成果物の活用  

治療法 (1)延期、もしくは機能削減  (2)ソルジャー投入

重大  

短期的  4象限による分類

長期的  

軽微  

死に至る病

慢性的重大病

簡単に治る病

じわじわと体力をそぐ病

横軸＝重大度  縦軸＝病気発症までの時間

重大  

短期的  プロジェクトの中止

欠陥多発モジュール

4象限上へのマップ

不適切なソフトウェア工学ツールと技法

不適切な構成管理

再利用性の低いシステム構成

再利用性の低い設計

低生産性

不適切な計測

管理者の不当行為

過酷なスケジュール

長期的  

軽微  

※あくまで個人の感想です

病気間の関連図

プロジェクトの中止

欠陥多発モジュール

不適切なソフトウェア工学ツールと技法

不適切な構成管理

再利用性の低いシステム構成

再利用性の低い設計

低生産性

不適切な計測

管理者の不当行為

過酷なスケジュール

関連の多いもの

病例を作ってみよう  ワークショップ

【ワーク１】

•  開発現場で起こる病気を列挙してみよう  – 病名を付箋に書く（個人ワーク）  – 付箋を4象限上にマップ（グループ単位）  

•  4象限の説明  – 横軸＝重大度  

• プロジェクト成功への影響度  

– 縦軸＝病気発症までの時間  • 突発的に発生する（短期的、急性）とじっくり時間を掛けて発症する（長期的、慢性）

重大  

短期的  

4象限上にマップ

思いついた病気を貼り付けてみよう

ここかな？

ここかも？

※なにぶん病気の情報ですので、  大人の対応でお願いします  ※貼り付けた方はその場で説明お願いします  

長期的  

軽微  

【ワーク２】病気を詳細化しよう

•  グループワーク  •  4象限にマップした病気についていくつかピックアップ  

•  簡易版テンプレートに従って病気を詳細化する  •  グループで発表

【再掲】簡略版テンプレート

項目 説明 解説

名前 病気の名前 病気の内容がわかるキャッチーな名前。おちゃらけ可  「なんちゃってレビュー症候群」とか

病状 病気の定義 ここはしっかり。状況と症状

病原 病気の根本原因 はっきりしない場合は想像でも可

予防法   新たな発生を抑える方法 病原の裏返しでも可

治療法 もう罹ってしまったものを治す方法

病原の裏返しでも可

※簡易テンプレート使用例

項目 説明

名前 静的解析ツール欠乏症

症状 単体テストレベルのバグが統合・システムテストで頻発  

原因 (1)静的解析ツールを知らない (2)ツールなしで開発が進んでしまっている

予防法   静的解析ツールに関する研修を実施

治療法 (1)とにかく導入し、逐一報告を上げさせる (2)バグのトリアージを実施し、修正対象を決める

まとめ

まとめ

•  20年の時を経ても変わらないもの  – きちんと計測し、数値に基づいて判断する  – すでに実証されている方法論やツールを使おう  – 20年前の病気はそろそろ克服したい  

•  新たな病気を認識し、未来につなぐ  – 新しい開発方法論、プロセスがもたらすもの  – ハードウェアの劇的進化がもたらすもの  – 人と人のつながりの変化がもたらすもの  

告知

•  読書会の今後  – 継続？新たな書籍？  

•  こくちーずにて次回開催をお知らせ  •  読書会は聞くだけでもオッケー  – 書籍購入は不要です  – 宿題担当の方には資料をお渡しします  

•  参加者は専用のGoogleグループにて過去資料/議事録が閲覧できます  

•  詳細は読書会にて