シリーズ: システム開発の基礎
- システム開発におけるシステムとは何か
- V字モデルを使って開発プロセスを組み立てよう〜システム開発で迷子にならないために
- V字モデルの基本構造をWhy,What,How,Make,Testの視点で理解する
- V字モデルの各レイヤー(企画、運用・評価編)
- V字モデルの各レイヤー(要件定義、運用テスト・システムテスト編)
- V字モデルの各レイヤー(基本設計、結合テスト編)
- V字モデルの各レイヤー(詳細設計、単体テスト編)
- V字モデルの各レイヤー(プログラミング、コードレビュー編)
- システム開発の品質保証プロセスの進め方
- 品質を支える4つの視点：外部品質・利用時の品質・内部品質・プロセス品質を体系的に理解する（本記事）
TRACERYプロダクトマネージャーの haru です。
システムの品質を考えるとき、まず注目されるのは「仕様どおりに正しく動くか」「不具合なく安定して動作するか」といった、動作の正確さや信頼性といったユーザーから見える品質です。
しかし、リリースを重ねるほど不具合が増えたり、修正に時間がかかるようになる背景には、ユーザーには見えないシステム内部のつくりや、開発プロセスそのものに問題がある場合があります。
本記事では、品質を捉えるための4つの視点（外部品質、利用時の品質、内部品質、プロセス品質）と、それぞれの関係について説明します。
外部品質と利用時の品質
ユーザーから直接確認できる品質には、大きく「外部品質」と「利用時の品質」の2種類があります。
いずれもシステムの外側から評価される品質ですが、着目するポイントが異なります。以下にそれぞれ説明します。
外部品質
システムが「仕様どおりに正しく動作するか」「不具合なく安定して使えるか」といった点は、ユーザーが実際の利用を通じて確認できる品質であり、このように外側から観察できる特性を「外部品質」と呼びます。
動作の正確さ、安定性、セキュリティ、性能など、多くの場合、品質と聞いてまずイメージされるのがこの外部品質です。
具体的には、画面が正しく表示される、ボタンが期待どおりに反応する、といった目に見える品質のことです。
利用時の品質
品質は「正しく動く」だけでは十分とはいえません。
そのプロダクトを使うことで、利用者が業務の効率化や成果の向上といった目的を達成し、価値を得られるかどうかという視点で評価される品質が「利用時の品質」です。
利用時の品質もプロダクトの外側から判断できますが、単なる動作の正確性ではなく、その利用によって価値が生まれるかどうかに着目する点が外部品質とは異なります。
その重要性から、利用時の品質は外部品質とは独立した視点として扱われます。
内部品質
外部品質や利用時の品質は、ユーザーに直接評価される品質ですが、それを継続的に維持するためには、システム内部の構造的な品質、すなわち「内部品質」が欠かせません。
内部品質の代表的な特性として、保守性、再利用性、テスト容易性などが挙げられます。
これらは、設計の妥当性やコードの構造の健全性によって左右され、ソフトウェアの変更容易性や拡張性、そして品質の持続性を支える土台となります。
内部品質が外部品質に与える影響
内部品質が低い状態、たとえば複雑で読みづらいコードや整合性の取れていない設計では、変更や修正のたびに不具合が発生しやすくなります。
さらに、修正の影響範囲が特定しづらくなるため検証に時間がかかり、開発生産性は大きく低下します。
生産性が下がった状態でビジネス上の都合を優先して無理にリリースを早めようとすると、十分な検証が行えないままリリースに至り、不具合が混入しやすくなります。その結果、外部品質の低下として顕在化します。
これは、内部品質の劣化が外部品質へと波及する典型的な悪循環です。
逆に内部品質が高いと、設計の一貫性やコードの見通し、依存関係が整理されているため、変更時に別の箇所が壊れにくい構造になります。
その結果、不具合が混入しにくくなり、外部品質の向上につながります。
このように内部品質はユーザーには見えないものの、長期的に外部品質に影響を与える重要な要素であり、外部品質を継続的に維持・改善するための前提条件といえます。
外部品質が十分に確保されていると、プロダクトは正しく動作し、必要な機能を期待どおりに利用できる状態になります。
外部品質が整うことでユーザーは目的の達成に集中でき、その結果として価値を得られる「利用時の品質」が実現されます。
プロセス品質
内部品質を高めるためには、開発プロセスの品質（プロセス品質）を高めることが不可欠です。
ここでいうプロセス品質とは、設計やプログラミングそのものの質に加え、要件管理、設計判断の基準、レビューの方法、記録や共有の仕組みといった、開発プロセスの進め方の品質を指します。
プロセス品質が内部品質に与える影響
プロセス品質が低いまま開発を続けると、成果物の内部品質が下がります。
内部品質は「作ってみたら勝手に高くなる」ものではなく、どのような手順・考え方・基準で開発したかの結果として決まるからです。
プロセス品質が低いと、要件や設計の意図、前提条件が曖昧なまま実装が始まり、以下のような事が起こります。
- 似た機能が複数箇所で別実装される
- 命名や設計ルールがバラバラになる
- モジュールやコンポーネントの役割や責務の分離が曖昧になる
その結果、設計の整合性が失われ、コードは複雑化し、影響範囲の特定も難しくなります。
先に説明した通り、内部品質の低下は、やがて性能や信頼性、安定性といった外部品質の劣化として顕在化します。
外部品質の低下は表面的な現象に過ぎず、その背景には内部品質の低下があり、さらにその根本原因となるのがプロセス品質の低さです。
逆にプロセス品質が高ければ、設計の一貫性や構造の健全性が保たれ、内部品質が向上します。
内部品質が高くなることで変更容易性が高まり、開発生産性向上と不具合の抑制が実現し、外部品質も継続的に維持・改善されます。
つまり、良いプロセスが内部品質を高め、内部品質が外部品質を支えるという好循環が生まれます。
最後に
本記事では、外部品質、利用時の品質、内部品質、プロセス品質という４つの視点から、品質をどのように積み上げていくかを説明しました。
ユーザーから見える部分の品質だけを整えても、内部品質やプロセス品質が伴っていなければ、変更のたびに不具合が発生するようになり、外部品質は維持できません。
長期的に品質を安定させるには、日々の開発プロセスを整え、内部品質を継続的に高めることが不可欠です。
内部品質が高まれば、不具合は入りにくくなり、開発生産性も向上し、その結果として外部品質も安定して改善されます。
良いプロセスが内部品質を生み、内部品質が外部品質を支えてこそ、持続的な品質向上が実現します。
その基本的な考え方を踏まえ、日々の開発に取り組んでいきましょう。
