Webディレクターの役割はメンバーを迷わせないこと　プロジェクト成功の鍵を握るプロジェクト憲章のドキュメント作成法

「〇〇がどこに書いてあるか」の情報共有も必要

名村晋治氏（以下、名村）：情報共有がプロジェクトの成功の鍵をもつ。成功させないといけません。そのために情報共有をしていきましょう。そしてプロジェクト憲章の話をしましたが、それ以外にもう1つです。プロジェクトに必要な、それ以外の情報共有です。例えばサーバーのアドレスや、テストサーバーのURL。あとはBasic認証がかかっていたら、IDとパスワードはどこに書いてあるか。

このいろいろな「〇〇ってどこに書いてあるの？」も情報共有していく必要があると思います。みなさん、こういう経験ないでしょうか。ログイン情報がBacklogのチケットの中に書いてあって、行方不明になっているとか。圧縮ファイルを解凍しようとしたら、相手から「前のメールに書いたパスワードと同じです」と書かれて、「だからそのパスワードどれ!?」と、メールをずっと掘っていくとか。

あとは、テストで使うメールアドレスを忘れて、毎回メールボックスから探したり、クライアントからの仕様書がチケットに添付されていて「添付ファイルどこだっけ？」と探す。仕様の取り決めがチャットの中で行われていて、その2人しか知らなかった。こういった経験はないでしょうか？　こういうことがあった場合、みなさんが何をするかといったら、「どこにあるかな」と探すわけですよね。

調べている時間って、仕事している時間ですか？　たぶん30秒、下手したら1分とか、毎回それくらいの時間かもしれませんが、これを1年積み重ねたらいったいどれぐらいの時間になるかということです。そのため、「ゴールはメンバーを迷わせないこと」と私は定義しました。どうすれば迷わないで仕事ができるかです。プロジェクト憲章やドキュメントが、どういうときに作っておくべきなのかという、タイミングの紹介をします。

これは私が2000年頃から全国で行っている、Webディレクター育成講座のカリキュラムのある1ページに書いてあるワークフローです。だいたい戦略の策定が終わって、クリエイティブメンバーに実際に動いてもらう直前ぐらいには、絶対にできていなければいけません。Webディレクターの方は必ずクリエイターの方たちが動く前にプロジェクト憲章を作る。それを忘れないでください。

共有するまでがプロジェクト憲章作り

ただ、それ以上に重要なことがあります。共有です。プロジェクト憲章を作ったから、何かツールを作ったからうまくいくわけではなく、使ってこそ初めて意味があります。相手が理解していなければ、作ったものは意味がありません。共有するまでがプロジェクト憲章作りと考えてください。連絡にはBacklogを使いましょう。

プロジェクトの中でいろいろなツールが出てきました。大きな問題があり、メールで連絡が来る、チャットで済ませてしまう、そして最大の問題がBacklogを見ていないことです。これらを解決しなければいけません。ディレクターは解決の方向を作っていきましょう。

私は、場合によってはBacklogを見ていない人は切ります。「見ていないあなたが悪い」まで持って行く場合もあります。「あれ？　その話ってどこでやったの？」「Backlogでやりましたよ」「え？　俺見てなかったよ？」「みんなもうそこで盛り上がっているんですけど」みたいな感じで、見ていないと置いて行かれる感を醸成したりもします。

その結果、意地でもBacklogを見てもらうようにしていきます。私が地道にBacklogへ誘導するためには、はこんなことをしています。メールで連絡がきたら、Backlogへコピペ。メールでの添付資料もBacklogのファイルへアップします。電話の内容もBacklogに書くし、チャットの内容ですら僕はBacklogへコピペします。こういったことをすべて情報集約していくことを進めています。

ただ、ここまでやっても大変な前提があります。使えるようになるには、それを使おうとしている方々が、「あー、なるほど！　そういうふうにやらなきゃいけないのか。意味がわかったよ」と。その次に「確かにそれはやったほうがいいね。じゃあちょっと使ってみようか」。ここはまだ意図的に使っています。

その次に、やっと「これはちょっとBacklogに書いておこうかな」「これはちょっとBacklogを見ようかな」と、無意識に使いこなす。ここまでの時間がかかってくるということです。

Webディレクターは、プロジェクトが動き始めればハブになります。wikiをどのように整理して、どのように書くのかも極めて重要になります。

ドキュメントは、第三者が探せるように書いていかなければいけません。英語表記とカタカナ表記、微妙に正しくないオレオレ用語を勝手に使っている、タイトルのつけ方が「〇月〇日の話の件」みたいな雑なつけ方。そういったことは、全部排除していく必要がディレクターは求められます。第三者が検索できるライティングが必要です。

そして第三者が探せるということはもう1つ、共通のフォーマットを作る必要があります。そうすれば、「wikiを見ればこのあたりに書いている」ことが、みなさん感覚的にわかってくれます。私が2020念3月頃に公開した、文書の書き方としてのフォーマット、『誰がどうみてもそうとしか受け取れない文書術』を公開しています。もしよければ検索してみてください。

フォーマットの具体的な使い方

私がフォーマットをどう使っているかを紹介したいと思います。社内で全員が見れるプロジェクトを1つ立ち上げています。この中のwikiに「プロジェクト用wikiプリセット」を作ります。この中身は、Backlogのマークダウン記法で書いているものを、さらにコードとしてwikiの中に登録しています。

なぜこのようなことをしているかというと、これをコピペするんです。1つ目は見出し1です。そのプロジェクト全容の下はリスト表示になっていて、中はwikiのアンカーの設定になっています。これをそのままコピペして、新しいプロジェクトのwikiにコピペで貼ってもらいます。

さらに、その中身でもプロジェクトを共通して使うもの、プロジェクトの管理方針や、議事録用のルール。あとは、ファイルをどこに置くのか、チケット運用はどうやってやるのか。そういったことを明文化したものは、同じように貼り付けるだけで済むような文書を作っています。

新しいプロジェクトが始まり、ディレクターが先ほどのところからコピペをたぶん12、3回繰り返すとフォーマットができます。チケットの起票時のルールや、本番・ステージングのURL・接続情報など、忘れそうなものもフォーマットにしています。

そして貼り付けるとこうなります。使っていない、中身が書かれていないところはグレー表示、中身が書かれているものはオレンジになります。書かれていないものは使うかもしれないので、消す必要がありません。書いて縮めてしまうことによって、毎回どこに書いてあるのかがよくわからなくなることを避けるためにも、まずはババッとコピペをして使うようなかたちを取りました。

共通フォーマット化することの利点。未記入も含めてプロジェクトごとにwikiの構造が同じで、いつも「wikiのあそこにある」を提示することで探す手間は圧倒的に減っていくことになります。

そして大事なものです。そもそも何をするかを共有するためにツールを考えました。共有することでクリエイターが動ける。すべてはプロジェクトの成功のためです。これを今日はみなさんに覚えて帰ってもらいたいと思っています。

みなさんに対して、少しお土産を紹介します。先ほど私がコピペで使える、Backlogのマークダウン記法で書いているプロジェクト憲章、wikiの記法フォーマット、プロジェクト進行のルールのフォーマットをダウンロードできるフォーマットを用意しました。このQRコードか、bit.ly/backlogworld2021からダウンロードできるようにしています。

中にはテキストファイルが入っているだけですが、マークダウン記法で書いた、私がふだん使っている書式をご紹介したので、ぜひみなさん使って、仕事の役に立てば幸いだと思っております。

もし疑問、質問あればTwitterの@yakumo、Facebookは本名の名村晋治で登録しているので、ぜひ連絡いただければなと思います。長々とありがとうございました。