みんなで大小様々なプロジェクト(企画開発やタスク)を同時に進めている場合は、常に全てを頭で把握しておくことは困難ですしまたナンセンスです。その代わりに各プロジェクトの情報を知りたいと思った時には、あちこち探しまわることなくさっと手に入る状態にしておくべきです。
そのためには、まず前提として必要な事柄が書き出されてオープンに情報共有できている状態にある必要があります。
そしてそれらに簡単にたどりつけるようにするために各プロジェクトやタスクに ID (番号やキー)を発行し、チケット/タスクカードやドキュメント、コミットログなどに明記するのが、現実的に一番取扱いやすいです。
JIRA のようなユニークなチケット ID がチケットに発番され、かつそのチケットに permalink のあるチケット管理ツールを中央に据え、その ID を活用することでぐっと情報が共有しやすくなります。ここで ID 形式がさっと人が読んだり手書き・手入力したりできるものであることが大切です。
そういう点で言うと Trello は permalink しかないのでセンターを取れないなと思っています(Trello アーカイブ性も弱いという点もあります)。
基本「すべての情報を共有する。情報閲覧者が判断する。」(2006年5月15日)という方針が良いとずっと思っております。責任者だけが知っていれば良いとか、チーム内だけでわかっていれば良いとか、そういうのはちょっとどうかなという派です。
もちろん共有範囲を限定すべきものはすべきとして、それ以外はできるだけ共有する組織文化になれば良いと思っていますのでよろしくお願いいたします。
Qiita:Team はドキュメント群を階層構造化する機能を提供しないので、プロジェクトのドキュメントシステムとして使うには書き手・読み手双方が相当頑張らなければなりません。特に1つの Qiita:Team で扱うプロジェクト数が多いと顕著です。
Qiita:Team は今いる人と、今情報共有するためのツールを志向しています。
投稿した記事はフィードに共有されます。階層構造やカテゴリーなどの面倒な管理は不要です。 — https://teams.qiita.com/features
あとから記事を探しやすい仕組みを用意しています。整理することを考えなくてよいので書くことだけに集中できます。 — https://teams.qiita.com/features
ということで整理しないで使うことを想定したものなんですよね。みんな大好き Markdown 系シンタックスで簡単に書けるので、フロー型の情報共有システムとしてはいいと思います。
ただし「後からプロジェクトにかかわることになった人が全体像をさっと把握できる」ように整理されたドキュメントを作れるようにはなっていません。検索できれば大丈夫という話ではないので、整理されたドキュメント群を Qiita:Team 上に置きたければ記事間の関係がわかるような形で頑張ってリンクを書いていく必要があります。
そのあたり理解した上で導入したり使ったりするといいんじゃないかと思います。
「公開で作業する」を実現するため、部門で使っている Qiita Team 上にワーキングノートを投稿してみることにした。ドキュメントとして残すのが目的ではなく、コミュニケーションの補完として個人の作業ノートを見えるようにしておくのが目的だ。
次のような運用にするつもり。やってみてアレンジする。
今まで Markdown で書いているノートを Google ドライブで共有する (Markdown ファイルのままだったり Google ドキュメント化してだったり) のを試みたけれど続かなかった。 Google ドライブはオーナーシップと共有範囲のコントロールをできて良いのだが、記事として気軽に見てもらえるような感じではやはりなかった。
Obsidian Publish とは違い Qiita Team は記事をローカルファイルと同期できないので、複数のノートを公開・更新していくのは現実的ではない。1つのワーキングノートだけに絞り反映させることにした。
1つのノートを更新していく方法だと変更点が分かりづらいので、だんだん読まれなくなってしまう懸念はあり。
永続的に残ると思うとリンク先の永続性とか気になりだしてしまって更新するのが億劫になる。あくまで作業ノートとして最新のスナップショットだけ共有したい。1つの Qiita Team 記事を更新していくのがシンプルなんだけれど、古い編集履歴を消す機能が無いので1週単位で新しくしてみることにする。
[ 組織内公開ワーキングノート ] [ 公開で作業する ] [ Top of Mind ノート ]
月曜日に部門の情報共有ツール (Qiita Team) にワーキングノートを新規作成し、その週はそのノートを更新するというのを今週やってみた。
共有するかどうかとは別に、そもそもデイリーノートとワーキングノートを分けない方がいいという気持ちになった。知的作業空間としてはデイリーノート一本化に戻す。作業中に共有・非共有の判断にエネルギーを割かないようにする。
コミュニケーションの補完という目的では、雑感記事をデイリーで情報共有ツールに書いていくのが良さそうだ。
結局行き着くところは社内 Web 日記 (社内 Blog)か。
[ 組織内公開ワーキングノート ] [ 公開で作業する ]
石ごろごろ#photography
— Naney (@Naney) October 13, 2022
Lomo LC-A Minitar-1 Art Lens#Minitar #Minitar1 pic.twitter.com/PKrcAzY7Ne
組織内で「公開で作業する」というコンセプトで2月から MkDocs + GitHub Enterprise Server の GitHub Pages で組織内公開ワーキングノートサイトを作って使っている。
Markdown 形式で書いている作業中のノートを気軽に共有できるようになったのはやはり良かったかな。
一方9カ月続ける中で他から何度も参照されるような寿命の長いノートが出てきて、ノートへのたどり着きにくさが課題になってきている気はする。過去にシェアした URL を見つけ出して再閲覧するために記憶に頼るところが大きすぎるなと。
参照資料になったノートはきちんと組織の情報共有ツールの方に移しておくべきというのが正論でありつつ、ほとんどそのままにしちゃうんだよね。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。