品質を後工程に任せない考え方とは？IT初心者が身につけたい「作り込み品質」の基本

結論からいうと、品質を後工程に任せないとは「テスト担当が見つけてくれる」「レビューで直してもらえばいい」と考えず、設計・実装・確認の各段階で品質を作り込む考え方です。

IT現場では、設計者、開発者、テスト担当、運用担当など複数の人が関わります。そのため、「自分の作業が終われば次の工程で確認してもらえる」と考えてしまうことがあります。

しかし、前工程で作り込まれた不具合ほど、後になって修正コストが大きくなりやすいのが実務です。

新人のうちから、「品質は最後に確認するものではなく、最初から作るもの」という考え方を持つことが重要です。

「品質を後工程に任せない」とはどういう意味か

システム開発には、大まかに次のような工程があります。

• 要件定義
• 基本設計
• 詳細設計
• 実装
• 単体テスト
• 結合テスト
• システムテスト
• 本番リリース
• 運用保守

品質を後工程に任せる考え方では、「実装時に多少問題があっても、テスト工程で見つかるだろう」と考えます。

一方、品質を作り込む考え方では、要件定義では要件の抜けを防ぎ、設計では矛盾を防ぎ、実装ではバグを減らし、テストでは残った問題を確認するというように、各工程で品質を確保します。

テスト工程は「品質を作る場所」ではなく、主に「作り込んだ品質を確認する場所」と考えると理解しやすいでしょう。

なぜ後工程に任せると問題になるのか

前工程のミスは、後工程になるほど影響範囲が広がることがあります。

たとえば要件定義で「退職済みユーザーは検索対象外」という条件が抜けていたとします。

このまま進むと、設計書にもその条件がなく、実装にも入らず、テスト項目にも含まれない可能性があります。

本番運用後に発覚すると、仕様確認、設計修正、コード修正、テスト、再リリースまで必要になることがあります。

上流工程の小さな漏れが、下流工程では大きな手戻りになるのがポイントです。

初心者が覚えておきたい基本の考え方

よくある考え方	品質を作り込む考え方
レビューで指摘してもらえばよい	レビュー前に自分で確認する
テスト担当がバグを見つける	実装時点でバグを減らす
動けば完成	異常系や影響範囲まで確認する
仕様が曖昧でも進める	曖昧な点は実装前に確認する
障害は運用担当が調べる	調査できるログを開発時に用意する

考え方1．仕様の曖昧さをそのまま実装しない

品質問題はコードだけで発生するわけではありません。

仕様が曖昧なまま実装すると、開発者ごとに解釈が変わります。

たとえば「一定期間ログインしていないユーザーを無効化する」という仕様があった場合、次の点を確認する必要があります。

• 一定期間とは何日か
• 最後にログインした日をどこから取得するか
• サービスアカウントは対象か
• 退職者は別処理か
• 無効化前に通知するのか
• 処理に失敗した場合はどうするか

この状態で「たぶん90日だろう」と実装してはいけません。

不明点を放置しないこと自体が品質活動です。

考え方2．設計段階で失敗パターンを考える

正常に処理できるケースだけを設計すると、障害時の動作が曖昧になります。

設計時には次のような状態を考えます。

• 対象データが存在しない
• 入力値が不正
• データベースに接続できない
• APIがタイムアウトする
• 権限不足で処理できない
• ファイルが存在しない
• 途中で処理が失敗する

「エラーになったらどうするか」を実装者の判断に任せるのではなく、可能な範囲で設計段階から決めておきます。

考え方3．コードを書く前にテスト観点を持つ

実装後に初めて「何をテストしよう」と考えると、実装者自身が想定した条件だけを確認しがちです。

そこで、コードを書く前に最低限のテスト観点を考えます。

たとえば1～100まで入力できる項目なら、次の値が候補になります。

• 正常値の50
• 最小値の1
• 最大値の100
• 範囲外の0
• 範囲外の101
• 空欄
• 文字列

このように考えると、実装時点で条件式の漏れにも気付きやすくなります。

