新しいツールの使い方を、記事にまとめようとした日の話。
最初に書こうとしたものと、最後に残したものが、まるで逆になった。
「正しい手順」をきれいに並べようとした
最初に考えたのは、ごく普通の手順書だった。
アカウントを作って、ここを設定して、こう繋いで、はい完成。
うまくいく流れを、つまずきのない一本道として並べる。
読む人が迷わないように整える、それが親切だと思っていた。
書きながら、自分でも気持ちよかった。
手順が一直線に決まっていくと、いかにも「分かっている人の記事」っぽく見える。
スクリーンショットも、緑のチェックがついた成功画面ばかりを撮っていた。
でも、できあがっていくのは「うまくやれた自分を見せる記事」だった。
「困っている人を助ける記事」ではなかった。
半分くらい書いたところで、ふと手が止まる。
これ、本当に誰かの役に立つんだろうか。
正常系は、ぜんぶ公式が持っている
冷静に考えると、うまくいく手順は、たいてい公式のドキュメントにもう書いてある。
しかも公式のほうが正確で、更新も早い。
私がなぞって並べ直したところで、ただの劣化したコピーにしかならない。
人が検索して、わざわざ個人の記事までたどり着くのはどんな時か。
たいていは、公式どおりにやったのに動かなかった時だ。
検索窓に打ち込んでいるのは、たぶんエラーメッセージそのものだったりする。
- 赤いエラーが出た
- 設定したのに反応しない
- 画面が真っ白になった
そういう「詰まった瞬間」に、人は同じところでつまずいた誰かの記録を探している。
つまり読者が本当に欲しいのは、成功した画面じゃない。
私がさっき撮らずに飛ばしていた、失敗した画面のほうだった。
思い返せば、自分が誰かの記事に救われたのも、いつも失敗のときだった。
途方に暮れて検索して、「私もここで詰まりました、原因はこれでした」の一行に、何度も助けられてきた。
あの小さな安心を、今度は自分が次の誰かに渡せばいい。
そう思ったら、何を書くべきかが急にはっきりした。
失敗の記録は強い。でも混ぜると毒になる
そこで方針を変えた。
わざとつまずきそうな所を、自分から踏みにいく。
エラーを出して、その画面を撮って、どう直したかまで残す。
これは公式には絶対に載っていない、自分だけの一次情報になる。
ただ、ここで一つ大事な落とし穴に気づいた。
失敗には、まったく性質の違う二種類がある。
- 設定ミス：手順を間違えた、値を入れ忘れた。つまり自分が悪いやつ。
- 製品の不具合：正しくやっても起きる。つまり向こうが悪いやつ。
この二つを混ぜて「こうしたら直りました」と書くと、危ない。
本当は設定ミスが原因なのに「再起動したら直った」とだけ書けば、再起動が万能薬みたいに見えてしまう。
読んだ人は、自分の環境では直らない手順を握らされて、よけいに迷う。
良かれと思って、直らない解決法を配ってしまうことになる。
だから、直ったからといって、すぐ「解決法」にするのは早い。
なぜ直ったのか、原因のところまで自分で説明できるか。
そこを確かめる前は、ただの「たまたま動いた」を再現手順のふりで渡しているだけだ。
撮るのは、失敗画面と直し方。そして分けて書く
最終的に、手順書はこういう形に落ち着いた。
残すのは、うまくいく流れではなく、つまずいた画面とその直し方。
そして失敗を書くときは、二つをはっきり分ける。
- 直せるミスは、原因と直し方をセットで書く。
- 直せない不具合は、回避策と「これは向こうの問題です」の但し書きを添える。
分けておけば、読む人は、自分のケースがどっちなのかを自分で判断できる。
同じエラー画面でも、原因が自分側か製品側かで、打つ手はまるで変わる。
そこを混ぜないことが、いちばんの親切だった。
価値があるのは「完璧にできた記録」じゃない。「つまずいて、直した記録」のほうだ。
成功は誰のものでもないけれど、失敗の直し方は、その時その場にいた自分にしか書けない。
きれいな手順は公式に任せて、私は転んだ場所の地図を描く。
次にツールを触る時は、緑のチェックより、赤い画面を先に撮ろうと思う。