00:00
こんにちは。言語化.fmは、あんな話やこんな話を、キリンとダテの2人で緩く話しながら、言語化を試みるポッドキャストです。
はい、というわけで、今回第11回目は、いいドキュメントとは何かということについて、言語化を試みたいです。
言いましょう。
お願いします。
お願いします。
意外と多分、ちゃんと言語化をしたことない、
したことあるっちゃあるんだが、
盲点というか、話してそうで話してなかったトピックだなという気はしていて、
いいテーマだなという気持ちなんですけど、
ここで言うドキュメントってどうだろうな。
基本的には会社で、どっかの組織とかチームで働くときのストックされる情報とか文章の話かなと思ってるんですけど、
そうですね。
なんかいいと思うドキュメントはどんな感じですか、ダテ氏。
初っ端からぶん投げるっていう。
端から飛んできたけど。
そもそも前提としてさ、ドキュメントされてるのは偉いっていうのがあるよね。
確かに。
そうだね、その分岐があるね、最初に。
確かにね。
偉いんだよ。
どういったものがドキュメンテーションされてるかっていうのを考えると、
もちろん会社の基本情報とか、頻繁に参照する情報は、
もちろんそういうのは放っておいてもされるから別によくって、
これあるとめちゃくちゃ嬉しいなっていうドキュメントなんだろうって考えたら、
やっぱ歴史なんだよね。
なるほど。
歴史。
どういう道筋を悟って今ここにいるんですかっていう、
その時点のスナップショットがあるとすごくいい残し方してるなって思って、
なんでそう思うかっていうと、
やっぱ初期からやってるメンバーとかは文章化されなくてもなんとなく知ってるわけじゃん。
こういうタイミングでプロダクトを出して、
具体的な日付とかはさ、人間の教育は脆弱だから飛んでくんだけど、
どういうプロセスでやったかっていうのは割と頭の中にあるわけじゃん。
それと同時にどういう失敗をしたのかみたいな、
こういう失敗をしたとかこういうデメリットが見えたのでこういう風になってますって説明可能じゃん。
それがないと新しく入ってきた、
その会社のドメインがまだそんなにない人が、
こっちの方がいいんじゃないっていう無邪気な変更をやって、
03:06
文章化されてなかったけど実はこれはこうで、こうでっていう説明を古川文の人がしなきゃいけなくて、
結構手間になってしまうというのがあって、
わざとやることもあるけどね、たぶん歴史的経緯でこれはこうなってるんだろうっていうのを勝手に読み取ってきつつも、
無邪気にこっちの方がいいでしょうプロリクエストを投げることもあって、
それが通ればそれでもいいわけじゃん。
だけどそこで否定されることによって初めてアンチパターンとしてドキュメンテーションされるみたいな、
そういうなんか積み重ねになっていると、
いいドキュメントだなって思うことが最近はありますね。
なるほどね、今の話の中にも切り口が無限にありすぎてマジ、
5時間ぐらい喋れるなみたいな気持ちだけど。
でもそうだね、歴史は大事だし、
またコンテキストとか背景を、文脈とか背景をきちんと共有するためのドキュメンテーションが整っているっていうのはかなり尊いなっていう気はするね。
後から入ったメンバーとか、後から入ったメンバーでなくても別のチームのメンバーとか別の職種の人が、
なぜこうなってるのかとか、なんでこの意思決定をしたのかみたいなのをつかみたいときに、
それをつかみに行ける場所にきちんと情報があるっていうのは確かにめちゃくちゃ大事だね。
いやー、どう切り込んでいくのがいいかな。
なんか今の話を、脳内でいいドキュメントをどう分解するかすごい考えてて、
今の話は、どういうコンテンツを残すべきかみたいな話じゃないですか。
あとは、その他にも個人的には、どういう形で、ちょっと上手い言語化ができないけど、どういう形で残すべきかみたいな話もあると思ってて、
それに関しては、実は僕は以前言語化したことあるんで、そこそこパッと答えられて、
どういう形がいいかっていうと、前言語化したのに忘れちゃったな。
あれだ、誰でもアクセスができる状態であることと、すぐにたどり着けることと、たどり着いた情報の質が高いこと。
だからそれで言うと、3番目のやつが背景をつかめるものになってるよねとか、歴史以外のコンテンツっていうのもドキュメントにあると思うから、
06:01
その内容、内容に適したフォーマットとか、情報の抽象度とか流度でまとめられてるのがいいよねみたいなのを、昔言語化した記憶があるっていうのを思い出した。
その3つのポイントの最初の2点は、今はNotionっていう素晴らしいドキュメントデータベースがあるから割と解決されてるんだけど、
昔は誰でもアクセスできて検索がとても容易ですっていうようなサービスってあんまりなかったんだよね。
なかったっていうとちょっとあれかもしれないけど、個人的にはやっぱりコンフルエンスみたいなものはすごくかっちりした思想で、
多分好きな人は好きだと思うんだけど、そもそもアプリケーションがとても重くてサクサク検索できないっていうストレスを抱えるので、
実はあんま好きじゃなくて、Notionもとても柔軟な構造化されたドキュメントが作れるのでとても気に入ってるんだけど、
やっぱりどうしてもドキュメントの数が増えてくると重くなったりっていうパフォーマンスの問題にぶち当たったりするから、
まだベストなものはないなと思いつつも、今のところはやっぱNotionが一番近しいもので、すごく使いやすくなってるからこその3番目の質の話だよね。
どうやったら質の高いドキュメントができるかっていう話で、それこそオンシャーの事例とかちょっと聞いてみたいんだけど。
なるほどっすね。それ言うと早速チャブ台を返すんだけど、僕はその2番目のところで実は全く満足してなくて。
あ、そうなんだ。
そうそうそうそう。これはNotionだからじゃなくて、今まで僕が新卒の頃から数えると、口に出しながら数えると、
使ったことあるドキュメンテーションツールはRedmine、Googleドキュメント、内製の聞いたChromeみたいなウィキその1。
あとは、2社目は、これ別に言ってもいいと思うんですけど、ChloeっていうOSSがあるんですけど、当時メルカリのCTOが作ったものと、
コンフレンスと、今はNotionかな、Notion。なんで今何個言った?6個くらい使ってきたけど、
いずれにしても僕は検索は本当に、あとはあれかな、プライベートではScrapboxを使ってるんですけど、
その辺はすごい課題だなーっていう気がしていて、かつ解決とかも正直あんま思いついてないなっていう。
09:02
ただ一種の発生条件と原因は大まかにはほぼ共通してて、
一つは発生条件は、多分一定の流量、一定の情報量を超えると絶対に発生するかなと思ってて、
それは分かりやすいのは多分社員数が多いと、ドキュメントの数が増えるからデータ量が増えていろんな情報が引っかかるようになるよねっていうのが一つで、
いろんな情報が増えたときに各サービス検索エンジンがすごい頑張っていい感じに見つけをしたりスコア評価をしたり、
多分エラスティックサーチを維持維持して表示順をいい感じにしてあげたいとか、タグ検索みたいな概念で頑張ってるんだけど、
それでもうまくいかない理由としては、無限に上げられるけどやっぱパッと思いつくのはストックとフローが混ざってることがやっぱきついなっていう感覚が強くて、
例えば今パッと出したエラスティックサーチのことを、エラスティックサーチの設定周りのドキュメント探したいなと思ったときにエラスティックサーチって打つと、
エラスティックサーチの設定周りと一緒に、例えば日報がそこに突っ込まれてるんであれば、今日はエラスティックサーチの修正しますみたいな日報がバーって引っかかるみたいな。
たしかにね。
すげーあるある。
あるねー。
そうなんですよ、これなーって思って。
じゃあなんかストックとフローを分けるべきかと言われると、
ここから先の領域は僕の中では多分原稿ができてないんですけど、いろんなトレードオフがあるなと思ってて、
書くときに制約を作ると、多分ドキュメントって書かれなくなると思うんですよね。制約を作りすぎると。
例えば日報は絶対にここにしか書いちゃダメとか、ストック情報になり得ないメモは絶対にここにしか書いちゃいけないみたいなルールを細かくどんどん敷いていくと、
多分書く側はめんどくさくなって書かないし、新しく入った人はノリでちょっと書いたらそこ違うんでみたいに言われてめんどくせーってなって書かないとかっていうのがあって、
でもかといって緩くすると、そうやって性質の違う情報がいろんな場所に混在して、それに現代のドキュメンテーションの検査が対応できないみたいな、結構つらいなみたいな感じですね。
その話で言うと、やっぱり情報がストックとフローが混在して一番嫌なのってメンテナンスされてないことなんだよね。フォーマットの話は僕は実はそんなに気にしないんだけど、
もちろんかと言うと、古い情報が引っかかってしまうことの方が会社ドキュメントの場合は嫌なんだよね。さっき歴史は書いて欲しいって言ったけど、それはストックとして残っていて欲しい一方で、どんどんメンテされるべきドキュメントを、
12:19
例えば社内の開発環境への接続の仕方みたいなドキュメントが欲しいと思ったときに、そうやって言ったときに、その生徒ならドキュメントも出てくるんだけど、誰かが入社したときにセットアップしましたみたいなメモが3,4件ぐらいは引っかかってきて、
どこかで詰まるんだったら、その生のドキュメントがアップデートされるべきなのに、生のドキュメントを読んでもわからないから、誰かが残したメモを見て、それを追従していったら、なんとなくセットアップできたわっていう風になってしまうことがあってですね。
それはやっぱり何が原因かっていうと、ドキュメントがちゃんと更新されていないっていうところですね。
たしかにね。たしかに。だから究極を言えば、すべてのドキュメントの質がそれこそ更新され続けて担保されればいいんだろうなと思いつつ、すべてのドキュメントは更新できないんだよな。
そう、なんかそこがさ、ツールだと解決できないような気がしていて、運用の仕方で頑張るところなのかなと思ってしまうんだけど、なんか良い採点はないものかね。
そうね。ちなみに弊社なんかすごい、僕が答えのないブーメランをぶん投げた後に、さっきだてしが聞いてくれた弊社の状況、ユースケースの話をすると、
でもそうだね、ストックとフローの仕分けみたいなのは、結構最初賢いな、入社した時賢いなと思ったのは、ひたすら書き下すだけの超巨大なデータベースが一番トップレベルにあって、みんな最初はそこに書いてねみたいな場所があって、
なんでさっき言ったような、フロー情報に近かったりストックするにはちょっとまだ質の低いような情報はそっちに溜まってて、ノーションの場合は僕がノーション使い始めてから何故か3ヶ月間ぐらい知らなくて、それはちょっとUI直してっていう気持ちで思ってるんですけど、
検索の時に特定のページ配下だけ検索するっていう機能があるから、それを使えばそこそこのノイズは排除できるかなっていう感じでカバーしてるかな。
知らなかったんだけど。
知らないのしょうがなくて、なぜかっていうとフリーワード検索した後に最初出てこないんだよね。何か1回検索した後じゃないとそのフィルターのオプションが出てこないって。
15:12
これか、フィルターってやつね、なるほど。
あとフィルターでインカレントページってやつがあって、これはね、これは気づかんやろっていう。
これ分かんないね。
そうそう。
そうなんだ。
分かんないでしょ、これ。いや、だって分かんないな。多分、世のプロダクトを作らない人間はみんな分かんないんじゃないかって思ったけど。
でもね、俺そんなに実はノーション使いこなせてない方で、そういう細かいとこまでクイックファインドでサクッと調べて終わるくらいの使い方しかしてないから、分かんない。
単純に。
それで言うと、データが大量になった時にどうなるかみたいな話はあれか。
そうやって対処するのね。
そう。
なるほどね。
いやー、なんか絶対ベストな回答じゃないなって思いながら、試験的に今もやってみているのは、
例えばチーム内でそういう話題があったことあって、検索で引っかかったドキュメントがステーブルなのかどうか全然分からんみたいな、最新情報か分かんないみたいな話があったときに、
過去の情報を全部玉押しするのは非現実的だから、
自分たちがストックする情報は、ドラフトとフィックスと最新版ですよっていうのと、
廃止済みですみたいな3つのラベルをつけて運用してみましょうみたいなことをやって、
自分のチームがメンテするデータベースの情報の治安はそのラベルで守るとか、
あと個人的にちょっと会社のメンバーのフィードバックを直接もらえてないから、
僕が自己満で終わっちゃってるかもしれないけど、やってよかったなと思っているのは、
開発メンバー全員が触るドキュメントページみたいなのがあって、
開発チップスみたいなリストがあるんだけど、
それにそのステータスラベルを同じようにつけて、
そっちはもうちょっと工夫をして、今手元で開こう。
我らがいいラベル付けをしてると勝手に満足してるんだけど、
最新版というラベルと、古いので要更新というラベルと、
編集中というラベルと、過去の情報ですというラベルと、
あとは自由に編集してくださいという5種類つけて、
スタンスとしては誰でもそのラベルを更新していいですよというふうにしてたりはするって感じ。
逆にこれをしないと何が起きると思ってるかというと、
18:02
あるあるなのは頑張って掘り起こして自分の求めるページ見つけて、
でもかっかけとか、あとちょっとだけ間違ってるみたいな時に、
情報に対する感度とか意識が高いメンバーだったら、
多分勝手に書き換えるとか書き足すってのやれると思うんだけど、
やっぱ遠慮する人っていると思うんですよね。
ちょっと触らぬ神にたたりなしじゃないけど、
なんか触れないみたいな時に、そういうラベルをきちんと振ってれば、
自由に編集してくださいだったら勝手に編集するし、
古いので要更新ってなったら、じゃあ僕が更新しますみたいな。
あとは個人的にミスだと思っているのは、
古いので要更新みたいなラベルが付いたとして、
そのドキュメント全部更新すべきかというとそうじゃないと思ってて、
なぜならその時々で使われたり参照される情報ってどんどん変わっていくから、
基本的にはPVが一番多い情報からどんどん更新されるべきで、
なので要更新ラベルが付いているものを、
例えば毎月頼ろしして何かをアサインして更新してくださいみたいなことをする必要はないと思っているけど、
PVが多ければ誰かしらがいい加減更新しようってなって更新するかなみたいな、
淡い期待を込めてラベルを振ったりしている感じですね。
なるほどね。その運用なんかすごい良さそうだけど、
そうやってそのドキュメントを眺めて更新しなきゃっていう感度の人がいないと成り立たないから、
多分それは君がいるから成り立っている文化でもあるんだなっていうのをちょっと聞いてて思っちゃったんだけども。
いやー、でも、どうだろうな。文化、
だからそういう文化をでも最終的には作っていかないと、
情報の鮮度をそこそこ保つっていうのは無理な気がしてて、
そうっていうのも人が増えたら基本的に先継的にドキュメントが増えていって、
それを固定された人数だけでメンテナンスしていくっていうのは非現実的だと思うから、
そうなったら個々人がちょっとずつ更新するっていうのが理想系で、
でもそれを成し遂げるには多分やってくださいって頼むだけじゃ絶対ダメで、
何かしらその更新することのインセンティブとかメリットみたいなのを肌で体感してもらう必要があって、
っていう意味ではそこに対して何か僕ができてるかっていうと、それは正直はもうできてないかもだし、
今の会社のメンバーがそういうところを理解してるメンバーが多いから、
わざわざ言わなくてもいいかなって思ってるっていうのが正直なところで、
この先人数が増えていって同じ状態を保てるかで言うと、ちょっと難しいかもしれないなっていう。
ただ会社として情報をちょっと忘れたから元気は避けますけど、
21:06
会社内で扱う情報をどういうふうに扱っていくべきかみたいな指針みたいなのを定期的に見直して社内で共有をしてて、
それはその情報を更新しましょうとかだけじゃなくて、なるべくパブリックに情報を扱いましょうとか、
なぜならこういうふうにしたいからみたいなものを言語化したものがあったりして、
そういうところにフィードバックをかけて会社の意思として情報はこういうふうに扱っていきたい、
その理由とかリターンみたいなのを言語化して、
メンバーと会話、情報を更新してくれないメンバーみたいなのが、
更新してくれないって言い方おかしいけど考え方の違うメンバーがいたときには、
うちの会社はこういう考え方で情報扱うからこれに習ってやってねみたいなコミュニケーションが取れたら、
まあ健全というか、一番ベストシナリオはそういう感じな気がするな。
現実うまくいってるかはちょっとさておきではあるんだけど。
なるほどね。
そうね、まあでもリソースよ全部。
絶対100点は取れないから、どこまで頑張るかだよな、ほんとに。
まあ難しいのがさ、ドキュメントを更新することが仕事ではないっていうところもやっぱりあってさ、
ちゃんとものを進めなきゃいけないっていうところがある中で、
いかに最小限の時間でドキュメントをアップデートするかっていうことをやらなきゃいけないから、
どうしてもお隣になるところは出てくるわけだし、
棚下ろしとかステータスの管理をしないと、
ドキュメントの情報がまず状態がわからないっていうことになってしまうんだけど、
どうすればコスパ良く更新していけるかな。
コスパ良くか、コスパ良くね。
でもなんかその、いやーちょっと脳内にいろんな選択肢が今散らばり始めてるんだけど、
いやー難しいな、なんかいやーマインドアップ書きたい。
思いついたままにしゃべると、多分今からしゃべることは、
ドキュメントを書く場面を全然網羅できてない前提でしゃべりたいんだけど、
コスパ良くみたいなところで言うと、例えば、
開発っていう側面だけで切り出すんであれば、
技術的な意思決定とか技術的ディスカッションする過程のツールとして、
ドキュメントを使うみたいなのが多分一番コスパが良いというかよくある手法な気がしてて、
例えば、一番明らかにしたいのはデザインドックをきちんと書くみたいなものが開発プロセスに入ってるみたいな状況なんであれば、
24:03
デザインドックのクオリティは何にしても、
必ず技術的意思決定というのは文書上で言語化されて、そこに対してレビューが走って、
レビューの結果意思決定が決まるみたいなものが必ず大きい技術的意思決定にはペアになるから、
そのデザインドックを放置というか、それを保守するかどうか各社いろいろスタイルがあると思いますが、
更新しないスタイルだったとしても、
何でしょうね、2年後になんでうちの会社ファイヤースターなんですかみたいなときに、
このデザインドック読めばわかりますみたいなので、
あんまり意識しなくてもいいよねみたいなところとか、
あとはうちの会社で、それこそ今まさにやってる取り組みとかは、
仕様書をちゃんと書きましょうみたいな話をしてて、
仕様書をちゃんと書くってすごいいろんなグラデーションがあるし、
人によってはアレルギー反応を起こす人もいる気はしていて、
僕も正直仕様書をちゃんと書く会社にいたことがあんまなかったから、
どういう感じなんだろうなっていう気持ちがあったんだけど、
何だろうな、
さっきのデザインドックを書くも仕様書を書くもそうだけど、
それ書くことが目的なんじゃなくて、
書くことで何かを得ることが目的だから、
基本的には目的を見失いさえしなければ、
一番コスパのいい形でドキュメントを書く形に落ち着くはずなんですよね。
デザインドックも技術的仕決定をするために書きますっていう風になってると、
いい例えがぱっと思いつくといいんだけど、
データベース選定しましょうみたいなときに、
世の中にあるデータベース全部列挙して、
それぞれのプロスコンスを調べて、
中の実装まで追っていって、
それをメモるみたいなことをしなきゃいけないかっていうと、
そうじゃないじゃん。
なぜなら技術的仕決定にはそこまでミクロな情報っていうのを得らなくて、
ざっくり比較ができればいいし、
詳細に比較をしなきゃいけない場所だけ掘り下げて書けばいいよねみたいな形で、
一番結局質を最低限のところのラインで収まるはずだし、
仕様書も同じで、
うちの場合はその仕様書を書く目的っていうのを、
品質を担保していきましょうみたいな観点に絞ってるから、
じゃあテストプロセスでテストケースを書くときに、
仕様書でアンノーンというか積み切れてない場所があると、
テストケースを書くときに、
あれこれどういう仕様なんでしたっけみたいな、
手戻りが発生するみたいなことが起きてるから、
そういうのを網羅するようにしようとか、
あとはその開発の一番最初から一番最後のリリースまで関わるメンバー全員が、
なぜそれをやるのかみたいなのを目線が揃うようにしましょうみたいな、
目的があればなんだろうな、
テストケースで書こうと思えば100ケース書けるみたいなところで、
100ケース書かなくても全然いいですよとか、
27:00
目的もなんかなんだろうね、
開発メンバーの目線を揃えるんであれば、
ステークホルダー全員に対して納得にいく説明というか、
倫理を通すための仕様書を書かなくていいみたいな、
LINEに落ち着くみたいなところはある気がする、
バーッとしゃべっちゃったけど総括すると、
そのドキュメントを書く目的が明確であって、
それを達成するために一番最適化された形が文章として落ちれば、
一番コスパがいいのでは?
そうね、書いただけじゃなくて、
それがちゃんとした何か成果につながっているといいよねっていう、
それはそれでドキュメントとしての価値だよねっていうお話だったと思うので、
それは割と全面的に同意だなっていうところと、
最初に話した検索性がうまいこと両立してくれると本当はいいなと思って、
これはまだインプログレスの話なのか、
もうフィックスされた話なのかみたいな区別が付きやすいドキュメントが出るといいなと思って、
例えば新しいドキュメントを作ろうと思った時にタイトル打ったら、
もう似たようなものをすでにあるからそっちに書けっていう、
なんと出してくれるようなものとかね、
たまに自然言語処理で解析したらちょっと不完全だったから、
これ本当にアップデートされてるってちょっと注意を流してくれるような、
根本の構造は変わらないんだけど、
スマークツール側で整理をアシストしてくれるような機能がMotionとかに入ってくれると、
個人的には使いやすいのではないかと。
たしかにな、なんかそういうその、やっぱ自動整理や乱暴にしても、
アシストしてくれるような機能あってもよさそうだね、なんか。
そうだよね。
なんか見かけないけど俺が知らないだけかな。
なんかありそうだけどね、ないのかな。
なんか、いやでもそのMotionのリリースノートとか、
機能追加の頻度見てた思うんですけど、
いや、もうそのドキュメンテーション作るので精一杯なんだなって思う。
正直。
そうだよね。
ドキュメンテーションツールを作るのが大変だし、
またなんかこれはサービスオタクというか完全に主観の話をしてしまうけど、
そのMotionはなんか文章を綺麗に構造化して、
すごい綺麗なページを作ることにすごい特化してるツールだなと思っていて、
なんか2カラームレイアウトとかもそうだなと思うし、
なんかほんと細かいいろんなところで、
なんかほんと綺麗に、いくらでも綺麗に書き込めるみたいなところとか、
30:03
またもう一つはそのいろんなツール、
Motionでなるべく完結するようにみたいな思想も多分あって、
看板が作れたり、
結構頑張ればいろんな自動化ができるというか、
可視化とか消すことができちゃうみたいなところがあるから、
なんかわかんないけど、
彼らの中のプライオリティで、
2000人の企業に耐えるドキュメンテーションツールを作るみたいなのは、
ファーストプライオリティじゃないのかなみたいな気はするな。
そうして完成するのが、
Googleドキュメントみたいなものになりそうだよね。
どっちかっていうとコンフレンスなんじゃない?
そうだね、コンフレンスか。
そうか、そうだな。
僕な、
いやもうこれ完全になんか、
回し者でもなんでもないんですけど、
検索とか、
アシストの観点だけだったら、
ほんとにスクラップボックスが一番推したいんですけどね。
あれも面白かったけどね。
面白かったって過去形で言っちゃったけど。
ごめんなさい、そういう意図はないんですけど。
すごい良かったんだけど、
僕がやっぱり、
使ってなかったっていうのがあって、
ドキュメントのフォーマットを合わせにくかったんだよね。
一人で整理してるときはまさに、
よくお世話になってたんだけど、
それもモーション出たタイミングで、
一緒に切り替えてしまったというか。
今までのドキュメンテーションツールとパラダイムが違いすぎて、
多分会社とかで導入しようってなっても、
説得するのすげえ難しいなって思う。
あれはドキュメント間のネットワークを構築するのには、
すごく斬新で面白かったんだけど、
複数人になったときに、
本当にいいのかって言われたら、
自分の脳内がきれいになるのはいいんだけど、
他人の脳内まではスッキリしないっていうのが、
多分あるんだよね。
でも騙されたと思って、
みんな使ってほしいなあ。
騙されたと思って。
あれのフルスイスルっていうか、
あの会社がやってるギャゾっていう、
あの画像のやつもすごく良かったんだけど、
すごくいいサービスなんだけどね。
なんかもっと広まってほしいのは、
本当にそうなんだけどなあ。
そうなんですよ。
ちなみになんか、
ガチの味もんじゃんってなるかもしれないけど、
あれのサービスをやってる会社のCTOは、
僕の研究室の先生なんで、
それもあってちょっと、
それで言うと、
なんかその3万ページとかのドキュメンテーションを、
何十人で、
何百人で、
何百人で、
何百人で、
何百人で、
33:00
何百人で、
ドキュメンテーションを何十人で、
スクラップボックス上で扱うみたいな、
世界線を見てるから、
あの、
想像できるというか、なんか崩壊しなくて、
かけ味も落とさずに、
なんか見つけたい情報もすぐ見つかってみたいな、
世界を体験できてるけど、
世界を体験できてるけど、
でも、いやあ、啓蒙はむずいよね。
なんか、騙されたと思ってやってみてくださいで、
騙されたわって言われたときに、
責任取れるかというと、
そうですね。
まあ、
そうだよね、みたいな感じ。
自分が会社立てるならスクラップボックス?
うん。
会社単位でいきなりやるのはちょっと怖いから、
個人ベースで始めるといいんじゃないかなと思ったんだけど、
会社立ち上げるとしたらもう、
スクラップボックスですか?
そう。会社立ち上げるとしたらもう、
うちの唯一の、
決まり、
技術剪定の、
全部やっていくと、
ドキュメンテーションするだけ、
スクラップボックスですって言って。
まあ、確かにあれはなんか、
さっき話してたドキュメントの重複を省くみたいなところで言うと、
結構いいのかもしれないよね。
そうだね。
キーワードをこう選んで、
そこをページにしちゃうって言いそうだから。
そうだね、そうだね。
省くのもそうだし、
またやっぱなんか見つけやすいから、
かぶりづらいというか、
なんか、まるまる見つけられなくて、
同じようなページを生成してしまって、
なんかそれの無限ループみたいな。
そうなんだよな。
でもあれを一回やったおかげで、
Notionでも結構ページに
リンクを貼るように
しているというか。
はいはいはい。
リンクって正義だよな。
またなんかちょっと話変わるけど。
リンク、
なんか、
どんなドキュメンテーションツールを使うときでも、
個人的にめちゃくちゃ意識してるのは、
リンクを絶対に貼ることは
本当に意識してる気がするな。
うん。
やっぱどんなサービスでも
一つのドキュメントが
どんどんどんどん大きくなると
その分読み込みも遅いし、
更新も遅いから、
やっぱドキュメントは小さく保つっていうのが
たぶん正義なんだけど、
じゃあどうやってその
周辺とのリンクを確保するかっていうのは、
やっぱ書いた人がちゃんとやらなきゃいけない
っていうのがあって。
まあそれがあれだね。
それがドキュメントの質っていう話かもしれないね。
確かに。
質の話に。
参照可能な単位に
ページを分割するという
話ですね。
プログラミングの話ですか、
これは。
でも本当にさ、情報設計ってそういう話だよね。
まあそうだね。
確かにな。
構造整備でね。
最近なんかやっぱさ、
作っててもさ、デザインでも
デザインシステムがあって、
あれもさ、参照可能な
最小単位に
パーツをコンポーネント分けてみたいな
36:00
話とかがあったりする
わけだから、結局はそうやって
1回作ったものをちゃんと
作業可能な形にしようねって思って
それだって全くプログラミングと一緒だよね
っていうところで、
やっぱドキュメントも
そうやってエンジニアリングをすべきなのではないでしょうか
という
みたいな話なんですけども。
良さそう。
あと個人的にもう1つ共通点
見出したのは、
オーナーシップめっちゃ大事という話もある気がするわ。
ああ、そうね。
書いたコードに責任持って、
その命を
尽きる時まで面倒見ようねと一緒で、
ドキュメントも書いたら、
チームなり個人が、
個人は難しいんだろうな。
チームでメンテするのがいいのかな。
わかんないけど。
役に立たない日が来たら、
その手できちんとアーカイブをしてください
っていうのは、
確かにな。
システムと一緒じゃん。
ドキュメントとはシステムであるという
まとめを頂いたところで、
いいドキュメントとは。
いいドキュメントとは。
構造化されて、
オーナーシップがあって、
わかりやすくて、
いやでも難しいな。
ドキュメントオタクをゲストに呼んで、
もう一回話したいぐらいだわ。
我こそはドキュメントオタクという人は、
お便りをくださいという、
いつものあれを奪ってしまった。
お願いします。
待ってます。
こんな回もあっていいでしょう。
それなりに頭の中をアウトプットして、
言葉に変えられた気がするから、
引き続き、
お互い戦っていこうなって感じやな。
こうやって言語化してると、
さっき言ったドキュメントのアウトプットを出すぞ
みたいな話じゃないけどさ、
なんとなく整理されて、
明日行かせそうないい話になって終わるのはいいよね。
確かに。
俺も自分がよかれと思ってやったことはよかったが、
抜けてた思想みたいなのもあったから、
まだまだ学びが多いですな。
みそじらが。
今日はそんなところですかね。
良いドキュメントとはというトピックについてお話ししました。
また次回。さようなら。
さようなら。
