静的解析のroi
TRANSCRIPT
静的解析ツールの ROI
Masaru Horioka Senior Sales Engineer –
APACRogue Wave Software
Japan
静的解析の効果って？• バグ（プログラミングエラー）の発見（予防）
– テストやレビューでは見逃されたプログラミングエラーの発見– コーディング、 CI 段階でバグを発見することにより、後工程への混入を予防
• 工数削減– 人手による（プログラミングエラーを見つけるための）コードレビュー、デバッグ時間の削
減
• 将来的なリスク低減– コーディングルール、メトリクスにより、プログラミングエラーが混入するリスク・技術的負
債を下げる
• 教育– 全てのプログラマがセキュアコーディングの本を読むわけではない– 静的解析に指摘されたことを確認しながら学ぶ
• スタンプ– 納品先に「静的解析かけてます」って言える
静的解析の効果って？• バグ（プログラミングエラー）の発見（予防）
– テストやレビューでは見逃されたプログラミングエラーの発見– コーディング、 CI 段階でバグを発見することにより、後工程への混入を予防
• 工数削減– 人手による（プログラミングエラーを見つけるための）コードレビュー、デバッグ時間の削
減
• 将来的なリスク低減– コーディングルール、メトリクスにより、プログラミングエラーが混入するリスク・技術的負
債を下げる
• 教育– 全てのプログラマがセキュアコーディングの本を読むわけではない– 静的解析に指摘されたことを確認しながら学ぶ
• スタンプ– 納品先に「静的解析かけてます」って言える
直接的で計算しやすい
ROI 算出における課題
1. そもそもツールを活用できていない
2. ROI の計算の仕組みがない
3. ROI の計算方法がわからない
ツールを問わず、実はこれが多い！
大事なこと その１
• 指摘内容を定期的に確認し、選別していますか？• 指摘内容が妥当な場合、コードを修正しています
か？→ 修正しない限り効果はない
• 定期的に解析を実行していますか？→ 一度限りの解析だと修正されたか、副作用がないかが確認できない
大事なこと その２
• 選別、または修正件数はカウント可能ですか？
• ROI を計算できればよいので、必ずしも完璧なカウント方法である必要はない
• （半）自動で計算できるかどうかが鍵
• カウント方法の例– Klocwork のレポート、 API を用いてカウント– バグトラッキングシステム、コミットログ等からカウント
Klocwork のレポート
1. プロジェクト一覧
2. ステート別の全ての指摘
3. モジュール別の修正活動
注意事項： Klocwork システム上は、過去の解析で存在した指摘が次の解析で存在しない場合、修正されたとみなされるため、コードの大幅な変更や削除により修正済みとカウントされてしまうことがある。選別データと合わせて判断する
みなさんのプロジェクトはどうでしょうか？
修正済み (Fixed) の件数が表示されていますか？
みなさんのプロジェクトはどうでしょうか？
レポート > ステート別の全ての指摘
Fixed の指摘がありますか？
みなさんのプロジェクトはどうでしょうか？
レポート > ステート別の全ての指摘 （ステータスを追加したカスタムレポートを作成）
選別ステータスが「 Fix 」かつ Fixed のみを表示
みなさんのプロジェクトはどうでしょうか？
レポート＞モジュール別の修正活動
「デスクトップ指摘」を選択すると、コネクテッドデスクトップ解析使用中に発見され修正された指摘件数がカウントされる＝チェックアウトからチェックイン前までに発見され修正した問題をカウント
そもそもうまく活用できていない場合
プロセス化、自動化
• プロセス化
• 現実的な（アクション可能な）修正目標
• 確認すべき指摘の絞り込み例
• デフォルト or Sev 1, 2 のみ or さらに絞り込み（サンプリングして決める）
• 過去のバージョンの指摘は一旦 Filter （新規不具合のみ着目）
• サードパーティコードは除外 (ignore ステータスか、ビュー、モジュール機能を活用 )
• Manager/PM/QA による定期的な利用状況の確認
• 自動化
• 定期的な解析の実行（ Jenkins 等）
• メール通知による注意喚起
どんな指摘があるのかサンプリングしたい
レポート > 新規レポートの作成（X軸分類基準：フィルター：重要度）
ベースラインの設定
最初の解析結果（出荷済みバージョン）は全て Filter 扱い
1. 指摘一覧 > 「すべて」 を選択し 「 Filter 」 を付与
2. 開発中のバージョンに混入した指摘のみ選別・修正対象とする
メール通知例
ROI の計算式
考え方は様々、シンプルな方が使いやすい
指摘一件あたり削減時間 ( コスト ) ＝テスト工程やフィールドで発見されたプログラミングエラーの発見から修正にかかる時間（コスト） ー 静的解析ツールで発見された指摘の修正にかかる時間（コスト）
総削減時間（コスト） ＝ 指摘一件あたり削減時間 ( コスト ) × 修正件数
例： 静的解析を使用しない場合、 20万円 静的解析を使用する場合、 3万円、 1年間の修正件数 1００件とする
総削減コスト： (20万 -3万 ) * 100 件 = 1700万円
複雑な計算モデルのほうが支持、承認されやすい組織であれば、その限りではない
ROI の計算式
数値例： Klocwork ホワイトペーパーより抜粋
ROI の計算式
考慮事項
• 全ての修正件数をカウント対象とするか、特定の指摘のみ（例えば、メモリ破壊やリソースリーク等重要度の高いものに絞るか）
• 時間やコストの見積もり根拠
• 自社データ
• 他社データ
• 何の作業をコストに含めるか
ROI の計算式
バグ発見フェーズによる重み付け Klocworkホワイトペーパーより抜粋
まとめ
ROI 算出のために必要なこと
• ツールを使って指摘を確認、修正していることが大前提
• ツールを活用できていないなら、最低限活用できる仕組みづくりが先決
• ROI 計算は修正件数＊削減コスト が基本的な式
• 完璧ではなくても、ツールの出力データをベースに計算可能な手法にする（ほうが楽）
• その他利用方法について支援が必要な場合は販売代理店または まで
参考資料
• 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/deployment-
guide
http://www.klocwork.com