5
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

私とチームの課題と興味の移り変わりについて

Posted at

会社で「コミュニケーションコストに関する問題をどう解決するか?」と聞かれて正直何にも思いつかず「適当にやればよいのでは?」と答えた。
そのときは思いつかなかった。過去のプレゼン資料を漁ったら15分級の発表資料が3本見つかったにもかかわらず、昔はあんなに頭を悩ませた問題であったにもかかわらずだ。

なぜ思いつかなかった?当時はどうでもよくなっていたからだ。
ではなぜどうでもよくなったか?
チームで解決して問題そのものを意識することがなくなったからだ

「どうすれば自転車にうまく乗れるようになるか」という問題は小学生の私の頭を悩ますことはあってもいまの私の頭を悩ませることはない。
「自転車にはすでに当たり前のように乗れる」からだ。

ということで過去に興味関心を持ったトピックについてここにつらつらと書いていく
ここで書くのは私がプライベートチームをリードする上で考えていたトピックだ。
あのチームではゲームを開発し販売している。
リーダーとしての私の興味の移り変わりの傾向をみると面白い

興味の移り変わりの傾向

最初はチームの中のことを考えている。
しかしチームの開発がうまく回り始めると次にプロダクトのことを考え始めた
次にプロダクトが一定の機能と品質を備え始めると、プロダクトをどう売るかという点に興味が移っている
プロダクトの売上が順調に伸びると、今度は販売数を伸ばすためのユーザーへの訴求と、訴求する機能開発のために有限な開発リソースの機能開発への効率的な運用を考え始めている。

最初はチームの中のことだけ考えていたが、次第に興味がユーザーに見せるプロダクトに移り、次にユーザーに見せるプロダクトを販売するチャンネルに移り、さらに販売チャンネルの向こうにいるユーザーに興味が移っている。
興味が自分の半径3mのことからだんだん視野が広がり、ユーザーの方向に近づいて行っている。

過去のトピック

メンバー募集

プロダクトを作るためのメンバーを集めたかった
この時点でゲーム制作というプランは持っていた
一人ではスキルに問題がありそうだったので複数人で作ろうと思った。

「ユーザーに使ってもらえるプロダクト」を作りたいメンバーを募集した。
募集要項は「自分1人でもプロダクトを作れる」メンバーを募った。
報酬やコミットを求めるもの、かたち、制約条件やチームの最終目標、解散条件などを定めた。

プロダクトの青写真

このプロダクトはなにをウリにするのか
どの指標を重視するのか(販売数?メンバーの満足?技術的冒険?)
販売数を重視するならどのジャンル、どの形態、どういう売り方をするのか?それは販売数かどれだけ見込めるのか?
どのセグメントに対してどの販売チャネルで売ってどれくらいの販売数を目指すのか?
などなどの企画検討を行った。
インセプションデッキやビジネスモデルキャンバスが作れる程度の練り込みは行った。
ここで固めたビジョンはあとあとかなり役に立った。

チームビルド

各メンバーのスキルセットの確認、なにを目指すか、完成時、あるいは各自の「取り分」をどうするかなどの検討
モチベーションの設定、役割分担、そのほかもろもろを決めた
チームとしてメンバーが機能し始めるまで、あるいはチームとしてのプロダクト開発が機能するまでのフローが固まっていく過程をうまくマネジメントした。

コミュニケーションコストの調整

直接会うのは週1回くらいで残りはチャットや通話頼みのため、できるだけコミュニケーションコストが重くならない方向を手探りで探した。
基本的に「ツーカーの仲」になれば多くの言葉はいらない。なのでハイレベルなコンテクストの共有を志向し実現した。
権限の委譲と委任方式、命令の意図の共有などのプラクティスが有効に機能した。

ファーストリリース

完成させたプロダクトをユーザーに有償で配布し、
「はたして自分たちのプロダクトは完成するのか」
「リリースしたプロダクトは有償で購入してもらえるのか」
などの検証を行った

フィードバックの取り込み

リリースするたびに自己変革するチーム作りを目指した
「ユーザーからの声の評価とタスクリストへの反映」
「チーム内のプラクティスの修正」
「数値目標の設定と実行後の数値の評価、分析」
の3つに分けて、リリースのたびにチームが自己成長できる体制を整えた。

プロダクトの「完成」

セーブ機能やエンディングなど「プロダクトとしてあって当たり前」の十分品質の達成を目指した。
実際には欲をいうときりがないため、十分品質とみなされるものに優先度をつけ、上から実装して行った。
最終的に予定機能は修羅場進行があったものの完成した

販売チャンネルの拡大その1

チームとプロダクトの最優先指標は販売数。
販売数を確保するためには販売力がもっとも強い(と当時は思われた)最大手の販売チャンネルへの進出がもっとも有効と思われていた。
しかし、「売れない製品」は最大手の販売チャンネルでは相手にしてもらえないため、販売実績を作る必要があった。
そこで販売力は弱いが比較的間口の広い販売チャンネルであるダウンロード販売に進出した。
拡大したダウンロード販売チャンネルを販売量の3割を占める主要チャンネルに成長させた。

製品機能の拡充

大失敗トピックその1
やりたいことを全部やろうとしたせいで開発予定機能が肥大化。
実際の開発進行が納期に間に合わず、予定リリース機能の半分のリリースになった。
これ以降は優先度をつけたリリースと、開発対象の集中と重点化(Focus)が重視されるようになった。

リリースサイクルの小型化

