今担当している新規開発プロジェクト立ち上げ期にやってみたこと
別名、プロダクトマネージャへの長い道シリーズ第一弾。今、新規開発プロジェクトの担当としてプロダクトの定義から開発計画など全般的に取り仕切るポジションで動いています。自分の中ではプロダクトマネージャが一番近い仕事像。基本手探りなんですが、楽しいです。
9月からもろもろプロジェクト開始に向けた下準備やら情報収集やらジミーな仕事をしていたのですが、これは本エントリでまとめたいこととは違うので割愛します。11月にプロジェクトの体制が決まってスタートしてから、とりあえず開発のスタートを切ることを決めるまでにやったことをまとめます。
自分のポジション(ミッション)の定義
手探りでやるにしても方向見極めながらしたいし、迷子になるにしてもなり方があるだろうということで、今回自分がどういうポジションで、どういうミッションを達成すべきか定義してみました。参考にしたのは下記エントリ。
特にこの辺。
プロダクトマネージャーは、ユーザーの理解とロードマップの企画や提案、製品の企画、ユーザー体験のデザイン、リリースされる製品の品質確保までトータルにマネジメントする役割です。要するに「その製品はあいつが作った」「こいつが考えた」というその人に相当します。
プロダクトマネージャーはいわゆる世間で言うところの「企画職」のようにも見えますが、彼らの役割は企画を立ててあとは開発に任せて終わり･･･ではなく、その後の開発プロセスが回ってる間の開発の支援や開発中の意志決定、製品の品質確保、リリース、その後の改善の企画までをトータルに見ていくので実態としては少し異なるでしょう。
より良い製品やサービスを作るためには「健全な意志決定の偏らせ」、つまりある種の独裁制が必要だと思っているからです。
これがいきなり全部できるようになるとは思っていないので、今回はもう少しゆるふわっと定義してみました。
- アイデアからビジョンを抽出し、
- ビジョンをプロダクトとして成立するレベルに落とし込み、
- プロダクトとして現実的なリリース計画を管理する
上記の遂行ももちろんですが、これがうまく回るようなプロセスの管理も行います。事業の核となるアイデアを思いつく人ではありませんが、それをうまくプロダクトに導けるように、という定義です。その過程で、誰よりもビジョンを知ることや誰よりもプロダクトを愛することが必要になるとは思いますが。
やったこと
スコープ
- 期間は11月〜1月現時点までの2ヶ月強
- フェーズはターゲットの設定からビジネス的な1stリリースの整理まで
プロセスも含めて手探りなので、ステークホルダーが少ない今のうちは定例ミーティングで状況を進めてTODOを出し、次の定例ミーティングまでに調査やタスク遂行を洗い出して、私がまとめてやることにしました。実質私の一人プロジェクトみたいなもの。。。
実施期間での観点
1stステップをいかに早く合意するか、ということをまず考えました。自信持ってないけど、これ以上は考えても仕方なくて、フィードバックをもらうしかないという状況で積極的に動き出しにつなげるために「この件について話ができるのはこれが最後ではありません」ということを何度も言っていた気がします。プロジェクトが継続している限りは軌道修正ができますし、細かくフィードバックがもらえれば軌道修正も楽なので。
それから、すぐに各論に飛びつかずにちゃんとビジョンとプロダクトの全体像を作ることに意識を向けました。今まで他のプロジェクトを見ていて、このレベルの共通認識が足りてないのではないかと感じたので。
また、進める上で幾つか参考にしたプロセスがあるのですが、プロセスを守ることではなく基本的にスピード勝負で積極的に代替案の実施や順序の入れ替えをしていこうと意識しました。具体的にはインタビューですね。最初の仮説を検証するためのインタビューをユーザに実施するところが時間がかかりそうだったので、インタビュー対象を変えてなるべく早く小さく作るとか。
最後に、チームを急激にスケールさせないこと。ビジョンの検討も開発も。これにはフィードフォースさんでディスカッションしたことが反映されています。新しいことを手探りで進めていくにあたって、人が多くなるとズレをコントロールできないですし、スケジュールの遅れはだいたいこういうズレを埋めていくところで発生しますので。
とりあえず情報収集
本気でどこから手をつけていいのかわからなかったので、本を読むところから始めました。読んだ本は以下。
- 今日からはじめる情報設計
- サービスデザイン入門
- ユーザーストーリーマッピング
仮説キャンバス
ある程度流れにイメージがついたら、これから作るプロダクトがどこを目指すか、どこを狙うかをはっきりさせるために仮説キャンバスというやつを作りました。ちなみにこの仮説キャンバスは、ギルドワークスさんが公開されていた資料からフォーマットを使わせていただいています。リーンキャンバスでも良かったのかもしれませんが、各ブロックの内容がこちらの方がしっくりきたという感じです。
で、キャンバスを書くにあたって、いきなりステークホルダーに一緒に書きましょうという話をしても私もステークホルダーもついていけないので、まずアイデアについてAsIsとToBeをざっくりと図示し、それを元に私がキャンバスを埋めてみてそれを定例ミーティングに持ち込みました。私自身で消化したものに対して議論しながら進めることができたので、やり方としてはあながち外してはいなかったかな、と。だいたい固まるまでに二回のミーティングを要しました。
有識者へのインタビュー
本当はここでユーザーになりうる人へのインタビューをしたいところではあるのですが、現状チャネルを持ってないこと、それが可能になるのを待つのは時間がかかりすぎるのではないか、という議論が出てきました。そこで、ビジネス領域となる業界をよく知っている社内の有識者にインタビューして、仮説の感触を聴いてみることにしました。ユーザ当事者ではないので、仮説への絶対的な自信がついたわけではありませんが、それでも得るものは大きかったです。残りはシンプルに作ってフィードバックをもらうことに。
なお、上記を補強するために個人的な観察レベルで収集可能なところについては実施しています。妻に「こういうときってどう思う？」とか聴いてみたり。
議事録ちゃんと書く
どういう情報が必要になるかわからないので、公式非公式を問わず、ミーティングをしたらとにかく議事録を書くようにしました。というか誰も書かんし、合意事項なんかは残しておかないとプロジェクトが迷子になるし。
ジャーニーマップ(ストーリーマップのバックボーン)作成
今ここ。ビジョンや仮説がある程度見えてきたので、作ろうとしているものはどのくらいの人を対象にしたどのくらいのものなのかを把握するために、かなりラフではありますがストーリーマップ(ジャーニーマップのレベルかも)を作成しました。
大きな目的は、ユーザ体験とユーザ、アクティビティと議論が足りてないところの洗い出しと全体像の可視化。マップを作るときにプロダクトで実現するわけではないけど、ビジネス上大事なこともストーリーとして洗い出しています。もしかしたらプロダクトで実現する部分になるかもしれませんが、少なくともここで上がったことは今後議論の俎上にあげて決断しないといけないことが多かったです。
これからやること
- 業界の展示会に参加して情報収集
- ディスカバリーチームを作ってストーリーの掘り下げ
現時点で感じているストレス
役割として非常に楽しいところではあるんですが、それでもストレスに感じることはあります。自信がないのに決断しなければならない状況に起因してるんですけどね。
事前にある程度の情報を得ていて脳内リハーサルはしていたとはいえ、そもそも進め方がうまくいっているかよく分からない状態で、進める、つまりこの部分については投資をするということを決めるのは、責任とか諸々結構感じます。プロセスも手探りなら、進めて確認する以外に何がある？という腹のくくり方をしているだけです。少なくとも自信がつくまでは投資額が膨大にならないように、少人数チームで最小限のプロダクトになるように常に気を使っていきたいと思っております。
こういうときに注意が必要なのは会議なんですね。議論をするのは良いけど、会議が踊っちゃダメなんだ。議論してると気持ちいですし、議論して満足してしまいたくなる誘惑がすごい。結論出さない議論は満足感という点では麻薬です。議論し尽くすことではなくて、具体的な行動に移すためのマネジメントをしたいと思いました、まる。
