← 提出本文に戻る

校正過程

校正過程: 『リハする』のたびに、気が重い ─ SREが発表準備のToilを削った話

対応する提出本文: 『リハする』のたびに、気が重い ─ SREが発表準備のToilを削った話

CNK 2026 採択 abstract の「型」を移植し、Round 1〜5 のレビューと改善を経た記録。

トーク設計#

幹（一文）#

スライド × 台本は「発表のフロントエンド」。SRE のインフラ屋として、勉強中の Platform Engineering の発想（DX 改善）と SRE の Toil 削減を登壇準備に持ち込んでみたら、SSOT が効いた。

対象（ペルソナ）#

  • 登壇する人全般（エンジニア／デザイナー／PdM 問わず）
  • Slide-as-code（Slidev・Marp 等）ユーザー
  • リハの摩擦（時間配分・台本管理・心理的コスト）に心当たりがある人

持ち帰り価値#

  • メイン: 「FE 文化（テスト／DX）が逆方向に持ち込まれる」越境体験 — SRE / Platform Engineering の発想で登壇準備を見直せる
  • サブ: 「資料 × 台本」を SSOT として扱う具体レシピ（スピーカーノート + VOICEVOX + ffmpeg）

避けたいこと#

  • ツール紹介で終わる（“便利でしょ” 着地。比喩を後半で消さない）
  • 技術詳細（ffmpeg フラグ、VOICEVOX 話者番号等）で 5 分オーバー
  • 自虐や恐縮トーン（個人実践は越境の強みとして堂々と扱う）

構成の型#

PREP（Point → Reason → Example → Point）

流れ（5 分配分）#

  • P (0:00–0:40) フック: 「画面の向こうに誰かがいる限り、地続き ─ 登壇も同じ」とテーマに乗り、「聴衆の皆さんという”画面の向こう”のために登壇者がやるべき”フロントエンド”の話」と切り出す。自己紹介はフックスライド 1 枚に併記（本職: SRE のインフラ屋 / 個人で Platform Engineering 勉強中）
  • R (0:40–1:30) なぜ: リハの摩擦 = Toil / _script.md 別管理 = 二重管理 / 「気合いでリハ」は属人化・スケールしない
  • E (1:30–3:40) ★山: スピーカーノート一元化 = SSOT
    • Before/After スクショ
    • デモ動画 5–10 秒
    • 「これ、Single Source of Truth — 皆さんが状態管理やデザインシステムで日常的に使ってる発想」
    • 副次: 差分ビルド（HMR 比喩で接続、Platform Engineering の DX 改善のもう一例）を 30 秒チラッと。タイトなら最初に削るバッファ
  • P (3:40–4:40) 結論再提示: 「登壇する人みんなが、自分の発表準備を”プラットフォーム”として整備できる。SRE の Toil 削減 / Platform Engineering の DX 改善 で見直すと SSOT がよく効く」+ リポジトリ公開
  • バッファ (4:40–5:00)

焦点化#

一人称・内的（「私が試した」「個人で持ち込んでみた」）。“べき論”の俯瞰解説にしない。

削った素材 → 退避先#

  • ffmpeg / VOICEVOX 詳細 → Q&A / ブログ
  • _measure-timing.mjs（過去の自前時間計測） → Before スライドに名前だけ残す
  • Bebeu / FSD（もう片方の CFP の題材） → 完全に出さない（混線回避）
  • nakos-kb の他機能 → リポジトリリンク表示のみ
  • 差分ビルドの実装詳細（ハッシュキー設計） → Q&A 退避

タイトル候補#

  • 現行案: 「『リハする』のたびに、気が重い ─ SREが発表準備のToilを削った話」
  • 補欠案B: 「『台本どこに書いてますか？』── スライドと台本をSSOT化した5分」（Toilを捨ててFE共通語SSOTに寄せたバリエーション）
  • 旧案: 「発表のフロントエンド、テストできますか？ 〜SREがSlidev × VOICEVOXで発表準備のToilを削った話〜」

旧版アーカイブ#

v1: 初期案#

テーマへの呼応から本論に入り、Platform Engineering の DX 改善と SRE の Toil 削減を並列に提示していた版:

登壇するとき、台本どこに書いてますか？

Slidev でスライドは書いているけど、台本は別ファイル。時間配分は気合いで測る。「リハする」のたびに気が重い。─ それ、SRE で言う Toil (反復的な手作業の運用負担) です。

本職はインフラエンジニアで SRE をやっていて、Platform Engineering の発想にも興味があって個人で勉強中です。「画面の向こうに誰かがいる限り、地続き」── 登壇もそうだなと思っています。聴衆の皆さんという “画面の向こう” のために登壇者がやる、登壇準備というもう一つの “フロントエンド” の話を 5 分で持ってきました。

