プロダクトオーナーの異常な雑用 または私は如何にしてプログラムするのを止めて雑用をするようになったか

タイトルについて

映画のパロディです。
ジョニーの凱旋が流れるシーンが好きです。

私の担当

チームにおける私の配置は

• プロダクトオーナー
• チーフエンジニア
• 雑用係

の３つです

経緯

私は業務外でゲーム開発チームを運営しています。
役割分担は「システム」「シナリオ」「デザイン」の３人でした。
ひとまず開発が落ち着いた段階で、製品そのものはゲーム性を備えたので、販売を強化しようということになりました。
すなわち、販売強化に関わるタスクを誰かが受け持つ必要がありました。新しく人とかまだ雇えないし。
この時点でデザインさんは投入可能時間と要求作業量が均衡しており、新しいタスクは振れません。
シナリオとシステム、どちらが作業したほうがゲームのプロダクト価値をあげられるか、と考えた時、データ分析から、明らかにシナリオ量のほうがユーザーに訴求することが明らかでした。また、ゲームシステム開発はひと段落し、新たにシナリオスクリプトを投入すればほぼ追加開発がなくてもゲームリリースが回る状態になっており、システムのタスク需要が大きくなかった、という判断から、システム担当がシステム開発の時間を削り、販売強化にまつわるタスクを受け持ちました。

販売強化is何

大きくあげると「マーケティング」「販売宣伝」「カスタマーサポート」「データ分析」「売上集計」「渉外ぜんぶ」に分化されます。
あとでイラスト絵などの「外注管理」も加わりました。

そのあとも「いま、誰の作業時間を"本業"に当てれば最もプロダクト価値が上がるか」は常にリリース単位で検査の対象となりました。結果は上下するものの、「最も価値に寄与しない」最下位と判断されたのは常にシステム担当でした。
こればかりは同じゲームエンジンを使いまわすというプロダクト戦略の都合上やむをえません。
そのため、私は常に「雑用係」を担当しました。

雑用と便宜上言っていますが、こうして並べると分かる通り、製品開発以外の「超重要な業務」です。ないとプロダクトとして機能しません。作って終わりではありませんから。ですので、私もかなり真面目に取り組みました。
特に、マーケティングと販売宣伝には注力し、１年間で売上８倍の売上を達成しました。

担当の基本

１人に複数の役割を振ってもいいですが、責任を持つ役割を同列の２人に振ってはなりません。常識です。コーラを飲んだらゲップが出るレベルの。(エッセンシャルスクラムにそう書いてあった)
そのため、雑用係は輪番制や共同担当制をしかず、常に私が受け持ってきました。

担当制

ながらく担当として一人に担当すると「強い責任感」と「ノウハウの蓄積」による高いパフォーマンスが期待できます。逆に「どうでもいい仕事」で邪魔をしてしまうと「自分は軽んじられている」と感じて"本業"にも"副業"にも責任感を感じられなくなります(出典：ピープルウェア)
メンバーを専門職として尊重し、"本業"に高い生産性を出させるためには、誰かが"落穂拾い"を引き受ける必要があります。今回の場合はそれがプロダクトオーナーである私の仕事でした。

自分が担当したことによる利益

その甲斐あって、２つの利益が得られました。
１つは他の担当を雑用から解放したことで、プロダクト価値に寄与するシナリオやデザインの生産性が常に上がり続けたこと。
もう１つは、プロダクトオーナーが雑用を行ったことでユーザーのニーズや考えていること、販売媒体が我々に期待すること、売れ線の把握などがそのまますぐにプロダクト戦略に反映されたことです。

インメモリ理論

コンピューターサイエンスのセオリーとして、記憶媒体のI/Oを行わず、高速なメモリ上のみのデータを使って計算を行うとスループットが向上します。
同様に担当間で情報をやりとりするより、一人の人間が別の担当として仕入れたノウハウを別の担当としてふるまうときに利用することで、高いスループットと強力なシナジー効果が得られました。今回のケースで言えば、「カスタマーサポートや渉外担当、データ担当」という外向きの担当とプロダクトオーナーを兼任していた点です。
もっというならプロダクトオーナーがシステム担当も兼ねていたので、システム側のギミック実装が極めてスムーズでした。

