hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

トップ > チームのScrapbox3000ページくらいを見返して整理した

チームのScrapbox3000ページくらいを見返して整理した

会社でScrapboxを使っている。チームごとやプロジェクトごと、話題や趣味ごとにプロジェクトを作っていて、うちのチームは1年3ヶ月くらい使って3000ページほどに達している。
どんどん書いていたのだけど、最近、どこに何があるかわからなくなってきていた。同僚に、ここの仕様はどうでしたっけ、って何度も聞いてしまうことがあったので、これはまずいと思ってちょっと整理していた。

表記揺れを直す

One Fact in One Placeということで、どんどんページをマージしていった。ページを同名にリネームするとマージボタンが出現して押すだけなので楽。
よくみるとスペースの有無によって同じ話題のページが2ページに分かれていたり、略称と正式名称と、「(正式名称)まとめ」の3つにわかれたりしていた。情報を探しているときにはどんどんマージしたりしないので、今回マージするぞと見返せてよかった。
サポート担当、通称サポタンというチーム内の制度があって、「サポート担当」のページと「サポタン」のページがあったのを、普段はサポタンと読んでるのでサポタンに寄せた。言文一致運動とか思い出してしまって、まだどちらがいいか分かってない。あとから変えてもリダイレクトされるのであまり心配はしていない。

どう見てもいらないページを消す

UntitledなページがUntitled_4まで作られていたり、ひとこと書こうとして数文字書いて止まってるページも不要そうなものは消した。「着手」というページに「手を付けること」とだけ書かれていたので迷わず消した。

フロー情報とストック情報を分ける

フロー情報(一時的な情報)は先頭に日付を付ける、そうでない蓄積すべきストック情報には日付を付けない、というルールを前から決めていたけど、とっさに書いたページなどは徹底されていなかった。ページを見返していって、フロー情報っぽいものには日付を付けて回った。日付のスタイルはCtrl-tで出るものにして、202005015ではなく、2020-05-15でも、2020/05/15でもなくて、2020/5/15に揃えた。
現在は事実ではない情報が書かれていたとして、ストック情報なら直さないといけない。フロー情報なら、当時の内容、ということで置いといてもよいので気楽になる。
昔やっていた定例会のアジェンダはどうしようか迷ったけど、old/というプレフィックスを付けて、先頭に「現在は運用していません」とか書くことにした。



1ページにありとあらゆることを書かずにリンク集にする

「よくある対応」みたいなページに、問題とその問題が起きたときの対処法をずらずら書いていた。また、対応によっては独立したページになったりして一貫性がなかった。
課題たちは1ページ1話題になるよう統一して、「よくある対応」はただのリンク集にする形に整理したら一覧で見えるようになってスッキリした。いまのところページを切り分けただけで飛んだ先はまだ整理されていなかったりするけど、ひとまず見た目が整うことで素晴らしいページのように思えてくる。

ストック情報は他のストック情報からリンクする

ストック情報がどこからもリンクがなく宙に浮いている状況は無くそうと、他のストック情報からリンクを貼るようにした。
うちのチームは運用しているサービスがたくさんあるので、機能や企画のページは基本的にサービスのページからリンクされるようにしたり、前菜と共通で使っている機能なら、機能ごとのページからリンクを貼るようにした。
副次的な効果として、規模の大きいサービスはドキュメントのリンクがたくさんあるけど、シンプルなサービスではリンクが少ないので、初見でサービスの規模を推し量れるようになり、ちょっと便利になった。
普通のWikiではREADMEというかトップページから辿れるものは確定情報としてメンテナンスしましょう、という運用ルールがあったりするらしい。

リンク集の構造はメンタルモデルと一致させる

サイトの説明があったら、まずURLがあって、仕様があって、機能一覧があり、インフラ構成があり、これまでの障害があり、という並びで、普通にサービスの紹介をするときの流れと一致するようにした。また、機能一覧もカテゴリ別に並べて、似たものは近くに並ぶようにした。
知っている箇所はすんなりまとめられたけど、あまり知らないところはあいまいな理解で、フラットなリンク集を並べることしかできなかった。リンク集を作れるということはドメイン知識を持っている、ということで、詳しい人に編集してもらうのがよさそう。詳しい人から見ると、変な構造になっていると編集したくなると思う。
ロジックツリーの作り方を学んでいると、どういう章立てやどういう箇条書きのネスト関係にするとよいかの感覚を掴めそう。

紛らわしいリンクを削除する

とくに重要なページたちは、そのページにリンクしているページを見ていって、関係がうすそう、と思うものはリンクを消すようにした。
意図せず同音異義語がリンクされていたのを発見して、丁寧にやるならまぎらわしいので別の用語をつけるべきだけど、古いページであって、現代ではその話をする人もいなさそうだったので、単にリンクだけ削除した。

トップページを上から下までスクロールする

これら整理活動は、プロジェクトのトップでDate created順にして上から下まで順に眺めていく形で、変なページを見つけたら直していく、という形で整理した。Chromeのウィンドウを2つ開いて、片方は時系列順に見ていくウィンドウ、もう1つはよく使うストック情報を開いておくウィンドウで、みかけたらストック側にリンクを置いていった。3000ページあったら一番下までスクロールできないかと思ってたけどやればできた。
今回は全ページの中身を見たわけではなくて、タイトルの時点で揃ってなかったり変なものだけを直した。リンク関係をだいたい作れたので、あとは本文を見て整合性を整えたり、リンク集も順番がいい加減なので納得度が上がるまで並び替えたりの活動をすればよさそう。


まとめる活動をするのが大事そう

これまでは、書いていれば自然とまとまっていくのだろうと思っていたけど、それでは不十分なようで、まとめようと思ってまとめる時間をとることが必要なようだった。今回まとめる行為を通して、どういうページがあるかがだいたい頭の中に入った。
ページ下のLinksがあればなんとかなるだろうと思っていたけど、ページ間に関連があることはわかっても、それがどのような関係の関連なのかはわからない。また、ストック情報とフロー情報が混ざってしまうので、どのページが重要かはわからない。
知識を持っている人がカテゴリを用意したり、その中でわかりやすいように並べてリンクを貼っておくのが大事なようで、UMLとかをイメージすると、has-aの関係だったりis-aの関係だったりする。リンク集の章立てはドメインエクスパートが書いている、という形になれば、そこの情報は信用していいので、知識の中に関係が整理されるので、わかりやすくなると思う。
こういう自治活動を一人でやってると破綻するので、試行錯誤してうまくいきそうになってきたら、まとめ時間をとってみんなで整理しましょうと働きかけようと思う。

参考

ナレッジ蓄積ツールの利用事例のページを見回ったりしていた。ツールは違っても思想は参考になったりするので、サービス運営側からインタビューして回ってくださってるのはありがたい。