下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

プロダクトマネジメントと事業開発に関する私的な振り返り

TL;DR

試行錯誤の瓦礫の記録です。

はじめに

もくじ

以前書いた記事

前提・免責

  • 複数案件を経ての感想です。特定の案件に限定した話はしていません。
  • 一般的な方法論の解説ではなく、筆者個人の私的な振り返りです。自分の考え方のクセを矯正するために書いています。
  • バイアスがあります。担当案件の多くは「BtoB・BtoBtoC」「Web・Mobileサービス」「0→1立ち上げ」「開発者〜10人」「私費・社内予算」「複数会社の協業体制」でした。
  • 世の資料を読み漁っていると「マーケティングや財務の責任者はプロダクトマネージャーとは別にいる」とか「事業開発は非連続の成長を目指すものであって製品の細部調整ではない」とか、色々と書かれているのですが、本稿では特にスコープを定義しません。全て自分の責任範囲として捉えます。
  • 本稿は筆者個人の見解に基づく内容であり、関係組織を代表するものではありません。不適切・考慮不足だと感じさせてしまう点があれば、それは筆者個人の責任によるものです。どうぞ筆者個人宛てにご指摘のコメントをいただけますと幸いです。
  • 100,000字になってしまいました。さすがに弊害が多いので、超長文を一気に書くのは、これで最後にします。

アイデア

1日1案(やってよかったこと)

新卒入社初日から1日1つアイデアを出し続けた。 手持ちのアイデアは1,000を超えている。 無限にアイデアを出せるようになった。

ただ、この取り組みは他人に勧めない。 アイデア自体には価値がないし、自分でアイデアを出す必要もない。

自分にとっては3つの点で有益だった。

1つ目は日常のちょっとした発見や会話から事業案を出せるようになったこと。 条件反射で「こういうサービスが出来るのではないか」と思いつく。 この脳内回路ができると、意図してアイデアを考える必要がなくなる。

2つ目はアイデアを出す行為に執着しなくなったこと。 1,000以上のアイデアを持っていても、成功できるわけではない。 1つのアイデアを実現するほうがずっと価値がある。 だから「いかにアイデアを実現するか」を考えることに時間を使うのがBetter。 そう思い知ることができた。

3つ目はアイデアの内容に執着しなくなったこと。 アイデアは無限にあるから「絶対にこのアイデアを周囲に認めさせてやる!」と考える必要はない。 もっと柔軟に「周囲に売れるアイデアはどれだろう?」を確かめればOK。 リサーチや技術検証を通して「当初の案よりこっちのほうが良さそうだ」と思ったら、方向転換すればOK。 自意識ではなく、顧客や市場に向き合うほうがBetter。 そう思い知ることができた。

「これ以上アイデアを模索しても仕方ない」と思えるくらい、アイデアを考えたからこそ、もっと大事なことに気付けるようになったと思う。 過去の自分はアイデアに恋して空回りをしていた。 今の自分はアイデアと適切な距離感を保ち、検証プロセスを着実に進められていると思う。 そういった意味では、1歩だけ前進できた。

1stスクリーニング(やってよかったこと)

検証する価値のあるアイデアかどうか、は以下で判断している。

  1. お金や時間を割いてくれる顧客候補が思い浮かぶか。
  2. 友人や家族に話したときに、自分のテンションが上がるか。
  3. 3年後に「この市場で1位を取れた理由」を聞かれときに、答えられるか。
  4. 3年後を想像したときに、周りの人たちがサービスを使ってくれているか。
  5. 変わらないもの(ジョブ)を説明できるか。リプレイスする時間・予算を説明できるか。
  6. 変わるもの(PEST)を説明できるか。このタイミングで参入する必然性を説明できるか。
  7. 市場ポテンシャル(単価 x 顧客数)が自分の期待水準を超えるか。

これらは全部テキスト1行ずつで書き出せば十分だった。 それだけでスクリーニングできる。 1,000のアイデアがあっても、スクリーニングで生き残るのは、せいぜい1桁しかない。

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

コミュニケーション

チームへのリスペクト(やってよかったこと)

チームを組むとマジで凄い。 1人の意思を超えた力が発揮される。 自分が本気で打ち込めば打ち込むほど、自分1人では出来ないことが沢山あったと気付き、チームの凄さに気付き、メンバーへのリスペクトが生じる。 このリスペクトは今後も常に持っていたい。

これまでの自分は「まぁ自分1人が本気を出せば何とかなるからな」と思っていた。 だけど、自分とは違う人に対して製品を売るのだから、自分とは違う人の視点は絶対に必要になる。 チームメイト(自分とは違う人)の意見を聞きながら企画を磨き込めること自体が奇跡的な体験だと思う。 改めて振り返ると「この発見はターニングポイントだ」と思えるような発見が毎日のように起きていた。 これは体験しないと理解できなかったと思う。

話す <<< 聞く(改善余地あり)

全方位へのインタビューこそがPdMの1番の仕事。

  • 顧客との会話。メンバーとの会話。ステークホルダーとの会話。取引先との会話。
  • 話を聞きながら、判断材料を集めて、意思決定して、仕事を進めていく。
  • チームでの会議も、PdM(私)にとっては「ミーティング」ではなく「チームメイトへのインタビュー」と呼ぶのが正しいかも。

背景:

  • とにかく見る範囲が広い。
    • 財務、UI、仕様、開発スケジュール、顧客サポート、契約書etc。
    • どこかで何かしらのリスクは抱えている&問題は起きる。
  • 自分の頭で考えても、問題を上手く処理できない。
    • そもそも適切な情報が手元にあるなら悩まない。
    • 情報収集と意思決定を間違ってしまうと、さらなるリスク&問題が降り掛かってくる。
    • 自分1人で考える場合「脳内情報が古い」「知識が不正確」「1人の視点にとらわれている」のいずれかによって、判断を間違える。
  • 個人差はあると思うが、私は毎日死ぬほど不安になる。
    • 不安は伝染する。不安な人の話を、毎日ミーティングで聞いたら、周りも不安になってくる。チームのコンディションに影響する。
    • 伸るか反るかのピークでは、お腹がめちゃくちゃ痛くなる。週3で正露丸。この心理状態と上手く付き合わないといけない。

改善余地:

  • メンバーと一緒に問題を整理する。
    • 不安の背景にある問題を整理して、一緒に問題と1つ1つ向き合う。
    • 整理できていないことは整理してから話す。先走らない。
    • 整理するために、必要な情報を集める。
    • 北風ではなく太陽。一緒に情報を整理すると、自然と次のアクションが見えてくるので、それをお願いする。
  • ミーティングは基本的に情報収集。話を聞く。
    • とにかく「話すこと」よりも「聞くこと」を心掛ける。口は1つだけど、耳は2つある。
    • 自分の頭で考えるのではなく、情報を仕入れて、現実的な解に寄せる。
    • なるべく「最新」「正確」「多様な視点」の情報を仕入れる。
    • 大抵の問題は「思考」では解決しない。「現状」と「制約」を把握すれば選択肢は絞られる。
    • 「負けるビジョン」を消していくと「勝てるビジョン」に辿り着く。
  • メンバーとの1on1を避ける。少なくとも2on1にする。
    • 私が何かを伝えるのではなく、2人が話すのを私が聞く場にする。
    • 私の不安まみれの情報を伝えても事態は変化しない。ほどほどの自己開示はOK。
    • メンバーが持っている情報(進捗・課題・気付き・意見・感情)には、問題検知・問題解決のヒントがある。
  • Slackに各自のtimesチャンネルを作ってもらう。
    • 何をやっているか、何を思っているか、の雰囲気を察することができる。
    • 無理にコメントやリアクションをしなくてもOK。
    • プレッシャーになる場合があるので、ミーティング時に本人から相談がなければ、無理に「困っていたけど大丈夫でしたか」と聞かなくてもOK。
  • 不安に負けないメンタルを作る。
    • 「長期的にポジティブ・短期的にネガティブ」な思考スタイルになりたい。
      • 電通鬼十則「計画を持て、長期の計画を持っていれば、忍耐と工夫と、そして正しい努力と希望が生まれる。」
      • 財務計画の策定時に十分なランウェイを確保することが前提になると思っている(後述)。
    • 気持ちを切り替えるためのルーティーンを習得する。後述。

備考:

  • 自分の作業をゼロにして、インタビューと意思決定に専念できたら(私が個人的に好きな)戦略マネジメントゲームの体験に近くなりそう。
  • そこを目指したい気持ちがある。

「聞く力」こそが最強の武器である

「聞く力」こそが最強の武器である

  • 作者:國武大紀
  • 発売日: 2018/12/16
  • メディア: Kindle版

即決する(やってよかったこと)

  • その日のうちに返信する。待ちを発生させない。
  • ボールを持ち続けない。依頼された作業はその場で完了させる。
  • メールやチャットを開けるチャンスが少ないので、見たら5分で返すつもりでいる。
  • 意思決定に1分以上を費やさない。その場で決める。

なぜこれが大事か?

  • 待ってもらっている時間が無駄だから。
  • いくらお金を積んでも、いくら大人数に協力してもらっても、いくら高性能なツールを導入しても、自分の返信が遅いと何も進まないから。

判断が間違っていたらどうするの?

  • 間違った場合は軌道修正する。
  • 落ち込む必要はない。判断ミスを恐れてスローペースになってしまうのが、一番のミス。そのミスは防げている。
  • すぐに頭を切り替える。過ぎてしまったことを引きずると二次災害が起きる。
  • 軌道修正が完了したら、30分間で反省会。どういう情報が意思決定に必要だったのかを振り返る。再発防止のために各種テンプレートに反映する。

すぐに意思決定できないケース①「情報が足りない」

  • 意思決定の情報が不足している場合は、その情報を持っている人にすぐ連絡する。
  • 関係者全員をCCに含めておく。全員が回答を確認できるようにする。
  • 問い合わせる際に「回答が◯◯であれば(条件)」「△△なので(理由)」「□□を行う(決定事項)」と数パターンの未来を決めておく。
  • 「◯◯ですよ」と返信してもらったら、事前に決めたように「それでは□□で進めますね」とメンバーに自主判断してもらう。
  • 想定外のパターンだった場合は、急いで集まって会話する。

すぐに意思決定できないケース②「情報が整理できていない」

  • 30分の分科会をセッティングする。
  • 事前に毎日ミーティング枠を確保しておくと、慌てなくて済む。
  • ホワイトボードに書き出しながら整理する。
  • 情報を整理する過程で「①情報が足りない」点が多々見つかるので、すぐ連絡する。
  • 「後で私が整理しておきますね」よりも、さっさと集まって話したほうが、その問題単体の解決にとってはGood。

すぐに意思決定できないケース③「失敗時のダメージが大きい」

  • 例1.法令違反になっていないか?
  • 例2.広報文に差別表現が含まれていないか?
  • 例3.システムリリースで主要機能にデグレが起きていないか?
  • リーガル、広報、QAといったチェック体制を組んで、週30分のミーティングで相談する。
  • 「◯曜日のミーティングで△△さんに聞いてOKなら□□しましょう」という結論を1分で出す。
  • チェック担当には「新情報は◯◯で(差分)、△△なので(意図)、□□を行う(やりたいこと)」を伝える。
  • 指摘コメントをもらったら、その場で「ではどうしたらいいか」を一緒に決める。
    • 「持ち帰って検討する」だと、また1週間が空いてしまうので、レビュアーがいるうちに結論を出す。
  • 指摘コメントをもとに、セルフチェックリストを充実させていく。
    • 1度教えてもらった観点については、フルタイムのメンバーがセルフチェックできるようにする。
    • 1週間後の専門家ミーティングを待つ必要がなくなる。

最高のリーダーは2分で決める

最高のリーダーは2分で決める

自分で各論まで見る(やってよかったこと)

自分で、全ての領域について、各論まで見る。

OKの例

  • ソースコード1行についての相談でも「開発メンバー内で解決してほしい」とは言わずに、自分なりに相談に乗る→OK
  • 『3分間コーチ』のように1日3分だけでも1人1人と会話して次のアクションを一緒に考える→OK
  • メンバーが作業を完遂できなかった場合は自分が巻き取るつもりで作業内容を把握しておく→OK

NGの例

  • ソースコード1行1行について指示を出す→NG
  • メンバーにお任せした仕事を確認日前に自分が巻き取る→NG
  • 専門家と企画職の目線が対立したときに企画職の言い分を優先する→NG
  • メンバーへの期待水準と実情にギャップがある場合に見て見ぬ振りをする→NG
  • メンバーが(自分には相談できているが)他のメンバーに相談できていない状況を放置する→NG

なぜこれが大事か?:

各論までコミットして、要求事項を細かく言語化して、そこで初めてメンバーに意図が伝わる。 その過程で当初計画の矛盾や問題点に気付くこともある。 各論を積み重ねることでしか、製品・事業は立ち上がらない。

各論まで見るのは大変だ。 だからこそ、本気度が周りにも伝わって、徐々に周りも力を貸してくれる。 結果的に周りを信頼できるようになって、任せられるようになる。 人を信じるとか、人に任せるというのは、自分が本気であることが前提だ。 他人を変えることは出来ないけど、自分を変えることは出来る。

これまでの自分は「人に任せる」という言い訳をして、各論から目を背けていた。 上司の曖昧な指示を元に最高の結果を出すのが部下力。 クライアントの曖昧な要望を元に最高の結果を出すのがプロフェッショナル。 そう思っていた。 しかし、それは部下や受注者のスタンスであって、上司や発注者がその前提で動くのはダメ。 自分が言語化できていないことを、他人に丸投げして、作業してもらって、理想の結果に辿り着こうというのは、さすがに無理がある。

ユニクロの柳井さんはIT部門の細かいところまで口を出しているらしい。 本当かどうかは知らない。 ただ、私個人に照らし合わせたときに、感銘を受けた。 少なくともユニクロの規模になるまでは、つまりほとんどのケースでは、各論にコミットしたいと思った。

発散→収束でディスカッション(改善余地あり)

  • 企画=仮説=間違っている可能性がある=リスク。
    • 検証できるものは検証しておく。
    • 例:机上の思考実験、インタビュー、ファクトチェック、お試し実装。
  • 全てを洗い出す。
    • 問「誰の課題を解決するのか?」
    • 考えられる対象セグメントを全て洗い出す。
    • そこからターゲットを絞り込む。
  • ウォークスルーを何度も行う。
    • やり直す度に「あれ?ここどうなったんだっけ?」とか「ここ矛盾してね?」というポイントが出てくる。
    • 論点を行ったり来たりするのに、思っていた以上の時間・労力・金額が必要になる。
    • 数画面のWEBサイトだと、毎日検討しても、仕様を7〜8割まとめるのに約2週間。残りの2〜3割を埋めるのに追加で1ヶ月。
    • 頭の使いすぎで発狂しそうになる。
  • どんどん色々な人と話す。
    • インタビューや事業説明を行うと、その度に擬似的にウォークスルーができる。
    • UIプロトを見せたり、ターゲットセグメントについて相談したり。
    • 話しているうちに「これってどうだっけ?」と自分で気付いたり、「こういう場合もあるよね」と助言してもらえる。

なぜこれが大事か?:

  • 後から「そういえばこの場合はどうだろう」といった議論が出てこないようにするため。頻繁に議論がひっくり返ると、収集がつかなくなる。
  • 開発がスタートしたら10倍の人数と10倍の時間が掛かるので、机上シミュレーションで先に直せるなら100倍マシ。

改善余地:

  • そうは言っても、事前に潰せるリスクには限界がある。その後の「どうにかするパワー」のほうが重要かも。むしろそっちが必要か。
  • また、リスクを丁寧に潰すチームよりも、ある程度は決め打ちでアクセルを踏むチームのほうが、結果として早く目的を達成できたりする。それも必要か。
  • それはそれとしてロジカルに議論を進めていくパワーも自分に必要か。

シリアル起業家のすごいところって、予言能力が高いんじゃなくて”修正する力”なんだと思います。 僕らも例えば事業をやるときに、全部自分の言ってることが当たるなんて思ってない。実験的に試して試して、違ったらこう決める、合ってたらこう決めるっていうその連続的に意思決定してるんです。

【福島良典】極めたものを捨て去る「覚悟」に投資したい

リスクとシェアの話っていうのは、事業が成立することを優先するか、事業が大きくなることを優先するかの明確にトレードオフがある話。事業の成立確度を上げるっていう話と、事業のシェアを上げるって話はトレードオフにあるって話ですね。

リスクとシェアの話

会社を立ち上げるということは、あらゆる会社と競争をするということです。だから、ユーザーの求めることや、稼ぎ方、プロダクトの広め方、成長性が全部明らかになったタイミングでアクセルを踏むのでは遅いんです。その時点でもう、競争に負けているんですよね。

スタートアップがアクセルを踏むべきなのは、もっと不完全な段階です。他のサービスで改善できないユーザーの課題があって、考えたロジックが確かかすら分からない段階でプロトタイプを作り、それをユーザーに使ってもらう。それで「このタスクが楽になった」「こういう課題が解決できた」となった、その瞬間に踏むべきです。このタイミングがすごく大事。

【LayerX CEO福島良典】2度の起業から見えた「スタートアップが勝つための鉄則」 - エンジニアtype | 転職type

イラストで話す(改善余地あり)

なるべく iPad + Apple Pencil で図を書いている。

  • 1人で書けばOKの内容については、iPadのnote shelf 2で絵を書く → Slackで相手に送る or AirDropで自分のPCに送って適切な場所に投稿。
  • 複数人で一緒に書く場合はGoogle Meetで会議を行う → Google Jamboard を開く → MacとiPadをAirPlayで同期 → iPad + Apple Pencil で書き込む。

なぜこれが大事か?:

  • テキストより図のほうが早く正確に伝わる。
  • 複雑な仕様については、チャットの文章だと伝わらないし、ミーティングの音声・ジェスチャーでも伝わらない。
  • 画面については、ビジュアルがないと無理。ワイヤーフレームっぽいものを手書きで渡せば一瞬で伝わる。

改善余地:

  • オフィスでホワイトボードを囲む体験のほうが圧倒的に良かった。今の方法だとタイムラグがもどかしい。
  • iPadから直接共有できないパターンが面倒臭い。
  • Jamboardはまだ使い慣れていない。将来的に使い慣れている自信がない。使いにくくないですか。

日次ミーティング(やってよかったこと)

  • 毎日10分でも相談できる場があると何かと話が早い。
  • いちいちカレンダーを調整せずに話せる場があると進めやすい。
  • 後述する契約形態によっては週次や月次でも良いと思う。
    • 月10万円のリモート副業でITインフラの構築・運用を自動化してくれる開発者とか。
  • 本来の狙いではないが、人によっては毎日チェックしたほうが進捗を出してくれる。
    • いちいちチェックせずともチケットを次々と更新してくれる人や、進捗があるたびにレポートしてくれる人は問題ない。
    • そういう人たちは、定例ミーティングがあろうがなかろうが、決めた時間に、決めた場所で、決めた作業をして、安定してアウトプットを出してくれる。
    • そうでない人も大勢いる。プロフェッショナルとしての習慣を確立している人材はむしろ少数派。
    • 基本的にはチェックポイントを頻繁に設けておいたほうが安全と言える。

議事録を書く(改善余地あり)

例1 例2
f:id:yuzutas0:20210327113305p:plain:w160 f:id:yuzutas0:20210327114004p:plain:w160
  • Google Docsに議事録を書きながらミーティングを行う。
  • 毎日・毎週・毎月に話す議題は、定常議題としてコピペできるようにする。
  • 関連資料のURLは多めに張っておいて、探す手間を省く。

なぜこれが大事か?

  • ドキュメンテーションを残すことは、テレワーク時代におけるコミュニケーションの基礎だと思う。
  • 未来の自分の記憶力を信用しない → 確認できるようにする。
  • その会議に参加していなかったメンバー → 確認できるようにする。
  • 後から参加したメンバー → 過去の経緯を調査できるようにする。

改善余地①:私の文章は読みにくい。

  • 形容詞を付けないとか、文を短くするとか、頭では知っているが、定着していない。
  • 文章力講座を受講して、赤ペン指導を受けたほうが良いのだろうか。

改善余地②:幹と枝葉。

  • 私の議事録は「枝葉」を記載しがちだ。まさにこの文章がそうなのだが……。
  • 議事録では「幹」に絞ったほうが、書きやすく、読みやすいのではないか。①と関連するだろう。
  • 議事録における「幹」とは、議題・論点・選択肢・結論・根拠・宿題、を指すと思う。

得た情報を共有する(改善余地あり)

万能な人は存在しないので、少しでもBetterな成果が出るように、自分が得た情報をチームに還元する。

例:他社デザイナーに「アクセシビリティに配慮するとBetter」と助言してもらった。 参考として以下の記事を紹介してもらった。 この記事をチームメンバーに共有して、アクセシビリティについて、どういう優先順位で扱えば良いのかを相談した。

なぜこれが大事か?:

外部の専門家の知見を、社内の専門家に繋げることで、レバレッジを効かせられるから。

最初は悩ましかった。 他の専門家のコメントを、自チームの専門家に渡すことは、Goodなのか、Badなのか、分からなかった。

「アクセシビリティよろしく!」とメンバーに一方的に押し付けるのは、ナンセンスだと思う。 計画は一度合意されて、既に作業が進んでいるのに、急に要件を増やされても困るだろう。 「検討から漏れているから対応したい!」と言えば「でもその計画に合意したのはお前じゃないか!」と言われてしまうだろう。

理想を言うと、一緒に仕事を行うメンバーには、自分なりのチェックリストを持っていてほしい。 以下は @r1ccha さんがPR担当として着任直後にやることリストだそうだ。 これこそがプロフェッショナルの仕事だと思う。

しかし、現実的な問題として、そこまで出来る人は多くない。 この水準を前提にしてプロジェクトを進めるのは筋違いだ。 完璧なリストは手元にない、という前提で進めないといけない。

では、担当者が最初に思い付いた範囲内で仕事を進めればOKなのか。 アクセシビリティについては聞かなかったことにしておけばOKなのか。 それは違うと思う。 妥協はユーザーに伝わる。 ユーザーからの信頼を損ねる。 最高のプロダクトを作らないといけない。 改善余地に気付いたら、無視してはいけない。

なので、結論としては「こういう話を聞きました」「優先順位を相談させてください」が落とし所なのだと思う。 そして、チームで仕事をする中で、徐々にテンプレートを埋めていくのが良いだろう。

想定納期を示す(改善余地あり)

何かの作業を依頼するときには、Must・Wantの想定納期を提示する。

なぜこれが大事か?:

もともと私は「納期」という概念はクソだと思っていた。 依頼者視点では、納期が短すぎたら文句を言われるし、納期が長すぎたら納期ギリギリまで作業が完了しない(パーキンソンの法則)。 だったら、最初から納期ではなく見積もりを元に会話したい。 「◯◯日を目安に進めますね」「まずは1週間ほど検討した後にスケジュールを相談しますね」と宣言してもらえたほうが、お互いにラクだ。 自分が案件を受注するときには、納期ではなく見積もりで話をしていた。

しかし、残念ながら「納期」があったほうが動ける人は多いように思う。 見積もりを依頼すると「やってみないと分かりません」「正確に見積もるためには◯ヶ月が必要です」と反応する人が一定数存在した。 かといって期限を設定しないと、延々とタスクを終えないままで、週次定例で「進捗なし」としか言わなかったりする。 そういう人たちには「◯◯日を目安にお願いします」と言ってしまったほうが、何かと話は早かった。

見積もりで会話できる相手なのか、納期を提示したほうが良い相手なのか、によって適切なコミュニケーションが変わる。 いちいち探るのも面倒なので、想定納期を示すようにしている。 同じ人とは徐々に見積もりで会話するようにシフトしたいが、切り替えてしばらくすると進捗が悪くなったりするので、どうしたものか悩ましい。

a

カレンダー招待&日程確約コメントを転記(改善余地あり)

自分の人生で最大級の失敗の1つが、Gunosyのメンバーたちとの飲み会で、2時間の遅刻をしたこと。 あれは今でも覚えている。 それ以降、Gunosy関係者からの依頼は、些細なことでも絶対に断らないようにしている。 本当に申し訳なかったと思っている。

なぜか予定日の翌日にカレンダーを入れていて「今日の仕事は終わりだ!」と爆睡して、メッセージに気づかなかった。 同じように「カレンダーの日程が1日ずれている」「1時間だけずれている」といったミスが、年に1回ほど起きる。 過去の失敗を振り返ると、ミーティングを一気に入れる時は、勘違いで設定ミスをしているようだった。

社外の人たちとミーティングやインタビューを実施する機会が増えた。 一気に10人のアポを取ったとき、念のため、messengerからGoogleCalendarに日程確約コメントをコピペした。 「それでは◯◯日の◯◯曜日でお願いします」といった文章だ。 すると、10件中2件で、設定が間違っていた。 チェックして本当によかった。 ということで、ダブルチェックとして、日程確約コメントをカレンダーに貼り付けることにした。

また、相手がGoogleアカウントを使っている場合は、カレンダーに招待を送っている。 勘違いしていたら指摘してもらえるだろうと期待している。

改善余地:

「日程確約コメントをカレンダーに貼り付けることにした」と書いたが、そこまで出来ていないような……。

プロセス管理

仮説検証シートを書く(やったけど不要だったかも)

