nanapiメンバーでミーティングをするときにやってることを書いてみます。
いつも新しい何かを話すときは、最初に↑の図を書いて、これから何の話をしようとしているかを、一番上段のAから確認します。最初の5〜10分くらいです。特にC、具体的な手法の話をしようとしているときは特に意識してこの確認をします。
目的は以下。
- 上段にあるAとB「目的」「やり方」から順に確認していくことで「なぜやるのか」を再確認
- 手段の話で盛り上がりすぎるのを防ぐ（Cの話をする場合）
- 全員の熱量と目線の高さを合わせる
よく見かける、戦略・作戦・戦術っぽいですが、そこまでちゃんとしたものでなくてもよくて「目的からちゃんとブレイクダウンした上で、これから何を話そうとしているか/何を話すべきか」だけわかれば良い。この図があると、より可視化できるのでサッと書いてます。
これからCの具体的な施策（新機能の実装や、なんかキャンペーンとか）について話そうとしている場合、Cより上のAかBに空白、もしくは不透明なままの箇所があるなら、そこを埋めてからCの話したほうが良くない？というアラートにもなる。そこを空白にしたままそこより先の話をしてしまうと、すすんでからズレがわかり、場合によってはすごい後戻りになってしまうので。 密なコミュニケーションをとってる同士でも、あとになって齟齬が発覚して無駄な時間が発生する、ということがわりとあります。
AとBのところが明確になって、じゃあ具体的なCの話をしようか、というときも、
- AとBを実現するCは今から話そうとしているaでいいの？
- その他にbやcになりうる案はないか検討した？
- aとbとcがあったら本当にaが最適って明確なんだっけ？
も、一応話しとく。「aを実装したらBが実現しそう」っていう手段やアセットから逆算で考えるのとか、勢いで「一旦aをまずは実装してみますか」みたいなのをやりがちなんですが、サービス開発ってそんなに簡単なものじゃないし、経験上ほとんどうまくいかない印象。趣味やサークル的な集まりだったらいいけど、自分は天才でもないんで仕事ではあんまりやっちゃだめなやり方だと思ってます。
あと時々ブレストが白熱すると、どっか一箇所にフォーカスしてめちゃくちゃ話込んじゃったりするんですが、一旦落ち着いて↑の図で「今どこの話してるんだっけ？」を確認すると、いまそこの話をすべきかどうかが冷静にわかっていいです。Bを固めようとしているのに、まだ決まってもないbの案について白熱してもしかたないですからね…。そんなバカなことある？って感じなんですが意外にやってしまうんです、、
そこはファシリテーターとかプロジェクトを引っ張るリーダーがズレのないように牽引せえよ、とも思いますが、誰かひとりだけがわかっててもみんながついてきてないとあんまり意味ない。プロジェクトはチームで進めるものなので、全員の腹落ちのためだったり、意識を揃える意味でも、毎回こういう丁寧な確認をしていく方が、結果無駄な時間を抑えられるんじゃないかなーと思います。
今のチームのメンバーはこの辺の理解があり面倒臭がらず確認してくれるし、手段の目的化もやめようと意識しあってます。どのプロジェクト、チームにも応用できるものかはわかんないですが、今のチームではこのように進めていて結構うまくいっています、という話でした。