プロダクトオーナー＋エンジニア＋雑用係

この組み合わせが機能したのは、私が比較的企画よりのエンジニアだったこと(逆に言うとガチガチの技術よりではない)と、なんでも一通りこなせる「便利屋」的なスキルを備えていたことが影響していると思います。
経験としては楽しかったですし、新規事業とかやるときにはまたこういうことをやってもいいな、と思いました。

データを見る限り、私が雑用することでチーム全体のパフォーマンスは向上しています。
「誰の本業がプロダクト価値に寄与しているか？」は計測していてよかったと思いました。

悲しい現実

上ではかっこいいことを言っていますが、なにか「必要なタスク」があるとわかったとして、みんな自分の仕事に全力投球しているので、新しいタスク引き受ける余裕なんてないんですよ。
雑用振れるような新卒メンバーがいるのは大きい企業だけなんです。
ということは、そのタスクは誰かが(主に自分)引き受けなければいけなくて、そのためには本来予定にあったタスクを外すか、あるいはその新しく湧いたタスクを後回しにするかの二択をせまられるわけです。
その現実から目をそらして、「無理してでも両方やろう」とか言えないわけですよ。特にある程度以上のタスクサイズなら。
そこで腹をくくって現実を受け入れて、計画修正するのがプロダクトオーナーの仕事だと私は思ってます。

結論

プロダクトオーナーならチームのために雑用とかやっても楽しいです。結果が出ている場合は特に。 。

プロダクトオーナーの異常な雑用 または私は如何にしてプログラムするのを止めて雑用をするようになったか

タイトルについて

チームにおける私の配置は

• プロダクトオーナー
• チーフエンジニア
• 雑用係

の３つです

経緯

私は業務外でゲーム開発チームを運営しています。
役割分担は「システム」「シナリオ」「デザイン」の３人でした。
ひとまず開発が落ち着いた段階で、製品そのものはゲーム性を備えたので、販売を強化しようということになりました。
すなわち、販売強化に関わるタスクを誰かが受け持つ必要がありました。新しく人とかまだ雇えないし。
この時点でデザインさんは投入可能時間と要求作業量が均衡しており、新しいタスクは振れません。
シナリオとシステム、どちらが作業したほうがゲームのプロダクト価値をあげられるか、と考えた時、データ分析から、明らかにシナリオ量のほうがユーザーに訴求することが明らかでした。また、ゲームシステム開発はひと段落し、新たにシナリオスクリプトを投入すればほぼ追加開発がなくてもゲームリリースが回る状態になっており、システムのタスク需要が大きくなかった、という判断から、システム担当がシステム開発の時間を削り、販売強化にまつわるタスクを受け持ちました。

販売強化is何

大きくあげると「マーケティング」「販売宣伝」「カスタマーサポート」「データ分析」「売上集計」「渉外ぜんぶ」に分化されます。
あとでイラスト絵などの「外注管理」も加わりました。

そのあとも「いま、誰の作業時間を"本業"に当てれば最もプロダクト価値が上がるか」は常にリリース単位で検査の対象となりました。結果は上下するものの、「最も価値に寄与しない」最下位と判断されたのは常にシステム担当でした。
こればかりは同じゲームエンジンを使いまわすというプロダクト戦略の都合上やむをえません。
そのため、私は常に「雑用係」を担当しました。

担当の基本

１人に複数の役割を振ってもいいですが、責任を持つ役割を同列の２人に振ってはなりません。常識です。コーラを飲んだらゲップが出るレベルの。(エッセンシャルスクラムにそう書いてあった)
そのため、雑用係は輪番制や共同担当制をしかず、常に私が受け持ってきました。

