（ドキュメント＝自分たちのためのドキュメント、という体）
ドキュメントを用意する、というのは一定面倒なタスクではあるけれど、なぜ面倒なのかを考えてみると、こんなところがあるんじゃないだろうか。
- 全部を書かなくちゃいけない
- ぶっちゃけ仕様がわからない
- どこまで書いたらいいかわからない
- どういう構造が適切かわからない
- コードがドキュメント
- 図を作るのが面倒
- 陳腐化する（更新が必要）
究極、自分たちの頭の中に全部あって、全部共有されていて、という状態であればドキュメントなんてなくていいだろうけれど、まあなかなかそうはいかない。現実には、あれなんだっけ、これなんだっけ、人が来たので説明しなくちゃ、などなど色々ある。そうするとドキュメントがあると何かと便利なので用意したくなる。
そして、ドキュメントを用意しようというときに、最初から超完璧なものを用意できればそれが一番いいけれど、そんなことをしていると時間がかかる。なので、小さくリリースを繰り返して育てていく、というのがいいのではないだろうか。
PRでは一つの大きなものでドドン！とするとレビューに時間もかかるしリリース時の大変さも増える。たとえば、ペアプロでPRの大半を作ってレビュー時間を削減したり、機能はあるけど有効にはなっていない状態、とかできると大きなPRでも問題は少ないかもしれないけれど…。なので、小さいPR、小さいリリースを頻度を上げて繰り返すことでリードタイムや負荷を減らすのがいいと思っている。
これと同じ話をドキュメントでも言える。ドキュメントも一度にドドン！ではなく、小さくリリースを積み重ねたい。
さらに、プロダクト開発はコードを書いて機能を増やしたり減らしたり、コードの構造を変えて開発しやすくしたりをするけれど、これとドキュメントもまったく同じだろう。ドキュメントそれ自体もプロダクトとして捉えたほうがいいかも。
プロダクト = ドキュメント（自分たちのドキュメント）、であれば、ユーザ = 同じチームの人たち、になる。他にも…
- 新機能の開発 = 新規ドキュメントの執筆
- 機能の改善 = ドキュメントの加筆/修正
- 機能のリリース = ドキュメントの公開
- 機能の削減 = ドキュメントの廃止
- 機能提供のためのコードをリファクタリング = ドキュメント構造・内容の見直し
- 他プロダクトとの連携 = ドキュメントのリンク、引用
- 悪いUX = 自分たちがドキュメントを活用できていない
などなど…。他にもプロダクト開発でこういうことしてるよな、というのは全部当てはめられるはず。
そう考えてみると、自分たちが使う自分たちのためのプロダクト=ドキュメントを育てるのは、プロダクトの価値を向上させるためにコードを書いてプロダクトを育てている、と同様だし、育てるのをやめてしまえば、ユーザが離れていってしまう=自分たちがドキュメントを使わなくなる、というのも理解しやすい。
小さく更新を積み重ねていくのであれば大変さも少ないので、やりやすいのではないだろうか。
とはいえ、やっぱり面倒な部分はある（もっと要素を分解できる）ので、それぞれ現実的にどうするかはまた別の話…