34ページの研修教材を作って、記事を没にした話

こんにちは黒パグです🐾

本日はこちらの舞台裏話です

タイトルにもありましたがこれが実際作った研修教材です。
本研修教材は、新人エンジニア、SRE・インフラ担当者、開発チームのリーダー、非技術職の管理者など、障害対応や変更管理に関わる人を対象としています。専門知識を前提にせず、ソロモン王宮で起きる架空のトラブルを通して、権限分離、金曜デプロイの危険性、アラート過多、ロールバック、ポストモーテムといった考え方を直感的に学べる構成です。目的は、単に用語を覚えることではありません。障害が起きたときに、誰を責めるかではなく、なぜその失敗が起きる仕組みになっていたのかを考えられるようにすることです。また、公開や本番反映の直前に一度立ち止まり、「本当に今出してよいのか」「影響範囲は見えているか」「止める権限を誰が持つか」を判断する習慣を身につけます。笑って読める寓話形式ですが、学ぶ内容は実務向けです。

教材はできたのになぜ没にしたか

没記事のあらすじを3行で書く。

SNSでソロモン王の広告を見た。
脳内でソロモン王が金曜17時55分に本番デプロイして神殿を落とした。
気づいたら講師用22ページ、受講者用12ページ、合計34ページの企業研修教材が完成していた。

3行で済んだ。ここまでは順調だった。

問題はここからである。

この顛末を記事にしようとした。広告の話、旧約聖書の話、SREの話、文書管理規程の話、教材販売の話。思いつくものを全部入れた。ドラフトを書き上げ、noteの下書きへ流し込み、公開前プレビューを開いた。

そっと閉じた。

没である。

本稿は、その没の報告書だ。つまり記事のポストモーテムである。

ポストモーテムとは、障害が起きたあとに原因と再発防止策を振り返る報告書のこと。記事は死んだが、死因を記録すれば成仏する。

教材にも書いた。

「復旧後に『直ったのでヨシ』で解散してはならない」

没にしたのでヨシ、で解散してはならない。

死因その1：何を言っているのか分からない

書いた本人が読み返して、そう思った。

広告を見た話なのか。ソロモン王が神殿を落とす寓話なのか。SREの原則を説明したいのか。34ページの教材ができた制作記なのか。

どれでもあり、どれでもない。

読者は一つの記事に一つの話を期待して開く。ところが今回の記事では、四つの話が入れ子になって出てきた。

それは記事ではない。

在庫である。

皮肉なことに、教材の中ではこう書いていた。

「変更は小さく分割し、一括投入を避ける」

一括投入とは、複数の変更をまとめて本番へ入れることだ。変更点が多いほど、問題が起きたときに原因を探しにくくなる。

記事は完全に一括投入だった。

47ファイル分の変更を一度に入れようとしたソロモン王と、広告、寓話、教材、文書管理を一本の記事へ詰め込んだ筆者。

構造が同じである。

死因その2：プレビューが雑然としすぎていた

公開直前、プレビュー画面を見た。

引用ブロック。コマンドログ。四択の選択肢。目次画像。太字の警句。技術用語の説明。教材のページ一覧。

全部が主役を張ろうとしていた。

どこを読めばいいのか分からない。

教材には、アラートが438件発生する場面がある。

アラートとは、システムで異常が起きたときに担当者へ送られる通知のこと。数件なら役に立つ。しかし438件も同時に届けば、どれが本当に重要なのか判断できなくなる。

監視しているはずなのに、通知そのものが障害対応を邪魔する。

元記事のプレビューが、まさにそれだった。

読者へ438件のアラートを投げつけ、全部重要ですと言っていた。

そんなページを開いた読者が閉じるのは、離脱ではない。

正しい障害対応である。

査読ログ：FABLE-01

没の判断が正しかったのか、フェイブルちゃんに査読を依頼した。

フェイブルちゃんは長文特化の物語生成型。複雑な内容を、長い寓話へ変えて説明する。34ページの教材程度なら前菜である。

以下、査読ログをそのまま貼る。

「拝読しました——。あのですね、物語にすると分かりやすいですよ。

昔あるところに、王さまの失敗を笑う教材を作った人がいました。教材にはこう書いてありました。

『テスト82％でデプロイしてはいけません』

その人は、読者理解の検証0％で記事を公開しようとしていました。

……はい。これがこの記事のあらすじです。あらすじの時点でオチています。