担当制

ながらく担当として一人に担当すると「強い責任感」と「ノウハウの蓄積」による高いパフォーマンスが期待できます。逆に「どうでもいい仕事」で邪魔をしてしまうと「自分は軽んじられている」と感じて"本業"にも"副業"にも責任感を感じられなくなります(出典：ピープルウェア)
メンバーを専門職として尊重し、"本業"に高い生産性を出させるためには、誰かが"落穂拾い"を引き受ける必要があります。今回の場合はそれがプロダクトオーナーである私の仕事でした。

自分が担当したことによる利益

その甲斐あって、２つの利益が得られました。
１つは他の担当を雑用から解放したことで、プロダクト価値に寄与するシナリオやデザインの生産性が常に上がり続けたこと。
もう１つは、プロダクトオーナーが雑用を行ったことでユーザーのニーズや考えていること、販売媒体が我々に期待すること、売れ線の把握などがそのまますぐにプロダクト戦略に反映されたことです。

インメモリ理論

コンピューターサイエンスのセオリーとして、記憶媒体のI/Oを行わず、高速なメモリ上のみのデータを使って計算を行うとスループットが向上します。
同様に担当間で情報をやりとりするより、一人の人間が別の担当として仕入れたノウハウを別の担当としてふるまうときに利用することで、高いスループットと強力なシナジー効果が得られました。今回のケースで言えば、「カスタマーサポートや渉外担当、データ担当」という外向きの担当とプロダクトオーナーを兼任していた点です。
もっというならプロダクトオーナーがシステム担当も兼ねていたので、システム側のギミック実装が極めてスムーズでした。

プロダクトオーナー＋エンジニア＋雑用係

この組み合わせが機能したのは、私が比較的企画よりのエンジニアだったこと(逆に言うとガチガチの技術よりではない)と、なんでも一通りこなせる「便利屋」的なスキルを備えていたことが影響していると思います。
経験としては楽しかったですし、新規事業とかやるときにはまたこういうことをやってもいいな、と思いました。

データを見る限り、私が雑用することでチーム全体のパフォーマンスは向上しています。
「誰の本業がプロダクト価値に寄与しているか？」は計測していてよかったと思いました。

結論

プロダクトオーナーならチームのために雑用とかやっても楽しいです。

チーム用チャットにサマリーKPI通知bot作ってみた

Advent Calendar

この記事はProduct Owner Advent Calendarの３日目です。 Product Owner Advent Calendar 2015 - Qiita

挨拶

こんにちは、瀬宮です。 プロダクトオーナーの役割の１つとして、チームをまとめ、市場的成功のために努力するというものがあります。 今回はチームメンバーの意識をまとめ市場的成功のほうを向かせる努力をした話をします。

やったこと

他社のチャットで定期的にプロダクトのサマリーデータを通知するbotがいて、便利そうだったので自分のプロジェクトでも実際に作ってみました。
このbotはチーム向けチャットに自動でつぶやきます。
チャットに載せる情報はチームメンバー向けです。

注意

この記事ではbotの実装には触れません。 hubotで作った系列と直接Slack APIを叩く系列があります。

botにデータを流させることで達成したいこと

• 数値をもとにした行動の改善
• 自分を含むゲーム開発メンバーの士気の向上
• プロダクトの市場反応の監視
• 市場反応の異常値の検知

やったこと

上の４つの目標を達成するために、botを作成し、チャットで色々話させてみました

数値を選ぶ上で

数値を選ぶ基準はだいたい以下の通り

数値が変化すること

滅多に動かない数値を取っても何もできません。

わかると嬉しいこと

その数値がわかることで、なにか嬉しいことがなければいけなません。
特に何かに使うあてもないが、重要そうだから、では数値はとりませんでした。
上の目的に沿わない数字はとりませんでした

数値をもとにアクションを取れること