以下のような検証プランをGoogleDocsに記載した。

  • 「How much / いくらで」検証するのか。
    • 後述のコスト管理シートと同期させた。
    • 改善余地:コスト管理シートに改善余地がある。
    • 改善余地:検証にもフェーズがあるのではないか。どの検証フェーズで何円使うのか。
    • 改善余地:予算ありきで進めた感はある。それはそれで良いのかもしれないが。
  • 「When / いつまでに」検証するのか
    • 後述のWBSと同期させた。
    • 改善余地:WBSに改善余地がある。
    • 改善余地:2ヶ月とか3ヶ月とか期間ありきで進めた感はある。それはそれで良いのかもしれないが。
  • 「What / 何を」検証するのか
    • 後述のコンセプト案をもとにエレベータピッチのように項目を書き出す。
    • 例:◯◯が◯◯できる◯◯とは◯◯である
      • 買い手が
      • 安心して購入できる
      • ECサイトとは
      • 実物の写真が豊富に掲載されていることである
    • 項目から検証ポイントを洗い出す
      • 本当に? / 実物の写真を見せたら買ってもらえるのか?
      • 具体的には? / 何のECサイト?
      • 具体的には? / どういう写真?
    • 顧客行動フローを図示する
      • ◯◯を見て◯◯が欲しい
      • Google検索
      • ◯◯の記事を読む
      • リンクを踏んでECサイトに訪問
      • ECサイトで◯◯を見比べる
      • 購入する
      • 郵便物が届く
      • ◯◯を使って◯◯だと喜ぶ
    • 検証ポイントを洗い出す
      • 顧客は何をトリガーにしてそのECサイトに訪れる?
      • 他のECサイトと価格を見比べる?
      • 試しに◯◯で検索したらECサイトではなくレンタルが主流のようだが……
    • 検証ポイントごとの優先順位を定める
  • 「How / どうやって」検証するのか
    • 検証ポイント(論点)ごとに適切な手法をマッピングする
    • 大抵は ①インタビューによる事実確認 ②プロトタイプによるウォークスルーテスト
    • それぞれに掛かる期間・費用を見積もって、優先順位に応じてスコープを決める

やってみたけど、不要だったと思っている。 このフレームワークではないのだろうなと感じている。

欲しかったのは「全体計画」だが、上記はリサーチ計画に終止してしまっている。 「ああでもないこうでもない」とリサーチを行いながら思考実験するのは分かる。 仮説思考でリサーチを進めることは効果的だとは思う。 期間と予算を区切ることにも一定の意味があるとは思う。 お金を持っている人や偉い人が、誰かにリサーチを依頼して、毎週これを聞くなら、納得感がある。

ただ、事業開発プロジェクトで、企画推進者が毎週これを話しても、進んでいる感がなくて、苦しい。 企画が動き始めているのであれば、後述するコンセプトボードを作り始めたほうが良さそう。 その過程でカスタマージャーニーを分析すると、アウトプットが明確なので進めやすそう。 その延長で純粋な事業計画として集客目標やコンバージョン件数目標を置いたほうが良さそう。 その目標を達成するための施策を各領域のプロフェッショナルに相談したほうが良さそう。 検証シートを作らずとも、事業計画を立てて実現する過程で、必然的に仮説検証は進むと思った。

ビジネスデザインシートを書く(やったけど不要だったかも)

リボンモデルとステージゲートを合わせたシート。 「まずはここを攻めてユーザー◯◯人」「次はここを攻めてユーザー◯◯人」といった可視化ができる。 進捗管理・レポーティングに使おうとした。

これは不要だったと思う。 無理に1枚絵にする必要はなかった。

  • ステージゲート:進捗管理ではなく、市場調査・財務計画の意味合いが強い。 将来の展開構想は「ざっくり方針」x「TAM>SAM>SOM」の1枚シート(後述)で済ませて良かった。 「この段階でポテンシャルは◯◯円」を端的に示せば良かった。
  • リボンモデル:進捗管理ではなく、ソリューション検証の意味合いが強い。 登場人物を洗い出し、登場人物ごとのカスタマージャーニーマップを書き、製品全体のグロースサイクル(後述)を描くほうが良い。 無理にリボンで表現せず、再訪問率 or 紹介率を最大化できるように、サイクルに注目するほうが筋が良い。

①10X体験→②10%改善→③内部改善サイクル(改善余地あり)

  • ①まずはWow体験を実現する / 財務目標達成に向けて10XなUX改革を実現する
  • ②その後の改善で市場を刈り取る / VOC(ユーザーの声)をもとに製品や施策を10%磨き込む
  • ③そこまでやってから内部改善する / メンバーの声をもとにオペレーション・アーキテクチャ・チームを改善する

エンジニアチームが内部改善をしている間に、アナリストやデザイナーが次のWowを探索し始める。 初期は【①→②→③】→【①→②→③】→【①→②→③】でサイクルを回して、10倍の成長を繰り返す。

注意点1:最初は人数が少ないので、同じ人が①→②→③→①のサイクルを回す。 一定規模になったら担当者を分けることが多いように思う。 ①機能開発チーム、②UI改善チーム、③アーキ改善チーム、みたいな。

注意点2:財務計画に①②③全ての予算と期間を反映する。 売上を見立てるための「TAM>SAM>SOM」は①をベースに見積もる。 費用を見立てるにあたっては、①の実施だけでなく、②③を含めると、多少は現実的な計画になる。

注意点3:③の後回しを合意する。 特にエンジニアチームは最強のアーキテクチャを作りたくなりがち。 これは難しい問題だよなと思う。 0→1の場合、WEBフロントエンドを作り込んでも「やっぱりLINE Botを中心に開発します」と方向転換する可能性がある。 なので、①②で顧客開発を進めた後に、③でシステムやプロセスを改善して次の①に備える、という順番が妥当なのかなと。 どうしてもということであれば、妥協案としては、毎週何曜日の午前を改善に当てる、といったところか。

改善余地:プロジェクト管理方法。 結果として現実はこうなっているし、私としては誘導しているつもりだけど、明示的にプロジェクト管理できていない。 案件管理の粒度が細かすぎるからだろうか。 五月雨で①②③それぞれの案件チケットが動いてしまっている。 本当はウォーターフォール開発(企画→リリース)を3回(①→②→③)繰り返すようなイメージで案件管理できると良いのかしら。

継続的にユーザーの桁を増やす(改善余地あり)

某ツール開発案件は以下のスピード・ボリュームで進めた。 意図的に無理して垂直立ち上げを行った。

  • 1ヶ月目:資料・デモを作って起案→予算確保。
  • 2ヶ月目:開発会社10社面談→選定→契約。
  • 3ヶ月目:開発スタート→リリース→10名利用。
  • 4ヶ月目:フィードバックを元に改善→50名利用。
  • 5ヶ月目:フィードバックを元に改善→100名利用。
  • 6ヶ月目:フィードバックを元に改善→1,000名利用。

なぜこれが大事か?:

  • 10→100→1000とユーザーの桁が増えると、フィードバックの内容が変わってくる。
  • そのフィードバックをもとに、あるべき仕様を整備していくと、1,000人に使われるものに進化する。
  • 10人でテストすると、10人のための仕様になってしまい、1,000人に当てにくいものになる。
  • 10人が前提の時よりも、1,000人が前提のほうが「どうやってユーザーに届けるか?」「どこが仕様のセンターピンか?」がより鮮明に見えてくる。

よく、プロダクトを出したばっかりなのに、いきなりこんなに人増やすの? こんなマーケティングに突っ込むの? みたいなスタートアップがあるじゃないですか。ああいうのも、それが成功するかどうかじゃなくて、その先を描いた時の一番早いタイミングで決めていないと遅過ぎるんですよ。

引用元:【LayerX CEO福島良典】2度の起業から見えた「スタートアップが勝つための鉄則」 - エンジニアtype | 転職type

改善余地:

  • 要は「サービスのユーザーを増やしたら、ユーザーが増えるサービスになる!」と言っている。
    • トートロジー。
    • そう簡単にユーザーを増やせたら苦労しない。
    • どう増やすかが課題。
  • CVRが低い状態で広告を踏みまくるような覚悟が必要。
    • 一定数の批判が寄せられる。
    • チーム・ステークホルダー・顧客との期待値調整が必要。
    • 企業内プロジェクトだと案件が凍結することもある。その割には短期間・高目標を設定しがち。難しい。

VOC→課題発見→製品発見→製品開発(改善余地あり)

①Wow体験→②10%改善→③内部改善の①②③それぞれについて、以下のような企画フローが流れる。

  • 顧客(③の場合は担当者)のコメントを拾い上げる。Salesは商談時に、CustomerSuccessはオンボーディング支援・問い合わせ対応時に、Analyst・Designer はユーザーインタビュー時に、VOC(顧客の声)リストを追加する。問い合わせメールやインタビュー動画など、なるべく生の声を保存しておくとGood。後から事実確認が容易になり、関係者にも空気感を伝えやすい。
  • 集まったVOCをグルーピングして、課題の因果関係を構造化する。「AとBの意見が多いけど、実はCという共通の問題が背景にあって、そこが最も重要ではないか」といった真因を考察する。必要に応じて該当ユーザーに追加インタビューを行い、事実確認を行う。課題を構造化したら、どこを解消すると最もインパクトがあるか「人数 x 頻度 x CVR」といった軸を設定して分析する。どのくらいの数字まで改善可能かは競合や類似サービスを参考にする。Analyst や Designer がリサーチ・分析を主導する。必要に応じてSales、CustomerSuccess、Developerがサポートに入る。困っている人が誰で、なぜその課題が起きていて、その課題を解くと何がどのくらい嬉しいのか、を課題リストにまとめる。
  • 課題リストを元に解決案を列挙する。解決案は他社事例をTTP(徹底的にパクる)。競合サービスや類似サービスをリサーチする。別の業種・職種についても、成功モデルを抽象化して、自社に当てはめる。このテーマについてはこの企業をベンチマークにする、と決めておくと進めやすい。最も課題解決に貢献できそうな施策を採用する。施策の要件を詰めながら、同時並行でプロトタイプ作成、技術調査、法務やセキュリティ観点でのリスクレビュー、コストの見積もり、販売促進の方法を決める。Designer が仕様策定をリードしつつ、Analyst がインパクトを分析し、Developer、Promoter、Sales、CustomerSuccess、Legal といった各担当が実現性を模索する。調査と擦り合わせを繰り返して、最終的には施策リスト・仕様書にまとめる。
  • 施策リストを元にプロダクト開発や販促施策を進める。開発プロジェクトとしてWBSを引いたり、スプリントバックログに列挙して、タスク消化をバーンダウンチャートで追う。リリース後はサービスレベルが守られているか監視し、課題を発見したら改善施策を講じる。Developerが自身の稼働を最も使う箇所。

改善余地は何か?

  • PdM 1人 + Dev 3人 といった体制を組みがちだった。それは「製品開発」を重視する体制だと言える。しかし「製品開発」の前には「課題発見」「製品発見」がある。各フェーズで専門家のサポートやリサーチへの投資(時間・金額・労力)が必要だった。最初のリサーチに3ヶ月・300万円を費やすことで、その後の1年・数千万円の資本効率が変わる。安易な開発に逃げるのはなく、リサーチのアウトプットを明確にして、資金提供者との週次定例で自信を持ってアップデートを伝えることが、自分には出来ていなかった。
  • 開発(Dev)・運用(Ops)だけではなく、企画フェーズこそDeveloperが必要で、企画フェーズこそWBSやバックログによる管理が必要だと思う。しかしDeveloperには「開発外タスク」として放り出されてしまいがち。説明すると「なるほどOKです」と言ってくださった方もいたので、個人差がありそう。初期フェーズでは「一緒に企画を推進できるか?」は「手が早いか?」と同じくらい重要だと思った。
  • メンバーが少ない初期フェーズでは、PdM自身が、Analyst 兼 Designer 兼 Sales 兼 CustomerSuccess 兼 Developer 兼 Promoter 兼 Legal の役割を担うことになる。反対に、チームが大きくなるほどPdM は(mini)CEOに近づき、自身が手を動かすのではなく、専門家に作業をお願いすることになる。後者にシフトするほどレバレッジが掛かる。成功者は意図的に早い段階で後者に移行しているように思う。自分はまだその成功体験を得ていない。その成功体験を得たい。
  • 全ロールを2-3人xフルタイムで確保する場合、人件費を月100万円で置くと、1ヶ月で1,000万円以上が吹き飛ぶ計算になる。まだ企画さえ詰まっていなくて、売上0円の状況では、この投資を決断できない。ロールによってはパートタイムでお願いして、月1回でサイクルを回すのだろうか。専門知識が必要なところだけ顧問として月10万で専門家にお願いするとか。あるいは、Sales&CustomerSuccess&Analystの箇所は自分で担うのが筋か。ソリューションによってはDesignerやDeveloperの箇所も自分で作るのが良いか。それだと結局はレバレッジが効かないままではないか。分からない。

開発プロセスにUX検証を組み込む(改善余地あり)

背景:

  • ユーザーインタビューやユーザーテストを何となくで実施していた。
  • しかし、とりあえずリリースして、とりあえずコメントをもらって、とりあえず改善していく、はNGだった。
  • 1人月100万円 x 複数人のプロジェクト(=年間で億単位の投資になる体制)だと、金額・労力・期間の面で無駄が多すぎる。

概要:

以下の方法に軌道修正した。

  1. ユースケースシナリオ策定 ↔ユーザーインタビュー(再現可能な解像度で顧客のジョブを把握)
  2. 必要機能・画面遷移・表示項目の洗い出し ↔ユーザーインタビュー(課題を解決できるか机上でウォークスルー)
  3. 概算見積もり+バッファ多め →スケジュールの頭出し
  4. 画面がある場合はUIデザイン ↔ユーザビリティテスト、デモDay
  5. 仕様書にまとめる ↔整合性チェック
  6. 詳細見積もり+バッファ多め →スケジュールの確定
  7. 設計・実装 ↔機能テスト
  8. Stagingリリース ↔モンキーテスト、ユーザビリティテスト、デモDay
  9. Productionリリース ↔利用状況モニタリング、ユーザーインタビュー

ウォーターフォール開発の各フェーズごとにUX観点のテストを挟んで品質を担保する。 設計・コーディングと同じかそれ以上に、思考実験・インタビュー・プロトタイピング・ユーザーテストといった要素が、チームのメインタスクになる。

このUXテストが1回で通ることはない。 100回作り直して、100回手戻りするようなイメージ。 実際にこのフローをやってみたところ、仕様書をFixするまで、毎日数時間 x 1.5ヶ月を費やすことになった。

以下の図を参考にした。

f:id:yuzutas0:20210324134005j:plain

位置付けとしては「①ワオ体験→②磨き込み→③内部改善→①…」のサイクルがあって、 この①②③の各フェーズごとに「VOC→課題発見→製品発見→製品開発」の流れがあって、 その「製品開発」の箇所を、上記のウォーターフォールで進める。 一連のサイクルを何度も繰り返すことで、製品を充実させていく。

補足:

ウォーターフォールがいいとか、アジャイルがいいとか、そういう話ではない。 投資対効果を最大化するためにベストを尽くそう、と言っている。 「何となくリリースしてフィードバックをもとに改善する」では解像度が低いと言っている。 「いつ何をユーザーに当てて、何を検証するのか」を決めたほうが、資本効率が向上するという話。

システム開発要件や人材採用要件でも同じことが言える。 つい「とりあえずやってみて反応を見ながら軌道修正しましょう」と言ってしまいがちだ。 『リーン・スタートアップ』を読み直すと、きちんと仮説の重要性を強調している。 たとえ「まだ仮説でしかない」と思っても「これで行きましょう」と決める勇気が必要だ。 自分が案を提示しなければ、全てが曖昧な状態で模索タイムが始まってしまう。 仮に間違っていても、明確な叩き台があれば、マクドナルド理論でブラッシュアップできる。 それに「この考えは間違っているかも」と思っているのなら、なおさら早くツッコミをもらったり、人と話しながら整理したほうが、早い段階で検証できる。 間違った結論を口に出す勇気が欲しい。

「ゴール仮説」から始める問題解決アプローチ

「ゴール仮説」から始める問題解決アプローチ

  • 作者:佐渡 誠
  • 発売日: 2018/10/15
  • メディア: Kindle版

改善余地:

  • 言っていることは正しいのだけど、毎日ゴリゴリにアップデートしてくる会社と殴り合うときは、本当にこれで勝てるのだろうか、とは思う。
  • 成果物が重複している気がするので、1.ブループリント → 2.要件メモ&UIプロト → 3.簡易見積もり → 4.実装 → 5.リリース くらいに単純化したい。

OKRシートを書く(改善余地あり)

優先事項を絞って、目標達成をトラッキングするためのシート。 チーム全員で毎週チェックする。

  • 現状(攻):高い目標を達成できそうか?期待とのギャップはどこにあるか?
  • 現状(守):A.ユーザーとの関係、B.プロダクトの品質、C.チームの雰囲気はGoodか?期待とのギャップはどこにあるか?
    • 依存関係がある。C.チームが険悪だと、B.プロダクトの品質が悪化する。B.プロダクトが不調だと、A.ユーザーとの関係も悪化する
  • 打ち手:今週中に問題を解消するために何を優先するか?

まだ改善余地がある。 というか、正直なところ、どうしたら良いのか悩ましい。

1:全体のシートと、チーム別シートとで、階層化したほうが良さそうだと思った。 全体としては財務目標→分解した指標(例:MAU)を目標にして、事業成長をトラッキングしたい。 だけど「MAUを追うぞ」と言われても、開発者は自分ごととして捉えにくい。 MAU目標をブレークダウンして「開発したい機能はこれ」「必要な集客施策はこれ」とチーム別に表現したほうが分かりやすい。 常に事業全体を見渡しながらクロスファンクショナルに動くことが理想だと私は考えていた。 しかし、多くの人はスキルで職を得て、スキルで飯を食う。 分業しやすい環境を整えて、各々の得意なことに集中するほうが、良い結果に繋がるのだろうと思う。

2:毎週でトラッキングする意味が薄れそうだなと思った。 期間で目標を区切るのは、悪いことではないと思う。 全体としては「いつまでにどうなるか」を描いて、逆算で施策を打ちたい。 10年後に1,000ユーザーを目指すのと、3年後に10万ユーザーを目指すのとでは、製品・販促・組織・財務の戦い方が変わるからだ。 しかし「開発したい機能はこれ」と目標をチーム単位で分けたときに、期間を区切る必要はあるのだろうか。 毎週のミーティングで、WBSやバーンダウンチャートを見て、課題を検知・対処すればOKなのではないか。 チーム横断で同じフォーマットを使って、情報共有することに意味があるのだろうか。

3:「1ヶ月で1つのワオ体験をユーザーに届けること」といった置き方はどうだろうか。 私は「3月末までにMAU ◯◯を達成」と置きがちで、経営企画チームが10人いるなら彼らに相談できるが、 企画担当が私1人だけだと「そのために何をするかチームに示すのがお前の仕事だろ」と言われて終わってしまう。 「財務目標」→「MAUなどの指標目標」→「その指標を達成できるワオ!施策」に分解して、 「今月は◯◯施策をリリースする」といった目標設定にしたほうが健全に思える。

OKR(オーケーアール)

OKR(オーケーアール)

WBSを書く(改善余地あり)

どのプロジェクトでも最終的には必要になっている。 毎回のように試行錯誤しながらSpreadsheetで作っている。

f:id:yuzutas0:20210322154825p:plain

f:id:yuzutas0:20210322154839p:plain

f:id:yuzutas0:20210322192235p:plain

改善余地:正直なところWBSを使いこなせている気がしない。

  • 目がチカチカする
    • 担当チームごとにシートを分ける?
    • 粒度が細かすぎる?
    • 後述する開発チケットのうち、親チケット(要求仕様書)と1:1対応が適切な粒度か?
  • 1つのスケジュールを更新したいだけなのに、影響箇所の修正が大変
    • 自動化できる?
    • ツールを使ったほうが良い?
  • シートがないと困るのだが、シートを見たときに「だから何?」と思ってしまう
    • そういうもの?
    • 週次定例で確認できていればOK?
  • 他のシートと繋がるはずなのに繋がっていない
    • 財務計画、事業計画、カンバンと同期できる?
    • ツールを使ったほうが良い?

財務管理

現実的な財務計画(できていない)

製品開発時はペインとソリューションに目が行きがちだった。 先に抑えるべきは財務計画だった。 自分が想像していた以上に「人員」「時間」「金額」のボリュームが必要になる。

「最初は3人・3ヶ月・数百万円で最小製品を作るべし」「ビジネス1人、ハッカー1人、デザイナー1人の3人構成がGood」といった言説がある。 これを鵜呑みにして予算を設定すると破綻する。

まず、3ヶ月でギリギリ作れたとしても、次の資金調達(予算確保)が間に合わない。 そして、ハッカー1人・3ヶ月・数百万円も現実的ではない。

  • Developer 1人は無理がある。メルカリはリリース初年度で10人近くメンバーがいたらしい。
  • 3ヶ月も無理がある。ビズリーチは1年以上を費やしたらしい。
  • 人件費設定にも無理がある。ペロリ(MERY)は1人月15万円だったらしいが、実力のあるエンジニアに仕事を依頼すると相場は1人月100万円で、節約上手なスタートアップの5倍以上が必要になる。

仮に「10人」「1年」「1人月100万円」が必要だと仮定すると、リリースに必要な本来の人件費は1.2億円になる。 マザーズ上場を視野に入れて、売上10億円がベンチマークだとすれば、1.2億円は高すぎるとは言えない。 むしろそのポテンシャルがあるからこそ、複数人が人生の一部の時間を投資するのだとも言える。 いずれにせよ自分が思っている以上に初期投資が必要だと認識して財務計画を引かないと詰む。

ポテンシャルを読む(やってよかったこと)

そのステージで実現できるポテンシャルを読む。 人数◯◯ x 単価△△ の積み上げ式でマーケット規模を推定する。

  • 最大で◯◯人が使う(=◯◯人が使っていても不自然ではない)
  • 最大で△△円を払う(=△△円を払っていても不自然ではない)

仮に業務ツールであれば

  • 世界10万社が導入
  • 平均社員数は20人(グローバルな大企業もあれば1人会社もあるけど平均はこのくらい)
  • 毎月1人あたり1,000円(SMBは安価だけどエンタープライズプラン含めた平均はこのくらい)

100,000万社 x 20人 x 1,000円 x 12ヶ月 = ARRは24,000,000,000円。 最大で年間200億円を稼げるポテンシャルがある。

なぜこれが大事か?:

自分自身の金銭・時間を投資できるし、他の人の金銭・時間の投資をお願いできる。 この数字を簡単に実現できるとは言わないが、そうなった未来を脳内でイメージできることは必要条件だと思う。 ポテンシャルが見えないと「本当にこのプランは売上に繋がるんだっけ?」という不安が生じる。 その不安を抱えたままでは、自分自身の時間と労力を投資できなくなる。

仮に「開発に1年」「Developerを中心にチームが10人」「1人月50万円〜100万円」だとする。 50万円だとDeveloper業界から安すぎると批判されるし、100万円だと投資家から高すぎると批判される。 50万〜100万 x 10人 x 12ヶ月 = 6000万円〜1.2億円。 リリースから黒字化まで2年かかる場合、合計して3倍の「1.8億円〜3.6億円」が人件費で必要になる。 株式発行やらSOやら単価を下げるやらで工夫するのだろうが、本来はそれくらいお金が掛かる。 MAXポテンシャルが低いと、とてもではないが人を巻き込めない。

開発以前に「調査・検討に3ヶ月」「Developer・Designerで2人」「1人月50万円〜100万円」「各種専門家で5人 x 月10万円」だとする。 50万〜100万 x 2人 x 3ヶ月 + 10万 x 5人 x 3ヶ月 = 450万円〜750万円。 本格的にリサーチするだけで数百万が必要になる。 ポテンシャルが低い企画だと、とてもではないがリサーチに全力投球できない。

注意点1: ポテンシャルの数字は大きければ大きいほどBetterだと思っている。 成功したときに夢がある。 自費を投じている場合、MAXのポテンシャルが低いと、委託先が音信不通になったり、納品物の品質が低かったときに、サンクコストで心が折れる。 ホームランを打てるかもしれない、と思えるからこそ、投資し続けることができる。

注意点2: 必ずしも「TAM>SAM>SOM」である必要はないと思うが、

  • 最終的なMAXで目指すポテンシャル(ベンチマークIR資料から推計)
  • 現在追っているターゲットの切り方で取れるMAX(各種統計やベンチマークIR資料から推計)
  • 現在追っている施策で取れるMAX(チャネル軸 x ファネル軸で推計)

は優先順位付けのために見ておきたい。 各施策と財務計画の擦り合わせ時に行う。

コスト管理シートを書く(改善余地あり)

f:id:yuzutas0:20210322175846p:plain

  • 【予算・費消】x【予測・実測】をSpreadSheetで可視化した。
  • 別のシートで入出金管理を行い、その結果をビジュアライズした。

改善余地: 会社としての会計システムとのCSV連携だとか、発生主義の仕訳処理に対応できるように契約管理シートを作って同期するとか、 どの検証フェーズ・どの案件・どの職種にどれだけのコストを投下しているかの可視化とか、色々と磨き込む余地はある。 必要になってからで良いと思うし、必要になるくらい事業規模を伸ばしたいものです。

