「（ソフトウェア品質技術者のための）データ分析勉強会」で、小池利和さんに声をかけていただき、同人誌「メトリクス公団 Vol.2」の一部を執筆させていただいた。
私の執筆した章のタイトルは「診えていますか？炎上の兆候」である。
この同人誌が再販売されることはなさそうなので、ここに内容を記載しておく。
診えていますか？炎上の兆候
はじめに
プロジェクトが“炎上”した経験はあるだろうか？多くのプロジェクトマネージャや開発者が、「納期間際になってもテストが消化しきれず、毎日不具合が発見され続け、いつになったら開発が終わるのかわからない。」という状況を経験しているのではないだろうか？
計画した品質のソフトを遅れずにリリースするためには、早く炎上の兆候を掴み、手を打つことが重要となる。病気と同じで、手遅れになる前に兆候が掴めれば、炎上を防げる、炎上から抜け出せる可能性が生まれる。
本節では、炎上の兆候とその兆候を検知するメトリクスを整理した。その成果を「問診票」と呼ぶ。
炎上状態とは
SQiPシンポジウム2010の企画セッション「ソフトウェアプロジェクト・サバイバルガイド ～火消しの達人が贈る 混乱プロジェクトの救済法～」では、炎上プロジェクトを**「出口の見えないトンネル」「計器が壊れ飛び続ける飛行機」**と例え、以下のような症状が見受けられると議論されていた。
- 目標、ゴールが定義されていない。
- プロジェクト計画がない。計画書はずっと変わらない。
- 計画書を上司から言われて作り、上司のための計画になっている。
- 進捗報告がされない。進捗報告の内容が何日も変わらない。外から見ると何が起きているかわからない。
- 基本動作（工数入力、議事録作成、帳票更新、承認、時間を守る等）ができなくなる。また、「やらなくちゃいけないのは、わかっているんですけど、それどころじゃなくて」という発言がある。
- 協力を仰がない。当事者から「トラブル」とは言わない。「問題を打ち上げても、結局解決するのは自分なので」という発言がある。
- 挨拶をしない。声が小さい。よそよそしい。
問診票の作成方法
「ソフトウェア品質技術者のためのデータ分析勉強会（2015年度 第6回）」と「ソフトウェアテストシンポジウム 2014 東海（SIG）」でワークショップを実施し、炎上の兆候とその兆候を検知するメトリクスを整理した。ワークショップには、業務や立場の異なる約30名が参加した。
ワークショップでは、参加者の組織・プロジェクトで実際に見受けられた炎上の症状をもとに、炎上の兆候を掴むための「問診票」の作成を実施した。このワークショップの進め方、成果イメージ、参考にした技法・フレームワークを以下に示す。
ワークショップの進め方
ワークショップでは、問診票を以下のStepで作成した。
- 炎上の症状の洗い出し
- 炎上の症状の整理
- 確認事項とメトリクスの整理
ワークショップのタイムスケジュールを以下に示す。
| Step | 時間 | 作業種別 | 内容 |
|---|---|---|---|
| 1 | 10分 | 個人ワーク | 過去の経験から炎上の症状を洗い出す。 |
| 2 | 60分 | グループワーク | 炎上の症状をグルーピングし名前付けする。キーワードをもとに、見逃していた新たな症状を追加する。 |
| 3 | 60分 | グループワーク | GQM形式で確認事項とメトリクスを整理する。GQMのゴールは「計画した品質の製品を納期までにリリースする」とする。 |
ワークショップの成果イメージ
ワークショップで作成した成果イメージを以下に示す。
■炎上の症状
■問診票（確認事項とメトリクス）
問診票作成時に参考とした技法・フレームワーク
GQM
目的の達成に必要なデータとして何を測定するか定めることが重要。その際には、GQM（Goal-Question-Metric）と呼ばれる思考フレームワークが役に立つ。
まず、ソフトウェアやその開発プロセスを通して達成したい組織の目標（Goal）を定める。次に、その目標を達成できたかどうかを知るために必要な質問（Question）を定める。そして、その質問に答えるために必要なメトリクス（Metric）を定め、目標の達成度合いを定量的に示す方法を定める。目標からトップダウンに考えることで、目的と整合性のあるメトリクスを定めることができる。
今回のワークショップでは、「目標を達成できたかどうか」ではなく「目標を達成できそうか」を知るために必要な質問（確認項目）を抽出した。
PMBOKの知識エリア
PMBOK（プロジェクトマネジメント知識体系ガイド）では、知識エリアが定義されている。ワークショップでは、以下の知識エリアを、炎上の症状を洗い出しと症状のグルーピングをするときに、キーワードとして使用した。
- 統合
- スコープ
- タイム
- コスト
- 品質
- 人的資源
- コミュニケーション
- リスク
- 調達
「SECBOOKS：ITプロジェクトの「見える化」」のフレームワーク・ツール
「SECBOOKS：ITプロジェクトの「見える化」 ～下流工程編～」では、「見える化」「言える化」「直せる化」を可能とする現場に立脚した方法論を創出することを目標として、フレームワークやツールを提供している。
- 見える化
プロジェクトで発生した事象、あるいは何かの予兆が見える - 言える化
見えたものから真の問題が何かを言える - 直せる化
問題の対応策を策定する
ワークショップでは、以下の3つのフレームワークとツールを参考に、問診票を作成した。
- 知識エリア
PMBOKの知識エリアに加えて、「顧客」「組織」「基本動作」「モチベーション」「技術」「課題管理」という6項目を追加定義している。 - 症例分類表
プロジェクトで起こる問題の「発生個所」と「状態」に注目し、過去のプロジェクト失敗事例を分析して、体系化している。 - 測定項目リスト
プロジェクトの状況を定量的に「見える化」するために、有識者の知見や世の参考文献を基に、測定項目を体系化し示している。
「計画した品質の製品を納期までにリリースする」をゴールとしてGQM形式に整理した測定項目リストを参考として以下に示す。ワークショップでも以下を参考にしている。
■測定項目リストの整理結果（GQM形式）
炎上の症状と問診票
ワークショップで作成された成果物を統合・整理し、「炎上の兆候を掴む問診票」を作成した。問診票は、GQMの構造を参考に、[症状]－[質問]－[メトリクス]という構造とした。
- 症状
炎上の兆候を示すプロジェクトの状態 - 質問
炎上の症状が出ているかを知るための質問 - メトリクス
質問に答えるために必要なメトリクス
また、ワークショップの結果を分析した結果、炎上の症状には因果関係があり、因果関係はツリー構造ではなく、循環するような構造となることがわかった。先に述べた問診票の構造ではでは、この症状の因果関係を示すことが難しい。そこで、問診票だけでなく、炎上の症状の因果関係を示す「炎上の症状の関連図」も作成した。
「炎上の症状の関連図」で、症状「炎上」に直接関連づいていない、離れた位置にある症状を掴むことができれば、炎上の兆候を“早く”掴むことができる。
以下に、作成した「炎上の症状の関連図」と「炎上の兆候を掴む問診票」を示す。
■炎上の症状の関連図
■炎上の兆候を掴む問診票
おわりに
問診票に対する所見と今後の課題・期待を示す。
問診票に対する所見
見るべきメトリクスは多い
問診票を作成すると多数の質問・メトリクスが抽出される。プロジェクトマネージャが、全てのメトリクスを毎週計測して、質問に回答することは負担となり、実施することが難しい。確実に炎上の兆候を掴むためには、定期的かつ客観的な診断ができるSQAやPMOといった組織が、必要になると思われる。
工数は重要なメトリクス
問診票作成時に抽出されたメトリクスには工数を使用するものが非常に多い。炎上の兆候を掴むためには、実績工数データをいつでも利用できる状態にすることが必要となる。また、工数計測を定着させることは、組織の重要な課題である。
今後の課題・期待
課題
今回定義した問診票は、現場で活用し効果を生み出せる状態にはなっていない。問診票が活用されている状態とするためには、以下が必要となる。
- メトリクスの計測方法の定義
- データを計測する仕組みの構築と計測
- 統計手法を用いたメトリクスの有効性の証明
- 問診票の使用方法の明確化
新たなデータの計測を始めることはハードルが高いため、既に計測できているデータが活用できるメトリクスから、一つずつ有効性を証明していくとよい。
期待
炎上の症状は、組織の文化やプロセスの影響を受けるため、組織ごとに異なると思われる。また、自分の問題と繋がらないメトリクスは、計測の必要性を感じられず、定着しないことが多い。そのため、問診票は組織毎に作成する必要があるのではないかと考えている。
今後、各組織のSEPGやSQAが、自組織の炎上の症状を整理し、問診票を作成し、活用する活動が広がっていくことを期待している。そして、少しでも炎上プロジェクトが減り、エンジニアがつまらないスケジュール調整等の作業に時間を割くのではなく、魅力的な成果物を作るための活動（リファクタリング、技術や知識の獲得活動、プロセス改善）に時間を割けるようになることを期待している。
参考文献
[1] 「SECBOOKS：ITプロジェクトの「見える化」 ～下流工程編～」、日経BP社、2006
[2] 野中誠・小池利和・小室睦、「データ指向のソフトウェア品質マネジメント」、日科技連出版社、2013
参考発表
関連記事