取った数字をもとにアクションを取れる数字を取りましたた。
アクションにつなげづらいものは後回し＝とりませんでした

わかったこと

botを作ってわかったこと

時間

botがつぶやくのは朝の９時頃がよいです。
一気にやる気が上がるし、今日も１日がんばるぞい感が出ます。
ユーザーの購入は夜中心です。朝だと販売の伸びが一段落していて１日の売上の確報感があります。
逆に夜は売上実績の数字が上がっている最中で、確報感がありません。夜に出そうとするのは良くなかったです。

数値を多数出すのは良くない

出ている数値が多いと、知りたいことを知るためにそれが分かる数値を探すが、それが「ウォーリーを探せ」状態になるからよくなかったです。
チャット上の発言だと特に探しづらいです。
また、各人がその数値の群れからそれぞれ「各人が見たい情報」を拾ってしまう(もっというと、見たいものを見たいように見てしまう)ので、共通の見解が得られないです。
多くの数値を載せることはMTG資料ならそれでもいいですが、チャットの速報は天気予報のように、「短期間で短期的な現状をさっとわかるようにすること」が目的なので今回は避けました。

数値は絞る

各位に「知らせたいこと」をもとに数値をピックアップします。
現状を的確に表す情報は、週報を出すより、日報で出した方がよいです。
必要なら時報でもありです。
逆に多数の数値を並べても景気付け以上の意味はなく、逆に前述のマイナス効果が強くでました。

数値は変える

発売直後と発売一ヶ月後だと数字の伸びがまったく違います。
我々の場合、発売初週で売上の過半を出すので、必然的に時間が経つと日毎売上が萎れていく様が明示されてしまいます。
士気を上げるために景気の良い数値を見せたいので、発売直後は１日ごとの販売数を、販売から期間が経ったら累計数と前作同時期比を表示します。

市場反応にメンバーの興味を向ける

メンバーが数値を毎日目に向けるようになり違いにすぐ気付くようになって、プロダクトと市場反応の関係に興味を示します。
つまりメンバーがユーザー目線を持ち、「このプロダクトは売れるか？」を気にするようになります。

見せる数値は絞るけど裏で貯める

絞っているだけで、想定された事態が惹起されたときに分析するための数値は貯めておきます。
ログそのものは残っていても、何かあったときにそれを取り直すのは面倒があります。
面倒があると「面倒くさいからいいや」になってしまいます。

異常時は知らせる

異常時、つまり急な売上の上昇や沈滞などの事態には、botがメンションを飛ばし「これはヤバイ」感を示す必要があります。
グッドニュースなら祭り感が出るし、バッドニュースなら連携して解決しよう感が出ます。

botを作ってよかったこと

数字を見たチームメンバーから改善案が出たこと

「売上が初週以降すぐ落ちる、パッケージとマーケティングがいけないのではないか」
というような提案がよく出るようになりました。

チームメンバーの意識の変化

常に数字を見せるため最終的な市場での実績をゴールだと考えるようになりました
チームメンバーが製品の開発だけでなく売上のことまで考えてくれるようになりました

酒が美味くなった。

「今回は成功したか？」「前回に比べてどれくらい成功したか？」が明確に分かります。
明確に分かるから、メンバーは、リリース時ではなく、販売直後の販売実績速報値を見て祝杯をあげるようになりました。
このときに気持ちよく酒を飲みたいために、「リリースまでの開発的成功」から「販売の市場的成功」に強い責任を感じるようにマインドが変わりました。

結論

俺たちは登り始めたばかりだ、このチャット用bot実装坂をよう

プロダクトオーナー祭り2015でベストスピーカー賞をいただきました

11/28のプロダクトオーナー祭り2015でベストスピーカー賞をいただきました
gloops様会場提供、日本のプロダクトオーナー会の最先端を突っ走っている関満徳様のPOStudy主催の大規模イベントで、企画が本業でない私がベストスピーカー賞をいただけた点は感謝の極みです。
プロダクトオーナー祭り2015 ～世界を変えるのは俺たちだ！～ - POStudy ～プロダクトオーナーシップ勉強会～ | Doorkeeper

