Webディレクター8年目のさけびんです。
先日ツイートした内容が非常に反響があったので、これについてより詳しくブログにまとめてみたいと思います。
https://twitter.com/WSakebi/status/1005331268408496129
ドキュメント化されてないものは「無い」に等しい
Webディレクターを8年もやっていると、何百回と経験しているのが「言った言わない問題」です。
言った側は言ったつもりでも、言われた側は覚えてないことがほとんど。
人間の脳みそは非常にあいまいで、実際のアメリカの研究でもわかっているのですが、脳のネットワークが情報を引き出す時に、情報を書き換えてしまうんですね。
なので特に仕事において、記憶に頼ってコミュニケーションを進めるのは不可能だと考えたほうが良くて、かならず言ったことについては「ドキュメントに残す」ことが重要です。
ドキュメント化スキルに必要な考え方
しかしドキュメント化するのは面倒です。
なのでドキュメント化する内容は最低限にしたいですよね？
そこでドキュメント化するものを最小限にするために、どのような考え方でドキュメント化するものを絞り、何をドキュメント化すべきなのか？について書いていきます。
「TODO」「背景」「ステータス」は残す
基本的にこの3つは残しておくべきです。
1番忘れられがちなのが「TODO」です。
人間は怠ける生きものなので、なるべくタスクはやりたくないわけです。そして人間、嫌なことは1番忘れやすい。
これが「TODO」は残しておくべき理由です。
そしてTODOを残しておいても、それをやる理由がわからないと人はなかなか動きません。
なので「背景」を残す必要がでてきます。
また、そのTODOがどういう「ステータス」なのか分かるようになっていないと、プロジェクトの進み具合がわかりません。
以上の理由から「TODO」「背景」「ステータス」を残すべきなんです。
基本は「5W1H」
「TODO」「背景」「ステータス」を残すとなっても、どういう内容を残すべきかというと「5W1H」を残すべきです。
つまり「いつ（When）」「どこで（Where）」「誰が（Who）」「何を（What）」「どのように（How）」「なぜ（Why）」を残しましょう。
TODOであれば、誰が何をどのようにやるのか、それをなぜやるのか（＝「背景」）が特に重要です。
ステータスも、なぜこのようなステータスなのか、いつまでにどういうステータスになるのかを残しておくと他の人にって意味のあるドキュメントになります。
ただ、毎回すべてを残しておくと非常に大変なので、言わなくても分かる内容は書かなくても良いでしょう。
「これは明確に言わないと勘違いする人が出てしまうな」と感じる情報については、必ず残していきましょう。
よく使われるドキュメントと、それぞれのポイント
このドキュメント化の考え方に沿って、実際に仕事でよく使うドキュメントをつくるポイントについて詳しく解説していきます。
議事録
「新人の仕事といえば？」と聞かれると、ほぼ間違いなく出てくるのが「議事録づくり」。
しかし、議事録にはそれだけ社会人に必要なドキュメント化スキルの全てが詰まっています。
前提1：議事録は事前に書いておく
議事録と言うと、ミーティングで言われた内容を残すものだと思われています。
半分はあっていますが、半分間違っています。
私は「議事録は事前に書いておくべき」だと考えています。
もちろん全てを書くことは難しいですが、事前に分かっていることについてはすべて書いておくべきです。
そうすると、ミーティングの時に何を書くべきか明確になります。
また議事録を書くことだけに集中することもなくなり、ミーティングに参加しながら議事録を書けるようになります（経験談）。
すると外でのミーティングに1人で行っても支障がなくなり、また議事録も残るので他の人に引き継ぎやすくなるという一石二鳥の効果があります。
前提2：みんなの前で議事録を書く
議事録はなるべくみんなの前で書きましょう。
具体的に言うと、ミーティングルームにたいていあるスクリーンやディスプレイに議事録を映しながら議事録を書いていきましょう。
そうすると、そこで書かれたことが間違っているとその場で指摘がもらえますし、議事録をあとで送ってわざわざ確認するというフローが無くなります。
では議事録では何が書かれるべきなのでしょうか？
前回までのTODO
場合にもよるのですが、定期的に開催されているミーティングの場合は、前回までのTODOが発生しているはずなので、それを書いておきましょう。
誰がいつまでにやることになっていたTODOなのか？を書いておきます。
ミーティング中には、それぞれのTODOのステータスを確認して書いておきましょう。
次回までのTODO
ミーティング中に決まったTODOも書いておきましょう。
これも誰がいつまでにやるTODOなのかを書いておきます。
「前回までのTODO」で残ってしまったTODOに関してもここに残しておきましょう。
議題
まず事前準備の時に議題を書いておきます。
議題は、その議題が発生した背景も書いておきます。そうすることであとで見返した時に「なんでこれ議論したんだっけ？」みたいな話が無くなります。
よくいるんですよ。「そもそもこれってなんだっけ？」おじさん。
とはいえおじさんに「そもそも、とか言わないでください」と言ってもムダなので、自分たちでそこへの予防策を張っておきましょう。
議論の内容
議題ごとにどういう議論になったかも書いておきましょう。
細かく発言内容まで書かなくても良いです。ただ、それぞれの議題がどういう結論になったのか？それがなぜなのか？を書いておくことで、「そもそもおじさん」を防ぐことができます。
議事録は「これなんだっけおじさん」と「そもそもおじさん」との戦いなのです！（キリッ）
スケジュール・進行管理
スケジュール・進行管理用のドキュメントも重要です。
これは主に「TODO」と「ステータス」の管理をするためのツールになります。
スケジュール・進行管理におけるドキュメント作りにおいて重要な点は下記のとおりです。
バッファを十分にとる
バッファは十分にとりましょう。
ギリギリのスケジュールを引いてクライアントや営業に共有してしまう方がいらっしゃいますが、プロジェクト進行の基本は「期待値を下げる」です。
・ギリギリのスケジュールを引く → スケジュールに遅れる
・余裕のスケジュールを引く → スケジュールより早めに終わる
どちらのほうが良いでしょうか？
確実に後者ですよね。
なのでバッファを十分にとって、損することは基本ありません。
できる限りバッファを取りましょう。
アウトプットベースで進行管理をする
私はスケジュールを管理する時に「WBS」を使用します。
「WBS」もいろいろ種類があるのですが、私がやっているものは、最終アウトプットを分類し、分類されたアウトプットが完成するまでに必要なタスクに落として、タスクごとのスケジュール管理をする方法です。
下記のように「ID（＃）」「アウトプット」「タスク」「担当者」「ステータス」「開始日」「終了日」の項目で管理をしていきます。
こうすることでアウトプットならびにタスクのヌケモレを防ぎやすくなります。
もし「開始日」と「終了日」を視覚的に把握したいという方は、こちらのスプレッドシートをご活用ください。
日付を入れるだけで色が塗られるようにできています。
定期的に進捗を確認する
ドキュメントを作っても、定期的にプロジェクトメンバー全員で確認しないとドキュメントは腐ります。
つまり意味をなさなくなるので、必ず定期的に確認しましょう。
プロジェクトが立ち上がった時に、どういった頻度で確認をするかを決めておくと、非常にスムーズですよ。
私は基本的に15分ほど、毎日確認するようにしていますが、チームの規模やプロジェクトの大きさによってそこは臨機応変に変えていきましょう。
issue・チケットを切る
エンジニアやデザイナーにタスクを依頼するときは「issue（GitHub）」ないし「チケット（Redmine等）」を切ります。
ココで重要なのも、やはり「5W1H」です。
特にこの順番で書いていくのが良いでしょう。
・What：何をやるのか？
・Who：誰がこのタスクをやるのか？
・Why：なぜこのタスクをやるのか？なぜこの人がやるのか？
・How・Where：どのようにやるのか？どこでやるのか？
・When：いつまでにやるのか？
これらがヌケモレなく入ってないと、タスク依頼として不十分で、思っていたタスクと異なる形で進行してしまう恐れがあります。
まとめ
ドキュメントをつくることを怠ると、プロジェクトが上手く進みませんし、チームメンバーとのコミュニケーションがうまくできずに、関係がギクシャクしてしまうことすらあります。
ドキュメント化スキルを高めて、最高のアウトプットが出せるようにしていきましょう！
