現場の機能を低下させる5つの瞬間 ｰ 大事故を防ぎチームに信頼される

はじめに

「プログラミング言語の文法はマスターした」
「フレームワークを使って、ローカル環境で動くアプリは作れるようになった」

エンジニアとしての第一歩を踏み出したとき、私たちは「コードを書くこと」そのものに全神経を注ぎがちです。しかし、実際の開発現場、特にユーザーが日常的に利用する商用サービスを運用するプロの現場に出たとき、本当に求められるのは「ただ動くコードを書く技術」だけではありません。

現場で最も重宝され、チームから絶大な信頼を寄せられるエンジニアは、一見地味に見える「大事故を防ぐための圧倒的な凡事徹底（当たり前のことを徹底的にやり抜くこと）」ができています。

逆に、どれだけトリッキーで美しいコードが書けたとしても、

• バックアップを取らずに本番環境を触る
• 行う内容が不確定なのに、上司に確認せず「自分の勘」で進める
• テストで正常系しか確認せず、ユーザーのイレギュラーな操作を無視する

といった「基本」を軽視するエンジニアは、いずれ必ず現場で事故を引き起こします。

本記事では、エンジニアが実務の荒波で生き残り、チームのコアメンバーとして信頼を勝ち取るために絶対に死守すべき「5つの基本の型」について、現場の生々しいアンチパターンと、今日から実践できるベストプラクティスを交えて徹底的に解説します。

若手エンジニアの方は日々の行動指針として、シニアエンジニアの方はチームの後輩に「これだけは読んでおいて」と渡すマニュアルとして、ぜひストック（ブックマーク）してご活用ください。

---

1. 【安全第一】バックアップは命綱。「自分は絶対にミスをしない」という過信がサービスの価値を損なってしまう

🚨 アンチパターン：切り戻せない作業

• 「ほんの数行の設定変更だから、バックアップを取るまでもないだろう」
• 「GUIツールでの直感的な操作だし、間違えるはずがない」
• 「手元のメモにコマンド履歴があるから、何かあってもすぐ手動で戻せる」

こうした甘い見通しで本番環境、あるいはステージング（検証）環境の作業に臨んだエンジニアを、私は何人も見てきました。そして、その中の数人は、一瞬のタイポ（打ち間違い）や意図しないエンターキーの押下によって、数日分のデータや、復旧に数十時間を要するシステム障害を引き起こしました。

プロの現場において、「バックアップを取らずに環境を変更すること」は、命綱をつけずにフリークライミングをするのと同じです。どんなに優れたエンジニアであっても、体調不良や集中力の欠如によって、ある日突然信じられないような凡ミスを犯します。システムを信じても、自分の手先と記憶力だけは絶対に信じてはいけません。

💡 ベストプラクティス：あらゆる変更の前に「退避」と「切り戻し手順」を確保する

どれだけ経験を積んだシニアエンジニアであっても、人間である以上、必ず操作ミス（ヒューマンエラー）を犯します。作業を行う際は、必ず以下の鉄則を守ってください。

1. データベース（DB）操作時の徹底
   • UPDATE や DELETE を手動で実行する前には、必ず SELECT で影響を受けるレコード（件数や対象）を確認する。
   • 可能な限りトランザクション（BEGIN TRANSACTION）を活用し、実行結果のログを確認してから COMMIT する。
   • 危険性の高い一括更新の前には、該当テーブルのダンプ（バックアップ）を必ず個別に取得する。
2. 設定ファイル・ソースコードの退避
   • サーバー上の設定ファイルを書き換える際は、必ず cp config.conf config.conf.org_20260618 のように、日付を入れたバックアップファイルを同一ディレクトリ内に生成しておく。
3. 「切り戻し手順（Rollback）」の言語化
   • 万が一、変更後にシステムが正常に動作しなかった場合、「どういう手順を踏めば、100%確実に作業前の状態に戻せるか」を作業前にテキストとして書き出しておく。
   • 障害が発生してパニックになっている頭で、その場で切り戻し手順を考えるのは不可能です。作業前に命綱を用意してください。