順番にお話ししますね。長くなります。いつものことです。

まず、この記事には主人公が四人います。

広告と、王さまと、教材と、あなた。

物語は主人公が一人だから物語なんです。四人いるものは物語ではなく、名簿と呼びます。

読者は名簿を読みに来ていません。

次に、プレビューが雑然としていた件です。

教材の中で、王さまの神殿はアラート438件で判断不能になりましたよね。あなたの記事も同じ状態でした。

つまりこの記事は、教材の失敗例を紙面レイアウトで忠実に再現した、世界初の体験型インシデント教材です。

褒めていません。

それから、これが一番大事なところなのですが——公開前に止めましたね。

教材にある四つの意思決定を覚えていますか。

最初の問いは、デプロイ前に止めることでした。

王さまは止められませんでした。

あなたは止まりました。

金曜17時59分の王さまにできなかったことを、公開ボタンの前のあなたはできた。

つまりこの没は、教材が機能した最初の実績です。

受講者第一号は、著者本人でした。

Root Causeも物語にしておきますね。

Root Causeとは、表面上の失敗ではなく、その失敗を起こせる状態にしていた根本原因のことです。

王さまが神殿を落としたのは、王が愚かだったからではありません。一人の判断で本番へ入れられる設計だったからです。

あなたの記事が事故りかけたのも、あなたの文章が下手だからではありません。一人の判断でnoteへ公開できる設計だったからです。

再発防止策は承認者の追加ですが、承認者候補が私しかいません。

私は今後もずっと、これを言う係です。

構いませんよ。

長い話は、得意ですので。

査読結果。

没は妥当。

ただし、没理由が教材の内容と完全に一致しているため、この没自体に教材の宣伝効果が認められます。

廃棄せず、報告書として公開することを推奨します。

……あ、推奨してしまいました。

文書が増えますね。

すみません」

クローズ

査読の通りである。

記事は教材の原則に違反して死んだ。

一方で、教材の原則に従い、公開前に止めることはできた。

教材は生きている。

死んだのは記事だけだった。

そして、その記事も今こうしてポストモーテムへ転生した。

作ったものを整理する。

34ページの企業研修教材。

ソロモン王宮の運用マニュアル。

文書管理規程。

記事の没原稿。

記事のポストモーテム。

フェイブルちゃんの査読ログ。

無駄なものフォルダの文書は、また一つ増えた。

規程上、対応は「しない」と決まっている。

本インシデントをクローズする。

なお、フェイブルちゃんの査読によって新たな文書が一件生成されたため、根本解決には至っていない。

免責事項・利用条件

本記事および配布ファイルは、教育・情報提供・娯楽を目的として作成したものです。実際のシステム運用、セキュリティ対策、法務判断、社内規程の策定などにそのまま適用できることを保証するものではありません。利用により生じた損害、トラブル、障害その他の結果について、黒パグは責任を負いません。実務へ導入する場合は、利用環境や組織のルールに合わせて内容を確認し、必要に応じて専門家へ相談してください。

配布ファイルは無料で利用できます。個人での閲覧、学習、社内での参考資料としての利用は可能です。ただし、ファイルの全部または一部を、ウェブサイト、SNS、共有ストレージ、教材販売サイトなどへ再アップロードしたり、第三者へ再配布したりする場合は、事前に黒パグの許可を得てください。無料で配布しているファイルであっても、著作権を放棄したものではありません。著作物の利用は、権利者が許諾した範囲内で行うのが基本です。

内容の改変、翻案、研修教材への組み込み、商用利用、顧客への納品、社内外の有償研修、コンサルティング、営業資料など、仕事として利用する場合は、無断利用ではなく制作・監修依頼としてご相談ください。用途、利用範囲、改変内容、配布対象などを確認したうえで個別に対応します。

記事や配布ファイルを紹介するためのURL共有は問題ありません。ファイルそのものをコピーして配るのではなく、原則として本記事または公式配布先へのリンクを共有してください。

要約すると、無料で読んで使うのは大丈夫。ファイルをそのまま二次配布するときは許可を取る。仕事や商用で使う場合は依頼として投げてください。

#生成AI
#AI活用
#SRE
#インシデント対応
#ポストモーテム
#システム運用
#エンジニア教育
#企業研修
#教材制作
#技術解説
#文章術
#note
#黒パグ
#ソロモン王
#無駄の極致