DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

今年の夏の甲子園大会は、例年以上の盛り上がりを見せています。地方大会も含め、明らかに実力が高いと思われたチームがあっさり敗れるなど波乱の展開が多く、これだからスポーツは楽しいと客観的に思える人もいれば、これだけ頑張ってきたのにあんな負け方で終わるとはと引きずっている人も中にはいることと思います。

スポーツの世界では「勝負は時の運」という言葉がありますが、、、
システム開発プロジェクトでは「品質は時の運」という言葉が当てはまるでしょうか？

【　品質を「本番障害発生率」と定義してみる　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さて、当ブログの　【第５６回】品質とは何か？　では、「システム開発プロジェクトにおける品質の定義とは、品質マネジメント計画書に具体的に定義し、合意したものである！」と宣言しておきながら、これまで具体的にどう定義するかを保留のままとしてきました。

実は、私自身、その定義について、これといった確信的なものを持っていないのが正直なところです。これまで携わったプロジェクトにおける品質管理活動を振り返ってみると、設計書のレビューや構築したシステムのテストを、どんな観点や役割分担で、どれだけのボリューム実施して、その結果、どれだけのレビュー指摘やバグを摘出するか目標設定した上で、目標と実績を比較することによって、品質を評価する活動が多かったと思います。

たとえば、基本設計では1ページ当たりのレビュー指摘数は1件という「品質目標」を設定して「品質目標」の達成度合いを評価したり、テスト工程では実装されたプログラム１KSあたりの摘出バグ数が単体テストでは10件、結合テストでは2件、システムテストでは0.5件という「品質目標」を設定して「品質目標」の達成度合いを評価していたという具合です。（※１）

このような活動内容と先ほどの定義を合わせてみると、「品質とは、レビュー指摘密度やバグ密度である」と定義して、これまで品質管理活動を行ってきたということをあらためて認識しました。1年や2年という長丁場の大規模システム開発においては、開発途中段階で定量的な品質評価を行い、その結果を品質改善活動に結び付けるということは当然のことであり、それはそれで大切なことは言うまでもありません。

しかし、開発途中段階の「レビュー指摘密度やバグ密度」をまとめた結果が、そのプロジェクトで開発したシステムの品質であると説明するのは、システムを作る側の論理でしかなく、システムの利用者にはあまり受け入れられないように感じます。初心に戻って、あらためて考えてみると、出来上がったシステムの最終的な品質はどうだったかという評価が必要であり、開発途中の評価よりも重要であるように思えます。開発途中段階の数字を並べられるよりも、出来上がったシステムの品質はこうだという評価の方が、エンドユーザーも含めたすべてのステークフォルダーにとって共有しやすいものでは無いだろうか？と思ったりしています。

そこで、今回は、出来上がったシステムの最終的な品質を、単純に「本番障害発生率」という尺度で評価してみてはどうかということを考察したいと思います。「本番障害発生率」は、本番稼働後一定期間（たとえば３ヶ月とか）に発生した障害件数をプロジェクトの規模（ステップ数、ファンクションポイント数など）で割ることにより算出します。開発規模の代わりにプロジェクトの実績コストを使っても面白いかもしれません。

「本番障害発生率」が低ければ品質の良いシステムということになります。品質マネジメント計画書に掲げる品質目標としては、たとえば「稼動後3ヶ月間の本番障害発生率が０．０１件／Ks未満」などと設定します。これであれば、誰の目から見ても、品質の良し悪しが共有しやすくなるのではないでしょうか？

【　品質は「本番障害発生率」という定義を検証する　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
では、品質は「本番障害発生率」であるとした定義の実効性を検証するために、それが受け入れられない理由を思いつくままにあげてみて、それぞれ考察してみたいと思います。

１．品質の多面性をカバーしていないのでは？

当ブログの　【第５５回】プロジェクト八景～品質評価の多面性　、　【第５６回】品質とは何か？　では、再三、品質には多面性があると強調してきました。この多面性を「本番障害発生率」だけではカバーしていないのではないか？「本番障害発生率」だけではなく、他の尺度も必要ではないかという意見です。

確かに、「本番障害」だけに着目するということは、システムの利用者視点による評価が中心となり、かつ、いわゆるＪＩＳの品質特性で言うところの「信頼性」の評価でしかないのでは、とも考えられるかもしれません。しかし、本番障害となるのは、利用者や運用者がシステムが「期待通りの動き方」をしないと判断した場合や、「期待した効果」が得られないと判断した場合だと考えられます。この「期待通りの動き方」の中には、「合目的性」も含まれれば、「操作性」も含まれるし、「期待した効果」の中には、「保守性」や「拡張性」なども含まれていると考えることができると思います。すなわち、「本番障害発生率」という定義の中には、品質の多面性もある程度カバーされていると考えることもできるはずです。また、システムは利用者のために開発しているはずなので、利用者にとっての品質を最も重視するという考え方は、受け入れやすいと思います。（※２）

