https://tech.feature-branch.co.jp/tags/%E5%93%81%E8%B3%AA%E7%AE%A1%E7%90%86/Recent content in 品質管理 on Feature Branch Tech BlogHugojaFeature Branch inc.Mon, 06 Jul 2026 18:48:25 +0900https://tech.feature-branch.co.jp/posts/2026/05/whys-technique/Wed, 06 May 2026 00:00:00 +0900https://tech.feature-branch.co.jp/posts/2026/05/whys-technique/<h1 id="なぜなぜ分析5-whysで本当の原因を見つける">なぜなぜ分析（5 Whys）で本当の原因を見つける</h1> <h2 id="はじめに">はじめに</h2> <ul> <li>バグを修正したはずなのに、似たような問題がまた発生する</li> <li>障害対応をしたのに、数週間後に同じようなインシデントが起きる</li> <li>「原因は分かった」と思っても、実は症状しか見ていなかった</li> </ul> <p>そんな経験はないでしょうか。</p> <p>開発現場では「問題を直す」ことに意識が向きがちですが、本当に重要なのは「なぜその問題が起きたのか」を深掘りすることです。</p> <p>そのために役立つのが、トヨタ生産方式でも使われている <strong>5 Whys（なぜなぜ分析）</strong> です。</p> <p>単純ですが非常に強力で、障害分析・品質改善・振り返りなど、ソフトウェア開発とも相性が良い考え方です。</p> <p><img src="image.png" alt="alt text"></p> <hr> <h1 id="1-5-whysなぜなぜ分析とは">1. 5 Whys（なぜなぜ分析）とは？</h1> <ul> <li>問題に対して「なぜ？」を繰り返し問い続けることで、根本原因を見つける分析手法</li> <li>表面的な現象ではなく、背後にある「仕組み」や「プロセス」の問題を明らかにする</li> <li>一般的には5回程度「なぜ」を繰り返すことで本質に近づけると言われている</li> </ul> <h2 id="ポイント">ポイント</h2> <ul> <li>「誰が悪いか」ではなく「なぜ防げなかったか」を考える</li> <li>個人のミスで終わらせず、再発防止につながる仕組み改善へ繋げる</li> <li>バグ修正よりも“同じ問題を繰り返さない”ことを目的にする</li> </ul> <hr> <h1 id="2-なぜ開発で重要なのか">2. なぜ開発で重要なのか？</h1> <h2 id="同じ種類の障害を繰り返さなくなる">同じ種類の障害を繰り返さなくなる</h2> <ul> <li>一時的な修正だけでは、似た問題が別の場所で再発する</li> <li>根本原因まで辿ることで、構造的な改善ができる</li> </ul> <h2 id="チームの品質改善につながる">チームの品質改善につながる</h2> <ul> <li>コーディングルール</li> <li>レビュー体制</li> <li>テスト不足</li> <li>ドキュメント不足</li> </ul> <p>など、開発プロセス全体の問題が見えてくる</p> <h2 id="属人化を減らせる">属人化を減らせる</h2> <p>「〇〇さんしか分からない」 「たまたま気付けなかった」</p> <p>ではなく、</p> <ul> <li>なぜ誰でも気付けなかったのか？</li> <li>なぜ仕組みで防げなかったのか？</li> </ul> <p>を考えるようになる</p> <hr> <h1 id="3-実際の例障害対応">3. 実際の例（障害対応）</h1> <p><img src="image-1.png" alt="alt text"></p> <h2 id="問題">問題</h2> <blockquote> <p>本番デプロイ後、サービスが2時間停止した</p> </blockquote> <table> <thead> <tr> <th>段階</th> <th>なぜ？</th> <th>回答</th> </tr> </thead> <tbody> <tr> <td>Why 1</td> <td>なぜサービス停止した？</td> <td>デプロイスクリプトが途中で失敗した</td> </tr> <tr> <td>Why 2</td> <td>なぜ失敗した？</td> <td>本番環境に必要な環境変数が存在しなかった</td> </tr> <tr> <td>Why 3</td> <td>なぜ環境変数が無かった？</td> <td>ローカルだけ追加されCI/CDへ反映されていなかった</td> </tr> <tr> <td>Why 4</td> <td>なぜCI/CDへ反映漏れした？</td> <td>追加時の確認手順が存在しなかった</td> </tr> <tr> <td>Why 5</td> <td>なぜ確認手順が無い？</td> <td>デプロイチェックリスト自体が整備されていなかった</td> </tr> </tbody> </table> <h2 id="根本原因">根本原因</h2> <ul> <li>環境変数漏れではなく</li> <li>「デプロイ前確認プロセスが存在しない」ことが問題だった</li> </ul> <h2 id="対策">対策</h2> <ul> <li>デプロイチェックリスト作成</li> <li>CI/CDで環境変数差分チェック</li> <li>Pull Requestテンプレートへ確認項目追加</li> </ul> <hr> <h1 id="4-salesforce開発での例">4. Salesforce開発での例</h1> <h2 id="問題-1">問題</h2> <blockquote> <p>Trigger実行時にGovernor Limit Errorが発生した</p>https://tech.feature-branch.co.jp/posts/2026/01/operation-maintenance-mindset/Tue, 06 Jan 2026 00:00:00 +0900https://tech.feature-branch.co.jp/posts/2026/01/operation-maintenance-mindset/<h2 id="はじめに">はじめに</h2> <p>システムの運用保守は、サービスの安定稼働を支える重要な仕事です。お客様からの問い合わせ対応、障害対応、改修作業など、日々さまざまなタスクが発生します。</p> <p>この記事では、新卒2年目の私が運用保守の現場で意識している5つのポイントと、これから取り組みたいことをまとめました。運用保守に携わる方や、これから運用保守を経験する方の参考になれば幸いです。</p> <p><img src="./images/01_Operation_and_maintenance_site.png" alt="運用保守の現場"></p> <hr> <h2 id="私のキャリア">私のキャリア</h2> <p>2024年4月に新卒としてIT業界でキャリアをスタートし、研修を経て7月から現在のプロジェクトに参加しました。当初はテストや手順書作成を担当し、2025年10月から本格的に運用保守をメインで担当するようになりました。</p> <hr> <h2 id="運用保守の4つの主要業務">運用保守の4つの主要業務</h2> <p>現在、私が担当している運用保守業務は大きく4つに分類されます。</p> <table> <thead> <tr> <th>業務分類</th> <th>内容</th> <th>頻度</th> </tr> </thead> <tbody> <tr> <td>仕様確認</td> <td>お客様からの機能仕様や操作方法に関する問い合わせ対応</td> <td>随時</td> </tr> <tr> <td>障害対応</td> <td>不具合発生時の原因調査と報告</td> <td>随時</td> </tr> <tr> <td>改修対応</td> <td>不具合修正や既存機能拡充の工数見積・実施</td> <td>随時</td> </tr> <tr> <td>運用作業</td> <td>週次バックアップデータ共有、システムの稼働状況の確認、運用報告書作成などの定型業務</td> <td>定期</td> </tr> </tbody> </table> <p>これらの業務を通じて、システムの安定稼働を維持しています。</p> <p><img src="./images/02_Main_operations_and_maintenance_tasks.png" alt="運用保守の主要業務"></p> <hr> <h2 id="1-慣れた作業こそ慎重にダブルチェックの重要性">1. 慣れた作業こそ慎重に(ダブルチェックの重要性)</h2> <h3 id="なぜ慎重さが必要か">なぜ慎重さが必要か</h3> <p>運用保守では、同じ作業を繰り返すことが多くあります。例えば、開発環境から本番環境へのリリース作業は、私が担当することが多く、手順も熟知しています。</p> <p>しかし、<strong>慣れた作業ほどミスが起きやすい</strong>というのが現実です。</p> <p>実際、Sandbox環境でのリリース作業において、リリース前後に実施すべき作業を見落としたことがありました。この経験から、以下の2つを徹底するようにしています。</p> <h3 id="実践している対策">実践している対策</h3> <p><strong>1回目のチェック</strong>: 手順書を1ステップずつ確認しながら作業を進める</p> <p><strong>2回目のチェック</strong>: 作業完了後、少し時間を置いてから手順書と環境を再確認し、抜け漏れがないかをチェックする</p> <p>この「少し時間を置く」というのがポイントです。作業直後は「やったつもり」になっていることがあるため、頭をリセットしてから確認することで、見落としを防げます。</p> <p><img src="./images/03_Double_Check.png" alt="ダブルチェックの重要性"></p> <hr> <h2 id="2-本番環境では何も試さない事前検証の徹底">2. 本番環境では何も試さない(事前検証の徹底)</h2> <h3 id="本番環境は実験場ではない">本番環境は「実験場」ではない</h3> <p>本番環境でのデータメンテナンスやスクリプト実行は、事前に必ず検証環境(SandboxやSO環境)で動作確認を行います。</p> <p>これは当たり前のことのように思えますが、<strong>時間がないときほど「これくらいなら大丈夫だろう」という油断が生まれやすい</strong>ものです。</p> <h3 id="検証の手順">検証の手順</h3> <p>本番環境で実行する前に、以下のステップを踏みます。</p> <ol> <li><strong>Sandbox環境で同様のデータを準備</strong></li> <li><strong>スクリプトを実行し、想定通りの結果が得られるか確認</strong></li> <li><strong>副作用(意図しない変更)がないかチェック</strong></li> <li><strong>問題なければ本番環境で実行</strong></li> </ol> <p>このプロセスを省略すると、取り返しのつかない事態を招く可能性があります。運用保守の基本は「予防」であり、問題が起きてから対処するのではなく、問題を起こさないための準備が重要です。</p> <p><img src="./images/05_Problems_are_quickly_shared.png" alt="検証環境での事前確認"></p> <hr> <h2 id="3-障害は迅速に共有するスピード重視のコミュニケーション">3. 障害は迅速に共有する(スピード重視のコミュニケーション)</h2> <h3 id="障害検知から報告までの流れ">障害検知から報告までの流れ</h3> <p>本番環境でエラーが発生すると、Slackにエラー通知が届きます。通知を受け取ったら、以下の手順で対応します。</p> <ol> <li><strong>エラー内容を確認</strong></li> <li><strong>Sandbox環境で再現できるか検証</strong></li> <li><strong>原因と影響範囲を調査</strong></li> <li><strong>調査結果・原因・改善策をお客様に報告</strong></li> <li><strong>暫定対策がある場合は併せて共有</strong></li> </ol> <p>ここで重要なのは、<strong>完璧な報告を待たずに、まず現状を共有する</strong>ことです。</p> <p>調査に時間がかかる場合は、「現在調査中です。〇〇時までに続報を共有します」といった中間報告を入れることで、お客様に安心感を与えられます。</p> <p><img src="./images/04_Verification_environment.png" alt="障害は迅速に共有する"></p> <hr> <h2 id="4-チームとの情報共有を怠らないリスク予防">4. チームとの情報共有を怠らない(リスク予防)</h2> <h3 id="なぜリーダーに共有するのか">なぜリーダーに共有するのか</h3> <p>お客様とのやり取りで、改修の依頼があった場合、たとえ小さな変更でもリーダーに共有するようにしています。</p> <p><strong>共有する理由</strong>:</p> <ul> <li>私が気づいていない技術的な問題があるかもしれない</li> <li>他の機能への影響を見落としている可能性がある</li> <li>過去に同様の要望があり、別の解決策が検討されたかもしれない</li> </ul> <p>「こんな小さなこと、わざわざ報告しなくても…」と思うこともありますが、<strong>報告しなかったことで問題が起きるリスク</strong>を考えれば、共有する手間は惜しむべきではありません。</p>