財務計画シートを書く(改善余地あり)

f:id:yuzutas0:20210322192436p:plain

コスト管理シートとは別のプロジェクトで作ったもの。 財務計画と呼べるものに近付いた気がする。 予算消費だけではなく、その予算を投下することで、何を得るのかまで可視化した。

  • リターン:何を開発するのか、どのような体験を実現するのか、どのような価値を得るのか
  • 投資:どれだけの金額を、どのくらいの期間で、どこに投下するのか

ここをステークホルダーと握らなければ、どこかで必ずブロッカーになる。 これは会社のプロジェクトに限らず、自費で何かをするときだって全部同じ。 それなりの金額を使うのに、目的を曖昧にしていたら、歪みが生じる。

仮にリターンを金額で表現できないような社内プロジェクトであっても、 どのくらい恩恵を受ける人がいて、どのくらい業務がラクになるのか、 結果としてどのくらいのインパクトを生み出すのか、は何らかの指標で可視化できるはず。

改善余地:

  • 私はまだ財務計画を十分にハンドリング出来ていない。
  • 他社の実例をこっそり見せてもらってマネするのが最速なのだろう。 今の私の知識・経験では、書籍・記事を読んでも「どういうシートをどう運用しているのか」の現実が見えてこない。 実績ある創業経験者のクラウドファンディングやオンラインサロンにお金を払って実物を見せてもらうのが良いかもしれない。
  • 大企業の大型案件だと、親チケット(稟議書)に子チケット(稟議書)をぶら下げていた。 同様に、プロジェクトのコストの内訳について、1つ1つ投下金額の妥当性を明文化するのが良いのだろうか。 メンバー → 稟議チケット → Spreadsheet(管理会計)→ MoneyForward(財務会計)→ 税理士、のような仕組みがスマートか。
  • 各要素の相場金額がどのくらいで、相場通りに実行できた場合に、どのくらいのROIを実現できるのか。 財務面での頑張りどころはどこにあるのか。 どの領域に注力するとインパクトを最大化できるのか。 これらが企画単体のバリュエーションになるのだろう。

ランウェイから希望予算を置く(できていない)

資金調達にせよ、予算稟議にせよ、自費投資にせよ「◯◯を実現したいから◯◯円が必要だ」を提示する。

製品開発の場合はバーンレートとランウェイが重要概念になる。

  • 資本(予算)◯◯円 ÷ 毎月◯◯円支出 = 会社(プロジェクト)の残り寿命。
  • スタートアップだとランウェイ(寿命)を18ヶ月で設定するらしい。
  • 仮に毎月500万円を支出するなら、必要な金額は9000万円になる。
  • 18ヶ月の間に次の資金調達ができるだけの成果を上げるか、毎月500万円以上を稼げる状態に持っていかないと、アウト。

投資家視点で、その金額を実際に投資することが妥当なのか。 仮にTAMの◯◯%を◯年後に達成するとして、利益率◯◯%・総資本◯◯円で、現在必要な総額◯◯円を投資したら、利回りが◯◯%になる。 その利回りが期待できるだけのボリュームになっているのか。 このくらいは一応計算しておいたほうが良いかも。 あまり筋が良くはないかな。 でも、自分が自分に投資するときは、そういうことを考えるだろうなとは思う。

改善余地:単純に出来ていない。

  • ペロリ(MERY)の事例が強烈。 1人月15万円で、ワンルームに缶詰めだったらしい。 仮に 1人月15万円 x チーム5人 x 18ヶ月 = 1,350万円で済むなら、金銭面でのハードルは一気に下がる。 コストが低ければ、長く戦うことができる。 理屈は分かる。それを実現できていたのが凄い。 その域にまだ辿り着けていない。
  • 企業内予算は18ヶ月を前提にしていない。 四半期の節目など予算見直しのタイミングで梯子が外れてしまい、18ヶ月間を走り続けることが難しい。 最初に合意を得て、チェックポイントを達成しても、市場環境や社内財務状況は変わる。 大抵の場合はチェックポイントの見直しも必要になる。 どれだけステークホルダーと握ったつもりでも、全く別の文脈で人事異動が生じて、決裁者が変わることもある。 予算を使っていなければ「しばらく使わないでしょ?」と言われて、予算を使っていたら「既に使っているでしょ?」と言われる。 「そりゃそうでしょ」「あっちのプロジェクトのほうが重要じゃん」「まだ売上が出ていないのに何を言っているの」と言われたりする。 なかなか難しい。 Yコンビネーターの出資先は3ヶ月でサービスを立ち上げているので、ランウェイが短いなりの戦い方もあるのだろうが……。

誰に何を返すのかをシートに明記する(できていない)

お金を出してくれる人には、何を返すのかを明確にする。 キャッシュインは「①資金」か「②売上」の2つ。 いずれの場合も相手のモチベーションを知ることから始める。

①については、主に金銭面のリターンになるだろう。 銀行から借りるのなら、売上を安定的に伸ばして、確実に返済することを約束する。 そのための事業計画と財務諸表を提示する。

②については、顧客への提供価値とは何か?と同義になるだろう。 営業戦略やプライシングにも直結する話で「決裁者のメンツを立たせる」といった観点も関わってくる。 特に初期フェーズは意図的にN1でCRMを管理すると良さそうだなと思う。 このあたりの話は以下の記事が興味深かった。

これらをSpreadSheetで管理しようとしているが、残念ながら、まだ試行錯誤中。 なぜシート管理したいかというと、期待に応えられる相手だけからお金を頂きたいから。 例えば、ランウェイ18ヶ月を担保したいなら、社内予算を使うのではなく、別の箱を作り、外部資本から調達したほうが健全だろう。 外部資本を調達するにも、赤字を掘るモデルならVCだろうし、黒字を重ねるモデルならJFC→信金・地銀→メガバンに広げていくのが健全だろう。

上場企業は四半期ごとに利益を見られるのでどうしても短期で売上や利益を求められがちです。 事業会社における新規事業への投資は景気が悪くなるとすぐに引き上げられることもあります。 VCの方々から資金調達するにはきちんとした事業プランが必要ですが、上場企業で新規事業に投資してもらうよりは難易度が低いと感じました。

起業して9ヶ月経って感じていること|麻野耕司|note

シート管理によってもう1つのメリットも生じると期待している。 資金提供者や初期ユーザーとのコミュニケーションを、他のコミュニケーションと切り分けることが出来るのではないか。 例えば、資金提供者にプロダクトを見せて「そういえば自分はこれに困ってるんだよねぇ」という話を受けたときに、どう振る舞うか。

A.課題インタビューのシートを見せて、一緒に埋める。 1人のユーザー候補として意見を扱うためのフローに乗せる。 もうすぐリリース予定だったり、既に対応完了している場合は「これで解決できませんか」と提案する。

B.当面対応しない場合は、企画状況を共有する。 1人のチームメイトとして、見ているものを共有する。 似たようなコメントがこれだけ集まっていて(あるいは集まっていなくて)、 この点がネックになっていて(あるいは全体としてはこういう状況で)、 こちらを優先してこういう計画になっています、と説明する。 本当は、週次または月次で30分ほどレポート&相談の場を設けて、普段からこの会話が出来ると理想ではある。 レポート&報告の場にあまり出席しない人もいる。 普段は5分のサマリーしか伝えられない人もいる。 そういう相手に対しては説明の機会を得ることが出来たとポジティブに捉えたい。

C.上記とは別に、資金提供者に対して「こういう観点でリターンを提供します」を何度でも伝える。 「その点は分かっているから心配しなくて大丈夫ですよ」と言われるまで伝え続ける。 相手が違和感を覚えていそうなときに、話し合って擦り合わせるのか、信じてもらうのかは、難しいラインだなと思う。 気軽に相談に乗ってもらえるようなら「何にフォーカスすべきなのか」を会話できると建設的だ。 そういう会話がお互いにできるのかを確認してから資金調達をしろよという話でもあるが……。 「この案件ならこの部署の予算が管轄だね」ではなく、資金提供者と資金調達者がn:mの関係で、代替候補があるとマッチング率が上がるのだろうか。

複数の金融機関に相談する(改善余地あり)

なぜこれが大事か?:

  • Executive Summaryが求められる。
    • 分かりやすい商品や事例を示す必要がある。
    • シンプルな事業モデルと勝ち筋を示す必要がある。
  • ある意味では一番近い存在になってくれる。
    • 顧客・チームと各論を話す時間=実際に前に進んでいる時間。自分のもどかしさを伝えるとプレッシャーになる。
    • 金融機関とサマリーを話す時間=立ち位置と距離を確認する時間。自分のもどかしさを分かち合える。
  • 加速を後押ししてくれる。
    • メンバーにとっては「急ぎすぎじゃないか」と言いたくなるような意思決定も時には必要。
    • 金融機関は、お互いに「この事業でB/S、P/Lを大きくしていこうぜ」という利害の一致がある。
    • 人材や販促に投資して、もっとグロースしようぜ、という後押しをしてくれる。
  • 複数の人に話を聞いて比較する。
    • 複数人から同じ意見が出てくる場合、素直に受け止める。
    • 人によって意見が割れる箇所については、自分なりに解釈する。
  • ミスマッチを予防する。
    • お金が絡む状態でのミスマッチは、ゼロより厳しい。
    • 最高のパートナーになるか、足を引っ張る泥沼になるか。
    • BATNAがある状態で会話して、少しでも違和感があったら断るのが、お互いにとって良さそう。
    • 社内起業だと「この領域は◯◯部門の予算」「決済者は◯◯さん」と資金提供者が固定になるので、ハードルは上がる。

改善余地:

  • たまたま機会があったところと話せているだけで、あまりコントロールできていない。
  • もっと計画的にファイナンスできるはず。

起業のファイナンス増補改訂版

起業のファイナンス増補改訂版

Developerの月額発注 or 案件単位発注(分からない)

これは何がベストなのか未だに分からない。

もともと私は月額発注がGoodだと考えていた。 開発者に対して1人月◯◯円でお金を払うスタイルだ。

昔は「納品して終わり」が主流だったと聞いている。 本当かウソかは知らない。 もし「納品して終わり」が主流だと、致命的な問題が生じる。 納品後に改善できない。 リリースまでの10ヶ月よりも、リリース後の10年のほうが、明らかに期間は長い。 10年間の改善こそが重要だ。 だから「納品して終わり」ではなく『納品のない受託開発』が大事だと思っていた。

「納品」をなくせばうまくいく

「納品」をなくせばうまくいく

一方で、月額発注には、弊害が多々ある。 良くも悪くも、長距離走になるので、メリハリが利きにくい。 結果だけを見ると「これって手抜きじゃない?」と言われてしまうようなパフォーマンスになることもある。

そんな折に気付いたのだが、自分が某ベンチャーを手伝うときには、案件単位で受注していた。 これが思っていた以上にやりやすい。 それに「納品して終わり」と感じたことは一度もない。 同じ会社の同じサービスについて、新しい案件が発生する度に受注している。 このスタイルはGoodな気がする。

受注側のメリットは以下。

  • 貢献できる余地がないときや、別の案件で忙しいときは、無理にその会社の仕事をやらなくてOK。メリハリが効く。
  • 案件ごとに「こういう課題がある」「こういう仮説がある」「こういうことを実現したい」と相談を受ける。目的に対してQCDSがベストな提案ができる。

発注側のメリットは以下。

  • 優秀な人に依頼しやすい。
    • 好きなタイミングで作業してもらえば良いので。
    • 締め切りやマイルストーンを合意さえすればOK。
  • どの案件にいくら投資するかが見えやすい。
    • 「継続的な改善」で思考停止せずに「この改善を行うべきか」を判断できる。
    • 継続的な改善は大事だけど、工数を貼り付ける必要はない。
    • その改善が本当に必要なら案件として明示的にお願いする。
    • 追加のコスト・工数を費やすほどの価値がないなら、無理にやらない。
  • 時給換算でも作業項目別請求でも、月額請求のドンブリ勘定に比べると、単体で見たときのコスパは良い。
    • お金を無駄に垂れ流さなくて済む。
    • つまりランウェイが伸びる。

こう考えるとプロダクトマネジメント観点では魅力的に見える。 一方で「毎月きちんと工数を確保して着実に作業を進める」「トラブル発生時は確実に即日対応する」といった安定性は損なわれる。 プロジェクト期限まで余裕がない場合、案件のボリュームが大きい場合、安定的な品質が求められる場合は、このやり方だと無理がある。

初期フェーズはスポット案件として少しずつ進める。 顧客・売上が増えて、サービスレベルが求められるようになったら、人月請求での工数確保に舵を切る。 このスイッチングが出来ると依頼者としては嬉しい。

Designerの月額発注 or 案件単位発注(分からない)

デザイナーについても同じ課題を感じている。

特に難しいのがリテイクをどう扱うか。 リテイクを嫌う人は多い。 作業量が倍になるので、まぁそりゃそうだよなとは思う。 ただ、プロダクト観点だと「納品して終わりではない」「その後の改善が大事だ」「リテイクは必要悪ではないか」という懸念があった。 なので、人月会話のほうが良いのではないか、と思っていた。

しかし、最近は「1案件・1納品・1請求」でも良いのではないか、と思い直している。 工程を細かく区切って、途中でUXをテストできているなら、微調整はあれど、根本的なリテイクのリスクは低い。 それでもUIを作り直す場合は「他案件のUIデザインを止めてまで磨き込むのか」を判断しないといけない。 結果として「新しいUI改善案件」として扱うのと同じことになる。

だとしたら「1案件・1納品・1請求」と何も変わらない。 むしろ案件単位のほうが、デザイナー視点では「短期間で納品するとすぐに稼げる」構造になる。 効率的に目的を達成するインセンティブが生じる。 依頼者視点では「いくらを投下して、何を得たのか」が見えやすくなる。 バーンレートを下げることにも繋がるのではないか。

まぁ、そこまでお願いできる相手なら、案件単位で請求処理を交わすよりも、 月額契約のほうがお互いにラクなのでは?とも思う。 結論は出ていない。

期待の10倍のスケジュールで見積もる(できていない)

Yコンビネーターでは、3ヶ月で製品を作るらしい。 その影響で「新規事業は3ヶ月でリリースまで漕ぎ着けるものだ」と思っていた。 しかし、現実的な話として「ゼロから企画して3ヶ月でリリース」は無理がある。

ランウェイを18ヶ月に置かざるを得ない理由は明確で、自分が思っていた以上にプロジェクトには時間が掛かるからだ。 1回の仮説検証では、ゴールに辿り着かない。 1円の資本効率に徹底的にこだわるべきだからこそ「プロトタイピングを何回もやり直す」という前提で計画を立てたほうが良さそう。

自分が脳内で描いている最短ルートだともっと安くて早く仕上がるはずなんだけど、 それは解像度が甘かったり自分本位な仮説を置いているゆえの幻想で、 現実に落とし込もうとすると、そんな最短ルートはどこにも存在しない、というのがオチ。

進捗・金額だけを見ると「ベストを尽くしているのか?」「もっと早くできないのか?」「もっと費用対効果を改善できないか?」とツッコミを受ける。 自分でも同じツッコミをしたくなる。 だから、プロトタイピングなり、課題整理なり、作業工程のアウトプットを細かく可視化して、 どこにどのくらいの時間・金額が必要なのかを見えるようにしたほうが良いのかもしれない。 そのシートを見ながら「具体的にはどこが改善できそうですかね」と会話すると、建設的な議論になるだろう。

どうにも「企画フェーズは所要時間0」「自分自身や正社員は工数無限・コスト0」の感覚で、計画・レビューしてしまっている。 そこで無理が生じているように思う。 どこかで無理をしないといけないのは重々承知だが、最初から計画が破綻していると、自分だけでなく周囲にも迷惑が掛かる。 全てを業務委託ベースで見積もったほうが適正なスケジュール・予算になるだろう。

慣性の法則(改善余地あり)

お金とスケジュールには、エンジン&ブレーキが必要になる。 前後1-2ヶ月はエンジン&ブレーキが必要な前提で見積もりたい。

10月末にジャッジしてコストを止めたくても、解約は1ヶ月以上前に申し出てねという契約だったら、 10月末ジャッジ→すぐ申し出る→11月分を支払い(タイミングによっては12月分も支払い)になる。

1円の資本効率に徹底的にこだわるべきなのだけど「1円も無駄なく節約できる前提で計画を立てる」のはNGだ。 1-2ヶ月は着地がズレる想定で、多少多めに払う想定で、バッファを積む必要がある。

ペイン・課題分析

リファレンスカスタマーを6人探す(改善余地あり)

  • 『Inspired』によると「対象セグメント」の顧客候補を「6人・6社」見つけ出すのがポイントらしい。
  • 後述するインタビューやコンセプトボードのテストなど、リファレンスカスタマーがいないと何も進まない。
  • 最終的にはプロダクト開発を通して6人のユーザーにワオ体験を提供する。
  • 6社どころか成功者たちは100人・100社にインタビューしていると思う。

なぜこれが大事か?:

スケーラブルな製品を作るために必須だと思う。 「まず自社で使われるものを作ってから外販しよう」 「まず1人が使えるものを作ってから広めよう」 「広めるときに作り込もう」は、局所最適に陥りやすいと感じている。

1社の課題解決ならSpreadsheetでも可能だ。 そこそこ使えるSpreadsheetを作ると、ステークホルダーはそのSpreadsheetで満足してしまう。 「さらに労力や資金を投資する必要ある?」「このSpreadsheetをコピペすれば?」で話が終わる。

1社の課題解決ならこれでOKだけど、10万社を目指すならプラットフォーム開発が必要になる。 初期モックアップを見せたときに「Spreadsheetで十分じゃない?」と言っていた人たちが、 3年後には「Spreadsheetからこのソリューションに切り替えよう」と言い出したりする。 製品開発者は1:nで提供できるし、製品利用者は1/nのコストで導入できるので、全員にとって投資効率が良い。 最高の選択肢だ。

ユーザーの立場では3年後に導入すればOKなのだが、プロバイダーの立場では、3年後に売れるものは今から作り始めなければいけない。 最初からn人・n社に売る前提で製品を考えたい。

改善余地:

  • 「対象セグメント」をどう設定するか?が悩ましい。
    • ついアクセスしやすい相手を探してしまっている。
    • アクセスしやすい相手から攻めるのは間違っていないが、戦略的に選んでいるというより、とりあえずで進めている感がある。
    • よくよく分析すると、6人とも抱えている課題や視点が違うじゃないか、ということになる。
    • その結果、後述するLP作成・デジタル広告配信のときに、顧客セグメントについて悩む。
    • 後で整理して軌道修正することになるので、仮説ベースで良いので、最初からきちんと整理したい。
  • 「6人・6社」をどう見つけ出すか?
    • 今のところは見つかっているけど、アクセスしやすい相手にサービス提供しているから、だと思う。
    • 狙ったセグメントで見つけに行くことは出来ていない。

インタビューシートを書く(改善余地あり)

インタビューをGoogleDocsに記録した。 「yyyymmdd_xxxさん.gdoc」で1人1ファイル管理にしている。 他の資料で「このインタビューを参照」とURLを貼れるので、何かと便利だ。

インタビューでは、事前に台本の骨子を用意した。 『Running Lean』を参考にして「①課題インタビュー」と「②ソリューションインタビュー」を実施した。

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

フェーズ Customer / Problem Fit Problem / Solution Fit
検証事項 f:id:yuzutas0:20210322220648p:plain:w200 f:id:yuzutas0:20210322220705p:plain:w200
台本(骨子) f:id:yuzutas0:20210322220719p:plain:w200 f:id:yuzutas0:20210322220734p:plain:w200
  1. SNSやSlackで呼びかけて、候補者を見つけて、スケジュールを合わせる。
  2. 30分間でコーヒー休憩&雑談がてらのGoogleMeet・Zoomインタビューを実施。
  3. インタビュー後に文字起こし。

ちなみに、2020年12月時点では「1週間で10人」が自分の上限ラインだった。 10人と話すだけでも収穫は大きかった。 2021年3月時点では「1週間で20人」まで自分のキャパシティが増えた。

意識していることは以下3点。

  • 別の立場の意見を網羅する。
    • 例:教育サービスなら、講師・学校・親・児童で見え方が違う。
    • 各自の立場の違い(構造の歪み)がどう問題を引き起こしているかを明らかにする。ゲーム理論っぽい。
    • ソリューションを提供することで、構造的な歪みに対して、裁定取引を行うイメージ。経済学っぽい。
  • 新しいアイデアを出すのではなく、可能性を絞り込む。
    • 困っている点を聞く。想定課題から重点領域を絞り込む。
    • 不安な点を聞く。コミュニケーションやブランディングの重点領域を絞り込む。
    • これはやめてほしいと思っている点を聞く。ソリューションの制約を確認する。
  • 具体的な数字を聞く。
    • 「周りにも沢山います」→「同じ部署の同僚だと何人中何人が該当しますか?」
    • 「けっこうコストを使っています」→「もし可能なら年間でいくらになるか教えていただけますか?」
    • 「かなり時間かかってます」→「どの作業に何分くらい使っていますか?」
    • 「頻繁に行きますよ」→「月に何回くらい行きます?」

なぜこれが必要か?:

自分がユーザーに近くて、仮説に自信があった企画は、インタビューよりも開発を優先したが、結果としてプロジェクトが迷走した。 インタビュー記録をテキストに起こすことで「論点が整理される」「ステークホルダーと共通認識を醸成できる」と感じた。

改善余地:

  • ①課題インタビュー ②ソリューションインタビュー にも内訳がありそう。
    • 粒度:A.コンセプト策定 > B.機能追加 > C.UI改善 といった分類が可能か。
    • 詳細:Bにも、B1機能、B2機能、..., Bn機能 とn個が存在するだろう。
  • ①課題インタビュー ②ソリューションインタビュー だけではなさそう。
    • 案件ごとに開発プロセスの途中でインタビューやユーザーテストを細かく挟むのがGood。前述。
  • 「インタビュー種別」と「インタビュー対象者」はn:mの関係にある。
    • 例:課題インタビュー:Aさん、課題インタビュー:Bさん、ソリューションインタビュー:Aさん。
    • フォルダ構成が悩ましい。
    • ラベル付けしてラベル別で一覧表示できるツールが良いのか。
    • インタビュー種別でフォルダ階層を作る+インタビュー対象者はHubspotで管理+記録DocsとCRMツールで相互リンクを貼るのが良いか。
    • Spreadsheetでマスターシートを作って各記録URLを張っておけば十分か。
  • テキストを書くのが大変。
    • 音声入力や文字起こしツールは滑舌が悪いと反映されない。
    • 動画保存はGoodだが、30分音声から該当の会話を探すのは大変。
    • どこにヒントがあるのか分からないので、安易に要約できない自分がいる。
    • とはいえ素早く要約してインタビューの数を増やしたほうが絶対に良いだろうとも思う。
    • 重要なポイントは何度も話に出てくるから、わざわざ細かくメモを取る必要はないのだろう。
    • GoogleDocsを画面共有して、一緒に議事録を書きながら話を聞く、という手もある。リサーチ手法としてはNGだろうけど、インタビューをやらないより100倍マシだと思う。
  • 毎日の習慣にしたい。
    • 商売において、外(顧客)と話すのと、中(チーム)と話すのは、同じくらい大事。
    • チームメンバーと毎日朝会やるなら、ユーザーと毎日カフェトークしないと、バランスが崩れるのではないか。
    • Slack(ユーザーグループ会)に10人のユーザーを招く x 1人ずつ隔週でインタビューを依頼 → 平日2週間サイクルで毎日インタビューできるやん!

ユーザーグループ(改善余地あり)

  • リリース後に、初期ユーザーを集めて、ユーザーグループを設けた。
  • 熱狂的な顧客の1人に幹事を依頼した。
    • ユーザー同士でQ&Aや意見会をやってくれると、開発チームの工数負担が減る&忖度ない意見が出てくるので助かっている。
    • 本来はコミュニティマネージャー職を設けたり、自身が担うべきだとは思う。
  • ソリューション検証・開発の状況はあまり伝えていない。
    • 開発チーム視点に近くなってしまうと、ユーザー視点で率直な意見を言えなくなるのではないか、と懸念しているため。
    • 開発側の都合を無視した、ワガママで率直なコメントが欲しい。最高のUXにしたい。
  • 必ずしも要望を全て受け入れるわけではないと期待値を調整している。
    • VOCリストを元に真因を分析し、インパクトのある課題を選び、施策を検討する。前述。

改善余地:

  • 初期フェーズでどこまでコミュニティを作りこむのか。そこまで力を入れるべきポイントではないようにも思う。
  • 心情としてはJAWSやGCPUGやLookerユーザー会のようなコミュニティ感がもうちょっと欲しいなぁ。盛り上げたい。

NPSのトラッキング(検討したけど不要だったかも)

背景:

  • リリース後にワオ体験(UX)をどのように計測して、次の製品改善に繋げるか。
  • 主要指標を単体で見ると、リリースや広報活動によって数字が上振れしてしまい、直感と成果が合わないことがある。
  • ユーザー体験をダイレクトに評価する指標が欲しくなる。
  • UX計測を調べるとNPSに言及する記事や書籍が目立つ。

やろうとしたこと:

  • 5段階アンケートで「Very Good / Good」「Normal」「Bad / Very Bad」「未回答」「未質問」にセグメント分け。
  • 具体的にどの顧客がどのセグメントなのか追えるようにする。
  • ワオ施策でスコアがどのくらい上がったかを計測する。
  • 狙った人たちのスコアが狙った動きをするかを見る。

