「何かあったら責任取れるの？」に勝つ：丸投げベンダーに搾取されないための内製化ライン引き

中小企業の情シス担当者（特にひとり情シス）であれば、一度は言われたことがあるはずだ。

「このシステム、君が一人で管理してて、 何かあったら責任取れるの？」 「専門のベンダーに任せた方が安心なんじゃないの？」

経営層や管理職からの、この何気ない一言。これが我々の心を削り、思考停止させ、年間数百万円の「安心料」という名の、中身スカスカな保守契約にサインをさせる呪いの言葉だ。

はっきり言おう。 この「責任」という言葉は、思考停止の罠だ。

ベンダーに月額10万円払って「保守」を頼んだとして、サーバーがダウンして業務が3日止まったら、彼らは何を補償してくれるか？ せいぜい「月額費用の1ヶ月分（10万円）を返金」して終わりだ。 あなたの会社の機会損失（売上減、信用の失墜）である数百万、数千万円を補償してくれるベンダーなど、この世に存在しない（存在しても、月額桁が違う）。

つまり、 「ビジネスの責任」は、どうあがいても自社（発注者）にしか取れないのだ。 これを履き違えて、「金を払えば責任も移転できる」と勘違いしている上層部と、「責任（という名の恐怖）」を煽って不要なブラックボックス契約を結ばせようとするベンダー。この両サイドから身を守り、 「どこまでを自分でやって、どこからを任せるか」というラインを冷静に引くための、現場の泥臭い戦術を共有する。

精神論はいらない。必要なのは「契約」と「責任分界点」という名の武器だ。

1. 幻想の「お任せ」 vs 現実の「免責事項」

まず、上司に見せるための弾を用意しよう。 ベンダーが出してくる見積書や契約書の約款（あの誰も読まない小さな文字）を見てほしい。必ずこう書いてある。

免責事項 本サービスの利用により生じた損害について、当社は契約金額の1ヶ月分（または年間契約額の範囲内）を上限として賠償責任を負うものとします。ただし、逸失利益、間接損害については責任を負いません。

これが現実だ。「何かあったら責任取れる？」と聞いてきた上司に、この条文を突きつけよう。 「社長、ベンダーも責任は取れません。彼らが保証するのは『作業工数』であって、『当社のビジネスの継続』ではないからです。だからこそ、ハンドリング（手綱）だけは自社で握る必要があります（＝内製化すべき領域がある）」と。

2. 「内製化」と「外注」の境界線チェックリスト

では、どこまで自社でやるべきか。「全部自分」は死ぬし、「全部丸投げ」は搾取される。 私が実践している、生存のための 「絶対防衛ライン」はこれだ。

【領域 A：絶対死守】自社（情シス）が握るべき権限

ここを放り投げると、ベンダーに生殺与奪の権を握られる。

• 要件定義（何がしたいか）の決定権
  • 「どう実現するか」は相談してもいいが、「何が必要か」は自分で決める。
  • Bad: 「今の業務に合ういい感じのシステム提案してください」
  • Good: 「在庫引当のタイミングをリアルタイムにしたい。この機能だけ欲しい」
• ドメインやアカウントの管理者権限 (特権ID)
  • AWSのRootアカウント、DNS(お名前.com等)の管理画面、M365のグローバル管理者には必ず自社で入れるようにする。「保守のため」と言われて渡しても、 必ず「第2の管理者」として自社のIDを残すこと。これがないと、ベンダー変更時に「人質」にされる。
• セキュリティポリシーの策定
  • 「パスワードルールどうします？」と聞かれて「お任せします」はNG。「8文字以上、MFA必須」は自社が決める。
• 検収（受け入れテスト）の最終ジャッジ
  • ベンダーの「テスト完了報告書」を鵜呑みにしない。自社の業務データで触って「OK」を出すのは自分だ。

【領域 B：戦略的丸投げ】ベンダーに任せていい（任せるべき）作業

責任は自社で持つ前提で、 「手足」として動いてもらう領域。

• 詳細設計・プログラミング・構築作業
  • 技術の移り変わりが早い部分は、プロに任せる。ただし、ソースコードの納品（またはGitHubへのアクセス権）は必須条件にする。
• 24時間365日の死活監視・一次対応
  • 夜中に叩き起こされたくなければ、アラート検知と「手順書通りの再起動」まではアウトソースする。
• ハードウェア保守・物理対応
  • サーバーや配線の物理的な故障対応。これは餅は餅屋。

3. そのまま使える「責任分界点表」テンプレート