今後ともユーザー目線、市場目線でプロダクトオーナー＋エンジニアの両輪の視点を持ちつつ頑張っていこうと思います。

業務外での活動ということで、社外秘密もなく自分が考えたことを生々しいほどに書きました。
綺麗事ではない課金とゲーム性の両立、ぜひ読み取っていただければ幸いです。

ユーザーの時間軸を含めたプロダクトデザイン from Shin Semiya

www.slideshare.net

なお、ワークショップ部門トップはヤフーの伊藤さんでした。卒業すると認定メトリクススペシャリストがもらえるそうです。我々のチーム The 苦労人's は全員が受託開発経験者かつ「品質」のSQiPなどの活動を認知しているというハイコンテクストなチームだったので話が素早くまとまりました。 メトリクスによる「見える化」のススメ:No 見える化、No 改善

カスタマージャーニーマップの作り方

会社でカスタマージャーニーの話が出ていたのでちょっとここに書く。
カスタマージャーニーについて悩んでいた彼がここを見るかもしれないし見ないかもしれない。
もし見たのなら助けになればいいと思う。
あくまで私の一見解であるので特に勧めたりはしない。
また一見解であるので、真に受けて痛い目みても責任は取れない。

本題

さて、私はカスタマージャーニーとはUX設計の一手法だと思っている。

ここにAirBnbのカスタマージャーニーの図があるんだが、これはわかりやすい。
ただしわかっている人間にとっては。
わかっていない人間にとっては非常に誤解しやすい図だと思っている。

ドツボにはまるケース

わかっていない人間は手続き的にユーザーの動作を列挙しようとしてドツボにハマる。
つまり行動を列挙し、それにともなう感情を付け加え、最後に書き連ねた内容を総括して「結局ユーザーは何をしたい？」を書く。
順番として 行動 > 感情 > 目的の順番でまとめようとする。そしてドツボにはまる。

ドツボにはまらないケース

順番として 目的 > 感情 > 行動の順番でまとめる。話は結論から始まる。論文を書くときに Conclusion comes first って習うでしょう？

AirBnbがシンプルなのはあれを利用したい人間にとっては(少なくとも初回は)楽天トラベルやじゃらんと同じサービスだ。
つまり、旅をしたいときに、金を払って泊めてくれる宿泊先を探すサービス。
目的が明確。

どうフェーズに分解するか？

ユーザーは旅行先での宿泊先を探したいのだ
より分解するなら

• 宿泊先を１つに絞りたい
• 宿泊先オーナーと交渉し契約を成立させたい
• 当日に宿泊先に移動したい
• 利用後に宿泊先を評価したい

となり、それぞれにモチベーションと不安が存在する。
それぞれをフェーズとして分解する

ここで注意すべきなのは最後の「利用後に宿泊先を評価したい」はユーザーが先天的に持ち得る感情ではないため、後天的に動機付けすることで行わせる必要がある。

カスタマージャーニーではフェーズごとに何を書く？

モチベーション実現(あるいは不安解消)に伴うユーザーの感情を列挙し、感情に伴うそれぞれの行動を列挙する

感情とは？

宿泊先を選定するにあたり利用者が抱くであろう感情を列挙する

• 宿はどんな感じの部屋？(興味)
• 交通利便性は？(興味)
• お値段は？(興味)
• 宿は写真通りの快適そうな場所か？(不安)
• オーナーは悪党ではないか？(不安)

感情欄に上の感情を書き過度に下がりすぎないようにする
過度に下がると離脱するから。

行動とは？

上記の感情を解決するためのもの。
インサイトにアバウトな解決の方針を書く。
インサイトの方針に沿って実装方針を後で決めることにする(別にカスタマージャーニーマップ内で決める必要はない)
AirBnbで実装された内容はこんな感じ。