質問候補:

  • 「今後も利用したいですか?」
  • 「このツールに満足していますか?」
  • 「このツールがないと困りますか?」
  • 「このツールは簡単に利用できましたか?」
  • 「このツールによって◯◯が変わったと実感できますか?」
  • 「このツールを同僚や知人に紹介したいと思いますか?」(実際にご紹介お願いする場合があります)
  • 「このツールを導入するのにいくらなら支払えますか?」
  • 「全ての回答をハイスコアにするには何が必要だと思いますか?」

迷ったこと:

  • 定期的に配信するのが実務面で難しそう。
    • わざわざ抽出→配信のオペレーションを構築するか?
    • わざわざ配信システムを構築するか?
  • 最初は自分たちが開発環境でNPSを回答するだけでも良いかもしれないと一瞬思った。
    • 理由:せめて自分たちで胸を張ってアピールできるものを作りたいから。
    • 結論:意味がなさそう。わざわざNPSを計測せずとも、レビューOKならリリースすれば良いし、UXに問題があるならレビューNGで手戻り。
  • 定期的に配信されてもUX面で微妙そう。
    • この手のアンケートに定期的に回答できた記憶がない。
    • 後述のユーザーセグメントが変わったタイミングで、個別に聞くほうが良さそう。
  • ◯◯したいと思いますか?への違和感がある。
    • 本当に思っていたら行動ログに反映されているのでは。
    • NPSではなく「再訪問率」とか「リピーター数」を追うほうが納得感がある。
    • さらに突き詰めると、グロースサイクルを軸にしたユーザーセグメントの計測が良さそう。

福島は「ユーザーが使い続けてくれているかどうか(=再訪率)」をもっとも重要な指標として捉えている。「創業期は、『何を解決しようとしているのか、ターゲットに使わせたときにちゃんと使い続けてくれているのか』が非常に重要です。初期はそこだけを見ていたらいいと思います」

引用元 『STARTUP 優れた起業家は何を考え、どう行動したか (NewsPicksパブリッシング)

結論としては、後述の「グロースサイクルを軸にしてユーザーセグメントを計測」「ユーザーセグメント変更時に個別アンケートを実施」のほうが筋が良さそう。

グロースサイクル x ユーザーセグメント(改善余地あり)

リリース後は、さらなるUX改善に向けて、ユーザーセグメントの可視化を行っている。 とは言え、まだ十分に出来ていないことも多く、試行錯誤中なので、これで良いのか自信はない。

グロースサイクルは、Amazonの「Virtuous Cycle」やら、 メルカリ・サイクルやら、リボンモデルやら、ネットワーク効果やら、 色々と言われているものの延長にある概念だと解釈している。

このグロースサイクルをベースにして、対象期間におけるユーザーセグメントを5つに分けてトラッキングする。

  • 新規(New):累計サイクル0回。
  • アクティブ化(Active):前期間は累計サイクル0回、今期間はサイクル1回以上。
  • 継続利用(Keep):前期間はサイクル1回以上、今期間もサイクル1回以上。
  • 離脱(Churn):累計サイクル1回以上、今期間はサイクル0回。
  • 復帰(Comeback):前期間は累計サイクル1回以上かつサイクル0回、今期間はサイクル1回以上。

財務面ではUnitEconomicsを見るように、UX面ではグロースサイクルをUnitで見て、Churn x Cohort を改善していく。 初期フェーズでは「DAU」「売上」といった全体の規模感を見ても施策に繋がらない。 UU単位で「顧客体験が通っているか?」「成長エンジンが回っているか?」を追うことに意味があると思っている。

備考:

  • サービスが成長するとセグメントの定義は変わる。
    • ECサイトなら「購入頻度が多い・少ない」「売上が大きい・小さい」といった軸でロイヤリティを分ける。
    • 初期フェーズはそれどころではないので、まずはアクティブ化と継続利用にフォーカスする。
  • サービスごとに計測期間も変わる。
    • 毎日使うニュースアプリと、月末しか使わない経理ツールでは、計測期間が異なる。
    • カスタマージャーニーマップを書いて、現実的な時間軸を設定する。
  • 何を持ってサイクル1回と判断するか。グロースサイクルをどう描き、どう集計するか。
    • 例:写真投稿・閲覧のCtoCサービスの場合。
    • 案1:ユーザーが投稿もしくは閲覧の主要導線を1回通したらサイクル1回。投稿者サイクルと閲覧者サイクルをそれぞれ可視化する。リボンモデルの考え方。分かりやすい。
    • 案2:写真を投稿して(行動)、いいね!受信通知を開いて(トリガー)、詳細画面でいいね!数を確認したら(心理的報酬)、1サイクル。『Hooked』を参考にしている。顧客心理に基づいている。習慣化モデルの仮説が外れたときに指標の変更が必要。
    • あくまでUX指標としてユーザーセグメントを管理する。機能別の規模感については、ユーザーセグメントとは別に、投稿UU・投稿数・閲覧UU・閲覧数を期間別に可視化する。
  • グロースサイクルを選んだ理由は、初期フェーズではまずサービスを成立させないといけないから。
    • フェーズが進んで利用が増えたら、カスタマージャーニーマップやサービスブループリントの各要素を細かく見たほうが良さそう。
    • 理想としては顧客体験を描いたカスタマージャーニーマップで見たい。
    • 現実的にはログを取得しやすいサービスブループリントで見ることになるだろう。
  • ユーザーセグメント変更時に個別アンケートを送りたい。
    • セグメントを可視化するのは、Goodなセグメント移動を促し、Badなセグメント移動を減らしたいから。
    • Goodなセグメント移動:未アクティブ→アクティブ化、アクティブ化→継続利用、離脱→復帰。
    • Badなセグメント移動:新規のまま移動なし、アクティブ化→離脱、継続利用→離脱、復帰→離脱。
    • セグメントが移動したばかりのユーザーに話を聞いて、何がGood要因・Bad要因だったのかを調べたい。
    • Good要因は他ユーザーでも再現したい。勝ちパターンをソリューションに当てる。
    • Bad要因を他ユーザーで再現させたくない。離脱ポイントをソリューションで塞ぐ。
    • 『顧客起点マーケティング』を参考にしている。

Route Cause Analysis(改善余地あり)

課題の構造と真因を分析する。

  1. インタビューで挙がった課題をグルーピングする。
  2. 課題の因果関係を書き出す。なぜなぜ分析。
  3. ある課題Aがある課題Bを引き起こしている、を可視化する。
  4. 悪循環をサイクルで表す。飛躍しているところは仮説で埋める。
  5. 誰が抱えているどの課題から切り込むのかを決める。

なぜこれが大事か?:

  • インタビューで挙がった全ての意見にそのまま対応すると、もぐら叩きのような仕事量に疲弊して、ツギハギだらけのハウルの城が出来上がる。その製品を使った顧客には「何か違うんだよねぇ」と言われて終わる。
  • 顧客自身が自分の欲しい物を理解しているわけではない。「遠くまで行ける馬が欲しい」という意見に対して「生き物には体力があるから長く走れないのではないか」と分析して「機械を使えば解決できる」と仮説を立てて、自動車や汽車を提供する。これが企画。

改善余地:

  • 毎回の施策で実施できているわけではない。
  • ツールが悩ましい。
    • MiroやJamBoardなどのホワイトボードツールが良いのだろうか。
    • 長期的に運用するならSpreadSheetでリスト化したほうが良いのだろうか。

競合・類似サービスの感想を書く(改善余地あり)

  • 競合・類似サービスを使いまくった。
    • 他にもヒントになりそうなサービスや、インタビューで名前が出てきたサービスは片っ端から試した。
    • インタビューで「あのサービスを試してみたけど期待と違った」という意見が出てきたときに、解像度高くペインを理解する機会になる。
    • 既存の製品の進化の延長では問題を解決できない→では本当に欲しいものは何か?の流れで分析する。
  • 課金しまくる。
    • 価格がクローズドの場合は、問い合わせると相場が見える。聞くからには顧客として導入検討・課金する。
    • 使ってみて最高だったら、自分の企画はボツにして、そのサービスをPRする人になる。導入支援のコンサルティングをやる。
    • 直接的な競合ではなくても、関連サービスにお金を払うことで、エコシステムとしてのUX・お金の流れが見える。
  • スクリーンショットを撮って、感想をGoogle Docsに書いた。
    • 「サービス名/yyyymmdd_実施者名.gdoc」のファイル名で管理した。
    • 開発チケット起票時に「この仕様を参照してください」とURLを貼れると何かと便利。
  • 後のソリューション検証に関しては「TTP」(徹底的にパクる)を重視する。
    • ペインはユーザーに聞く。ソリューションは違う。ユーザーは速い馬車を求めるが、売れるのは自動車だ。
    • 自分でアイデアを出す必要はない。新しいアイデアは既存のアイデアの組み合わせから生まれる。

改善余地

  • 仁義。「同じ分野のサービスを作りますね」と一言挨拶するかどうか。挨拶すると、市場拡大のために応援してくれる派と、怒って潰そうとしてくる派がいる。
  • スクリーンショットの撮影→記載が手間。簡単に実現できないか。

競合・類似サービスを分類する(やってよかったこと)

f:id:yuzutas0:20210322233620p:plain

星取表を作りながら以下をマッピングする。

  • どのカテゴリ・セグメントに属する人が(例:EC集客担当が)
  • カスタマージャーニーのどのジョブについて(例:リード獲得について)
  • どのサービスを(例:ABC入稿ツールを)
  • いくら支払って(例:ツール利用は月◯◯円、広告配信は月◯◯円で)
  • どのように運用して(例:週1回1時間で実績を見ながらバナー候補を選択して)
  • どれだけの便益を受けているのか(例:月◯◯人、CPA◯◯円、全体の◯割)

これをやると「一応埋まっているんだけど違和感あるんだよなぁ」ポイントが見える。

「なぜそのサービスを使い続けているのか」「なぜあのサービスを使っていないのか」をインタビューする。 「一応使っているけど使いにくい」とか「最近はもう使っていない」とか「存在を知らなかった」とか「わざわざ使おうとは思わない」とか「こういう点が使いにくい」とか、色々と聞ける。

  • ①お金を払って毎日使うだけの需要がないのか
  • ②需要はあるけどプロダクトやマーケティングが不十分なのか

を判断して、明らかに①の場合は落とす。 ②の場合は後で検証する。

  • 初期仮説に自信がある場合は、このフェーズはマーケット状況の検証と言える。
  • 初期仮説に自信がない場合は、このフェーズはチャンスを探るための調査と言える。

ソリューション分析

リスクを検証する(検討したけど不要だったかも)

『Inspired』によると以下のリスクを検証することが肝だと言う。

  1. 価値のリスク。顧客が価値を感じるようにコンセプトボードを作り込み、インタビューや広告配信で確かめる。
  2. ユーザビリティのリスク。顧客が使い方を理解できるようにUIプロトタイプを作り込み、デモDayやユーザビリティテストで確かめる。
  3. 実現可能性のリスク。技術リサーチ(お試し実装)を行い、システム開発に着手する前に確かめる。
  4. 事業実現性のリスク。財務計画と仕様書をまとめて、後述の有識者会議で妥当性を確かめる。

『Running Lean』や『スタートアップ・マニュアル』や『逆説のスタートアップ思考』によると、以下のリスクを検証することが肝だと言う。

  1. Customer / Problem Fit:顧客と課題。AsIsのカスタマージャーニーを描き、インタビューで確かめる。
  2. Problem / Solution Fit:課題と解決策。コンセプトボード・UIプロトタイプを作り、インタビュー・広告配信・デモDay・ユーザビリティテストで確かめる。
  3. Solution / Product Fit:解決策と製品。技術リサーチ(お試し実装)を行い、システム開発に着手する前に確かめる。
  4. Product / Market Fit:製品と市場。財務計画と仕様書をまとめて、前述の有識者会議で妥当性を確かめる。

それぞれの内容は、該当箇所で解説する。

逆説のスタートアップ思考 (中公新書ラクレ)

逆説のスタートアップ思考 (中公新書ラクレ)

  • 作者:馬田隆明
  • 発売日: 2017/03/31
  • メディア: Kindle版

少なくとも私の場合は、これらのリスクは意識しなくて良かったかな、と思う。

  • これまでの自分は、教科書の演習問題を解くように、各リスクを順番に検証していこうとした。手応えはなかった。
  • 実際に上手く検証できたときは、上記のイメージとはちょっと違った。
    • もっと無秩序で泥臭くて「これだー!」と「やっぱり違う」を繰り返しまくって、色々な情報が錯綜して、気付いたときには1本の線が通っていた。
    • 最初から「こういう製品があれば売れるのではないか」という筋道があって、最高のUXを実現するために「ああでもない」「こうでもない」とリサーチ・テストマーケティングを行っていると「まぁこれが勝ち筋だよな」という結論に辿り着く。
  • ステークホルダー向けに報告資料をまとめるときは、これらの観点はそのまま使えた。
    • ロジックの筋が通っているか確かめるときにはGood。
    • 残りの論点を洗い出すときにもGood。
    • ただし、論点を解消するためのアクションは「このリスクについて今からインタビューで検証します」ではなかった。もっと段階がある。

極端なコンセプトを複数提示する(改善余地あり)

案A 案B
f:id:yuzutas0:20210322234619p:plain:w250 f:id:yuzutas0:20210322234631p:plain:w250
  • 「顧客セグメント」「ジョブ」「ペイン」「既存ソリューション」を列挙する。
    • 「この顧客」x「このジョブ」x「このペイン」x「この既存ソリューション」のリプレイス案を出す。
    • まず局地戦で勝てるコンセプトを描く。ランチェスター戦略。
    • 「このコンセプトが広がった先に、マスを食えるか?」
      • 事前に考えると思考停止するので、コンセプトを考えた後にチェックする。
  • リプレイス案は極端なものを複数出す。
    • 例:自動化によって人件費がゼロになる→価格を半額に抑えられる。
    • 例:1クリックで完了できる→所要時間が1時間から1分に激減する。
    • 例:月に5件だったマッチングが毎日5件になる→成約の機会が30倍に増える。
    • 『400のプロジェクトを同時に進める 佐藤オオキのスピード仕事術』を参考にした。
      • 極端な複数案を提示して、その中から選ぶ。
      • 最大公約数では良いコンセプトには到達しない。
      • どれかを選べば、少なくともこれまでとは違うアクションに繋がる。
  • 案を出すときには「◯◯版の◯◯」というコンセプトで考える。
    • 『アイデアのつくりかた』曰く、アイデアは既存のアイデアの組み合わせ。

なぜこれが大事か?:

「他に良いアイデアがあるのでは?」という議論の余地を残したくない。 プロジェクトの逆境時には誰かが「他の可能性」に言及したり、その言及を受けてチームに迷いが生じる。 隣の芝生は青く見える。 学びを経てのピボットなら良いが、大抵「他の可能性」は現実逃避に過ぎない。 フォーカスと実行でしか乗り越えられない HARD THINGS は多々存在する。 いちいち余計な迷いが生じていては、成功できるはずの企画も成功できなくなる。 「全部検討した上でこれで行くと決めました」と言える状態にしたい。

改善余地:

コンセプトの表現方法。 私はこの工程をテキストで実施したが、テキストでは限界があると感じている。 後述するコンセプトボードまで提示できると理想か。

アイデアのつくり方

アイデアのつくり方

コンセプトボードを作る(改善余地あり)

百聞は一見に如かず。目に見えるものは大事。 LP・プロトタイプを作ると、関係者の期待値が跳ね上がる。 「これなら上手く行きそうだね」と思えるアウトプットを提示できると、何かと話が早い。

具体的には、以下のようなアウトプットをイメージしている。

f:id:yuzutas0:20210322235306p:plain

https://onn-hr.com/ のスクリーンショットを引用。 このサービスは私とは何も関係ありません。念の為。

実際にやることは以下。

  • 上記スクリーンショットのようなランディングページを作る。
    • 公開できる場合は公開する。
      • ペラ1やStudioだと月1,000円で出来る。
      • 事前登録が多かったら最高!
      • インタビュー候補者を確保できる。
      • 事前登録の多さをステークホルダーに示せる。
    • 公開できない場合はステルスに流す。
      • 社内限定、紹介限定など。
      • GoogleSitesだとGoogleアカウントでアクセス制御が可能。
      • あるいは希望者を専用SlackチャンネルやFacebookグループに招待。
      • 人が集まるなら、公開版と同じメリットを享受できる。
  • 事前にプレスリリースを書く。
    • リリース時にそのまま使うつもりで!
    • Amazon流。
  • ユーザーからの感謝の手紙を書く。
    • 想像の産物でOK。
    • Inspired流。
  • Figmaなどのプロトタイピングツールでモックアップを作る。
    • どのみち必要になるので。
    • 文章説明だけだと「具体的な使い方がイメージできない」と言われてしまう。
    • 動くものを作って、デモ動画に収録して、LPに埋め込む。

なぜこれが大事か?:

関係者(自分自身を含む)が挑戦できる状態に持っていきたい。 「勝てる賭け」であることを示して「これに賭けて良いのか」という不安感を払拭したい。

「マーケット環境の変化で3年以内に新しいプレイヤーが台頭しても不自然ではない」 「その未来の成功を予感させるに相応しいランディングページだ」 と思わせられたら、最高だ。 実際に問い合わせが寄せられていたら、さらに最高だ。

開発者や初期ユーザーは、プライベートαの「ハリボテ版」でも使い始める。 しかし「ハリボテ版」の完成度は低いため、他のステークホルダーからは「これで上手く行くのか」という疑心が向けられる。 特に資金提供者(決裁者)の視線が痛い。 ステークホルダーが納得感を得ていないので、要所で歪みが生じてプロジェクト進行に悪影響が出る。 そういう状況を避けたい。 「ハリボテ版」はこれが現状だけど、ゆくゆくは「このランディングページのようになりますよ」と言えるようにしたい。

改善余地:

色々と試してはいるが、残念ながら「◯◯億円を目指せそうだ」「3年後に普及しても不自然ではない」と関係者に言ってもらえていない。

ワオ体験を描く(改善余地あり)

最初は出来ていなかったが、徐々に習得しつつある。

1つのユースケースに絞って「便利じゃん!」「これは感動だ!」「ワオ!」と思わせる。 特定のユースケースで120点のUXを見せつける。 たとえ他の機能が不完全でも、1つが魅力的だから、次のアップデートが楽しみになる。 全てを平均点で作るよりもROIが高い。

どこで120点の感動を生み出すのかを決めることが、企画の妙味だと言える。

  1. 想定ユースケースを洗い出す
  2. いつ誰にどのような影響を与えたいのか整理する
  3. ワオ体験の案を複数出して
  4. 対象ユーザー数 x 頻度 x 面倒臭さ x 実現難易度 で優先順位を決めて
  5. コンセプトボードやUIプロトタイプを作る ↔ ウォークスルーを毎日繰り返す(感動的なUXを実現できそうかシミュレーション)

ワオ体験を描く工程は、前述のコンセプトボードや、後述のFigmaモックアップと重複する。 Figmaモックアップの動きを見てインタビュイーが「ワオ!」と感動する。 モックアップの動きを収録したデモ動画を、コンセプトボード(LP・プレスリリース)に掲載する。 これが出来ると理想的だ。

ワオ体験に直結しない機能はスコープアウトする。 開発チームでスコープを検討できるように、ワオ体験と仕様を紐付けて要件を作るのが好ましい。 メルカリ創業本を読むと「スマホで売れた!」の感動体験にフォーカスしたらしく、初期リリースでは売上出金さえ最初は手動だったらしい。

顧客体験をマッピング(改善余地あり)

ワオ体験を設計する中間成果物として、順番に作成していく。

  1. カスタマージャーニーマップ(登場人物ごとにBeforeとAfterの体験がどうなるか)
  2. グロースサイクル(前述:複数の登場人物がサービスを使うことでAfterの世界がどうなるか)
  3. サービスブループリント(登場人物ごとにAfterの体験がどうなるか+サービスがどう使われるか)
  4. フローチャート・シーケンス図(主要導線・異常系の挙動を解像度高く洗い出すとどうなるか)

なぜこれらが大事か?:

  • 顧客理解(AsIs)とワオ体験(ToBe)とUIプロトタイプ(製品案)を繋ぐものだから。これらが明文化されていないと「何を作れば良いのか?」が曖昧になる。
  • 力の入れどころが見えてくるから。例えば「WEBサイトは最小限でOK」「LINE Botとバッチシステムの作り込みが鍵になる」と見立てられる。

背景:

  • これまでの自分は、わざわざ中間成果物を作らなくても、どんどんリリースしてユーザーに当てれば十分だと考えていた。
    • 「まずはリリースして反応を見る」を言い訳にして、思考停止して、開発作業に逃げていた。
    • 考えるのが億劫で「まぁ大丈夫か」と手を抜いたところは、後で必ず問題を起こし、ユーザーに迷惑を掛け、巡り巡って自分たちに跳ね返った。
    • リリースする度に「これはちょっと微妙じゃないか?」と思ってしまう自分がいた。
    • 大量に寄せられたフィードバックを整理すると、9割のコメントは開発前に検証できることに気付いた。
  • 私の場合、本当に必要なのは、徹底的な企画検討だった。
    • 成功者が言う「企画よりリリース」は、嘘ではないだろうけど、企画だけで私より10倍の品質を担保しているように思う。
    • 午前中はチームでディスカッションを行い、手元にある情報だけで、納得できる水準までソリューション案を詰める。
    • 午後はPdMが情報収集・インタビューを行い、Designerがプロトタイピングを作り、Developerがリスクの高い箇所を技術調査する。
    • そしてまた集めたピースを持ち寄ってパズルを組み立てる。
    • 1.5ヶ月ほど繰り返すと、それなりに自信を持って見せられる仕様案に辿り着けた。
  • 感動体験を実現するためには必要な企画プロセスだと思う。
    • 机上で「どのような機能・体験を提供するか」をシミュレーションするだけで、多くのUX課題を洗い出し、解消できる。
    • 簡単なようでいて、全体の筋を通すのは難しい。
    • 可能性を洗い出して、絞り込む。整合性の取れたUIプロトタイプを作る。それだけで「これ売れそう」に仕上がる。

改善余地:

  • 実際には前後の工程を行き来しながら、何度も作り直すことになる。
    • 率直に言って大変。
    • 新規リリースの場合、1日数時間を企画に費やして、何十回も成果物を行き来して、1.5ヶ月でようやくまとまった。
    • 少しでも簡単にする方法はないだろうか。
  • ツールをどうしたら良いのか。
    • GoogleDocsの箇条書きやSpreadsheetの表管理だけでも一応は進められた。
    • もっと良い方法がありそう。

FigmaでUIプロトタイプを作る(改善余地あり)

CrowdWorksの事例が分かりやすい。すごいと思う。

  • 確実に「ワオ!」と言わせるためのUIを作り込む。
    • 何度でもウォークスルーテストを繰り返す。
    • ユーザーやステークホルダーに見せながら「ワオ体験を提供できるか?」「懸念を払拭できるか?」を確認する。
    • 上記事例のように「プロトタイプを1ヶ月で100個作る」を最初の目標に設定しても良いのではないかと思う。
    • ものづくり(クラフト)とUXは切っても切り離せない。
    • 目に見えるものがあると、解像度の高いフィードバックを受け取れる。
  • 目の肥えたユーザーが期待する「当たり前」品質を担保する。
    • ハリボテ版を本番リリースしたが、良くなかったかもしれない。
    • まだ動かないボタンを付けたり、チーム内でしか通用しない用語が、画面に表示していた。
    • ユーザーの脳内で「このボタンは何?」が気になると「ワオ!」は遠ざかる。
    • どんなに感動する映画でも、途中の1分間が絵コンテだったら「え?今の何?」と戸惑う。
    • 一度でも戸惑ったら、その後は映画の中身に集中できなくなる。
    • だったら最初から2時間ではなく30分の映画として放送したほうが良い。
  • 開発者とは別にデザイナーが必要。
    • ワイヤーフレームをDeveloperに渡したので、最低限のUIにはなると思っていたが、そうはならなかった。
    • リリーススケジュールに意識が向くと、UIに強いDeveloperでなければ、UI品質は担保できない。
    • 高い目標を設定すると、作業量も多くなるので、最低限の開発要件を捌くので精一杯になる。
    • UI大臣は、Developerとは別に必要。それがCSSも書けるDesignerだと理想的。
    • クロスファンクショナル幻想とDevOps幻想は捨てよう。しかるべき担当者に、慣れた仕事を、慣れたやり方で、確実に進めてもらうほうが安定する。
  • プロトタイプと見比べながら受け入れテストを行う。
    • 私は開発者の苦労を想像できてしまうので「まぁこのくらいでもいいかな」と判断しがち。
    • しかしそれはユーザーに不便を押し付ける意思決定なので、結果としてチームの首を締めることになる。
    • プロトタイプと異なる挙動をしたらNGを言わなければいけない。
  • プロトタイピングツールとシステム開発を分ける。
    • 「最初からシステムを作ってどんどん直せばいいじゃん」「開発環境でステークホルダーに見せればいいじゃん」と思っていたけど、分けたほうが良さそう。
    • 「システムを作って直す」「新画面を開発環境にデプロイする」だと、数日が溶けるリスクがある。
    • プロトタイピングツールなら、同じ変更を1日で実施可能。生産性は何倍も高い。
    • @shoito や @hotchemi と同じチームだったときは、デザインツールより早くコードで画面を作ったが、あのチームの実力が異常だっただけで、普通そうはならない。
  • URLで共有できるプロトタイピングツールなら何でもOK。
    • Adobe XD も一応URL共有が出来るらしい。

