PL「設計書に説明資料…。もう大変だよ」
メンバB「Slidevで設計書をそのまま説明資料にできませんかね？」
PL「日本語資料だとあの手のツールは表示が崩れやすいから、正直怖いんだよね。」
メンバA「それなら、チームの環境統一と日本語フォントの方針を最初に決めましょう。」
第2回のテーマは、ドキュメント化の環境整備とルール作りです。
Slidev運用の成否は、デザインより先に「フォント」「行長」「出力検証」を固定できるかで決まります。
この記事で解決すること
Windows 11上で、次の3点を再現可能な手順で実現します。
- VS Code + Slidevの実務環境を構築する
- 日本語本文とコード表示の崩れを最小化する
- PDF出力までを品質チェック付きで完走する
結論（先に要点）
- バージョン方針はLTS固定にする
- フォントはWindows標準優先でフォールバック順まで固定する
- PDF品質は目視ではなくチェックリストで判定する
-
slidev export <対象md>で出力対象を明示する -
npm run export:02は短縮コマンドとして使う
前提環境
- OS: Windows 11
- Node.js: LTS（推奨は20系または22系）
- エディタ: VS Code
- AI支援: GitHub Copilot
実践手順
手順1: プロジェクトを初期化する
npm create slidev@latest
cd <project-name>
npm install
npm run dev
確認方法:
- ローカルURLでスライドが表示される
- 初期スライドで日本語入力が表示できる
完了条件:
- 開発サーバーが起動する
- 3ページ以上のサンプルスライドを作成できる
手順2: フォントとタイポグラフィを固定する
styles.css の例:
:root {
--slidev-theme-font: "Yu Gothic UI", "Meiryo UI", sans-serif;
--slidev-code-font: "Consolas", "Cascadia Mono", monospace;
}
.slidev-layout {
font-family: var(--slidev-theme-font);
line-height: 1.5;
}
table {
font-size: 0.9em;
}
確認方法:
- 別PCで開いても日本語の行送りが大きく崩れない
- コードフォント置換時でも可読性が維持される
手順3: PDF出力と検証を実施する
判断基準は「出力できたか」ではなく「提出品質を満たしたか」です。
実行コマンド例（Slidevプロジェクト配下）:
# 初回のみ: export に必要な依存を追加
npm i -D playwright-chromium
# 第2回サンプル（slides02.md）をPDF出力
slidev export slides02.md
# ほかの資料を出力する場合（対象mdを明示する）
slidev export slides03.md
slidev export slides04.md
補足:
-
slidev exportは Playwright を使用するため、未導入だと失敗する - 成功時は
slides02-export.pdfのような出力ファイルが生成される -
npm run export:02はslidev export slides02.mdの短縮コマンドとして使える
確認方法:
- PDFを100%表示と125%表示で確認する
- 改行、見切れ、図表文字サイズをチェックする
- ページごとの主張が1つに収まっていることを確認する
完了条件:
- 提出候補PDFをチェックリストで合格にできる
- NGページの修正方針を分割・要約で説明できる
よくある失敗パターンと回避策
-
失敗: フォントを後回しにして最後に崩れる
回避策: 初日に本文フォントとコードフォント、フォールバック順を固定する -
失敗: PDFを最終日に一度だけ確認する
回避策: 主要章ができた時点で中間出力し、崩れを早期検知する -
失敗:
slidev exportで Playwright 未導入エラーになる
回避策:npm i -D playwright-chromiumを初回セットアップへ組み込む -
失敗: 対象ファイルを指定せず誤った資料を出力する
回避策:slidev export <対象md>で対象を明示する
Slidev変換例（基本設計書 -> 説明資料）
元の基本設計書（.docs/examples/member-registration-basic-design.md）から、
顧客説明に必要な観点だけを1ページへ再構成します。
# 会員登録APIの基本設計
**判断基準:** 顧客説明では、入力項目と完了条件だけを1ページで判断できる形に要約する
| 観点 | 内容 |
|------|------|
| 入力項目 | メールアドレス、会社名、担当者名、電話番号 |
| エラー時挙動 | 重複は 409、入力不備は 400 |
| 完了条件 | 登録成功後に確認メールを送信 |
まとめ
第2回の到達点は、環境構築を「起動できる」から「提出品質を維持できる」へ引き上げることです。
- LTS固定で環境差分を抑制する
- フォントと行長制約を先に固定する
- PDF品質をチェックリストで判定する
- 出力対象のmdを明示して、誤出力を防ぐ
次回は第3回として、ここで作ったルールを社内テンプレートへ落とし込みます。
テーマ、コンポーネント、レビュー導線を標準化し、誰が作っても同じ品質に寄せる設計を扱います。