「聞いていない」「言ったはず」——多重下請けのAWS案件で消耗を生むのは、腕ではなく"境界の曖昧さ"です。責任分界・変更管理・エビデンス・スコープ握りという4つの仕組みで"言った言わない"を減らす実務を、二次請けの現場目線で率直にまとめます。

01"言った言わない"は、人ではなく境界が起こす

AWSの案件を二次請けで回していると、炎上の火種はたいてい技術そのものではありません。「聞いていない」「言ったはず」——境界での認識ずれです。設計を担ったのに方式判断は元請けが顧客と握っていた、口頭で受けた変更が後で「指示していない」となる、テストの合否基準が曖昧なまま検収でもめる。どれも、腕の問題ではなく境界の設計不足から来ています。

多重下請けの構造では、情報が顧客 → 元請け → 二次請けと伝言でつながります。伝言は必ず減衰します。顧客が本当に困っている背景、元請けが顧客と交わした細かな約束、途中で変わった前提——それらは層をまたぐたびに少しずつ抜け落ち、二次請けの手元には"結論だけ"が届く。誰が悪いという話ではなく、層をまたぐたびに前提が落ちるのが構造上の宿命です。だからこそ、個人の善意や記憶に頼るのをやめ、境界を"仕組み"で固定するのが唯一の解だと考えています。

多重下請けでは「境界の隙間」で認識がずれる 顧客 要件・データ・最終責任 元請け（一次請け） 全体管理・顧客窓口・承認 二次請け（EMW） 設計・構築・テスト・移行 ⚠ ⚠ 要件/指示→　←成果物/報告 要件/指示→　←成果物/報告 隙間は「気合」ではなく「仕組み」で埋める 責任分界表 誰が・何を・承認は誰 変更管理 承認・PRゲート エビデンス 図/IaC/チケット/議事 スコープ握り 対象外・非機能を数値
図：顧客⇄元請け⇄二次請けの境界（⚠）は情報が伝言でつながるため、認識がずれやすい。隙間は責任分界表・変更管理・エビデンス・スコープ握りという「仕組み」で埋める。
本記事の持論はシンプルです。"言った言わない"は気合や信頼関係で防ぐものではなく、①責任分界表②変更管理③エビデンス④スコープ握り、という4つの仕組みで防ぐ。この4つを最初に置くだけで、後半の消耗戦の大半は起きません。

以下、二次請けの現場目線で、品質と信頼を落とさないための実務を順に整理します。特定の元請けを批判する話は一切ありません。誰がやっても構造的に起きることを、どう仕組みで消すかだけを書きます。

02責任分界を、最初に一枚の紙で握る

最初にやるべきは、「誰が・何を・承認は誰か」を1枚に書くことです。設計・構築・テスト・運用・データ・アカウント権限——このどれもが、放っておくと境界が曖昧になります。曖昧なまま進むと、必ず後半で「そこはそちらの担当だと思っていた」が発生します。

ポイントは「手を動かす人」と「承認・意思決定する人」を分けて書くことです。二次請けは手を動かす側ですが、最終判断は元請けや顧客にあることが多い。ここを混ぜると、判断待ちなのに責任だけ手前に来る、という不健全な状態になります。

領域（何を）主に手を動かす承認・意思決定二次請けが最初に握る境界
設計（方式・構成）二次請け（詳細方式）元請け → 顧客「全体方針の最終決定は誰か」を図と議事で確定する
構築（IaC・リソース）二次請け元請けレビューPRのレビュー担当と本番apply承認者を先に決める
テスト（結合・UAT）二次請け／顧客（UAT）元請け・顧客合否基準と要件トレースを着手前に合意する
運用（監視・障害・変更）運用担当（別会社のことも）元請け・顧客一次対応の範囲・エスカレ先・オンコール時間帯を明記
データ（移行・BK・消失責任）二次請け（移行実装）顧客（データ責任）バックアップ世代／リストア責任／消失時の切り分け手順
アカウント・IAM権限元請け／顧客顧客誰が本番権限を持つか・最小権限・棚卸し頻度
この表は完璧である必要はありません。大事なのは「空欄＝未合意」が可視化されることです。埋まっていないセルこそ、"言った言わない"の予備軍。キックオフで叩き台を出し、埋めながら合意を議事に残すだけで、案件の見通しは一段良くなります。アカウント権限とIDの束ね方は範囲が広いので、マルチ/ハイブリッドクラウドを「ID」で束ねる考え方もあわせて設計します。
現場のコツ：理想は元請け主導で作ることですが、決まっていなければ二次請けから叩き台を出して構いません。「勝手に線を引く」のではなく「認識合わせのために可視化する」というスタンスなら、角は立ちません。むしろ最初に整理してくれる二次請けは、元請けからの信頼を得やすい。

