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