前々から書き溜めていた内容で、
ブログを書いてみます。
今のプロジェクトを通じて、
進行ディレクターとして沢山の経験をさせてもらいました。
このブログで下記に書いているのは、
自分が痛い目にあって学んだり、
信頼する先輩やメンバーに気付かせて貰ったりした内容です。
自分自身、全部が全部出来ているわけではないですが、より血肉化できればいいな、と思って書きました。
文量が多いので、たぶん読んで下さってる方も、途中で挫折するかも。。
（複数日にわたってちょこちょこ書いたので、トンマナのズレはすいませんごめんなさい）
---------------------------
■いまは何のフェーズなのかを、明確に。何度も伝える。
いまチームは何を目指していて、
それが終わると、次は何が待っているのか。
それがチームに伝わっていないと、
いくら良い計画を立てていても、メンバーが不安になってしまいます。
同じ話の内容でもいいので、何度も伝える。
■色々あるけど、まず理想で考える。
チーム開発をしていると、いろいろな「都合」が出てきます。
「実現するのが難しい」とか、
「先にやらないといけないことがある」とか。
それに直面した際に、「色々あるけど、本当は〇〇になると良いよね。どうすればできるかな。」と話すことができれば、
チームの進む道が変わってくると思ってます
■違和感があれば、全てをテーブルに並べる。
沢山の関係者と、１つのサービスを作っているので、「物事が、なんかうまく進んでないな。。」と、思うタイミングが稀にきます。
その際に、「おれはこの辺りを課題だと思ってる。」と
思っていることをストレートに伝えることが大切だと思います。
周りはみんな、
「良いものを作りたい」という気持ちをもった仲間なので、
よく話すことが重要だなあ、とよく感じます。
■メンバーの「やりたい」は、出来るだけ優先させる。
いかに楽しそうにメンバーが作るか、は
サービスのクオリティに物凄く直結すると思います。
メンバーが能動的にやりたい、と言ったことは、できるだけ任せたい、と思うし、
多少の優先度だったら変更すべきだと思います。
「こっちとこっち、どっちからやりたい？」と提案して、
自分から選んでもらうのも、結構大切だったり。
■言ったからには、の責任を持ってもらう。
とはいえ、やると言ったからには、
絶対に成し遂げてもらわないと困るし、
それをサポートするのが、
この仕事の重要なことの１つだと思ってます。
■仮素材でも良いから、まずは全ての素材を揃える。
作り方の話。
仕様の全容を把握したら、
まずは「不足している素材を無くす」こと、に注力する。
仮でもダミーでもいいから、
仕様要件を満たした素材を全て揃える。
物が揃ってから発覚することが、本当に多いので、
そのリスクを少しでも早く無くすこと。
■無いものから作る、が最優先事項。
既存の素材のブラッシュアップよりも、
まずは無いものを作ること。
理由は↑で書いた通りですが、
その雰囲気というか、
スタイルをチームに浸透させることが、
チームのスピード感をあげると思います。
■最終工程まで１個でも良いから、作ってみて全容を出す。
無いものから作る、に近いですが、
最終工程まで、１個でも良いから、まず作ってみる。
制作対象が量産物だったりした場合、
その過程で、「連絡フローが不明確」とか、
詰めるべき点がほぼ必ず出てきます。
最終工程の定義は、テスト完了まで。
「デバッグコマンドがあるのとないのでは、
作業工数が全然違う」とか色々出てくるので。
■まだ見ぬ、開けるのが怖い「蓋」がないか。
社内でよく言う「蓋」について。
蓋とは、「全容がまだみえていないもの」だったり、
「なんとなくふわっとさせてしまって、今後問題になりそうなもの」
のことを指してます。
スケジュールに影響することが多いので、
「蓋開け」は、勇気と覚悟がいる作業なのですが、
この「蓋」が無いことがチームにとっては重要です。
スケジュールを意識しすぎると、
自ら「蓋」を作ろうとしてしまったり。。。
やることが可視化されている状態を作れるようにする。
■言葉の定義をはっきりする。完成とは。納品とは。
2Dイラストの「納品」、という言葉ひとつにしても、
「イラストはあるが、未書出しの状態」だったり、
「書き出されているけど、Gitに上がってない状態」だったり。
チーム内で
・うちでいう「〇〇」の定義とは
の認識と精度を合わせていくことが重要だと思います。
■進行管理が根性頼りになり続けると、メンバーが疲弊する。
絶対にスケジュール遅らせたくないじゃないですか。
でも品質も落としたくない。
なんとかする方法を考える。
それでも難しければ、
再設計をすることも勇気ある判断だと思います。
〇〇日までに、どうこうできなかったら、
再設計しよう、と決めて動くこと。
ただし、ラストの追い込みとかは話が別。
もう全力で走るだけ。
■自分よりデキる人に、助けてもらう。
周りに経験者がいたり、
信頼できる人が助けてくれている、という事実だけでも
だいぶ楽になります。
自分には、
定期的にスケジュールをチェックしてくれる人もいれば、
一緒に管理してくれているできる人もいるので、
だいぶ恵まれているな、と思ってます。
■多額のお金が出ていく話は、第三者にアドバイスを貰う。
足元の問題を解決することに躍起になって、
冷静な判断が出来ていない場合があります。
支払うお金は１円でも安い方がいいので、
目的を果たすために、自分のコストのかけ方は妥当か、を
知見ある人に相談してから、実施可否を判断する。
■全体感を失わない。
メンバーの人数が一定(20人とか）を越えると、
１人で全てを管理しようとしても、徐々に回らなくなります。
ガントをひくだけだったら、30人とかが対象でもできます。
ただ現実ガントは引いているだけではなく、
必ず問題が起きて、その対応に追われ始めます。
そうなると、足元の一部の問題しか分からなくなり、
全体感を失い始めます。
これが前半期の一番の失敗でした。。
チームの人数が増えてきたら、
「問題の解決ができる人」をチームに迎える。
もしくは元々いてくれたメンバーが管理側に回るなどして、
自分が全体感を失わない体制をつくること、が
重要だと今では心底思います。
■どういう状態になったら人を増減するのか、を決めておく。
↑の話にも通じるのですが、
メンバーの数は多すぎても少なすぎてもダメで、
「適切な人数と役割分担ができているか」が重要だと思います。
少ないことが美学、になりすぎず、
一方で、人を増やすなら、
それ相応のメリットを分かりやすく明示することが大事。
■責任者を明確にする。
「〇〇に関しては、▲▲さんが責任者なので」
とチーム全体に分かりやすく伝えること。
責任者の方もやる気になって頑張ってくれるし、
今までの経験で、チーム内でよく議題になるのは、
「だれが決定者なんだ」というあるある話。
■期日付きの判断ポイントをもっておく。
何時までにこうなっていなかったら、どうする。
何日に〇〇の効果が出たら、進める。
そのキメが甘かったり、
そこに感情が入ってしまうと、計画が崩れてしまう。
■FIXしたレイアウトが無ければ、見積もりはズレて当たり前。
計画が遅れないようにするには、
計画を立てる段階で、
メンバー間の完成イメージを摺合ることが重要だと思います。
僕は、ゴール（完成イメージ）を一番正確に伝えてくれるのは、
デザイナーだと思っています。
デザイナーが
「仕様要件で漏れのないレイアウト」
「未定項目や曖昧な箇所がないレイアウト」
を前もって作れるように計画をしないと、計画はずれてしまう。
■誰よりもチャットツールを隅々までみる。
チャットをよく見ることで、
「のちのち問題になりそうなこと」を事前に潰せたり、
「次のアクションが決まってなさそうなこと」が推進するようにサポート出来たり、良いことがたくさんあります。
自分とあまり関係ない話題でも、
見てるよ感を出すために、軽く反応したりとか。
社内でもトップクラスにチャットみてる自信ある。たぶん。
■良いと思ったことはすぐに褒める。
メンバーが想定以上のクオリティで、モノづくりをしてくれたり、
こっちが求めるよりも早いスピードで物事を進めてくれたりした際は、
すぐにメンバーの所に言って、具体的に褒めるようにしています。
より前向きに仕事に取り組んでくれれば良いな、が第一目的ですが、
チーム内にも「ああ、ああいう所が評価されるんだ」と伝わると良いな、と思って続けてます。
■ペース配分は意識しつつも「スイッチ」は切らせない。
プロジェクトはの進行は、
「マイルストーンに向かって突き進む時期」と「マイルストーンが終わり、少し落ち着く時期」の繰り返しだと思います。
落ち着く際に、一度「落ち着き過ぎ」てしまうと、
再度スイッチを入れる際に、相当なパワーが必要になってしまう。
「次はいつ走り出すのか」を
「落ち着くタイミング」に入る際に、チームへ共有すること。
■メンバーのプライベートを大切にする。
みんな、このプロジェクトを成功しようと思ってくれているメンバーが揃ってくれていますが、
それ以上に、メンバーには大切にしたいものがあるはずです。
（もちろん、成功を第一に考えてくれてるメンバーもいますが）
彼女や家族だったり、人によっては好きなアイドルのライブだったり。
それぞれのメンバーの大切なものを知って、
その上で一緒に仕事を依頼するのかどうか、で
働き方が変わってくると思います。
■邪魔をしない。（いい意味で）
全体を管理すると、色々と細かいことが気になり始めます。
その際に、「あえて口を出さない」というのも重要だと思い始めました。
3Dとか入ってくると、もうその道のベテランがいて、
自分が細かく「じゃあ、次は〇〇をお願いして～」とかやってるとスピードが落ちるんです。
タスクの依頼先が経験豊富な人なら、
「やってほしいこと」と「納期」だけ伝えて、
途中途中で雑談ついでに席に言って、進捗を聞けば良いな、と。
■メンバーの得意と苦手を把握する。
それぞれの個性を把握して、
なるべく「得意」なことしか、しなくていい環境を作ること。
マルチタスクが苦手な人は「１つ」のタスクに集中させること。
■メンバーが、前向きに頑張りたいという理由を作る。
スケジュールの期日だけを伝えると、メンバーは萎えていきます。
なぜ、ここまでにやることが、チームにとって重要なのか。
なぜ、このタスクをあなたに頼んでいるのか。
上記をできる限り、依頼先の相手に伝えること。
■なるべく情報は早く伝える。
なるべくメンバーには、情報を早く正確に共有すること。
そうすることで、メンバーの「当事者意識」が高まっていき、
より強いチームになっていく。
アプリボットから教えて貰って、よかったことをちゃんとやる。
■なるべく大きな声で笑ったり、冗談を言う。
雰囲気が良くなる、と信じてる。
■改善＜＜＜まずは作り切る。
MTGでやることが決まったあと、
いざ作り始めてみると
「あれ、これってもっとこうした方が良くね？」という意見が出てきます。
その際に、「少しの修正ならやっちゃってもいいか。」が頻発すると、計画が崩れ、迷子になっていきます。
まずは、自分たちが一度「イケる」と信じたものを作ること。
その上でダメだったら、ブラッシュアップすること。
まずは作り切ることが大切。
■短期的な損よりも、長期的な利益を取る勇気。
「ベストじゃないけど、しょうがない」が発生した際に、
本当のベストを目指せるかどうか。
例えば、
チームにフィットしていない人に外れてもらうのは、
相当パワーがいる作業で、短期的には損失が出る。
でも、長期的見ると大きなプラスが出るんです。
■全ての問題を自分で解決しようとしない。
新規開発をしてて思うのは、
問題を1人で全てを解決するのは到底無理。ということ。
毎日大量の問題が出てくるので、
自分で全てを解決しようとすると、
確実に自分がボトルネックになります。
そうならないように、
メンバーにも一緒に考えてもらう癖をつくること。
もし、メンバーが全然考えられてなかったら、
「そのくらい自分で考えてよ」と、あえて厳しいことを言ったりも。
（その分、今後考えてくれると信じて。。）
問題が出てきた際に、一緒に解決できる人を作ること。
■周りの協力に心底感謝する。
周りが助けてくれるのは、普通のことじゃない、ということ。
プロジェクト内でもみんなが助けてくれるし、
プロジェクトの垣根を越えて、みんながフォローしてくれる。
うちのプロジェクトは、
大変ありがたいことに、社内でも注力してもらってる。
人生の中でも、こんなに助けてもらいやすい状況は、
なかなかない、と思う。
今は甘えさせてもらって、ヒットさせてから恩返しすること。
■俺たちは「凄いことをやっているんだ」を伝える。
新規開発を一年以上続けていくと、
気づけばそれが当たり前になってしまいます。
自分たちが、改めて思い返したり、
チームに伝えないといけないのは、
「俺たちはいま、凄いことをやっているんだ」
ということ。
新規開発ができるなんて、とても恵まれていること。
俺たちが「面白い」と心底思ったことを、
本当に形にできるチャンスが貰えている、ということ。
その為に、
多少めんどくさいことや気に入らないこと、失うことがあっても全然良いじゃないか。
そんな気持ちが比べ物にならないくらい、
「面白いもの」をユーザーさんに届けるチャンスがある、ということ。
そのチャンスが目の前にあること。
---------------------------
数えたら、32個だった。
（キリが悪いので、2個削ろうか悩んだけどやめた）
色々書いたけど、
一番最後の「俺たちのやっていることはどれだけ凄いか。わくわくするようなことなのか」を伝える事が一番大切だと思った。
ディレクターの仕事か、って言われたら分からないけど、
「職種を超える」というアプリボットの文化らしくて良い気がする。
間もなくスタートに立てる！！！
人気サービスにするぞー！！！
ここまで読んでくれた方がいたら、ありがとうございましたm(_ _)m