２．「本番障害発生率」はシステムの利用頻度に左右されるのでは？

たとえば、同じぐらいの開発規模で、本番稼働時の残存バグが同じぐらいの件数である二つのシステムを比較した場合、品質は同程度と評価されるのが妥当です。しかし、一方のシステムは毎日稼働するオンライン中心のシステムであり、もう一方は月に一回しか稼働しないバッチ中心のシステムだったとすると、利用頻度の高いオンラインシステムの方がさまざまな条件下で稼働することにより、残存バグが顕在化する可能性が高くなる、すなわち「本番障害発生率」が高くなるということが考えられます。

そのような場合には、本来同程度と評価されるべきなのに、より利用頻度の高いシステムの方が「本番障害発生率」が高くなることから、品質が悪いという評価になってしまうので、品質の良し悪しが平等に評価できないという意見です。

しかし、そもそも同じくらいの規模であっても、要求仕様の難易度の違いにより、同じスキルレベルのチームで構築したシステム間で、品質に差異が出る（当然難易度が高いシステムの方が品質が低くなる）こともあるため、それと同じようにシステムの利用頻度によって、同じ残存バグ率であっても品質に差異が出る（利用頻度の高いシステムの方が品質が低くなる）というのも仕方ないと割り切っても良いのではないでしょうか？

３．「本番障害発生率」はゼロであるべきという暗黙の前提がある

たとえば「本番障害発生率」をゼロより大きい目標値として設定して本番稼働に進むということは、本番障害が発生する可能性があるのにリリースを認めるということになり、かといって、「本番障害発生率」の目標値を毎回ゼロに設定していたのでは、品質目標をいつも達成できないことになってしまうため、発注側、受注側どちらも品質目標として「本番障害発生率」を適用することは許容できない、という意見です。

それに、システム開発を受注する側にとっては、システムをリリースした後は、引き続き保守を行うかもしれませんが、基本的にお役御免ということになり、発注側から十分な情報を得られずに「本番障害発生率」をきちんと把握できないという事情があるかもしれません。

しかし、長い目で見てシステム開発の品質を向上させていくためには、最終的に出来上がったシステムが、どれだけ障害が残存していたのかをしっかりデータとして蓄積し、バグが残存した原因を分析して再発防止を徹底していく必要があるのではないでしょうか？そのためには、発注側、受注側が協力しあって、「本番障害発生率」を注視していく必要があるのではないでしょうか？

【　品質は時の運？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
高校野球のチーム力は、たとえば、練習試合の通算打率や防御率などの数字で評価することができると思います。しかし、夏の甲子園大会やその予選などの公式戦の試合の勝ち負けは、練習試合の通算打率や防御率が良いチームが必ずしも下馬評通りの結果を残すとは限りません。

また、プロ野球でも、フリーエージェントなどにより、各チームの主力打者やエース級のピッチャーを集めて「一人オールスター」と言ってもよいようなチームが、必ずしも毎回優勝するとは限らないのは周知の事実です。

システム開発の品質に関しても、実は、万全に万全を重ねてレビューやテストを実施したり、開発途中の品質評価をしっかり実施して、品質改善を重ねていたとしても、本番障害が発生してしまう可能性があります。逆に、レビューやテストに手抜きをしていても、なかなか本番障害が顕在化しないケースもあったりするのです。（そこが品質の難しいところ！）

だからと言って、最終結果である大会での勝敗や「本番障害発生率」を「勝負は時の運」として流してしまっていては、大会での勝率アップや「本番障害発生率」の向上につなげることができないはずです。

もちろん途中段階での評価を行い、その結果を受けての改善を行わなければ、最後の大会までにチーム力をアップすることも、本番稼働までに所定の品質を確保することもできないことは間違いありません。しかし、途中段階での評価と改善の結果が、最終結果にどれだけ寄与したのかを評価しなければ、せっかくの努力が無駄とは言わないまでも、非効率になってしまっている可能性に気付けないと思います。

今回、システム開発における品質を「本番障害発生率」と定義して、いろいろと考察してみましたが、一考の価値があるのではないかと思います。。。

「開発途中段階の品質だけでなく、本番稼働後の最終的な品質もしっかり評価しよう！」

ん。あなたの組織では、もうとっくに取り組んでいて、成果も出しているんですって？

それはたいへん失礼いたしました！

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　当ブログを通して登場する具体的な数字（たとえば、「１ページ当たりのレビュー指摘数は１件」など）については、あくまでも現実のプロジェクトのものではありませんので、そのまま実際のプロジェクトには適用できませんので、ご注意願います。

※２　いわゆる「JISの品質特性」については、以下参照。
・「ISO 9126」『フリー百科事典　ウィキペディア日本語版』
2014年7月16日 (水) 13:57 utc https://ja.wikipedia.org/wiki/ISO_9126