--- title: "手順書の作り方：業務手順書の構成・書き方ルールと古くならない更新運用【2026年】" url: "https://www.issoh.co.jp/column/details/19721/" published: 2026-11-13 updated: 2026-11-13 categories: ["DX"] publisher: "株式会社一創" --- # 手順書の作り方：業務手順書の構成・書き方ルールと古くならない更新運用【2026年】 手順書は、ある作業を初めて担当する人が、横に先輩がいなくても最後まで終えられるようにするための文書です。作り方の要点は、1つの作業だけを扱う範囲に絞り、手順を1動作ずつに分け、更新の持ち主を決めておくことにあります。この記事では、業務マニュアルや作業標準書との違い、対象作業の選び方から試行・承認までの6工程、記載項目のテンプレートを整理しました。書き方ルールはGoogleの開発者向け文書スタイルガイドと文化庁「公用文作成の考え方」を根拠に示し、古くならない更新の仕組みと、手順書を書かずにシステム側を直すべき作業の見極めまで扱います。 ## まとめ：手順書は1作業1文書に絞り、更新の持ち主と改訂のきっかけを先に決める 手順書づくりで失敗が多いのは、書き方より範囲の決め方です。業務の目的や全体の流れまで1冊に詰めると、読み手は自分の作業がどこに書いてあるかを探す羽目になります。手順書は「請求書を再発行する」「新入社員のアカウントを発行する」のように、1つの作業を終わらせるところまでに絞ってください。 書くときは、1手順に1動作、操作の場所を先に書き、操作の後に結果を添えます。一文を分ける目安は、50〜60字を超えたときです。完成の判定は書いた人ではなく、その作業を初めて行う人に一人で実行してもらって決めます。 公開した後に効くのは、改訂のきっかけを業務やシステムの変更に結び付けておくことです。担当者と版番号、次のレビュー期限を冒頭に書き、置き場所を1か所に決めます。入力ミスや判断の迷いが手順書で減らないなら、文書を厚くするのではなく画面や入力チェックを直す側へ回すのが筋です。 ## 手順書と業務マニュアル・作業標準書の違いを書く範囲と読み手から整理 「マニュアル」「手順書」「作業標準書」は社内で混ざって使われがちです。違いは書く範囲と、誰が読むかにあります。 ### 手順書が扱う範囲を「1つの作業を終わらせる」までに絞る判断基準 ドキュメントの型を4つに分けて整理する[Diátaxisの「How-to guides」](https://diataxis.fr/how-to-guides/)は、手順を示す文書を目標志向のものと定義しています。読み手はすでに一定の力量があり、特定の作業を終わらせたい人です。学習者に一から教えるチュートリアルとは別物で、両者を混ぜることが多くの文書が読みにくくなる原因だと指摘しています。 この考え方を社内文書に当てはめると、手順書の範囲は次の3つで判定できます。 - タイトルを「〜する」で言い切れる（「請求書を再発行する」は可、「請求業務について」は不可） - 開始の条件と完了の状態を1行ずつで書ける - 背景や制度の説明を省いても、作業は最後まで進められる 3つ目を満たさない場合、説明部分は業務マニュアルへ切り出し、手順書からはリンクで参照させます。Diátaxisも、作業中の読み手に解説を挟まず、必要な説明はリンクで外に出すよう勧めています。 ### 業務マニュアル・作業標準書・引継ぎ資料との役割分担を一覧で比較 | 文書 | 書く範囲 | 主な読み手 | 更新のきっかけ | | ------- | ----------- | --------- | ----------- | | 手順書 | 1つの作業の操作順 | その作業の担当者 | 画面・帳票・手順の変更 | | 業務マニュアル | 業務の目的・流れ・役割 | 部署の全員・新任者 | 組織・規程の変更 | | 作業標準書 | 品質を保つ条件と基準値 | 製造・検査の作業者 | 工程・設備の変更 | | 引継ぎ資料 | 担当者が持つ案件と経緯 | 後任者 | 異動・退職のたび | 業務マニュアルは手順書の「目次」にあたり、個々の作業は手順書へリンクで分けるのが扱いやすい構成です。引継ぎ資料は進行中の案件や関係者など、その人にしか分からない情報を残すための文書で、手順書とは更新の周期がまったく違います。記載項目は[退職後も消えない引継ぎ資料の作り方](https://www.issoh.co.jp/column/details/18639/)で、文書管理の規程を現場の手順に落とす書き方は[文書管理マニュアルの作り方](https://www.issoh.co.jp/column/details/17754/)で扱っています。 ## 業務手順書の作り方を対象選定から試行・承認まで6工程で進める流れ 手順書は次の6工程で作ります。最初の工程を飛ばすと、使われない文書が増えるだけになります。 1. 手順書にする作業を選び、優先順位を付ける 2. 読み手と完了条件を1行で決める 3. 作業の横で聞き取り、操作を順に書き出す 4. 手順に分解し、分岐と例外を切り出す 5. 初めての人に一人で実行してもらい、詰まった箇所を直す 6. 担当者と版番号を付けて承認し、決めた場所に置く ### 手順書にする作業を頻度と失敗時の損害から選ぶ優先順位の付け方 全業務の手順書を一度に作ろうとすると、途中で止まります。優先するのは、失敗したときの損害が大きい作業と、担当者が1人しかいない作業です。毎日行う作業は担当者が慣れているため、意外と後回しで構いません。 先に書くべきなのは、月末の締め、年1回の更新手続き、障害時の切り戻しのように「頻度は低いが、間違えると取り返しがつかない」作業です。回数が少ないぶん、担当者自身も手順を覚えていません。どの業務が特定の人に寄っているかの洗い出し方は、[属人化の原因と脱属人化を進める標準化の実務](https://www.issoh.co.jp/column/details/13292/)が参考になります。 ### 作業の横で聞き取り、1つの作業を5〜15手順に分解する進め方 聞き取りは会議室ではなく、作業している席の横で行います。口頭の説明では、担当者が無意識に行っている確認や待ち時間が抜け落ちるからです。画面の名前とボタンの表示は、聞いた言葉ではなく画面に出ている文字のまま書き取ります。 書き出した操作は、1つの作業あたり5〜15手順に収まるよう分けるのが目安です。15を超える場合は、途中に区切れる完了状態がないか探し、手順書を2本に分けます。逆に5未満なら、前後の作業と合わせて1本にしたほうが探しやすくなります。 ### 初めての人に一人で実行してもらい、詰まった箇所を直す試行の回し方 手順書の完成を決めるのは、書いた人のレビューではありません。その作業をしたことがない人に手順書だけを渡し、一人で最後まで実行してもらいます。作成者は横で見ているだけにして、質問されても口では答えず、詰まった手順の番号を記録します。 記録した番号ごとに、原因が「書いていない前提」「画面の名前の違い」「判断の基準がない」のどれかを見て直します。試行は2人目で詰まる箇所がなくなるまで繰り返してください。1人目で問題が出なかった場合も、担当経験が近い人だった可能性を疑い、別の部署の人で確かめると漏れが見つかります。 ## 業務手順書に載せる記載項目と、記載例で見る1ページの具体的な構成 手順書の型を社内でそろえると、読み手はどこを見れば何が書いてあるかを覚えられます。項目は冒頭の管理情報と本文に分けて決めます。 ### 手順書の冒頭に置く管理情報と前提条件・完了条件の書き方の具体例 冒頭には、手順に入る前に読み手が判断したいことを並べます。[Googleの開発者向け文書スタイルガイド（Procedures）](https://developers.google.com/style/procedures)も、作業の準備に必要な情報は手順の前に伝えるよう求めています。 - 文書番号・版番号・最終更新日・次回レビュー期限 - 担当者（更新の持ち主）と承認者 - 目的：この作業を終えると何がどうなるか（1行） - 前提条件：必要な権限・事前に届いているべき書類・作業可能な時間帯 - 完了条件：画面やデータが最後にどの状態になっていれば終わりか - 所要時間の目安と、困ったときの問い合わせ先 完了条件は省かれやすい項目ですが、これがないと読み手は「本当に終わったのか」を判断できません。「経費精算システムで申請の状態が『承認待ち』になっている」のように、目で確かめられる状態で書きます。 ### 経費精算の差戻し対応を題材にした手順書の記載例と分岐の扱い方 差し戻された経費精算を申請し直す作業を例に、本文の書き方を示します。架空の社内システムを想定した記載例です。 1. 経費精算システムの［申請一覧］で、状態が「差戻し」の申請を開きます。差戻し理由が画面の上部に表示されます。 2. 差戻し理由を読み、下の表で対応を確認します。 3. ［編集］を押し、該当する項目を直します。 4. 領収書の画像を差し替える場合は、［添付を削除］を押してから新しい画像を添付します。 5. ［再申請］を押します。状態が「承認待ち」に変わったら完了です。 2番目の手順の「下の表」には、差戻し理由ごとの対応を「理由」と「直す項目」の2列で並べます。判断が必要な箇所を手順の中に文章で書き込まず、表として外に出すと、手順そのものは5行のまま保てます。 ## 読み手が迷わない手順書の書き方ルールを公開された文章指針から引く 書き方のルールを社内で一から作る必要はありません。公開されている指針をそのまま社内基準にできます。 ### 1手順1動作・場所から操作・結果の順で書くGoogleの手順記述ルール Googleのスタイルガイドの手順の項は、英語の技術文書向けですが、業務の手順書にもほぼそのまま当てはまります。社内基準に取り込みたいのは次の5つです。 - 1つの手順には1つの動作だけを書く（use one step for each action） - 操作の場所を先に、操作を後に書く（「［申請一覧］で、〜を開きます」） - 目的があれば操作の前に、結果は操作の後に書く - 読み手が判断することは1手順に1つまでにする - 任意の手順は先頭に「任意：」と書き、必須の手順と見分けられるようにする 同じガイドは、別の手順書と同じ操作を繰り返し書かず、リンクで参照するようにも求めています。ログインや承認依頼のように多くの作業で共通する操作は、独立した手順書にして各所からリンクすると、画面が変わったときに直す文書が1本で済みます。 ### 一文50〜60字を目安に論点を1つに絞る公用文作成の考え方の応用 日本語の文の書き方は、文化審議会が2022年1月7日に建議した[「公用文作成の考え方」（文化庁・PDF）](https://www.bunka.go.jp/seisaku/bunkashingikai/kokugo/hokoku/pdf/93651301%5F01.pdf)が使えます。行政文書向けの手引ですが、読み手に作業を正確に伝える目的は手順書と同じです。 同書は一文を短くすることを勧め、50〜60字ほどになってきたら読みにくくなっていないか意識するとよい、としています。同書が併せて挙げているのは、一文の論点を1つにすること、三つ以上の情報を並べるときは箇条書を使うこと、主語と述語の関係が分かるようにすることです。手順書のレビューでは、60字を超える文と、1文に動作が2つ入った文に印を付けるだけで、直す箇所の大半が見つかります。 ### 判断が要る手順を「条件を先、操作を後」の形にして迷いを減らす書き方 「必要に応じて上長に確認する」は、手順書で最も読み手を迷わせる書き方です。何が「必要」なのかが書かれていません。判断が入る手順は、条件を先に書き、その後に操作を書きます。 たとえば「金額が5万円を超える場合は、［承認者］に部長を追加します」と書けば、読み手は金額を見るだけで次の動作を決められます。条件が3つ以上に分かれるときは、前の記載例と同じく表に出してください。「適宜」「なるべく」「状況により」の3語は、手順書の中では使わないと決めておくと、判断基準の書き漏れを機械的に見つけられます。 ## 作った手順書が古くならない更新ルールと置き場所・検索の仕組み 手順書が使われなくなる最大の理由は、一度古い内容を見つけた読み手が、ほかの手順書も信用しなくなることです。更新は担当者の善意ではなく、仕組みで回します。 ### 改訂のきっかけを業務・システムの変更に結び付けるトリガーの決め方 「年に1回見直す」だけのルールでは、その間に画面が変わった手順書は放置されます。改訂は、内容を古くする出来事が起きたときに必ず発生するよう、次のきっかけに結び付けます。 - 業務システムの改修・バージョンアップのリリース（リリース判定の確認項目に「影響する手順書の更新」を入れる） - 帳票・申請様式・社内規程の改定 - 手順書を見ながら作業した人からの「書いてあるとおりにできない」という報告 - 担当者の異動・退職（更新の持ち主を後任へ付け替える） 1つ目が抜けると、システム部門の改修と現場の手順書がずれ続けます。社内システムを外部に改修してもらう場合も、納品物に「影響する手順書の一覧」を含めるよう依頼しておくと漏れが減ります。 ### 版番号・改訂履歴・レビュー期限を持たせ、古い版を参照させない管理 手順書には版番号と改訂履歴を持たせ、旧版は読み手の目に触れない場所へ移します。共有フォルダに「手順書\_最新」「手順書\_最新\_修正版」が並ぶ状態は、どれが正しいかを読み手に判断させている点で、手順書が1本もないより危険です。 冒頭の「次回レビュー期限」は、作成日から6か月や1年など、作業の変わりやすさで決めます。期限を過ぎた手順書は、担当者に確認を依頼する通知を出し、確認が済むまで一覧で目立つ表示にしてください。ファイル名に日付を付けて版を見分ける運用は、文書が数十本を超えると破綻しやすくなります。 ### 置き場所を1か所に決め、社内検索から手順書へ着ける命名と分類 読み手は手順書を目次からではなく、検索で探します。タイトルは「〜する」の形で作業名をそのまま書き、システム名や帳票名など、読み手が検索窓に打つ言葉を入れてください。「経費精算 差戻し 再申請」で探す人に「経費関連手順（その3）」は見つかりません。 置き場所は、社内wiki・共有ドライブ・文書管理システムのどれか1つに決めます。複数の場所に同じ手順書があると必ず起きるのが、片方だけが更新される事故です。社内wikiに置く場合の形骸化の防ぎ方は、[社内wikiが失敗する原因と運用設計](https://www.issoh.co.jp/column/details/16016/)で整理しています。 ## 手順書を作らずにシステム化・自動化へ回すべき作業の見極めと判断条件 手順書は万能ではありません。書くより先に、システムの側を直したほうが早い作業があります。 ### 手順書を書くより画面や入力チェックを直すほうが早い作業の条件 次の条件に当てはまる作業は、手順書を厚くしても間違いは減りません。手順書の作成を止めて、システムの改修や自動化を検討すると判断します。 - 手順書に「〇〇の欄には必ず△△と入力する」「この順番を守らないとエラーになる」という注意書きが3つ以上ある - 同じ転記作業（Excelから業務システムへ、メールから台帳へ）が毎日発生している - 試行で詰まった箇所の原因が、手順書の書き方ではなく画面の分かりにくさにある - 判断の表が10行を超え、担当者ごとに解釈が分かれている 注意書きは、本来システムが入力チェックで止めるべき内容です。入力値の制限や必須項目の設定で防げるなら、手順書から1行消せます。どの工程をシステムに任せるかの選び方は、[業務フローのシステム化と対象工程の選び方](https://www.issoh.co.jp/column/details/15783/)で解説しています。 ### Excel・Word・社内wikiで足りる規模と文書管理システムを入れる境界 手順書が数十本までで、更新する人が数人に限られるなら、WordやExcelのひな形と共有ドライブ、または社内wikiで十分です。この段階で専用の仕組みを入れても、運用ルールが決まっていなければ効果は出ません。画面録画や手順の自動生成など、作る側の手間を減らす製品の比較は[マニュアル作成ツールの4タイプと選び方](https://www.issoh.co.jp/column/details/13551/)にまとめています。 文書管理の仕組みを検討する目安は、手順書が数百本に増えた、承認の記録を残す必要がある、部署ごとに閲覧権限を分けたい、の3点です。版の管理とレビュー期限の通知、承認の流れを既存の業務システムや社内の認証基盤とつなぐ必要がある場合は、既製品の設定だけでは足りないことがあります。一創の[文書管理システム開発](https://www.issoh.co.jp/service/business%5Fsystem/document-management/)では、版管理・承認フロー・権限設定・全文検索を、既存の社内システムに合わせて設計から開発しています。 ## よくある質問 手順書の作り方について、よく寄せられる質問に答えます。 ### 手順書とマニュアルの違いは何ですか？ 手順書は1つの作業を終わらせるための操作の順番を書いた文書で、マニュアルは業務全体の目的・流れ・役割・決まりを説明する文書です。マニュアルが「何のために、誰が、どの順で業務を回すか」を示し、手順書は「この作業を、どの画面で、どう操作するか」を示します。業務マニュアルの中に手順を全部書き込むと探しにくくなるため、マニュアルを目次として、個々の作業は手順書へリンクで分ける構成が扱いやすくなります。 ### 手順書はWordとExcelのどちらで作るのがよいですか？ 手順が文章中心で画面の画像を多く入れるならWord、手順を表の行として並べ、担当者や確認欄を列で持たせたいならExcelが向きます。どちらを選ぶかより、社内で1つの型に統一することのほうが効きます。手順書が数十本を超え、検索や版管理に手間がかかり始めたら、社内wikiや文書管理システムへの移行を検討する段階です。 ### 手順書に画像やスクリーンショットは必ず入れるべきですか？ 必須ではありません。ボタンの位置が分かりにくい画面や、似た名前の項目が並ぶ画面では画像が役立ちます。一方で、画面の配置が変わるたびに画像の差し替えが発生し、更新の手間が増えます。基本は画面に表示されている名前を文章で正確に書き、画像は迷いやすい箇所に絞って入れるのが、更新の負担とのつり合いが取れた方法です。 ### 手順書はどのくらいの頻度で見直せばよいですか？ 定期の見直しは6か月から1年を目安にし、作業の変わりやすさで決めます。ただし、定期の見直しだけでは画面の変更などに追いつきません。業務システムの改修、帳票や規程の改定、担当者の異動、「書いてあるとおりにできない」という報告があったときにも必ず改訂すると決めておくと、内容が古くなる期間を短くできます。 ### 生成AIで手順書の下書きを作ってもよいですか？ 下書きに使うことはできますが、そのまま公開するのは避けてください。生成AIは、実際の画面にないボタン名や、社内の承認ルールと違う手順をもっともらしく書くことがあります。作業の横で聞き取ったメモや画面の名前を材料として渡し、出てきた文案は、その作業をしたことがない人による試行で確かめてから公開します。 ## 関連記事 - [文書管理システムとは？機能とメリット、ファイルサーバーとの違いと選び方を解説](https://www.issoh.co.jp/column/details/13547/)：手順書を含む社内文書の版管理と権限を仕組みで扱う方法 - [システム運用保守ドキュメントの整備手順｜優先順位と更新が止まらない仕組み](https://www.issoh.co.jp/column/details/16404/)：情報システムの運用手順書に絞った整備の進め方 - [RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説](https://www.issoh.co.jp/column/details/12919/)：蓄積した手順書を生成AIで検索・回答させる仕組み --- 出典: [手順書の作り方：業務手順書の構成・書き方ルールと古くならない更新運用【2026年】]()（株式会社一創）