会社情報
採用情報
お問い合わせ
Article

3時間で完成する業務マニュアル作成法

高田晃太郎
3時間で完成する業務マニュアル作成法

知識労働者は業務時間の約19%を情報検索に費やすという調査（McKinsey）¹や、文書が見つからない・古いことで生産性が大きく下がるという報告（IDC, Gartner）³²、国内でも社内情報の整理・検索性の低下が従業員の不満や生産性低下に結びつく可能性があるという実態調査⁴は広く知られています。現場で手順がばらつき、属人化が進んでいるほど、正確な業務マニュアルはチームの再現性を押し上げます。一方で、マニュアル作成には十数時間から数十時間を要することが一般的で、ここがボトルネックになりがちです。CTOの視点からは、テンプレート化と自動抽出、軽量レビューを組み合わせ、タイムボックス3時間で“リリース可能”な初版を出す運用は十分に現実的です。この記事では、品質を定量的な指標で定義し、コードとパイプラインで実装する手法を、エンジニアリング組織のリーダー向けに解説します。なお、前述の「19%」という目安は、社内ナレッジ共有の非効率が実務に与える負担を示す複数の分析とも整合します⁵。

3時間の到達点を数値で定義する：MVM（最小実用マニュアル）

短時間で仕上げる最大のコツは、完成度の境界を曖昧にしないことです。私は「最小実用マニュアル（MVM）」を成果物と定義し、品質を定量基準で固定することを推奨します。たとえば、対象業務のカバレッジを80%以上、再現テストの成功率を95%以上、所要時間・責任者・インプット/アウトプットの明示率は100%を目安にし、変更履歴はGitで全て追跡可能にします。これらは多くの現場で無理なく運用できる初期値であり、初版の3時間に対して以後の改善は差分プルリクで吸収します。重要なのは、文章の美しさではなく再現性と検証可能性です。判断と作業を分離し、誰が読んでも同じ結果に到達できる手順のみを残します。

測定方法も最初に決めてしまいます。再現率は、非エンジニアを含むメンバーが手順通りに試行して得られる成功/全試行の比率で計測します。所要時間は手動計測でも十分ですが、開始と終了のタイムスタンプをテンプレートで記録するだけで後の分析が容易になります。こうして測定値を回収しておくと、次のスプリントでの改善サイクルが回り始めます。

時間配分の設計：60分の素材収集、90分の整形、30分のレビュー

3時間の配分は、60分の素材収集、90分の整形、30分のレビューと再現テストという流れが安定しやすい構成です。手を動かす順番を固定することで、思考の切り替えコストを避けられます。特に重要なのは、素材収集の段階で自動抽出を徹底することです。人間の記憶に頼らず、Gitの実行可能スクリプト、OpenAPI、IaC（Infrastructure as Code）定義、CI設定など“すでに動いている真実”から引くことで、初版の信頼性が一気に上がります。

1時間で素材を集める：リポジトリから真実を引き抜く

属人化の多くは「知っている人の頭の中」にあるのではなく、「コードや設定に埋まっているのに参照されていない」ことから起きます。素材収集では、ヘッダコメント、シェルのusage、Makefileのターゲット、Terraform/Helmの変数、OpenAPIのoperationIdといった機械可読な断片を一気に収穫します。以下は、Gitリポジトリからスクリプトの先頭コメントとusageを走査し、SOP（標準作業手順書）のタネをYAMLで吐き出す最小の例。

# extract_sop_seeds.py
import re
import subprocess
from pathlib import Path

ROOT = Path('.')
PATTERN = re.compile(r"^#: (?P<line>.*)$")

def list_scripts():
    for ext in ("sh", "py", "rb", "ps1", "make"):
        yield from ROOT.rglob(f"*.{ext}")

def parse_header(path: Path) -> list[str]:
    lines = []
    try:
        with path.open("r", encoding="utf-8", errors="ignore") as f:
            for i, line in enumerate(f):
                if i > 50:  # headerだけ
                    break
                m = PATTERN.match(line.strip())
                if m:
                    lines.append(m.group("line"))
    except Exception as e:
        print(f"skip {path}: {e}")
    return lines

def detect_usage(path: Path) -> str:
    if path.suffix == ".sh":
        return subprocess.getoutput(f"grep -n 'usage' {path} | head -1")
    return ""