03変更管理を、性善説ではなく仕組みにする

責任分界を固めても、案件は動きながら変わります。ここで効くのが変更管理です。要点は3つ——誰が承認するか／変更をどう記録するか／破壊的変更をどう扱うか。

① 承認の経路を1本にする。変更依頼が口頭・チャット・メールでバラバラに飛んでくると、必ず取りこぼします。「変更は記録に起こしてから着手」を原則にし、承認者を責任分界表と一致させます。口頭で受けた指示は、その場で復唱し、直後にチケットやメールで「認識合わせ」として文章化して返す。相手を疑うためではなく、双方の記憶違いを防ぐためです。

② IaCならPRをレビューゲートにする。インフラの変更は、Terraform/CloudFormationのPull Requestを唯一の入口にするのが理想です。PRにplan差分・tflint/tfsecの結果・変更理由を載せ、承認者がレビューしてからマージ。こうすると「いつ・誰が・なぜ・何を変えたか」がGitの履歴として自動で残ります。これは最強の"言った言わない"対策です。

③ 破壊的変更は別扱いにする。再作成が走るリソース（データを持つDB、固定IP、ステートフルな要素）の変更は、通常のPRと同じ温度で流してはいけません。IaCは便利な反面、たった1行の差分が既存リソースのdestroy → createを引き起こすことがあります。手作業なら「これ消していいんだっけ？」と一瞬立ち止まる場面を、コードは黙って実行してしまう。だからこそ、破壊的変更は仕組みで検知し、別レーンで扱う必要があります。

IaCのPRゲートは二次請けの立場でも始められます。まず自分たちのリポジトリで「差分と根拠が見えるPR」を出す運用から入る。本番apply権限や最終承認は元請け・顧客の領域なので、そこは責任分界表で握った上で、"レビューできる状態"を二次請け側から提供します。仕組みは、権限を持つ人ではなく、記録を残せる人から始められます。

04"エビデンス"で会話する — 記憶ではなく現物で

境界でもめる会話は、たいてい「記憶 vs 記憶」になっています。これを「現物 vs 現物」に変えるだけで、消耗はほとんど消えます。二次請けが日常的に持つべきエビデンスは4種類です。

この4つが揃っていると、境界の会話は「では議事のどこで合意しましたか」「PRのこの差分です」という形になり、感情論になりません。逆に、どれか一つでも欠けると、そこが"言った言わない"の入口になります。

設計のエビデンスは「厚い設計書」である必要はありません。むしろIaC時代は、コードが実体を語り、設計書は"意図とトレーサビリティ"を担うのが健全です。工程ごとに何を書き何を書かないかは、設計書は何を書き、何を書かないかで整理しています。エビデンスは量ではなく「後から辿れるか」が価値です。
現場のコツ：エビデンスはもめてから集めるのでは遅い。平時に、PRに理由を書く・議事に決定者を書く・チケットに口頭指示を起こす、を習慣化しておく。これは相手への不信ではなく、半年後の自分と後任者への引き継ぎだと考えると続けやすいです。

05スコープと非機能を握る — 曖昧さは炎上の火種

境界の中でも、いちばん燃えやすいのがスコープと非機能要件です。ここが曖昧なまま構築に入ると、後工程で必ず火が出ます。

スコープは「対象外」を明記する。「何をやるか」より「何をやらないか」を書くほうが効きます。移行対象外のシステム、今回は手を付けない領域、別フェーズに送る項目——これを最初に紙で握っておくと、追加依頼が来ても「スコープ外なので変更管理で扱いたい」と建設的に線を引けます。断るのではなく、判断を元請け・顧客に返す形にするのがコツです。

非機能は数値で握る。「止まると困る」「速いほうがいい」は要件ではありません。二次請けとして必ず数値化を求めるべきなのは次のあたりです。

