システム開発のプロが実際にやってる～不具合発生を抑制する品質保証活動

当社はQMS（ISO9001）の取得認証企業です。
そのQMSの要求事項で定義されている品質とは「お客様満足度」です。
お客様は要求した内容と同等、またはそれ以上のサービスを提供した場合に満足してくれます。
つまり、お客様に満足してもらえるサービスは「品質」がいいということができますね。
では、何をしたらお客様の満足につながるのでしょうか？
満足の要素はたくさんありますが、一般的にはリソースが限られていますので「全部」というのは現実的ではありません。ではどうするのか。
それはお客様の状況・背景・目的・リソース等によって異なると思っています。

＜お客様満足の要素例＞
・システムに不具合が出ないこと（不具合の発生確率が低い）
・予算内で予定の期日通りにビジネススタートできること（コストパフォーマンス）
・透明性のあるコミュニケーション（信頼関係構築）
・迅速な対応やアフターサポート
・進め方の柔軟性（アジャイルライクなプロセス）
・強固なセキュリティ確保

などなど。
これら要素のどれに重きを置くかが重要になります。

我々は「透明性のあるコミュニケーション」を最も得意（売り）としているのですが、今回は「不具合が出ないこと」をターゲットに執筆したいと思います。
上記のような品質に関する全体的なお話は別の機会に記事にできればと思います。

「不具合が出ないこと≒正確性が高く仕様に忠実なシステム」
と置き換えてご覧いただければと思います。
不具合をゼロにすることは不可能だと考えていますので、こういった表現にしています。
なぜ不具合をゼロにすることが不可能と考えているかについても、別の機会に記事を書きたいなと考えています。

組織としての品質管理能力が向上した背景

「不具合がでない」ようにする。
これについては、メーカー系大手SIer（エスアイアー）の下請けをしていた時代にレベルアップさせていただきました。
メーカー系の大手SIerさんは社会インフラやシステム障害時の影響力が大きいシステムを取り扱っていることが多いからだと思いますが、「不具合を出さない」という品質保証に対しては、かなり厳しかったです。
不具合によって重大な事故を引き起こしたり、企業の信用問題に発展するリスクがあるので当然のことかとは思いますが、本当に厳しかったですよ（汗）
ただ、こうした多くのビッグプロジェクトに携わる中で、品質保証に対する意識と技術を徹底的に鍛えられました。

今となっては、エンドユーザーとの直接取引が大半を占めるようになってますが、この時代に経験して学んだことは今も十分に生かすことができています。

一方、「不具合が出ないようにする」以外については、エンドユーザー様と直接取引することでどんどん身についた考えや能力です。
必ずしも「完璧な品質」を追求するのではなく、限られた予算（リソース）の中で最適な品質（スピード感、実用性、効率性など）を提供するバランスや柔軟性が必要となります。

「標準的」な品質保証活動のご紹介

前置きが長くなりましたが、請負契約によるウォーターフォール開発を前提とした、我々が実践している標準的な品質管理方法を紹介します。
「標準的な」としているのは、アジャイル開発やPoC、PoVなどの場合は、この限りではありませんし、お客様のビジネス目標を踏まえて都度、品質目標・品質保証活動の内容を柔軟に検討するからです。
ビジネス目標、IT予算などにより、品質保証へのコストのかけ方や品質担保に対する重要度は変わってきます。

また、セキュリティや性能、そもそもの機能仕様などの品質特性は、要件定義でしっかりと定義されている前提で、その後の設計・開発工程で実施している品質管理を紹介したいと思います。
なお、発注者が気にするのは主に「そもそも要求通りに作られるのか」かと思いますが、「そもそも」を定義する要件定義工程については、こちらをご覧いただければと思います。

すべての成果物をレビュー

当該工程のレビューは、同プロジェクトの上流工程を担当したエンジニアによって行います。
要求や仕様、ここに至るまでの背景等を把握していますので、当然プロジェクトに関わっていないエンジニアのレビューより質は向上します。
ただ、必要に応じてアーキテクトやDBスペシャリストなどによる、業務とは関係のないシステムのあるべき論の観点でレビューをすることもあります。

レビューのプロセスは下図の通りです。

システム仕様書、ソースコード、テスト仕様書、各種計画書など、作ったものはすべて時間をかけて上記のプロセスでチェックします。
全工程の成果物（仕様書やソースコード）に対し実施することで、品質（不具合少）を各工程で少しづつ磨いていきます。
ここでのポイントは、図中の「③指摘入力」でしょうか。
上図では「Redmine」というプロジェクト管理ツールで障害情報の入力・管理を行っていますが、エクセルでもなんでも良いかと思います。
とにかく数々の指摘をため込んでいきます。修正確認漏れなど防止することもそうですが、ここでため込んだ障害データをあとで有効活用します。
ではどのように活用するのでしょうか。

品質分析

工程の途中や終盤になると上記でため込んできた障害情報を集計します。
障害情報には主に以下のような項目を設けています。

これらを集計し分析することで

【分析結果】
　・機能Aにバグが多すぎる、もしくは少なすぎる
　・機能Bの設計不具合によるバグが多すぎる
　・Yさんのバグが多すぎる

などの傾向が見えてきます。
これらの傾向に対してなぜバグが多いのか、あるいは少ないのか、などバグ混入の原因を解析します。
すると

【障害の原因】
　・機能Aの設計者が要件をご認識（勘違い）していた
　・業務ロジックの設計バグが多い
　・単純ミスが多い

など、不具合の原因が見えてきます。
この原因を解析し、必要に応じて

【対策】
　・再レビュー
　・上流工程にさかのぼって品質確認
　・担当者に業務仕様を再度レクチャ

するなどの、品質強化を行っていきます。
不具合をゼロにすることは（保障）できないと思っていますが、上記のような品質保証活動をすることで不具合の発生確率を下げることはできます。

さいごに

上記でも述べてきたように、システムの品質というのはいろんな側面を持っています。

・業務に直結する重要なシステムの場合
　　不具合が発生した際の影響を最小限に抑えるため、バグの徹底的な管理を優先する必要がある

・モバイルアプリなど迅速なリリースが求められる場合
　　仮に不具合が発生しても、すぐに修正・配信できるため、開発コストやスピードを優先する（選択も可能）

・PoC（概念実証）としての開発の場合
　　本格的な運用を前提としないため、ひとまず正常系の動作に焦点を当て、短期間での開発や実証を優先する

プロジェクトを進める上では、限られた予算の中で「何を最優先すべきか」を明確にし、発注者と開発ベンダーの認識を要件定義工程が終えるまでに揃えることが重要です

今回は超ざっくりの記事となりましたが、どれだけしっかりと品質を磨いているのか、
実際に品質保証活動をしているスタッフにも記事を書いてほしいなぁ、と思いました。
このあとスタッフに相談してみます（笑

プロジェクト管理全般のお話はこちら