クレジット
タイトル: 反狂騒のための協奏原理入門
著者: k-cal k-cal , Dr_Kudo Dr_Kudo , Jiraku_Mogana Jiraku_Mogana , ukwhatn ukwhatn
作成年: 2023
目次
このエッセイの想定読者
- 今後複数人で協力して創作を行う予定の方
- 特に発起人やまとめ役(マネージャー役)を担う方
- スタッフ、イベント委員会等でプロジェクトの進行を担う予定のある方
執筆者紹介
本エッセイの企画主催及び主筆を担当。チームコンテストではチームMMMRでマネジメントを担当。他、外部で開かれている「700字文体シャッフル企画」の定期イベント化や、新聞掲載の対談企画の主催などを経験。
チームコンテストでは、MVPを獲得したチーム産地直送幻覚畑のリーダーを務めた。外部で開かれている「700字文体シャッフル企画」の定期イベント化に携わったほか、サイト内では過去渉外スタッフを経験している。SCP関連イベントで頒布された合同誌「りょかんのごはん」の製作ではマネジメント役を担った。
サイト上のイベントに数多く携わり、素手喧嘩コンテスト|、わかば応援!ワクワク批評キャンペーン、OVERLOADキャンペーンでは主催を担った。他、混迷を極めるかに思われた闇寿司ハブ製作会議で主導的役割を担い、これを完遂に導いた。
このエッセイ投稿時、テクニカルスタッフとして活動中。スタッフ組織の効率化、円滑な運営のための様々な組織改革を手掛けるほか、サイト外でも数多くのイベント・プロジェクト・組織のマネジメントに携わっている。
※(注記) 本エッセイはあくまでエッセイであり、上記のメンバーの個人的な意見に基づいて作成されています。
人は一人で生まれ、一人で死にます。我々の人生における究極的な友は一貫して孤独のみであり、すなわちこのサイトでも基本的に我々は孤独と共に歩むことになります。執筆をするときも、記事を読むときも、ほとんどの場合我々は一人ぼっちです。
しかし一方で、「人は一人では生きていけない」というクリシェ染みた格言も、また真実でしょう。本サイトにおいても、共著やイベント運営、スタッフ業務──こういったケースでは複数の人々と協力することになります。特にリーダー、主催、あるいはマネージャーとしての役割を担う人々は、普段必要とされないような仕事をする必要に迫られるでしょう。このとき必要とされるスキルは、個人プレイに必要なスキルとは異なります。では、もし全くスキルが不足した状態でチームプレイを始めてしまえば、一体どうなるでしょうか? 仕事の質が悪くなる程度ならまだよい方でしょう。そもそも仕事が完成しない、あるいは最悪チームが空中分解してメンバー同士に軋轢が生まれるなんてことになりかねません。
このエッセイでは、チームプレイでよりよい成果を出せるように──そして何より、チームプレイを笑顔で終えられるように、チームマネジメントについていくつかの知見と提案をお届けします。
(なお今後は、企画やプロジェクトの主催、あるいはマネジメント担当者のことを、単にリーダーと呼ぶことにします)
第一章:企画の始動まで
リーダーや主催の仕事は、企画の始動前から始まっています。ここでは、メンバーを集めて企画を始動する前にあらかじめこなしておく仕事について解説していきます。
企画の概要を決めておく
「今度何か一緒に面白いことやりましょうよ!」
この言葉の先には何もありません。そうとわかっているはずなのに、私たちは誰かを誘うときに思わずこの言葉に頼ってしまいます。きっと、それは悲劇の始まりでしょう。
この言葉の一番の問題点は、何をやるかが決まっていないことです。何をやるかがわからないと、よっぽどのことがない限りやる気も出ませんし、何より企画に参加するかどうかを決めることもできません。メンバーの選定も効率的にできないでしょう。
仮に企画内容が非常に曖昧な状況で人を集めたのなら、どういった悲劇が起こるでしょうか? 一つ、最初の会議の場面を想像をしてみましょう。
「じゃあ、まずどんな企画をやるか決めましょうか。何かアイデアのある方はいらっしゃいますか?」
「うーん、なんかみんなのスキルを活かせるようなものがいいですね」
「ありがとうございます。他に意見はありますか?」
そうしてアイデアが出ず企画もまとまらないまま、数週間が過ぎました。当初は盛り上がっていたチームメンバーのやる気も消え去り、何なら数名は音信不通です。こうなってしまっては、もう立て直しはできないでしょう。
このケースから得られるのは、「人は縛られなければアイデアを考えることもできない」という逆説的な教訓です。「これからなんでもできる状況」より、「何をするかが明確な状況」の方が、とっかかりがある分アイデアを作りやすいのです。上の例は、アイデアを出すのに熱心でないメンバーが悪いのではなく、とっかかりを用意していなかった主催に非があります。「みんなの意見を取り入れて〜」という言葉は甘美な響きですが、その言葉に甘えて土台となる概要も用意しないのはリーダーの責任放棄に他なりません。
複数人で協力して何かをしたいのであれば、主催がある程度「やりたいこと」や「ビジョン」を決めておくべきです。「共著をしたい」「コンテストをしたい」程度では十分とは言えません。「人事をいっぱい使ったTaleが書きたい」「こんなテーマ・ルールのコンテストをしたい」「定期的に掌編を書く契機になるような企画を始めたい」......誘われた人が、「どんな企画か」をイメージ出来て、そしてワクワクするような企画概要を作っておきたいところです。
もちろん企画概要は、頭の中に置いておくだけでなく、他人に説明できるようにしておく必要もあります。小規模なプロジェクトであれば簡単な説明で済むかもしれませんが、ある程度の大きさのプロジェクトになれば説明のためにスライドかドキュメント形式で、企画の内容や目的、スケジュール案などを含んだ「企画書」を作成しておいた方がよいでしょう。企画書を作る過程で、自分の考えを整理する機会にもなります。
この企画概要・企画書の作成は、基本的に一人で行うようにしましょう。細かい箇所や方針のすり合わせについてメンバーと話し合うことは必要に応じて行うべきです。しかし土台となる大本の企画概要段階で複数人の手が入ると、齟齬や矛盾が生まれたり、全体的なビジョンがぼやけたりします,。
企画の終了日を決めておく
この企画はいつ実行されるか、あるいはいつまでに作品を完成させなければいけないのか。そういった企画の最終的な終了日は、企画が始動する前、あるいは始動した直後に大雑把にでも決めておくべきです。例えコンテストに出るわけでもなく、本当はいつ完成してもいいとしても、期限は決めておかなければいけません。
期限を決めておけば、様々なタスクの期限を逆算して決めることができます。逆にあらかじめ終わりの設定されていない企画は、延々と間延びして、いつしか全員のやる気がなくなります。やがて企画はなあなあの内に崩壊し、メンバーの関係に暗い影を落とすでしょう。
また、期限を決めておくことは、企画の進行状況を捉える際にも役立ちます。現在企画は順調に進んでいるのか、遅れているのか。そのことがわからないと、メンバーもスピード感が掴めず、やる気をだすことができません。何よりリーダー自身が適切に管理を行えなくなってしまうでしょう。
ここまでの話を読んで、もしかするとこのように思う方もいるかもしれません。
「でも期限なんて、実際やってみないとわからないじゃん!」
お気持ちは非常によくわかります。しかしそれは、全体の工程を管理するという最も重要な仕事を放棄しているのと同じであり、とても正しい行為とはいえません。
正直な話をすれば、イレギュラーや見積もりの甘さで期限日までに完成させることが困難になることは多々あります。そういったときは方々に頭を下げつつ、期限を後ろ倒しすることになるでしょう。しかし「あなたの謝罪」をコストに「企画の完成」が召喚できるなら、それは素晴らしいことではありませんか。
仮に正確な期限を設定できないとしても、一生懸命考えて期限を設定すること自体に価値があるのです。ミスを恐れず、期限は大胆に設定していきましょう。
確認頻度を決めておく
企画を開始する前に、企画に関する連絡をチェックする頻度である「確認頻度」を決めておきましょう。
仕事であれば平日は毎日メールや連絡をチェックするのが義務です。一方で本サイトに関連する協力プレイは、基本的には趣味の範疇です。したがって、事前に「何日に一回連絡を確認するか」を決めておくと、悲劇的なすれ違いを防止できます。
通常であれば、毎日〜三日に一度程度がよいでしょう。忙しいメンバーがいる場合は(そのメンバーに限ってもいいですが)、一週間に一度、休日に確認してもらえればよい方かもしれません。
「確認頻度」を決めておくことによって、逆に確認できない時期の申告も容易になります。「あらかじめ○しろまる日に一回連絡を確認する」というルールがあるわけですから、そのルールを守れなさそうなときに申告をすればよいのです。
また、「確認頻度」はマネジメント側にとって、リマインドや非アクティブ化の基準にもなります。確認頻度を越えて連絡がないメンバーには、声掛けを行ったり、場合によっては別メンバーへのタスク再割り当てをすることになるでしょう。
確認頻度はメンバーがその企画に割かねばならないリソースの参考にもなります。とても忙しい人が、毎日連絡を確認しなければいけない企画に参加することは困難でしょう。逆にマネジメント側にとっては、メンバーの忙しさを表す指標にもなります。全体的な確認頻度に合わせることが厳しいメンバーがいるような場合、そのメンバーの確認頻度を落としたうえで、割り振るタスクも軽めにしましょう。
第二章:会議や相談について
企画を動かすならば、会議や相談が生じることは避けられません。この章では会議の進め方や、チャットの活用方法などについてお話します。
専用の会議鯖を作る
企画用に、自由に調整できる専用の連絡場所を作りましょう。Discordの鯖や、Slackのワークスペースなどがこれにあたります。他の場所を間借りすると、どうしてもチャンネルの管理等で効率的に作業を進められない可能性があります。
サーバーには、一般的な連絡チャンネルのほかに、次のようなチャンネルを設けておくとよいでしょう。
- 企画情報をまとめるチャンネル: 概要や全体的なスケジュールを掲載し、重要情報にすぐアクセスできるようにします。
- 会議用チャンネル: 定期的・臨時的な会議で使い、雑談と混線しないようにします。
- タスクとリマインドチャンネル: タスクの割り振りとリマインドに特化したチャンネルを設けることで、すぐに「今なにすべきか」を把握できるようにします。
- アイデア共有用のチャンネル: 隙間時間にアイデアを共有できるように、アイデアを気軽に放り込める場所はあった方が良いです。
他に、分報用チャンネルや予定共有チャンネル、資料共有チャンネル、成果物置き場など、用途に合わせて必要なチャンネルを用意しましょう。
会議の目的とは
サーバーも作り、会議のためにメンバーにも集合してもらいました。定刻になり、会議が始まります。司会は当然リーダーのあなた。仄かな期待が籠った視線を受けながら、あなたは口を開きます。
「......さて、何を話せばいいんだろう?」
結局会議はなあなあで進み、企画について話したことと言えば「頑張ろう!」くらい。あとの時間は当たり障りのない雑談で終わってしまいました──これはまずいですね。会議を開く前には、まず会議では何をすべきか把握しておく必要があります。
会議の主目的は作業内容の明確化と分配、そして締め切り設定です。これをスムーズに行えるように、タスクの切り分け等、あらかじめ会議の準備をしておきましょう。
せっかく会議を開いたのにタスクの分配が行えないということは、次の会議までの時間を無駄にしているということになりますから、そのような状況は基本的に避けるべきです。大抵の場合、意外と細かい作業・やっておくと今後がスムーズになる仕事(例えば共著であれば投稿手順の確認・リスト化など)が残っているはずですから、手が空くメンバーが発生しそうであれば、そういった作業を割り当てましょう。事前にタスクを洗い出し、明確化しておくのはリーダの大切な仕事です。
もちろん、進捗管理や議論すべき部分の相談など、会議で取り扱うべき事項はこれ以外にもいくつもあります。事前に議題やタスクの整理をし、取りこぼしがないようにしておきましょう。
必ず会議は「定期的」に
メンバー全員が一堂に会する会議を定期的に行いましょう。
会議にはもちろん様々な役目がありますが、その中でもメンバーの状態を確認したり、企画から離れかけていた意識を引き戻したり、メンバーの交流を保ったりといった、組織維持のための機能は無視できません。また定期的に会議を開く必要に迫られることで、主催が怠けてしまうことを防ぐこともできます。こういった機能を有効活用するためにも、定期的な会議の実施はほとんどの企画で必須です。
定期的に会議が開かれない場合(オンデマンドの臨時開催のみにするような場合)、メンバーの心が徐々に企画から離れ、結局ぐだぐだになって空中分解する可能性が高くなります。
進捗確認くらいしかやることがないような場合でも、基本的に定期会議は開催しましょう。最初だけ企画のことを話して、最悪雑談やゲームで遊ぶことになっても大丈夫です。話すことがないからといって一度定期会議を中止してしまうと、そのあとぐだぐだと中止にすることが増えて、メンバーの心が徐々に企画から離れ、結局空中分解からの自然破局に至る可能性が高くなります。
会議の頻度はメンバーの忙しさを加味して設定してください。趣味の範疇でゆっくり進める企画であれば、一週間〜二週間に一度程度でいいかもしれません(それ以上間隔があくと、心が離れすぎてしまう可能性があります)。逆に短いスパンで進めるような企画ならば、会議の頻度は高めに設定することをおすすめします。
また大きなタスクの締め切りが近い場合は、一週間前と前日に臨時会議を開くのをお勧めします。後にも述べますが、メンバーの最大瞬間風速が発揮されるのは締め切り直前です。したがって、一週間前にタスクの確認をしてタスクを進める環境を整え、前日の会議で進捗を確認して士気を高める(あるいはそのまま作業通話に切り替える)などの流れを用意してあげると、締め切りによるブーストを最大限活用することができるでしょう。
なお、必ずしも定期会議が必要ない企画もあります。メンバーから独立した記事や部分を集める寄稿型プロジェクトや、アイデアのみを提出してもらって後は一人が書き上げるようなタイプの共著についていえば、メンバーの仕事が独立しているためすり合わせの必要が薄く、また企画自体が長期になりにくいので、会議で扱うべき検討事項やタスクの細かな割り振りがほとんど生じません。その場合は、無理に定期会議をする必要はないでしょう。その代わり、進捗確認を密に行う等、企画から気持ちが離れてしまっているメンバーや困っているメンバーがいないか常に確認できるような仕組みを整える必要はあると思われます。
作業予定日を確認する
特に趣味の企画については、メンバーが毎日作業に取り組めるわけではありません。
そこで定期会議や企画の開始時に、次の会議までの作業可能日・作業時間のスケジュール(あるいは作業予定スケジュール)をメンバーに共有してもらうのはかなり良い方策です。
そうすることで、まず各メンバーに合わせたリマインドや進捗確認が可能になります。それ以外にも、タスクの割り振りの際に参考になったり、見通しを立てるのにも役立つでしょう。逆にメンバーが働きすぎてリアルを犠牲にしてしまうような事態も防げます。
メンバー同士がお互いの作業可能時間を知ることは、お互いの事情を知ることで、作業量の差による不公平感を低減することにもつながるでしょう。また、あらかじめ作業時間を宣言しておくことで、「有言実行しなければ」という外圧を生むこともできます。
反対に、次の作業ができるまでに間が開くような場合には、必ず共有してもらうようにしましょう。
もちろんメンバーによってはプライベートに関わる情報を共有したくない人もいると思われるので、採用するかどうかはメンバーと相談のうえで決定してください。
会議はテキスト? ボイス?
オンラインで会議を進めるのであれば、基本的にはテキストチャットを利用することをおすすめします。
テキストであれば、とにかく議事録が自動的に残るので、あとから決定やアイデアを見直すうえで非常に便利です。また、文面を整理してから発言できるので議論が混乱しにくいですし、複数人が同時に発言しても混線しません。ただし、内容を整理するためにも、会議の終了後に主催は要旨を作成し、チャットに貼っておきましょう。
一方で、ボイスチャットにもメリットはあります。各メンバーの声を聞くことができるので、メンバーのメンタル状況の確認やメンバー同士の結束を高めるという感情的な機能を期待することができます。また、思いついてすぐリアルタイムで発言できるので、ブレインストーミングなどの場面でも役に立つでしょう。
ただし議事録が残らないというデメリットがあるので、主催は適宜議事録を取る必要があるという点には注意してください。
応答を「個人のタスク」化せよ
誰も... 消防車を呼んでいないのである!
- 『しあわせアフロ田中』のりつけ雅春 作
人は周りに人がたくさんいる程、「誰かがやるだろう」と考え、自分で行動を起こさなくなります。
あなたが人のほとんどいない田舎に住んでいて、外から助けを求める悲鳴が聞こえたなら、きっと斧でも持って様子を見に向かうでしょう。しかし都会の人が集住するマンションでは、外から助けを求める悲鳴を聞こえても、誰も様子を見にさえ向かわないのです。「誰かがやることは誰もやらない」のです。
同様に「皆さん意見をください」など、広く呼び掛けるような発言で反応を求めても、メンバーは「誰かが答えるだろう」と考え、結局反応は返ってきません。したがって、あらゆるメッセージは、各メンバーにとって「誰かが返答すること」ではなく「自分が返答する」ものであると感じられるようなやり方で送信する必要があります。
そのためには、以下のようなことを気にかけてください。
- メッセージを送る際は、対象を明確に、名指しにすること。
- その際、対象を一人、あるいはできるだけ少数にすること。
- 自身を対象にしたメッセージには、確認後に何かしらの反応をつけることをルール化すること。
- 返答に時間がかかりそうな場合、期限を設定すること。
最後の2点は、例えば返答に時間がかかるような質問(確認頻度より返答作成に時間がかかりそうなもの)をしたときに役立ちます。「とりあえず見たらリアクション」とすることで、「確認済だけど返答作成中なのか、そもそも確認していないのかがわからない」という状況をなくすことができますし、メンバーの流し読みを防ぐことができます。
メンバーが投稿した質問やメッセージが上記の点を満たしていないような場合は、リーダーが追加で対象者の設定とメンションなどを行ってあげると良いでしょう。
これらの工夫をせずにメンバーの対応が遅いことを嘆くのは、リーダーの義務の放棄です。
「反応待ち」を極力減らす
×ばつについてホームページに掲載してもよろしいでしょうか?」
「はい。お願いします」
「了解です。では〜〜〜〜という文面を追加します。問題ないでしょうか?」
「はい。お願いします」
アイデアを集めるとき、許可を求めるとき......企画やプロジェクトを進める中で、他人からの反応を待つ場面は必ず訪れます。他のメンバーからアイデアを貰ったり、許可を貰ったり、合意を形成したりすることは、チームプレイにおいて最重要の工程ですが、しかしながら「反応待ち」の時間ほど無駄な時間はありません。そういった時間はなるべく減らしたいところです。そのために、作業メンバーは何ができるでしょうか?
一つの方法は、そもそも「反応待ち」の回数を減らすことです。
例えば上の例のように「○しろまる○しろまる×ばつについて、〜〜〜〜とホームページに記載したいのですが、問題ないでしょうか」というように、具体案を作成してから許可を求めるようにしましょう。
二つ目の方法は、そもそも許可を求めないことです。
些細なことや後戻りの効く作業についていえば、合言葉「確認よりも報告」を実践してください。例えば原稿や時程案の作成などは、それぞれの要素についていちいち確認を取るのではなく、一通り完成させてからチェックを受ければよいでしょう。不安な点や従来の計画から変更した点については、まとめてチェックを貰う際に「特にチェックしてほしいところ」「変更点まとめ」という形で挙げておけば十分です。
つまり先ほど述べた合言葉の通り、すべきことは「○しろまる○しろまるをしてもいいですか?」という確認ではなく、「○しろまる○しろまるをしました。確認お願いします」という完了報告です。もしまずいことをやってしまっても、他のメンバーが止めてくれるという信頼を持ちながら作業を進めましょう。
ただし、後戻りのできないこと(例えば、一般に公開されている部分の編集、実行に承認が必要な変更など)については、作業前に合意を形成しておくべきであるということは注意してください。
三つ目の方法は、確認や質問による「反応待ち」の時間と作業を並行するということです。
自分一人では決定できない事柄、わからない事柄、他のメンバーに影響を及ぼすような事柄については、意見・許可をもらいながら作業を進めることもできます。
共著の例で考えてみましょう。自分のパートを執筆する中で、他人のパートに大きな影響を及ぼす伏線などを変更したいときは、他のメンバーの許可が必要になります。当然「○しろまる○しろまるの要素を変更したいのですが、大丈夫でしょうか?」と許可を求めることになりますが、許可が出るまで作業を止めていては、時間が無駄になってしまいます。こういった場合は、とりあえずその変更箇所に関係ない別の部分を書いておいたり、許可を貰える可能性が高そうな場合は、許可を貰ったものとして案を書き進めてしまうのがよいでしょう。
この方法で重要なことは、「反応待ち」は仕方ないとして、「反応待ちで何もしない時間」をなくすということです。そのためにも、必要な確認は早めに行いましょう。だらだらと最後まで確認を引き延ばしていると、「返答がないと進められない作業」だけが残り、「何もしない時間」が生じます。
全ての方法に共通する注意点ですが、あくまでこれは自分の担当・職掌の範囲の話です。自分の担当外のことを勝手に始めると事故が起こるので、担当外のタスクを実行する場合は一旦リーダーに確認を挟むのが賢明です。
なお「手が空いた人から実行するタスク」に分類されているものについては、「自分がやります」と報告のうえ着手しましょう。ここでも「確認より報告」の合言葉が活きてきます。「手が空いた人から実行する」と書いてあるのですから、すべきなのは「自分がやってもいいか?」という無意味な確認ではなく、「自分がやります」という報告です。
ここまではメンバーのすべきことについて話をしましたが、ここからは「反応待ち」の時間を減らすため、リーダーができることについて考えてみましょう。
まずはタスクの割り振りを明確にすることです。
メンバーが自分のタスク・職掌の範囲を理解できなければ、当然「この仕事を自分がやっていいか」という確認作業が生じることになります。それはあまりにも無駄な時間であり、リソースを喰らいます。基本的にメンバーの手の届く範囲にあるタスクについては、全て誰かに割り振られているか、「手が空いた人から実行するタスク」に分類されている必要があります。タスクが増えたなら、それらもすぐに分類しましょう。
次に、メンバーの報告にはこまめにリアクションをつけるようにすることです。
「確認より報告」の合言葉があるとはいえ、メンバーは自身で何かを決定するたびに不安を抱えていることを理解しましょう。この不安を解消するためにも、メンバーの報告はただ読んで終わりではなく、「確認しました。問題ありません」という意思を示すためにもリアクションをつけることをお勧めします。
メンバーへの呼びかけと環境構築の両面から、「反応待ち」を減らして高い効率を実現しましょう。
決断はあなたの仕事である
皿に最後に残った一つのから揚げを取るのは、あなたの役目です。
マネジメントにおいて、不要な遠慮はプロジェクトの破綻と遅延をもたらします。これを最も意識すべきなのは、意見が割れてしまった場面でしょう。
話し合いの結果として、意見が割れ、どうしても議論が平行線になってしまうことがあります。そういった場合に、「ここは多数決で......」「全員の意見をうまく取り入れて〜」などと、訳の分からない遠慮や民主主義を持ち出すことは絶対にやめてください。
そもそも意見が割れる状況というのは、大抵どちらの意見にもきちんと説得力や魅力があるような場合です。そういった場合に無理に主張を統合しようとしても方針がぶれてどっちつかずになるのがオチです。また多数決にしても「より良い方」が選ばれるわけではなく、「何となく無難な方」が選ばれるだけです。
したがって、このときリーダーが行うべきなのは、企画全体の責任を持つ立場から、企画のために最もよい決断することです。どちらかを選ぶという行為は誰かの意見を廃案にするということでもあり、誰もが取りたがらない最後のから揚げです。だからこそ、その仕事はリーダーが行わなければいけないのです。その責務から逃げることで、無駄なコストや方針のブレなどが生じてはいけません。
もちろん、(特にメンバーの関心が高い項目については)話し合いをすること自体はとても大切なことです。なんでもかんでも独断でやれというわけではありません。メンバーの意見を聞き、情報を集めなければそもそも決断することさえできませんし、自分以外の意見に耳を貸さないことはメンバーを尊重していない邪悪な仕草として受け取られます。決断をするということは、「あなたが好きなことをやる」という行為ではありません。あくまでどちらも不正解ではなく、同じくらい説得力があるときに、「決断という誰も負いたがらない責任を負う」のが「決断」です。
そのほか、複数の案があり、正直どれでも良いがために議論が停滞してしまう場面や、メンバーの意見を問う必要もない些細なことも、リーダーが積極的に決断を下すべき事項です。
リーダーが大権を振るうことについて不安があるのならば、あらかじめ企画前にメンバーに宣言しておいてください。決断はリーダーの必須業務です。恐ろしいですが、勇気をもって立ち向かう覚悟を持ちましょう。
第三章:タスクの割り振りと進捗管理について
リーダーの最も大きな仕事の一つが、メンバーへのタスク分配です。作業としては至極単純で、必要なタスクを洗い出し、適切にメンバーに割り振り、タスクの進捗を管理するだけ......なのですが、単純なものほど難しいとはよく言ったもので、この仕事は一筋縄ではいきません。しかもこのタスク分配は非常に重要で、リーダーの分配スキルが、チーム全体の出力を大きく左右するといっても過言ではありません。
この章では、そんなタスクの割り振りから進捗管理について、いくつかの提案をしていきます。
計画的にタスクを進めるメンバーなどいない
この世界のほとんどの人間は、計画的に少しずつタスクを進めたりしません。締め切りが近づいてきて初めて仕事に取り掛かり、仕事効率の最大瞬間風速を記録するのは締め切りの直前です。
夏休みの宿題をギリギリになって泣きながらこなしていたあの頃から、私たちはちっとも成長していません。メンバーが計画的にタスクをこなしている前提で話を進めようとすると、企画が破綻します。
「外圧」という役割
調整やタスク割り振り、いざというときに責任を取る......そういったわかりやすい仕事に加えて、リーダーには隠れたもう一つの重要な役割があります。それが外圧です。
自分を完全に律し、自分だけの力で作業を進められる人間はそう多くありません。大抵の人間は、期限や期待など、周囲からの圧力に押されて仕事を始めます。この圧力を生むのが、リーダーの仕事です。ぐだぐだになってしまう企画の多くが、外圧不足によるものです。
外圧のあげ方についてはそれぞれの章で適宜触れていますが、基本的には定期的な進捗確認と締め切りの厳守が圧力維持の要になります。
もちろん圧力が強すぎると潰れてしまうので、作業を促す程度の適度な圧力になるように調整しましょう。
タスクの割り振りを恐れない
リーダーの最も犯しがちなミスの一つが、変な遠慮をしてメンバーにタスクを割り振らない、あるいはごく少ないタスクだけを割り振ってしまうことです。
まず全く割り振らないとどうなるかということですが、単純に仕事が進みません。「これやらないとね〜」とだけ言ってメンバーの方をチラチラ見ていても、基本的には誰もそのタスクをやってくれないからです。特に新しく増えたタスクについては、リーダーがしっかりと割り振っていきましょう。
次に割り振るタスクが少なすぎる場合について言えることは、むしろそれがメンバーに対して不誠実な態度だということです。企画に参加した以上、メンバーはタスクをこなす覚悟ができているはずです。だからこそ、メンバーの使えるリソースを考え、少なすぎず多すぎないタスクを割り振るのがリーダーの義務です。逆にタスクが全然もらえないと、企画への熱量は失われていきます。
ここで重要なのは、最初から適切な量のタスクを割り振ることではありません。多少多めに割り振ってもメンバーから「この量は無理!」といってもらえる環境を作ることです。メンバーが気軽に言い出せるよう、リーダーはタスク割り振りの際や進捗確認のタイミングで、細かに声掛けを行うと良いでしょう。
タスクは具体的に、細かく
タスクを分配するときは、メンバーが作業をイメージできるよう、なるべくタスクを具体的にするようにしましょう。
作業と完了条件をメンバーがイメージできない場合、単純に効率が悪くなったり、作業内容の勘違いが起こったりします。したがって、具体化や例を提示するなどの方法を用いて、タスクをイメージしやすくすることを心掛けてください。
また、抽象的で大きめのタスクは、なるべく細かく小さなタスクに分解するようにしましょう。例えば「○しろまる章を書く」などの大きなタスクの場合は、「○しろまる○しろまる文字まで進める」「○しろまる○しろまるのシーンまで書く」という小さなタスクに分割しましょう。そうすることで、作業がだらけることや完了報告が滞ることや、進捗を実感できず士気が下がることを防ぐことができます。
「何個でもいい」系のタスク(例えばアイデア出し)などでも、最低個数を提示するなどして、クリア条件を明確にしておいた方がメンバーのやる気に繋がります。「アイデアをどんどん出してください」より、「各自アイデアを最低でも三つずつ提出してください。多い分にはいくらあっても助かります」という言い方の方がよい指示だしといえます。
どうしても具体化や細分化が難しい場合は、こまめに進捗確認を行い、メンバーが放っておかれることのないようにしましょう。
全体的な流れを区切り、タスクを明確化するのはリーダーの重要な役割です。もしメンバーの作業が滞りがちであれば、メンバーを責める前に、タスクが大きすぎないか、抽象的すぎないかを検討してください。
「公平なタスク分配」は悪魔の見せる夢である
「公平」......なんと美しい言葉なんでしょう。その輝きはあなたの目を焼き、大切なものを見失わせます。
メンバーはそれぞれが別々の能力やリソースを持っています。そんなメンバーたちに「公平に同量の」タスクを分配することは、思考停止に陥ってしまっています。
時間的余裕があるメンバーには、それだけ多くのタスクを担ってもらう必要があります。能力の高いメンバーは同じ時間で多くの仕事をこなせるでしょうから、それだけ多くの、あるいは難度の高いタスクを割り当てることになります。またどうしても個人のスキルへ依存するようなタスクは、そのスキルを持つメンバーにお願いするしかありません。そうなると、そのメンバーのタスクが多めになることは避けられないでしょう。
これらの配慮をせず、全てのタスクを同量に分配してしまった場合、あり得ない計画によって企画が途中で破綻することになります。それを避けるためにも、メンバーのリソースと能力によってタスクの分配に傾斜をつけ、現実的に実行可能な計画を立てるようにしましょう。
もちろんいくら傾斜が仕方ないものだとしても、ごく少数の人間に大量のタスクが降りかかるような状況は、できる限り防がなければいけません。とはいえ、現実問題そうなってしまった場合は、きちんとメンバーのメンタル管理を行うべきです。具体的にはしっかり謝罪と感謝を伝えること、そしてそのメンバーの貢献を可視化することです。例えば共著であれば、映画のクレジットのようにどこのパートにどのメンバーが関与したかを明確に書くと良いでしょう。そうすれば、メンバーの頑張りを多くの人に認めてもらうことができます。
必ずしもタスク分配が公平にならないということに関しては、あらかじめメンバーに了解を取っておいた方がよいでしょう。理解のないまま傾斜的な配分を行うと、メンバー同士で軋轢が生まれかねません。
また、能力による傾斜配分はときに無用な僻みを生むので、あまり露骨にやらないようにしましょう。はやくタスクをこなせているメンバーのタスク量を徐々に増やす(もちろん同意のうえで)というやり方が、最も角が立たない方法かもしれません。
リーダーは常に余力を持つ
リーダーは、自身が余力を持てるようにタスク量を調整しましょう。
もちろんプレイヤーとして最前線で活躍したい気持ちもわかりますが、自分のことで手いっぱいになってしまった場合、他のメンバーの進捗管理まで手が回らなくなってしまいます。そうなれば企画が滞り、せっかくプレイヤーとして投資したリソースが無駄になってしまうでしょう。
また、リーダーは不測の事態に対応するための要因でもあります。メンバーが失踪した、絶対に終わらせるべきタスクが終わっていない等々、リーダーがすでに満身創痍だと、こういった解決にリソースを割けなくなってしまいます。
自分がやりたいからといって仕事を詰め込んでしまうのは、決して褒められたものではなく、むしろチームの強度を低下させる身勝手な行為です。うまくメンバーと協力し、余裕をもってタスクやマネジメントに取り組みましょう。序盤は負い目を感じるとしても、どうせ終盤で死ぬほど忙しくなります。
タスクの締め切り日は明確に、タイトめに
タスクの締め切り設定は、必ず明確に行いましょう。また口頭で伝えるだけではなく、テキストやカレンダーに残し、すぐに確認できるようにしておくべきです。そうすることで、タスクがなあなあの内に放置されたり、忘れ去られたりすることを防げます。メンバーへのリマインドも容易になりますし、メンバーもいつまでにタスクをこなせるかがわかりやすいでしょう。
また、タスクの期限はゆったりめに取りたくなりますが、むしろタイトめに設定することを心掛けましょう。期間をタイトに取っておくことで、様々な不測の事態に対処する時間的余裕が生まれるだけでなく、作業の効率も上昇します。企画の最終的な締め日から逆算して、一週間くらいは余裕を持てる期限設定ができるといいでしょう。
ただし、「期限はタイトめに設定しているので、最悪遅れてもなんとかなる」ということは、チームメンバーに知らせるべきでない場合もあります。特にサボり癖のある人がこれを知ると、タスクの期日が有名無実化します。そのような人がチームに居るなら、あくまでリーダーの心のなかに留めましょう。
加えて既に述べた通り、多くのメンバーの最大瞬間風速が出るのは締め切りの直前です。ゆったりめに取った場合、途中でだれるのがオチであり、効率が悪くなります。一方で期間をタイトに設定すると、常に締め切りが近い状態になるため、期間の多くを有益に活用することができるのです。
もしかすると、「タスクを確実に完了してもらうためにも、ゆったり期間を取った方がいいのではないか」と思うかもしれません。しかし、別にゆったり期間を取ったところで締め切りに間に合わないメンバーは必ず出てきます。それに仮にメンバーが締め切りに間に合わなかった場合でも、新たな締め切りを設ければいいだけです。むしろもう一つ締め切りができることで、より締め切り直前ブーストを活用できることになります。
もちろん厳しすぎる期限はメンバーのやる気を削ぐだけですので、現実的な範囲で間延びしないような期間を設定するように心がけましょう。期限の設定時にメンバーに「○しろまる日までにいけそうですか?」と質問しておけば、メンバーにとっても無理のない期限設定ができるでしょう。
期限までに達成できなさそうなときの報告を徹底する
メンバーには、「期限までに達成できなさそうなときは報告する」ということを徹底しましょう。
もっと言えば、「期限に間に合うのが最良、期限に間に合わないことを報告するのが次善、何も言わないまま遅れるのは最悪、遅れたのに謝らなければ人間じゃない」という順序を理解してもらいましょう。
タスクが間に合わないのは、まだ仕方のないことです。しかし、「報告」は誰でもできます。もし何も報告なしに期限に間に合わなかったメンバーが出たら、必ず「報告はするように」と伝えてください。
リマインドを恐れてはいけない
タスク期限日の直前や、期限日を過ぎてもタスク完了報告がない場合、確認頻度を越えて連絡に反応がない場合などは、必ず(そしてすぐ)リマインドを行うようにしてください。
メンバーはこの企画以外に様々な仕事に取り組んでおり、タスクを忘れてしまっている可能性は十分にあります。そのような場合に、不快に思われるのを恐れてリマインドをしないのは、リーダーの怠慢としかいいようがありません。
リマインドはリーダーの義務です。逃げずに必ず行うようにしましょう。
進捗の確認について
特に大きなタスク(例えば一週間以上かかるようなもの)を動かす場合や、定期的な会議までに日が空く場合などには、タスクの終了報告だけでなく、タスクの経過の確認を必ずすべきです。
メンバーが主体的に行うものとしては、定期的に自分から進捗を報告する制度を用意するという方法があります。いわゆる日報や週報がそれにあたります。他にも分報で進捗や仕事の感想をリアルタイムに共有する方法もあります。チャンネルを用意するだけで終わらせず、SlackやDiscordに専用チャンネルを設け、リーダーが積極的に呟いていくといった、環境づくりも必要でしょう。
ただ、日報や週報を共有することが、趣味にかける労力としては大きすぎるという考えもあるでしょう。また我々のような†孤独に生きる者†にとって、自分のことを積極的に共有するのはややハードルの高いことかもしれません。
そういった場合は、リーダーが定期的に進捗を尋ねるという手段をとるようにしましょう。進捗を尋ねるペースはメンバーに合わせる必要があります。毎度締め切りに間に合わせられるようなメンバーであれば、一週間単位で尋ねる程度でいいかもしれません。逆に期限に間に合わせるのが辛そうなメンバーや、うまく作業に取り組めないメンバーについては、短期間──それこそ一日〜二日ごと程度の頻度で──進捗確認をする必要があります。
また、事前に作業可能日のスケジュールを共有しているような場合は、作業後に簡単な進捗報告を行ってもらうという方法でもよいでしょう。
とにかく重要なのは、メンバーをほったらかしにしないということです。進捗確認の主たる目的は、メンバーの状況を把握し、必要に応じてサポートすることです。しかしそれと同じくらい、進捗を確認されるという「外圧」を生じさせるという役割も重要です。当然進捗確認の頻度が高いほど外圧が高まるので、メンバーに合わせて適宜手法・頻度を調整しましょう。
メンバーが締め切りを破ってしまったら
メンバーによる締め切り破りが発生した場合の対応は、リーダーによって様々です。
外圧を強く意識しているリーダーの場合、タスクの軽重に関係なく締め切り破りに対しては毅然とした態度で対応するでしょう。つまり、淡々と締め切り破りが「してはいけないこと」であることを説明すると予想されます。もう少し柔和なリーダーであれば、軽度の締め切り破りは見逃してくれるかもしれません。
しかし両者はどちらも、「締め切りが破られた」という変えられない過去の事実より、「これからどうするか」という未来を重視しているという点で共通しています。罪を責めても山積したタスクは減りません。リーダーがまず考えるべきは、この遅延されたタスクをどうするか、ということです。いらついて感情的な対応を取るなどもってのほかです。
具体的なリカバリー方法は次の項で確認しますが、意識すべきことは「遅延したタスクをどう処理するか」と「締め切りを破ることが慢性化してぐだぐだになることを避けるため、どのような対応を取るのがベストか」ということです。
また、締め切り破りが発生した場合は、自分のマネジメントに原因があることも考慮しましょう。例えばリマインドが足りない、進捗確認を怠った、タスクが分かりにくい、割り振ったタスクの大きさが不適である、相談しにくい環境である......などが挙げられます。
締め切りを破らないのはメンバーの仕事ですが、締め切りを破らせないのはリーダーの仕事です。
リカバリー方法は静かに用意しておく
リーダーは不測の事態に対処しなければいけません。特にメンバーに配ったタスクが遅延した場合の対応は常に考えておくべきです。
最も簡単な対応は、締め切りを伸ばすことでしょう。ただし、毎度この方法を取れるわけではありません。これ以上締め切りを伸ばせないケースやそもそもメンバーが失踪しているケース、メンバーに遅刻癖がついているケースなどは、締め切りを伸ばしても問題が解決しないことがあります。
次に考えられるのは、別メンバーにタスクを割り振りなおす対応です。担当メンバーが失踪した場合や、急用で動けなくなった場合に利用することができます。引き受けてくれた別メンバーにはしっかり感謝を伝えましょう。
テクニカルにはなりますが、「そのタスクがなくとも何とかする」という方法もあります。例えば連作の場合、間に合わなかったシーンは次話に回す等、調整することができます。
最終手段は、リーダーが何とかすることです。最も手っ取り早い方法ではありますが、あくまで最終手段であるという認識はしておきましょう。リーダーにタスクが集中すれば当然リーダーの余力がなくなり、チームの強度が下がります。それだけでなく、結局リーダーが何とかするという雰囲気の蔓延は、チームの士気を下げ、リーダーの外圧力を損ないます。
さて、ここまでリカバリーの手法について説明してきましたが、一方で無闇にリカバリーの可能性について言及するべきではありません。
第一に、メンバーはリカバリーを用意しているアピールをされると、自身が信頼されていないのだと感じることがあります。こうなってしまうと、やる気が破壊的に削がれます。リカバリー計画は最終手段であって、リーダーはあくまでメンバーのことを信頼しているというスタンスを取りましょう。
第二に、「リカバリーがある」という認識は外圧を減少させます。「どうせタスクが間に合わなくてもリーダーが何とかしてくれる」と思われると、タスクの期限が有名無実化してしまうのです。したがって、リカバリーの可能性を見せびらかせたりせず、あくまで「このタスクはあなたが終わらなければヤバい」という状況を維持するようにしましょう。
タスクを完了したら
メンバーからタスクの完了の報告があったら、必ず成果物を共有してもらうようにしましょう。
「やりました!」という報告だけで満足してはいけません。学校で丸付け済のワークをわざわざ提出させるように、完了報告だけでなく成果物を確認することは必須の工程です。
例えば思いもよらない勘違いやズレなどは、完了報告のみから読み取ることはできません。こういったものがブラックボックス化されたまま放置されると、最終的に破滅的な問題が生じます。誰もが実物を確認できる環境に成果物を共有しておけば、こういった問題はおきません。
他に、成果物を共有することにしておけば、「最悪やったことにして報告しちゃえ」という逃げ道を封鎖することができます。つまり、外圧を維持することができます。
本サイトにおける共著であれば、進捗を必ず砂箱の下書きに反映することを徹底することや、Google Documentを活用してリアルタイムで変更が反映されるようにすることですることで成果物が共有されやすい環境を構築することができるでしょう。
また、メンバーのタスク完了報告については、必ずポジティブな反応を返すようにしましょう。
メンバーも人間ですから、好意的な反応を貰うと(悪い言い方をしない限り)良い気分になります。逆に反応がなければ、徐々にやる気を失っていくものです。メンバーの士気を保つのも、リーダーの大切な役目です。
修正が必要な場合でも、まずは「作成ありがとうございます!」等、好意的なコメントから始めるようにしましょう。それだけで受け手の心象は大きく変わります。
もちろん、ときには厳しいことを言う必要もあります。しかし大抵の場合、メンバーがわざわざコストをかけてタスクを実行していることを忘れないでください。メンバーは、やろうと思えばタスクに手を付けず企画にダメージを与えることもできます。ですから、基本的にタスクを完遂してくれた時点で感謝をすべきなのです。
自分のリアクションが「上から目線」にならないかどうか心配な場合は、「助かりました!」や「非常にわかりやすいです!ありがとうございます 」など、感謝を基調とするのがおすすめです。「嬉しいです」など、相手への評価ではなく自分の想いを伝えるアイ・メッセージも有用です。
自分が疲れているときにポジティブな気持ちを伝えるのは難しいかもしれませんが、これは疲れていてもやるべきリーダーの重要な仕事の一つです。どんな状況でも、感謝や良い評価はこまめに伝えるようにしましょう。
納得感のない修正を要求してはいけない
修正を要求することは、リーダーにとって快感です。すべてを手中に収めたかのような全能感を得ることができます。しかしこの快感に支配されたとき、あなたは醜悪で矮小な化け物に成り下がります。
確かに、メンバーの成果物に対して修正を要求しなければいけない場面は多々あります。しかしその場合は、必ずメンバーの納得できる理由を添えて修正をお願いするようにしてください。面倒だからといって「これとあれとそれをこのように直してください」とだけ伝えるのははっきり言って悪手です。
第一に、成果物を提出したメンバーは、「これでよし」と思って提出をしているということを絶対に忘れないようにしてください。その修正を要求されるというのは、そもそもストレスが溜まる事象であるということを理解しましょう。
メンバーが「これでよし」と思っている以上、「それではいけない理由」を論理的に説明できない限り、その修正はストレスフルで理不尽な仕打ちでしかありません。こういったことを繰り返せば、リーダーの信頼は地に落ち、不満が燻っていくことになります。
また、理由をわかりやすく説明することができれば、次から同様のミスが起こることを防ぐことができます。こういった説明の積み重ねが、メンバーのスキルアップと長期的なコスト低減につながるのです。
もし理由を論理的に説明できず、「なんかこっちのほうがいい」というわけのわからん感性的な理由で修正をしたいと思っても、そのような修正要求は基本的にすべきではありません。あなたがほんの少し満足することより、理不尽な要求をしてメンバーの士気を下げるデメリットのほうがはるかに大きく、残念ながら最悪の行為の一つです。
お互いのために、丁寧な説明を心がけましょう。
よっぽどのことがない限りメンバーから仕事を奪わない
メンバーの仕事を見ていて、「自分がやった方が早い」と感じることがあるかもしれません。しかし基本的には、メンバーの仕事は奪わないようにしてください。
メンバーの仕事を奪うというのは、リーダーとして最悪の行動です。これは「私はあなたを尊重していません」というメッセージ以外のなにものでもなく、メンバーの自尊心とやる気を破滅に追い込みます。これをされたメンバーは、場合によっては今後使い物にならなくなる可能性すらあります。それはリーダーとしての仕事の放棄、あるいはくだらない有能マウントに他なりません。
もちろん、メンバーの仕事を回収せざるを得ないような場合もあります。それは、期限が迫っていてこれ以上遅れさせられない場合や、メンバーがこれ以上このタスクを続けても完遂できないと判定した場合など、本当にどうしようもないときだけです。
誰がリーダーをリードするのか?
リーダーの主な仕事は、声掛けや環境整備を通して、怠惰や先延ばしという名の悪魔を鍵のかかった部屋に閉じ込めてしまうことだと言えるでしょう。リーダーは、悪魔がメンバーを誘惑しないよう、扉の前に立って厳しく見張ります。だからこそ賢明な悪魔は、手始めに扉の前に立つリーダーを誘惑するのです。
このエッセイで挙げられている「やるべきこと」──例えばリマインドや会議の開催などは、リーダーの「タスク」であるといえます。そしてリーダーも人間である以上、他のメンバーと同様にタスクを忘れたり、先延ばしにしてしまう可能性があります。あるいはもっと単純に、私生活が忙しくなってリーダーの役割を果たせなくなってしまうかもしれません。
大型企画の場合、この危険性はより高まります。人が多くなればなるほどリーダーのやることは多くなり、一つ一つのタスクもより面倒になりますが、一方で人が増える分一人一人が感じる責任感は薄れます。リーダーの仕事が滞っていても、誰もが他人事のように感じ、指摘してくれません。それなのに、企画が転んだときのダメージは致命的です。
このような事態を防ぐためには、(特に大型の企画では)あらかじめ副リーダーを決め、メンバーに周知しておくことが効果的でしょう。
通常時、副リーダーはほとんどの点において一般メンバーと変わりません。「船頭多くして船山に上る」を避けるために、特別な決定権も持っていないほうがよいです。特別なのは次の二点のみです。
- リーダーを監視する: リーダーのやるべきことを把握し、必要に応じて、リーダーに対してリマインドや催促をします。
- リーダー不在時の代打: リーダーが失踪したり、仕事をすることが不可能になった場合、代わりにリーダーの権利を引き継いで、企画を進行します。
なお、もしあなたが副リーダーでなく一般メンバーで、かつリーダーの仕事が滞っているのを見かけたとしても、勝手にリーダーの仕事を代行するのは絶対にやめましょう。確かに副リーダーの仕事は重要ですが、その役目を各人が無秩序に担おうとすることは、全ての人間にとって最悪の選択になります。代わりに、まずはリーダーに優しく声をかけてあげてください。業務が厳しそうであれば、助力を申し出るとリーダーは喜ぶかもしれません。
第四章:メンバーとの関わりとトラブル
企画は人が作るものであり、人が関わるということはトラブルが起きるということです。この章では、人間関係で起こり得る問題やその問題への対処、メンバーとのよりよい関わり方について触れていきます。
もしメンバー間で仲違いが起きた場合でも、成果物を公表できるよう約束しておく
どれだけ仲のいい間柄でも、一緒に仕事をした途端にお互いを嫌い合うようになってしまうことがあります。このように、人間関係の事故は事前に防げるようなものではありません。
したがって、「もしメンバー間で喧嘩別れがおこり、脱退者が出たら企画をどうするか」はあらかじめ(仲のいいうちに)メンバーと合意しておくとよいでしょう。
より具体的には、脱退したメンバーの成果物をどうするか、成果物を公表するときに元メンバーの名前を入れておくかはあらかじめ決めておきましょう。「元メンバーが作成した成果物は利用できる。名前は基本的に入れるが、脱退後に希望があれば消すこともできる」等としておくとやりやすいかと思われます。
自治行為を絶対に許さない
メンバーによる他メンバーへの説教や皮肉、あるいは外部での他メンバーへの不満の漏洩、進捗煽りなどは、事前に禁止してください。そして、他メンバーへの改善要求はリーダーが窓口になるということを伝えましょう。
禁止というと強く聞こえるかもしれませんが、こればかりは企画を崩壊させる可能性が重大な因子になるので、本当に許してはいけません。それにこれは何も特別なことを言っているわけではなく、まともな大人の社会常識です。
現代的な秩序は、個々人から自力救済の権利を奪うことで成り立ちました。なぜなら、個々の主観に基づいた救済・報復行動は無秩序に肥大化するからです──などという難しい話はしなくてもよく、「別に監督者でもないメンバーからガミガミ言われたらムカつくよね」程度の認識と、「そうしたムカつきが増えると、メンバーの心が企画から離れ、企画が立ち行かなくなる」ということを共有しておきましょう。
特に高い成果を上げたり素早く仕事を終えたメンバーは、直後にこの禁忌を破ってしまうことがあります。リーダーは絶対にそれを諫め、軽い場合は発言の削除、他のメンバーの不満が高そうなら発言を訂正させるか、謝罪させるかすべきです。くだらない言い訳も許してはいけません。これらの指示に反抗するメンバーは、どれだけ有能でもチームを崩壊させるので、泣いて馬謖を斬る覚悟をしましょう。
また、こういった自治行為に出てしまう人々の中には、強い気持ちで企画に取り組んできてくれたメンバーもいます。頑張ってくれているからこそ、他のメンバーに対して不満を募らせるのです。そういった人々の不満を放置し続けた結果自治行為に至ってしまったのであれば、リーダーには大きな責任があります。もちろん自治行為は決して許されるものではありませんが、それ以上にリーダーは自身のマネジメントについて大いに反省すべきでしょう。
もしあなたがメンバーで、どうしても不満があるのなら、リーダーにまずそれを伝えてください。もしそれでも改善がない、あるいはあなたの不満が受け入れられないのであれば、あなたには二つの選択肢があります。我慢して続けるか、企画を脱退するかです。それ以外の選択肢はあなたの名誉を傷つける可能性が高いので、なるべく避けるようにしてください。
説教をしない
リーダーというと、何かと説教をしているイメージを持つ人もいるでしょう。しかし説教というのは、基本的に恐怖でもって相手を支配する手段であり、恐怖はモチベーションと効率を下げます。しかも説教は、1 リーダーが相手より圧倒的に強い位置にいて、2 相手がその構造から抜け出せず、3 強制的に相手を従わせる必要がある という極めて限定的な状況でしか効果を発揮しません。趣味の企画でこの要素が揃うことはまれですから、説教はモチベーションを下げるだけの悪い選択肢であることがほとんどです。
メンバーが何かまずいことをしてしまったときの対処は、まず「次上手くやろう」と伝えることです。次にメンバーが上手くやれるように一緒に方策を考えたり、環境を整えたりすることが続きます。それでも改善できない場合や問題が大きい場合には、淡々とその問題行動によってどのような不都合が起こるかを説明し、あまりにもひどい場合には一緒に企画を進めることはできないと伝えることになります。
もちろん、いくつかの「感情的な縛り」を用いてメンバーに何かを強要する方法もあるでしょう。しかしそれは高度なうえに、メンバーへのリスペクトを欠き、失敗すると悲劇的なデメリットを生むので、ここでは扱いませんし、推奨もしません。
無理に難しいことをしようとせず、説教など感情的な対処は控えたほうがよいでしょう。
スランプに陥ったメンバーは通話に誘おう
外部SNS等でメンバーがスランプに陥り、辛そうな声を漏らしていたのであれば、相談通話や作業通話に誘うようにしましょう。
メンバーがネガティブな発言を繰り返していると、企画全体に対する周囲からの印象が悪くなったり、秘密にしておくべきことが流出してしまったりする場合があります。
また単純に、話を聞くだけでメンバーの思考が整理され、作業の効率が上がることもあります。
常にSNSに貼り付いていろというわけではありませんが、追い詰められているメンバーを見つけたら、メンタルのサポートを積極的にしてあげましょう。
メンバーにあまり期待しない
メンバーに過度な期待をすべきではありません。先にも書きましたが、「タスクの締め切りに間に合わないことを連絡してくれる」だけでも嬉しいと思いたいところです。
これはメンバーを見下せといっているわけではありません。リーダーは企画に人一倍思い入れがあるでしょうが、それは異常なことです。メンバーには他にもやるべきことがあり、常に自身の人生を精一杯送っています。そういった「普通の人たち」と一緒に企画を完成させていく環境を構築するのがリーダーの役目であって、過度な期待をすることはその役目の放棄ということになります。
加えて、勝手に期待しているとメンバーが失敗したときに「裏切られた」と感じ、精神衛生上よくありません。リーダーが被害者面をしだしたら、その企画は終わりです。
メンバーに期待することは、「決めたことを守ること」「守れなさそうだったら事前に連絡をくれること」くらいにしておくようにしましょう。
メンバーを変えようとしない
リーダーの最も大きな過ちの一つは、自分がメンバーを指導し、変えてやろうと思ってしまうことです。
それぞれの人生を歩み、環境に適応しながら自分なりに成長した結果が今の各メンバーであるということを絶対に忘れないでください。その積み上がってきた非常に重みのあるものを変えようなどと、たまたまリーダーをやっているだけの矮小な人間が思い上がるべきではありません。
もちろん、企画を進める中で守るべき事項はしっかり伝え、守ってもらわなければいけません。例えば無言で締め切りをすっぽかすようなメンバーには、事前連絡を徹底してもらわなければいけないでしょう。しかしそれは「企画のために必要なことをするようお願い」しているだけです。それ以上でもそれ以下でもありません。
人は変えられません。変えられるのは自分だけです。ですから、メンバーに何かをお願いする前に、まず自分ができること、例えば環境の整備やタスクの分配の工夫などを行うようにしましょう。
これは一方で冷淡な結論を導き出します。環境を用意しても必要なことができないメンバーは、残念ながらどうしようもありません。
大事な報告ができない、すぐに失踪する、自治行為で周囲の士気を下げる──どうしても一緒に企画を進められないメンバーが出てしまうこともあります。是正をお願いして環境を整えてもこれらが改善しない場合(あるいは事前に伝えておいたルールを破った結果、取り返しのつかない破滅的な結果をもたらした場合)、それらのメンバーに退場を願うのも、辛いですがリーダーの役割です。この役割から逃げ、そういったメンバーを少しでも放置すれば、企画全体の破綻や、他の重要メンバーの離脱に繋がります。
もちろん、退場をお願いすると恨みを買うリスクがあります。みんなでワイワイやることが主目的の企画であれば、良い感じになあなあにして企画自体を潰した方がマシでしょう。しかしそうでないのなら、本気で取り組んでくれたメンバーがいるのなら、それに報いるためにリーダーはそのリスクを背負う必要があります。
脱退後の直後の元メンバーはリスクのかたまりです。企画や主催への恨みから、システムや企画の名声に対し、とんでもない攻撃行動を取られる場合があります。脱退を打診する前に、あらゆる破壊工作への対応を考えておくようにしましょう。また、できるだけネガティブな感情が強く表出しないよう、打診時はリーダーも感情的にならず相手を慮って対応するよう心掛けたいところです。
メンバーが遊んでばかりいて不安でも......
メンバーがSNSでゲームのスクショばかりあげている場合、作業が進んでいるのか不安になるかもしれません。ですが、我慢してください!
メンバーは独立した個人であり、私生活があります。オンオフが重要です。そこに介入し、メンバーのストレス解消を妨害するのは可能な限り避けるべき手段です。
進捗確認はあくまで定期的なものに留め、「メンバーが遊んでいるのを見たから」という理由で行わないようにしましょう。
なおメンバーとの関係構築が非常に上手く行っていて、かつメンバーの締め切り破り癖が強く、さらに締め切りがこれ以上伸びると不味いような場合は、最終手段として声掛けを行うという選択がでてくることもあります。そういう場合でも、あらかじめ「ヤバそうだったら確認するからね」と同意を取っておくようにしましょう。
メンバーのオフを邪魔することはかなりの悪手であるということを理解し、不安と全てを支配したい欲求、自分は頑張っているのにというイラつきに飲まれないようにしましょう。
Don't be a Brilliant Jerk !
あまり良く思っていない人についていこうと考える人は多くありません。
また、ちょっと無理をお願いしなければならないときや、成果物に対する修正を依頼するとき、一瞬でも「は?」と思われると相手のやる気が急激に下がります。逆にリーダーに人望があれば、逆境さえメンバーを盛り上げるスパイスになり得ます。
基本的に、人を動かすのは人望・人徳です。それはあまりにも自明な事実であるのに、特に有能なリーダーは自身の能力に溺れ、メンバーの感情を軽視してしまうことがあります。
"Brilliant Jerks"という言葉を聞いたことがあるでしょうか。「有能だが協調性がない人」「態度の悪いハイパフォーマー」という意味で使われる言葉です。仕事はできるが一々嫌味を言ってくる、とにかくなんにでもダメ出しをする、合意形成を怠って我が道を押し付ける等、あなたも遭遇したことがあるかもしれません。
このような人は「自分で仕事をする」場合は高いパフォーマンスを発揮しますが、他のメンバーのパフォーマンスを下げてしまうとされており、リーダーなんてやらせようものなら悲惨なことになります。
自分にそのような傾向・言動があり、それをメンバーの前でもやっていると感じたなら、強く意識して改善すべきです。メンバーをリスペクトできないのなら、例えプレイヤーとしては有能でも、リーダーとしては無能です。
おわりに
ここまで四章に渡って、チームプレイでリーダーが注意すべき事項について語ってきました。
全て読んだ方は、もしかすると「リーダーって面倒なんじゃないか?」と思うかもしれません。はい、その通りです。意識すべきことは膨大で、自制が求められる場面も多くあります。慣れない仕事ばかりで、常に不安と戦うことになるでしょう。企画が失敗したとき、真っ先に刃を向けられるのはリーダーです。
しかし一方で、リーダーはチームプレイに不可欠な存在であり、やりがいと価値のある仕事でもあります。企画が成功したときの高揚と感動はひとしおでしょう。
最初は恐ろしいかもしれませんが、あまり気張らず、是非リーダーに挑戦してみてください。補足資料を見てもわかる通り、このエッセイの執筆者たちも全てを完璧にこなせているわけではありませんし、それだけの挑戦の価値があります。
そしてなにより、リーダーシップはあなたの夢を叶える強力な手段です。チームの力は個人の力の和を越えます。例え一人一人が戦っても勝てないような相手でも、リーダーシップを発揮してメンバーの力を最大限生かすことができれば、きっと打ち勝つことができるでしょう。
このエッセイを通して、チームプレイについてある程度の知識を得ていただくことができたと信じています。さらに、このサイトにはコミュニティがあり、創作や運営といった実践の機会が豊富にあります。つまり今必要なのは最初に声を上げる勇気だけ。だからこそ、さあ──
──武器を取れ! 戦列を整えろ! 小さな槍を合わせ、我が物顔で君臨する巨人を殺せ! そして、自分自身の世界を手にするのだ! 協力とは、すなわち革新の王道である!
補足資料
メンバーが過去の企画で実際に使った文面の実例や振り返りなどを集めました。過去の事例の紹介という都合上、どうしても自分語りや自慢っぽくなってしまうことはご了承ください。
また、掲載許可を下さった各企画関係者の皆様にこの場を借りてお礼を申し上げます。突然のお願いにもかかわらず掲載についてご快諾いただき、本当にありがとうございました。
これはJiraku_Moganaが初めての共著で用いたサーバーのチャンネル構成です。
ザ・シンプルな構成ですが、これはメンバーを収集しサーバーを作成した時点で記事の大枠が書き上がっていたという特殊な状況だったため。批評と雑談ができるスペースがあれば十分でした。
逆にいえば、それ以上のコミュニケーション(会議や相談)が必要ならもっとチャンネルの構成は工夫する必要があるでしょう。今から新しい共著をするなら、もう少し凝ったチャンネル構成にすると思います。
チームコンテスト2020、チームMMMRの会議は、なんと他人のサーバーを間借りして行われていました。というのもこのチームの始まりは、仲間内で遊ぶために作られたサーバーでの雑談中に、k-calが企画を持ちかけたことだったからです。k-calが当時企画運営経験があまりなかったこともあり、チーム用に使っていたチャンネルは "#カノン「共異廻歴」" のみでした(もちろん、元々遊ぶためのサーバーだったので、雑談チャンネルは他にありましたが)。
それでも企画が順調に進み、コンテスト初日投稿にこぎ着けたのには、いくつかの理由があると考えています。まず一つが、個人ウィキの下書きページを議事録代わりに使っていたことです。序盤はアイデアがチャンネルに直置きされていましたが、中盤以降重要なアイデアはどんどん下書きページに追記されていったので、忘れられることがありませんでした。あまり複雑な設定もなかったので、そもそも覚えることが少なかったというのもあるかもしれません。
次に、恐らくこれが一番の要因ですが、異様な頻度でボイスチャット(VC)が発生していたことが挙げられます。ほぼ毎日といっていいほどVCにメンバーがいたので、常にほどよい外圧が発生し、リマインドも容易で、誰かが置いていかれるということがありませんでした。さらにほとんどの会話がVC上で行われるので、会議のたびにチャンネルの履歴が流れるということもおきませんでした。
したがって、チャンネルはもっぱら会議中のメモと、タスクの期日の記録(これはピン止めしていました)、そして息抜きも兼ねた分報に使われていました。
上の画像は、この分報が活躍した一幕です。リアルタイムで軽く問題が報告されていますが、たまたま暇なメンバーがそれを見たことによって、すぐに解決することができました。また今思えば、お互いに励まし合うことでやる気の維持ができたのも非常にありがたかったです。
これはほぼ毎日会話が可能という限られた状況なので、あまり参考にならないかもしれません(私ももう一度やるなら、もう少しチャンネル構成を考えます)。ただ分報的な報告チャンネルの有用性と、メンバーと交流を絶やさないことの重要性が伝われば幸いです。
-
- _
700字文体シャッフル企画は、700字の作品を募集し、集まった作品を匿名で公開、作者を当てるという外部企画です。元々meshiochislash does not match any existing user name氏が主体となって不定期に開催されていた企画でしたが、無理を言って定期開催にしていただきました。
私はそのお手伝いという形で運営側に参加していましたが、定期開催のためにとにかく心掛けたのが「コストの低減」です。手間がかかりすぎる企画は、少し異常事態があっただけで転んでしまいます。企画の強度を高めるためには、「誰でも簡単にその回の主催をできる」環境を構築する必要がありました。
まず最初に行ったのは集計等の自動化です。こちらはDr_Kudo氏と共同で行いました。またこのプログラムをPCに詳しくない人でも扱えるよう、マニュアルを作成しました(最近では、既存の文章マニュアルがわかりにくいということで、プログラムの使い方が動画化されました)。
また、主催のタスクをなるべく具体的にフローにしました。その実例がこの下の折りたたみ内部のものです。
-
- _
【開催フロー】
〇 〜31日まで
- 次回の担当者を決定 #雑多な話し合い
- 主催:告知したりテーマを決めたりプログラムを動かす人。(必須)
- 補助: 主催をサポートして、仕事に抜けがないかどうかや、プログラムの動作チェックの様子を見る人。マネージャー・ケツモチ・後見人。主に主催経験者が担当。いなくてもいい。
※(注記) 31日までに決まってなかったら、気付いた人が主催・補助の募集を始める(担当者を決める仕事を担当する)。動いた人はめちゃ偉い。
〇 開催月第一週くらい
- #雑多な話し合い にスレッドを作成【文体シャッフル企画 〇月】。
- 開催日を決定。
- 何かわからないことがあれば誰かにメンションして質問
〇 作品募集開始まで
- テーマ・レギュレーション確定
- 募集用フォームの作成 (プログラムのマニュアルにやり方の記載アリ)
- 募集用フォームのリンクを共有 #リンク共有
- 企画下書きページの作成([URLの指定])
- 過去データを使ってプログラムの動作チェック。予想フォームの作成練習。
- 作品募集ツイートの文面作成 (#テンプレ を参考に)
〇 開催日前日深夜〜当日:
- 告知直前に、下書きページをコピペする形で企画ページを作成([URLの指定] )
- 0:00、作品募集ツイートを投稿
〇 作品投稿期間中
- 途中経過のデータをダウンロードし、プログラム(1_pub.py)の動作チェック。(問題なければ、ダウンロードした途中経過のデータは消しておく)
- 予想募集ツイートの文面作成 ( #テンプレ を参考に)
- レギュ違反の作品ないかチェック
- 投稿された作品をみてにやにやする
- 適宜(〆切1日前など)リマインドのツイートを行う。
〇 作品投稿期間終了・予想募集開始
- 投稿期間終了後、データをダウンロードし、マニュアルに沿ってプログラムを実行
- マニュアルに沿って予想フォームを作成
- 予想フォームのリンクを共有 #リンク共有
- 下書きページで体裁を調整
- 企画ページに反映
- 予想募集ツイートを投稿(目標 00:30 マデ)
〇 予想期間中
- 途中経過のデータをダウンロードし、プログラム(2_result.py)の動作チェック。(問題なければ、ダウンロードした途中経過のデータは消しておく)
- 結果発表ツイートの文面作成 ( #テンプレ を参考に)
- 投稿された予想をみてにやにやする
- 適宜(〆切1日前など)リマインドのツイートを行う。
〇 予想募集期間終了・結果発表
- 予想期間終了後、データをダウンロードし、マニュアルに沿ってプログラムを実行
- 下書きページで体裁を調整
- 企画ページに反映
- 結果発表ツイートを投稿(目標 00:15 マデ)
〇 企画終了
- 余韻に浸りましょう
- 何かあれば #雑多な話し合い で共有
- おつかれさまでした!
基本的には「誰でもこの順にこなせばほとんど考えることなく企画を進行できる」ことを目標にフローを作成しています。そうすることで、誰でも主催を低コストで行うことができるようにすることが目的でした。これはタスク割り振りの際におこなう、タスクの具体化に該当します。例えば、単に「企画ページを作成する」「企画開始を告知する」とだけ書くのではなく、(隠していますが)ページを作成する際のURLの指定や、ツイート文面のテンプレなどまで指定し、とにかく余計なことを考えなくていいように作ったつもりです。
特に4月初頭の定期臨時メンテナンスイベントの運営など、多人数で様々な作業を行うようなイベントでは、このように事前に十分タスクを具体化しておくことで無用な停滞を避けることができると思われます。
なおこのようなタスクの具体化の際は、一度必要な作業を自分でリハーサルしてみると書くべきものがみえてきます。作業をしながら少しでも考えること・自由裁量になりそうなところがあれば、事前にテンプレ化するなどして不確実性を潰しておきましょう。そのほか、 #リンク共有 は募集フォーム等のリンクを共有するためのチャンネルで、もし主催が急に失踪しても他の人が主催を引き継げるようになっています。もちろん限界はありますが、不測の事態に備えて誰かが引継げるシステムを作っておく(属人性を低くする)と、企画の強度をあげることができます。
concerto_700_1.pngこちらは同じく700字文体シャッフル企画、第一回特別回の企画書です。別所のボイスチャットでRuka_Naruse Ruka_Naruse 氏と一緒にSuamaX SuamaX 氏にご協力をお願いし、企画の開始に至りました。
他の運営に「面白そう!」と思ってもらうことをメインにしつつ、大枠の期間設定と喫緊のタスクの締め切りが設定されています。
元々k-calがメインで進行を務めようと考えていたのですが、この直後私生活が忙しくなり、一緒に企画の立ち上げをしてくださったRuka_Naruse Ruka_Naruse 氏にメインの進行を代わっていただきました(本当にありがとうございました)。代わっていただいた身で言うのもおかしな話かもしれませんが、主催も含む参加者は、自分の仕事が全うできなくなりそうになる可能性が出た時点で他の人に引継ぎをお願いするか、(自分が失踪しても)いつでも引き継げる体制を整えておくことが重要だと思います。ギリギリまで引っ張って突然動けなくなると、多くの人に迷惑が掛かりますから。
その後、私は著者の方々との連絡役を担当したのですが、依頼した原稿の提出状況などは逐一報告していましたし、私が連絡を忘れているとRuka_Naruse Ruka_Naruse 氏がリマインドをかけてくださいました。おかげさまで準備はとてもスムーズに進み、とにかく進捗の共有が重要であることを実感しました。
合計9万文字を越えるEP.01 新宿バイドアンドシークの共著は、最近k-calが経験した中で最も期間の長かったプロジェクトです。
元々はmeshiochislash does not match any existing user name氏、islandsmaster islandsmaster 氏、dr_kasugai does not match any existing user name氏の共著プロジェクトだったのですが、エンディングの構想にほれ込み、無理を言って参加させていただきました。
共著で一作を作り上げる場合の王道は、群像劇的にするか、資料の羅列のようにしてそれぞれの資料を担当するか、出されたアイデアをメインライターが一人でまとめあげるかです。こういった形式はそれぞれの役割が明確で、それぞれの部分が比較的独立しているので、一貫したテーマとおおざっぱな流れさえ決めてしまえば、タスクの割り振りが比較的容易でかつ他の人の変更の影響をあまり受けません。各メンバーがある程度好きにやれるので、事前にあまり細かいプロットをたてる必要がないのです。
一方で、これらに当てはまらない通常の一話を共著で作り上げるのは、かなり大変な作業です。このプロジェクトの場合、大枠の進行は「概要作成」→「プロット作成」→「ファーストライターによる執筆」→「リライターによるリライト」→「全ライターによる確認とリライト」となりました。
概要作成はやりたいことや大体のオチ、テーマ、主人公、設定などを決める作業で、こちらは私が参入した時点でほぼ終わっていました。問題はプロット作成です。
先にファーストライターによる執筆についてお話すると、これは割り振られた章を複数のファーストライターたちが分担して執筆し、原案を仕上げる作業です。つまり、これらが始まる前に「物語の全体像を作成して、それをさらに分担できる形に区切る」という作業を済ませておく必要があります。それが「プロット作成」でやるべきことです。
実際に作成したプロットの序盤が下の「大枠のプロット」です。
大枠のプロット
1. 少女が落ちてくる。
2. 少女が目を覚まして、スーツを直したいという。そのためには上層の機械屋にいかなければ。
3. 上層へ向かう途中の道。(主人公の父親への想いとか話す)テントで休んでいると、襲撃され、逃げ出す。どれだけ逃げても奴らは追ってくる。
3-1. スーツのパワーで──[略]。
3-2. 時間稼ぎの目的は──[略]。
......
[以下省略]
このように、シーンや章レベルで展開を書き出し、それぞれに番号を振っていきます。そうして、「○しろまる○しろまるさんは〜日までに02, 03を書き上げてください」といった感じで、前の方からシーンを割り当てていきます。一旦全員にある程度タスクが行きわたったら、書いているうちに変更点が出る可能性があるので、残りはまだ割り当てないで様子を見ます。
この作業の辛いところは、一人で、かつ高速で済ませなければいけないということです。このプロット作成は矛盾を防ぐために(あとから意見は貰うとして)一人でこなす必要がありますし、何よりこの作業が終わらないと他のメンバーにタスクを割り振ることができません。あまりもたつくと、企画が完全停止してメンバーの気が離れて行ってしまいます。これは通常の企画でいう企画概要を作る段階にも似ているので、可能ならメンバーを集める段階ですでに大枠のプロットがあると話が進みやすいかもしれません。
さて、プロットを割り振ったのなら、そこでプロッターの仕事は終了でしょうか? そんなわけはありません。実際にも起こった問題ですが、「書くことはわかったけど全然流れが思いつかない」という声がメンバーから上がることがあります。その場合、そのシーンをさらに細分化した具体化されたプロットをプロッターが提案したり、担当者と一緒に作り上げることになるでしょう。実例は以下のようになります。
具体化されたプロット
※(注記) ネタバレ防止のため要素を置き換えています。
【07の展開案】
1 06終了後、コンクリートで舗装された道を進む二人。
- なぜここだけ舗装されているのか? この道の説明をする。
- 「この地域の地面の下には槍が埋まってて......」伏線となる槍の説明をする
2 ひとつ前の拠点に戻ってくる
- なんでわざわざ帰ってきたんだ!と憤慨する主人公
- ペットの猫が登場。とても強い。
- 猫について協力者が解説。この世界の猫は強くて、でかくて、美味しい。こいつが居れば敵に勝てる。
- 地図とか持ってないか? → 地図はないけど、さっき拾った変な文書があるよ(読めないけど) → 協力者が読むと、道が出てきた。
3 仲間を助けるため出発
- 走りながら探していると足音が。物陰に隠れる。
- 敵が歩いているのを発見。こちらには気付いていない。
- 「俺は膝が弱くてな」(この発言大事)
- 攫われた仲間が担がれている!
- 協力者から敵の説明。あいつらは戦場帰りの傭兵だ。
- 助けなければいけないが、武器もない。協力者は方法を思いつかない。
- ひそひそ会話。伏線「穴でも掘って近づけないかな」「スコップならあるけど」
4 作戦実行
- 仲間が殺されそうになる。協力者は土のついたスコップをもって敵の前に飛び出す
- 「穴でも掘って近づこうとしたのか?」「あほが」
- 協力者は追い詰められる。スコップでぶったたくが全く効かない。緊張感がマックスに。
- その瞬間、後ろから槍が飛んでくる。スコップで穴を掘って、埋っている槍を掘り出したのだ!
- 敵を倒して、仲間を救出、
- みんなで拠点に戻る。
いかがでしょう。かなり具体化されたような気がします。その後結局「そのシーンでキャラ同士の関係や感情、思惑がどのように変化しているのか」という点も追記することになったので、最初からそれらも含めて具体化すればかなり書きやすくなるのではなると思われます。これが通常の企画における「タスクの具体化」であり、「タスクをイメージしやすくする」作業です。
このようにしてファーストライターがガリガリと書き上げていく後ろから、リライターが追っていきます。リライターの役目は全体の文章校正をし、全体的な目線から話に統一感を持たせることです。リライターがいるので、ファーストライターは細かいことで悩まず、多少汚い文でもゴリゴリに筆を進めることが推奨されます。
この追いかけっこを続けていると、最終的にはファーストライターたちが先にゴールすることになります。ゴールしたファーストライターはそこで仕事終了ということにはならず、本文の見直し、荒削りな文章を事前に修正してリライターの負担を下げる、リライターによる変更の影響を後ろのシーンで反映する、次話の構想を作成する、などの仕事を行っていました。
そうしてときおりプロットの修正を入れながら最後までリライトが終わったら、最後に全てのライターが確認や伏線の修正、小規模なリライト等をして、作品は完成です。
口でいうのは簡単ですが、実際にその道のりはかなり厳しいものになりました。長編なので時間がかかり、さらにメンバーが途中で多忙になってしまったために完成予定日を何度も後ろにずらしました。
こういったときほどマネージャーは気合を入れる必要があります。
まず、完成予定日を過ぎてしまったときは、なるべく次の完成予定日を設定するようにしていました。「完成予定日を決めずにゆっくりやろう」とすると、ずるずると進捗がないまま進んでしまう恐れがあるからです。
次に、メンバーの作業日の把握やリマインド、進捗管理などをしっかり行うことを心掛けました。また進捗はすぐに全員が見れるページに反映してもらうようにし、常に進捗の実態を把握するよう努めました。
締め切りの設定についても意識を尖らせ、次のタスクに移行するときや締め切りをオーバーしてしまったときは、すぐに次の締め切りを自己申告してもらいました。
最終的な進捗確認の頻度は、なんと(もちろん合意のうえで)二日に一度です。仮に進捗がなくとも、進捗がないことがわかることと、連絡を維持することに価値がありました。
そんなこんなを経て、メンバーの多大な協力のおかげで、なんとかこの長編を書き上げることに成功しました。全員でかなりの努力をしたこともあり、投稿したときの嬉しさたるや凄まじいものでした。今でも思い出に残るお気に入りの一作です。
以下はこのようなマネジメント業務で使用した文章の実例です。共有を許可してくれた寛大なメンバーに、このの場を借りて感謝申し上げます。
遅刻の常態化を防ぐためのお願い
05までの進捗確認しました。結構いい流れでできていると思います。ありがとうございます。
進捗に関しては、色々予定があるのは仕方ないですし、趣味の範疇なので進められないとかは全然大丈夫です! こういう趣味なので進捗が遅れるのもそういうもんだと思っています。
その代わり、進捗の予定が遅れそうなときは事前に共有していただけると、こちらも協力できるので共著者としてありがたいです!
共著メンバー全体としては、共著はチームプレーなので、今ここまで進みました〜というような進捗の共有もなるだけ積極的にやっていきましょう。俺の方もなるべく進捗を共有できるようにこまめな報告はしていきます。
ちなみに俺は明日までのタスクが山積しているので明日の昼まで動けません
忙しいメンバーの作業可能日の確認
今月の現実的な稼働はどのような感じになりそうですか?(毎日少しずつ or 休日のみ 等)
稼働日が限られるのであれば、稼働日の終わり〜翌日に進捗確認をしようと思います。
連絡が途絶えたメンバーへの応答要請
ご覧になりましたら返信だけでもよろしくお願いします。いつまでに回答・対応できるかの明示があれば最高ですが、「見ました」や「うんち」だけでも大丈夫です(ただし、うんちの場合はTwitterに晒します)。
SCP関連イベントで頒布された合同誌「りょかんのごはん」。Dr_Kudoは共同主催(マネージャー)としてこの企画の運営に携わりました。この画像はその企画用サーバーのチャンネル構成です。比較的このエッセイで書かれていることを実現した構成になっているのではないでしょうか。
"#アナウンス"チャンネルでは体裁などの重要な情報の共有のほか、タスクの期日やリマインドなどが行われていました。"#一般" や "#缶詰" は分報あるいは進捗報告、アイデア投下の場として活躍しました。
寄稿型の企画でしたので、基本的に一般メンバーの仕事は原稿を書くことに限られていました。したがって、全体を集めての会議は開かれていませんし、会議や議事録のためのチャンネルもありません。会議がないことによるメンバー同士の交流の過疎化については、元々別サーバーで交流していたメンバーを集めた企画ということもあり、あまり問題になりませんでした。もちろん、企画側でもこまめなリマインドをすることによって、企画が忘れ去られてしまわないようにしていました。
メンバー全体を集めての会議がない一方で、共同主催(オーナー)のshionome4ono shionome4ono 氏とは密に連絡を取りあっていました。氏はどんなときでも基本的に一日以内には連絡を返してくださったのですが、これが企画をスムーズに進行する上で非常に助かったポイントでした。
他に特に意識していた点としては、最初の段階からスケジュールをしっかりと決めるということです。下の例のように、企画開始時からメンバー向けに予定を共有していました。
当初示した予定
1/18: サークル参加申し込み
1/22: 参加者皆様のサーバーへの招待
1/22 〜 2/5: プロット執筆依頼&順次提出依頼(イラストも可)
1/25 〜 1/29: 表紙の作品募集
1/30 〜 1/31: 表紙候補作品への投票と決定
2/1: 表紙の発注 & プロットどうですか(進捗確認)一回目
2/12: プロット&ラフ締め切り
2/15: 見積もりと印刷所決定
2/28: 原稿どうですか(進捗確認)一回目
3/14: 原稿どうですか(進捗確認)二回目
3/21: 原稿どうですか(進捗確認)ファイナル
3/31: 入稿
これによってメンバー全体としてスピード感や進捗の度合いを共有しながら企画を進めることができたと考えています。
もう一点が「二段階制」という方法です。特に原稿など、重いタスクを消化しなければいけないときは、全てをポンと任せてしまうとどうしても最初の一歩が重く踏み出せないという問題が起こりがちです。そこで、本企画では原稿作成というタスクを「プロット作成」「本文作成」という二つのタスクに分割し、前者の提出を企画参加の要件としていました。
「プロット作成」だけであればまだ取り組みやすいでしょうし、なにより企画に参加するための条件としたことが強烈な後押しになりました。またプロットさえ作成していれば「本文作成」の足掛かりになって、作業にとり取り組みやすくなるはずです。実際この方法のおかげか、脱落者は一人も出ませんでした。
寄稿型以外では最初にメンバーを確定する都合上、参加要件とするのは難しいと思いますが、最初の足掛かりとなる部分を別タスクに分割するのはどの形態でも応用できるテクニックなのではないかと思います。
参加者目線でのコメント(k-cal)
まず初めにプロットを提出することになっていたのですが、企画開始と同時にその実例が公開されていたことにかなり助けられました。おかげさまで完成形のイメージを掴むことができ、難しいことを考えずに作業ができました。
また、主催側のリマインドの仕方が非常によく、ストレスなく製作に取り組むことができました。
例えば、「確認いただいた皆様、ありがとうございます!まだの方、私も明日やります。一緒に頑張りましょう〜」であったり、「実質明日明後日が変更の最後の機会です。悔いの残らないよう、いい本を出しましょう」のように、単に無味乾燥なリマインドをするのでなく、こちらを優しく鼓舞してくれるような言葉遣いのおかげで、企画へのやる気が出た部分もあると思います。一度締め切りを過ぎてしまったこともあるのですが、その際も「上記、念のためご対応願います」と丁寧な言葉遣いで対応していただきました。
個人的には正直何人か脱落者が出ると思っていたのですが、全員で完走できたのはこういった細かな気遣いのおかげである部分も大きかったのではないかと思います。
企画始動時のメッセージ
皆さん集まりましたね。
今回はご協力ありがとうございます。主催のケーカルです。
企画の概要と今後のフローと作業内容については、 # 企画概要 に掲載しますので、ご確認ください。タスクについては、早速アイデア出しから作業を開始していただきたいと思います。
作業についてイメージしにくい点、日程的に厳しい点があれば、遠慮なく申し付けください。日程はかなりタイトに設定しているので、場合によっては若干後ろ倒しにすることもできます。
それでは、改めてこれからよろしくお願いします。良いエッセイを作りましょう!
※(注記) なお生活リズムの関係で、夜間でもバンバンメンションが飛ぶ可能性があります。通知等はご自身で調整をお願いします。
※(注記) 大体二日に一度はメッセージを確認していただけるという前提で動きます。
※(注記) 締め切りに間に合わない等あれば、事前にご報告をお願いします。
※(注記) メンション付きメッセージを読んだ場合は、ご返信かリアクションをお願いします。
企画書
【企画概要】
企画概要: チームプレイについてのエッセイを共著しよう!
エッセイの目的: チームコンが近いので、チームプレイの際に役立つ情報、特に「マネジメント」についてアドバイスを提供すること。
エッセイの対象: チームマネジメント経験がないサイトメンバー。(+ 新人サイトスタッフ、新人お祭り運営)
参加者: ケーカル(主筆・計画), Dr_Kudo, Jiraku_mogana, ukwhatn
【タスクフロー】
アイデア出し1: 〜10/16(月)
- みなさんにエッセイに盛り込みたいアイデアを提出していただきます。
草案確認、アイデア出し2: 〜10/23(月)
- 頂いたアイデアを基にケーカルが草案を執筆しながら、皆さんには不足部分やアディショナルな部分のアイデア出しをお願いします。
- こちらから欲しい情報について質問するほか、草案を確認していただいたうえで、足りないところ、さらに盛り込んだ方がよい情報等があれば指摘をしていただくという形になります。
第二草案作成と確認: 〜11月初頭
- アイデア出し2で頂いたアイデアを基に、ケーカルが最終草案の作成を行い、そちらの確認をお願いします。
完成と査読提出の目安: 11月初頭
- 査読通過後は四名による共著として投稿します。投稿作業等はケーカルが行います。
【アイデア出しについて】
基本的には、みなさんに出して頂いたアイデアに肉付けをする形でケーカルが全体を構成します。したがって、アイデアを提供していただく際は、「これさえ言っとけばケーカルはわかるだろう」くらいの大雑把さ・ラフさで提供いただければと思います。
例としてですが、アイデアは以下のような感じで作成をお願いします。あくまで一例なので、書きやすい形で書いていただければ問題ありません。情報の量がこれ以上増える分には大変ありがたいです。
<例1: やるべきことと理由>
○しろまる 怖気づかずに、反応が欲しい場合は個人にメンションを飛ばす。
理由: 全体にメンションを飛ばしても誰も反応してくれないから
<例2: 達成すべきこと(抽象的な目標)と達成するための手法、理由>
○しろまる 常に交流を絶やさないようにして、離しやすい環境を作る
手法1: 一週間に一度など、定期的にミーティングを行う。無理に作業のことを話さなくてもよい。ゲームとかしたらいいと思う。
手法2: こまめに進捗確認やリマインドを行う。
理由: 創作者はすぐに一人で悩んだ挙句、どん詰まって憂鬱になり、結果も出せないことがあるから。
思いついたものから #アイデア共有 にポンポン投げて頂いても大丈夫ですし、期日にボンッと一覧にして投げて頂いても構いません。また、他の方のアイデアに付け足したいことや補足があれば、そちらもどんどん共有をお願いします。
いただいたアイデアに対してケーカルが質問をすることもあると思います。その際はご対応をよろしくお願いします。
この項目については是非自分で執筆したいという場合はお声がけください。全体の構成を見ながら執筆をお願いすることになると思います。
また、有用な資料やツール、ケーカルの執筆の際に参考になりそうなものについては 資料置き場 に是非共有をお願いします。
【こんな話題があると嬉しいです】
- 企画を始動する前に気を付けておくべきこと。
- 企画進行中に気を付けるべきこと。
- ありがちなインシデントとその対処法
- メンタルマネジメントで重要なこと
- とにかく伝えたいこと
- 胸に刻んでおくべきこと
- おすすめのツール、ハウツー等......
- チームプレイ歴戦の素晴らしいメンバーに恵まれた
- メンバーが尋常じゃなく多忙であった
- 始動から一か月程度で企画を完遂する必要があった
本企画は以上の点で特殊な企画となりました。この条件下で走り切るために、なるべくメンバーのコストを下げたうえで最大の効果を得ることを意識しています。
まず企画書が、多忙なメンバーがスムーズにタスクに取り掛かれるよう、シンプルさとタスクのイメージしやすさを意識したつくりになっています。具体例や話題の指定をすることで、アイデア考案のコスト低減を目指しました。
一方で、チームプレイにおける基本的な注意事項は省略しています。特に第四章に関わるようなことはほぼ事前に認識のすり合わせを行っていませんでした。これはメンバーの経験を考えると基本事項を改めて説明する必要が薄かったことと、企画が短期間で行われること、形式的に問題が起きにくかったことが理由です。
最も特徴的なのは定期会議の場が設けられていないことかもしれません。これは企画が短期間で完走する前提であったのと、フロー的に会議をして決めることがほとんどないと予想されたこと、外圧を高めなくとも各メンバーがタスクをこなしてくれそうだったことが理由です。
これはあくまで特殊な例であり、基本的な注意事項の認識すり合わせと定期会議を省略することは大きなリスクを伴うので、通常の企画で同じように省略することは絶対におすすめできません(私も普段は省略しません)。また、今一人寂しくこの文を書きながら、分報用の進捗報告チャンネルを設けておけばよかったな、と反省しています。
総じていえば、有能なメンバーのおかげで、主催はかなり楽をさせていただきました。Dr_Kudo Dr_Kudo 氏、Jiraku_Mogana Jiraku_Mogana 氏、ukwhatn ukwhatn 氏へ、本企画へのご参加とご協力、本当にありがとうございました!
しかしあなたがリーダーであるのなら、相当な勝算がない限りこのようなラッキーに頼るべきではありません。仮に「無からみんなでつくる」という体でメンバーを集める場合でも、誰もアイデアがない場合に備えて、あなたのやりたい企画の概要は考えておくべきです。