ソフトウェア品質とは
ストーリー
「品質って、バグがないことですか?」
「それも大事だけど、品質ってもっと広い意味があるんだよ」
「バグがないだけじゃダメなんですか?」
「例えば、バグはないけど5秒かかるログインフォーム、使いたいと思う?」
「...それは嫌ですね」
品質の2つの側面
ソフトウェア品質は大きく 2つの側面 に分けられます。
1. 機能要件(正しく動くか)
「仕様通りに動作すること」 を指します。
| 機能要件の例 | 確認ポイント |
|---|---|
| ログイン機能 | 正し いID/パスワードでログインできるか |
| 検索機能 | キーワードに合った結果が表示されるか |
| 登録機能 | 入力したデータが正しく保存されるか |
| 計算機能 | 計算結果が正確か |
「ボタンを押したら、期待通りの動作をする」これが機能要件です。
2. 非機能要件(どれくらい良く動くか)
「正しく動く」だけでなく「どれくらいの品質で動くか」 を指します。
| 非機能要件 | 説明 | 具体例 |
|---|---|---|
| 性能(パフォーマンス) | 速さ | ページ表示が3秒以内 |
| 可用性 | 安定して使えるか | 99.9%の時間稼働している |
| セキュリティ | 安全か | パスワードが暗号化されている |
| ユーザビリティ | 使いやすさ | 直感的に操作できる |
| 保守性 | 変更しやすいか | コードが整理されている |
| 互換性 | 様々な環境で動くか | Chrome、Firefox、Safariで動作する |
品質の具体例
良い品質の例
ユーザーがログインボタンを押す
→ 1秒以内にログイン完了
→ ダッシュボードが表示される
→ パスワードは暗号化されて保 存されている
→ 入力ミスには丁寧なエラーメッセージが表示される
悪い品質の例
ユーザーがログインボタンを押す
→ 10秒間何も反応がない
→ やっとログインできたが画面が崩れている
→ パスワードが平文で保存されている
→ 間違えると「Error」とだけ表示される
どちらも「ログインできる」という機能要件は満たしていますが、品質に大きな差があります。
品質は「視点」で変わる
同じソフトウェアでも、立場によって求める品質は異なります。
| 立場 | 重視するポイント |
|---|---|
| エンドユーザー | 使いやすい、速い、止まらない |
| 開発者 | コードが読みやすい、テストしやすい、変更しやすい |
| 運用者 | 監視しやすい、障害対応が簡単、ログが充実 |
| 経営者 | コストが適切、納期を守れる、顧客満足度が高い |
新人のうちは、まず「機能要件を正しく満たす」ことに集中しましょう。 非機能要件は経験を積むにつれて意識できるようになります。
新人が最初に意識すべき品質ポイント
最優先: 正しく動くか
- 仕様書・チケットの要件を満たしているか
- 主要なケースで期待通りに動作するか
次に大事: エラー時の動作
- 異常な入力をしたとき、アプリが壊れないか
- エラーメッセージが適切か
余裕があれば: 読みやすさ
- コードが他の人にも理解できるか
- 変数名が意味を伝えているか
品質意識の成長ステップ:
[動く] → [正しく動く] → [安全に動く] → [快適に動く]
初心者 新人 中級 上級
まとめ
| ポイント | 内容 |
|---|---|
| 機能要件 | 仕様通りに正しく動くこと |
| 非機能要件 | 速さ、安全性、使いやすさなど動作の品質 |
| 視点の違い | 立場によって重視する品質ポイントが異なる |
| 新人の優先 | まずは「正しく動くか」を確認することから始める |
チェックリスト
- 機能要件と非機能要件の違いを説明できる
- 非機能要件の種類を3つ以上挙げられる
- 品質は立場によって見え方が違うことを理解した
次のステップへ
ソフトウェア品質の基本がわかりましたか?
次のセクションでは、品質にかかるコストについて学びます。 「品質を上げる」ことと「コスト」の関係を理解しましょう。
推定読了時間: 25分