print("sops:")
for p in list_scripts():
    header = parse_header(p)
    if not header:
        continue
    usage = detect_usage(p)
    print(f"  - id: {p}")
    print(f"    title: {header[0] if header else p.name}")
    print("    sources:")
    print(f"      - {p}")
    print(f"    usage: \"{usage}\"")

API駆動の業務についてはOpenAPIから叩き台を作ります。エンドポイント、必須パラメータ、期待されるレスポンスを手順に変換するだけで、十分に“現場で使える”初版になります。

# openapi_to_sop.py
import json
from pathlib import Path

def to_md(op_id, method, path, spec):
    summary = spec.get('summary', op_id)
    params = spec.get('parameters', [])
    req = spec.get('requestBody', {})
    return f"""---
id: {op_id}
title: {summary}
owner: api-team
sla_minutes: 15
---

## 目的
{summary}

## 手順
1) {method.upper()} {path} を呼び出す。
2) 必須パラメータ: {[p['name'] for p in params if p.get('required')]}
3) 期待レスポンス: {list((spec.get('responses') or {}).keys())}

## 検証
ステータスコード200系で成功とみなす。
"""

素材抽出の段階で、SLAの目安や既知の失敗パターンなど観測から引ける数値はできるだけ書き抜いておくと、後段の整形が楽になります。たとえば下記のようなYAMLが一括で出てくれば、以降は文章化とテンプレートへのマッピングだけで済みます。

sops:
  - id: scripts/deploy.sh
    title: ステージングへデプロイ
    sources:
      - scripts/deploy.sh
    usage: "42: usage: deploy.sh <env>"

90分で整形する：Docs-as-Codeの最短ルート

整形では、テンプレートへのマッピング、自動の目次・図の生成、マルチフォーマット出力を一気に行います。最初にSOPのテンプレートを固定し、フロントマターで責任者、前提、SLA、計測の方法、更新ポリシーを明示します。文章は短く、読み手の行動を誘導する動詞で始めます。以下は最小テンプレートです。

---
id: deploy-staging
title: ステージング環境へデプロイ
owner: platform-team
version: 1.0
updated_at: 2025-08-30
sla_minutes: 20
success_rate_target: 0.95
verification: curl -I https://staging.example.com/healthz | grep 200
---

# 目的
ステージング環境に安定してデプロイし、疎通を確認する。

# 前提
認証済みのCLIが使用可能であり、直近のmainがグリーンである。

# 手順
アーティファクトを取得し、環境変数を読み込んでからデプロイコマンドを実行する。完了後にヘルスチェックを通す。

# 検証
verificationコマンドが成功し、平均応答時間が500ms未満であることを記録する。

Docs-as-Code（ドキュメントをコードと同等に扱い、Gitでバージョン管理しCI/CDに載せる手法）で、マークダウンからPDFやHTMLを同時に出力するにはヘッドレスブラウザを使う方法が高速です。Node.jsでスタイルを当ててからPDFに落とすと、現場配布のしやすさが上がります。

// render.js
import fs from 'node:fs/promises'
import path from 'node:path'
import { mdToPdf } from 'md-to-pdf'

const srcDir = path.resolve('sop')
const outDir = path.resolve('dist')
await fs.mkdir(outDir, { recursive: true })

for (const file of await fs.readdir(srcDir)) {
  if (!file.endsWith('.md')) continue
  const input = path.join(srcDir, file)
  const { content } = await mdToPdf({ path: input }, {
    css: `body { font-family: system-ui; } h1,h2 { page-break-after: avoid; }`
  })
  const pdf = path.join(outDir, file.replace(/\.md$/, '.pdf'))
  await fs.writeFile(pdf, content)
}
console.log('done')

変更時の自動ビルドと配布はCIで回します。GitHub Actionsでプルリクごとに文法チェックとビルドを走らせ、mainマージ時にアーティファクトをリリースすれば、更新の遅延は大幅に抑えられます。

