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