結論
サイロ化を防ぐ最大のコツは、「動く」だけを成果物にしないことです。
運用・引き継ぎ・変更の戻し方までを成果物に含めると、仕組みは「担当者だけが触れる状態」から抜け出せます。
基本情報技術者試験のシラバスにある、レビュー・コーディング標準・テスト・構成管理／変更管理は、
机上の知識ではなく「職場を守るための道具」です。
そしてマネージャの役割は、個人の気合いに頼らず、基礎を「工程」に落としてチームの再現性にすること。
基礎的な学問は、現場の人間関係と納期を守る──これが今日のメッセージです。
炎上の原因：仕組みが「触れない」形だと、会話が壊れる
先日の混乱は、言い方や空気の問題に見えます。
でも芯はもっと単純で、仕組みが「ストークしか直せない形」になっていたこと。
それが、困っている人同士をぶつけました。
ストーク。あの混乱、仕組みが「あなたしか触れない」形だったから起きたんだよ。
それって、現場の人が困る前提で作ってるのと同じ。
……言い返せんたい。期限があって、まず動かすことばっかり考えた。
他の人が触る前提で整えるの、後回しにした。
余裕の話じゃないよ。
化学や機械の基礎力がなっていない人が、プラントを設計していいわけないよね？
同じ。基礎を飛ばして「動くもの」だけ作ると、職場が壊れる。
……たしかに、プラントなら基礎を飛ばしたら危なか。
俺、ソフトのほうは「動けば勝ち」って思い込みがあったたい。
うん。ここからは責めたいんじゃない。
「次は守れる形にする」って話。
そのために、基本情報のシラバスに戻るって考えてみる。基礎は、ほんとに現場を守るから。
職場を守る基礎は「きれいに書く」みたいな趣味の話じゃありません。
読めない・戻せない・変えられない仕組みは、誰かを黙らせて、誰かを孤立させます。
だから、基礎を工程にします。
シラバスで見る極意：基礎を「工程」にするとサイロ化が止まる
シママがストークに渡すのは、特別な裏技じゃなくて、
基本情報技術者試験のシラバスに載るような「当たり前」を、現場の成果物にする手順です。
1) レビュー：属人化ポイントを早めに潰す
シラバスではレビューについて、「レビューの種類，目的」を理解し、結果を成果物へ反映する流れを押さえる、と整理されています。
これを現場に落とすと、「誰か一人の頭の中」になりそうな箇所を、早い段階で見つけて直すになります。
レビューは「粗探し」じゃない。
サイロ化を止めるために、属人化ポイントを先に潰す工程。
シラバスにも「コードレビュー」って書いてあるでしょ。
俺、レビューって「余裕があるときにやる」って扱いにしとった。
でも、工程にしないと結局やらんたい…。
2) コーディング標準：読める形に揃える
シラバスは「コーディング標準の目的」や、守らない場合の弊害まで含めて理解する、としています。
これが効くのは、「説明しなくても読める」状態が作れるからです。
命名規則、インデント、ネストの深さ、例外処理の書き方。
これは見た目の問題ではなく、引き継ぎの摩擦を下げる「安全柵」です。
3) テスト：仕様の説明書を残す
シラバスは、ソフトウェアユニットの作成やテスト、そして結果の評価基準（網羅性など）まで押さえます。
現場での意味は、「壊れるのが怖い」を消すことです。
正常系だけでなく、異常系・境界のテストがあると、
「どこを触ってよくて」「どこが危ないか」が共有できます。
これは、ディープルみたいなタイプを守る基礎です。
4) 構成管理：全体を「構成品目」で説明できるようにする
シラバスの構成管理は、構成識別体系を確立し、管理方法を明らかにして管理する、と説明しています。
これがないと、仕組みは「どこに何があるか分からない」になり、触れなくなります。
「どのファイルが何の役割か」「設定はどこか」「ログはどこに出るか」。
これを構成品目で説明できない仕組みは、だいたいサイロ化する。
俺、頭の中では分かっとったたい…。
でも、人に渡す形にしとらんかった。結果、俺しか触れんかった。
5) 変更管理：失敗しても戻せる前提で進める
シラバスでは変更管理の活動として、承認・計画・試験、そして「ロールバック（切り戻し）」まで含めて理解する、と整理されています。
これを工程にすると、変更が怖くなくなる。
怖くないから相談が早くなり、炎上が減ります。
結局、職場を守るのは「基礎」
ここまで全部、派手な技術じゃありません。
でも、これをやらないと、困っている人が「自分が悪い」に落ちて、相談が遅れて、関係が壊れます。
基礎は、人を守るためにある。
テンプレ：サイロ化しない開発の「合意文」
これを最初に置くと、基礎が「気合い」ではなく「工程」になります。
1つだけ、貼れる形で置きます。
【成果物の定義】「動く」＋（運用手順／引き継ぎ手順／設定一覧／ログの見方／復旧手順）まで含める。
【標準】命名規則・インデント・例外処理など、コーディング標準を決めて守る。
【レビュー】コードレビューを工程に入れる（属人化ポイントの早期発見）。
【テスト】正常系／異常系／境界の最小セットを用意し、仕様の説明書にする。
【構成管理】構成品目（コード・設定・手順・テスト）を識別し、変更履歴と戻し方を残す。
【変更管理】変更は承認・試験・ロールバックまでをセットで扱う。
【相談】迷ったら（条件）で（相談先）へ。相談は工程であり、迷惑ではない。
これ、最初に合意しとけば「後で整える」が逃げ道にならんたい。
最初から職場を守る形にできる。
そう。基礎は「余裕がある人の趣味」じゃない。
基礎は、現場が荒れないための保護具だよ。
落とし穴：優秀な人ほど「一人で回す」を成功にしてしまう
一番危ないのは、ストークが優秀で、短期的に一人で回せてしまうことです。
回るほど周囲は触らなくなり、相談は減り、属人化が進みます。
対策は、成功条件を変えること。
「あなたが直せる」ではなく、「誰でも直せる」「戻せる」「判断できる」を成功にする。
それが、基礎を職場の防波堤に変えます。
速さは大事。でも、職場を守る速さは「あなたが走る速さ」じゃない。
みんなが走れる道を作る速さ。
その道が、基礎なんだよ。
了解たい。俺の勝ち方を変える。
「動いた」じゃなくて、「運用できて引き継げる」を勝ちにする。
締め：基礎は、現場の優しさを実装する
基本情報のシラバスにある内容は、試験のためだけの暗記ではありません。
レビュー、標準、テスト、構成管理、変更管理。
これらは、困っている人が「自分が悪い」に落ちないための土台です。
化学や機械の基礎が、プラントを守るのと同じ。
ITの基礎も、職場を守る。
その当たり前を工程にできたとき、サイロ化は止まり始めます。