0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術力以前の壁。誰が読んでも迷わない「手順書」を書くための3つの鉄則

0
Posted at

技術力以前の壁。誰が読んでも迷わない「手順書」を書くための3つの鉄則

はじめに

「手順書を読んでも、結局どこを操作すればいいか分からない……」
「自分で書いた資料を先輩に見せたら、『意味が通じない』と突き返された」

インフラエンジニアの仕事の半分は、実は「文章」です。特にSESでは、現場が変わるたびに大量のドキュメントを読み、また自分の作業を後に残す必要があります。

はじめまして、ハンズオンラボ運営メンバーの「えむ」です。
私は6年間のエンジニア生活の中で、数多くの「解読不能な手順書」に泣かされてきました。その経験から気づいたのは、良い資料を作るのに「高度な技術力」は不要だということです。

今回は、現場で「えむさんの資料は分かりやすいね」と信頼されるための、文章のコツをお伝えします。


1. 「主語」と「目的」を絶対に省略しない

具体的なエピソード

以前、先輩が書いた「設定を確認し、反映する」という1行の手順で、私はパニックになりました。「どの画面で?」「何の設定を?」「反映って、サービス再起動が必要なの?」……。

なぜ困ったのか

書いた本人には「当たり前」の前提条件が、読む側には全く伝わっていないからです。これが作業ミスや事故の引き金になります。

どう解決したか

私は、すべての手順に**【誰が・どこで・何を・どうする】**を徹底して入れるようにしました。

  • ×:設定を変更する
  • ◯:【作業者】が【/etc/httpd/conf/httpd.conf】の【80行目】を【443】へ書き換える
    これだけで、誰がやっても同じ結果が出る「プロの資料」になります。

2. 構成図を「情報の整理棚」にする

具体的なエピソード

複雑な構成図を見て、どこから手を付ければいいか途方に暮れたことはありませんか?私はドキュメントを書く際、図をいきなり書き始めるのをやめました。

どう解決したか

図を書く前に、**「今から話すのは、ネットワークの話か? サーバーの中身の話か?」**と、情報のレイヤーを分けました。

  • 全体像(鳥の目):システムの繋がりを示す
  • 詳細図(虫の目):特定のサーバー内の設定を示す
    この「視点の切り替え」を意識するだけで、相手に伝わる速度が劇的に上がります。

まとめ

ドキュメント作成は、次に作業する人への「思いやり」です。

  • 主語と目的を明確に: 「なんとなく」を排除する。
  • レイヤーを分ける: 一つの図にすべてを詰め込まない。
  • 読み手に成り代わる: 初めて読む人が迷わないか、一歩引いて見直す。

一緒に学びませんか?

「ドキュメントの読み解き方がわからない」「技術を言語化するのが苦手」という方へ。
ハンズオンラボでは、実際に手を動かした内容を「自分の言葉でまとめる」練習も大切にしています。

✅ アウトプットすることで、技術の理解がさらに深まります
✅ 現場で役立つ「伝わる資料」の作り方を共有し合えます
✅ 仲間からのフィードバックで、自分の癖に気づけます!

📍 connpassページ: https://zeki-chan-lab.connpass.com/event/

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?