思い出したように本棚から文庫本を出してきてはすきまの時間を見つけて読んでいた。しかしそれも長くは続かない。好奇心というか物事に対する興味が薄れいているような気がする。なにかが蓋をしているという言い方もある。結局はいま作成中のWebサービスを作りきらないと前に進めない。そういうことなのか。
Backlogのユーザーコミュニティの勉強会に参加した。今回のテーマはドキュメント。どの業界でも職種でも、ドキュメントには向き合う必要があるようだ。
中野さんの発表。良かった。構造化とは伝えたい項目をもれなくダブりなくまとめることである。「網羅的かつ誤解なき言語化」という言い方がしっくりきた。しかし、単純にそれだけではない。ドキュメントは問題解決のために作るもの。「誰に何を伝え、最後にどうなれば良いのか」を見据えて書くのだと。問題が解決できるのであれば枠組みからはずれても構わない。なるほど。
AIが台頭する昨今、ドキュメントを書く意味を考え直さないといけない。彼らもドキュメントを作成してくれるのだが、こちら側の指示も大事だ。答えだけを尋ねるのではなく、答えにたどりつくために必要そうな項目を考え、それらを適切な粒度・順序でまとめてから指示を出す。そうすると良い。
そうか。
私も少しだけ話をした。ドキュメントはあまり整備されず使われることはないが、それでも現場の声を聞けば少しは良いものにはなるだろうということ。「じゃあどうやってやるか」を考えていたけど、今回の勉強会でなんとなく見えてきた。Backlogのドキュメント機能を使ったらいいのではないか。
Backlogの新機能である「ドキュメント」はWikiとは異なり、リッチテキストをそのまま使うことができる。非IT系の人間にとってMarkdown記法は馴染みがないからやりやすそうだ。変更管理、差分管理もできるようだ。単純なエクセルだと「誰がなにをいつ変えたか」がわからない。これはできる。良い。
あとは機械設計書、ライン設計書をドキュメントでつくるのも良い。図面管理とはまた別の考えだ。その仕様にいたった経緯が後任にも伝わりやすい。別途で「過去の不具合リスト」をつくっておき、それを参照させるというやり方もできそうだ。
Backlogはプロジェクト管理のツールという認識だったが、ドキュメントの運用・管理のツールとしても使えそうだ。ちょっと社内で使えるように調整しないといけない。
所用で帰ることになってしまい残念だった。次は最後まで参加したい。
