Developers.IO 2015 の企画について

3/27(金)、29(日)の二日間にわたって開催した「Developers.IO 2015」は、600名近い方からお申込みをいただき、実際に半数以上の方にご来場いただきました。 当日ご来場された方、会場には行けなかったけど Twitter やセッションのレポートブログをご覧になった方に御礼申し上げます。 本エントリーでは、Developers.IO 2015 の企画や、企画立案時に使ったツール、その際に気をつけたことなどを解説したいと思います。「企画」というと、カーディンガンを肩に羽織ったチャラいおっさんが「◯◯ちゃんシクヨロ！」的なノリで適当に進めているのだろうと思われるかもしれません。

図)チャラいおっさん

しかし現実はノリで済ませられるほど甘くはなく、複数のツールを使って企画意図やコンセプトを可視化し、数十ページにおよぶ企画書を作成してようやく「◯◯ちゃんシクヨロ！」に至ります。そこまではひたすら地味地味アンド地味の世界です。本エントリーではその地味なところについてポイントを絞ってご紹介します。

私はイベントだけでなくあらゆる企画やプレゼンの時にビジネスモデル・キャンバスを描いて、関連する情報を整理しています。この「関連する情報を整理する」というのは、地味さでいうとかなりなものです。しかし、これができていないと、企画が立ち上がり正式にプロジェクトとして走り始めた時にボディブローのように効いてきます。 プロジェクトに例えるとどのような常態かと言うと、タスクの増加量と消費量のバランスが壊れプロジェクトが健全性を保てなくなった頃にある種独特なスモーキー・フレーバー(※ 焦げ臭いと表現するべきだがマッサンの影響)のような香りが漂うころに「そもそも、なんでこんな仕様になったのか？」といった疑問を発したことがあるではないでしょうか。そういった危険なスモーキー・フレーバーが漂う事態を回避するためにも、関連する情報を整理し「ちょっと考えればわかることでしょう」的な欠陥を排除していきます。 ビジネスモデル・キャンバスは、そういった「そもそも、なんで」を整理することに適しています。ビジネス全体を素早く俯瞰できます。そして、とにかく簡単で誰でも使うことができます（※ その気があれば）。現状分析と新規の企画で使わないのはもったいないと思います。

 図）ビジネスモデル・キャンバス

ビジネスモデル・キャンバスは、ビジネスを下記の9つのブロックに整理して考えます。

1	顧客セグメント (CS : Customer Segments)	顧客は誰なのか
2	価値提案 (VP : Value Propositions)	自分たちが何を提供して、それが顧客にとってどのような価値があるのか
3	チャネル (CH : Channels)	顧客にどうやって価値をとどけているか
4	顧客との関係 (CR : Customer Relationships)	顧客とどのようにやりとりをしているか、あるいは顧客が使い続ける理由は何か
5	収益の流れ (RS : Revenue Streams)	提供した見返りは何か（お金とは限らない）
6	リソース (KR : Key Resources)	自分たちは何をもっているのか
7	主要活動 (KA : Key Activities)	自分たちは何をしているのか
8	パートナー (KP : Key Partners)	ビジネスを成立させるために協力してくれる人や組織は何か
9	コスト構造 (CS : Cost Structure)	もろもろひっくるめて何にお金（他）をつかっているか

ビジネスモデル・キャンバスの使い方については、こちらの書籍を参考にして下さい。 (※ そんなに難しいツールではないので、とりあえず手を動かしちゃった方が早く習得できると思います)

ビジネスモデル・キャンバスは、短時間で全体を俯瞰するのは得意だけど、もうちょっと深堀りたいっていうときは物足りないときがあります。特に、ビジネスの核となる「顧客」と、顧客にとっての「価値」について、ビジネスモデル・キャンバスをつかって表現するのは難しいです。グループで一緒に考えたビジネスモデルであっても、価値がどのように顧客と結びつくのかについては、グループ内ですら認識がズレることが多いものです。

私は、「エクスペリエンス・ビジョン」という書籍で紹介されていた「バリューシナリオ」というのツールの簡易版で補完するようにしていました。価値を提供する（or得る）手段とタイミングを明らかにし、その後のPRに繋げるという方式ですが、これでもやはり「そもそも、なんで」が掘りきれないケースが発生します。何故、顧客は私たちの製品（か何か）を求めるのか？　顧客のどういった課題を解決しているのか？　もしくはどういった満足をもたらしているのか？　この辺りがあいまいなままふわっと進んでしまいます。

バリュー・プロポジション・キャンバスの登場

こういった課題はビジネスモデル・ジェネレーションの原著者も感じていたらしく、昨年10月に”Value Proposition Design”が出版され、2015年4月14日に翔泳社さんより翻訳版「バリュープロポジション・デザイン(リンク)」が出版されました。

