なぜ品質を学ぶのか
ストーリー
先輩から「この作業、もう一度確認してもらえる?」と言われた。
何を確認すればいいのかわからない。
「えっと...見た感じ大丈夫だと思うんですけど...」
「大丈夫『だと思う』じゃなくて、ちゃんと確認してほしいんだ。品質を意識した作業の仕方を覚えていこう」
品質を学ぶ理由
バグは後から見つかるほど修正コストが高い
開発の現場で最も怖いのは、リリース後に問題が見つかることです。
開発中に発見 → 5分で修正
テスト中に発見 → 1時間で修正
リリース後に発見 → 数日〜数週間の対応
小さなミスでも、発見が遅れると大きな問題になります。
顧客の信頼に直結する
| シナリオ | 結果 |
|---|---|
| ボタンを押しても反応しない | ユーザーが離れる |
| データが消える | 信頼を失う |
| 表示が崩れる | 「ちゃんとしてない会社」という印象 |
一度失った信頼を取り戻すのは、品質を最初から確保するよりも何倍も大変です。
プロとしての意識
アマチュアとプロの違いは何でしょうか?
| アマチュア | プロ |
|---|---|
| 「動いたからOK」 | 「正しく動くことを確認してOK」 |
| 「たぶん大丈夫」 | 「テストで確認済み」 |
| 自分だけが使う前提 | 誰が使っても問題ない前提 |
プロの開発者は「動くコード」ではなく「品質の高いコード」を書きます。
品質意識がないとどうなるか
シナリオ: 新人エンジニアの田中さん
月曜日: タスクを完了、「動いたからOK」と思いPRを出す
火曜日: レビューで10箇所の指摘を受ける
水曜日: 修正中に新たなバグを作り込む
木曜日: テストで不具合が見つかる
金曜日: まだ修正が終わらない...
→ 1日で終わるはずの作業が1週間かかった
シナリオ: 品質を意識する佐藤さん
月曜日: タスクを完了、チェックリストで自己確認
テストを実行、問題なし → PRを出す
火曜日: レビューで2箇所の軽微な指摘
すぐに修正 → マージ完了
→ 2日で完了、余裕のある水曜日
このミッションで学ぶこと
このミッションを完了すると、以下ができるようになります:
- ソフトウェア品質の基本を説明できる
- チェックリストを作成・活用できる
- テスト手順書に従ってテストを実行できる
- テスト結果やバグを報告できる
- コードレビューを受ける準備ができる
- レビュー指摘を活かして改善できる
全6ステップ、合計20時間 で、品質を意識した作業の基本をマスターします。
まとめ
| ポイント | 内容 |
|---|---|
| バグの発見タイミング | 後から見つかるほど修正コストが高い |
| 顧客の信頼 | 品質の低さは信頼の低 下に直結する |
| プロ意識 | 「動けばOK」ではなく「品質を確認してOK」 |
次のステップへ
品質を学ぶ理由が理解できましたか?
次のセクションでは、ソフトウェア品質とは具体的に何を指すのかを学びます。 「品質が高い」とはどういう状態なのかを整理しましょう。
推定読了時間: 15分