アメザリズ流タスク管理術 3：Notion で作る「形骸化しない Wiki」

どうも、アメザリズスタッフの Neo です。

メンバーが物理的に離れた地域に住んでおり、ほぼ全てのやり取りをオンラインで完結したアイドルプロジェクト「アメザリズ」。

前回までで、飽和状態だった Slack に Trello というチケット管理ツールを連携させ、タスクを可視化しました。今回は、「完了したタスク」のまとめ方にまつわるツールを導入していきます。形骸化しにくい情報管理の術もご紹介できればと思っています。

決定事項の共有には Notion (ウィキ) を使う

Trello によるタスク管理と同時に、Notion というツールも使い始めていました。任意のページを作って共同編集ができる、いわゆる「ウィキ」的なツールを求めていました。

Notion の良いところは WYSIWYG である点でしょう。プレビュー画面がそのまま編集画面にもなり、見たままに編集ができるので、特に表を編集する時は大変扱いやすかったです

会話は Slack で、タスク管理は Trello でやっているのに、Notion には何を書くのか？ですが、Notion のようなウィキには「決定事項」を書きます。つまり、ツール別にその運用手順を並び替えると、次のようになります。

Slack で議論を交わし、やるべきタスクを明確にする
Trello にチケットを起票し、チケット内で議論を進めて作業を完遂していく
完了したタスクに関する決定事項は、Notion に書いていくことで、チケットを漁ることなく、確定した情報だけを拾い読みしやすくする

情報は原則として一元管理する

認識齟齬を減らすためには、情報は一元管理し、複数の箇所を同時に更新しないことが重要です。やたらと複製された情報を持ち回っていると、どれが最新版なのかが分かりにくくなったりします。しかし、各ツールを移動するときは一瞬だけ、情報が二元管理される瞬間が発生します。すなわち、

Slack で話していた経緯を Trello のチケットに表現する時
Trello で取り扱っていたタスクに決着がつき、決定事項として Notion に書く時

の2点です。この瞬間ばかりは「同じ情報が二元管理されている」ように見える瞬間がありますが、このタイミングを利用して情報を要約してまとめることで、後から経緯を辿る時に会話の全文を漁ったりする必要がなくなります。最近は ChatGPT などを活用すれば要約にかかる手間も省力化できるでしょうから、単なるコピペで済まさず、必要な情報に絞って要約することが後々有用なドキュメントになるでしょう。

「決定事項」とは、Wiki には何を書くと良いか

プログラマや SE などの職業に就かれている方は特に、こうした業務管理ツールを多用している場合が多いと思いますので、その使い分けや勘所が掴めているかと思いますが、アメザリズのメンバーは非エンジニアがほとんどだったので、急に「Notion が要りそうだ」という話になっても、当初はその必要性や運用方法のイメージが湧かなかったようでした。特に、Notion の機能で表やチェックボックスが取り扱えてしまうので、やろうと思えば「Notion でタスク管理表を作る」といったことも出来てしまい、じゃあ Trello との使い分ける必要はあるの？というところが不明瞭になってしまいます。

そこで、繰り返しになりますが、Notion に書いていい情報はあくまで決定した内容のみ、というところを徹底するようにしました。メンバー全体に知っておいて欲しい情報はもちろん、

どうしてそのように決まったのか、といった「後々再確認したくなりそうな付随する情報」だったり、
どうして B プランは選択しなかったのか、といった「却下したアイデア」とその理由

などは、決定事項とともにまとめておくと良い情報になるでしょう。

ウィキのページ分割の単位はどうすると良いか

「社内ウィキ」や「チーム Wiki」みたいなモノを用意すると大抵課題になるのが、何をどういう粒度で書いていくか、という話です。ウェブページを作ったり、ブログを書いたりした経験があると、コチラも「見やすい『1ページ』がどんなものか」という勘所を持っていることが多いですが、ドキュメンテーションの経験値は人それぞれなので、組織内でよくよくルールをすり合わせておくと良いでしょう。

個人的に、どんな場面でも有用だと感じている原則があります。それは「単一責務の原則」というモノです。

一つのモノには、一つのコトだけやらせる
一つのモノに複数の役割を与えない

という、主にプログラミングの中で重視される考え方なのですが、コレをドキュメンテーションにも適用します。つまり、

1つのページには、一つの事柄だけ書く。複数の異なる事柄を書かない