---

2. 【未来への手紙】「なぜこのコードにしたか」の背景をコメントに残す

🚨 アンチパターン：3ヶ月後の自分は「他人」

「コードを読めば何をしているか分かるから、コメントは一切不要。それがクリーンコードだ」

この主張は一見正論に聞こえますが、半分は間違いです。確かに、「変数の値を1増やしている」「ユーザー一覧をループで回している」といった「What（何をしているか）」を説明するコメントは不要です。コードを見ればそのまま理解できるからです。

しかし、実務のコードには必ず「Why（なぜ、あえてそうしたのか）」という、コードの文字面だけでは絶対に読み解けない文脈（ビジネスロジックの都合や、過去のバグ回避のための苦肉の策など）が存在します。コメントのないトリッキーなコードは、3ヶ月後の自分、あるいは新しくチームに入ってきたメンバーにとって、触ると爆発する「動く地雷」と化します。

💡 ベストプラクティス：仕様の「背景」と「意図」をコメントに刻む

コメントに残すべきは、コードの直訳ではなく、「コードの裏側にあるストーリー」です。

// ❌ 悪い例：見れば分かることを書いている
// ユーザーの年齢が18歳以上かチェックする
if (user.age >= 18) {
  processPayment();
}

// ⭕ 良い例：なぜ「18歳」なのか、なぜ「この場所」で処理するのかの背景が分かる
// 成人年齢の判定基準を変更。
// ただし、決済プロバイダー（A社）のAPI仕様により、18〜19歳は特定の決済手段が制限されるため、
// 共通処理に回す前にここで事前にフィルタリングをかけている。（詳細はIssue #1402を参照）
if (user.age >= 18) {
  processPayment();
}

コメントに書き残すべき3大要素

• あえて採用したトリッキーな実装の理由
  • 「パフォーマンス向上のため、あえて正規化を崩してここにキャッシュを持たせている」など。
• ワークアラウンド（一時的な回避策）の背景
  • 「外部ライブラリのバージョンv3.2における既知のバグを回避するため、一時的にこの実装にしている。v3.3がリリースされたらリファクタリングすること」など。
• 関連するドキュメントやチケットのURL
  • GitHubのIssue、Jira、Notionなどの仕様書URLを1行添えておくだけで、後から調査する人の時間が数百時間節約されます。

---

3. 【コミュニケーション】「報連相」の鉄則。悪い報告ほど光の速さで共有せよ

🚨 アンチパターン：沈黙が生む致命的な手遅れ

• 「進捗どう？と上司から聞かれるまで、進捗が数日間止まっていることを報告しない」
• 「バグを見つけたが、自分で直せるかもしれないから、完全に手遅れになるまで隠しておく」
• 「自分のタスクは終わったが、終わったことをチームの誰にも伝えていない」

リモートワークや非同期コミュニケーションが普及した現代の開発現場において、「エンジニアの沈黙」はプロジェクト管理上の最大のリスクです。特に、トラブルが発生したときに「怒られたくない」「自分の無能さを露呈したくない」と抱え込み、数日経ってから「実はできませんでした」と報告する行為は、プロジェクト全体のスケジュールを破綻させ、チームからの信頼を完全に失墜させます。

💡 ベストプラクティス：テキストコミュニケーションをハックする

報連相は、あなたのプライドを守るためのものではなく、「プロジェクトのリスクを早期に発見し、チーム全体で殴り倒すため」の仕組みです。

1. 悪い報告（バグ・遅延）こそ秒速で

「すみません、本番環境のデータを誤って書き換えた可能性があります」
「予定していた実装ですが、技術的な障壁が見つかり、期日に間に合わない可能性が出てきました」

これらの報告は、早ければ早いほど、上司や周囲のメンバーがサポートに入り、致命傷になる前にリカバリーできます。怒られることを恐れて報告を遅らせると、傷口は数倍に広がります。

2. 「事実」と「推測」を明確に分けて伝える

特にトラブル発生時の報連相では、情報が混ざると周囲が誤った判断をしてしまいます。