# .github/workflows/docs.yml
name: build-docs
on:
  pull_request:
  push:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: node render.js
      - uses: actions/upload-artifact@v4
        with: { name: sop-pdfs, path: dist/*.pdf }

図や手順の可視化にはMermaidを使うとスピーディです。テキストで差分管理でき、レビューでの指摘が具体に落ちやすくなります。さらに、マニュアルの更新も一つの開発フローとして吸収できます。

30分でレビューと検証を終わらせる：現場で動くことが正義

レビューでは言い換えや文体よりも、失敗しにくさと検証の容易さに集中します。各節に検証行を設け、実行後すぐに確認できるコマンドや観測指標を置くのが有効です。たとえば、APIならステータスコードとレイテンシのしきい値、デプロイならヘルスチェックのHTTP 200と平均応答時間、データ処理ならレコード件数やジョブの終了コードといった数値基準を成功条件として文中に埋め込んでおくと、属人性を最小化できます。

スピードを担保するため、マニュアルの再現テストは非開発メンバーに実行してもらうのが効果的です。操作に迷いが出た箇所は、スクリーンショットや補助スクリプトを追加する対象として即座に差分化します。初版に設定した成功率（例：95%）をクリアできればリリースし、それ以下なら前提の明示や検証コマンドの追加といった狙い撃ちの修正を加えます。大がかりな書き直しは避け、測定値で見えているボトルネックのみを詰めます。

最後に、仕上げの自動化をもう一段入れておくと継続運用が楽になります。目次やリンク切れの検査は機械に任せられます。

#!/usr/bin/env bash
set -euo pipefail
for f in sop/*.md; do
  markdown-toc -i "$f" > /dev/null 2>&1 || true
  markdown-link-check -q "$f"
done

この運用を回すと、以降の更新は15〜30分程度の差分で済むケースが多いはずです。オンボーディングにかかる日数は、体感ではなく記録を通じて着実に下げやすくなり、障害対応のMTTR（Mean Time To Recovery）も、手順が一本化されることで短縮が期待できます。投資対効果は単純です。仮に、週に2時間の検索・確認のロスが10人規模で発生しているなら、月80時間分の回収ポテンシャルが見込めます。マニュアル整備の初期コストが数本で数十時間だとしても、数週間スパンでペイする可能性があります。

ケース接続とスケール戦略

小さく始めて、チームの基幹に広げることが肝心です。まずは障害対応、リリース、データ修正といった高頻度・高リスクの業務を対象にし、MVMを3時間で立ち上げます。その後、レビューフィードバックをテンプレートに逆流させ、次のマニュアルの初版品質を底上げしていきます。社内ナレッジをGitに揃え、プルリク駆動にするだけで変更の心理的障壁が下がります。典型的な流れとしては、オンコール手順のMVMを用意→当番交代時の引き継ぎを短縮→関連SOPに測定方法を横展開、という順番が扱いやすいでしょう。LLM（Large Language Model）の支援を入れる場合も、真実のソースを前述の抽出パイプラインから供給する限り、幻覚の余地を狭められます。ガバナンス面は整合させ、権限と監査の閾値を定義しておくと運用が安定します。

まとめ：3時間の初版が、継続改善を呼び込む

完璧なマニュアルを一度で作る必要はありません。3時間でMVMを出荷し、測れる指標で再現性を担保すれば、現場はすぐに恩恵を受け始めます。重要なのは、品質を定量的に定義し、コードとCIで流通させることです。素材はコードと設定に眠っており、自動抽出で初版の信頼性は確保できます。あなたのチームでは、どの手順から3時間を始めますか。まずは高頻度・高リスクの業務を一つ選び、今日中にテンプレートと抽出スクリプトを置いてみてください。次のスプリントで改善サイクルが回り出すはずです。関連記事として、Docs-as-Codeの入門、API Firstの運用、ポストモーテムのテンプレート化を併読すると、より短期間での全体最適が進みます。

参考文献

  1. McKinsey. Rethinking knowledge work: A strategic approach. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/rethinking-knowledge-work-a-strategic-approach
  2. Gartner. Gartner Survey Reveals 47% of Digital Workers Struggle to Find the Information Needed to Effectively Perform Their Jobs (Press Release, 2023-05-10). https://www.gartner.com/en/newsroom/press-releases/2023-05-10-gartner-survey-reveals-47-percent-of-digital-workers-struggle-to-find-the-information-needed-to-effectively-perform-their-jobs
  3. IDC. The High Cost of Not Finding Information. https://studylib.net/doc/18896230/idc-on-the-high-cost-of-not-finding-information
  4. PR TIMES. 社内情報の整理・検索に関する実態調査（大企業従業員を対象）. https://prtimes.jp/main/html/rd/p/000000190.000027275.html
  5. Panopto. How much time is lost to knowledge sharing inefficiencies at work? https://www.panopto.com/jp/blog/how-much-time-is-lost-to-knowledge-sharing-inefficiencies-at-work/