整理する何をすればいいのかわからないというというカオスな状態だったので、まずは整理が必要だと思いました。(ブランド醸成に関わり、主にコンテンツの制作を行なっている)、そして開発部として、プロダクトに変更を加える施策として何を考えているのか、ヒアリングすることから始めました。サーバーサイドエンジニアとして様々なデータを扱っていたり、管理サイトの構築などを通して他部署とのコミュニケーションがあったので、部署間でどのような施策を考えているのかは肌感はありましたが、さらに具体的に聞くことで、工数見積もりやそれぞれの部署でのプライオリティの高さなどを聞くことで、施策の解像度を高めていきました。優先度を決める全ての部署が一つのプロダクトを良くしようと動いていたとしても、基本的には開発リソースは一つで、ほとんどの場合それもパツパツだと思います。その中で、何をすべきかを考えることは容易ではないし、その意思決定はその時の気分に左右されることなく、再現性がなければなりません。Bizサイドの諸々をコーチングしてもらう時間を設けてもらいました。プロダクトの行く末を左右するプロダクトマネージャーには会社のほぼ全ての情報を頭にインプットしておく必要があります。そのため、経営層の考えを聞くことは不可欠でした。各部署の責任者であるジェネラルマネージャーは部署間で情報を共有できていたとしても、プロダクトに変更を加える必要がある各部署の大小ある施策の全て頭に入れておくことは難しいと思います。そのため、プロダクトマネージャーは全ての情報を自分に集積し、今会社にとって解決しなければならない課題は何かを決定しなければなりません。各部署で優先度が高い施策であっても、それがプロダクトにすぐに反映できるとは限りません。その優先度を決めた背景をロジカルに説明する責任も同時にプロダクトマネージャーが負っているわけです。実行するなぜ、今その施策をするのか。施策のwhyを開発に関わる全ての人が知っていることはとても重要です。納得感を持って開発できるかが施策の良し悪しを左右することもあると考えています。その責任もプロダクトマネージャーにはあります。そのためには、ドキュメンテーション能力が不可欠です。僕は、ここで自分の意思決定を言語化することにとても苦戦しました。あらゆることを総合して考えて意思決定を行なっているので、それらを順序立てて、全ての人に理解してもらえる粒度で言葉に落とすことはとても難しいです。そのため、自分のドキュメントで納得していなさそうなメンバーが入れば席まで行って、納得してもらえるまで議論することもありました。実際の開発では今まで実装段階ではアジャイルを取り入れていたものの、要件定義をウォーターフォールで行なっていたがために、課題はあっていても解決策が間違っているということが度々あり、それが開発での課題となっていました。要件定義もアジャイルで行おうという、前述したリーンな開発プロセスの定着にメンバーとともに注力しました。要件定義フェーズでは、最初は細部まで介入して、それらが上手く回るようにフローの改善を行なったりしていました。部署間で実行する施策や全社規模で注力する機能については、スケジュールを常に更新、可視化し、ステークホルダーには通知するなどを行い、部署間の摩擦や間違ったものを作ってしまうようなリスクを減らすことも行いました。プレイヤーから離れる自分がプレイヤーから離れる、これが一番難しかったことです。最近では新卒からプロダクトマネージャーを任せるケースやプロダクトマネージャーが一般化したことで転職するケースもあると思います。内部からエンジニアあるいはデザイナーからプロダクトマネージャーになるケースが多いのではないでしょうか。その時に、しっかりと自分のプレイヤーとしての業務を引き継ぐ時間があれば良いのですが、弊社のようにいきなりプロダクトマネージャーを任されるケースでは、そうはいきませんでした。僕の場合は、サーバーサイドを書きながらプロダクトマネージャーとしての業務を遂行する必要があります。自分がコードを書くことが好きで、開発リソースがパツパツ且つやりたいことがたくさんある中でついつい自分を戦力としてカウントして、様々なことをこなしてしまいがちでした。それではどっちつかずになってしまい、自分もキャパオーバーになりかけていました。心を鬼にして、自分がプレイヤーから離れる決断をしなければなりませんでした。幸いなことに、弊社サーバーサイドチームは少数ながら精鋭が集まっており、徐々に自分が担当するタスクを減らしていくことで、フェードアウトすることができました。プロダクトマネージャーとして大切なこと半年間という短い期間ながら、プロダクトマネージャーを経験していて、大切だと思った考えをお伝えしたいと思います。執着し、諦めない前述した、えふしんさんのツイートにもあるように、プロダクトマネージャーには24時間のマインドシェアをプロダクトに費やすことができるかが資質なのではと思います。費やすという表現も適切ではなくて、気がついたらプロダクトのことを考えていたくらいがちょうどいいと思います。自分でサービスを立ち上げたことがある人なら思い当たる節があるのではないでしょうか。気がつけば、自分のサービスを使ってもらうにはどうすればいいのかを考えていたということがあるはずです。プロダクトは順調な時ばかりではありません。長く苦しい時期に差し掛かる時もあります。苦しい時でもプロダクトに寄り添い、更なる成長ができることを諦めない。頭がちぎれるまで考える。時には自分も泥臭いことをする。そんな諦めの悪さも必要だと思っています。自分の枠組みだけで考えないつい自分の枠組みで考えてしまうことがあります。やればDAUをあげることができるかという課題に対して、開発側で考えたら、リテンションを上げるための施策を考えてしまいがちです。それ自体は間違いではないのですが、その答えはプロダクト開発の外にあるかも知れません。したら、リアルイベントを開催したら思わぬ盛況ぶりで、SNSでバイラルしまくり結果として、自分のプロダクトをグロースさせることができるかも知れません。DAUを上げるためにはプロダクト変更はいらずに、マーケの施策で解決できるかも知れません。なると、マーケティング的な視点など自分の枠組みの外で考えることも必要になるわけです。そのためには、常に社内外でアンテナを高く貼り、様々なサービスの施策をみて自分たちのプロダクトにローカライズさせるとどうなるかを考えておく必要があります。した瞬間に自分の頭の中に一つ一つのピースがぴったりと繋がることもあるのです。逆算思考それはちゃんと目標から逆算して考えているのか、と自分に常に問うことは大切です。されている前田さんの記事から引用します。大きなジャンプを生むために、目標は逆算で設定しています。「1年後にユーザーあたり収益を3倍にする」といった厳しい目標を立てて、そこから逆算して考えるということを日々行う。これは、非常に重要な状況設定だと思います。seleck.ccこの記事にあるように、例えば1年後にユーザーあたりの収益を3倍にするという目標を立てたとします。この値は事業計画から引っ張ってくるのでいいと思います。今の実際の成長率を厳しめにみて、成長曲線を引いた時に、1年後には収益は2倍にもいかないことがわかったとします。すると、このままやっていては目標が達成できないことに気が付くわけです。すると、違う手を考えなければなりません。その中で思わぬ手が思いつき、一気にグロースさせることができることもあります。解決すべき課題設定で全てが決まる今僕らが全力を掛けてでも解決すべき課題は何であるかを考えることがプロダクトマネージャーの本質だとも思っています。その施策が成功し、プロダクトを大きくグロースあるいは改善させることができるかは課題を設定した時点で決まっていることもあります。そのため、ユーザーあるいはビジネスにおける課題を発見し、それらに優先順位をつけて解決していく、そこにプロダクトマネージャーの手腕が問われていると思います。難しい課題にフォーカスするエンジニアあるいはデザイナーのリソースはとてつもなく貴重です。プロダクトには大小様々な問題があります。改善リストを作りちょっと運用しただけでも、かなりの数の解決しなければならない課題が見つかることでしょう。その時によく思い出すメタファーは、以下の記事にある瓶と石と砂とコーヒーです。tabi-labo.comこの記事で言っていることはプロダクト開発にも適応されます。瓶の中に、最初から砂を詰めていると、肝心な時にそれらに邪魔されて石を詰めることができなくなってしまいます。プロダクト開発においても、目先の小さい施策に気を取られてしまっては、本当に僕らが解くべき、難しく大きな課題を解けないまま時間だけが過ぎてしまうのです。小さい機能でも、アプリはリリースされたら取り返しがつかない場合が多いので、隅々までチェックすると思います。結果として、大小関わらず一つの機能をリリースするには、ある程度の工数がかかるわけです。その中で、解くべき大きな課題に対して全力で取り組む、このマインドを持っておくことが大切だと感じています。プロダクトマネージャーになろうと思った理由なぜ、プログラムを書くことが大好きな僕がプロダクトマネージャーになろうと思ったかを簡単に書いておきます。僕自身のエンジニアになろうと思った理由が「テクノロジーを通して世の中を幸せにしたい」という人生の目標があるからです。その中で、自分はプログラムを書くことにハマっただけで、それは手段に過ぎないと思っています。世の中を幸せにするプロダクトを自分の手で創っていくためには、一人のエンジニアとしては限界があると思っていたし、意思決定をしていくためには自分のレイヤーを上げていくしかないと考えていました。そのための選択として、一番良いと思ったのがプロダクトマネージャーになることでした。最後に「明日からプロダクトマネージャー」と言われた自分の経験を通して、弊社のプロダクトマネージャーの役割やマインドセットについて紹介しました。プロダクトマネージャーは何でも屋であるが故に、大変な場面も多々あります。世の中をより良くしていく実感は強く、やりがいのある役職だと思っています。弊社では、ユーザーあるいはビジネスの課題に対して成果に執着していけるプロダクトマネージャーを募集しています。これからさらに、弊社と弊社が運営しているプロダクトはどれも面白くなると自負しています。プロダクトマネージャー以外の役職でも、もし興味があれば、僕のtwitterアカウントでも何でもいいので、声をかけていただけると幸いです。明日は、弊社の機械学習エンジニアの辻より自身が使っているNixOSの話が書かれると思います。お楽しみにしていてください。dely開発部の伊ヶ崎(@_ikki02)です。sakura(@818uuu)です。Inc.でプロダクトマネージャー兼開発部ジェ...2018-12-12kurashiruが取り組むSEOのおはなしおはようございます。月別アーカイブはてなブログをはじめよう!delyjpさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。