結論
DX（デジタル化）が失速するとき、表面には「引き継げない」「担当者しか触れない」「修正が怖い」が出てきます。
でも、炎上の芯は技術力そのものよりも、誰が・どこまで・何を守るか（責任の境界）が決まっていないことが多いです。
境界がないと、開発側は「動くもの」を抱え込み、利用側は「自分が悪い」と感じて相談できなくなります。
その結果、困っている人同士がぶつかり、プロジェクトが荒れます。
立て直しは、作業／成果物／判断を分けて境界を宣言し、
成功条件・保守ルール・相談の入口を先に置くこと。
そして、当事者の感情を「構造」に戻せるシママのような視点が不可欠です。
導入：大炎上は「正しさ」ではなく「困ってる」から始まる
ある日、運用の現場でトラブルが続きました。
画面の挙動が想定と違う。エラーが出る。どこを直せばいいか分からない。
しかも、期限が近い。
こういうとき、悪いのは「誰か」だと決めたくなります。
でも実際には、みんな困っています。
ただ困り方が違うだけで、同じ場所でぶつかってしまう。
ディープル、ちょっとさ……。
これ、止まってるよね？ もう何回目？
なんで毎回「分かりません」で戻ってくるの。
……ごめんなさい。
分からない、というより……怖くて。
どこを触ったら壊れるか分からなくて……。
怖いのは分かる。でも、止まってるのも事実だよ。
こっちは現場に説明しなきゃいけない。
「誰が直せるの？」って聞かれて、答えられないの、つらい。
わたしが……もっと分かれば、答えられるのに……。
ちゃんとできていないのは、わたしのせいで……。
いや、それは違うたい。ここは俺の責任たい。
俺が作った仕組みが、他の人が触れる形になっとらんかった。
まず俺が受け止める。
じゃあ、どうするの。
「ストークしか直せない」って状態のまま、また次の修正が来るの？
それって……詰むよ。
ごめんなさい……ごめんなさい……。
わたしが弱いから……わたしが迷惑を……。
……え。ちがう、そうじゃなくて……。
（ごめん、言い方……）……。
いったん止める。いまは、誰も責めない。
これは「性格」じゃなくて、設計の問題。
ここから先は、私が整理する。マネージャの仕事だから。
ここで起きているのは、ファビーもディープルも「サイロ化」という言葉を知らないまま、
ただ困っていることだけを抱えて、互いに刺さってしまう状況です。
ディープルは「仕組みが保守しづらい」とは言えません。
代わりに「自分が悪い」に落ちてしまう。
その瞬間、議論は止まり、炎上だけが残ります。
崩れ方：DXが失速するときに起きる「境界の崩壊」
仕組みが「触れる人が限られる」状態になると、現場は不安になります。
でも多くの場合、現場は技術の良し悪しを言語化できません。
代わりに出てくるのは、次の3つです。
① 何が成功か分からないまま、作業だけ増える
「入力」「集計」「帳票」「修正」など、作業は増えます。
でも成果物の定義が「動く」止まりだと、運用と引き継ぎが置き去りになります。
DXの成果物は本来、「誰が見ても同じ判断ができる」「手順が再現できる」「ログが追える」まで含みます。
ここが合意されないと、動いてもチームは弱くなります。
② 相談の入口がなくて、自己責任化が進む
ディープルのようなタイプは、困っても「聞いていいのか」を先に考えます。
入口が曖昧だと、「自分が悪い」に落ちて相談が遅れます。
相談が遅れるほど、開発者は自分で吸収しやすくなり、さらに入口が消えます。
こうして「触れない仕組み」が完成します。
③ 判断の境界がないまま、責任だけ増える
「例外はどうする」「優先順位は」「止める条件は」。
これが決まらないまま期限が迫ると、開発者が現場判断で吸収し続けます。
結果、属人化します。
俺、期限を守ることばっかり考えて、
「動く」までで出してしまったたい。
でも結果、俺しか触れん形になっとった。そこは俺の落ち度たい。
落ち度は個人の能力じゃなくて、「成果物の定義」が足りなかったこと。
そして、その定義を最初に置かなかったのはマネージャの責任でもある。
いまから、成果物を「運用と引き継ぎ」まで含めて作り直そう。
……わたし、壊したら怖いって思ってしまって。
それで固まってしまいました……。
それは自然だよ。壊れる可能性があるのに、境界も手順もないんだもん。
だから、まず「壊していい場所」と「壊したら戻せる方法」を成果物に入れる。
あなたが怖がらなくていい設計にする。
立て直しの基本：作業／成果物／判断を分ける
ここからの立て直しは、技術の前に「境界」を置きます。
同じ「作る」でも、任せる粒度が違うと必要な情報が違います。
- 作業：実装／設定／テスト／データ整形／手順書更新
- 成果物：運用手順／引き継ぎ手順／設定一覧／ログの見方／復旧手順（戻し方）
- 判断：例外の扱い／変更優先順位／リリース条件／停止・切り戻し条件
「成果物」に運用と引き継ぎを含める。
これが決まるだけで、「触れない」状態はほどけていきます。
テンプレ：サイロ化を止める「運用・引き継ぎ」合意文
炎上後の立て直しで効くのは、「誰が悪いか」ではなく「何を成果物に含めるか」の合意です。
チャットに貼れる形で、1つだけ置きます。
【成果物の定義】「動く」だけでなく（運用手順／引き継ぎ手順／設定一覧／ログの見方／復旧手順）まで含める。
【粒度】今回の対象を「作業／成果物／判断」に分け、誰が持つか決める。
【成功条件】（誰が見ても同じ判断ができる状態）＝（ ）。
【相談の入口】迷ったら（条件）で（相談先）へ。相談は「迷惑」ではなく工程。
【境界】（ここまでは開発者判断／ここからはマネージャ判断）。
【締切】（いつまでに何を）を明確化する。
「復旧手順」まで成果物に入れるの、ええな。
それがあれば、ディープルも触りやすくなる。
うん。怖さを消すのは根性じゃなくて、設計。
「壊しても戻せる」が分かれば、運用は強くなる。
相談していい条件があるだけで……すごく安心します。
「何を言えばいいか」が分かるから……。
この合意を置くと、開発者が「全部背負う」形になりにくくなります。
利用側も「自分が悪い」ではなく、「どこが未確定か」を言いやすくなります。
それが、炎上後の最短の立て直しになります。
落とし穴：善意で埋めて、見えない負債を増やす
炎上後に一番やりがちな落とし穴は、「とりあえずストークが直す」「ディープルが慣れる」と、
人の善意で穴埋めしてしまうことです。
一時的には回ります。でも、境界が無いままなので、次のトラブルでまた同じ場所が燃えます。
しかも、そのたびに「相談しづらい空気」だけが強くなります。
対処：途中で見るのは「正解」ではなく「状態」
立て直しで大事なのは、内容の正しさよりも、状態の見える化です。
次の3点だけを揃えると、会話が落ち着きます。
- 決まっていること（合意済み）
- 未確定なこと（判断待ち）
- 次の判断点（いつ・誰が・何を決めるか）
今日は「誰が悪いか」は決めない。
「未確定」と「次の判断点」だけ決める。
それが決まったら、成果物に運用と引き継ぎを足す。順番を守る。
了解たい。俺も「動く」だけで出した分、今から整える。
ただ、整える内容を成果物として合意して進めたい。
わたしも、「未確定」を言っていいんですね。
それなら……少しずつでも言えそうです。
DXは、技術の話に見えて、実は「境界の設計」問題で崩れることが多いです。
その境界を俯瞰して整える役がいるかどうか。
そこで差が出ます。
締め：ディープルを「自責」から戻すのが、マネージャの仕事
ディープルは、困ったときに「仕組みが悪い」とは言いません。
「自分が足りない」と言います。
だからこそ、シママのように問題を俯瞰し、責める対象を人から構造へ戻す存在が不可欠です。
境界がないから、困っている人同士がぶつかる。
境界を作れば、相談が遅れず、炎上は起きにくくなる。
DXの立て直しは、いつもここから始まります。
よし。今日の方向性は決まった。
成果物に「運用・引き継ぎ・復旧」を入れる。相談の入口を作る。境界を見える化する。
ここまでやったら、また前に進めるよ。
了解たい。今度は「動く」だけで終わらせん。
一緒に触れる形にして、困る人を減らす。
……はい。
相談していい入口があるって分かるだけで、少し呼吸が戻りました。