テストを後から考えるのではなく、実装と同時に考えるのが重要です。

考え方4．セルフレビューしてから他人に見せる

コードレビューや設計レビューは重要ですが、レビュー担当者に品質を丸投げしてはいけません。

提出前に自分で確認します。

1. 仕様どおりになっているか
2. 不要な処理が残っていないか
3. 異常系が考慮されているか
4. 変数名や処理内容が分かりやすいか
5. ログに必要な情報が出るか
6. 既存機能への影響がないか
7. テスト結果を確認したか

時間を置いてから見直すと、自分で書いた直後には気付かなかった問題を見つけられることもあります。

考え方5．「動いた」ではなく「期待どおり」を確認する

新人によくあるのが、エラーが出なかったので正常と判断することです。

しかしプログラムが正常終了していても、処理結果が間違っている場合があります。

たとえば10件更新する処理が、実際には9件しか更新していなくても画面上でエラーが出ないかもしれません。

確認すべきなのは、処理が終了したかではなく、期待する結果と実際の結果が一致したかです。

考え方6．自動テストで早く問題を見つける

単体テストを自動化できる環境では、自動テストを活用します。

コードを変更するたびに自動テストを実行できれば、過去に正常だった処理が壊れていないか早い段階で気付けます。

これはCI（Continuous Integration：継続的インテグレーション）と組み合わせて利用されることもあります。

CIとは、コードの変更を継続的に統合し、自動ビルドや自動テストなどを行う仕組みです。

重要なのは、自動化そのものではありません。

問題をできるだけ早い段階で見つける仕組みを作ることが目的です。

考え方7．ログも開発時点で品質として考える

本番障害が発生したとき、ログが不足していると原因調査に時間がかかります。

「障害が起きてからログを追加する」のではなく、開発時点で調査に必要な情報を考えます。

たとえば次の情報です。

• 処理開始日時
• 対象処理
• 対象データを識別できる情報
• 処理結果
• エラー内容
• 外部システムとの通信結果

ただし、パスワード、アクセストークン、個人情報などの機密情報をそのままログへ出力してはいけません。

運用で調査できることも品質の一部と考えます。

考え方8．レビューを検査ではなく予防に使う

レビューは、完成品の間違いを探すだけの作業ではありません。

設計段階でレビューすれば、コードを書く前に問題を発見できます。

実装前に設計レビューを行い、実装中には小さな単位で相談し、完成後にはコードレビューを行うなど、早い段階で他者の視点を取り入れる方法があります。

後工程でまとめて指摘されるより、小さい段階で問題を修正するほうが手戻りを減らしやすくなります。

考え方9．変更時は必ず影響範囲を見る

既存システムの改修では、修正した機能だけが正常でも十分ではありません。

共通部品を変更すると、別の画面やバッチ処理まで影響することがあります。

変更前には次の点を確認します。

• 変更対象をどこから呼び出しているか
• 共通処理かどうか
• データ形式が変わらないか
• APIの入出力が変わらないか
• 既存ユーザーへの影響がないか
• どの回帰テストが必要か

変更箇所だけでなく、変更によって壊れる可能性がある場所を見るのがポイントです。

考え方10．運用担当へ問題を押し付けない

開発者が「本番で問題が出たら運用担当が調べればよい」と考えると、障害対応しにくいシステムになります。

たとえばエラーコードがなく、ログもなく、「処理に失敗しました」とだけ表示されるシステムでは原因の切り分けが困難です。

開発段階から、次のことを考えます。

• エラー時に何を表示するか
• どのログを残すか
• 監視で検知できるか
• 再実行できるか
• 途中失敗時にデータが壊れないか
• 復旧手順を用意できるか

品質は開発工程だけではなく、運用しやすさや障害復旧のしやすさまで含めて考えることが重要です。

実際のIT現場でよくある事例

社内向けのユーザー登録システムを例に考えてみます。

画面から入力されたユーザー情報をActive Directoryへ登録する仕組みがあるとします。

後工程に品質を任せる場合、まず実装し、テスト担当に確認してもらいます。