改善余地:

  • プロジェクトによっては出来なかったものある。
    • 初期からデザイナーを巻き込めるかどうかがポイントか。
  • 現実的な金額・期間・労力で抑えるには、どう働いてもらえるといいか悩ましい。
    • 初期フェーズだとリテイクは必須になる。それこそ100回リテイクする前提でいたほうが良い。
    • しかし「リテイクの多い客はクソだ!」「リテイク料金を請求すべし!」という風潮がある。無償労働を押し付けるのは確かに反対。

コンテンツを集める(やってよかったこと)

  • WEBサービスやアプリを作る前に、Spreadsheetに実際のデータを手動入力した。
    • 仮に音声投稿サイトなら音声コンテンツを集める。
    • 仮に画像投稿サイトなら画像コンテンツを集める。
    • 仮に動画投稿サイトなら動画コンテンツを集める。
  • ワオ体験を実現できる優良コンテンツを早期に特定できる。
    • 優良 or NOTの判別方法。
    • 優良コンテンツの扱い方。
    • 優良コンテンツの集め方。
  • Figmaに当てはめることで、リアルなウォークスルーテストを行える。
    • テストデータではなくリアルなデータで「ワオ!」と言えるか。
  • 本番リリース時には初期コンテンツが豊富な状態でスタートできる。
  • リアルなコンテンツがあるので、ステークホルダーが顧客を理解しやすい。
  • リアルなコンテンツがあるので、そのまま営業できる。
    • 特にマッチング系の事業はSpreadsheetだけでも売上を立てられる。
    • その後に顧客が日々使うツールやメディアを聞いてサービス化すれば良い。
    • 仮にLINE Botを使ったソリューションなら「マッチング事業をLINE対応しました」で送客できる。
    • 以降は手動マッチングからLINE Botに切り替えれば、LINE Botを軸にしたマッチングサービスの完成。

技術リサーチを先行して行う(改善余地あり)

  • UIのプロトタイピングと並行して、開発者にはシステム開発観点でプロトタイプを作っていただいた。
  • 例:UIの動きを実現できそうか、事前に仮実装を行ってみる。
  • 例:簡易的なスクリプトで連携システムのWebAPIにアクセスしてみる。

なぜこれが大事か?:

  • 要件定義を進めた後で「技術的に実現は困難」と分かると、大きな手戻りが発生する。
  • 手戻りできずに対策前進せざるを得ない場面もある。事前に分かっていれば、その前提で要件を調整できたのに……。
  • リスクを抱えた状態で見積もり・スケジュールを提示することに開発者がストレスを感じてしまう。
  • ものづくり(クラフト)とUXは切っても切り離せない。

改善余地:

開発スタート前は機能したが、リリース後の改善フェーズだと、技術リサーチの位置付けが難しい。 前述のように「10XなUX改革」→「VOC駆動のUX改善」→「内部改善」で3回ウォーターフォールを回して、企画フローで開発者が技術検証を担うのが理想的だろうか。

簡易システムを先行してリリースする(改善余地あり)

  • GoogleAppScriptやGoogle Colabで簡易システムを作る。
  • 裏側のDBとして、GoogleFormやSpreadsheetでデータ入力・管理する。
  • 画面を作る場合は、Google Sites + Google DataStudio(iframe埋め込み)でビジュアライズを作成。
  • コア体験に絞って「体験版」を顧客候補に提供する。
  • 例:ビジネスマッチングサービスであれば、オススメの専門家を毎週3名、GAS経由でメール配信する。
  • 全てを自動化できないので、オペレーションスタッフに作業を行ってもらって、徐々に自動化する。

なぜこれが大事か?:

  • UIプロトタイプや技術検証を経て、仕様書が出来たとしても、システム開発→リリースには数ヶ月を要する。
  • その数ヶ月を使って「体験版」を顧客に当てる。
  • リリースを待たずに、顧客の業務がどう改善されたか、業務に乗せるには何がブロッカーなのか、もっと使い勝手を良くできないか、を確認できる。
  • UIプロトタイプだけよりも、体験版があったほうが、販促・営業・紹介がしやすい。ここは簡易システムの完成度次第だが。

改善余地:

  • ちゃんと出来ているわけではない。実行面が中途半端。
  • Developerがシステム構築するのと同時並行でPdM(私)が実施することを想定していた。しかし、本当はDeveloperがこの作業を担当して、簡易システムを成功させた後に、本格的なシステム構築に着手するほうが良いのではないか。ここで運用スクリプトやDB設計を試行錯誤すれば、その知見をシステム構築に活かせるはず。
  • GASやColabでは出来ないことも多い。選択肢を持つという意味では、同じようなローコードツールをもっと知りたい。
  • オペレーションスタッフとDeveloperで運用改善ミーティングを定期開催できると良さそう。実際に困っている人がチームにいて、リアルな課題を実感できたら、Developerはシステム化・自動化にやる気を出すのではないか。

デジタル広告配信(改善余地あり)

やったことは以下。

  • Google, Facebook, Twitter でデジタル広告を配信 → どのキーワード・セグメントで、どのくらいのImpression&Clickが発生するか。
  • ペライチでLP表示 → Google Analytics で滞在時間を確認。
  • Google Form で事前登録 → Google Spreadsheet で登録状況を確認。

改善余地:

  • 広告媒体は1つで良いかも。
    • わざわざツールを分散させてオペレーションの手間を増やすのは悪手か。
    • SmartHRは2万円のFacebook広告だけで済ませていた。
    • SmartHRの立ち上げの話は理想的だと思う。スマートだ。
  • そんなに細かく分析する必要ある?とは思う。
    • LPやフォームの離脱率を気にするフェーズじゃなくない?
    • 予算◯万円で配信してみて、熱狂顧客が6名見つかるか、だけにフォーカスしたほうが良くない?
  • プロにお金を払って、教えてもらいながらやりたい。
    • きちんとしたツールの使い方。
    • WEB集客やLP設計の考え方。企画との繋ぎ方。
    • 具体的にどのようなドキュメント・シートで設計を進めるのか。
  • troccoとBigQueryならファネル全体をデータで繋げるのでは?とふと思った。
    • マーケ専任を雇えるフェーズなら整備したいですね。

デモDay(改善余地あり)

  • ステークホルダー全員が集まる場で、デモを見せる。
  • Google Meetで操作画面を3分間ほどシェアするだけでも物事が一気に進んだ。
  • 直接画面を見せる or 事前にデモ動画を収録する。
    • 理想は前者。サーバトラブルがあれば、サービス信頼性の低さも含めて、課題として扱う。
    • 現実には後者も必要。ステークホルダーが多い場合や、出資者がハプニングを好まない場合は、事前収録が無難。
  • 参加者に好き勝手にコメントしてもらう。
    • UIプロトタイプを見せるパターン:このソリューション案でペインを解消できそうか?顧客に最高の体験を届けられるか?
    • 開発環境を見せるパターン:このソリューションをリリースしてOKか?顧客に最高の体験を届ける用意が全て出来たか?
    • 本番環境を見せるパターン:現状プロダクトのどこにUX課題があるのか?
  • チームメンバーは同席して、そのコメントを受け止める。
    • 欠席者への情報共有や、後で開発チケットに関連URLを貼るために、デモDayの様子を収録&サマリーメモを残しておく。
    • 同席した人と、そうでない人とで、温度感にギャップがあるような気もする。

なぜこれが大事か?

  • 作業に専念していると、視野がつい狭くなってしまうので、リリース前に客観的なコメントを貰う。
  • ユーザーに迷惑を掛けない段階で、目の肥えた人々にツッコミを貰い、(私自身を含めて)チームが低品質なアウトプットに甘えないようにする。

改善余地:

  • そこまで毎回できていない。実施頻度はどのくらいが良いのだろうか。
  • ステークホルダー全員を同じタイミングで集められない。スケジュールが合わない。言うほど簡単ではない。

MVPを作ろうとしない(改善余地あり)

f:id:yuzutas0:20210324174417p:plain

引用元 Top 5 Misconceptions About Building A Minimum Viable Product | by Tyrannosaurus Tech | TyrannosaurusTech | Medium

  • 既に述べたように実際にはMVPを作っている。MVP自体はGood。
    • 例1「ティザーサイトで事前登録してもらう」
    • 例2「Spreadsheetでマッチング代行をしてお金をもらう」
  • ただ、私個人の意識の持ち方として「MVPを作ろう!」と思うと、中途半端なハリボテになって、本当に検証したかった仮説に辿り着かない。
  • むしろ「製品開発は次のフェーズで行う」「企画フェーズの1ステップとしてソリューションについてリサーチする」意識のほうが上手く回っている。
    • MVPを作ろうとすると、MVPがゴールになってしまうのかもしれない。
    • MVPの次のフェーズに意識を向けておくと「リサーチを進めたら結果的にMVPと呼ばれるものが出来ていた」という状況になる。
  • 同様に「仮説を検証する」ではなく「最高のUXを提供する」と意識したほうが上手く回るように思う。
    • 上図のように、ユーザビリティや信頼性を担保した上でユーザーに使ってもらう、が本来の筋だと思う。
    • 何度も軌道修正して、UXを磨き込んで、ようやく顧客に提供できる。で、それはめちゃくちゃ難しい。だから普通はステークホルダーの誰かが耐えられずにどこかで下手を打って失敗する。そこを耐え抜いた者が成功する。
    • 「どれだけプロトタイプを作り直せるか」と「試行錯誤の時間を財務計画にどこまで織り込むか」で「どこまでチームが耐えられるか」が決まる。スピードと(それ以上に)耐久力の勝負になるのだと思う。
    • 課題発見→製品発見→製品開発の各フェーズにおいて、インタビュー用の叩き台は20点で素早く作り(最速:アジリティ重視)、次のフェーズに進めるには120点を手堅く作る(最高:クオリティ重視)へと切り替えるのがポイントかなと思う。

改善余地:

意図してコントロールできているわけではなかった。 この文章を書いていて「そう言えば」と気付いた。

世界観・ビジョンを描く(改善余地あり)

  • ある程度ソリューションが固まった段階で「このソリューションがどんな未来を実現するのか」を言語化する。
    • 書籍・スライドによっては「最初にビジョンを決める」とか「ビジョンが全ての根っこ」と書いてある。
    • 実務としてはソリューションありきだと思う。
    • 最初にビジョンから始めると、抽象的な議論ばかりで前に進まない上に、顧客・市場に理想を押し付けるような内容になりがち。
  • こういう感じでWhy?を突き詰める。
    • 案「◯◯業務を効率化するツールです」
    • Q「なぜ◯◯業務を効率化したいの?」
    • A「早く仕事を片付けたいから」
    • Q「なぜ?」
    • A「もっとクリエイティブな本業に時間を使いたいから」あるいは「趣味に打ち込んだり、家族と過ごす時間を増やしたいから」
    • Q「なぜ?」
    • A「人生を充実感のあるものにしたいから」
  • このツールが普及したときの世界を思い浮かべる。
    • 友人が海外企業に転職したとする。
    • 上司「うちは◯◯を使っているんだよ」
    • 友人「ああ、前職でも◯◯を使っていました、便利ですよね」
    • 入社初日のセットアップはスムーズに完了。
    • みたいな場面を思い浮かべると、自分たちが世界に何を提供しようとしているかイメージできる。

なぜこれが大事か?

  • これらのビジョンに合っているときだけ「ワオ!」が生まれる。
  • UXのバリデーションになる。
    • 「1クリックで終わる」「スマホで写真を撮って送るだけでOK」は「セットアップはスムーズに完了」のビジョンに合致する。
    • 反対に、遷移が多かったり、機能が複雑だと、ビジョンに合致しない。
  • 長期的なアップサイドが大きくなる。
    • 短期的には◯◯の課題を解決するツール。長期的には◯◯な人生を実現できる事業。
    • ユーザーにとっての本当の価値を理解していると、10Xの改善施策が次々と見えてくる。
    • 対象となる課題の根っこが汎用的だと、市場のポテンシャルを大きく捉えることができる。

システム開発

初日にリリースする(改善余地あり)

なぜこれが大事か?:

  • 勢い(モメンタム)を得られる。
  • 手が早い人と一緒に働くのは単純に楽しい。
  • 「緊急事態や軌道修正にも素早く対応できるだろう」と安心感も生じる。
  • 動くものがあると現実的なスコープを実感して目の前の課題に専念できる。

背景:

  • 過去の開発案件では「ダラダラと話し合っているうちに机上の空論だけが膨れ上がって頓挫する」「勢いで作り始めたら関係者が本気になって話が軌道に乗る」ことが多々あった。
  • 予算の大小を問わず、数億円規模のプロジェクトでも同じだった。
  • 何も開発できないのが最悪のパターンで、開発さえ出来れば、何らかの学びを得られる。
  • 数億円を費やして得る学びは、予算がない会社の3年分の試行錯誤に匹敵する。3年分のアドバンテージを得られる。お金で時間を買える。
  • だからこそ「初日リリース」がGoodだと考えた。

改善余地:

最近、初日リリースがGoodなのかBadなのか、分からなくなっている。 プロジェクト開始初日にリリースできたということは、裏を返すとペインやソリューションの検証が不十分ということでもある。

  • ペインやソリューションの検証について初日にWBSを引くのはGoodだと思う。
  • 初日にデザイナーがコンセプトボード(例えばLP)を作って公開するのはGoodだと思う。
  • 早い段階でリリースサイクルを回してプロセス・システムを磨き込むのはGoodだと思う。
  • ダラダラと計画性のない話し合いを続けるのはBadだと思う。

だが、初日にハリボテをリリースすることが、どこまで重要なのだろうか?とは思い始めている。

「リリースしたけど使われませんでした」「結局リリースできませんでした」の悲劇を恐れすぎて、リリースにこだわりすぎているように思う。 それ自体は悪いことではないけれど、最初に注力すべきは企画フェーズではないか。 企画会議で100回ボツを食らって、企画を100回練り直すことに、もっと価値を置いても良いのではないか。

ドッグフード&ユーザーテスト(改善余地あり)

初日リリースしたハリボテで、ドッグフード&ユーザーテストを開始した。

なぜこれが大事か?:

  • 自分たちで使っていると、次々と直したいところが見つかる。
  • 不安になる場面もあるけど、着実に機能を強化していくと、やっぱり便利じゃんと思える。

改善余地:

  • リリース後に初めて問題を検知するのでは遅いのではないか。
    • 前工程のリサーチやプロトタイピングでもっと品質を担保すべきではないかと思い始めている。
    • ドッグフードをリリースするのではなく、最高の製品を最高の状態で顧客に届けたい。
    • プロトタイピングとリリースの中間に、自分たちが使うための試作品を作る、というのはアリだろうか。遠回りかな。
  • ステークホルダーのうち、使っている人と、使っていない人とで、温度差が生じる。
    • ドッグフーディングしている人は、早く改善しなければと焦る。
    • ドッグフーディングしていない人は、細部を指摘して、話が前に進まない。
    • 試しに使ってみてくださいと何度も促したら、数日後に「これやばいね」と言って一緒に焦る。
    • この感覚の共有が悩ましい。
  • ドッグフーディングで目先の課題に焦ることが正しいわけでもないだろう。
    • 前工程を固めるなら細部の指摘には真摯に向き合うべきとも言える。

サービスレベルを決める(できていない)

yuzutas0.hatenablog.com

大まかに言うと、以下を決める。

  • サポートする端末・OS・ブラウザ。
  • どの機能で、どのような障害が起きたら、誰が、いつまでに、どのように対応するのか、どのようなサポートを行うのか。
  • どのようにインシデントを検知するのか。

なぜこれが大事なのか?:

  • 要件の1つとして、UXとスケジュールに影響を与えるから。サポートブラウザが2つになると、ブラウザテストの必要工数は2倍になる。
  • リリース後に障害対応で慌てないように、予めトラブル発生時の動きをシミュレートし、備えるため。

改善余地:

  • サポートブラウザを決めるくらいしか出来ていない。Developer時代に強みだった領域の1つなので、もどかしい気持ちになる。
  • 運用が始まる前にPdM(私)が「こういうケースに備えてスクリプトを用意してほしい」と言っても、あまり上手く行っていない。運用が始まって、障害対応を経て、必要性がはっきりしてからスクリプトを作るほうが、短期間で要件に合うものが出来る。そして毎回「事前にもっとしっかりしたスクリプトを用意しておけば良かった」という振り返りがDeveloperチームで行われる。毎回「だから言ったやん!」と思ってしまう。何をどう伝えたら良いのだろうか。

開発チケットを書く(改善余地あり)

f:id:yuzutas0:20210327142659p:plain

以下のような要求仕様書を3ヶ月で200チケットほど書いた。

- AsIs
- ToBe
  - ユースケース
  - 画面遷移・イメージ
  - ログ・DB項目
- 理由・意図・背景
  - このチケットを完了すると何が嬉しいのかを伝える
  - 誰が、何に、なぜ困っているのか
  - ユーザーインタビューのURLを貼る
- スケジュール
  - 見積もり or 希望納期
- 完了条件
  - チェックリスト
  - 要件が複雑になると実装漏れが起きるため明記する
  - これをもとに受け入れテストを行う
- 着手条件
- 想定する改修範囲
  - システム構成図を元に記載する
- リスク・懸念
  - 認識しているリスクを記載しておくと、チームメンバーから改善提案を貰えることがある
- 注意点
  - セキュリティ・プライバシー
  - パフォーマンス
  - リリースタイミング
  • 案件によっては項目を省略した。
  • この手のフォーマットは世に沢山あるので、Goodな観点を見かけたら取り入れていきたい。

補足:

チーム結成初期は、なるべく自分でチケットを書くようにしている。 自分が開発者だったときは、開発者がチケット起票・管理を行うべきだと考えていた。 自身の担当案件を主体的に推進することが、プロフェッショナルな働き方だと考えたからだ。 しかし、人によって価値観は異なる。 少なくとも依頼する側が過剰な期待を持つのは健全ではないだろう。 そう考えて最初は自分が全てを担うつもりで作業した。 回らなくなったタイミングで相談したら、上手く委譲できた。

改善余地:

  • 開発者以外への依頼も同じようにフォーマット化したい。
    • UIデザイン、セールス、集客・宣伝、リーガル、HRなど。
    • まだ出来ていない。
  • 3ヶ月で200チケットは多すぎる。
    • チケットが乱雑状態になってしまった。
    • 探すのも大変。
    • GitHub Projectだと破綻する。
    • JIRAでEpicにまとめるなら可能だが。
  • 粒度が細かすぎるのではないか。
    • 親チケット(要求仕様書)と、子チケット(開発タスク)を分けたほうが良かったのではないか。
    • 子チケット(開発タスク)なら「3ヶ月で200件」「開発者自身による起票」に違和感がない。
  • いきなりチケットを起票するのはNG。
    • 「VOC→課題分析→施策分析」を経てから起票すると、数を絞って、質の高いチケットを作ることができたはず。
    • 役割分担の問題にも直結すると思う。PdM 1名+Developer 3名だと、チケットをどんどん起票してしまう。企画フェーズに人を割くべし。
  • 稼働面で破綻する。
    • UX・マーケ・財務など、自分の視野が広がるにつれて「アレも考えなきゃ」「コレも考えなきゃ」とやっているうちに、チケットが雑になってきた。
    • 200件の起票後、徐々に巻き取ってもらえたので、何とか破綻せずに済んでいる。
    • 開発チケットの細部に時間を費やすと、UX・マーケ・財務まで手が回らなくなる。
    • 結果として開発チームの負担や不安が増えてしまったように思う。
    • だけど「丸投げはダメだよね」「細部まで把握してナンボだよね」も正論だと思う。
    • スタンスは「細部まで把握」で、稼働破綻を防ぐには「少数の親チケットを作り込む」「企画フェーズで要件を磨き込む」の2点だろうか。

受け入れテスト(改善余地あり)

開発チケットについて、受け入れテストを実施した。

背景:

なるべく自分で受け入れテストを行うようにしている。 「製品を作る人」と「製品を使う人」は、見ているものが違う。 特にプログラミングを担当する人は「1文字のスペルミスでシステムが動かなくなる」世界で戦っている。 そして誰よりも開発中の製品に触れて、慣れてしまっている。 だからこそ、プログラミングを担当しない人間(自分)が「製品を使う人」の視点で見ることに意義があると思う。

改善余地:

  • 「ちょっと微妙かな」「まぁこれでもいいか」でOKしてしまいがち。
    • 結局はユーザーに迷惑が掛かり、結果として開発チームに迷惑が掛かる。1秒でも悩むなら相談する。
    • 理由を伝えて修正してもらう。
    • 上手く言語化できないときは、開発者とデザイナーに相談して、違和感を言語できるように手伝ってもらう。
    • 相談の場で「そのくらいなら大丈夫じゃないですか?」と言われて「そうですかね」でOKを出すと、大体そこがダメになる。
    • 「こいつ面倒臭いやつだな」と思われるくらいが、結果的にちょうど良さそう。
  • 「やっぱり違うかも」「まぁせっかくここまで作ったから」でOKしてしまいがち。
    • 結局はユーザーに迷惑が掛かり、結果として開発チームに迷惑が掛かる。1秒でも悩むなら相談する。
    • 手戻りを恐れない。
    • 前工程の課題が顕在化したなら、しかるべき前工程で解消するしかない。
    • 手戻りを許容するには、スケジュールと財務に余裕(18ヶ月のランウェイ)が必要。
    • スケジュールと財務に余裕がないときは、①玉砕覚悟で突っ込むか、②撤退するか、③スケジュールと財務を組み直すしかない。
    • スケジュールと財務を組み直すには、①スコープを減らす(ワオ体験を絞り込む)か、②リソースを増やす(MAXポテンシャルに賭けて追加投資する)しかない。

デリバリーマネージャーの役割を担保する(改善余地あり)

背景:PdM(私)がPjMを(事実上)兼任してしまいがち。

  • 開発スケジュールを管理して、リリースのボトルネックについて相談したり
  • 受け入れテストのはずなのに、単体テストレベルのバグを発見したり

打ち手:以下の取り組みを積み重ねると、徐々に改善できているように思う。

  • チケットごとにチェックリストを設けてセルフチェックしてもらう
  • 「ステージング環境で動作確認しましたか?」と聞く
  • WBS・バーンダウンチャートを朝会で確認して、チケットごとに着地予想を確認する

改善余地:

  • 新しい開発チームを結成すると毎回同じことが起きる。
  • もはやプロダクトマネジメントに限らず、システム開発プロジェクトで毎回同じ光景を見ている気がする。
  • 初手で予防できるようにしたいが、難しいのだろうか。

仕様書を書く(改善余地あり)

例1 例2 例3
f:id:yuzutas0:20210327143337p:plain:w160 f:id:yuzutas0:20210327143847p:plain:w160 f:id:yuzutas0:20210327143924p:plain:w160

背景:

開発チケット200件の反省を活かして、GoogleDocsで仕様をまとめることにした。

概要:

DeveloperやDesignerと一緒に話しながら書く。 「製品発見」(ソリューション検証)での議論を元に、ソフトウェアの振る舞いを記述していく。

  • 表示文言について決める。何を載せるか。何を載せないか。UIプロトに当てる。
  • 表示順について決める。作成日時・降順。更新日時・降順。投稿グループ別・昇順。
  • 異常系について決める。0件のとき。エラーのとき。入力途中で画面を離れる場合。
  • 状態・ロジックについて決める。「入力途中で画面を離れる」の「入力途中」をどう判断するか。

リスクを先送りせず、文言や異常系まで網羅する。 次々と追加の検討事項が出てくるので、片っ端から決めていく。 数画面のWEBサイトにも関わらず、50ページ(20,000文字)のボリュームになった。 それだけ検討事項は多い。

検討漏れの論点を詰めると「この挙動は技術的に可能なのだろうか」「このパターンのUIはどう表現したら良いだろうか」といったリスクが見つかる。 その場合は、Developerに技術調査を、DesignerにUIプロト作成を依頼する。

改善余地:

  • もっとビジュアルを重視したい。
    • SIerがExcel帳票で作る仕様書(画面・DB・バッチ)みたいなやつ。
    • 文章だと論点を網羅できているか分かりにくい。
    • 単純に読みにくい。
  • 企画概要も同じドキュメントに記載してしまった。
    • ビジョン、顧客、課題分析、他ソリューション検討など。
    • それぞれで分割しないと、ファイルが重厚長大になる。
    • 各フェーズごとに中間成果物(ドキュメント)を作ると良いのかな。
  • 意思決定の経緯を記録しておきたい。
    • どういう議論を経てその仕様になったのか。
    • だが、全ての経緯を記載すると、読みにくくなる。悩ましい。
  • サービス全体でガイドラインを設けたい。
    • Submitボタンを「Level1」「Level2」に分けて、Level2は確認モーダルを挟む、とか。
    • いちいち個別で検討&記載をせずとも、もう少し簡単に出来ないかなと思ってしまう。
  • 書き手を委譲したい。
    • PdM(私)が全て書いてしまったけど、営業・サポートに手が回らなくなった。
    • フォーマット化できたら、要件定義のプロを探さなくても、推進をお願いできないだろうか。

