手順書を作成する時の考え方

はじめに

システム開発や運用保守の現場では、「手順書」が業務の品質を左右します。
ただし、手順書を「とりあえず作る」だけでは、後から見返した時にわかりにくく、誤解を招くこともあります。
この記事では、実務で役立つ「手順書作成の考え方」を、構成や思考プロセスに焦点を当てて紹介します。
「何を書くか」よりも、「どう整理して、どう伝えるか」に重きを置いた内容です。

作成方法

🗒️下書き

最初から完璧な手順書を目指すのではなく、まずは「頭の中の流れを外に出す」ことから始めましょう。
下書きの段階では、文体や表現よりも「抜け漏れなく、全体像を把握できる」ことを目的にします。

①ボトムアップで洗い出す

最初はトップダウンではなく、「実際に行う操作」から箇条書きで洗い出すのがおすすめです。

• どの順番で操作しているか
• どの画面で作業しているか
• どんな前提条件が必要か

②文章を整理する

次に、洗い出した箇条書きを「文として伝わる形」に整えます。
この段階では、以下のような観点でリライトします：

• 主語と動作を明確に（誰が、何をするのか）
• 一文を短く
• 手順番号を付与して可読性を高める

③共通処理がある部分を探す

複数の手順書を作る場合、「共通部分」を早めに見つけて整理すると効率的です。

たとえば「AWSコンソールへのログイン手順」などは毎回書かず、別紙化または共通テンプレート化しておくとよいでしょう。

✅ ヒント：
「毎回書いている操作」「どの手順書にも出てくる処理」は共通化候補です。

④別紙参照にした方がいい場所を探す

逆に、1つの手順書に詰め込みすぎると読みにくくなるため、分割も検討します。

たとえば：

• 「環境構築手順」と「初期データ登録手順」は別紙化
• 「共通の設定ファイル編集手順」は別ドキュメント参照

目的が異なる作業は、別紙や別リンク参照にするのがコツです。

✒️清書

下書きで構造を作ったら、次は「読む人に伝わるように整える」段階です。
ここでは、業務フローの理解と例外パターンの明示がポイントです。

①業務の一覧の流れを清書する

まず、業務全体の流れが俯瞰できるように、冒頭に「全体フロー」を載せましょう。

• 開始条件
• 手順の順序
• 成功条件（完了条件）

②例外処理を清書する

現場では、「想定外のケース」が発生することもあります。
そのため、「正常系」だけでなく「例外系」も明記しておくと安心です。

✅ 重要：
「エラーが出たら止まる」のではなく、「次に何をすればよいか」がわかる構成にしておくこと。

Tips

手順書作成をスムーズに進めるためのちょっとしたコツです。

• 図解・スクリーンショットを活用する
  → 文字だけでは伝わりにくい箇所は、図や画像で補足する
• レビューを依頼する
  → 他人に読んでもらうと、「伝わらない箇所」が浮き彫りになります
• 前提条件・使用環境を明記する
  → OSやバージョンの違いで手順が変わる場合は特に重要
• 定期的に見直す
  → システム変更や仕様更新のたびに「手順書の陳腐化チェック」を行う

まとめ

手順書は、「人が理解できるコード」のようなものです。
正確さだけでなく、読み手の視点を意識して構成することで、誰が読んでも同じ結果を再現できます。

ポイントを振り返ると：

• 下書きでは「抜け漏れ防止」
• 清書では「理解のしやすさ」
• 定期的な更新で「信頼性維持」

単なる作業記録ではなく、「チームのナレッジ資産」として機能する手順書を目指しましょう。

✍️ おまけ：もしチーム全体で統一したい場合は、「手順書テンプレート」を作成しておくと便利です。
構成を固定しておくことで、品質のばらつきを防げます。