Booklog - ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング

前回が軽かったので今回は積読消化回。積み過ぎて日があたってたところのオレンジが褪せてる。 わたしは仕事でサブシステムを作ったら文書や障害対応の手引なんかを書くのは結構好きだ。 それに対し称賛されることもあるけど、逆にしょーもないことすんなと批判されることもある。 書いてもコイツラ読まへんなーという状況も常にあるので、なんかきっかけを掴めたらいいな。 「ドキュメントは機能の 1 つ」、いいなあ。はじめに、は入門 Kubernetes の人。 この本はツールになるべく触れてないらしく、良い。ツールで解決できたら誰も困ってないもんな。

2024-09-15, read count: 1, page: 1 ~ 28

chapter 1 終わり。 この本でも届けたい相手のペルソナを作る。「遠くへ行きたければ、みんなで行け」でも「インディゲームサバイバルガイド」でもそんな感じだった。 仕事ではガチでやるのは当然として趣味レベルでサクッと始めるには重いな。呼吸をするようにペルソナを作れるようになれってことなのか。 社内向けにはあえて知識の呪いにかかったまま文書を書くこともあるけど、どうなんやろね。ペルソナにそぐうならいいのかな。

2024-09-16, read count: 1, page: 29 ~ 46

chapter 2 終わり。 ドキュメントのタイプとパターンというのは意識して考えたことなかったので学びになった。 届けたい先に合わせて提供するパターンが変わる。ここは何度か噛みしめるように読もう。

2024-09-17, read count: 1, page: 47 ~ 68

chapter 3 ドラフト。 ドキュメントの構成要素を使い分け、流し読み上等で簡潔に、重要なことははじめに書く。 完璧を目指さず満たすべき要素を網羅してるか注意して初版を書き上げたら一歩踏み出せたと。 なかなか普段ここまで考えて書いてないなって気がするわ。

2024-09-18, read count: 1, page: 69 ~ 92

chapter 4 編集。 技術的な正しさと必要うな情報の完全性はやってそうやけどその後の構成とか簡潔さの編集は中々訓練してない難しそう。 フィードバックの受け方送り方。 plussing は覚えとこう。 ストーリーにもあるけどコードレビューと同じなので HRT を意識したいところ。

2024-09-19, read count: 1, page: 93 ~ 106