要件をカットする(改善余地あり)

  • 仕様書の整備と合わせて、対象スコープを大胆にカットした。
  • 本当はやりたい。全部を作って、提示したい。
  • だけど、目標期間でリリースして、利用してもらって、成果を出さないといけない。
  • さらに、コアのUX(ワオ体験)に関する機能・UIは、中途半端な開発をして、妥協するわけにはいかない。
  • この決断こそが企画屋の真価だと信じている。

改善余地:

  • もっと早いフェーズでスコープを削れるのではないか。
  • その機能について、仕様書で異常系を検討したり、技術調査したり、UIプロトを作ったりしたが、その時間がもったいない。
  • 既述のGAS・Colabで簡易システムを作って、そこから進化させる形式の場合、コア体験以外をスコープに入れずに済むのだろうか。
  • シンプルなプロジェクト計画書があれば、VOC→課題→施策→開発で、筋道が通るような最小限のスコープに留めることができるのだろうか。

カンバン(改善余地あり)

  • 開発タスク管理ではカンバンを使いがち。
  • 開発チケットを【TODO】【WIP】【DONE】と流していく。
  • 「とりあえずこれで始めましょうか」と言いやすい。

改善余地:

  1. 製品開発以外のフェーズも管理したい。
  2. 開発チーム以外も管理したい。

上記2点についてはどうにかしたい。

  • VOC→課題発見→製品発見→製品開発のうち、最後の部分だけがカンバン管理になっている。
    • 「課題発見」「製品発見」「製品開発」でIssueのラベルを分けるのが良いかな。
    • 同様に、担当ロール「Developer」「Designer」でIssueのラベルを分けるのが良いかな。
    • ラベル別にベロシティを計測して振り返りを行うことは可能なはず。
  • チームごとに同じツールじゃなくてもいい。Spreadsheetでもいい。
    • そのチームの担当案件がリストになっていて、どれが進んでいて、いつ着手して、いつ終わるのか。
    • できれば各チームの予実(ベロシティ)が分かると計画を調整しやすい。
  • スクラムやDevOpsの文脈だと「プロダクトのリリースに必要なものは全て可視化しよう!」と言う。
    • 実際に「リーガルチェック」のチケットをカンバンに可視化してみた。
    • 開発者から「このチケットがここにあっても僕らは貢献できないので外してもらえますか」と言われる。
    • ですよね〜〜〜。
  • 開発チーム以外のタスク管理をどうしよう?という課題が生じる。
    • 立場的には「プロダクトのリリースに必要なものは全て可視化しよう!」(リーガルチェックを含む)派。
    • スクラムやDevOpsがどうこうではなく、全てを可視化しないと製品開発・事業開発を推進できないから。
    • 開発チームのカンバン・ベロシティだけでなく、全てのロール・タスクの進捗を把握したい。
    • エンジニアの開発タスク以外にも大量のタスクがあるので、本当の管理ツールはGitHubじゃないんだろうな。
  • 欲しいのはWBS……?
    • 実際にはタスクは左から右に流れる。どこで止まっているか分かるカンバン方式は魅力的。
    • PdM・PjMとしては、全体のバリューストリームが順調かどうかをモニタリングしたい。
    • Developerのタスクが順調でも、Designerが詰まっていたら、順調ではない。
    • Wrikeやnotionのようにデータは共通で見せ方を変えられるツールが向いているのだろうか。

指標・KPIダッシュボードを作る(改善余地あり)

ハリボテ版で主要導線を通せるようになってから構築した。

  • Google Analytics, StackDriver Logging, CloudSQL のデータを
  • GCPの機能で BigQuery に送って
  • Google DataStudio でダッシュボードに表示

この構成は最高。 一度体験すると、他の手段に戻れなくなる。 めちゃくちゃ簡単に実現できる。 サーバレスな ETL + DWH + BI 構成なので、開発者が運用保守に工数を割かずに済む。

なぜこれが大事か?:

  • 初期フェーズだと「ここまではユーザーに使ってもらえる」「ここで離脱する」がデータで顕著に反映される。
  • データを見ると「最高のプロダクトを提供できているのか?」「ここが不十分ではないか?」が一発で分かる。
  • UX観点で妥協した機能・画面の数字は確実に落ちてしまうのだと痛感した。
  • 自分の期待水準が徐々に上がっていくのを実感している。

改善余地:

  • どのフェーズで、どこまで指標を設計するか、が悩ましい。
  • やろうと思ったらどこまでも出来る中でどこまでやるべきなのか。
  • 前述の【グロースサイクル x ユーザーセグメント】が初期の要か。

yuzutas0.hatenablog.com

システム構成図を書く(やってよかったこと)

f:id:yuzutas0:20210327145937p:plain

  • Google Drawing や miro で書いた。
  • 後から気付いたが JamBoard でも良いかもしれない。GoogleDriveで管理できる。
  • 昔の案件では PlantUML + IntelliJ + GitHub で管理していた。あれも良かった。コード管理できるのが良い。
  • 以前の会社では Confluence のプラグインを使っていた。あれも良かった。高価なので最近はお目に掛かる機会がない。

なぜこれが大事か?:

システム構成図があると何かと便利だ。 開発チケットの想定影響範囲を会話しやすい。 セキュリティ試験やパスワード管理で漏れがないかチェックできる。 このような、いわゆるロゼッタストーン・ドキュメントは基本的に作ったほうが良いと考えている。

アプリケーションの構成は……(分からない)

ここは何がベストなのか未だに分からない。

なるべく「Easy」かつ「枯れた」技術要素が望ましいとは思う。 真っ先に思いつくのは Ruby on Rails かな。 欲を言うと最初の1週間で以下を一気に作るくらいのスピード感が欲しい。

  • インフラ:HelloWorld表示。ローカル→GitHub→CI→Staging→CI→Productionの開発の流れを作る。
  • アプリ:認証認可、メインCRUD掲示板、メールやSlack配信、簡易バッチジョブを作る。

少なくともソースコードが1万行を超えるまでは、このスピード感を維持したい。

そう考えるとFrontend・Backend For Frontend・BackEndの3層構成やmicroservicesは過剰かもしれない。 初期に採用すべきはフルスタックかつモノリシックな構成かな。 まぁ特に強いこだわりがあるわけではない。 期待するスピードを維持できる程度にEasyであれば、3層構造でもどんな技術要素でもOK。 過去に書いたコードが豊富にあって、認証認可やメール配信などの実装を使い回せるならモダンな構成でも大歓迎。

反対に「このプロジェクトで初めてこの技術を使います」は避けたい。 せっかくの新規開発だからと、新技術を試したいという気持ちは分かる。 だけど、新規開発でないと試せないような技術は、設計や運用観点が未検証というリスクを伴う。 短期間で顧客を獲得しないと案件が中止になる状況で、技術面のリスクを取る余裕はない。 医者に「この治療法はやったことがないのでぜひ試してみたい」と言われるようなもので、特別な事情がない限りは避けたい。

インフラはGCPを使う(やってよかったこと)

開発体験の良し悪しは何とも言えないが、ビジネス観点を含めると周辺サービスが魅力的だと思う。

  • 前述のダッシュボードが作りやすい。
  • Google Adsense(広告)やGoogle Analytics(計測)やFirebase(認証・通知・計測・ABテスト)と繋げるのも強い。
  • IAM と ServiceAccount で権限管理を行いやすい。これは他のIaaS・PaaSも同じか?
  • 監査ログを取得しやすい。StackDriver Logging が強い。これは他のIaaS・PaaSも同じか?

残念ながらGoogle・GCPは使いやすい機能とそうでない機能の差が激しい。 あまり真面目にGCPを使いこなそうとせず、無理に全てを自動化しようとせず、 「とりあえずこれでいいかな」という気持ちで進めると、まぁ悪くはないと思う。

技術的負債を返すためのチケットを作る(改善余地あり)

以下を共通認識にしてチケットを起票・差配した(つもり)。

  • 技術的負債はどんどん貯めて、どんどん返していく。
  • 勢い(モメンタム)を重視する。

自分がTechLeadロールの経験者なので、技術的負債の優先順位については会話しやすいと感じる。 今のところ、開発者と事業責任者の双方が納得する、ギリギリのラインを攻めることが出来ている……はず……。

背景:

個人的な見解なのだが、大企業で売上を稼いでいるWEBサービスや、世界中で使われているソフトウェアは、とにかくコードが汚い。 ヒットしたサービスは、ヒットする過程で紆余曲折を経ている。 どうしても技術的負債は蓄積するし、どうしても汚いコードになる。 その中でベストを尽くして、負債返済・予防の取り組みを行う。

  • developブランチにどんどんマージして、開発環境でドッグフードして、壊れたところを直して……。
  • 軽い負債は案件開発のついでに直して、重い負債はテックリードが時間を費やして直して……。
  • 優秀な人が開発フローやシステム構成を整備することもあるけど、その人が辞めたらまた元に戻ったり……。

メインの売上を稼いでいる部門の多くは、何だかんだで、こういった流れになってしまうのかなと思う。 だったらもう最初からこれで行こうぜ、というのが私の意見だ。

せっかくの新規開発だからと「理想のアーキテクチャを描こう」「あのシステムのような負債は事前に防ごう」という気持ちは分かる。 だけど、新規開発でないと試せないような設計は、運用観点が未検証というリスクを伴う。 「◯◯システムで生じた技術的負債はこれなら予防できるはずだ(※まだ試したことはない)」は、別の技術的負債を招くだけだったりする。 「この設計なら問題は起きないはず」で着手して、いざコードを書いたら想定外の問題が起きる、というのはよくある話だ。

短期間で顧客を獲得しないと案件が中止になる状況で、技術面のリスクを取る余裕はない。 欲を言えば、プロジェクト開始時点では、過去に書いたコードを使い回す形で進めてほしいなと思う。 案件が始まってから設計に時間を掛けるのではなく、案件が始まる前にプロとしてテンプレートを持っておいてほしい。 テンプレートがないということは、これまで出来ていなかったのだから、今から時間を掛けても綺麗に設計できるとは限らない。 だったらむしろ、0→1は汚す覚悟で素早く始めて、後で見直したほうが、結果として早いのでは?と思う。

まとめると以下。 この流れにしてもらえると、0→1フェーズの企画責任者としては、非常に嬉しい。

  1. クラス構成、認証・認可、メール配信など、他システムでも出てくる設計ポイントは、再発明をせずに作る。
  2. 理想のアーキテクチャではなく、製品のリリースに専念する。
  3. 実装中にデグレが起きたら、内部改善チケットを起票して、テストコードを充実させたり、リファクタリングする。

改善余地:

1:既に述べた内容と重複するが、以下を仕組み化したい。

  • 「①10X → ②刈り取り → ③内部改善」のサイクルを回して③で返済しよう。
  • 「どうしても」と言うことであれば「◯曜日の午前」を負債返済に当てよう。

2:共通認識の醸成をもっとスムーズに出来ないだろうか。

  • 私は「どんどん汚してどんどん直そうぜ」作戦を提案している。
  • 反対意見は「せっかくだから時間を掛けてきちんと設計したい」だ。
  • 良し悪しではなく、好みや相性の問題だと思う。
  • アンマッチを避けるには、アサイン面談で「得意な働き方」「開発実績」「過去案件でQCDS目標をどう達成したか」をインタビューするのが早いかな。

スクラム(改善余地あり)

セレモニーとアイテムについては、スクラムのような形を取ることが多い。 SMロールにお金を払えるフェーズではないので「なんちゃってスクラム」だが。

なぜこれが大事か?

  • 「とりあえずスクラムっぽい感じで」と言いやすい。始めやすい。
  • 特にレトロスペクティブは良い。定期的な振り返りを通して、チームの課題を可視化できる。

改善余地:

1:スクラムという言葉を使わないほうが良いかな。 「開発プロセス」というドキュメントを用意して、セレモニー(会議体)とアイテム(文書・ツール)の手順・URLを書く。 「この進め方で行きましょう」と合意する。 これだけで十分かもしれない。

2:開発チームに閉じた改善活動は、開発チーム以外に負担を押し付けることがある。 リーガルやデザイナーから「困ります」と言われてしまうと、結局はPdM・PjM(つまり私)の負担が増える。 そして巡り巡って開発チームの負担が増える。

理想を考えると、開発チーム以外も巻き込んで改善サイクルを回せると、全体のバリューストリームを加速できるのだろうか。 「各チームごとの課題管理表」「チーム横断の課題管理表」を設けて「チーム内ふりかえり」「チーム横断ふりかえり」ができると良いのかな。

そうは言っても、週30分だけ相談に乗ってくれているリーガル担当に「毎週1時間のふりかえりに参加してください」とは言いにくい。 その手のロールには「月に1回」「チャット・メールで」「お礼を兼ねて」「改善フィードバックを求める」が関の山かな。

3:納期コミットに比べて短期的なパフォーマンスは落ちるように思う。 1週間のウォーターフォールと、1週間のスプリントだと、前者のほうがベロシティが大きくなる気がする。 これは人間の弱さだなと思う。

もともとスクラムの「スプリント」は「短距離走」という意味だと認識している。

  • 仕事時間は目先のゴールに向けて全力疾走して
  • 疲労困憊になって
  • 夜や休日はゆっくり休んで(休まないと疲労で動けない)
  • 体力維持のために運動・食事・睡眠にも気を使うようになって(でないと疲労で続かない)
  • オン・オフを切り替えられるようになって(でないと精神的に続かない)
  • 徐々に仕事もプライベートも全力で楽しめるようになって
  • ウォーターフォールでもスクラムでも、同じ全力疾走を行えるようになる
  • 納期があろうがなかろうが、同じだけのパフォーマンスを安定して出せるようになる

というのが理想かなと思っていた。

スプリント(短距離走)を乗り越えた先に、次のスプリント(短距離走)がある。 短距離走を重ねることで、気付けば長距離を走っている。 プロフェッショナルの仕事というのはそういうものだと思う。 ただ、これは私の理想であって、他人に理想を押し付けるのはエゴだ。

来週もスプリントがあって、間に合わないチケットを申し送りしてOKなら、多くの人は力を温存する。 その気持ちは分かる。 深夜休日に障害対応が発生するかもしれない。 どのみち納期必達案件が降りてくるかもしれない。 温存できるときに力を温存しようというのは、生き物の本能だと思う。

だけど、事業責任者の立場でスクラム(っぽい何か)を見ると、違和感を拭うことが出来ない。 期限に間に合わなかったらプロジェクトは中止になるわけですよ。 スタートアップなら倒産するわけですよ。 そういうプレッシャーを抱えているわけですよ。

「納期なし」と「納期あり」を比べて、後者のほうが早く出来るなら、後者を提示せざるを得ない。 「ゆとりのある納期」と「ゆとりのない納期」を比べて、後者のほうが早く出来るなら、後者を提示せざるを得ない。 「スクラムだから申し送りにしよう」と言う人がいると(主張の正当性は関係なく)「じゃあスクラムやめません?」と言わざるを得ない。 これだと悪循環に陥らないか?

だから、事業責任者側の落とし所としては、以下の単純なコミュニケーションで留めるのが健全だろうか。

  • 概算(1週間単位)で見積もって、バッファを含めて、スケジュールを引いて、WBSで進捗管理する。
  • 問題検知のためのセレモニーは、各チームで定期的に行って、週次定例でレポートする。

そもそもで言うと、アスリートのようなプロフェッショナリズムを、関係者全員に期待するのは無理がある。 ポテンシャルのMAXを引き出そうとする発想が不毛なのだと思う。 だから、スクラムの問題というより、最終的には、私自身の問題なのだと思っている。

  • 関係者全員がゆとりを持って行動できるように計画を立てる。
  • ゆとりがあるから、予期せぬポジティブが生まれて、期待を超えるパフォーマンスに繋がる。
  • 仮にポジティブサプライズが起きなくても、計画を達成すれば、投資した以上のリターンを(金銭面なり精神面で)関係者全員が享受できる。

それが「良い企画」なのではないか。 そこに私は責任を負っているのではないか。

  • 「このスケジュールは全力疾走を前提にしていないか?」をチェックする。
    • NGならスケジュールを引き直す → 関係者にスケジュールの見直しを連絡する。プレッシャーの中でNOを言うのは苦痛だけど仕方ない。
    • リスクから逃げずに何度か向き合えば、次からは同じ苦痛を避けようとして、見積もり精度が上がる気がする。
  • 計画フェーズでの「もっと早くできないの?」「もっと安くできないの?」という資金提供者(自分自身を含む)には具体案を相談する。
    • できることならば!もっと早くしたいし!もっと安くしたいよ!そりゃそうだよ!
    • 「高い目標を設定するのだ!」論は、マーケットの切り方に当てるべきで、大勢の人間が関わるスケジュールや財務計画に当てはめると破綻する。

開発着手前に2週間のSprint Zeroを設ける(分からない)

  • Developerに過剰な期待を寄せるのはナンセンスだと反省して、開発前に2週間のセットアップ期間を設けてみた。
  • Developerが全員でモブプロをして、基本的な処理(画面描画、デザインコンポーネント、WebAPI Req/Res、バッチ実行、DB CRUD、認証・認可、メール送信)のサンプルコードを作りながら、内部設計の共通認識を揃えてもらった。
  • 企画フェーズ(VOC→課題発見→製品発見)をPdMが丁寧に進めると、その期間はDeveloperの手が空く。そこでメンバーに「こういう時間の使い方をやってみたい」と提案してもらった。素晴らしい。

悩みポイント

  • 最近の取り組みなので、これが良かったのかどうか、まだ結果が出ていない。
  • Developer Experienceは良さそう。チーム視点では「クリエイティブ人材が心地よく働くための福利厚生」と捉えて、投資家視点では「工場を清潔に保つための投資」だと捉えて、前向きに受け入れていくのが良いのだろうか。
  • 仮に 1人月100万円 x 0.5ヶ月 x 5人 だと、半月・250万円を投資することになる。長期的に見ると安い気もするが、Y!コンビネーターが3ヶ月・300万円で初期リリースすることを考えると、どうなのだろうか。もし半年後にクローズになったら無駄になるし、ユーザー数が増えて機能追加が続くと設計も変わるだろうし、そもそもの「最初に綺麗なシステムを作る」という発想自体がどこまで良いのか分からない。

開発ロードマップを作る(分からない)

WBSで作業を見積もって、担当者の稼働を当てはめて、スケジュールに反映する。 「いつまでに・何を作るか」を文書化して関係者と合意する。 開発ロードマップ自体は過去に何度も作ってきた。 しかし、未だに咀嚼しきれていない。

これをやるべきか。答えはYESだと思う。 開発ロードマップがなければ、開発チーム外とのコミュニケーションが難しくなるからだ。

  • 「◯◯案件は3ヶ月後に着手予定です」「リーガルリスクについて調査をお願いします」とリーガル担当に言いたい。
  • 「◯◯案件の着手タイミングは未定です」「来週かもしれないし、3ヶ月後かもしれないし、3年後かもしれない」「調査をお願いします」とは言えない。言われたほうも困るだろう。

問題は、開発チームにどう協力してもらうか。 開発チーム視点だと、スケジュールを提示しにくい。 着手してみないと分からないことも多いからだ。 仮の提示案が独り歩きして、いつのまにか必達スケジュールになって、納期達成のために残業させられたら、そりゃ不満だろう。

『Inspired』だと「開発ロードマップ」は最悪の存在としてボロクソに叩かれていた。 『Inspired』におけるプロダクトマネージャーは「予算が既に与えられていて要件定義と関係者合意を取るためのロール」のように見える。 会社によってはテックリード(TechLead)やエンジニアリングマネージャー(Engineering Manager)がやっている仕事だ。 つまり開発チームに閉じた視点なのだろうなと思う。 それなら開発ロードマップはないに越したことはない。

しかし、「やってみないと正確なスケジュールが分からない」のは、開発チームだけの話ではない。 他の部署も、他の仕事も、同じことだ。 全員がそれを理由にスケジュールを提示しなかったら、全ての案件が行き当たりばったりになって、全てが破綻する。 予算の獲得・運用という概念を当てはめると(自分で会社をやるときは特にお金の話が付いて回る)ロードマップは避けて通れないと思う。

開発ロードマップが批判されるのはなぜか。 ストレッチな財務目標をそのまま開発ロードマップに無理やり落とし込もうとした結果の弊害なのだと思う。 財務計画とロードマップを繋ぐところが肝。たぶん。 どうしたらいい?

障害や開発遅延は必ずどこかで起きるので、バッファを積んで計画することになるだろう。 バッファを積んだ分だけ作業は伸びるだろう(パーキンソンの法則)。 かといって短い計画だと破綻するし、様子を見ながらだと順調なのかどうなのかが見えない。

要するに、ロードマップは必要だけど、万能ではない。 ロードマップを合意しても、資本効率の無駄は回避できない。 資本効率を最大化するには、別の施策が必要になる。

また、ロードマップが問題なのは、人事評価や契約と結びつく場合だ。 初期フェーズのロードマップは精度が低い。 人事評価や契約に使うのは無理がある。 特に文書契約で縛ってしまうと、軌道修正が困難になる。 確実に破綻する。 一方で、特に上場企業の社内起業の場合、人事評価や契約で秩序を担保したい気持ちも分かる。 スケジュールを宣言してほしい上層部と、宣言できないメンバーに挟まれてしまい、苦しい。

妥協案としては「今月はこれを目指す」といった期間・バッチサイズを限定したコミットメントになるだろうか。 ロードマップと開発スコープを、決裁者 ⇔ PdM ⇔ チーム で擦り合わせる。 フィードバックの機会を上手く活かして計画をブラッシュアップできるとGood。

とは言え、毎月のコミットメントを文書化する必要はあるだろうか。 開発会社側が受け入れるかは微妙だ。 仮に3ヶ月単位の納品スケジュール契約だとしたら、正しい流れとしては「課題発見」「製品発見」に最初のQを使うことだと思う。 開発要件をまとめてから、次のQで開発会社に「製品開発」のロードマップを提示する。これが筋の通ったルートだと思う。

  • ①遠回りでも筋を通すか(企画に3ヶ月を投資する)
  • ②チーム全員が狂気に浸るか(自主的な残業祭りで目標をハイ達成する)
  • ③確実に手の届く範囲で小さくやるか(2週間規模のシステムを3ヶ月開発で契約する)

どれかを選ばないと上手くいかないと思う。 消去法で①にせざるを得ないだろう。 これはこれで「システム開発しないのに3ヶ月契約するのか」「もっと早く企画できないのか」とか言われるかな。

うーん、やっぱり、必要なのはチーム横断のWBSで、それを線描としてビジュアライズして、関係者に示せば十分だと思うんだよなぁ。 ステークホルダーと握れていないのは、ロードマップとは別の問題として切り分けたほうが良い気がする。 特に資金提供者とのコミュニケーションは、資金需給マッチングに課題があって、お互いの期待にギャップがあるのかなと。

ユーザーサポート

問い合わせ対応(改善余地あり)

  • 利用者からの問い合わせに対応している。
  • SlackやFacebook MessengerやTwitter DMで個人が対応して、その様子をスクリーンショットに貼ってチームに共有している。

改善余地:

  • 雰囲気でやっている。
    • 問い合わせが来たら慌てて対応するし、問い合わせが来なければまぁこのままでいいか、になっている。
    • まともな問い合わせ窓口を用意できていないので、対応や課題意識が属人化している。
    • 顧客管理ツールやチケット管理ツールを活用して、定例ミーティングでトラッキングするほうが健全だろう。
    • 類似の問い合わせへの対応は、スクリプト(台本)を使い回したい。
  • リリース後は稼働の大部分がサポート業務に取られてしまう。
    • 顧客理解には絶好の機会だが「サポート稼働で製品改善できない」「製品改善できないからサポート稼働が増える」という悪循環に陥る。
    • そもそもで言うと、サポートに過剰な労力が掛かるのは、前工程が甘かったから。
    • SRE・ITIL的な発想で、稼働の何%をサポートに費やしているかを計測して、仕組み・体制・スケジュールを継続的に見直せるのと良いのか。
    • 収束が見えるなら安心できるし、収束していないなら収束にフォーカスすべきだし、一定の稼働が常に必要ならサポートチームを作るのも一手。
  • 誰が担うとベストか。
    • 結局はPdMが担ってしまっているのが現状。
    • 初期だと人員に余裕がない&顧客理解を深める観点でも全員で群がるのが理想か。
    • 顧客に寄り添う役割と、改善策を考えて推進する役割は、どこかのタイミングで分けたほうが良いのだろうか。

問い合わせ→インタビューに繋げる(改善余地あり)

問い合わせ対応の延長で、インタビューをお願いして、次の改善施策に繋げている。

  • テキストでそのままQ&A。
    • クリティカル・クエスチョンを出せると、早く回答してもらえる。
    • 質問が長文だと回答に時間が掛かる。スルーされることもある。
    • 質問が淡白だと回答も淡白になりがち。スルーされることもある。
  • 「いま5分くらい話せます?」でクイックコール。
    • チャットが2-3往復した後だと、応じてくれる可能性がある。
    • テキスト化しにくいネガティブな本音を聞ける。
    • まだ相手の考えがまとまっておらず、テキスト化できていないインサイトを検知できる。
  • 「コーヒーがてら30分くらいどこかで話せます?」でオンライン会話。
    • クイックコールがNGでもアポを取って話す。
    • 30分あると話は広がるので、問い合わせ内容に閉じずに、聞けることを聞いておく。

