炎上なんて嫌だ！みんなが幸せになれる品質が高いシステムの作り方 〜見えない品質を可視化して改善する方法〜 ２章 数字にできるのはこれ！ 定量化できる品質指標
２章 数字にできるのはこれ！ 定量化できる品質指標
品質の何を定量化するの？何ができるの？
筆者はこの2年半中堅クラスの開発会社で、品質監査の仕事をしていました。1千万円〜億越え規模の開発を常時10プロジェクト前後ほど、全体的に見ていました。
試行錯誤の結果、次の項目に対して定量評価（数値化）することができました。
・1. 開発規模（FP法）
・2. マネジメントプロセス
・3. ソースコード（静的解析）
・4. ユニットテスト
・5. テストケース数
・6. バグ数
・7. 開発進捗
・8. サービスマネジメント（保守・運用）
それぞれの項目で「何故その項目なのか」「具体的に何を定量化するのか」「どうやって数値化するのか」「何を目指せばいいのか」という観点で説明をします。
1. 開発規模（FP法）
何故開発規模を定量化するのか
めちゃくちゃなことをいいますが、システム開発の見積りはできません（笑）
理由は「要求・要件が変わるから」です。時間が経つにつれ要求・要件は変わります。この変化に対応するために「見積り」したり「要件を定義」してしまうと変化に対応できません。
ただ、開発単位を明確にすることは重要です。言い換えるとモノサシを持つことが重要です。
ここでのFP法による開発規模の算出は「1FPあたり」というモノサシを持つことです。プロダクト、プロジェクト、システム、機能を相対比較するために単位を揃える目的があります。
もちろん、開発規模から工数・原価・出値の見積りをすることも可能です。
ただし、前出した通り「固定化」には気をつけてください。
どうやって規模を定量化するのか
FP法（ファンクションポイント法）を使います。
FPポイント法の中でもIFPUG法・NESMA概算法をベースにもう少し簡略化した見積りの仕方を解説します。
何故なら、「正確な見積り」よりも「モノサシであること」を優先し、スピード感を持って定量化したいからです。
「モノサシ」はその組織・会社内で通用すれば良いと割り切っています。
ゆえに、正規のIFPUG法・NESMA概算法・IPAから出されているFPなどと比較すると値が異なります。
詳細は３章に記載しますが、画面・機能単位でFPを算出します。
画面・機能を分類し、その分類ごとにFPを定義します。
余談ですが、FPを見積り金額算出にも利用しましたが、誤差は±10%内でした。
算出した規模（FP）をどう利用するか
プロジェクト間・プロダクト間・システム間・機能間で相対比較に使います。
一例ですが、テストケース数やバグ数をFPで割り、1FPあたりのテストケース数やバグ数を出します。
これらをテスト計画する際のテストケース数やバグ数の予測に利用します。
FPに係数を掛けて工数・原価・見積り金額を出すことも可能です。
規模を算出することでどのような効果があるか
大事なことなので繰り返しますが、プロジェクト間・プロダクト間・システム間・機能間で相対比較ができるようになります。
例えば1FPあたりのテストケース数とバグ数が少ないプロジェクトがあれば、バグが少ないのはテスト密度が薄く（テスト量が少ない）、テストの網羅性に課題があると推測できます。
このように相対比較することで、何が足りないかがわかります。足りない部分は課題やリスクとなります。このように可視化して分析することができます。
2. マネジメントプロセス
何故マネジメントプロセスを定量評価するのか
複数プロジェクトを見ていると、うまくいっているプロジェクトと炎上しているプロジェクトがあります。「うまくいっているプロジェクト」のノウハウを「炎上しているプロジェクト」に適用すれば、うまくいく確率を増やせるのではないでしょうか？
実際、関わるメンバーが異なるとやり方は複数あり、何を選択していいか悩みます。過去の成功体験を真似ることでプロジェクトの課題を解決できると考えられます。
「うまくいっていないプロジェクト」は個人の主観に基づいて意思決定し、その決定事項がミスリードになっています。
どうやってマネジメントプロセスを定量評価するのか
大事なことは2つ
1. チェックシートの項目は「イエス」「ノー」で判断できるようにする
2. ヒアリングではなく、ドキュメントやエビデンスで評価する
これらを防ぐために「見積り」「契約」「プロジェクト計画策定」「要件定義」「設計」「開発」「テスト」「出荷判定」の各フェーズでチェックシートを用いてチェックします。
このとき注意するのは1つの項目で「イエス」「ノー」で答えられるようにすることです。
以前、5点満点方式を採用していたのですが、機嫌が悪いと点数が低くなる傾向など、個人の主観が入りやすくなります。これでは適切に評価をすることができません。
「イエス」「ノー」にするとこのような主観による評価のブレを防ぐことができます。
もう一つはチェックする際にヒアリングではなく、ドキュメントやエビデンスを基にすることです。
ヒアリングにすると、「大丈夫です」という答えしか返ってきません。これでは状況を正しく把握できません。
ドキュメントやエビデンスは人と比較して嘘をつきませんし、少なくても感情はありません。
ゆえにヒアリングよりは正確に評価することができます。
これらのチェックシートの「イエス」の数を項目数を割った「達成率」をマネジメントプロセスの指標とします。
マネジメントプロセスのチェックシート
（後日例）
上記例は、PMBOKの9つのマネジメント領域をベースに工程ごとにチェック項目を分けています。
この項目が正解ではありません。ビジネスモデルや発注側なのか、受注側なのかによっても項目が変わるはずです。
別紙ファイルを参考にしてチェックシートを作成してください。
実際のチェックの仕方は３章で説明します。
マネジメントプロセスチェックのゴール
状況にもよりますが、マネジメントプロセスに関しては９０％以上「イエス」が出る状況が望ましいです。
あまりハードルを上げても対応できない項目が増えては意味がありません。
当たり前にできることをやるだけでプロジェクト成功率は上がります。あまり無理難題なマネジメントプロセスチェック項目を入れないようにしましょう。
どの人でも９０％クリアできる程度が目安です。
3. ソースコード（静的解析）
何故ソースコードを定量化するのか
私個人の主観ですが、ソースコードの品質が担保されればシステム・プロダクトの品質はかなり向上します。
以前、3,000万円（見積り時は5,000万円 笑）規模のシステム開発をリリース後バグゼロで実現したことがあります。
その時、リリース直前に仕様追加・改修もありましたがデグレートもありませんでした。
プロダクトオーナーのマーケティング部の要求にも迅速に対応できました。
ソースコードの保守性が高いので誰でも仕様追加・改修が容易だったからです。
その後、複数プロジェクトの品質保証に携わり、静的解析ツールを導入して結果を開発チームに展開して是正したところ、やはり保守性が高い、追加・改修がしやすいシステム・プロダクトになりました。
静的解析ツールの結果と保守性の高さに相関があることがわかりました。
ソースコードの保守性向上のメリット
静的解析の結果を開発側にフィードバックすると、反発を買うことがあります。
明確なバグではないので静的解析結果の対応が面倒だからです。面倒だけでなく、リファクタリングをすることでソースコードに触るのでデグレートの可能性があるからです。
不用意にソースコードに手を入れてバグを起こせば目も当てられません。
また、ビジネスサイドもバグがあるわけでもないのに無駄な工数（費用）を使いたくないので反発する可能性もあります。
では、そこまでしてソースコードの保守性を向上させる理由はなんでしょうか？
大きく分けて2つ理由があります。
1. 中長期で顧客価値があるから
2. 中長期でプログラマの心理的負担を減らせるから
ソースコードの保守性向上のメリット 1. 中長期で顧客価値があるから
ソースコードの保守性が低くなると可読性が減り、ソースコードが読みにくくなります。
それが積み重なると、長くそのシステムに関わっているプログラマでも追加・改修時にどこをどうすれば良いか判断がつきにくくなります。
退職・離脱などで人が変わればより、追加・改修時にどこをどうすれば良いか判断がつきにくくなります。
このようになると、開発チームとしては工数を増やして対応するしかありません。結果的にそのお金を払うのは顧客です。
また、工数もかかるのでリリースまで時間がかかるようになり、ビジネススピードが低下します。
顧客の視点では「何故、同じような追加開発・改修なのに費用が増えるのか？開発が遅くなるのか？」と不満が募ります。
結果的に顧客満足度が低下します。
リファクタリングを繰り返し、ソースコードの保守性を維持すれば誰でも追加・改修が容易にできて、スピード感を持った対応が可能です。
開発コスト増加が抑制され、スピード感を持って対応できれば持続的に顧客に価値を提供できます。
ソースコードの保守性向上のメリット 2. 中長期でプログラマの心理的負担を減らせるから
保守性が向上するとプログラマの心理的負担が減ります。
保守性が低い、ソースコードの可読性が低い（俗にう○コードと呼んでます 笑）ソースコードだと、何をどうしたらいいかわかるまで時間がかかり、ある程度理解しても手探り状態なのでストレスが溜まります。
自信を持ってコミットができません。
「1. 中長期で顧客価値があるから」でも書きましたが、保守性が維持されるとプログラムの可読性が向上します。
プログラマは自信を持ってソースコードをコミットすることができます。
どうやってソースコードを定量化するのか
各プログラミング言語に静的解析ツールがあるので利用します。
詳細は３章に記載しますが、PHPでは、PHP MDを使うと端的にプログラムが複雑かどうか、スパゲッティーになっていないかを数値化してくれるサイクロマティック複雑度を計測できるので強力です。
例：PHP
・PHP MD
・PHP Code Sniffer
・PHP Stan
例：JAVA
・FindBugs
・CheckStyle
これらはコマンドラインから呼び出したコマンドで処理ができるので、MRをトリガーにJenkinsなどのCI/CDツールを用いてデータを採取しアーカイブすることが可能です。
定量化したソースコードの何を見るのか
各静的解析ツールでは違反件数を取得することが可能です。違反の詳細を見て似たような違反に整理・分類し、優先度をつけて対応します。
違反件数が少なくなればなるほど保守性が高いといえます。
ソースコードを定量化して何を目指すのか
なかなか難しいですが、違反件数がゼロになれば保守性が高いといえます。
「1. 開発規模（FP）」で説明したFPで割って1FPあたりの違反件数を算出して相対的に違反件数をみて、他のシステムやプロダクトと比較して、対応有無や優先順位を決めて改修します。
4. ユニットテスト
ユニットテストとは？
適切にユニットテストを書くことで「プログラマの心理的負荷軽減」「中長期のテストコスト削減」することができます。
プログラムを追加・改修する時に、プログラマはデグレーションが起きないか不安になります。
リリース後にデグレーションが発覚すると心理的なダメージが大きいです。
ユニットテストを導入していれば、コミット時やマージリクエスト時にデグレーションしていればエラーで教えてくれます。
また、万が一テストが足りない場合、次からエラーが発生した箇所のユニットテストを書けば良いだけとなり、個人の責任ではなくなります。
結果的にプログラマは萎縮せずにコミットやマージリクエストをすることができます。
プログラマが萎縮しない環境を構築することが重要です。
ユニットテストを書く目的・メリット
・中長期視点でコストが下がる
・人為的ミスを減らす
・人の責任ではなく仕組み（ユニットテストがない）の責任にできる
・ユニットテストを書いているプロジェクト・プロダクトは品質がよくストレスが少ない
・プログラムが疎結合となり、可読性向上、ソースレベル品質が上がる
・プログラマが自信を持ってコミット・マージリクエストができる
・単体テストを手動でやる必要がなくなるので負荷が下がる
・回帰テストも手動でやる必要がなくなるので追加・改修時のテスト工数が減る
何故ユニットテストを定量評価するのか
テストにおいて重要なのは網羅性です。手間を考えなければホワイトボックステストで、全てのプログラム・全てのパターンをテストするべきですが、人とコストがいくらあっても足りません。
そこでユニットテストを書きます。一度書けば何度も繰り返してテストをしてくれます。
定量化できるのはガバレッジ
どのくらいテストできているかを調べるためにはプログラムそのものを追う必要があります。これも生産的ではありません。
ユニットテストのフレームワークにはカバレッジを測定する機能（コマンド）があるので活用します。
網羅率をパーセンテージで算出してくれます。
100%を目指せば良いのでしょうか？
カバレッジ至上主義は危険
結論ですが、100%は目指さないでください。ユニットテストがうまくいかなかった事例を検証した結果、カバレッジを追うとマネジメントが効かなくなります。
理由は、プログラマがカバレッジを追うあまり、ユニットテストばかりを書くようになるからです。
数値目標としてカバレッジを設定するのはやめましょう。
ユニットテスト目指す方向性
経験論ですが、85%程度であれば、そこまで苦労せずとも実現できます。80%を切ってもないよりはある方がよいのでそこまで問題ではありません。
90%を超えると、数字をあげるのが難しくなりますし、ユニットテスト書きすぎも実行時間がかかりすぎたり、メンテナンスコストも増えるので費用対効果がありません。
「ちょうど良いくらい」書くのが適切です。
重複しますが、下記にやり方と注意点をまとめます。
ユニットテストのやり方・注意点
ユニットテストに馴染みがない方にユニットテスト導入すると拒否反応を示します。主な理由は下記の通りです。
・ただでさえプログラムを書くのが大変なのに、追加してプログラムを書きたくないから
・書く意味がわからない
・書き方がわからない
・以前、ユニットテストでメンテナンスが大変だったなど痛い目にあっている
上記は全てマネジメントが失敗していることが原因です。適切なマネジメントをすればユニットテストの恩恵を受けられます。
特に「書きすぎ」には注意しましょう。書きすぎていたらコメントアウトするなど抑制します。
書けば書くことメンテナンスコストが上がると考えてください。
下記にやり方・注意点を記します。
・カバレッジはあくまで目安であり、固執しない。85%超えていれば問題なく、85%は無理なく実現可能。間違っても100%を目指さない。
・1メソッド：1機能を徹底する（ユニットテストが書けない）
・if elseを必ず1回通すだけとする（C1 分岐網羅）
・通常のプログラムとユニットテストの時間比率は8:2を目安とする
・各言語にxUnitがあるので活用する
・ユニットテストごとにsetUpでデータを作成し、tearDownでテストデータを削除する（setUp, tearDownはphpUnitでのメソッド名）
・アサーションはtrue/falseが理想
・1回ユニットテスト実行あたり、10秒ほどを目安とする
5. テストケース数
何故テストケース数を定量評価するのか
テストケース数を定量評価する目的は、網羅性が担保されているかどうかを測るためです。
極論ですが、テストをしなければバグは出ません。
テストしないは暴論ですが、テストが少ないからバグが少ないは往々にしてあります。
テストケース数を他のプロダクト・プロジェクトと相対比較することで網羅性があるかどうかを比較することが可能です。
プロダクトやプロジェクトによって規模が異なるので単純な数では相対比較ができません。
そこで、規模（FP）で割り、1FPあたりのテストケース数を用いて相対比較します。
どうやって網羅性を測るのか？テスト仕様書の書き方
テストの網羅性を相対比較するためにはテスト仕様書の粒度を揃えます。1期待値：1テストケースにします。
具体的なやり方は次章に記載します。
テストケース数は多すぎても少なすぎても問題
テスト手法が確立してくると、テストパターンやより網羅しようとテストケース数が増える傾向にあります。
テストケース数が増えれば網羅性が担保できますが、リソース不足やコスト増加、納期遅れなどリスクも発生します。
テストケース数が多い場合のリスクと対策
テストケース数が多い場合、次のようなリスクがあります。
・コスト超過
・納期超過
・コストと納期を間に合わせようとするとメンバーが疲弊する
テストケースは不安になると増える傾向にあります。境界値分析や同値分割を利用して適切なテストケース数を目指してください。
ユニットテストなどテスト自動化した部分をテスト仕様書に記載し、「手動テストをしない」という選択肢もあります。
手を動かさないと不安になりますが、人間はミスをするので人任せにする方が不安です。
テストケース数が少ない場合のリスクと対策
テストケース数が少ない場合の、次のようなリスクがあります。
・リリース後にバグが出る（テスト網羅性が低い）
テストケース数が少ない場合、テストケースの粒度が荒い場合がほとんどです。「1期待値：1テストケース」を前提にして、テスト設計の見直し、境界値分析などをやり直してください。これだけで適正値になります。
6. バグ数
何故バグ数を定量評価するのか
バグが多すぎると品質が悪いのは明白ですが、バグが少ないのは本当に良い状態なのでしょうか？
前出した通り、極端な話テストをしなければバグは出ません。テストの網羅性が少なければバグはあまりでません。
リリース後にバグが出ると顧客や利用者が不利益を被ります。
ある程度バグの数が出るのが正しい状態です。
どうやってバグが多いか少ないかを判断するのか
テストケース数と同じように他のプロダクトやプロジェクトと単純なバグ数で比較することはできません。
規模（FP）でバグ数を割り、1FPあたりのバグ数で相対比較をします。
バグ数が多い場合
一番多い状態です。様々な原因が考えられます。原因調査をして解決に努めましょう。ケースバイケースですので詳細は割愛します。
バグ数が少ない場合のリスクと対策
バグ数が少ない場合もリスクが潜みます。極端な話、テストをしなければバグは出ません。
・テスト網羅性が少ない（テストが少ない）
・リリース後にバグが出る
対策は「テストケース数が少ない」時と同じです。
ただし、調査した結果、ユニットテストが書いている。テストも予測より多いなど別の指標を満たしていれば、品質が高くていいプロダクトということができます。
具体的なやり方は次章に記載します。
7. プロジェクト進捗
何故プロジェクト進捗を定量評価するのか
プロジェクトの進捗はなかなか目に見えません。PMもしくはPLからの定性的な報告が多いのではないでしょうか？
それだと本当にどのくらい開発が遅延しているかがわかりません。
進捗率だけでなく終了予定日がわかるのが理想です。
タスクが数値化できれば、バーンダウンチャートを用いて終了予定日を算出することが可能です。
プロジェクト管理をする際にWBSを用いることが多いのですが、まともに管理されたWBSを見たことがある方はいらっしゃいますか？
私は20年近くWBSを見ていますが、真っ当に管理されたWBSを見たがことがありません。
各タスクが80%で止まって、そこから進捗がないものばかりです。
週次の定例などで
「何故進捗が80%ですか？」
「○×△…言い訳」
を繰り返します。これでは意味がありませんし、問題・課題の是正ができません。
詳細なやり方は次章で説明します。
8. サービスマネジメント（保守・運用）
何故サービスマネジメントを定量評価するのか？
プロダクトが顧客に公開されると、使い方の問合せ、バグの報告、データ追加などの依頼がくるようになります。
これらと監視機能から連携されるアラートなどを含めて「インシデント」と呼びます。
顧客対応がまずいと顧客の不満が溜まり、クレームに繋がります。クレームをくれるならまだマシです。ある日突然保守契約打ち切りということもあります。
初期リリース時は良好な関係でも、時間が経過するとプロダクト・システムは経年劣化することもあり、今までと同じような対応でも、コストがかかったり、時間がかかったり、リリース後にバグが発見されたり、だんだん「ガタ」がきます。
ただでさえ顧客の不満はだんだん増えてきます。
さらに、会議などで口頭伝達、電話、メールだとこれらのインシデントを忘れたり、誤認したりすることが多々あります。
こうなるとクレームの嵐になったり、業務時間外に電話が来たりいい事がありません。
そのために、インシデントも開発時と同じようにチケットで管理します。
このチケットの状況を随時モニタリングする事で、顧客との間のタスクがどのくらいあるかを把握し、リソースが不足していないか、顧客が不満を持っていないか、何かリスクが潜んでいないかなどがわかるようになります。
サービスマネジメントではどのような数字を見るのか？
結論からいうと「チケット数」をみます。
1インシデント：1チケットになっていれば、整理・分類する事で事象を定量的に把握することができます。
チケットを起票する際に、下記のことを守りましょう。
・1インシデント：1チケット
・期日を設定する
・担当者を設定する
・優先度を設定する
・一次回答日を設定する
下記のようなカテゴリごとに毎日数字をプロットします。増加傾向や減少傾向を把握することで、どのような課題があるかを探します。
・現状動いているチケット数
→ タスク量がわかります。増加傾向にあれば対応メンバーを増やすなどの対策を講じます。減少傾向にあればリソースに余裕があるので積極的に顧客と認識合わせをしましょう。
・期日がない
→ 優先順位がわからないので必ず入れる
・期日超過
→ 設定期日が過ぎているので早急に顧客と相談し、伸ばすのか、すぐに終わらすのかを検討する。期日超過が増えていると担当者の負荷が上がっていると考えられる。
・期日○営業日前
→ 優先順位を上げて対応する
・更新日が○営業日前以前
→ チケットが放置されている可能性があるので、棚卸しをする。
下記の数字もとります。
・平均1次回答リードタイム（単位：日）
→ このリードタイムが長いと顧客がチケットを起票してもムダだと感じ、顧客満足度が下がる。
・平均チケットクローズリードタイム（単位：日）
→ このリードタイムが遅いと、顧客を待たせることになる。増加傾向であれば、経年劣化していると考えられ、リファクタリングなどの対策を検討します。
サービスマネジメントのゴールは？
新規開発と異なり、サービスマネジメントはチケットがなくなることはほとんどありません。
10チケットくらい、開発規模によっては40チケットほど常にある状態です。
毎日チケット数をプロットすることにより、そのプロジェクト・プロダクトの平均チケット数を把握します。
その平均から増加傾向にあれば、リソースを補うなどの対策が必要です。
逆に少なければ、リソースを持て余している可能性があるので再配置などを検討します。
期日前○でフィルタすることで、優先順位も明確になります。
「期日なし」「期日超過」「更新日が○営業日前以前」はゼロが理想です。これらの数字が存在するのであれば、棚卸しをしましょう。
また、これらの数値が増加傾向であれば、クレームがなくとも潜在的に顧客は不満を持っていると考えて良いです。
平均1次回答リードタイム（単位：日）は1日以内を目指しましょう。すぐに回答できなくても「承りました。明日中に回答します」と答えるだけで、顧客の不満を抑えられます。チケットを起票したのにも関わらず回答がないと、顧客は「無視されている」と思い不満が溜まります。
平均チケットクローズリードタイム（単位：日）は短ければ短いほど良いですが、顧客確認を持ってクローズする場合は顧客都合でクローズが遅くなる場合もあります。
開発規模や状況によって理想値はケースバイケースとなります。
顧客を巻き込み、棚卸しを定期的に行いましょう。
この記事が気に入ったらサポートをしてみませんか？