静的解析ツールのROIを算出したいというお客様向けにプレゼンした資料です。基本的な考え方とROI算出の前段階として何が必要か書いたものです。

2. 静的解析ツールのROI
Masaru Horioka
Senior Sales Engineer –
APAC
Rogue Wave Software Japan

3. 静的解析の効果って？
• バグ（プログラミングエラー）の発見（予防）
– テストやレビューでは見逃されたプログラミングエラーの発見
– コーディング、CI段階でバグを発見することにより、後工程への混入を予防
• 工数削減
– 人手による（プログラミングエラーを見つけるための）コードレビュー、デバッグ時間の削
減
• 将来的なリスク低減
– コーディングルール、メトリクスにより、プログラミングエラーが混入するリスク・技術的
負債を下げる
• 教育
– 全てのプログラマがセキュアコーディングの本を読むわけではない
– 静的解析に指摘されたことを確認しながら学ぶ
• スタンプ
– 納品先に「静的解析かけてます」って言える

4. 静的解析の効果って？
• バグ（プログラミングエラー）の発見（予防）
– テストやレビューでは見逃されたプログラミングエラーの発見
– コーディング、CI段階でバグを発見することにより、後工程への混入を予防
• 工数削減
– 人手による（プログラミングエラーを見つけるための）コードレビュー、デバッグ時間の削
減
• 将来的なリスク低減
– コーディングルール、メトリクスにより、プログラミングエラーが混入するリスク・技術的
負債を下げる
• 教育
– 全てのプログラマがセキュアコーディングの本を読むわけではない
– 静的解析に指摘されたことを確認しながら学ぶ
• スタンプ
– 納品先に「静的解析かけてます」って言える
直接的で計算しやすい

5. ROI算出における課題
1. そもそもツールを活用できていない
1. ROIの計算の仕組みがない
2. ROIの計算方法がわからない
ツールを問わず、実はこ
れが多い！

6. 大事なこと その１
• 指摘内容を定期的に確認し、選別していますか？
• 指摘内容が妥当な場合、コードを修正しています
か？
→ 修正しない限り効果はない
• 定期的に解析を実行していますか？
→ 一度限りの解析だと修正されたか、副作用がな
いかが確認できない

7. 大事なこと その２
• 選別、または修正件数はカウント可能ですか？
• ROIを計算できればよいので、必ずしも完璧なカウント方法
である必要はない
• （半）自動で計算できるかどうかが鍵
• カウント方法の例
– Klocworkのレポート、APIを用いてカウント
– バグトラッキングシステム、コミットログ等からカウン
ト

8. Klocworkのレポート
1. プロジェクト一覧
2. ステート別の全ての指摘
3. モジュール別の修正活動
注意事項：Klocworkシステム上は、過去の解析で存在した指摘
が次の解析で存在しない場合、修正されたとみなされるため、
コードの大幅な変更や削除により修正済みとカウントされてし
まうことがある。
選別データと合わせて判断する

9. みなさんのプロジェクトはどうでしょ
うか？
修正済み(Fixed) の件数が表示されていますか？

10. みなさんのプロジェクトはどうでしょ
うか？
レポート > ステート別の全ての指摘
Fixedの指摘が
ありますか？

11. みなさんのプロジェクトはどうでしょ
うか？レポート > ステート別の全ての指摘 （ステータスを追加したカスタムレポートを
作成）
選別ステータスが
「Fix」かつFixedのみを
表示

12. みなさんのプロジェクトはどうでしょ
うか？
レポート＞モジュール別の修正活動
「デスクトップ指摘」を選択すると、コネク
テッドデスクトップ解析使用中に発見され修
正された指摘件数がカウントされる＝チェッ
クアウトからチェックイン前までに発見され
修正した問題をカウント

13. そもそもうまく活用できていない場合
プロセス化、自動化
• プロセス化
• 現実的な（アクション可能な）修正目標
• 確認すべき指摘の絞り込み例
• デフォルト or Sev 1, 2のみ or さらに絞り込み（サンプリングして決
める）
• 過去のバージョンの指摘は一旦Filter（新規不具合のみ着目）
• サードパーティコードは除外(ignoreステータスか、ビュー、モ
ジュール機能を活用)
• Manager/PM/QAによる定期的な利用状況の確認
• 自動化
• 定期的な解析の実行（Jenkins等）
• メール通知による注意喚起

14. どんな指摘があるのかサンプリングし
たい
レポート > 新規レポートの作成（X軸分類基準：フィルター：重要度）

15. ベースラインの設定
最初の解析結果（出荷済みバージョン）は全てFilter扱い
1. 指摘一覧 > 「すべて」 を選択し 「Filter」
を付与
2. 開発中のバージョンに混入した
指摘のみ選別・修正対象とする

16. メール通知例

17. ROIの計算式
考え方は様々、シンプルな方が使いやすい
指摘一件あたり削減時間(コスト) ＝テスト工程やフィールドで発見されたプ
ログラミングエラーの発見から修正にかかる時間（コスト） ー 静的解析
ツールで発見された指摘の修正にかかる時間（コスト）
総削減時間（コスト） ＝ 指摘一件あたり削減時間(コスト) × 修正件数
例： 静的解析を使用しない場合、20万円 静的解析を使用する場合、3万
円、1年間の修正件数 1００件とする
総削減コスト：(20万-3万) * 100件 = 1700万円
複雑な計算モデルのほうが支持、承認さ
れやすい組織であれば、その限りではな
い

18. ROIの計算式
数値例：Klocworkホワイトペーパーより抜粋

19. ROIの計算式
考慮事項
• 全ての修正件数をカウント対象とするか、特定の指摘のみ（例えば、メ
モリ破壊やリソースリーク等重要度の高いものに絞るか）
• 時間やコストの見積もり根拠
• 自社データ
• 他社データ
• 何の作業をコストに含めるか

20. ROIの計算式
バグ発見フェーズによる重み付け Klocworkホワイトペーパーより抜粋

21. まとめ
ROI算出のために必要なこと
• ツールを使って指摘を確認、修正していることが大前提
• ツールを活用できていないなら、最低限活用できる仕組みづくりが先決
• ROI計算は修正件数＊削減コスト が基本的な式
• 完璧ではなくても、ツールの出力データをベースに計算可能な手法にする
（ほうが楽）
• その他利用方法について支援が必要な場合は販売代理店または
まで

22. 参考資料
• Klocworkホワイトペーパー：http://cdn-
devnet.klocwork.com/documents/partners/resources/Japanese_Resources/
JP_White_Papers/klocwork-paper-business-case-for-sca-jp.pdf
• http://www.klocwork.jp/resources/case-study
• Klocwork 展開ガイド
https://developer.klocwork.com/documentation/klocwork/jp/current/deploym
ent-guide

23. http://www.klocwork.com