Zenn
🍖

過去の自分に教えたい、ソフトウェア品質の心得

2024/12/23に公開
コードレビュー
品質
心得
idea

こんにちは、Naotoです！Ψ

ソフトウェアの品質って、エンジニアとして避けて通れないテーマですよね。
そもそも品質って何だろう？どんな基準で「良い」「悪い」を判断しているのか？
そんな疑問を一緒に考えていきましょう。

品質とは？

「品質」とは一言で言うと、製品やサービスがどれだけ期待や要求を満たしているかを表すものです。
この「期待」や「要求」には、ユーザーの期待、仕様、基準、そして開発者自身の価値観も含まれます。

たとえばソフトウェアの場合

  • ユーザー視点の品質
    使いやすく、安定していて、価値を提供できるもの。
  • 仕様視点の品質
    要件通りに機能が実装されていること。
  • 内部的な品質
    コードが読みやすく、保守しやすい状態。

ソフトウェア品質の2つの側面

1. 外部品質（ユーザーが感じる品質）

ユーザーやステークホルダーが直接体験する品質です。
私は特に非機能の部分を重視して取り組みます。経験上ボトルネックになりやすい部分ですので。

  • 機能性: 期待通りの動作をしているか？
  • 信頼性: バグが少なく安定しているか？
  • 使いやすさ: UIが直感的で操作が分かりやすいか？
  • 効率性: パフォーマンスは問題ないか？
  • 互換性: 他システムや環境と相性が良いか？

2. 内部品質（開発者が見る品質）

こちらはソフトウェアの内部構造やコードの状態です。開発者にとっての重要な視点。
プログラマーの視点で内部品質は考えてよいのでは？と日々思ってます。どでかいシステムだと設計書の精緻化はマストになってますね。

  • 保守性: コードが理解しやすい、修正しやすい。
  • 再利用性: 他でも使えるコードか？
  • 拡張性: 機能追加や変更が簡単か？
  • テスト容易性: テストしやすい設計か？
  • 効率的な設計: 無駄が少なく最適化されているか？

内部品質が高いと、長期的に開発コストを抑えられるし、チームの開発速度もアップします。

品質を判断する基準

品質を「良い」とするか「悪い」とするかは、以下の基準で考えてます。
要件整理ができているか？プログラマーの質で雑なコードになっていないか？無駄なタスク・効率的な作業を模索できているか？

  1. 要求との適合
    ユーザー要件や仕様をちゃんと満たしているか？

  2. 期待の満足度
    「動けばいい」じゃなくて、「使って気持ち良い」「価値を感じる」と思えるか？

  3. 欠陥や問題の有無
    バグが少なく、修正も簡単な状態か？

  4. 定量的な評価
    テストカバレッジやレスポンス速度など、具体的な数値目標を設定。

  5. コストと時間のバランス
    品質向上は大事だけど、やり過ぎると納期遅延やコスト増につながります。

QA（品質保証）とQC（品質管理）の違い

品質に関わる活動として、よく出てくるのがQAとQC。違いを整理してみました。
記載してみましたが、違いがあるんだなぐらいで私は良いと思ってます。同じ部門の人が担当することが多いと思いますので。

項目 品質保証（QA） 品質管理（QC）
目的 問題の未然防止とプロセス改善 問題の検出と是正
焦点 プロセス全体 製品やサービスの結果
アプローチ プロアクティブ（予防的） リアクティブ（反応的）
活動範囲 規格や手順の作成、監査 検査、テスト、統計的品質管理など
適用範囲 開発・製造プロセス全般 製品や成果物

QAとQCの相互補完的な関係

  • QAは「正しいやり方で作る仕組み」を設計します。
  • QCは「その結果、品質が正しいか」を確認します。

品質を高めるためのポイント

※重要
一番の本記事で伝えたい部分です。システム開発している方々に刺さると思います。

  • 「動く」と「良い」は違う
    動くコードは最低限。「良いコード」は保守性、読みやすさ、再利用性が高いこと。

  • テストはコストではなく投資
    テストを書く時間がない、は言い訳。テストはトラブルを防ぎ、未来の開発速度を守る保険です。

  • レビューは学びの場
    コードレビューで指摘を受けるのは恥じゃない。成長のチャンス！

  • 仕様書の曖昧さがバグを生む
    疑問点を放置せず明確化しよう。ここが品質の第一歩。

  • 技術的負債を放置しない
    「後で直そう」はほとんど直せない。「未来の自分」に優しいコードを。

  • 品質はチーム全員の責任
    QAやテスト担当者だけでなく、チーム全員で意識すべき課題。

  • ユーザー視点を忘れない
    完璧なコードでも使いにくければ意味がない。ユーザーの体験を最優先に。

最後に

品質は人やチーム次第で変わる生き物みたいなものです。
人の入れ替わりがあっても品質を落とさず、ユーザーに価値を届けるにはどうするか？
日々考え、チーム全員で取り組む必要があります。

最後まで読んでいただきありがとうございました！
よければ以下の記事もチェックしてみてください👇
品質に関わるコードレビューとエビデンスの重要性

Discussion