• 部屋や建物の写真の掲載
• 地図の表示
• 総額及び内訳表示の終え弾表
• レビューの掲載、貸切かについての部屋タイプ表示
• オーナーの顔写真と素性掲載

ところで上にあるペルソナってなんぞ

ペルソナはユーザーの代表的な属性を書いたもの。
モチベーション、あるいは感情のレベルで「同じ」と判断できるものについてはまとめる。
「同じではないもの」についてはまとめずにペルソナを分ける。

アンチパターン

年齢を10代、20代、30代、40代。性別を男性、女性。家族を独身、既婚でマトリックス化しようとする。
それは目的や感情に影響するか？しないなら無駄だ。いますぐやめろ。

分けるって具体的には

例えば移動手段を選ぶとき
「時間と体力はあるがお金のない学生」は安いがしんどい深夜バスを好む
「時間と体力はないがお金はある老夫婦」は高くても快適な飛行機や新幹線を好む。

AirBnb的に考えるなら

「初めての海外旅行の日本人」は比較的値段が高くても表通りに面した、親切なオーナーの治安が良く清潔な宿泊先を好むだろう
「旅慣れた外国人のバックパッカー」ならば裏通りの、尼崎や西成みたいな比較的下町(婉曲的な表現)の安いドヤ宿や簡易宿泊所のような場所でもよいだろう。

独身男性なら相部屋二段ベッドのシェアでもよいだろうが、小さい子供連れのファミリーなら一戸建て貸切の宿泊先を好むだろう。

このように大きいレベルの目的は同じでも求めているものが違う、感情が異なる、あるいは対象選定の評価基準が異なるユーザーはペルソナを分けたほうがいい。
これらを一緒にして扱うことは、どちらに対しても親切でないごちゃごちゃとしたサービスをつくることにつながる。

ペルソナは適切な分割を必要とするが、どの粒度で分割するかについてはケースバイケースである。
最初は３パターンくらいで作るのがよいかもしれない。
ただし、ヤフオクやメルカリみたいなサイトを分析するならなら「よい買い手」と「よい売り手」のような「ユーザーの最小構成」は作っておく必要がある。

カスタマージャーニーマップとはなにか？

ユーザーは大目的においては共通である。(AirBnbなら旅をしたいときに、金を払って泊めてくれる宿泊先を探す)
しかしペルソナ単位で実際に手に入れたいもの、満たしたい感情や求めている機能は異なる。

ペルソナごとに以下のことを行うことが目的である。

• ユーザーの行動段階に即してフェーズ分けし、ユーザーの段階単位の小目的を定義することこと
• ユーザーの感情に沿って行動を定義することでユーザーエクスペリエンスを設計すること
• サービスには必要だが、本来ユーザーが取りたがらない行動を明確化させ、動機付けの設計を行わせること

またそれらを行うことで以下の利益がある

• UXの設計が行えることで高いユーザービリティを確保できる
• ユーザーの離脱動機が見えるためKPIの設定がしやすい
• ユーザー動線が明確なため、動線単位で設計変更がしやすい
• 離脱率を低下させる

これだけは覚えておいてください

カスタマージャーニーマップ＝ユーザーの求めるものに合わせてUXを設計するための手法。

コミケの実像をデータ解析から読み解こうとした-コミケ35周年調査報告から読み解く-

最近の日常

最近、データ解析にはまった。
実践してみたところ「男女比は50%である」「身長が高い人ほど体重が大きい傾向にある」というレベルの大変有益()な解析結果が得られ、真剣に反省する必要に駆られた。

前書き

コミケのユーザー層をサービスに取り込めないかという話が会社で出た。
ちょっと調べてみたが、なかなか面白かったので分析した結果をここにまとめる。
調査結果から読み取れる内容からは、興味深い結果がわかるとともにデータ解析でよくある「誤った解析結果」を出す条件が揃っていてとてもおもしろい。