改善余地:

  • 急な仕様変更が重なってカオスになってしまう。
    • 問い合わせ → 改善チケット起票 → 開発 を繰り返したら、カオスになっていった。
    • 不具合は、障害対応フローで緊急対応する。
    • 改修要望は、VOC(顧客の声) → 課題発見(ペイン分析) → 製品発見(ソリューション検証) → 製品開発(システム開発)の流れに乗せたい。
    • 企画フェーズを経ずに開発すると、検討不足で二次災害を起こす。
    • ①10X → ②磨き込み → ③内部改善 において、①をリリースした後の問い合わせ対応を、②の企画フェーズに繋げたい。
  • 製品を直さずにサポートでカバーできないか?
    • 焦りの背景にあるのは「製品を直そう」という視点。長期的には必要。
    • 裏を返すと、短期的には「製品が直るまで使い物にならない」状態に陥ってしまっている。
    • 必要なのは「製品を直さずにサポートでカバーする」という選択肢を手に入れることだと思う。
    • 意図的に「開発者とは距離があるサポート担当」視点にスイッチして、課題に向き合うと良いのだろうか。
    • いや〜きつくない?その3分前まで開発チケットを書いているんだよ?これは慣れですかね?
    • カスタマーサポートの専任者がいたらすごく助かるような気がする。これは逃げですかね?

集客・販促

リサーチ目的での営業&広告(改善余地あり)

f:id:yuzutas0:20210327154730p:plain

既述内容と重複するが、見込み顧客を獲得しながら企画を行い、顧客ありきで製品を開発している。

  • ペイン検証でインタビュー
  • ソリューション検証でデジタル広告配信

改善余地(既述内容と重複):

  • システム開発と同様に、獲得施策についても、調査→設計→実施→計測→改善のサイクルを回したい。
    • インタビュー相手を探すための営業活動は、完全に雰囲気でやっている。
    • 事前登録者を獲得するための広告配信は、完全に雰囲気でやっている。
  • プラクティスやツールを使いこなせていない。
    • 例:Google Adwards でペライチのLPにアクセスしてもらうには、どういうキーワードをどう入稿すれば良いの?
    • 例:HubSpotのようなツールを使って顧客リストを管理したほうが良いの?
    • 専門家の知見を入れたい。

低予算施策 x 手数で稼ぐ(改善余地あり)

個々の打ち手は、かいつまんで試した。

  • プレスリリース
  • 紹介プログラム
  • キャンペーン
  • メディア掲載
  • ウェビナー開催

改善余地:

  • 雰囲気でやっている。
    • 「狙ったもの・ノリでやったもの」x「ヒットしたもの・ヒットしなかったもの」で分解すると「計画が不十分」だし「勝率は低い」のが実情。
    • どういうときに、どういう施策が効くのか、どう推進すると良いのか、どういう人と連携すると良いのか、まだ全然分かっていない。
    • マーケの専門家に力を借りるべきか。その人物はどこにいて、どういうインセンティブで、どういう相談をすると、お互いにGoodなのだろう。
  • 手数が足りていない。
    • つい開発チケットに逃げている自分がいる。
    • 200の開発チケットを書けたのだから、次からはマーケティング施策を200個やって数字を伸ばす……?
    • 「顧客を獲得(①)」 →「獲得した顧客が製品に感動(②)」を目指しているわけだが、②と並ぶ重要度の①に全力投球できていない。
  • アクセルを踏むタイミングもアクセルの踏み方も分からない。
    • Winner Takes All の領域だと、メルカリが一気に市場を食ったように、ここが勝負を決めると思うだが……。
    • いやまぁまだ全然そういうフェーズじゃないわけですが……。
    • 少なくとも、そのフェーズにおける予算で、常にCACギリギリまで踏んでユーザーベースを積み上げていく、という戦い方は身につけたい……。

適正価格を提示する(やってよかったこと)

  • 段々と出来るようになってきた。
  • とにかく「値段を示す」のが大事。
    • 逆の立場だと分かりやすい。
    • 相手に「自信がないので無料で1ヶ月」と言われると、発注しにくい。
    • 初手でコミットと値段を提示されると決めやすい。
    • 発注後の軌道修正・相談は、離脱の可能性もあるけど、残る可能性もある。
  • 低い価格を提示しがちだったけど、最初から適正価格を提示したほうが良かった。
    • 話が来るときは、なぜか一気に話が来る。
    • 最初は安い価格でもありがたいが、顧客が増えたときに、お金を払ってくれるところを優先せざるを得なくなる。
    • 優先してほしいならお金を払ってほしい、と思ってしまう時があった。
    • プラットフォームとして上手く同時解決したいのだけど、最初は人力オペレーションが必要だったりするので、このあたりは難しい。
    • 交渉結果として値引きすることはあっても、予算はMaxで確保しておいてもらう(せめて基準を知っておいてもらう)ほうが、お互いに良さそう。
  • 予算面を相談すると、顧客のBATNAや価格相場が見えてくる。
    • 本当はこちらから他社について情報提供できると信頼構築に繋がるのだろうけど。
    • 何を基準にして、どのサービスと比較しているのか、顧客視点で教えてもらう。
    • 全員が本音を話してくれるわけではないだろうけど、多くの人と話せば話すほど、値付けの範囲は見えてくる。

働き方

心の余裕を保つTips(やってよかったこと)

これらを意識してから一気に心のゆとりを確保できるようになった。

  • Whyを添えて、最小のタスクだけを依頼する。ゆとりがあるからこそ、メンバーが課題を見つけて提案してくれる。
  • 上流から設計する。枝葉の前に幹を固める。全てをウォーターフォールで考えるつもりでいると、結果として丁度良い塩梅になる。
  • バッファを置く。推定1日→1週間の調査期間を設ける。推定1ヶ月→3ヶ月の開発期間を設ける。内心の期待(=解像度が荒い故の希望的観測)の3倍を確保する。
  • 目標をシンプルにする。迷ったら削る。
  • 事実と感想・想像を区別する。想像ドリブンの「大丈夫そう」ではなく、モックアップでウォークスルーして「本当に大丈夫?」を確認する。
  • 関係者を集めて、腹落ちするまで話を聞く。後から新事実が出て前提がひっくり返るのを可能な限り防ぐ。

師匠に教えを乞う(改善余地あり)

  • PdMの本を読んだら色々と解決した。
  • @hisonl に相談したら色々と解決した。
  • 英語学習を兼ねて、海外のPdM向け記事一覧を読んだら、ちょっとずつ意識できるようになってきた。

改善余地:

  • もっと早く本を読みながら仕事をすれば良かった。
  • もっと早くメンターをお願いすれば良かった。
  • 毎日の英語学習にPdM Readingを取り入れよう。

私の振る舞いとして、車輪の再発明が多いように思う。 Developer時代の感覚をアンラーニングできていない。 Whatの発明に専念するには、Howを発明している余裕はない。

昼の30分で「一番の問題」を分析する(やってよかったこと)

1日30分、目標とのギャップを確認して、ボトルネックになっている箇所について、対策を講じる。

初期フェーズにおけるボトルネックは「目標・指標をトラッキングできていない」または「数字・進捗が悪すぎて人に見せたくない」箇所だと思う。 ステークホルダーへの週次報告に当たって、さりげなくレポーティングを省略したくなるような箇所。 最も不安で、最も目を背けたくなる箇所。

なぜこれが大事か?:

事業責任者が、そこから目を背けるか、そこに立ち向かうかが、そのままプロジェクトの成否に直結するから。

備考:

  • 昼間のカフェが良い。
    • 朝だと「起きたくない」という気持ちになって、スマホに逃げたくなるから。
    • 夜だと疲労でネガティブ思考に支配されるから。あるいは盛り上がって眠れなくなるから。
    • ミーティングの合間の30分だけ、カフェラテを飲み切るまで、といった制約があると、勢いですんなりと状況を整理できる。
  • iPad + Apple Pencil で絵を描くように整理するのが良い。
    • 悪い状況は、箇条書きよりも、悪循環(サイクル)のほうが表現しやすい。
    • ビジュアルで記憶すると、一瞬で思い出せる。
    • 何かを即決するときに「あのサイクルのこの箇所に該当する」「これだと悪循環から抜け出せないだろ」と自分にツッコミを入れられる。
    • 悪循環の各要素のうち、どの要素に対してアクションを打てるかを特定できる。そこにフォーカスできる。

朝の30分で「やりたくないこと」をやる(やってよかったこと)

  • 「一番の問題」を分析する、の派生バージョン。
  • スケジュール調整とか、仕様書のブラッシュアップとか。
  • 無視できないこと。必要なこと。
  • なぜか「絶対にやりたくない!」と思ってしまうときがある。
  • 起きてすぐ「よし!今日はダメだ!」となる。
  • 普段はモチベーションに左右されずに、淡々と作業するタイプなのだが。
  • 疲労が蓄積すると、自制心が効きにくくなるのかな。
  • 布団の中で自問自答をiPhoneのメモ帳に書き出す。「何が嫌なの?」→「アポ依頼が嫌だ」→「何で嫌なの?」→「◯◯(来週の楽しみ:食事とか)にとって都合の悪い時間になったら困る」→「連絡が早ければ早いほど調整しやすいのだから、なおさら早くアポ依頼をしたほうが良くない?」→「確かに」→「とりあえずアポ依頼を送ろうぜ!」的な。所要時間は約5分。
  • ジャージ姿のまま机に向かって30分だけ作業する。
  • 30分作業したら、なんだかんだで「楽勝じゃん!」となって、そのままズルズルと作業を続ける。

情報の洪水を捌く(やってよかったこと)

  • 大量のインタビューを行うと、情報量が多すぎて、脳の許容力を超える。
    • 思考停止→現実逃避でスマホを開く。
    • ストレス→お腹が痛くてトイレに閉じこもる。
  • そのままだと処理できないので、メタ認知で乗り越える。
    • メタ認知①:発散と収束の繰り返しで思考は進む。情報が多すぎるなら、分類しよう。
    • メタ認知②:1人でダメなら他人を頼ろう。情報整理を手伝ってもらおう。
    • メタ認知③:枝葉と幹を見極めよう。一番の問題は何で、どの情報が答えに近いだろう。
  • とりあえずアウトプットを作ってみる。
    • 決め打ちで手を動かす。
    • 完成品を見たあとで、インタビューの記録を読み返すと、重要な論点は絞られる。
    • 強制的に仮説思考。

ストレスの受容(改善余地あり)

背景:

ストレスを感じたときは、現実逃避をするが、最終的には「受容」して、対象に向き合うことになる。 私は恵まれているので、ストレスというより、プレッシャー(重圧)と表現するのが正しい。

仕事が怖い。 怖くてたまらない。 心が変化を恐れている。 ◯◯(売上)が◯◯円台に上がること。 ◯◯(投資)が◯◯円台に上がること。 ◯◯を本格的に扱うこと。 だけど逃げたら絶対に後悔する。 書き出せばメリットしかない案件。 恐怖心は挑戦心の一歩手前。 怖い。けど、逃げたくない。挑戦したい。 そういうチャンスに恵まれたことが、ありがたい。

自分のメモ(実際の内容)だ。 読み返すと、なかなかひどい。 早朝に布団の中で震えながらiPhoneのメモ帳に書き殴った。

やったこと:

死の五段階仮説という理論がある。 死に近付いた人間が、自分の死を受け入れるまでの、心の変化を説明した概念だ。

  1. 否認:自分が死ぬということはないはずだ(病気は直る・延命できる)と否認する。
  2. 怒り:なぜ自分がこんな目に遭うのかという怒りを周囲に向ける。
  3. 取引:悪いところはすべて改めるので何とか命だけは助けてほしい、と奉仕活動を始める。
  4. 抑鬱:取引が無駄と認識し、すべてに絶望を感じ、何もできなくなる。
  5. 受容:解脱の境地。希望ともきっぱりと別れを告げ、安らかに死を受け入れる。

引用元:死ぬ瞬間 - Wikipedia

そこで、これと同じことをして、プレッシャーを受容できないか?というのを色々と試してみた。

  1. 「こんなことしなくていいでしょ」と否定して
  2. 「なんでこんなことしなきゃいけないんだ」と怒って
  3. 「代わりにあれをやろう」と別のこと(英語学習とか)をやって
  4. 「やっぱ逃げちゃだめだよね」と絶望して
  5. 「アホなこと言ってないでさっさとやるか」と受容する。

この一連の流れを5分で済ませたら、それはもうプレッシャーを制御していると言っても良いはずだ。

結果:

ダメだった。 ストレスで「ううう」という状態だと、冷静に5つを順番に出来ない。

他に試した方法:

  • Youtubeで10分瞑想
  • 近くのコンビニや神社まで散歩して帰ってくる
  • ジムに行って5周ほど泳ぐ

結果:

こういうので十分だった。 特に瞑想は場所・時間を問わないのでGood。 ルーティーン化したい。

マインドフルネス瞑想入門

マインドフルネス瞑想入門

どこにいてもミーティングに出る(やってよかったこと)

病院のラウンジでも、タクシーの走行中でも、空港の電話ブースでも、ミーティングに参加できた。 いつでも、どこでも、どんな状況でも、企画に貢献できる。

なぜこれが大事か?:

  • カレンダーが詰まっていると、ミーティングのセッティングが上手くできない時がある。
  • しかし「今日は対応できません」を1度やってしまうと、ダラダラと長引いてしまう。
  • 特に初期フェーズの場合、PdMの意思決定が遅れると、チーム全体の進行が遅れる。
  • なので「ここにミーティングを入れられるかも?」と思ったら、迷わずにそこで会話する。

備考:

移動時間を仕事に当てるのもGood。

  • 自宅から駅はタクシー移動。アプリで手配すると朝6時でも5分で到着する。
  • 電車ではグリーン席。チケット購入&チェックイン方法を一度理解したら超絶ラク。
  • 空港ではプレミアムチェックイン→ラウンジ→プレミアムシート。普通に作業できる。
  • 徒歩の場合は、目的地に着くまでに、次の仕事の段取りを考えておく。先に脳内で設計する。

生活リズムを整えて毎日10時間の安定稼働(改善余地あり)

今のところは以下で稼働時間を確保できている。

  • 5:30に起床。運動。
  • 7:00に業務を開始。フル集中できる。
  • 11:00には力を使い果たす。この時点で4時間が経過。
  • ランチ→昼寝→コーヒーでリセット。気分転換にパスタを茹でたり、豆を挽いたり、神社を散歩したり、読書したり、銭湯に行ったり、泳いだり。
  • 午後も頑張る。
  • 17時前後で限界を迎えるので、少量のアルコールを入れる。牛乳0.8杯にマリブ0.2杯を加える程度。
  • 勢いで残りを片づける。
  • 20時には満身創痍&睡魔。

なぜこれが大事か?:

新規事業の企画フェーズはとにかく時間が掛かる。 仮に300時間が必要で、土日は休むと仮定しよう。 急スピードで立ち上がっているベンチャーは、事業責任者が毎日10時間 x 1.5ヶ月を費やしていたように見受けられる。 一方で、新規事業に毎回失敗していた某企業は、担当役員がその事業に週5時間しか費やせていなかった。 300時間 ÷ 週5時間 = 1.5年が必要になるが、半年・1年の予算見直しタイミングで頓挫してしまう。 成功の前提条件として、少なくとも初期フェーズの事業責任者は、毎日10時間を投下することが必須だと感じている。

改善余地:

  • これ寿命を削っているのでは?
  • これ病気や怪我で破綻するのでは?
  • せめて毎日泳ぐ時間を設けたい。
  • 毎日5時間 x 3ヶ月でも別に良いのでは?
    • と思ったが、人月契約の場合、要件が決まらないとチームの稼働を浮かせることになる。
  • 理想としては、自分の計画稼働を1日3時間まで減らしたい。
    • 浮かせた時間を次の施策開拓に再投資するとポジティブな成長サイクルを回せそう。
    • それ結局10時間の稼働配分が変わっただけなのでは……。

一番難しいのは普通にやりきることだと思っています。普通にやる、例えば朝9時半始業ならちゃんと来る。遅れた人はちゃんと責められる。目標決めて、達成できなかったらなぜできなかったか次の対策を考える、みたいな。ベンチャーは全部自分で決められるんで、自分で全て決めてっていうのがほんとに大変。そういう中でいかに心が折れないようにがんばるのかっていう部分ですね。

引用元:「ゲームとTwitterとFacebookしかしないなんてもったいない」、Gunosy開発チーム根掘り葉掘りインタビュー - GIGAZINE

毎日10時間のインタビューに耐えられる環境(改善余地あり)

ピーク時には毎日10時間、ミーティングやインタビューをぶっ通しで実施し続けたわけだが、真っ先にフィジカルがやられた。 少しでも身体ダメージを軽減するためには、労働環境を整備することが大事だと気付いた。

  • ①ペットボトルの水を手元に置く。
    • なぜこれが大事か?
      • ずっと話しているので、喉が痛くなる。
      • ふるさと納税で定期的にペットボトルの水を届けてもらっている。
    • 改善余地
      • オフィスの自販機やウォータサーバーは業者の人が補充してくださったが、自宅にダンボールを積むのは抵抗感がある。
      • オフィスのゴミ箱に捨てたら業者の人が処理してくださったが、自宅でペットボトルのゴミが大量に出ると面倒臭い。
  • ②大きなモニターを使い始めた。
    • なぜこれが大事か?
      • かつてはオフライン会議で移動が多かったのでラップトップ派だった。
      • 最近はオンライン会議でPC画面を見下ろしていると首が痛くなることに気付いた。
      • そこで開発者時代に使っていたモニターを取り出した。
    • 改善余地
      • モニターに繋ぐと、相性が悪いのか、ZoomやGoogle Meetが固まりがち。なんでさ。
  • ③窓の向こうに自然(できれば絶景)が広がって欲しい。
    • なぜこれが大事か?
      • ずっと近くを見ていると目が痛くなる。
      • 視神経へのダメージがヤバそう。
    • 改善余地
      • 残念ながら、自然(できれば絶景)は広がっていない。
      • ホテル暮らしのときは、アクセスを考慮して、駅・空港の近くを選びがち。
      • 多拠点生活なのだが、どの物件も都心部にある。
      • 地方に引っ越そうかしら。テレワークならば、色々と環境を整備できそう。

身体に負担を掛けないアクション(やってよかったこと)

  • 夕方以降に長時間の予定を入れない。ぐっすり寝て体力を回復する。
  • 朝はラジオ体操で全身を伸ばす。
  • 水泳で深く速く呼吸する。
  • 瞑想で焦燥感を流す。
  • 足が冷えたらお湯を張って足を突っ込む。温泉のある家で暮らしたい。
  • ずっと座って気持ち悪くなったら、10分だけでも散歩したり、カフェに行って、外の空気を吸う。
  • 膝にPCを乗せない。姿勢が悪くて、首・肩・目が痛む。ホテル生活期間は、部屋のデスクが広いか確認してから予約。

各タスク・成果物を「20点版」と「100点版」で分ける(改善余地あり)

  1. 20点版は1日で仕上げる。1日以上掛かるものはPdMがタスクを持たずに専門家に依頼する。
  2. 20点版を元にして、顧客・メンバー・専門家に、インタビューやテストを行う。
  3. そこで出てきた意見を全て解消して100点版に仕上げる。

なぜこれが大事か?

  • ルールを決めることが大事。いちいち検討せずに済む。即決できる。
  • 可能な限り早く仕上げることが大事。PdMがボールを持ち続けると、チーム活動が止まる。
  • 自分の妄想に依存しないことが大事。PdMが悩むような箇所は、もはや1人では解決できない。
  • 企画の品質を妥協しないことが大事。PdMが上流工程をサボると、その後の工程も手を抜くことになり、顧客に届く頃にはゴミができる。
    • 「まぁいいか」と手を抜いたところは、後で必ず問題になる。

改善余地

  • 短期的には手を抜く(後回しにする・100点を取らない)インセンティブが多すぎる。互いに高水準を期待し合うカルチャーが必須。

1つの事業にフォーカスする(できていない)

改善余地:

  • 自分の人生を幸福にするに当たって、かなり本質的な改善ポイントだと思っている。
  • 仕事を色々と抱え込みがち。
  • 1日10ポモドーロだとして、この10ポモドーロが全て1つの事業に関するものであれば、3ヶ月(900ポモドーロ)で売上を立てることは可能な気がする。
  • この900ポモドーロが複数の仕事に分散していたら、いくら試行錯誤しても圧倒的に物量が足りない。
  • 難しいのが「部活をやめたからといって受験勉強に専念できるわけでない」「むしろ出来るやつは部活も受験も両方とも上手く出来る」法則。

感動体験に日々触れる(やってよかったこと)

  • ダメなものを見ると、何がダメかは説明できるようになるけど「じゃあどうしたらいい?」を学べない。
    • 「こうしたらいいのではないか?」というアイデアは出せるけど、あくまでアイデアでしかない。
    • そのアイデアが実現可能か、そのアイデアで問題が解決するか、そのアイデアがベストなのか、何1つ分からない。
  • 良いものを見ると「こうしたらいいのか」を学べる。
    • 目が肥えるので「このUXが課題」→「こうしたら最高のUX」が瞬間的に出てくる。
    • 他のメンバーに考えを伝えるときにも「これをマネしよう」と言うと伝わりやすい。
    • 絶景レストラン!かわいい動物!ビジュアルの良さ!「最高の外見」は正義!WEBサイトのUIデザインと同じ!
    • 駅チカ物件!空港直結のホテル!アクセスの良さ!「最高の近さ」は正義!店舗のエリア戦略と同じ!
  • あと単純に自分のテンションが上がる。人生の幸福度。

ステークホルダー

体制図と自己紹介を書く(改善余地あり)

  • Google Slides にステークホルダーを書き出して、自己紹介ページを作った。
    • 以前は SpreadSheet で体制図を管理したり、Confluence にメンバー一覧や自己紹介ページを置いたこともある。
  • 体制図では一覧性を重視して記載する。
    • 体制図から自己紹介ページにリンクを張る。
  • 自己紹介ページでは、業務連絡先・役割・稼働曜日・スキル・経歴・ソーシャルスタイル・モチベーションなどを記載する。
    • 一方で、年齢・性別・誕生日・出身地・宗教・血液型・結婚有無などの個人情報は、無理に開示しなくて済むように心掛けている。
    • 趣味は微妙なラインだが、自己開示しあうことで、アイスブレイクになることもある。

なぜこれが大事か?:

  • 体制図と自己紹介ページがあると何かと便利。
  • コミュニケーションが必要なときに「この人に伝えておこう」と判断できる。
  • Aさん・Bさんに直接の面識がなくても「Aさんはこういう反応でしたよ」とBさんに伝えるときにも役立つ。
    • 「Aさんはこの人ですよ」と自己紹介ページを添えれば「ああ、なるほど!」と理解してもらえる。

改善余地:

  • ステークホルダー一覧については miro や Google Drawing を使ったほうが良いのかなと最近は考えている。
    • スライドツールだと、人数が増えてきたときに、表現の工夫が必要になる。
    • シートだと組織間の関係性を表現しにくい。
    • ドキュメントツールだと読みにくい。
  • とは言え、どのツールも一長一短あるので、まだ何とも言えない。
    • ホワイトボードツールのほうが体制を一気に変更した時の修正は大変そうだよなぁとか。
    • Google Docs や Spreadsheet で無難に済ませたほうが良いのだろうか。
    • 図だと関係者が10人を超えるとアップデートが苦しくなってくる。
  • 更新しなくなりがち。
    • 月次更新は2-3ヶ月で続かなくなる。
    • 新規参画者のオンボーディング時に「資料が古くなっている」「この機に更新しよう」が落とし所か。

ステークホルダー定例(分からない)

例1 例2
f:id:yuzutas0:20210327161256p:plain:w200 f:id:yuzutas0:20210327161311p:plain:w200

ステークホルダーとのコミュニケーションをどう担保するのか、が悩ましい。

案1:@hisonl に教えてもらった方法「ステークホルダー定例」

  • ステークホルダーを集めて定例ミーティングを開く。
    • 開発定例ミーティングとは別に行う。
    • アジェンダ・議事録は開発チームにも共有する。
    • 各個撃破だと伝言ゲームになる可能性があるので、全員を集めて会話するのがポイント。
  • 少しでも関わる人たちを巻き込む。
    • トラブルが起きたときに相談する人か? → YESなら呼ぶ。
    • 意思決定できる立場の人か? → YESなら呼ぶ。
    • 例:決裁者、広報、知財、法務、人事、労務、セキュリティetc...。
    • 1ミリでも不安点・不透明な点があったらその場で相談する。
  • 最初は企画の理解とリスクの洗い出しをお願いする。
    • 具体的な課題が見えてから相談するのでは遅い。
    • 具体的な課題を可視化するために相談の場を設ける。
  • その後は任意参加で呼ぶ。
    • 念のために時間枠だけは確保していただく。
    • アジェンダが安定してきたら必要なテーマの時だけ来てもらう。
  • ステークホルダーへのインプット。
    • 体制図、財務計画、ワオ体験、カスタマージャーニー、フローチャート、シーケンス図、プロトタイプ、システム構成図 etc。
    • ラフなスケジュール「いつ頃までに誰が何をするか」「いつまでに何が必要か」を箇条書きで管理する。