非機能を曖昧にしたまま進めると、検収フェーズで「これでは不十分」と後出しされ、二次請けが割を食いがちです。特に可用性とDRは「Multi-AZだから大丈夫」と設計書に書くだけでは証明になりません。数値で握っておけば、達成の証明も「実際に落として、戻して、RTO/RPOを満たすことを実測で示す」だけで済みます。可用性の数値換算はツールでも補助できます（止まってよい時間の月・年換算など）。
現場のコツ：非機能は設計より前、要件で握るのが理想。ただ二次請けは要件定義に入れないことも多い。その場合は「前提としてこの数値で設計します」とこちらから明文化して確認を取る。相手が数値を持っていないなら、叩き台を出してあげるのが結局いちばん早い。

06二次請けがやるべき"自衛" — 記録は品質の一部

ここまでの仕組みを、二次請けの立場で現実的にどう実践するか。自衛という言葉を使いますが、後ろ向きの保身ではありません。記録を残すことは品質管理そのものであり、結果として信頼を積み上げます。

これらはどれも特別なツールを必要としません。既存のチケット・Git・議事フォーマットの使い方を少し変えるだけです。二次請けは「言われたことをやる人」ではなく、境界を整理して案件を前に進める人——そう振る舞える会社が、次も声をかけてもらえると考えています。

自衛の記録は、元請けとの対立のためではなく共通の現物を作るためにあります。「疑っているのではなく、認識をそろえたい」という言い方を徹底すれば、記録の習慣は関係を悪くするどころか、むしろ信頼の土台になります。仕組みで解決する、とはそういう意味です。

07まとめ — 境界を仕組みで固定する

多重下請けのAWS案件で品質と信頼を落とさない鍵は、腕でも気合でもなく境界の設計です。①責任分界を最初に一枚の紙で握る②変更管理を承認経路とPRゲートで仕組みにする③記憶ではなくエビデンス（構成図・IaC・チケット・議事）で会話する④スコープと非機能を数値と「対象外」で握る。この4つを最初に置くだけで、"言った言わない"の大半は起こりません。

そして二次請けにとって、記録と可視化は保身ではなく品質と信頼の積み上げです。境界を整理して案件を前に進める会社は、構造的な伝言ゲームの中でも消耗せずに立てます。

EMWは札幌のAWSコンサルで、SIerの二次請けとして設計から構築・テスト・移行まで実務で回してきました。責任分界表の型づくり、変更管理・PRゲートの設計、エビデンス運用の整備を、御社の案件体制に合わせて一緒に整えます。関連して設計書は何を書き、何を書かないか、マルチ/ハイブリッドクラウドを「ID」で束ねる考え方もどうぞ。

08よくある質問（FAQ）

責任分界表はいつ、誰が作るべきですか？

キックオフ直後、遅くとも設計着手前に作ります。理想は元請け主導ですが、決まっていなければ二次請けから叩き台を出して構いません。設計・構築・テスト・運用・データ・アカウント権限の各領域で「手を動かす人」「承認する人」を1枚に書き、元請けと顧客の合意を議事に残せば、以降の"言った言わない"は大きく減ります。

元請けから口頭で仕様変更を指示されました。どう扱えばよいですか？

口頭指示はその場で復唱し、直後に「認識合わせ」としてチケットやメールで文章化し返信するのが安全です。相手を疑うためではなく、双方の記憶違いを防ぐためです。破壊的変更や非機能に影響する変更なら、影響範囲を添えて承認を仰ぐ。仕組みとして「変更は記録に起こしてから着手」を徹底すれば、角を立てずに自衛できます。

IaCのPRゲートは二次請けの立場でも導入できますか？

できます。まず自分たちのリポジトリでplan結果・tflint/tfsec・レビュー観点をPRに残す運用から始めるのが現実的です。承認者の指定や本番apply権限は元請け・顧客の領域なので、そこは責任分界表で握った上で、レビュー可能な状態（差分と根拠が見える形）を二次請け側から提供します。

スコープ外の作業を頼まれたとき、どう線を引けばよいですか？

まず「今回のスコープはここまで」と最初に紙で握っておくことが前提です。その上で追加依頼が来たら、断るのではなく「スコープ外なので変更管理として扱いたい」と提案します。工数と影響を可視化し、判断を元請け・顧客に返す。線引きは人間関係ではなく、合意済みのスコープ定義と変更管理プロセスにさせるのがコツです。

責任分界表の型づくり、変更管理・PRゲートの設計、エビデンス運用の整備でお困りなら、御社の案件体制に合わせて一緒に整えます。"言った言わない"を仕組みで減らしましょう。

相談する
← ブログ一覧へ戻る