ITシステム原因調査の外注では、調査する症状と環境、提出してほしい根拠、修復作業を含む範囲を先に決めます。「原因を特定する」だけの依頼では、途中の追加調査や、結論が出ない場合の扱いが曖昧になります。
発注前の資料準備から委託先選定、調査中の承認、報告書の検収までを説明します。障害対応中の場合は、事業への影響を抑える対応と、原因を検証する作業を分けて進めましょう。
発注前に症状と調査可能な情報を整理する
症状・影響・時系列を一枚にまとめる
最初の依頼には、発生時刻、対象機能、影響を受けた利用者、期待していた動作、実際の動作を記載します。画面のエラー表示だけでなく、正常に動いていた時点も調べておきます。
例えば「夜間処理が失敗する」なら、毎日なのか特定日だけなのか、処理全体が止まるのか一部のデータだけなのかを分けます。確かでない部分は推測で埋めず、未確認として示します。
調査資料は、次の三つに分けると引き継ぎやすくなります。
- 確認済み事実：時刻、影響範囲、再現手順、観測したログを記載します。
- 変更履歴：リリース、設定変更、データ量の増減、外部サービス変更を並べます。
- 調査上の制約：ログ不足、接続できない環境、停止できない処理を明示します。
元データを保全してから共有する
調査に必要なログが保存期限で消える場合があります。まず対象期間と保管担当を確認し、取得元、取得時刻、対象環境が追える状態で保存します。
委託先には必要な範囲を共有し、原本と加工済みの共有資料を区別します。個人情報や秘密情報を伏せた際は、調査に使えなくなった項目がないかを確認してください。
調査と修復を分けて見積もりを依頼する
最初の調査範囲を限定する
調査対象は、システム名、環境、対象期間、症状で指定します。アプリ、データベース、ネットワーク、外部APIなど複数の領域にまたがる場合は、窓口と担当範囲も決めます。
原因が不明な段階で、調査全体の工数を確定できない場合もあります。そのときは、一次切り分けを行って追加調査を見積もるなど、段階を分けた提案を依頼します。
一次調査の終了時に、次の情報を提出してもらいます。
- 確認できた範囲：調べた資料、実施した操作、再現できた条件を示します。
- 残る仮説：否定できた仮説と、まだ検証できていない仮説を分けます。
- 次の判断：追加で必要な権限・資料・費用と、調査継続の選択肢を示します。
暫定対応と恒久修正の境界を定める
調査契約に修正作業が含まれるとは限りません。設定変更、プログラム修正、データ修復、リリース、再発防止テストのどこまでを任せるかを明記します。
障害中の緊急作業については、誰が実行を承認し、どの条件で止めるかを決めます。サービスを戻す必要性と証拠保全を、業務責任者と調査担当者が共有して判断できる体制を用意します。
委託先は調査方法と説明能力で比較する
類似環境の経験を具体的に確認する
使用言語やクラウドが同じでも、バッチ処理、認証、決済、データ同期では必要な調査経験が異なります。自社と似た症状に対して、何を観測し、どの順序で仮説を絞るかを聞きます。
守秘義務に触れる実案件の詳細を求める代わりに、匿名化した報告書や調査手順のサンプルを依頼します。原因が分からなかった場合の説明も確認すると、報告品質を判断しやすくなります。
複数ベンダーの調整役を決める
アプリ会社、基盤会社、外部サービス会社が別々の場合、全員が自社の担当範囲だけを確認して終わるおそれがあります。全体の時系列をまとめ、仮説を横断して検証する責任者を決めます。
選定時は、作業実施者だけでなく、情報をまとめる役割も比較してください。
- 技術担当：再現、ログ解析、設定・コード確認を担当します。
- 調整担当：他社への問い合わせ、権限申請、調査日程をまとめます。
- 判断担当：追加作業と本番変更を承認し、事業側へ状況を伝えます。
提案書の「迅速に対応する」という表現だけで判断せず、連絡頻度、緊急時の窓口、調査できない時間帯、再委託先の扱いを確認します。
調査結果を根拠と再現条件で検収する
報告書は事実・推定・対策を分ける
原因報告に「負荷が高かった」とだけ書かれていても、再発防止を判断できません。どの資源が、どの入力条件で不足し、どの証拠からそう判断したかを確認します。
Google SREの事後検証の解説では、障害の記録と再発防止の学習を重視しています。担当者個人の失敗で説明を終えず、検知や運用の仕組みまで振り返る観点が参考になります。
検収時は、次の内容を報告書で確認します。
- 根拠：ログ、設定差分、再現結果が結論と結び付いています。
- 限界：確認できない環境や不足データが、結論の確かさとともに示されています。
- 対策：暫定対応と恒久対策の担当、期限、効果の確認方法が書かれています。
再現しない場合も調査の成果を確認する
一度だけ起きる障害では、同じ条件を再現できないことがあります。その場合は、試した条件と結果、除外できた原因、次回の発生時に集める記録を残してもらいます。
原因特定を保証する表現だけで契約せず、どの状態を調査の一区切りとするかを合意します。未確定の原因を確定扱いにして、対策の効果を過大評価しないことが重要です。
まとめ
ITシステム原因調査の発注は、症状と資料を整理し、調査範囲と修復範囲を分け、委託先の調査方法を比較する順で進めます。報告書を根拠まで確認できる契約にすることで、その後の修正と再発防止へつなげられます。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。