しかし、実装前に確認していれば次の問題を防げる可能性があります。

• 同名ユーザーが存在した場合の扱い
• 社員番号が重複した場合の扱い
• Active Directoryに接続できない場合の処理
• 登録途中で失敗した場合の扱い
• 操作ユーザーに権限がない場合の処理
• ログに何を残すか

こうした条件を仕様・設計・実装の各段階で確認しておけば、結合テストで大量の問題が見つかる状況を減らせます。

筆者が現場で失敗した例

実務で印象に残っているのは、「テストで確認されるから大丈夫」と考えて細かい例外処理を後回しにしたケースです。

正常系の実装を優先し、そのままテスト工程へ進めたところ、異常系の指摘が複数発生しました。

1件ずつ見ると小さな修正でしたが、設計書の更新、コード修正、単体テストの再実施、レビュー、結合テストの再確認まで必要になり、想像以上に手戻りが増えました。

最初に数十分かけて異常系を整理していれば、防げた内容でした。

それ以降は、「後で見つけてもらう」より「今ここで潰せないか」を考えるようにしています。

不具合が見つかったときの切り分け方

問題が見つかった場合は、責任の所在を探す前に原因を切り分けます。

1. 現象を再現する
2. 仕様と期待結果を確認する
3. 入力値を確認する
4. アプリケーションログを確認する
5. Windows側を確認する
6. ログインユーザーと権限を確認する
7. ネットワーク疎通を確認する
8. DNSの名前解決を確認する
9. サーバーやデータベース側を確認する
10. 直前の変更内容を確認する

特定ユーザーだけで発生するなら、ログインユーザーや権限、端末固有設定を疑います。

全ユーザーで発生するなら、サーバー側、ネットワーク側、共通処理などの可能性も考えます。

Windowsで確認できる基本項目

Windows環境で動作する業務システムでは、GUIとCUIの両方を使って確認できます。

GUIで確認する

• 設定画面からネットワーク状態を確認する
• 資格情報やログインユーザーを確認する
• 対象フォルダのプロパティから権限を確認する
• イベントビューアーからエラーを確認する

コマンドプロンプトで確認する

コマンド	確認内容
whoami	ログインユーザー
ipconfig /all	IPアドレスやDNS設定
ping	基本的なネットワーク疎通
nslookup	DNSによる名前解決

PowerShellで確認する

PowerShellでは「Get-NetIPConfiguration」などを利用して、ネットワーク構成を確認できます。

Windows 11では、スタートメニューから「ターミナル」を検索してPowerShellを起動できます。

イベントビューアーの確認方法

1. Windowsキー + Rを押す
2. 「eventvwr.msc」と入力する
3. Enterキーを押す
4. 「Windowsログ」を展開する
5. 「Application」または「System」を開く
6. 問題が発生した時刻付近のエラーや警告を確認する

イベントID、ソース、発生日時、エラー内容を記録すると、上司や上位担当者へ報告しやすくなります。

初心者がやりがちなミス

• レビューで直してもらう前提で提出する
• 正常系だけ確認する
• 仕様が曖昧でも自己判断で進める
• 単体テストを後回しにする
• エラー処理を最後に追加しようとする
• ログを本番障害後に考える
• 修正した機能だけテストする
• 本番環境で初めて異常系を確認する
• テスト担当から指摘された内容だけを直す

特に危険なのは、「レビューで指摘されなかったから正しい」と考えることです。

レビューやテストで問題が見つからなくても、品質を保証できるわけではありません。

現場で評価される確認の順番

新人のうちは、次の順番を習慣にすると品質を作り込みやすくなります。

1. 仕様を読む
2. 曖昧な点を洗い出す
3. 正常系を整理する
4. 異常系と境界値を整理する
5. 影響範囲を確認する
6. 実装する
7. 自分で動作確認する
8. セルフレビューする
9. 単体テスト結果を残す
10. 他者レビューへ出す

レビューに出す前までに、自分で説明できる状態にすることが大切です。

上司へ報告するときのポイント

