目的地を決めるまでのあれこれについて
目的地を決めてからは楽なんですけどね。同じところぐるぐる回ってる感が非常に強くて焦りがでてくるポイントでもあり、今後も同じところで焦って変な意思決定をしないように、メモを残しておくことにしました。コードなんかないのでポエムだと思っていただければ。
目的地というのは「作りたいプロダクトとそれによって実現される世界」です。「どんなプロダクトを作るか」って考え始めた時には、今いる地形も目的地も何もわからない状況にあったりします。今いる地形はもしかしたらわかってるかもしれませんが。次に自分たちはどこにたどり着きたいのか決めるまでには、少し落ち着いて周りを見てから、どこにいけばいいか、最低限方角はどちらか、どんな目的のためにここから先の移動をするのか？あたりを計画しなければなりません。
なんですぐにスタートしないのか？
それはもうビジネスだからですよ。自分のプライベートな時間を使う興味のプロジェクトであれば、最初の思いつきから始めていってもいいし、そこからプロダクトのゴールが開けることもあると思います。
ただ、企業でビジネスをしている以上、新しくプロダクトを作るということは投資なわけなので回収が必要です。本当は定まっていないのにコストをかける決定をしてしまうことが一番怖いわけです。その決定をするまえに少人数のコストが必要であればそうするべきだし、もし「我々がする必要がない」という結論に至れば、そもそも無駄なコストをかけずに済むわけだし。
なので、少なくとも新しく作ろうと思っているプロダクトが進むべき方向に関して、会社の目指すビジョンに沿っていて、なおかつコストをかけるだけのビジネス上の価値があります、ということはビジネスサイド(つまりは金出してくれるところ)と合意してスタートさせる必要があります。投資の判断をする人たちとちゃんと意識を合わせようぜ、ということ。それにね、この辺の腹落ちしてないと開発チームに対して意思決定を自信持って説明できないと思いますですよ。
決めなきゃいけないこと
で、私が今回のプロジェクトで「これが合意できないうちは開発チームの立ち上げはできません」とした項目は以下の5点です。
- 現時点でのプロダクトの最終的な姿は？(ゴール)
- それによって実現される世界は？(ビジョン)
- そのためにどういう順序で何を達成する？(今後1〜2年のロードマップ)
- それはいつまで？(具体的なマイルストーン)
- マイルストーンを達成するためのチーム編成の計画(大雑把な見積もり)
ロードマップは、ユーザからの反応次第で変わる可能性があります。もしかしたら1と2は問いの順番が逆かも？1,2以外は、一旦スタートした後は、プロダクトへの反応次第で少しずつ軌道修正しながらプロジェクトを走らせてもいいのではないかと思ってます。1,2が変わるようであれば、そもそも投資について一旦立ち止まったほうが良さそう。。。
この辺は立ち上げ期だといくら投資するか、とかそれを元に経営会議でプロジェクトのスタートを決める、とかに関わってくるのであまり焦ってチーム立ち上げてもしゃーないな、というのがやってみた感じとPMJPで議論していて思ったこと。
ゴールとビジョン
何か達成したいことがあるはずなんですよ。そこを明確にしないと全てが始まらない。 そこにたどり着くまでの段階は？経由地は？移動手段は？と少しずつ詰めていくことで、自分たちがどういうものを作り出したいのかを知らないといけません。よく我々エンジニアがたとえに使うじゃないですか「顧客が一番必要だったもの」。あれは、ゴールとビジョンが浸透していれば、防げるんじゃないのか、と思ってます。
地図を広げすぎないこと
「あれもこれもできるように」は「何にもできない」と同じだと心得てプロダクトの形とロードマップを企画しました。ってかですね、ユーザに価値を提供してお金をいただくサイクルができるまでは無尽蔵にリソース突っ込めません。最小のコストで最大の効果を得なければならないので、「これがないと成り立ちません」くらい最小限のところでプロダクトを決めないとプロダクトそのものが継続していかないリスクを常に抱えていくことになります。
それに、ユーザ目線で見ても人間は一度に多くのことを要求されるサービスやインターフェイスは、使い勝手から離れてしまう傾向があります。フローが明確で絞り込まれたもの使い勝手を提供して、ユーザに親しんでもらうことに注力して、あまりプロダクトを盛りすぎないほうがいいのではないかと思いました。
ハンドリングしやすいツールがあれば迷わずに変更する
当初、仮説キャンバスのフォーマットを使っていたんですが、フォーマットを用意して書いたりするの面倒だし、redmineに添付でしか展開できないのもなあ、と思ってたらPMJPで yamotty さんが使っていたフォーマットがwikiとかでも使いやすかったのでそっちに変更しました。考える項目がよりシンプルになって、自分が説明するときにも理解しやすくなった気がします。
ユーザストーリーマッピングも少しやり方を考え中。このやり方で得られるストーリーの構造は欲しいけど、アプローチや管理は違うほうがハンドリングしやすいかもしれない、とかとか。
企画の9割はゴミ
ま、そもそも企画とかやったことないっす。自分が思いつく程度のものは「穴がある」か「そもそも欲しいと思われてない」か「すでに誰かがやりきってる」のどれかだと思ってました。とはいえ、数出せばましなものが出てくるだろうは思ってましたし、どちらにしろプロダクトの形を考えないと進まないので、システム思考とデザイン思考のワークショップを試してアイデアを出してみたりしたわけです。アイデアは質より幅が重要。私一人じゃ無理。
もちろん不安なので、感触をつかむためにいろんな人に企画をぶつけて質問をしたりしています。特に、一緒にやってくれる人が思いに乗っかってくれる企画であること、というのは一番重視した反応です。手段(プロダクトが実際に取る形)に正解はないので、それを価値だと感じてくれる人がどれだけいるか、という裏付けにしたかったからです。で、目的やKPIなどをシンプルなフォーマットにして人にぶつけてみるしかないわけですが、この段階でのやりとりをする上で、前項のフォーマットの変更がありました。何回かアイデアをぶつけたりしていて、仮説キャンバスがちょっとメンテナンスしづらくなったと。。。
その結果として得られた結論は、衛生要因だと思っていたことが実は価値だったということ(今回のプロダクトのケース)。ちゃんとフォーカスすべき価値に気づけたのは成果と言っていいのではないかと思いました。
これから押さえないといけないこと
まあ、ご想像の通り、やっとこさ目的地は決まったわけですよ。そうなると、これから進めていくことを考えて、私自身のスキルとして足りないものが見えてきました。
- 配色、色についての基礎知識
- UX、IAについての基礎知識
- マーケティングについての基礎知識
一応ね、それぞれ最終的にはプロフェッショナルに相談できる体制を整えておくことは必要なんですが、「どういう基準で、どの領域に対して意思決定をするのか」をスムーズに話できるようにするために、最低限の知識は押さえておく必要がある、と感じたわけです。前者二つは岡Webに参加したほうがいいかもしれないですね。マーケティングはPMJPでおすすめが上がっていたので読んでみようと思います。