大失敗トピックその2
リリースサイクルの小型化による頻繁なリリースを狙ったが、実際にはリリース前の準備のコストがリソースを食いつぶし、制作コストにまわすリソースが減少した。
頻繁なリリースはフォローしてくれるユーザーにも細かい購入を強要させた。
開発チームもファンも疲弊させたため、この方針は放棄された。

頻繁なリリースとそれにともなう細かい頻繁な製品のチェックとフィードバックの取得、という方針は間違っていなかった。
そのため、頻繁に内部向けのクローズドなインバウンドリリースを行うことは継続された。
一方、製品の一般リリース(アウトバウンドリリース)はある程度の間隔(8週間以上)の期間を空けて行う方針になった。

販売力強化

プロダクトそのものの販売力を高めるためにチーム外の人間とスポットで契約し支援を受けることにした。
パッケージデザインやユーザー分析ノウハウなどの供給を有償で依頼した。
プロダクトの制作コストは跳ね上がったが、販売力の高いプロダクトは値上げしても販売数を確保できると考えた。
実際には値上げしたにもかかわらず、販売数は伸びたため制作コストの高騰は十分ペイできた。

プロダクトの洗練

プロダクトの販売数の増加に伴い、企画面での見直しを時間とコストをかけて行った。
いままでの「初期の方針に伴ったなんとなく」の開発から「奪うことは楽しい」をコンセプトに、戦略目標の設定と作戦計画の策定をおこない、それに基づいたキャッチコピーの打ち出しや訴求ポイントの練り込みを行った。

ここで定めたプロダクトの方針性の一貫性と差別化、特色の明確化があとあとの販売数の急速な伸びにつながったと分析されている。

販売チャンネルの拡大その2

最大手の販売チャンネルへの進出を行い、販売数の拡大を行う。
チームとプロダクトにとって販売数は最重要指標なので、ここは重要な道程だった。

過去実績を鑑み販売チャンネルとの交渉は、最初は絞った数の取り扱いだったが在庫が十分さばけたことで次第に取り扱い数が増えた。
拡大した新販売チャンネルを販売量の5割を占める主要チャンネルに成長させた。
これに伴い販売数を2倍に増やせた。

チームの拡大

大失敗トピックその3
要求開発量の増大に対応させるためにメンバーの数を増やした。
指揮統制インフラの拡充とチーム戦態勢の整備、権限委譲の幅の拡大を行った。
結局コミュニケーションコストやエントロピーの増大により、コストとリスクがリターンに見合わないとして方針は放棄された。

開発効率の向上

前述のチーム拡大の方針を放棄し、少人数による高速進行に切り替えた。
「スイッチ」の考え方、「襲歩進行」プラクティスの採用などにより単位リソースあたりの開発速度を半年で3倍に高速化させた。
前回のチームの拡大で整備した指揮統制インフラや権限委譲が効率向上に大きな役割を果たした。
KPTを高い質で継続できたことで、メンバーの作業を「止める」or「低速化」させる場所がわかっていたことでそこに対応するだけで済んだ。

販売チャンネルの拡大その3

DL販売最大シェアを誇る販売チャンネル2つへの進出を行う。
予想販売数が最も伸びやすいチャンネルであるため製品の質が高まるまで温存していたが、十分に高まったと判断したため投入を決断した。
(1,000本販売できるはずのチャンネルで焦って投入して、ユーザーに「この程度」と見切られて100本が販売数のキャップになるという事態を回避したかった)

結果は販売交渉の難易度は高くないと予想していたが交渉は問題なく通った。
事前のもっとも高い販売数予測の1.5倍の販売実数が出た。
販売量も全体の4割を占める主要チャンネルに成長させた。

サンクコストの減少

施策の当たる確率=「打率」の上昇と失敗施策の損切りタイミングの早期化
クソみたいな施策を無駄なく素早く効率良く作っても意味がない。
リターンがほぼゼロだからだ。
当たらない施策を作り始める前に減らそうとしたり、撤退開始するタイミングを早くして損切りを素早く始められるようにした。

ドメイン理解とユーザー分析である程度打率を上げることはできた。
ただし「失敗施策の撲滅」はできない。絶対に。未来予知か全智の能力がない限りは。
だから撤退開始を早く始められるよう判断材料の指標の高精度化と速報化を進めた。
速報化と高精度化は背反するが、そのあたりはトレードオフで考えた。

プロダクトデザイン

ゲームのレベルデザインの考え方とユーザーフェーズの変化の考え方を取り入れてプロダクトやサービス全体をデザインしましょうという考え方。
大事なのは心理学の広範な理解。浅く広くでいい。
Hookedとか心理社会学の本とかをよく読んだ。FBI捜査官の異常犯罪と人間の欲求の関連性の本はプロダクト設計にブレイクスルーを与えたが他人に奨めたいとは思わない。SAN値が削れたから。
最も重要なのは心理歴史学だと思う。

セグメントの拡大

販売数の拡大を考える上で、訴求セグメントの取りやすいユーザーはすでに取ってしまった、伸びが鈍化していると判断した。
そのためアーリーマジョリティを対象セグメントに含めるために、購買までに、より敷居を引き下げるための戦術アクションを取る。
訴求セグメントに含まれるユーザー数が増えるため、販売数の増加が見込まれる。
販売チャンネルの拡大は十分に行えている(販売チャンネルのシェア合計が9割を超えている)ため、セグメント拡大が有効に機能するタイミングと判断した。

5
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?