システム開発にも品質の良し悪しが存在します。もしも品質が劣悪である場合、深刻な問題を引き起こしてしまうことがあります。システム開発のプロジェクトを進める時には、品質についてしっかり考えていくことも重要なポイントです。システムの品質をより良い状態にするために、品質管理という工程があります。
この記事では、品質管理とはどのようなものなのか、品質管理の工程、品質管理のポイント、アクシアにおける品質管理について解説しています。この記事がお役に立ちましたら幸いです。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
システム開発の品質管理とは？
ITにおける品質管理とは、開発工程で作られたソフトウェアが顧客の要望した仕様を満たしているなど、品質の向上をはかる仕事のことです。
前提として、バグはゼロにはなりません。リリース直後の故障頻発期間を初期故障期間と呼び、初期故障期間から偶発故障期間を経て磨耗故障期間にいたる故障率の曲線を、バスタブ曲線と呼んでいます。バスタブ曲線が示すとおり、安定期でもバグが0件にはまずなりません。
限られたコストの中で品質を最大限に引き上げるために、開発プロセスの各フェーズにて品質管理が必要となります。
また、開発手法によって品質管理の方法が異なります。
ウォーターフォールモデルの場合、要件定義、基本設計（外部設計）、詳細設計（内部設計）で定義されている要件を満たしていることを保証するために品質管理を行います。
スクラム型・アジャイル型などの場合、細かいサイクルでリリースを繰り返します。対象のスプリント（期間）で満たすべき品質基準を決定し、該当の機関でやること・やらないことを明確にして実施すると決定したことに注目し、品質管理を行います。
品質管理の工程
品質管理はさまざまなレビューやテストを行います。
設計レビュー
以下の観点で設計書をチェックしていきます。
- 要件定義で記載されている要件が設計にすべて落とし込まれているか
- 設計されているUI（画面）がユーザビリティ（使い勝手）を考慮した設計になっているか
- 詳細設計（内部設計）の内容が可読性や保守性を考慮した設計となっているか
ここで気をつけたいのは、上記3つをすべて埋めたとしても実際に作れるような設計になっているとは限らないということです。実際に作業に取り掛かれる設計であるかどうかを踏まえてチェックを行います。
コードレビュー
以下の観点でソースコード（プログラム）をチェックしていきます。
- 可読性に問題がないか
- 保守性に問題がないか
- コーディング規約に沿っているか
- テストコードがある場合、テストコードが正しく作成されているか（テストケースに漏れはないか）
ここで実装が仕様通りかまでレビューの対象・責務にするとレビュワーの負担（コスト）が急増するため、アクシアでは行いません。ただし、明らかに間違っている実装が見つかった場合には指摘します。
コードレビューした人は、メンバー全体に同じ改善事項の指摘をすることを回避するため、共通して周知すべき指摘事項はメンバーに共有するようにします。
単体テスト
単体テスト仕様書（テストケース）をレビューします。例えばブログ機能を作っていた場合、ログイン機能、投稿、保存、公開という機能ひとつひとつをレビューしていきます。
ホワイトボックステストの場合はテストコードをレビューします。ブラックボックステストの場合は検出した不具合の報告をします。不具合件数や不具合の傾向に偏りがある場合、チームで協議し以降の成果物で同様の失敗が減少するようにテコ入れを行います。
結合テスト
結合テスト仕様書（テストケース）をレビューします。例えばブログ機能を作っていた場合、ログイン→投稿→保存→公開と実際に使うような操作をして、不具合が出ないかテストを行います。
また、発生した不具合が結合テストで顕在化されるべき不具合であったかを評価します。結合テストで顕在化されるべき不具合であった場合、結合テストの不具合として報告し、単体テスト同様に不具合件数や不具合の傾向に偏りがある場合はフィードバックします。
もしも結合テストで顕在化されるべき不具合ではない場合、原因工程を特定します。単体テストで顕在化されるべき不具合が検出されていて、不具合発生の原因が単体テストのテストケース不足であった場合は単体テストの追加試験の実施を検討します。
単体テストで顕在化されるべき不具合が検出されていて、単体テストのテスト通過はしているがその後の改修で退行（デグレード）が発生している場合は、デグレードの原因を詳しく確認して再発防止策を検討します。
性能テスト
要件定義において性能要件が定義されている場合は、性能要件を満たしているか測定します。性能要件が明記されていない場合でも、本番運用と同等のデータボリュームにて一連の操作を行い、システムの動作が運用上問題ないレベルで動作することを確認します。
問題が検出された場合はボトルネックの特定を行い、問題を切り分けます。プログラムの実装、サーバー性能などボトルネックとなっている原因を取り除く対応を行います。
負荷テスト
アクセスが集中するユースケースが想定されるシステムの場合、要件定義にて想定される負荷状況を定義します。要件定義にて定義されている要件に沿って、同等の負荷を与えて測定します。負荷を与えてシステムの動作に問題が発生しないか検証していきます。
問題が検出された場合にはボトルネックの特定を行い、問題を切り分けます。プログラムの実装、サーバー性能などボトルネックとなっている原因を取り除く対応を行います。
保守・運用
セキュリティアップデートやミドルウェアアップデート、サーバーOSアップデートなどによるシステムの動作環境(外的要因)が変化した場合に、システム全体の動作に問題が発生しないかテストをします。機能追加、障害改修、仕様変更を実施した場合に、デグレード(退行)が発生していないかを検証するために、必要十分なテストケースを用意します。
実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>
品質管理のポイント
バグの傾向を把握し、開発者にフィードバックすることがポイントです。プログラムのコードは、開発者それぞれ書き方のクセがあり、そのクセによってバグの傾向も同じような症状になることが多くあります。それに気づき今後どうしていくか改善策を練るために、フィードバックは欠かせません。
自動化できるテストはできるだけ自動化することもポイントです。自動化したテストがあると、人為的なミスを防げたり、他の工程に時間をあてることができたりとメリットが多くあります。また、自動化されたテストがあると内容を変える際に、テストに合格し続けるようにコードを書いていけばよいため、次期開発の役に立ちます。
品質管理の古い手法で実装したプログラムの行数に応じて一定の割合でバグが含まれていると仮定する方法がありますが、近年の開発手法にはマッチしていません。
アクシアにおける品質管理
アクシアでは不具合が見つかった際に、不具合が見つけられたことをチームの成果とする文化を重要視しています。改善のために原因を追求することはありますが、ミスを検出し、より効率的に品質を高めることが目的であるため、ミスそのものを追求することはしません。
また、プロジェクトごとに重要となるメインテーマ（お客様が最も重要視している機能や業務）の品質を強化する文化があります。お客様が重要視しているポイントはプロジェクトごとに異なり、システム投資で一番解決したかったポイントで不具合が発生すると、信頼の失墜につながってしまいます。
投下できるコスト（マンパワー）は有限であるため、特に強化すべき機能に優先的にコストを投下します。このバランス感覚を醸成するために、アクシアでは初期の打ち合わせ段階から品質管理チームが打ち合わせに参画しています。
システム開発の品質管理とは？まとめ
品質管理は、バグがゼロにならないことを前提に、限られたコストの中で品質を最大限に引き上げるために行います。バグ（不具合）をいち早く発見して解決できるよう、傾向と対策を常に考えて品質の向上をはかります。
システムの品質はわかりにくいものですが、良い品質のシステムであることはとても重要になっていきます。品質が悪いものであると、システム障害が発生しやすくなったりセキュリティ上の問題が起きたりしてしまいます。お客様が満足できる品質のシステムをお届けできるよう、数々のテストを行い品質管理をしています。
システムの品質について、詳しくは別の記事でも紹介しています。
この記事によって、システム開発成功のお手伝いができましたら幸いです。最後までお読みいただき、ありがとうございました。