やったのは、Slidev のスピーカーノート (<!-- -->) に台本を寄せて、VOICEVOX でナレーション化、ffmpeg で動画に組み立てる ─ just sim-video <deck> 一発でリハ動画ができる仕組みです。結果、「資料を書く」と「台本を書く」が同じ作業になりました。これ、皆さんが状態管理やデザインシステムで日常的に使っている Single Source of Truth そのものです。副次として、_sim/.manifest.json のハッシュ管理で差分ビルドも入れました。1 行直して見直すが秒で回る ─ Vite の HMR の発想に近いです。

登壇する皆さんは、自分の発表準備を一つの “プラットフォーム” として整備できます。SRE の Toil 削減・Platform Engineering の DX 改善 ─ こうした発想を、登壇という “フロントエンド” の仕事に持ち込める。FE 文化のテストや DX が逆方向にやってくる越境体験を、5 分で共有します。

v2: 自分で書いてみた版#

CNK 型に寄ったが、まだ磨きが足りない素直な一人称版:

登壇発表やプレゼンをするとき、みなさんは台本を書くでしょうか？

わたしはアドリブに弱く、台本が必要になるくせに、実際に声を発してリハーサルするのが気が重くて……結局「えーいぶっつけ本番だ！」という発表を過去に何度か繰り返してきました。

そんな折、本業のインフラエンジニアとしてSREに取り組む中で、ふと「これはSREでいう、Toil（反復的な手作業の運用負担）なのでは？」と思い浮かんだことをきっかけに、この痛みをどうやって解消しようか、考えるようになりました。

それから実際にやったことは、Slidevのスピーカーノートに台本を集約して、VOICEVOXでナレーション化、ffmpegで動画に組み立てる。このフローをコマンド一発で流せるようにして、簡単にリハ動画ができる仕組みづくり。この結果、「資料を書く」と「台本を書く」が同じ作業になりました。状態管理やデザインシステムでおなじみの、あの Single Source of Truth が、そのまま登壇準備にも効いてくれた形です。

本セッションでは、発表の”フロントエンド”である「スライドと自分の声が乗った台本」を、SREの発想で整え直した越境体験を共有します。

移植した CNK 型の要素チェック#

  • #1 一人称の問い: 「『リハする』のたびに、なぜ気が重い？」（15 字に圧縮）
  • #2 違和感・モヤモヤの開示: 「アドリブに弱いくせに、台本を声に出すリハがどうしても気重で」「二重管理が痛い」「気合いでやるリハに、再現性はない」（弱み + 構造的違和感 + 運用知の合成）
  • #3 転換点の物語化: 「そんな折、気づきます。『これ、SRE で言う Toil じゃないか？』」
  • #4 姿勢フレーズ: 「リハは気合いでやらない。回す。」（独立段落として立てる）
  • #5 具体ツールと自前性: スピーカーノート、VOICEVOX、ffmpeg、just sim-video + Slide-as-Code への言及で Slidev の FE 出自を明示
  • #6 内的変化のビフォーアフター: 「『資料を書く』と『台本を書く』が同じファイルに収まり、リハの気重さがほどけました」（「同じ作業」→「同じファイル」で誤読リスク回避）
  • #7 独自概念で整理: 「発表のフロントエンド」（比喩 → Slide-as-Code への言及で実体に変換）/ SSOT は借用のまま文脈で再定義
  • #8 本セッションでは…: 最終段落で持ち帰り価値を明示 + 手前段落に「皆さんの Slidev デッキでも…始められます」の翌週月曜レシピを露出

Round 1 改善ログ#

  • タイトル: 案 A 採用（本文冒頭の一人称の問いと完全呼応するため）
  • #4 短縮 + 登壇文脈化: 「痛いなら、運用するのではなく削る。」(SRE 内輪ジャーゴン) →「リハは気合いでやらない。回す。」(13 字、CNK 型のリズム、登壇文脈で響く)
  • #6 内的変化を一節追加: 「リハの気重さがほどけました」を加え、事実の変化 + 感覚の変化の二段に
  • #7 整理: 「一人プラットフォーム」を捨て、「発表のフロントエンド」一本に絞る
  • 削った冗長: 差分ビルド / _sim/.manifest.json / HMR の言及
  • 最終段落整理: 「画面の向こう」の再持ち出しを削除、「5 分で。」→「越境体験を 5 分で共有します」に直す

