エンジニアと文章文書のマトリックス

table:m

エンジニアしか見ない エンジニア以外も見る

しっかりした文書 1 2

ラフな文章 3 4

言えること

1だけじゃなくて3もあるといい

3をする場合、ある程度ツール、フォーマット、ガイドラインを定めた方がいい

2は一種のボトルネックで、DXできる部分

各象限について

1 エンジニア向け文書

ガイドライン、規約、リファレンスなど

対象がエンジニアなので手段はこだわれる

Markdown + 自動ビルドでリリースするなど

しんどいのは中身の記述、メンテ、レビュー

これしかないとしんどいので、ラフがあると良い

2 全社向け文書

想像以上に手間暇かかっている部分

読者が欲しい情報を探す手間

文書を更新する側が更新する手間

本質的に煩雑なプロセス

ここを1（エンジニア向け）の水準に近づけることができれば、グンと手間暇が減る

もちろん文書の強さ的にそうできないケースもある

極論、就業規則レベルの根幹はほいほい変えられるものではないだろう

あえて「誰でも意見できるよ」として変えられるようにする組織もありそうだが

脱PWEPしている事例もある

3 エンジニア向けラフ

エンジニアによって書いていたり書いていなかったり

書いていても見える場所に置いてなかったり

これをn人で共有・読み書きできるようになると楽になる

ある程度ツール、フォーマット、ガイドラインを定めた方がいい

エンジニアだからといって「自律的にラフメモを上手く共有できる要領」を持っているとは限らない

「このやり方に従って雑に残せばいいっすよ」 ← これを定める

4 全社向けラフ

ここは例が無さそう

そもそもラフに文章を残すという行為は一般人には縁がない