案2:@isbtty7 に教えてもらった方法「専門家インタビュー」

  • 各専門家に個別インタビューする。
  • 全員のスケジュールを合わせるのは難しい。
  • 小資本のベンチャーで、相談先がそれぞれ別の会社だと「全員を毎週集めてミーティング」は現実的ではない。

案3:折衷案「有識者会議」

  • 目的別にミーティングを分けて、そのトピックに関連する専門家を呼ぶ。
  • 決裁者・資金提供者へのレポート&ディスカッション。
  • コーポレート職種(法務・広報etc...)によるリスクチェック。

悩ましい点:

  • どのケースにせよ、1回のミーティングに、それなりの費用・時間・労力が必要なので、もう少し何とかならないものか。
  • ユーザー代表(CSやリサーチがユーザーの代理人になる形でもOK)がいたほうが良いだろうか。
    • 例えば「セキュリティ観点はOK」「利便性はNG」というA案について「もうA案でいいじゃないですか by 専門家一同」みたいな空気になるとキツい。
    • 翌週に「ユーザーに聞いたらNGでした」と伝えると「確かにそうですね、じゃあB案でも良いと思いますよ by 専門家」になりがち。
    • この1週間を短縮したい。
    • ミーティングの場に、セキュリティの専門家しかいなくて、セキュリティ面だけを考えるから、現実感のない机上の空論に陥るのではないか。
    • そこにユーザーが1人いて、具体的な顔が見えるだけで「現実的にはこういう落とし所になりますね」といった会話を促せないだろうか。
    • 一方で、ユーザー代表には、何も知らない状態であって欲しい。背景を知ってしまうと、認知バイアスが掛かってしまうのではないか。

Slack(改善余地あり)

プロジェクトのSlackを用意する。

  • ステークホルダー横断で相談するチャンネル。
  • メンバーの雑談チャンネル。いわゆる「times」チャンネル。
    • 進捗報告。
    • 悩みの相談。
    • 関係構築。
  • 関連会社とやり取りするチャンネル。
    • 報告・連絡・相談。
    • 請求書・報告書。
  • ユーザーを招いて、開発者とユーザーが直接会話できるQ&Aチャンネル。
    • 皆で一緒に作っている感。
    • 開発者目線:自分たちが作ったサービスが使われるのって超楽しいですね。
    • 利用者目線:自分のフィードバックがサービスに反映されるのって超楽しいですね。

改善余地:

  • チャンネルを増やすタイミングが悩ましい。
    • 財務などのトピック、特定の案件、システムアラート、などの余地は多々。
  • 視点が違うステークホルダーで互いの発言が見えるとこじれることがある。
    • 開発者が「あー、これバグですねー」(開発環境のみ)と書く → 顧客サポートが「バグ!?ユーザーに伝えないと!」と焦る。
    • 出資者が「これだけの開発費でまだ出来ないのですか」と書く → 開発者が「深夜まで頑張ります」とプレッシャーで焦る。
    • 1つ1つの発言に「こう思う人がいるのでこう書いてもらえると助かります」と言って理解してもらうのに労力が必要。
    • 短期的には「気軽に投稿して素早く案件を進めてほしい」vs「丁寧な発言で関係者と協働してほしい」のトレードオフに陥る。

ハッカソンのように毎日を過ごす(できていない)

1回くらい以下の働き方をチームで試してみたい。

  • 1時間ごとにGoogleMeetに集まって「やったこと」「次にやること」「ブロッカー」を共有する。
  • 途中で作業が止まったら、詳しい人に「時間をもらえますか」とクイックコールして、次のチェックポイントまでに一緒に問題を解決する。
  • これを朝8:00から夕方16:00まで続ける。11:00から12:00はランチタイム。16:00に仕事を切り上げたらプライベートを満喫する。1日7時間労働。
  • 1人1時間1ストーリーポイントを消化すると、6人チームなら210ポイントを消化できる。仮に30%の達成でも63ポイント。
  • 障害対応やハッカソンが好きな人には向いている気がする。お祭り感がある。

できていない理由:

  • 人によっては幼稚園の送り迎えとかあるので……。
  • 業務委託に稼働時間を強制できない。というか正社員でも強制するのは今の時代ダメな気がする。
  • というか自分が複数の仕事を持ってしまっている。

人材プール(改善余地あり)

  • 既にプールがあって「この分野ならこの人だ」とピンポイントで決めている場合は、その人に相談する。
    • スタートアップ系の記事だと「最高の人材以外を採用するな!」と書いてあり、それはそのとおりだと思う。
  • そうでない場合は、募集を呼びかけて、人材プールを作る。
    • 主に、Slack、友人へのMessage・DM、Twitter、Facebook、bosyu、Lancersを活用。
    • 「友人」or「友人の友人」だとお互いにマッチングしやすい。リファレンスチェックも行いやすい。
    • Twitter・Facebookは拡散機能があるので「友人の友人」に繋げてもらいやすい。たまに関係ない人からのクソリプが届く。
    • bosyuは自分の使い方であっているのか自信がない。サービスポリシー・利用規約が何度か方針転換しているように見える。
      • 追記:bosyuサービス停止らしい。
    • youtrustは良さそう。募集側アカウントの作成に一手間掛かりそうなので、まだ使えていない。
    • CrowdWorksは途中から使わなくなった。募集開始から掲載開始までに数日かかるので、募集文章をブラッシュアップしにくい。
  • 人材プールから相見積もりする。
    • 「10人と話した中でこの人が一番フィットしそうだ」と判断できる。
    • 逆境時に「他にもっと良い人がいたのではないか?」と現実逃避せずに済む。
    • 「10人のうちベストマッチだった」「それでも問題が起きている」「誰を選んでもこの問題は起きただろう」と割り切って、問題に向き合える。

改善余地:

  • ツールを固定したい。
    • 人材プールを毎回リセットしてしまっている。
    • LAPRAS Scout + Chrome Extension の全職版が欲しい。
  • 具体的にいつ何をするのか、業務フローを具体化したい。
    • 行動量を追えるようにしたい。
    • 自分が思っている100倍はアプローチしていかないと、期待のマッチングに辿り着かない。
    • 記事をPocketに投げ込むように人材プールを作っていきたい。

人材募集要件(改善余地あり)

  • なるべく細かい要件を1枚のドキュメントに書き出す。
    • 曖昧に書いた状態で着任すると「で、具体的に何をします?」と結局は後で業務内容を細かく定義することになる。
    • 実際に働く姿を想像しながら 6W3H で業務要件を書き出す。
    • 案件の魅力、提供できるもの、マッチしそうな人材、について明記する。
    • 募集要項はMust (必須条件)とWant(歓迎条件)を分けて書く。
  • ブラッシュアップ。
    • 類似事業の該当ポジションの募集要項を見ながら修正する。
    • ジョブインタビューを通して「これも明記しておこう」と思った点があれば、その場で文書をアップデートする。
  • 自分で上流と下流をやるつもりで募集する。
    • 私の期待水準は高くなりがちなので、Mustはなるべく狭く取る。
    • たまにすごい人が登場して、華麗に仕事を巻き取ってくれる。
    • 最初から求めると上手くいかなくて苦しい。
    • 覚悟を決めておくと幸運に感謝できる。

改善余地:

  • 炎上しかけた。
    • 「あなたは対象ではありませんよ」という人の目に留まると、トラブルの元になる。
    • 色々と思うところはあるが、足元を掬われるような甘さがあったことは事実なので、再発防止したい。
  • 募集要件を曖昧にしない。
    • 契約形態。私は請負・委任・準委任をまとめて「業務委託」と呼びがちなので、誤解を招かないように明確にしておく。
    • 終了予定日。とは言え「自分たちも継続できるか分からない」「継続するために助けてほしい」状態なので、せめて想定期間を提示する。事業継続可否の判定タイミングが分かっているなら、その情報も伝える。
  • レビューを受ける。
    • 募集対象職種の知り合いにインタビューして、記載内容が問題ないか、相場と乖離していないかを確認する。
    • HRやLegalのアドバイザーに依頼して、記載内容が問題ないかをチェックしてもらう。
    • 過去の取引先、委託先、卒業生に相談して、レビューしてもらう。
    • レビューのついでに、心当たりがあれば候補者を紹介してもらう。
  • SNS公開のオープン版と、知人限のクローズド版で、表示項目を変える。
    • オープン版は一部項目を隠しておく。
    • 特に金額面。多寡に関わらず難癖を付けられる。開示しないほうが安全。
    • 稼働面も注意。想定稼働を書かないと「働き方がイメージできない」と候補者(応募する人)に言われる。一方で、想定稼働を書くと「稼働時間を縛るのは法律違反だ」と第三者(応募しない人)に批判される。数字で書かずに「◯◯曜日だけ働いている人がいます」といった実例を提示するのが回避策か。
    • どのみちリファラルでのマッチングが多いので、詳細は個別メッセージで伝えれば十分。
  • 異文化に配慮する。
    • 例えば「想定工数0.5」の募集要項に対して「どうせ1.0になる」といった批判が寄せられた。私の周りには「◯曜日だけ作業」「◯曜日以外はチャットを開かず返信しない」「複数案件を抱えているので1.0を割けない」人が大勢いるので「1.0をお願いしたくても現実的に無理ではないか?」「依頼者や本人の工夫次第ではないか?」と思った。互いが見ている世界は明らかに違う。異文化を生きる人の目に留まったときに、その人の気分を害さないように書き方を工夫しないといけない。
    • 少なくとも「1度に1つの会社だけで仕事をするべきだ」「1つの会社が責任を持って個人の生活を支えるべきだ」という働き方・価値観の人は多いので、その事実は認識しないといけない。

候補者とのコミュニケーション(やって良かったこと)

やったこと:

候補者への返信メッセージのテンプレを用意した。 UIデザイナーの場合は以下。

ご連絡ありがとうございます。
◯◯の◯◯と申します。

もしご迷惑でなければ
1. 過去案件の実績・ポートフォリオをお見せいただくことは可能でしょうか。特に、◯◯や△△の□□案件があれば、ぜひ拝見したいです。
2. オンラインで30分ほど会話させていただけないでしょうか。実際に案件の話を聞いてみて、興味関心にマッチしそうかどうか、ぜひご判断いただければと思います。

いかがでしょうか。
よろしくお願い致します。

※もし希望の曜日や時間帯があれば教えてくださいませ。特になければ私のほうで候補日を提示します。
※現時点で気になることや不安な点があれば気兼ねなく仰ってください。
  • 1について:候補者が得意な領域と、今回お願いしたい領域にギャップがあると、業務が始まったあとにトラブルに繋がることがある。経験者を優遇したい。迷ったら断るようにしている。
  • 2について:テキストで長文を渡すとそれだけで離脱することがある。カジュアルに会話する場を設けたほうが話は早い。募集要項(GoogleDocs)を画面共有して、口頭でQ&Aを行いながら、誤解を招かない表記に変えたり、業務の解像度を上げたり、募集要件を磨き込むとGood。

お断りする場合は、基本的には理由を添えず(最後まで悩んだ場合は例外的に伝えることもあるが)「今回たまたまマッチングしなかっただけ」「今後マッチングする機会があるかもしれない」「狭い業界なのでその時はお世話になります」とメッセージを伝える。これは実際そうだと思う。

全集中のアサイン(分からない)

開発メンバーについては、以下のうち後者のアサインを優先するのが良さそう。

  • 「週1日 1人」「週2日 2人」「週5日 1人」(合計で週10日)
  • 「週5日 2人」(合計で週10日)

なぜこれが大事か?:

ワインバーグの表

f:id:yuzutas0:20210323133429p:plain

引用元:アジャイルチームにおける兼任問題を考察する

  • フルタイムでない場合、スイッチングコストが生じる。
  • 例外的に、週1稼働で効率良く価値創出できる人はいる。しかし、例外は例外。ほとんどの人はそうではない。
  • 基本は週5コミットできる人にお願いするほうが良さそう。

悩ましい点:

  • スイッチングコストを気にすることにどれだけの意味があるだろうか。
    • 週5だと週5で「週5もあるからまだ本気を出さなくていいか」みたいな働き方になってしまう人も多い(パーキンソンの法則)。
    • 作業時間の差よりも「この要件であっているのか」といったプランニングの差のほうが全体の進捗影響としては大きいのではないか。
  • 週5で稼働できる人材を探すのは難しい。
    • 実力がある人は稼働が空きにくい。
    • 数を打ちまくっていると、タイミングが上手くマッチングすることもあるが、運の要素が大きい。
  • 方針転換で待ちが発生しうる。
    • 初期は方針転換が起きることがある。ユーザーが増えて、フィードバックが変わると、企画フェーズがボトルネックになり、開発者が手持ち無沙汰になる。
    • 週5でスタンバイしてもらうのは申し訳なさがある。
    • スタンバイ期間中にお金が流れていくのは財務観点で苦しい。
    • かといって無理に案件を依頼するのはナンセンス。
      • 思いつきで仕事を依頼するのは単純に失礼。
      • PdMがボトルネックなのに、追加案件の要件定義&テストにはPdM工数が必要になる。最悪。
      • ユーザーが仕様変更に混乱したら本末転倒。

Developerに丸投げしない(改善余地あり)

  • まず、Developerはソースコードを書いて、リリースして、運用してくれているだけで、十分に価値を発揮している。そのことを感謝する。
  • 自主的に企画(要件定義)やQA(品質保証)まで踏み込んでくれたら、それは予期せぬラッキーだと言える。大企業では別のポジションが設けられている。
  • とは言え、小規模チームだと、企画(要件定義)やQA(品質保証)の一部をお願いせざるを得ない場面がある。
  • だから、Developerが前後工程にも貢献できるように、PdM・PjMである自分が環境を整える。
  • 例えば、Designerと一緒に画面の状態パターンを洗い出す会を設けたり、結合テストを開発スケジュールに明示的に含めて、協力を要請する。
  • その時間はコーディングできなくて当然なので、開発スケジュールは余裕を持たせることが前提。欲を言うと想定の3倍でスケジュールを引きたい。
  • こういった条件を揃えれば、実力を発揮して活躍してくれる。

背景:

  • もともと色々なことをDeveloperが自主的に担おうぜ派だった。 自分自身がDeveloperだったときは、そのように心掛けて動いていた。 だから周りに集まるDeveloperたちも似た価値観だった。 しかし、それはDevOps幻想と呼ぶべきものだった。
  • 現実としては、Developerはコーディングで一杯一杯になりがちだ。 意欲や能力がないからではない。 予算とスケジュールに余裕がないからだ。
  • 必要な開発要件は山積みだ。 しかも、Developerは1文字のtypoでエラーになる世界で戦っている。 「これはユーザーにとって使いやすいのだろうか」「この挙動でOKだろうか」と考えるには、切り替えが必要になる。 予算とスケジュールに余裕がないと、単価の高いDeveloperには、コーディングに専念してもらわざるを得なくなる。

改善余地:

  • チームの環境整備は大事だけど、ここばかりに時間を割いていると「話が分かる良い人」「だけど赤字事業」を脱却できない。
    • プロダクト運営は顧客の獲得→定着にフォーカスしないと滅びる。
    • 事業責任者が、画面要件定義・受け入れテスト・チームタスク調整・進捗管理をやっているようでは、一番肝心なことまで手が回らない。
    • 内側だけでなく、もっと外側を向きたい。
    • 枝葉だけではなく、もっと幹を見たい。
    • チームだけではなく、もっと顧客志向になりたい。
  • セットアップを省略できないだろうか。
    • リーダーが意図して調整せずとも、普段からDeveloper 1人1人が前後工程に貢献している会社はあるように思う。
    • 会社のブランディング、採用要件、財務計画、開発要件の作り方、スケジュールの切り方、プロセスの回し方など、適切な環境を作っているのだと思う。
    • これは素晴らしいと思う。可能ならそこを目指したい。

顧問(改善余地あり)

以前一緒に仕事をしたことのあるデザイナー(@hiroyanumata)に、1on1オンライン飲み会で相談に乗ってもらった。 めちゃくちゃGoodな体験だった。

  • プロダクトを画面共有して「ここはこう直したほうが良い」系のレビュー。要件を一緒に磨き込む。
  • 今のフェーズに必要なデザイン業務のスコープ。「これはまだ不要」「この業務を優先したほうが良い」など。
  • 募集要項にレビュー&ツッコミ。「これはモバイルアプリだけですか」「この要件に絞ったほうが現実的ですよ」など。
  • 候補者のポートフォリオを見て「この人はこういうのが得意そう」「この点は面談で確認したほうが良い」といったアドバイス。

なぜこれが大事か?:

  • 試行錯誤するよりプロに教えてもらったほうが早い。チームに迷惑を掛けずに済む。
  • セカンドオピニオンの安心感。客観的に見てもらえると、致命的なミスを避けることができる。
  • 信頼している&実力のある人は、すぐにはチームに招けない。稼働が空かないし、期待報酬を支払えない。だけど頼りたい。折衷案として顧問を依頼。

改善余地:

  • 各分野で信頼できる経験者に顧問をお願いしたい。
    • セールス、集客・宣伝、リーガル、会計など。
    • 全方位に「この人に相談しよう」と思えるほどのネットワークが今の自分にはない。
  • 顧問料の予算確保が悩ましい。
    • 仮に 10分野 x 月10万円 だと月100万円になる。初期フェーズだとこの金額は節約したい。
    • 人によっては「楽しく話しているだけ」「友人の相談に乗っているだけ」「お金は不要」と言ってくれるが、そこを基準にすると破綻する。
  • 顧問の必要性をステークホルダーに理解してもらうのが難しい。
    • 本当はむしろステークホルダーの人脈を活用して顧問を斡旋してほしい。
  • 顧問にお願いすることを明文化できていない。
    • 案件設計、案件依頼フォーマット、案件レビュー、人材募集要項、人材マッチング判断、etc。
    • 私は過去にTechLeadポジションだった。経験を活かして開発チケットを書いている。同様に、他職種でも依頼フォーマットを作ると良いだろうか。
    • ざっくばらんに一番の悩みを相談させてもらえば十分か。一番の悩みを解決すれば、改善インパクトは大きいはず。

タレントマネジメント(出来ていない)

改善余地:

  • もっと人の良いところを伸ばすような関わり方をしたい。
    • Will・Can を活かす。1on1を重ねて、相手のことを知り、アサイン&メッセージングの機会を見つけたら、必ず一言添える。とか?
    • 利害関係を整理しながら物事を進める。ステークホルダーへの影響をホワイトボードに書き出して、必ず各自に個別フォローを入れる。とか?
    • ミクロ経済学、ゲーム理論、行動経済学、あたりのトピックに近い気がする。
    • それこそタレントマネジメントに詳しい人事担当者に相談しながら進めるのが良さそう。
  • 私は「困難を乗り越えてナンボ」の価値観から抜け出せていない。
    • 「困難を乗り越えてナンボ」は、HARD THINGS を突破するために必要な価値観。そして HARD THINGS は必ず訪れる。これは事実だと思う。
    • しかし、HARD THINGS は事業責任者に降りかかるのであって、必ずしもメンバーに降りかかるわけではない。
    • 無意識のうちにこの価値観をメンバーに押し付けてしまいそうで怖い。
    • パワハラのようなコミュニケーションをしてしまうと、全てが破綻する。
  • 自分自身にとっても百害あって一利なし。
    • 無理して勝とうとする悪癖は払拭したい。Will・Can に沿って依頼したほうが成功率は上がる。
    • いつもご機嫌で皆を笑顔にする爽やかイケメンになりた〜〜〜〜〜い!
    • 怒りプンプンおじさんは子供の教育に悪い。悪いところをマネされたら困る。
    • 脳が衰えたときに、タレントマネジメントが定着していないと、周囲と関係構築できなくなって、悲惨な老後を迎えそう。
  • 最高の機会を提供できる企画屋でありたい。
    • 「こいつの企画に関わったら自分の人生が充実する」と思ってもらえるような、そういう存在でありたい。
    • 人に聞いたり、人に助けてもらったり、人と関わることで、分析が磨き込まれ、製品ができるわけですよね。
    • 人の可能性が広がるような「場作り」を含めての、広義の「企画」ができるようになったら、1つレベルアップするのではないかと。

おわりに

雨が降ったら傘を差す

あえてざっくりまとめると、高い目標を達成するためには

  • 自分が思っていた以上に、沢山の投資(時間・資金・労力)が必要になる。
  • 自分が思っていた以上に、前工程で品質(UX・施策・設計)を担保したほうが良い。
  • 自分が思っていた以上に、ヒトはAgile&DevOps(全力疾走・役割横断・プロフェッショナル)になれない。

といった形で、自分の認知バイアスを突破する必要がある。 自分の妄想・神話・理想を、他人に押し付けるんじゃねぇよ、ということだと思う。

雨の日には、雨に不満を言うのでもなく、晴れの素晴らしさを語るのでもなく、「雨が降っているな」と確認して、傘を差す。 天気予報を確認して「雨が降りそうだな」と傘を事前に用意する。 それだけでいい。 自然現象に逆らうのではなく、適応すれば良い。 人間・製品・技術・お金についても同じで、原理原則に逆らうのではなく、適応すれば良い。 事象を観察して、情報を収集して、仮説を立てて、上手いことやっていきたい。

アンラーニング

「企画」「ビジネス」と一括りにしがちだった。 「プロダクトオーナー」「プロダクトマネージャー」と一括りにしがちだった。 しかし、業務で取り扱う粒度としては、もっと沢山の要素に分解できるのだと思い知った。

「ビジネスを理解して企画に染み出せる◯◯(職種名)です」と自分を売り込んだことがあった。 「自分が企画担当だったらもっと上手くやれるだろう」と内心では思っていた。 しかし、本当に事業責任者になったときに「マジで何も分からない」「迷惑を掛けまくってごめんなさい」と思った。

最高のUXを提供するのは、めちゃくちゃ難しいなぁと思う。 利用者や評価者の立場なら、いくらでも改善余地を指摘できる。 しかし、企画者・意思決定者の立場になると、本当に難しい。

現実を観察して、過去の成功体験をアンラーニングしないと、次の成功を勝ち取れない。 この事実をようやく心が受け入れ始めた。

遠すぎて見えない

プロダクトの企画はとても難しい。

  • 必要な資金を調達して
  • 1円単位で最適な投資を行って
  • 多くの人に動いてもらって
  • 最高のサービスを実現して
  • 1秒でも早く顧客に価値を届けて
  • 投資を回収できるだけの売上を得る

どれ1つとして満足できるレベルに達していない。 途方もなく難しいと感じる。

連続起業家たちが羨ましい。 次々とコンセプトを実現する人生が羨ましい。 どれだけ遠くにいるのかさえ分からない。

打席に立ち続けること

成功者たちと自分を比べたときに、単純に「金儲け」に対する挑戦回数が少ないなと思っている。 1つの企画コンセプトに対して、投下時間・コストが少ないし、リサーチ・テストの量・回数が少ない。 そういった意味では「打席に立ち続けること」の重要性を感じている。

どうやって打席に立つか。 例えば、1つのアイデアについて、30日間、毎日1時間をリサーチとLP作成とプロトタイピングに当てる。 LPの事前登録で、1,000社×300円/人×10人=3,000,000円/月(300万円)を稼げる自信を持てたら、 週3稼働のフリーランス人材を4人抱えながら、同時にデジタル広告へと投資することができる。 この取り組みを10年間続けることができたら、12ヶ月 x 10 = 120個のアイデアを試せる。 120のうち1つでもホームランを打てば、少しは見えてくるものもあるだろうか。

打席を立つときの障壁は何か。 1番は「他者に迷惑をかけることへの恐怖」だと思っている。 企画を実現するに当たって、資金を提供いただいたり、労力を割いていただいたり、様々な人に迷惑を掛けている。 だから「なるべく配慮すること」「なるべく誠実であること」は大前提だと認識している。

その上で「他者に迷惑をかける覚悟」も必要だと思っている。 これはもう覚悟するしかないのかなと。 生き物として他者の命を奪って生きている。 社会生活を送る中で他者に迷惑を掛けられることもある。 そこから学べることもある。 同じ事象に対して「迷惑を掛けられた」と思う人もいれば、そうでない人もいる。 そこは受け取る側の問題だと割り切る。 せめて自分なりにベストを尽くして事に当たる。 そういう勇気を持たないと、打席に立ち続けることはできないのだと思う。

超長文からの卒業

さすがに反省した。

  • Executive Summary をまとめる力。
  • 枝葉ではなく幹を伝える力。
  • 前工程でコアUXを磨き込むする力。
  • ウォーターフォールを進める力。
  • センターピンに狙いを定める力。
  • 勝ち筋を特定する力。
  • 1つの事業にフォーカスする力。

いずれも抽象化すると同じものだと思う。 これを身に付けないと、望む成功には辿り着かない。

まとめ

全ての観点をハックしよう。 素直な心で問題と向き合って、1つ1つ解決していくと、徐々にコツが見えてくる。 ストレスとしてお腹の中に抱えるのではなく、遊びのネタとして楽しもう。 毎日が観察と実験の連続だと思えば、これほど愉快な遊びもないだろう。

どうにもならないことを鬱々と悩み、天気予報に一喜一憂するくらいであれば、どんな天気であっても受け入れて、雨が降れば傘を差し、晴れたら薄着をしていこう、と構えているほうがよほどいい

あるキング: 完全版 (新潮文庫)

あるキング: 完全版 (新潮文庫)