会社でこの話をしようとしたがエンジニアがコードがでない話するのも肩身がせまいのでここで書く

種本

コミックマーケット35周年調査報告
注意：これは6年前の調査報告書
昨年の調査報告書も持っているが、裏取りの都合から一般公開されている方が良いと考えこちらを選んだ。

読み解くと？

アンケート以外で公表されていること

コミックマーケットとは( コミックマーケット - Wikipedia引用)

コミックマーケット（Comic Market、通称：コミケあるいはコミケット）とはコミックマーケット準備会が主催する世界最大規模の同人誌即売会。

• 春夏に２回開催
• 東京ビッグサイトを全館貸し切る唯一のイベント
• ３日間で合計５７万人の来場者

要するに同人業界最大のイベントにして、日本有数のイベント

アンケートで公表されていることから気になっているところだけ

参加者

サークル参加者は男女比　１：２
一般参加者は男女比　２：１

地域性？

関東が64％、ついで東海が12%。
大人口地域である近畿は13%。

地域性が高いと言える
すなわち、全国区のイベントというよりは関東ローカルの大規模イベントといった様相を示す。

サークルの構成員から見る、製作者のイメージ

サークルの参加者は１〜２人が男性だと80%弱、女性は90%強。
ほぼ企画〜製作〜販売をクリエーターが単独で行っているケースが多い
大半が二次創作であり、「原作の上に乗っている」という点を除けば企画〜製造〜販売まで１人で担当していることになり、極めて独立色の高い作家が多い。
クライアントから依頼を受け、納品して報酬を得るタイプの作家とはマインドセットが大きく異なっている

頒布傾向

「頒布物は何主体か？」という質問に対し
男女別で傾向が大きく異なる
最主力は漫画主体。男性で58%。女性で70%。
男性は漫画58% + イラスト24% + 小説12%
女性は漫画70% + イラスト07% + 小説32%
でいずれもこれらが主力を占める

男性の評論系主体11%とグッズ主体(男女10%程度)を除けば、残りは1%程度。

部数

総頒布部数は1,000部以下が60%
総頒布部数はイベント合計で 900万部

商業誌での発表希望

サークル参加者で全体で16% 300部〜3,000部のボリュームゾーンでも「強く希望する」は18~25%。
商業誌への転身作家の多さとは別に、商業誌での掲載希望の強さは大きくはないことがうかがえる

収益

年間収支は4割弱が黒字
７割が赤字、半数以上が５万未満の赤字、残り１５％は５万以上の赤字

消費額

コミケでは企業サイドと同人サイド(販売主が個人)があるが、ここで扱うのは同人サイドのみ
男性平均は¥28,400
女性平均は¥21,865
母数の男女比を考慮して¥25,000強くらいが平均と思われる

参加日数

全開催会期３日中、平均すると２日弱参加する

取扱高

述べ57万人かつ平均２日弱参加のためユニークユーザーは約30万人弱
30万人弱が¥25k強を消費するため、同人サイドだけでも約75億円の取扱高、市場規模がある。
企業サイドも合わせれば１回あたり100億円の取扱があることになる。

購買傾向

男女ごとに購買傾向は大きく異なる
「ジャンルごとの作品を購入したか」という設問に対し
男性は漫画(88.4%)、イラスト(62.8%)に集中している。
女性は漫画(96.6%)、イラスト(43.0%)、小説(73.4%)に集中している

男性は「小説(38.4%)」は女性ほど買わない。
男性は「論評、音楽CD、ゲーム、写真集」は30~40%で多くはないがある程度の層が買っている。
女性は「論評、音楽CD、ゲーム、写真集(全て20%以下)」はほぼ買わない。

グッズは集計対象に入っていない。誤差レベルということか。

ほかに？

業界人

サークル参加者側に(いわゆる)業界関係者は男性で10%、女性で7%存在する

さてさて

ここまでよんでどう思われました？

アンケートは嘘をつく

