手順書の読み方

ストーリー

「手順書があるのに、なぜか失敗しちゃうんです...」

「どう読んでる？」

「えっと、とりあえず上から順に...」

「手順書には正しい読み方があるんだ。それを知らないと、手順書があっても失敗する」

手順書を読む前にやること

1. 全体を一度通読する

いきなり手順1から実行してはいけません。

NG: 手順1を見る → 実行 → 手順2を見る → 実行 → ...
    → 後から「あ、これ最初に準備が必要だったのか...」

OK: 全体をざっと読む → 前提条件を確認 → 準備 → 手順1から実行
    → スムーズに完了

2. 前提条件をすべて確認する

手順を実行する前に、前提条件を満たしているか確認します。

markdown

## 前提条件
- [ ] Node.js 18以上がインストールされている
- [ ] AWS CLIが設定済みである
- [ ] 管理者権限を持つアカウントでログインしている

bash

# 確認コマンドの例
node --version  # v18.0.0以上か？
aws --version   # インストールされているか？
whoami          # 正しいユーザーか？

3. 所要時間を把握する

作業時間の目安: 約30分

→ 30分確保できる時間帯に作業を開始する → 急いでいるときや終業間際に始めない

4. トラブルシューティングの場所を把握する

「何かあったときにどこを見ればいいか」を先に確認しておきます。

→ ページ下部に「トラブルシューティング」がある
→ 困ったらそこを見ればいい

手順書を読むときのポイント

1. 「なぜ」を意識する

markdown

手順:
1. config.json の "debug" を "false" に変更する

「なぜ」を考える:

本番環境ではデバッグ出力を無効にするため
パフォーマンスやセキュリティのため

→ 理由がわかると、手順の意味が理解でき、応用が利く

2. 確認ポイントを見逃さない

markdown

3. デプロイコマンドを実行する
   ```bash
   npm run deploy

【確認】以下のメッセージが表示されることを確認する
```
Deploy completed successfully.
```


**確認を飛ばさない:**
- 確認せずに次に進むと、途中で失敗していても気づかない
- 後から問題が発覚すると、どこで失敗したかわからない

### 3. コマンドはコピペする

```markdown
以下のコマンドを実行:
```bash
ssh -i ~/.ssh/mykey.pem ec2-user@12.34.56.78


**手打ちしない:**
- タイプミスのリスクがある
- 特に長いコマンドや複雑なオプションは危険

NG: ssh -i ~/.ssh/mykey.pem ec2-user@12.34.56.79 ↑ 1文字違い

OK: コピペで確実に


### 4. 変数部分を見落とさない

```markdown
```bash
ssh -i ~/.ssh/mykey.pem ec2-user@<サーバーIPアドレス>


**<> や [] で囲まれた部分は自分で置き換える:**

NG: ssh -i ~/.ssh/mykey.pem ec2-user@<サーバーIPアドレス> （文字通り入力してしまう）

OK: ssh -i ~/.ssh/mykey.pem ec2-user@12.34.56.78 （自分の環境の値に置き換える）


### 5. 警告やNoteを読み飛ばさない

```markdown
> ⚠️ **警告**: この操作は取り消せません。実行前に必ずバックアップを取ってください。

> **Note**: 本番環境では管理者の承認が必要です。

警告は特に重要:

取り返しのつかない操作の前には警告がある
読み飛ばすと大きな問題になる可能性

手順書を読んで実行するときのチェックリスト

markdown

## 実行前チェック
- [ ] 全体を一度通読した
- [ ] 前提条件をすべて確認した
- [ ] 所要時間を把握し、十分な時間を確保した
- [ ] トラブルシューティングの場所を把握した

## 実行中チェック
- [ ] 各手順の確認ポイントで結果を確認している
- [ ] コマンドはコピペしている
- [ ] 変数部分を自分の環境に置き換えている
- [ ] 警告やNoteを読んでいる

## 実行後チェック
- [ ] 完了確認の項目をすべてチェックした
- [ ] 問題があればトラブルシューティングを参照した

手順書が不明確なときの対処

1. まず自分で調べる

不明点: 「設定ファイルを編集する」→ どの設定ファイル？

調べ方:
1. 前後の文脈から推測する
2. プロジェクトの他のドキュメントを確認する
3. ファイル名で検索する

2. 質問する

調べてもわからない場合は、具体的に質問します。

悪い質問:
「手順書がわかりません」

良い質問:
「手順3の『設定ファイルを編集する』は、
 config.json と settings.yaml のどちらを指していますか？」

3. 改善提案をする

不明確な点が見つかったら、手順書の改善を提案しましょう。

markdown

手順書へのフィードバック:
- 手順3で「設定ファイル」とありますが、config.json を指すと明記した方が良いと思います
- 手順5の確認ポイントがないので、追加を提案します

手順書に従わない場合のリスク

行動	リスク
前提条件を確認しない	途中でエラーになり、最初からやり直し
確認ポイントを飛ばす	問題に気づかず、後から大きな障害に
警告を読み飛ばす	データ消失や取り返しのつかない事態
手順を飛ばす	不完全な状態で完了したと思い込む
自己流でアレンジ	想定外の問題が発生

まとめ

ポイント	内容
実行前	全体通読、前提条件確認、所要時間把握、トラブルシューティング場所確認
実行中	確認ポイント実施、コピペ、変数置換、警告確認
不明時	自分で調べる → 質問する → 改善提案

チェックリスト

手順書を読む前にやるべきことを4つ挙げられる
実行中に気をつけるポイントを理解した
手順書が不明確なときの対処法を理解した

次のステップへ

手順書の正しい読み方は理解できましたか？

次のセクションでは、いよいよ「手順書を書く」ことに挑戦します。読み方がわかれば、良い手順書の書き方もイメージしやすいはずです。

推定読了時間: 30分