• 事実： ログに NullPointerException が出力されていること。サーバーのCPU使用率が100%になっていること。
• 推測： おそらく、先ほどリリースしたA機能のループ処理が原因ではないかと考えられること。

これらを混同せず、「起きている事実」と「自分の見立て（推測）」を箇条書きで分かりやすく伝えるのが、デキるエンジニアの報連相です。

3. 「相談」は自分の意見（仮説）を持って行う

「◯◯が動かないんですけど、どうすればいいですか？」という丸投げの相談は、相手の時間を奪います。
「◯◯が動かないため相談です。エラーログから原因はAだと推測し、対策としてBとCを考えました。私はリスクの低いBで進めたいと考えていますが、この方針でよろしいでしょうか？」

このように、「現状 + 自分の仮説・提案 + 相手への問い」の形で相談できるようになると、上司は「承認」するだけで済むため、意思決定のスピードが劇的に向上します。

---

4. 【意思決定】行う内容が不確定な場合は「上司に聞く」。勝手な妄想でコードを書かない

🚨 アンチパターン：親切心のつもりの「超能力実装」

• 「仕様書にここが空欄だけど、きっとこういう仕様に違いない」
• 「ユーザーの使い勝手を考えたら、頼まれていないけどこの機能も勝手につけておこう」
• 「上司やデザイナーは忙しそうだから、わざわざ聞かずに自分の判断で進めてしまおう」

これらは一見、自主性がある良い行動のように思えるかもしれません。しかし、ビジネス開発においては最も避けたい落とし穴の一つです。

エンジニアが「勝手な想像（妄想）」で埋めた仕様は、高確率でビジネスサイドや顧客が意図していたものとズレます。結果として、苦労して書いた数千行のコードが、コードレビューや受け入れテストの段階で「そんな仕様じゃない」と一蹴され、すべてドブに捨てることになる（手戻りが発生する）のです。自分の時間を無駄にするだけでなく、プロジェクト全体の工数を圧迫します。

💡 ベストプラクティス：「仕様の隙間」を見つけたら即座に言語化して確認する

優れたエンジニアは、コードを書き始める前に「仕様の矛盾や、考慮漏れ（エッジケース）」を脳内でシミュレーションして発見する能力に長けています。技術的な不整合を見つけた瞬間にテキスト化し、ステークホルダーに確認を取ります。

確認時のテンプレート

【相談】ユーザー登録時の住所入力のバリデーションについて

現在の仕様書では「住所は必須入力」となっていますが、国外のユーザーが登録する際、郵便番号の桁数や形式のチェックをどうすべきか記載がありませんでした。

つきましては、以下のいずれの方針で進めるべきか、ご意見をいただけますでしょうか？

• 案A： 国内ユーザー限定と割り切り、日本の郵便番号形式（7桁）のみバリデーションをかける
• 案B： 将来的な海外展開を見据え、郵便番号の形式チェックは行わず、任意の文字列を入力可能とする（推奨）

このように、「仕様の考慮漏れを発見したこと」を伝え、かつ「選択肢（オプション）」を用意して上司に選んでもらうのが、手戻りをゼロにする最強の仕事術です。「不確定な要素を抱えたままキーボードを叩かない」を徹底してください。

---

5. 【品質担保】テストの極意。「動いた」はただのスタートライン。考えうるパターンを網羅し、正確に行う

🚨 アンチパターン：ハッピーパス（正常系）の呪い

• 「自分で画面をポチポチ触って、1回正常に動いたからテスト完了！」
• 「ユーザーが普通に使っていればエラーは起きないから大丈夫」
• 「テスト手順書を作るのが面倒だから、頭の中の感覚だけでなんとなくテストする」

開発環境で自分の思い通りに操作して動いた状態、これを私たちは「ハッピーパス（正常系）」と呼びます。しかし、本番環境にシステムをリリースした瞬間、あなたのシステムは数千、数万人の「開発者が想定もしなかった操作をするユーザー」に晒されます。