Round 2 改善ログ（文章リズム・引き込み）#

  • タイトル: 50 字 → 34 字に短縮。固有名詞「Slidev × VOICEVOX」をタイトルから本文に回し、「気が重い」⇔「Toil を削った」の対比を立てる
  • 冒頭の問い短縮: 「なぜわたしは気が重くなるのだろう？」（17 字）→「なぜ気が重い？」（7 字）。フックの鋭さを倍化
  • 「。が、」のリズム破綻解消: 「やっています。が、白状すると、」→「やっているのですが、白状すると、」
  • 「のが気が」連続解消: 「台本を声に出してリハするのが気が重くて」→「台本を声に出すリハがどうしても気重で」
  • 段落 3 を 2 段落に分割: 「気づき」と「姿勢フレーズ + 実装」の間に段落改行を入れ、太字の姿勢フレーズを独立段落として視覚的に立てる
  • <!-- --> 括弧削除: 音読不能、Slidev 知らない人にも知ってる人にも不要
  • 段落 3 後半を短文化: 一文を二文に
  • 段落 5 主語 27 字を解消: 主述を分割し口語化
  • 「橋」の半文追加: 段落 2 末に「気合いでやるリハに、再現性はない」を加え、Toil への気づきへの飛躍を補強（運用知の語彙）
  • 余韻を奪う最終文削除: 「登壇する皆さんも、自分の発表準備を一つの”プラットフォーム”として整備できます」を削除

Round 3 改善ログ（CFP 審査者目線）#

  • 採否予測 (Round 3 レビュー前): 3/5 (「テーマ整合は成立しているが『個人 DX 紹介』枠の競合が多く、独自性で頭一つ抜けるかは紙一重」)
  • タイトル: 維持。レビューで Toil の SRE 内輪語化を指摘されたが、独自性とのトレードオフで現行維持。補欠案 B (「『台本どこに書いてますか？』── スライドと台本を SSOT 化した 5 分」) を更新してバリエーションとして残置
  • 「発表のフロントエンド」を比喩から実体に変換: 段落 4 末に「Slidev はそもそも Vue 製の Slide-as-Code ツール ── FE で当たり前の Component / SSOT 文化が、スライドにも来ています」を追加。Slidev の FE 出自という事実線で、「発表のフロントエンド」が言葉遊びではなく実体に
  • 「資料 = 台本」誤読リスク回避: 「同じ作業になり」→「同じファイルに収まり」。レビュー指摘「厳密には『スピーカーノートに台本を寄せる ＝ 同一ファイルに同居』で統合ではない」への対応
  • 「翌週月曜」レシピを 1 行で具体化: 段落 5 末に「皆さんの Slidev デッキでも、スピーカーノートに台本を寄せるだけで始められます」を追加
  • 概念の整理（最終段落）: Platform Engineering / DX 改善を最終段落から削除し「SRE の Toil 削減という運用知が、登壇準備という”発表のフロントエンド”に逆流させられる」一本に。abstract で残る概念は Toil / SSOT / 発表のフロントエンド / 越境 の 4 つに圧縮

Round 4 改善ログ（Anti-Slop）#

  • 5 軸スコア (Round 4 レビュー時点): 立場 8 / リズム 7 / 主体性 8 / 具体性 7 / 削減 7 = 合計 37/50。書き直し閾値 35 をクリアして公開可ライン
  • 最終段落の閉じを脱定型化: 「逆流させられる ── その越境体験を 5 分で共有します。」→「SRE 由来のやり方を、登壇準備という”発表のフロントエンド”に持ち込んだ話を 5 分で。」。Slop 3 種盛り（受動「逆流させられる」+ 大げさ昇華「越境体験」+ シグナルポスト「共有します」）を一掃し、体言止めで締める
  • ── を 3 個 → 1 個に削減: 段落 4 末「Slide-as-Code ツール ── FE で当たり前の…」の ── を句点に。段落 6 の ── は最終段落改善で消滅。段落 2 末の ──（「気合いで測る──二重管理が痛い」）だけ残す
  • 太字 3 連発を 2 つに圧縮: 「Single Source of Truth」の太字を外して地の文に
  • 「ふと」の削除: 「そんな折、ふと気づきます」→「そんな折、気づきます」（「ふと」は AI 常套副詞）
  • 空虚動詞句の置換: 「FE で当たり前の Component / SSOT 文化が、スライドにも来ています」→「FE で当たり前の Component や SSOT が、スライドにも来ています」
  • 維持判断: 「リハは気合いでやらない。回す。」「発表のフロントエンド」は姿勢フレーズ・独自概念として維持。「白状すると」は偽の脆弱性候補だが口語的で書き手の声が乗っており維持
  • 公開ライン到達: 5 軸合計が閾値超え。CFP 用 abstract として「AI 臭が抜けた」状態

Round 5 改善ログ（接続度 = coherence）#

ユーザー指摘「『本職はインフラエンジニアでSREをやっている』→『台本を声に出すリハがどうしても気重』が接続度が低そう」を出発点に、文章の各要素間の接続強度と接続タイプを RST 系（Halliday & Hasan の cohesion / coherence、Rhetorical Structure Theory）に基づいて評価。

