同人企画をやってると、他人を巻き込むには企画書が欲しくなることがあります。
ちゃんとした企画書があるから良い企画だと言えるわけではないんですが、企画書が良くないとなかなか他の人から信頼してもらえないことってありますよね。
というわけで、同人創作向けの企画書にどんな項目が必要か考えてみました。
概要
そもそも「企画書」という単語が何を指すのか、という共有された認識はないと思ってます。辞書には何かしらの定義が書いてあると思いますが、辞書通りに企画書を書けばそれで必要十分ってことはないでしょうしね。
なので、必要な項目を考えてみました。
必要な項目と、それぞれの意味～企画全体編～
まずは、企画全体のインプットとアウトプット。
あらゆる営みにはインプットとアウトプットがあると思うので、それらを明示します。企画の世界観なんかはインプットですよね。企画の成果を世に出すなら、それがアウトプットです。
で、インプットとアウトプットをどういう段取りで繋ぐか。チーム全体としてやるべきことのリストとか、やるべきことをどう実行していくか、プロセスに対してどのような支援があるか。そんな話が必要になってきます。
項目に落とし込むとこんなところでしょうか。
- 企画のインプット一覧と、場合によってはインプットの内容
全体が共有する世界観とかは、企画書に載せたいですね。 - 企画のアウトプット一覧
そもそもその企画って、何を創るんでしょうか？ - チームのメンバーリスト
この企画は誰が関わるんでしょうか？担当者と担当領域のリストがあるといいですね。責任分担表に繋いでいくといいかも。 - 作業リスト
この部分は、企画を進めていく上での全体の段取りになりますね。
ITの世界だとWBS(Work Breakdown Structure)なんて言ったりします。World Business Sateliteではありません。 - 企画のマスタースケジュール
全体のスケジュールを「マスタースケジュール」と呼んだりします。WBSを作るのにも使う情報になるでしょうね。 - チームのコミュニケーション体制
企画推進にどんなサポートがあるか？といったお話。ファイルのやりとり方法とかコミュニケーション手段(メーリングリスト？Skype？LINE？掲示板？redmine？サイボウズLive？)とか企画書のURLとかを書いておきましょう。 - 企画全体として期待と前提事項と、期待が裏切られるリスクの識別
企画倒れになることって、どうしてもあると思うんですよ。たとえば本業が急に忙しくなったとか、突然転勤で海外行きが決まったとか、親族の誰かが亡くなったとか。
なんですが、そういうリスクがあることが共有できていないと、たとえどんな理由があろうとも「あいつは突然企画を止めやがって！」になるんですよね。なので、「私の企画にはこういうリスクがあります。リスクを承知の上でご参加ください」と最初からお知らせしておいたほうがいいと考えていまして、リスク識別を企画書に入れたほうがいいということです。
リスク識別とは、「こういうリスクがあるので、こう対応する」という一覧です。対応方針は「リスクをなくすようにこのような手を打つ」とか、「このリスクは引き受ける」とか、「リスクの発生に備えてこういう保険を打っておく」あたりが典型例です。
メンバー一人一人に向けて
メンバー一人一人についても、同じことが言えます。つまり、その人はどんな責任を負って企画に参加し、どのようなインプットを受け取って、どのような段取りのもとにアウトプットを提出するか。
企画書にはこんな事項が書かれることになると思われます。
- メンバーとして期待して良いインプットの一覧
たとえばボイドラにおけるボイスコさんだったらチーム全体に提示される世界観、シナリオ担当者から上がってくるシナリオあたりがこの一覧に入るでしょう。
誰から、いつ、どんな、インプットを受け取るかを明記すべきです。 - チームとして期待するアウトプットの一覧
インプットから逆に考えると、アウトプットは誰に対して(提出先と、自分のアウトプットを使って次に動く人)、いつ、どんな内容で出すべきかという話になります。 - アウトプットの段取り
チーム全体の話とほぼ同様ですが、企画側から提示できるのはスケジュールくらいのものかな、と思います。
インプットが遅れる場合にアウトプットの期限を変えていく、といった対応は必要になりますが、そこらへんは後述。
もっと重要なこと
で、気付いた方もいらっしゃるかもしれませんが、企画書は一度作って終わりではありません。むしろ随時アップデートしていくことが大切です。
最初のうちはメンバーだってどんどん増えていきますよね。作業スケジュールだって変動するかもしれませんよね。というわけです。
そして、アップデートが前提ということは、いきなり最初から完璧な企画書を作らなきゃいけないわけでもありません。むしろスピーディーに改善・アップデートしていくことのほうが大切だと信じています。