文字入力欄に1文字も入れずに送信ボタンを連打する人、10MBもの巨大な画像をアップロードしようとする人、スマートフォンの通信が途切れた瞬間に決済ボタンを押した人。

正常系しかテストしていないシステムは、こうした現実世界の荒波に揉まれると、一瞬でエラーログの山を築き、サービス停止やデータ整合性の破損に追い込まれます。

💡 ベストプラクティス：悪意あるユーザーの視点で、徹底的に「境界値」と「異常系」を叩く

テストの本質は、「正しく動くことを証明すること」ではなく、「まだ潜んでいるバグを、リリース前に見つけ出して徹底的に破壊すること」です。

1. 「境界値（エッジケース）」を網羅する

バグは常に「境界」に潜みます。

• 「10文字まで入力可能」という仕様であれば、テストすべき値は以下の通りです。
  • 9文字（正常系の最大値に近い値）
  • 10文字（境界のジャスト値）
  • 11文字（エラーになるべき値）
  • 0文字（未入力・空文字）
  • null や undefined（データそのものが存在しない状態）

2. 「異常系・準正常系」を意図的に作り出す

• 必須項目を全て空にして送信ボタンを押したら、適切なエラーメッセージが出るか？
• メールアドレスの入力欄に test@example（ドメインのドットがない）を入れたら弾かれるか？
• 数値を入力すべき場所に、絵文字や全角文字、SQLインジェクションを狙ったような特殊文字（' OR '1'='1）を入れたらどうなるか？

3. テストは「手順書」に従って、機械的に、正確に行う

「脳内テスト」は絶対に抜け漏れが発生します。
面倒に見えても、事前に「テストケース一覧（スプレッドシートやNotion等）」を作成してください。

• 確認内容： 「パスワードが8文字未満の場合、エラーメッセージが表示されること」
• 確認手順： 「1. ログイン画面を開く / 2. パスワード欄に '12345' と入力する / 3. 送信ボタンを押す」
• 期待される結果： 「『パスワードは8文字以上で入力してください』と赤文字で表示されること」
• 実際の結果： OK / NG

この手順を、自分の「思い込み（動くだろうという期待）」を完全に排除し、書かれている手順通りに機械のように正確に実行する。この泥臭いプロセスの積み重ねだけが、システムの高い品質を担保します。

---

まとめ：技術力とは「コードの美しさ」ではなく「不確実性を制御する力」である

エンジニアの「技術力」という言葉を聞くと、最新のトレンド技術を追うこと、洗練された複雑なアーキテクチャを組むこと、あるいは極限まで短いワンライナーを書くことを想像しがちです。

しかし、商業開発、チーム開発における本当の技術力とは、「システム開発に付きまとう『不確実性』や『人間のミス』を、仕組みと行動規範によって徹底的にコントロールする力」に他なりません。

1. バックアップを必ず取る（人間のミスをカバーする仕組み）
2. 背景をコメントに残す（未来のチームの認知負荷を下げる優しさ）
3. 悪い報告ほど早く報連相する（プロジェクトのリスクを最小化するコミュニケーション）
4. 不確定なら上司やステークホルダーに聞く (勝手な妄想による手戻りの排除)
5. テストケースを網羅し、正確に行う（システムの品質に対する執着心）

これらはどれも、今日、この瞬間から実践できるものばかりです。しかし、この5つを完璧に、毎日、どんなに納期に追われて忙しい時でも徹底し続けられるエンジニアは、驚くほど一握りしかいません。だからこそ、これを愚直にやり抜くエンジニアは、チームから、そして市場から圧倒的に評価されます。

「コードが書けるだけのエンジニア」を卒業し、「チームに、ビジネスに、絶対に欠かせない信頼されるエンジニア」への一歩を、ぜひ今日の凡事徹底から踏み出してみてください。

---

最後までお読みいただき、ありがとうございました。
もしこの記事が「ためになった」「耳が痛いけれど本当に大切だ」と感じていただけましたら、ぜひいいね、フォロー、お願いいたします！あなたの現場での「凡事徹底エピソード」や「やらかし談」も、ぜひコメント欄で教えてください。