全体診断: Cohesion は強い（「気が重い／気重」「気合い」「回す／一発で回る」「SSOT」が段落をまたいで反復、接続詞「そんな折」「結果」「本セッションでは」も配置）。弱いのは Coherence。具体的には、(a) 伏線（SRE）が配置時点で浮き Payoff まで断絶、(b) FE 出自への話題転換が背景情報の唐突挿入になる、(c) SSOT が二段落連続で説明され順序が逆転。総じて「あとで効くように先置きした素材が、現場の意味接続を犠牲にしている」。

ワースト 3 → 修正:

  • W1: 段落 2「本職はSRE → 白状すると、アドリブに弱い」接続度 3 → 改善（ユーザー指摘箇所）
    • 問題: 「のですが」が逆接で形式的に繋ぐだけで、SRE 専門性と「アドリブに弱い」の間に意味的橋が無い。SRE は段 3「Toilじゃないか？」の Setup として配置されているが、配置時点では機能せず読者が「リハの気重さの話で、なぜ職業？」と詰まる
    • 修正: 「本職はインフラエンジニアでSREをやっているのですが、白状すると、…」→「本職はインフラ屋でSRE ─ 反復作業を削るのが日課です。なのに、白状すると、自分の登壇では削れません。アドリブに弱いくせに、…」。Antithesis（運用では削るのに、自分の登壇では削れていない）を入れて配置時点で意味接続を成立させる。Setup-Payoff の鋭さは「Toil」という用語ラベルを段 3 で初出させることで保持
  • W2: 段落 5 内「一発で回ります → SlidevはそもそもVue製の…」接続度 3 → 改善
    • 問題: 手順説明から FE 出自の背景化に話題が飛ぶ。共有概念が「Slidev」一語のみで、実装フローと Slide-as-Code の意味的橋が無い
    • 修正: 「just sim-video 一発で回ります。SlidevはそもそもVue製のSlide-as-Codeツール。」→「just sim-video 一発で回ります。これが成立するのは、SlidevがそもそもVue製のSlide-as-Codeツールだから。」。「これが成立するのは…だから」で Cause を明示する接続橋を入れる
  • W3: 段落 5 末「ComponentやSSOT」→ 段落 6「Single Source of Truth」接続度 5 → 改善
    • 問題: SSOT という同一概念が二段落連続で説明される（順序逆転で Restatement に劣化）
    • 修正: 段 5 末「FEで当たり前のComponentやSSOTが、スライドにも来ています。」→「FEで当たり前のやり方が、スライドにも来ています。」。SSOT 概念を段 6「Single Source of Truth そのものです」で初出に。段 5 末は抽象（Setup）、段 6 は具体名（Payoff）の関係を回復

接続度改善後の見立て: W1〜W3 すべて 接続度 7-8 に到達。Coherence の弱点が抜けて、Cohesion との両輪が成立した状態

ユーザーフィードバック反映#

  • 「5 分で」削除: 最終段落「登壇準備という”発表のフロントエンド”に持ち込んだ話を 5 分で。」→「持ち込んだ話を共有します。」。CFP フォームで枠（LT 5 分）を選んだ時点で時間は決まっているため、abstract での所要時間表記は冗長
  • ベタ詰め適用: タイトル候補とトーク概要本文の英数字・強調・半角括弧・半角引用符と日本語の境界の半角スペースを除去。英語フレーズ内 (Single Source of Truth, Slide-as-Code 等) のスペースと、em-dash ─ 前後は維持
  • Markdown 装飾の除去: トーク概要本文から強調 **...** とインラインコード `...` を除去。CNK 採択 abstract も装飾なし運用なので整合

採否予測の推移#

  • Round 2 終了時 (型 + リズム済み): 3/5（メタファー薄さ + 概念多すぎ + 誤読リスクがネック）
  • Round 3 改善後想定: 3.5〜4/5（FE 出自接続でメタファーが実体になり、概念整理 + 翌週月曜レシピで自分ごと化を強化）
  • Round 4 終了時: 3.5〜4/5（Anti-Slop で公開ラインに到達）
  • Round 5 終了時: 4/5（接続度の Coherence 弱点が抜け、Cohesion との両輪が成立）

留意事項（編成戦略）#

  • Round 3 レビューで「重複採択不可の前提なら、編成側は FSD を Regular で取り、本案は LT 枠の『越境テイスティング』として拾う可能性が現実的」と指摘された
  • もう片方の Regular (FSD × Bebeu) は “FE 文化が外へ流出する” 越境、本 LT は “他領域 → 登壇 (FE 隣接)” の逆向き越境、と方向が異なるので、両方魅力的に並べられる
  • スライド本編で「Slidev は Vue 製」ことを実演で見せる（または Vue の <script setup> 構造に触れる）と、abstract の FE 接続が体験として担保される