あんちべさんだったと思うのですが「データ解析において良い回答には良い設問が必要だ」といいました。

このアンケートが抱えている問題

営利目的のプロジェクトの参考資料としてこの調査報告を参考資料とした過去の実例を知っています。

上のアンケート結果は実態調査のため、２つの問題を抱えています。
一つは任意回答であることです。
ロイヤリティの高い人間ほど回答率が高く、逆は低いため、全体集団から回答した集団が偏っているせいで結果が上に出ます。
もう一つが実態調査という都合上、回答者の属性を「男性、女性」「サークル参加者、一般参加者、スタッフ参加者」という極めておおざっぱな括りになっています。
そのため、「イベントの地域性が高い」というイベント特性への誘導や
同人イベントの市場理解への「小説の善戦」「平均単価の高さ」「収益性の構造」「頒布部数の分布」を見誤らせる数値が隠れています

調査結果から有意な結論を読み取るために

１つは母集団をうまく選定し、よい設問を設定することです。
もう１つは既存の資料から読み取る際に修正をかけ、誤った結論を読み取らないようにすることです。
いずれもドメインへの理解と知識、あるいは経験を必要とします。

結論

この調査結果を真に受けてプロジェクトを始めるのは死亡フラグなのでやめたほうがいいと考える次第であります。

ドメイン知識を計画作りにどう使うか

結論

ドメイン知識のある人というのは、気象予報士みたいなものだと思っている
ドメイン知識は持っているだけでは役に立たない。
どう使うか。気象予報士のように使う。

気象予報士はなにをする？

気象予報士は天気図を見て、未来の事象である明日の天気や気温を予測する。
これは、明日の事象に影響する変数要素や数式を理解しているからだ

気象予報士のように使う、とは？

ある特定の、未来の事象を変数要素や数式で予測できること。
また、天気予報に含まれる要素(気温、天気、降雨確率、降雨量)のように「事象を表す要素として何を発表すればいいか」を無数の要素のなかかから選択できること。

未来の事象を数式で予想できること
数式に必要な変数要素がわかること
事象を表す少数の要素を選択できること
この３つが重要

昔大規模イベントの分析を行ったことがあって、イベントを表す要素として「推定参加者数、推定売上、１行説明」を入れた。これで読んだ人が大体わかるだろう、っていう要素がこの３つ。
推定に当たってはいずれも私が担当した分野では公式発表されないことが多い数値だが、いくつかの要素がわかればこれは簡単に推定できる。
例えば参加者数は消防法のからみで推定できる(詳細は秘密)。

事象を予測できると何がいい？

現実味のある企画書が書ける。
企画書には２種類ある。
現実性のある「プラン」と数字に現実味のない、極彩色の妄想である「ドリーム」だ。
後者は企画者の脳内にある現実歪曲空間でだけ通じる法則に基づいて作られている。

ドリームの何がまずい

ドリームだと判明しなければそのままサービス開発してしまい、３年たって赤字垂れ流しで撤退判断みたいな目にあう。
(2013年くらいのソシャゲやそのあとの新規事業でよくありましたね)

OSSのコミッタークラスが素晴らしい技術開発したプロダクトでも、現実味のない企画にもとづいて作られれば、それは「すごい技術で作られたガラクタ」にすぎない。
(うっ、心当たりが・・・)
開発し始めた当初は「ソシャゲでぶいぶい言わせた俺たちが作るんだからヒット余裕っしょ」という砂糖に蜂蜜かけたような甘い目論見は、３年間パッとしない現実の前に押しつぶされる。

ドリームをやめるには

ドリームの検出は役員チェックあたりで検出されることが多いが、役員チェックの前に企画のコストがかかっていることを考えると、企画者自身の目で「これドリームなんじゃね」っていう判断をすることが望ましい。
そのために企画者がドリーミーな企画書を書かないことが必要。

ドリーミーな企画書を書かないために、企画者自身のドメイン理解が必要だと思っている