『知識ゼロから学ぶソフトウェアプロジェクト管理』と、品質管理のメトリクス

　いくつかのレビューで好評だった、勝呂暖生さんの『知識ゼロから学ぶソフトウェアプロジェクト管理』を読んでみました。

知識ゼロから学ぶソフトウェアプロジェクト管理

　高橋寿一さんの『知識ゼロから学ぶソフトウェアテスト』と似た書名・装丁の本書。

知識ゼロから学ぶソフトウェアテスト 【改訂版】

 　第一印象は、「うわ、すごく書き殴ってるな！」でした。

　ずば抜けて有能で、知識も経験も豊かなベテランに、恐ろしく早口な口伝で教わってるような。話している方は雑談風味なんだけど、聴いてる方はメモ取らなくちゃいけない大切な話が多すぎて頭がパンクしそうになってる、そんな本です。　

 

　口伝と違うことの1つは、それぞれの教えが経験のみならず、先哲の知恵にも基づいており、参考文献として豊富に紹介されていることです。でも、詳細にはあまり立ち入らない。知りたければ、英語だろうと読め！というスタンス。

　「伝えたいこと」として筆者が挙げる、以下4つのtipsを軸に話が進みます。

• 一人一人のエンジニアのアウトプットを最大限にする
• 変更に体制を持つ開発スタイルにする
• 品質第一主義
• 非機能要求は上流から下流まで特別な扱いをする

　要求定義・アーキテクチャ・開発スタイルと章ごとに切り口は違いますが、筆者が伝えようとするポイントが、この4つに集約されています。

 

Microsoftで使っている品質管理メトリクス

　職業がら、第7章3節の「品質管理」にもっとも興味がわきました。
　そこでは、MicrosoftのJamese Tierney氏が使っているというメトリクスが紹介されています。
　バグ・テスト・ソースコード・信頼性・ビルド・スケジュールという6つのカテゴリーがあり、バグやテストは目新しいものではないのですが、信頼性のメトリクスはわたしにとって新鮮でした。以下の3つです。

実際の顧客が最も使うとおもわれるオペレーションをした際のMTBF ストレステストを行った際のMTBF 信頼度成長曲線

　著者は信頼度成長曲線を信頼していませんが、MTBFの計測には意味があると言っています。ここでいうMTBFはざっくり言うと、ソフトウェアを利用していて、どのくらいの時間でおかしくなるか、ということです。

　SRATSでも、日ごとのテストケース消化とバグ発生の推移をインプットとし、MTBFを算出することができます。ただ信頼度成長曲線を描くのと一緒に出てくるものであり、成長曲線とMTBFの価値に、どれだけの差があるのかがよくわかりませんでした。
　MTBFの推移の管理をしている品質管理屋さんがいらしたら、ご意見を聞きたいです。

MUFGのシステム統合で使っていた品質管理メトリクス

　これも最近読んだ『システム統合の正攻法』についても言及しておきます。

システム統合の「正攻法」

 　大規模システム同士（しかもそれぞれ自体が過去に統合したもの）の統合における、技術的な深堀りを期待して、本書を読みました。ですがトピックはプロジェクト管理中心で、後半になるほど「統合成功を記念して刊行！」みたいなノリになっていくのがイマイチでした。。。

　それはいいとして、史上最大規模のシステム統合プロジェクトで使われていたというメトリクスとして、以下が紹介されています。

不良発生類型の比率推移 前フェーズまでに発見すべき不良の比率推移 不良摘出率とテスト進捗率 重大度の比率推移 影響度の比率推移 収束曲線 収束傾向（前フェーズ対比） バグの対応残数の推移

　Jamese Tierney氏のカテゴリーでいうと、バグのメトリクスということになります。
　これらもそれほど目新しいわけではないのですが、2.の「前フェーズまでに発見すべき不良比率」を時間軸で見ているのはよいなと思いました。
　個人的には、フェーズの終わった最終状態でこの比率を確認することはよくあるのですが、推移はあまり見ていません。あるフェーズの十分性を次のフェーズでも継続して監視するのはよさそうです。

　もちろん「発見すべき」というのは、バグ票の起票者が判断・入力するという手間がかかっているのですが、集めるべき価値のある情報だとわたしは思っています。バグ票を書きまくる立場の方からの意見も聞きたいですね。めんどくさいですか？

まとめ？

　全然レビューになっていませんが、『知識ゼロから学ぶソフトウェアプロジェクト管理』は面白かったです。わたしの第3の書庫（会社の資料室）に保管してあるので、いつでも読めて安心です。
　プロジェクト管理の教科書的な話でなく、実務者のぶっちゃけた本音を知りたい方にオススメです。