ということです。もっと平たくいうと、「一問一答」のように、タイトルだけで書いてある内容が推測でき、その答えだけがページ内に書いてあるようにするワケです。「DEATH！DEATH！です。の歌詞」というタイトルのページがあったら、中には歌詞だけを書いておきます。間違っても「メロディ」や「コード進行」など、異なる情報は含めません。それらは別途「楽譜」のページを作る、という風に切り分けます。

そうすると、ウィキのトップページを開いた時に、ページ一覧のリストが「一問一答」形式になっており、欲しい情報がどのページに書いてあるかが一発で分かるようになります。こうすると、各ページが適切に更新されずに形骸化していく、といった事態が回避しやすくなり、形骸化ではなく「適切に凍結」されたページ群が出来上がっていくことでしょう。

階層構造による分割は後からでもいい

我々「アメザリズ」の活動内容やタスクをザックリと階層で表現すると、次のようになります。

なな子プロジェクト　　 … メンバーが集まるオンライングループの名前
└ アメザリズ　　　　　… アイドルプロジェクトの名前
　 └ ザリガニョンズ　 … デビューするアイドルグループの名前 (他のユニットも既に構想があります)
　 　 └ DEATH！DEATH！です。　　… ザリガニョンズが歌うデビュー曲の名前
　 　 　 ├ 楽曲製作のタスク
　 　 　 │ ├ 作詞
　 　 　 │ ├ 作曲
　 　 　 │ ├ ボーカル収録
　 　 　 │ └ DTM 打ち込み
　 　 　 ├ MV 製作のタスク
　 　 　 │ ├ V アイドル製作
　 　 　 │ ├ 背景写真の撮影
　 　 　 │ └ 動画製作
　 　 　 └ プロモーション (動画公開・宣伝)

楽曲でいえば、「作詞ができて」「作曲ができて」「音源が揃って」「DTM で打ち込みしたら」→「楽曲が完成する」という形で、タスク間の兄弟関係、およびグルーピングするための階層構造が存在します。

ザリガニョンズのデビューシングル発表に必要なタスク、という目線で大局的に見ると、「楽曲が出来上がって」「MV が出来上がったら」→「世間に公表してプロモーションできる」という関係性でタスクが絡んでいるワケです。

それでは、「アメザリズ Wiki」を新たに立ち上げたとして、最初に必要なウィキの階層表現はどのくらいが適切でしょうか。実は現状、ウィキの階層構造はおおよそ次のようになっています。

アメザリズ Wiki トップページ
└ ザリガニョンズ　に関するページ群のトップ
　 ├ 「DEATH！DEATH！です。」の歌詞
　 ├ 「DEATH！DEATH！です。」の完成した音源置き場
　 ├ 「DEATH！DEATH！です。」MV に登場する VRoid アバターのデータ置き場
　 └ 「DEATH！DEATH！です。」MV の絵コンテ

「DEATH！DEATH！です。」という曲単位でのグルーピングはしておらず、「ザリガニョンズ」直下に「楽曲製作」と「MV 製作」の情報を雑多に置いています。でも、現状はコレで充分だったりします。

今後、「ザリガニョンズ」が複数の曲を、同時並行で製作するような事態が発生したりしたら、その場合は「ザリガニョンズ」直下に「曲ごとのトップページ」を設けてグルーピングした方が分かりやすくなるでしょう。しかし現状、ザリガニョンズの持ち歌は「DEATH！DEATH！です。」の1曲のみ。厳密にカテゴリや階層構造を管理することも可能ではありますが、さほど必要ではないのです。

こうした、「今必要でないモノは用意しなくていい」といった考え方を、プログラマの間では「YAGNI の原則」と呼んでいたりします。YAGNI とは「You Ain't Gonna Need It」の略で、直訳では「そんなの必要ないって」といった意味合いになります。

デジタルなドキュメントの利点は、あとから好きなだけ移動や編集が加えられるところです。必要になってきたな、と思ったら、その時に初めて階層を追加したりして取りまとめれば良いのです。

職業病だったり、几帳面な性格の人だったりすると、ついつい厳格に管理したくなってしまうかもしれませんが、大切なのは「今必要なことが分かること」であり、それは「今・これからやるべき作業がすぐに把握できること」のために必要なのです。管理すること自体が目的になってしまっては、作業は捗りません。キチンと丁寧にまとめたい！といった欲求はほどほどに抑えて、周りにルールとして強要したりしないようにしましょう。ｗ