普段メンテナンスしているプロダクトの仕様について、うまいストック情報を作れていないという課題感があって、世間のノウハウを知ろう、とKindleで適当に買った本を読んでみた。
スクラムチームに所属しながら製品のコンシュマー向けのドキュメントを書くためのテクニカルライティングの本。
読書メモ
- アジャイル開発について学んでもライターについての記述はなく、ステイクホルダーにも入っていない
- 包括的なドキュメントよりも動くソフトウェアを、という宣言があるけど、コンシュマー向けのドキュメントが不要になるわけではない
- ドキュメントを書かずにプロダクトを作り終えたり、完全にプロダクトを作り終えてからドキュメントを書くことができるプロダクトも存在する
- メールアプリのドキュメントを読んだことがありますか?
- スクラム環境でドキュメントを作るには2つのパターンがあり、デベロッパのスクラムチームに所属するパターンと、情報部門(Information Engineering Team)に所属するパターン。アジャイルの各工程 x 2パターン、でそれぞれどのように振る舞うとよいかが記されていて、さくさく読んでいこうとすると、では次の場合は…みたいになってテンポが落ちる
- スプリントでの開発とドキュメントをどのように折りをつけるか、3パターン紹介されていて、開発が終わってからスプリントを始める、というウォーターフォールっぽいもの、関連するストーリーとして同じスプリントで取り組む、同じストーリーで取り組む、という3パターン
感想
新機能とその告知ブログをセットでリリースしているような開発をしているチームの人たちにはおすすめの本だと思った。開発とドキュメントづくりがうまく連携しない場合の例としては、エンジニアが一通り開発して、QAが済んでから、では告知のブログを書きましょう、とやっていると、書いたコードをマージできない間に他の開発が進んでコンフリクトしてしまったり、開発と告知の編集のあいだに情報の分断が起きていることがあった。
また、最近チームに所属する人の職種が増えているので、職種ごとに、どのようにアジャイル開発に関わっていくかという方針建てが必要なのだなと思って、この本ではライターはステイクホルダーとみなされていない、という話だったけど、いろんな立場の人がうまいこと活躍したり、情報の分断が起きないような取り組みがあるとよさそうだな、と思った。チームがでかくなると全員で集まるのも難しくなっていくけどそれは別の話で、ピザの枚数で制限をかけましょうという話があったり、組織構造とソフトウェア構造を一致させましょうという話があったりする。
タスクのチケットごとにドキュメントの更新が必要かどうかをトラッキングできるようにしましょう、という話がのっていて、ドキュメントが成果物の第一級の仲間たちとして認められている世界が提示されていた。実装とドキュメントづくりが同じユーザーストーリーなら、マージしたりレビューしたりするまでの間にドキュメントのレビューも入るはずで、実はここも変更が必要ですとか、専門的な知識が必要となるレビューが始まりそう。そのようなレビューができる人を得るにはどうしたらよいのか、数年ごとに社内のチームをあちこち異動していると、知識の定着がなくて難しいのではないか、とか考えていた。
どのようなドキュメントをどのように整備すれば運用中のソフトウェアの仕様を必要十分に記せるのか、というヒントを得たかったけど良いアドバイスは得られなくて、ドキュメンテーションを支える人の暮らしについて教えてくれる、という本だった。
