アンサンブルのリーダーをやってみて、プロジェクトリーダーと同じような感じがした話
某所で「オーケストラとプロジェクト運営は実はそっくり」という話があり、なんとなくアンサンブルのリーダーをやってみたときに「あ、なんかプロジェクトリーダーの仕事となんかそっくり」と感じたことを思い出したので、少し備忘録も兼ねて「こんな感じで運営するといいぞ」という感じで、書いてみます。
アンサンブルのリーダーになった！
2023年の1月に開催された、Arc-hive Philharmonic Winds 1st Concert -The Beginning of the Adventure-にて、アンサンブルのメンバーに選出され、いろいろあってリーダーを務めることになりました。というか、気がついたらなってました。
アンサンブルの内容は『わるい王様とりっぱな勇者』より、「日常メドレー」「おうちにかえろうメドレー」でした。
実はアンサンブルのリーダーは明確には決まっておらず、顔合わせのときに「自分がスケジュールを取りまとめるスケジューラを作ります」ということを言って、とりまとめを始めていたのですが、そこから「なんか流れで」という感じで、リーダーになることになりました。
まずはスケジュールの管理
プロジェクトリーダーの仕事の話になりますが、プロジェクトリーダーとしての仕事はまず、スケジュールの管理から始まります。（最初の要件定義の段階では管下メンバがいなくて自分だけとかはありますけどね）リリース日から逆算して、スケジュールを策定します。
それを考えると、スケジュールの管理にまず手を出した以上、あんたがリーダーやということになるのは必然･･･ということになります。
プロジェクトリーダーのようにまずスケジュールを策定すること･･･になりますが、プロジェクトとは違う部分もあり、要件定義が「本番の日にアンサンブルを演奏し成功させること」であり、外部設計が「アンサンブルステージの構成」内部設計が「譜面」であるならば後述しますがとりあえずそれは既にありました。だが「練習しないとはじまらねぇ」というのがあります。
ただ本番までの日程を逆算すると「やっべぇ」ということに気づいたので、とりあえずはDiscordを使用し、全員に「全体練習は何回しましょうか」というアンケートをとることにしました。
3回、という意見が圧倒的に多く、本番の日から逆算したスケジュールを鑑みるとそれがいい（というかそれが現実的）ということになり、まずは「伝助」を使用して、メンバーの集まれる日を策定しました。
個人練習の期間があまり取れていませんでしたがとりあえずは初回練習を企画することにしました。また、この時期にマイルストンを立てて大体のざっくり予定（いつまでに何をやる）などを策定していました。
プロジェクトでもありますが「本番リリースがここ」「本番の前の資源凍結段階がここ」などのマイルストンがそっくりそのまま「演奏会本番はここ」「ゲネプロはここ」「合宿はここ」などになりますので、それに当てはめるとスケジュールを引くことができ･･･と考えていくとだんだん「仕事っぽくなってるなあ」という自覚が出てきました。まあ演奏会本番の日までずっとこの感じだったんですけど。
開発手法に当てはめてみると？
開発手法にはウォーターフォール開発、アジャイル開発なんてのがありますけど、アンサンブルにおいてはどちらかというとウォーターフォール開発的、なところがあると思います。
ウォーターフォール開発の図だと、みんな見たことがあるこんなのがあるんですけど
この図に当てはめると、こんな感じになっていくと思います。
①要件定義･･･「本番の日にアンサンブルを成功させること」
②外部設計･･･アンサンブルステージの構成
③内部設計･･･譜面作成（または購入）
④プログラム開発・単体テスト･･･譜面の個人練習
⑤統合テスト･･･アンサンブル練習、合奏
⑥運用テスト･･･全体リハーサル内での合奏
⑦リリース･･･演奏会本番！
ただし、この図の中での①～③までは運営や編曲者が担当していた領域で、かつ既に成果物は完成しており、我々としては④～⑦までがんばりましょう、というようなプロジェクトになっていました。
ウォーターフォール開発のメリットとしては「プロジェクトの進捗管理がしやすい」というのがあり、また成果物が揃っている状態で次の工程には進めるので、わかりやすいという利点があります。なので、アンサンブルにおいては、ウォーターフォール開発的な手法で、プロジェクトを管理していくといいですね。
チームモチベーションマネジメントや、意見の吸い上げなど
メンバーのモチベーションはとても高く、正直なところモチベーションマネジメント的なことについては、なにひとつしていませんでした。
ゲームが題材のアンサンブルでしたので、ゲームを実際にプレイしてみるメンバーも多く、曲の理解を深めていただけました。
プロジェクトリーダーだとチームモチベーションマネジメントが必要になるというのは研修で学んだことがありますが、正直、ここに関しては何もしていません。基本的に「やりたいと思う人が集まる」のがアンサンブルだったり合奏だったりするので、基本的にモチベーションはそもそも高いのでここは考えなくてもいいかもしれません。
ただ、管下メンバからの意見の吸い上げですとか、そういったところは必要だと思っていたので、全体連絡やアンケートはDiscordのチャンネル機能を使用し、一部メンバーとはDiscordのDM機能を使用して意見をヒアリングすることもありました。
演奏家としてのスペシャリストもメンバーの中におり、自分はアンサンブルの経験が、結婚式の二次会で一回やったくらい（しかもお酒を飲みながらだ！）しかなかったので、このへんはプロジェクトだと現場の意見的なものになるのでしょうか、結構いろいろ聞かせていただいたのを覚えています。
ただ、「期間が少し少なかった」という理由もあり、あまり意見の吸い上げがおろそかになってしまっていて、若干決め打ちするしか無い、もしかしたら独裁的と捉えられるようなところもあったかもしれません。そこは反省しています。
ステークホルダは誰になるか
システムはユーザが使用してこそのものになりますが、ステークホルダも基本的に存在します。このアンサンブルでもそれは例外ではないんじゃないかなと思っていました。
この場合、演奏を聞いていただけるお客さんがユーザではあるとは当てはめられますけど、利害関係者はさて誰になるかと思うと、まあなんかある程度、かっちりとしたものではないですけど、そんな意味合いにある意味なるのかなと思ったのが主催であり運営であり事務局になるのかな、とは思っていました。ちょうど、アンサンブルを担当してくれたのが主催にもなるので、どちらかというとステークホルダではなくプロジェクトマネージャー、という感じだったのかもしれませんけど。
まあ利害関係者、みたいなかっちりしたものはあんまり無かったといえば無かったのですが、もちろん「演奏を成功させること」という利害が存在していて、もちろん失敗したら損害にな･･･るのかどうかはわかりませんが（仮にプロだと演奏ですごい大事故を起こしたら金返せとかになる･･･のかなぁー･･･）少なくとも成功したらこれが利益に当てはめられる、と思います。
もっと言うと、主催や運営だけではなくアークハイブの場合は「顧問」がいますし、「指揮者」ですとか「編曲者」ですとか、更に広義的なステークホルダですと「わるい王様とりっぱな勇者」の販売元である日本一ソフトウェアもなり得ます。
まあ直接的なステークホルダとしてはこれだけいますけど、基本的に「主催の利害と一致している」ので、ステークホルダとして整理するとこれだけいるんだぞ、というのは、あまり意識してはいませんでした。
スケジュールを立てたら進捗管理
進捗どうですか！進捗どうですか！
以上！
冗談ですが、スケジュールを立てたらとりあえず進捗管理をすることが必要ですが、演奏についても「人前で演奏できるレベルになる」までの進捗管理が必要で、ここに至るまでには個人練習のことは置いとくと「演奏が止まらないで通しでできる」からはじまり、最終的にそこまで持っていくのですが、これも前述した「マイルストンに応じてこのくらいだな」という管理が必要になり、若干遅れ気味だったので「練習を追加する」などしてなんとか間に合わせた、というところがありました。
まあなんかプロジェクトの進捗を取り戻すための手法で、クラッシングとかファストトラッキングとかIPAの情報処理試験かなんかのときに覚えた記憶がありますけど、プロジェクトの場合は人員追加すればまあいいんでしょうけどアンサンブルの場合は人員追加は不可能なので、基本的に練習追加くらいしか方法ないですよねとは思うんですけど。
トラブルを解決する！
トラブルが無かったわけではなく、詳しくは言わないほうがいいと思うので言いませんが「ほかのアンサンブルチームを巻き込んだ、アンサンブルステージ全体に関わる、解決すべき問題」というものが発生していました。ほかのチームのリーダーと話していて発覚したのですが、ほかのチームを巻き込んでいて自分のチームだけの問題ではないこともあり、仕方がないので、上の人を巻き込んで解決に向かわせることにしました。困ったことは上司に振れ、あると思います。
リーダーをしているうえで困りごとなんかがあれば、上の人にとりあえず振ってしまうと良いんじゃないかなぁとは思います。（もちろん、ちゃんとアンテナを張って困りごとに気づくことも必要なのですけどね）
あと、「アンサンブルメンバーが同時に二人コロナになった」というのがありました。まあそのうち一人が自分なんですけど。
別に練習の中でクラスタが発生したわけでもなく、偶然同時期にコロナになっただけではあったんですけど、症状が出るか出ないかは置いておいても、いずれにせよ当時は２週間ぐらいの隔離が必要だったので、貴重な3回設定した練習に1回出られなくなってしまうので、これはちょっと困りました。（まあ練習は増やしたんですけど。）
またコロナについては「本番の期間にかかるなかで誰かがコロナになってしまったらどうしよう」と悩むことがあり、かつこればっかりは（感染対策を個々人がしっかりしていたとしても）最終的に祈るしかできることはないため、隔離期間として設定されるであろう本番2週間前から演奏会本番の日まで「誰かからそういう体調不良的な連絡が来てしまわないか」をとても怖く感じており、特にDiscordのDMで連絡が来るであろうと想定していたため、Discordの「ﾎﾟｺｯ」みたいな通知音が鳴るたびに恐怖を感じていたのを覚えています。
なんとか大成功、総括してみて
その後、マイルストンとしてざっくりと以下を設定していましたが、なんとか進捗に追いつくことができ、本番を迎えることができました。
①合宿での練習 ･･･ 若干の遅れ気味はあるものの達成
②ゲネプロでのお披露目 ･･･ 練習を行ったこともあり、達成
③演奏会本番 ･･･ 大成功！
まあ本番当日にトラブルがなかったわけでもないんですけど（練習場所の楽屋が消滅してたとかね）、そういう細かいトラブルをなんとか乗り越えられたのもアンサンブルメンバー全員の尽力あってこそ、であったと思っています。
感想をずっとTwitterでエゴサしてたんですけど、とても良い感想が多く、エゴサが捗ったのを覚えています。
アンサンブルのリーダーをやってみて、「だんだんプロジェクトリーダーの仕事っぽくなっていってた」というのはそうですし、「仕事でやっていたことが役に立っている」実感も結構ありました。仕事でもプロジェクトリーダーだったりプロジェクトメンバーだったりしたこともありましたが、そのときの経験が生きた部分はすごくあったと思っています。
非エンジニアだとわけのわからないところだとは思いますけど、アンサンブルやオケの演奏会なんかのリーダーを務める際は、プロジェクトのライフサイクルだったりとかを意識してスケジューリングをして、開発手法に当てはめてみたりしてもいいのかもしれません。
まああと「めっちゃたいへん」だったので、こういうことやるひとは気をつけましょう（覚悟しましょう）
この記事が気に入ったらサポートをしてみませんか？