t_wの輪郭

最近、ITベンダーが書いたドキュメントの「その他」の章に、書き手の伝えたい気持ちが強い情報が書かれている可能性が高いことに気づいた。

「この情報はどの章にも入らないけど、これは絶対伝えておきたいからその他の章を立項するか」という感じ。

仕様をまとめたドキュメントをAIが全部かいてくれればいいのにと思いながら書いてない。

スタティックな「ドキュメント」が不要になるかも。

「ソースコード読め」から「AIに聞け」へ変遷する。

https://dev.classmethod.jp/articles/creating-documents-that-drive-actions/

Wordでドキュメント書くの、最初はMarkdownを変換してdocxファイル生成したらぁ！とか思ってたんだけど、Wordで書くのが思いの外楽しい。

Wordのアウトライン表示が楽しいんじゃ。

• 文章を書く序盤→アウトラインが書けて楽しい
• 文章を書く中盤→アウトラインがそのまま見出しになって楽しい
• 文章を書く終盤→文章の塊を見出し単位で簡単に移動できて楽しい

ドキュメントがWordで20ページぐらいになりそう。理系の卒論やん。

ドキュメント書くのめんどくせーなと思ってたけど、Wordのスタイルをいじってたら興が乗って文章が生えた

理想のプロジェクトマネジメントツールには当然に知識管理機能が融和的に内包される。

タスク・メモ・ドキュメントが同一の機構で扱えると良い。

質の良いドキュメントの形なら少なくとも読者人数の増加に対して執筆側の消費時間は定数なので，まずはドキュメントを整備すべきだ．

会社で知識や技術の共有をうかつにやったらパクられるだけで大損じゃん。誰が二度とするか。

エンジニアにとっては知識や技術が収入の源泉（知識が資本）だから、それらを供出させるのは難しそう。ドキュメントを書く専門の人（テクニカルライターとか）がいればまだマシなんだろうか。開発とドキュメンテーションの分離という感じで。

https://gfngfn.github.io/ja/posts/2022-06-18-be-a-documentation-geek/

ドキュメンテーションを引き受ける作業者がいれば、開発者は開発に集中できる

技術的なドキュメント化はあらゆるプロジェクトに求められる汚れ仕事である。 適切なドキュメントを書いて、保守することは、プロジェクトチームが後で使ううえで重要だ。しかし、こうしたドキュメントは誰が書くというのだろう？ 開発者が自分でドキュメントを書いたら、「実際の」作業の妨げになってしまう。

それゆえ:
必要なドメインをよく知っていて、設計自体には利害関係のないテクニカルライターを雇おう。 適切な記法を用いて設計を表現してもらおう。整えたうえで公開し、レビューしたり、組織で使えるようにしてもらおう。

from 『組織パターン』