図）「バリュー・プロポジション・デザイン」の表紙

この本では、ビジネスモデル・キャンバスを補完するためのツールとして「バリュープロポジション・キャンバス」を紹介しています。

図）バリュー・プロポジション・キャンバス

バリュー・プロポジション・キャンバスはビジネスにおける「そもそも、なんで」を可視化するためのツールです。右側を「顧客プロフィール」、左側を「バリューマップ」に分け下記のブロックを用いて両者の関係を明確にします。

• 右側：顧客プロフィール
  • 顧客の仕事
  • ゲイン（顧客の利得）
  • ペイン（顧客の悩み）
• バリューマップ
  • 製品とサービス
  • ゲインクリエイター（利得をもたらすもの）
  • ペインリリーバー（悩みを取り除くもの）

もちろん、これさえやっておけばどんな企画も成功間違いなし！というわけではありません。大切なことは、企画をする際にブラッシュアップを重ねられることと、そのブラッシュアップがどういう状態なのかが可視化されていることです。ちなみに、可視化がされていない時の状態が次のイラストです。

図）「バリュー・プロポジション・デザイン」より。会話ベースで進められることには限度があります。

いかにも、議論は重ねど何もまとまらない雰囲気がありますね。

Developers.IO 2015 での活用例

Developers.IO 2015 の企画においても、情報整理ツールとしてビジネスモデル・キャンバスとバリュー・プロポジション・キャンバスを使いました。大まかな流れは下記になります。

イベントの方針について

まずイベントの方向性について話し合いを行い、以下の方針と目標がでました。

• 「マーケッターを100名集めたい」
• 「クラスメソッドがやるのだから、クラウドとモバイルに関するテクニカルセッションも盛り込み、エンジニアも100名ほど集めたい」

これにより、マーケッターとエンジニアという大きく分けて2種類の顧客の存在が明確になりました。

• 「ファン・マーケティング」

営業や採用に繋がることも大事だけど、社外の人たちにクラスメソッドを好きになってもらえるよう楽しい雰囲気のイベントにしたい、という方針も示されました。

方針と目標が早々にでたので企画は立てやすくなりました。これらが定まれば実現に向けた課題が見えてくるので、あとはひたすら検証やトライアンドエラーを繰り返していくことになります。（※ 簡単になったわけではありません）

企画

企画書のたたき台を作成

目標（マーケッターやエンジニアに来てほしい）やどういう雰囲気（楽しんでもらえる）なのか、といった方針を元に企画書のたたき台を作成します。 この時点では、イベントを企画する上でほとんどのものごとが未確定ですが、わかっていることと、わからないことをひたすら書き出します。わからないことを理由に立ち上げ時点で誰かの決定を待っていると事態はどんどん悪化します。 何がわかっていて、何がわからないのかが明確になれば、ひたすらわからないことを決めていくための活動をするだけです。

ビジネスモデル・キャンバスを使って現状分析

ビジネスモデル・キャンバスを使って、クラスメソッドのビジネスモデルの現状分析をします。組織のビジネスモデルはそうそう変わるものではないので、これは使いまわしです。 その上で、今回のイベントが、クラスメソッドにとってどういう位置づけになるのかを確認します。今回はやっていませんが、イベントのビジネスモデルを作っておくのも良いかもしれません。 ビジネスモデル・キャンバスを描いてわかったことは以下です。

• Developers.IO の運営を通してエンジニアに対する情報発信はできている。しかし、ITを利用する人たち（マーケッターやプランナーなど）への情報発信は充分とは言えない
• したがって、マーケッターをどれだけ集客できるかは未知数。これまで使ったことがないPRを検討する必要がある
• しかし、これまでの活動から、Developers.IO 以外にもチャネルがあることがわかったので、併せて活用することとする
  • ソーシャルメディアを経由した口コミはもちろんですが、プレスリリースや関係各社様からのメールのご案内なども効果が高いです
  • 1つのチャネルに頼るよりは、利用できるチャネルをめいっぱい利用する方が良いですね

イベントの中身を考える

イベント全体の企画・運営は私の責務ではあるものの、最終的には12トラック39セッションという「無茶しやがって」以外に形容のしようがないイベントになったこともあり、これらのセッションを全て私一人で考えるというのは無理です。そこで準備の早い段階で、同僚諸氏の協力を仰ぐこととしました。 しかし、ふわっと「なんかいい感じの考えて下さい」って丸投げするのはもうしわけないので、全体的な方針は明示することにしました。 コンテンツの方針を検討するに当たり、社内のエンジニアとの雑談からどういったコンテンツが望ましいのかを検討しました。

• 実践的な情報が望ましい
• 概要を紹介して終わるセッションは嬉しくない
• 自己啓発？っぽい話もあんまり興味が無い

