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