ごあいさつ
こんにちは。ユティです。
「ロケタッチができるまで」第2回ということで、ディレクター編を書いていきたいと思います。
ディレクター
ディレクターという職種は、これまでこのブログでも繰り返し書かれてきましたが、仕事の内容が非常に多岐に渡ります。本来の「ディレクション」以外の雑務も、ほとんどディレクターの仕事になります。なのであくまで今回は、ロケタッチ制作においての「ディレクター」について書きたいと思います。
サービスの質を左右する議事録について
まずは基本のいわゆる「ディレクション」です。仕様まとめ、構成書作成、スケジュール管理、外部交渉などでしょうか。中でも今回の「ロケタッチ」で重要だったのは、「仕様まとめ」だと思っています。
「仕様まとめ」とはつまり、サービスの動きすべてを明らかにすることですが、そのために最も重要なものは「議事録」ではないでしょうか。
「ロケタッチ」は前回のプロデューサー編でもあったように、開発前の仕様策定の会議期間が、ライブドアのこれまでのコンテンツ比べ、非常に長く取られました。コンセプトづくりから、実際の動きが決まり、開発に入るまで、相当数の会議がありました。名前についてだけの会議やシールについてだけの会議も何度かあったくらいです。当然ですが、どの会議も毎回重要な内容が決まっていきます。キックオフ当初はブレスト、リリース直前は最後の仕様確認と、無駄な会議はありません。
そして、会議で議事録をとるのはやはりディレクターの仕事です。
ここで取りこぼしがないことで、最後に出来上がるものの質が変わると思っています。議事録とは、コンテンツの元となるパーツを置き忘れないようにすることなのです。
実際の議事録の書き方については、このブログでも何度か取り上げられていると思いますので、今回は私が実際に使っているツールと、議事録で気をつけていることを紹介します。
iPhone アプリ 「Note2Self Audio Recorder」
（
いわゆるボイスレコーダーアプリです。iPhoneにはデフォルトでボイスメモがついていますが、録音された音が小さすぎたり、いつの間にか録音が止まっていたり、録音状態がわかりづらいなどの理由から、こちらのアプリを利用しています。
音源の転送はWi-Fi経由（小さいものならメールも可）になりますが、起動も速く、録音状態もわかりやすいですし、音量もあとで聞き返すには十分に録れていて重宝しています。設定でAudio Formatを低めにしないと、容量がとんでもないことになりますのでそこはご留意ください。
ただ、そうして録音データを聞きながら議事録を作ろうとすると、きっと失敗すると思います。一言一句漏らさず書こうとしてしまいがちだからです。議事録は要約です。一個一個詳細に残す必要はありません。決まったこと、決まらなかったこと、次までに考えてくることなどがきっちり要約されていることが大事です。
私の場合は、会議中の手書きメモなどを確認しながら、議事録の初稿を作った後、メモのないところで重要なことがなかったか、流れてしまった議題が結局どうなったかなどについて、録音で確認する程度にしています。
参考記事：
議事録の書き方 基礎講座
議事録の書き方 Part2
開発速度に合った情報共有方法について
いわゆるディレクションとは少し毛色の違う「ライティング」も、今回はディレクターの仕事でした。もちろん文章メインのコンテンツというわけではないので、補完的な短い文言が多いですが、世界観を感じさせる要素の一つとして大事なものです。
「ロケタッチ」はコンセプトや思想に合ったメタファーとして、「小学生っぽさ」を取り入れています。ロゴから始まり、コンテンツ全体のデザインはもちろんのこと、端々にあらわれるテキストにも極力、小学生っぽさがでるようにしています。
世界観の統一のために、一人が主体的に文言を考えていきましたが、チェックやアイディアをまとめるために、複数人での共有が必要でした。いろいろと共有の方法はありますが、今回は Google (Apps) Docs を利用することにしました。
これまで複数の細かなテキストの共有といえば、Excelファイルを共有フォルダに置いたり、まとめてメールで送ったり、ITSに書き残したりという方法で進めてきました。もちろんこれでも進められますが、いまいちスピード感がでません。ロケタッチは前述の通り、仕様策定にかなりの時間をかけましたが、実際の制作は短期間で行われました。メールでやり取りしてる時間がもったいないのです。
また、毎日どんどん機能が実装されていくなかで、「この文言をここに」という指示は優先度から言えば下がりがちで、大量のメールに流れて見えなくなっていきます。実際にテキストを考えるのも、そうそう楽にいくものでもなく、制作陣的に先にほしいものもあれば、あとからでもよいものもありで、バラバラになりがちです。かといって、それぞれのタイミングで出していると、全体の統一感もバラバラになる可能性がありました。
そこで、関係者が常にリアルタイムで閲覧・編集が可能で、かつテキスト全体を見渡せる Google Docs を使うことにしました。
Google Docs スプレッドシート利用の一例
実はこれまで Google Docs を使うことはほとんどなかった（社内で Google Apps が本格的に使われだしたのは昨年末ぐらいから）のですが、ロケタッチでは想像以上の活躍でした。当初、1つの機能のテキストについての共有のみでしたが、その後、テキストに関することから制作物の進行管理などまで、かなり利用しました。そして、それは今も続いています。※進行管理は Google Docs 以外に、ITS、IRC、wiki、メールなどいろいろ使っています。
参考記事：
「Google ドキュメント スプレッドシート」のつまみ食い！スプレッドシートの共有化でプロジェクトのTodoチェックを楽にしよう。
最後に
オレ色のサービス作ってやるぜ！ という方は、ぜひこちらのページからご応募ください。
ライブドアでは、ジブンとヒラメキをもったディレクターを募集しています。
以下、今後の連載予定。
ディレクターブログが読めるのはライブドアだけ！
第1回 プロデューサー編 (佐々木)
第2回 ディレクター編 (荒井) ※本記事
第3回 デザイナー編 (小黒)
第4回 プログラマー編 (吉川)
第5回 マークアップエンジニア編 (浜)
第6回 プログラマー（ケータイ版）編 (平野)
第7回 プログラマー（iPhoneアプリ版）編 (浅見)
