・
サービスや製品の開発段階で必ず「戦略会議」なる
ものが存在する。
別に開発会議でも企画会議でも構わないけど、
今日はそこでちょっとブレイクスルーしたかな。
開発部が入念に準備したであろう方向性に対して
少なくとも自分の中ではすとんと「腹落ち」した。
しかも、最低限の言葉で。
こうなると早い。
結論までのマイルストーンがしっかりと
イメージできるから、ポンポンポンと必要な石だけ
おいて、ロジックを組み立てればよろしい。
役割分担も明確にイメージ可能。
このような「会議」であればちゃんと結論が出るので、
時間を取るだけの価値はある。
会議の仕方について少しだけ考えてみると、
いくつかの要素が必要になってくることがわかります。
今日は少しだけ、自分なりの考えを。
ちゃんとまとめてないし、思いつきなので、
乱文お許しを。
またちゃんとまとめます(いつか)。
１、目先の議論に没頭しない
陥れいりやすい落とし穴は、
「目先の議論」に没頭してしまって、
論点がどんどん逸れて行ってしまうこと。
話すべき主題は何？
この会議で結論出したい論点は何？
ちゃんとそこに立ち返りましょう。
よくあるのが、
「販売戦略」を考えていて、いつの間にか
「広告戦略」を議論していたり。
これじゃ決まるものも決まりません。
こういう話は、ブレストであればOKだけど、
結論出さないといけない会議の際は無意味です。
あれ？ちょっと違うな、と思ったら、
すぐに目線を上にあげ、全体を俯瞰しましょう。
２、「たられば」「かもしか」の話をしない
まず、ネガティブな要素はすべて「リスク」として扱う。
注意すべきは、リスクを主要論点として扱ってしまうこと。
そして、「たられば」の話は、
レイヤー上げて議論の本筋にのっけてしまうと、
結論が幾筋にも分岐してしまうので別で扱う。
(※ブレスト時は扱ってもいいですよ、もちろん)
できれば扱いとすれば、
システム開発時の「テスト・試験」のように
フェーズを分けることができれば最高。
クリティカルな要素は誰だって気づくよね、という、
自浄作用を期待した会議の進め方でも問題ないように思う。
そして、「たられば」の話に関しては、
必ず根拠を設けるように。
たとえば、
「もしアクティブ10万ライセンスユーザーが
集まれば起動画面に広告入れれるよね？」
というような話は、サービスリリース前の
戦略段階では無意味。まさに絵に描いた餅。
そこを話す前に、アクティブ10万ライセンスを販売する
方法(もっと言えばまず1000ライセンス)を考えよう。
３、枠組みとディテールで会議のレイヤーを分ける。
骨子立案→ディテール落とし込み
それぞれ会議の方向性も招集するメンバーも違う。
同じ時間内に行わないこと。
４、会議のための準備をしっかりする
これに関してはそのまんま、そして、
実はこれが一番大事。
準備したアイデアには説得力を持たせよう。
５、スピード
とにかく結論スピードを速く。
迷う暇があれば、
再検討する時間があれば、まずやってみよう。
あとはチーム各員の能力に依存しますよね。
普段から情報収集に勤め、
勤勉に仕事に取り組んでいるスタッフからは、
「思いつき」や「自分の経験・考えに頼った感覚」
といった定量化できない訳の分からない意見は出てこない。
これだけ情報スピードの速い世の中、
ユーザーの目も肥えている。
ユーザーを甘く見てはいけない。
今までとは違うアプローチでいかなければ、
過去に何度となく繰り返された手法を
トレースするだけになってしまうんですよね。
自分の思考の整理にもなりました。
・
具定例も掲載されていないので、
あまりいい記事とは言えないけれど、
内容的には分かりやすく書いてあるので一応掲載。
まあ、目次的な内容にはなりますが。
「わかったつもりになっていませんか：
「ビジネスモデル」とはなんだろう?」