そして、印象に残ったコメントとして次のようなものがありました。

昔、勉強会に出始めた頃、勉強会は少し怖いところで、迂闊なことを言おうものなら容赦なくマサカリが投げられるような印象があった。そしてセッションの内容は2割くらいしかわからない。でも、知らなかったことをたくさん学ぶことが出来るという満足感があった。自分が経験を重ねてきたこともあるのか、最近の勉強会ではそういった感想を持つことは少ない。自然と勉強会に足が向かなくなってしまった。

これらの情報の要点を抜き出してバリュー・プロポジション・キャンバスを使って整理した結果、「実践(実戦)から得られた知見」が重要なのではないかという分析結果がでました。Developers.IO の記事の多くは「やってみた」系なので、読者がそういったものを求めているとかんがえるのは自然だと思います。

更に、「より実践的な」を実現するために、ハンズオン形式や、少人数でディスカッションがしやすいセッションを用意することにしました。

バリュー・プロポジション・キャンバスによって、顧客が何を望み何を望まないのかの仮説を可視化することが出来ました。これらを元に、セッションをお願いするスポンサー様や同僚諸氏には次のような説明をしました。 （※ 紆余曲折があったことは認めます）

• Developers.IO の名を冠したイベントなので実践的で「やってみた」という内容が良いです
• 難易度は徹底的にマニアックな方向に倒してください。ここでしか聴けないものが望ましいです。マニアック過ぎて聴講者のほとんどが置き去りになるのはOKです （※ 通常のイベントでは、なるべく参加した人が全員理解できるように心がけます。置き去りは参加者の満足度が下がるリスクがあるので普通はやりません）
• 1,000人規模のカンファレンスではないので、思い切って自分たちがおもしろいと思うセッションをやりましょう。集客のことは気にしないでください

ある意味、無茶苦茶なお願いですが、みなさん快く実践的でマニアックな方向に倒していただいた結果が、こちらのタイムテーブルになりました。

Developer Day のタイムテーブル

後日、同僚諸氏から「聞きたいセッションがいくつもあるけど、重なっているから聴けない（聴けなかった）」というフィードバックを大量にもらいました。これについてはもう平謝りするしかないわけですが……。準備も佳境に差し掛かったとき、ふと「100人がなんとなく聞きにくるのではなく、日本中で20人だけが何が何でも聴きたくなるセッション」というナイスなコピーを思いついたのですが、その頃にはほとんどのセッションが決まっていたのでした。残念。

結果

Developer Day には370名程度のお申し込みがあり、実際には半分強の方がご来場されました。また関係者を含めると250名程度は参加をしたということになります。 集客人数の目標は達成できましたし、セッションの狙いが狙いなだけに辛いアンケート結果を覚悟していたのですが、思いの外好評価となりました。 歩留まり率については、控えめに60％を見積もっていたのですが、実際には50％強でした。この課題については「もっと参加したくなる」仕掛けを作っていくしかないだろうと考えています。

まとめ

今回のイベントは多くの人の汗と涙とご家族の信頼貯金の切り崩しなどがあり、なんとかやりきることができました。ありがとうございます。

また、ご協賛企業様におかれましても、拙い運営を大目にみてください本当に感謝しております。ご協賛いただいたにも関わらずタイミング等々でお断りするケースもあり、ご案内に不備があったことは否めず、本当にもうしわけございません。

そういったこともあり、私自身は多くの学びと経験を得ることができ、参加した人の中から採用にエントリーをして入社にいたったケースまであります。苦労はしたものの、やってよかったなあ、と思う次第です。

企画をやってみて気づいた学びのようなものを紹介して終わりたいと思います。

• ドキュメントを書く手間を惜しまない。企画書を書いてなんぼ。
• 企画書を書いたけどなんだかおもしろくなさそうという時は、本当に面白くないのでブラッシュアップしましょう。
• ユーザーの感情についても、（プラグマティック）ペルソナ、共感マップ、VPキャンバスなどを使えばある程度は可視化できるので、わかったつもりになって端折らない。可視化から思ってもないことを突きつけられることは多々ある
• ツールに描き起こしたモデルがしょっぱいのは、ツールがしょっぱいからではなく、自分たちのアイディアがしょっぱいから。机上の空論と揶揄されても、机の上での失敗は全然痛くないので、検証とブラッシュアップをなっとくできるまでやる
• アイデアを客観視して評価する手段を必ず持つこと。しゃべりが上手い人ならどれだけしょっぱいアイデアでも面白そうに説明することができるので、口頭だけで進む場合も要注意

以上です。

書きかけて仕上げるのを忘れていたので公開が今ごろになったことを陳謝しつつ、最後まで読んでいただきありがとうございます。