品質問題を発見した場合は、次の情報を整理します。

• どの機能で発生したか
• 何が期待結果と違うか
• 再現手順
• 再現率
• 影響範囲
• 原因として考えている場所
• 確認済みの項目
• ログやエラーメッセージ
• 直前の変更内容

「テスト担当から指摘されました」だけではなく、なぜ入り込んだのか、どの工程で防げたのかまで整理すると、再発防止につながります。

エスカレーションするタイミング

次のような場合は、自己判断で作業を続けず早めに上司や担当チームへエスカレーションします。

• 本番サービスに影響が出ている
• 複数ユーザーへ影響している
• データ破損や消失の可能性がある
• セキュリティ問題が疑われる
• 個人情報や機密情報に影響する
• 本番データベースの直接修正が必要
• Active DirectoryやDNSなど共通基盤の変更が必要
• サーバー再起動など影響の大きな操作が必要

品質向上のためであっても、影響範囲の大きな変更を無断で行ってはいけません。

応用知識：シフトレフトという考え方

品質を早い段階から確保する考え方として、Shift Left（シフトレフト）という言葉があります。

開発工程を左から右へ並べたとき、テストやセキュリティ確認などを、より早い「左側」の工程へ移して実施する考え方です。

たとえば、完成後に初めてセキュリティテストをするのではなく、設計段階で認証・権限・入力チェックを確認します。

単体テストや静的解析、コードレビューなどを開発中から取り入れるのも、同じ方向性です。

関連するIT用語

用語	意味
シフトレフト	テストや品質確認を開発の早い段階から実施する考え方
単体テスト	関数やクラスなど小さな単位を確認するテスト
回帰テスト	変更によって既存機能が壊れていないか確認するテスト
コードレビュー	他の開発者がコードを確認する作業
静的解析	プログラムを実行せずコード上の問題を検出する方法
CI	Continuous Integration。変更したコードを継続的に統合・検証する仕組み
影響範囲	変更や障害によって影響を受ける機能・ユーザー・システムの範囲

よくある質問（FAQ）

Q．テスト担当がいるなら、開発者のテストは不要ですか？

不要にはなりません。開発者が単体レベルで確認したうえで、テスト担当が別の視点から確認することで品質を高めます。テスト担当は開発者の確認作業を代わりに行う人ではありません。

Q．レビューで指摘されるのは悪いことですか？

レビューで問題が見つかること自体は悪いことではありません。ただし、毎回同じ種類のミスを指摘される場合は、セルフレビュー方法を見直す必要があります。

Q．品質を意識すると開発速度が落ちませんか？

短期的には確認作業が増える場合があります。しかし、後工程での手戻りや本番障害が減れば、プロジェクト全体では効率が上がることがあります。早期発見できる問題を後まで持ち越さないことが重要です。

Q．初心者は何から始めればよいですか？

「この問題を次の担当者に見つけてもらう前に、自分で確認できないか」と考えることから始めるのがおすすめです。仕様確認、異常系確認、セルフレビューの3つを習慣にすると効果があります。

Q．品質を作り込めばテスト工程は不要になりますか？

不要にはなりません。早い工程で品質を高めても、結合したときに初めて発生する問題や、本番に近い環境でしか確認できない問題があります。各工程で確認する目的が異なります。

まとめ

品質を後工程に任せないとは、「最後にテストすれば品質が上がる」と考えず、要件・設計・実装・レビュー・テストの各段階で問題を減らしていくことです。

新人のうちは、「レビュー担当が確認するから」「テスト工程があるから」と考えてしまうことがあります。

しかし実務では、早い段階で問題を見つけるほど、修正範囲を小さくしやすくなります。

まずは、「仕様は曖昧ではないか」「異常系を考えたか」「自分でレビューしたか」「変更の影響範囲を確認したか」「障害時にログから追えるか」を自分の工程で確認する習慣を身につけましょう。

品質はテスト担当が作るものではありません。自分の工程でできる限り作り込み、次の工程では別の視点で確認してもらう。この考え方が、手戻りや本番障害を減らすための基本です。