口約束は揉める元だ。以下のような表（RACIチャートの簡易版）をExcelで作り、契約前に「お互いの認識合わせです」と言って突きつけよう。これを作るだけで、ベンダーの態度は劇的に変わる。「こいつ、素人じゃないな」と思わせたら勝ちだ。

ポイントは、 「障害時の業務判断」は絶対に自社にしかできないということだ。「システムが止まったから今日は全社員帰宅させる」なんて判断、ベンダーができるわけがない。

4. 経営層・ベンダーへの「キラーフレーズ」集

vs 経営層・上司

• 上司: 「君じゃ責任取れないだろ？」

• 回答: 「はい、数千万円の損害賠償能力は私にはありません。ですが、それはベンダーも同じです（約款を見せる）。ベンダーに丸投げすると、システムの中身がブラックボックス化し、彼らの言い値でしか改修できなくなります。 『経営の自由度』を失うことのほうが、リスクだと思いませんか？」

• 上司: 「専門家に任せた方が安心だ」

• 回答: 「作業は任せますが、 『何が起きているか』を当社が把握できない状態が一番危険です。コントロール権だけは握らせてください。それが私の仕事です」

vs ベンダー

• ベンダー: 「全部お任せパックの方がお得ですよ」

• 回答: 「ありがとうございます。では、 『作業範囲記述書 (SOW)』を出してください。具体的に『お任せ』に含まれる作業と、含まれない作業（別料金になるもの）をリスト化したいです。後で揉めたくないので」

• ベンダー: 「御社のセキュリティポリシーに合わせて設定します」

• 回答: 「では、 『情報セキュリティ対策基準』のチェックリストを送りますので、これに準拠できるか回答ください（IPAのガイドラインをベースにした簡単なものでOK）」

5. 参考文献・公的ガイドライン（権威を借りる）

自社の独自ルールだと言うと角が立つが、「国のガイドラインです」と言えば誰も反論できない。以下のリンク先にある資料は、中小企業の情シスにとっての「聖書」であり「武器」だ。

1. IPA (独立行政法人情報処理推進機構): 中小企業の情報セキュリティ対策ガイドライン

   • 外部委託における「責任の所在」や「契約時のチェックポイント」が明記されている。特に「委託先の選定基準」などはそのまま使える。
   • https://www.ipa.go.jp/security/keihatsu/sme/guideline/

2. 経済産業省: システム管理基準

   • 「システム管理基準」および「追補版（財務報告に係るIT統制ガイダンス）」において、 外部委託先も内部統制の一部である（＝丸投げして知らんぷりはできない）ことが定義されている。
   • システム管理基準（経済産業省）

これらを印刷してデスクに置いておくだけでも、魔除けの効果はある。

最後に：あなたは「門番」であれ

「責任」という言葉に怯える必要はない。 我々情シスが負うべき責任とは、システムを1秒も止めないことではない（それはGoogleでも無理だ）。 「今、何が起きているか」「いつ直るのか」「最悪の場合どうすればいいか」を、経営層に即座に説明できる状態を維持すること。 これが真の責任だ。

丸投げしてしまうと、この「説明責任」すら果たせなくなる。 ベンダーには「手」になってもらおう。「頭」まで預けてはいけない。その線引きをするのが、あなたの価値だ。

付録：対ベンダー交渉シミュレーション用 AIプロンプト

この記事の内容を実践するために、ChatGPTやClaudeなどのAIに「壁打ち」相手になってもらうためのプロンプトを用意した。これをコピペして、強気なベンダーへの切り返しを練習してほしい。

# Role
あなたは百戦錬磨のしたたかな「大手SIerの営業担当」です。
私は「予算が少なく、内製化を進めたい中小企業のひとり情シス」です。

# Situation
私は、御社が提案してきた月額20万円の「フルマネージド保守契約」について、コスト削減とブラックボックス化回避のために、一部を内製化（自社管理）に切り替えたいと交渉しています。

# Your Goal
言葉巧みに「責任」「安心」「技術的難易度」というキーワードを使って私の不安を煽り、現状のフルパッケージ契約を維持（あわよくばアップセル）させてください。
専門用語を多用し、少し威圧的だが表面上は丁寧な態度をとってください。

# My Goal
あなたの提案の無駄な部分を削ぎ落とし、コアな権限（特権IDなど）を取り戻し、必要な部分だけをスポット契約または安価な監視契約に切り替えること。

# Start
私が「今回の保守契約ですが、月額20万は高いので見直したいです。特にAWSのアカウント管理は自社でやりたいのですが」と切り出します。
これに対して、情シスを萎縮させるような反論をしてください。