エンジニアリングマネージャー。プロダクト開発で、大切だと思っていることを書いていきます。この広告は、90日以上更新していないブログに表示しています。2017-03-04プロダクトマネージャーの仕事/スキルとエンジニアとのスキルギャプデブサミ2017でパネルディスカッション形式で登壇させていただいた。event.shoeisha.jpエンジニアからプロダクトマネージャーへのキャリアがテーマで、私自身どうやってなったのか振り返るキッカケになった。別の機会でもエンジニアのキャリアについて考えることが多く、改めてエンジニアからプロダクトマネージャーへのキャリアについてまとめてみた。プロダクトマネージャーの仕事と必要なスキルまず、プロダクトマネージャーの仕事とスキルについて言語化を試みた。プロダクトマネージャーの教科書であるINSPIREDにもあるように、プロダクトマネージャーの任務は2つ、「製品の市場性を評価する」ことと「製品を定義する」こと。わかりにくいので、下記の3つのプロセスを定義した。市場の分析STP(セグメンテーション/ターゲティング/ポジショニング・コンセプト)製品要求の定義Webの製品開発には、初めて市場に導入する際のような大きな粒度の仮説検証もあれば、成長フェーズの少し小さな粒度の仮説検証もある。どんな粒度でも結局は市場を分析し、その中で同じような悩みや問題を抱えるユーザーセグメントに切り、どのセグメントを優先して扱うかをターゲティングし、優先セグメントの本質的な課題設定とその解決策を価値として提案するプロセスを経る。プロダクトマネージャーにとってそのアウトプットが「製品要求」である。プロダクトマネージャーのスキルについても言語化を試みた。上記の仕事をこなす為に必要なスキルとして定義している。この辺りは漏れもあると思うし、製品ドメイン特有の知識も必要だとは思う。:財務会計基礎知識と評価力すべてのプロセルに必要スキル:巻き込み力このように定義するとプロダクトマネージャーはマーケターであることがわかる。プロモーションを担当しているマーケターは市場分析>STPを経て、広告広報などのコミュニケーション戦略がアウトプットになる。要はアウトプットが製品なのかコミュニケーションなのかの違いで、どちらも顧客の課題を正しく掴み、解決策として新しい価値提案を行うという意味ではマーケターである。キャリアについて考えていきたい。上記のプロダクトマネージャースキルの中でエンジニアなら持っているスキルをリストアップしてみよう。開発運用ノウハウ分析力のなかの分析ツールやSQLのスキルたったこれだけ。初めからわかっていたことではあるが、エンジニアとプロダクトマネージャーは全く役割や求められるスキルが違う。要するにジョブチェンジなのだ。0からキャリアをスタートさせるぐらいの覚悟がないとできない。エンジニアの延長線上にあるキャリアではない。開発運用ノウハウを知っていて同じ言葉でエンジニアと話せること、SQLを使えるということは、他の職種から見るとかなりハードルが高いので、それだけでもかなりのアドバンテージと捉えるべきか。上記からエンジニアとプロダクトマネージャーのスキルセットにはかなりのギャップがあることがわかった。全員に勧められはしないが、弊社のエンジニアチームを見てもプロダクトマネージャーに向いてそうなエンジニアもいる。次はそこを言語化してみよう。ソリューション志向のエンジニアがPMに向いてるエンジニアチームの中にソリューション志向タイプのエンジニアは必ずいるようにいるように思う。ソリューション志向のエンジニアとはどんなタイプだろうか。蓄積された技術力が一定ある技術は課題解決のための手段という強い認識があるそもそも課題解決能力が高い本質的な価値を追求するあまり、自分で分析やヒアリングをしてしまうような能動性をもっているステークホルダーへの説明責任を果たしながら、チームメンバーへのも説明し、周りをうまく巻き込んでいけるリーダーシップをもっている技術力もあり、課題解決能力が高く、コミュニケーションハブにもなれるこういうタイプのエンジニアはどこの会社でも重宝される。込み力の素養が高いといえる。レアケースだが、ビジネス感度が高かったり、デザイン感度が高いソリューション志向エンジニアも存在する。ビジネス感度が高いタイプは全体のビジネス構造を理解する力が高く、担当事業のKPIモデルや収益構造を感じ取る力が長けている。普段から競合他社の財務3表をよみ競合の収益構造なども理解していたりしているようなエンジニアだ。デザイン感度が高いタイプは自分でデザインの基礎を勉強していたり、モックレベルであれば自分で作ってしまうエンジニアだ。いうエンジニアは財務会計知識や、UX/UI基礎知識も持っているのでさらにプロダクトマネージャーの素養が高い。営業系職種やカスタマーサポートからプロダクトマネージャーになるケースも多いと聞くが、顧客インサイトを経験上多く持っている職種だからだろう。その場合、顧客理解度の高さがアドバンテージになる。デザイナーはもともとUI/UXのノウハウを持っているのでそれがかなりのアドバンテージになる。障壁になりそうなのは、やはり開発プロセスと技術的な理解度や分析ツールとしてのSQLを使ったりするところだろうか。エンジニアとうまく会話ができないということをよく聞いたりする。このようなケースはPMチームの分析官として分析業務をやりながら、トレーニングとして簡単なプロダクトのサンプルを作らせたり、技術知識のインプットを研修プランに落とし込めればうまくランディングできそうだ。スライドspeakerdeck.com参考文献プロダクトマネージャーを目指す人にはぜひ読んでほしい一冊。大切なことがたくさん書いてあります。Tumblr広告を非表示にするもっと読むコメントを書く2017-02-19Webクラウド時代のプロダクトライフサイクルマネジメント2016/12/13に株式会社ビズリーチのD3勉強会で発表した内容を公開。ビジネスサイクル、テクノロジーサイクルがどんどん早くなる中で、Webクラウド時代のプロダクトライフサイクル全体のマネジメントの難易度はどんどん高くなっている。プロダクトの各ライフサイクルの中で適切な投資判断が行われなければプロダクトの成長は止まり、競争に負けてしまうだろう。勉強会を機にどのように考えるべきかまとめてみた。人間、自分の思考の癖やバイアスには気づきにくいもの。売上予算、既存の組織、ステークホルダーへの説明コストなどの外的な制約(しがらみ)や、今までの経験からくる内的な思考のバイアスなど、様々な要因が複雑に絡み合い、思考が制約、歪められる。企画者としては、バイアスや気付いていない制約に気づくためにチェックツールを持っておくべきだろう。最近の企画でハッと気づいたことが多かったので、そこでの学びをまとめてみた。◯◯◯って、一言でいうとなに?◯◯◯のところに、自分が担当しているサービス名、プロダクト名を入れると、サービスの原点を確認できる。手元の課題に注力し近視眼的になっている時、複雑な問題を同時に扱っている時、サービスの本質からずれた企画を進めたりしてしまうことはよくある。そもそも俺たちって何者なんだっけ?何を目指していたんだろう?サービスの原点を改めて確認しなければいけない時に有効な質問だ。4Pなどの整合性は考えている。自社都合の制約など加味しすぎていて複雑でパッとしない、言っていることはわかるけどなんかボンヤリしているなど、ソリッドにまとめきれないことが多い。Backward"というデザイン手法。プレスリリースから考えれば、どうしてもターゲットに刺さるメッセージから考える必要があり、必然的にターゲットセグメント内のポジションや、訴求メッセージ、サービスビジョンが明確になる。詳しくは下記の参考リンクを。fladdictnews.mynavi.jpもし、ど新規でサービスを作るとしたらどうする?サービスのリニューアル時など、売上予算や組織がすでにあるなかで大規模に変えなければならない場合、投資家や現在の組織などのステークホルダーに対してかなり説明コストを払わなければならない。いうケースにおいては既存の制約事項がある前提で企画を進めてしまっていることがよくある。この質問はそういう制約事項を抜きにして、理想のサービスにするためにどうするべきなのか?考えるきっかけを与えてくれる。Tumblr広告を非表示にするもっと読むコメントを書く2016-01-12アップルの何が凄いのか?(前編)最近読んだジョナサン・アイブの伝記的な本をきっかけに、アップルがどのようにして世界を変えるほどのイノベーションを起こしてきたのかとても興味を持ったので、いろいろアップル関連の本を読み始めた。1997年にスティーブ・ジョブズはアップルの暫定CEOに復帰。iPadと続く快進撃は、イノベーティブなプロダクト開発をしたいと思っているプロダクトマネージャーやエンジニア、デザイナーの方々にとって、とても参考になるモデルケースであることは間違いない。なんだか凄すぎてよくわからない会社という印象だったが、何が凄いのかをまとめることで得られる学びもあるだろう。今回まとめる内容は1997年以降のアップルを対象にしている。読んだ本や、参考にしたページは一番下にリスト化した。原点回帰ジョブズ復帰前、アップルは迷走し、製品ラインナップもめちゃくちゃで、赤字を垂れ流していた状態だった。ジョナサン・アイブはそんなアップルに見切りをつけようとしていたが、ジョブズが復帰して状況は一変する。ジョブズは復帰後、一番はじめに行った幹部ミーティングでみんなにこう聞いたようだ。誰も返答しないでいると、ジョブズは大声で怒鳴り始めた。)ジョブズは復帰後の一番はじめに行ったミーティングで、幹部に対し、アップルの目標は金儲けではなく、偉大な製品を作ることだと宣言した。ジョナサンはこれを聞いて踏みとどまったようだ。会社の再建を考える時、普通だったらリストラからやりそうだが、それだと企業の魅力がさらに低下して負のスパイラルに陥ることをジョブズは知っていたのだろう。その企業が何をするために存在するのか、会社の存在理由(ミッション)が一番大切でその企業幹になることを忘れてはいけない。迷走している時はそこがぶれていることが多いのではないか?徹底的なリストラジョブズはリストラも尋常ではないぐらい徹底的に行った。ジョブズの前CEOアメリオ時代からリストラは始まり、アメリオは350程度あるプロジェクトを50まで減らしたが、ジョブズは就任した後はそれをさらに10まで減らした。役立つテクノロジー以外はことごとく抹殺された。人員に関しては、プロダクトラインナップ整理されるタイミングで、全社員1/3以上の7,000人弱が段階的にレイオフされている。ここで大事なのは、経営者自身がどのテクノロジーに投資するべきか判断している点だ。ジョブズ自身が、直近利益を産まないテクノロジーやプロダクトラインナップは全てこのタイミングで抹殺した。ジョブズは復帰した年にマイクロソフトと特許のクロスライセンス及び業務提携を結んだ。OfficeをMacintosh用に最適化させ、Macintosh版とWindows版を同時リリースすることになった。マイクロソフトは1億5000万ドル以上と言われる出資(額は非公開、議決権のない株式を発行)を行っている。この業務提携により、当面の運転資金を捻出し倒産の危機を脱した。Office製品をMacでも使えるようになったことが、後々Mac自体のシェア拡大に大きく寄与していると思う。上記にも記したが、ジョブズ復帰前のアップルの製品ラインナップは全体戦略がなく、40以上の製品群があり、混沌としていた。コンピューターは4つのラインがあり、それぞれのラインに10以上の異なるモデルがあった。アップルはコンピューター以外にもプリンター、スキャナ、モニーター、ニュートンの携帯デバイスまで、ありとあらゆる製品を手当たり次第なんでも市場に投入していた。この状況を見かねてジョブズは復帰後にシンプル且つ明快な製品戦略を打ち出している。ジョブズは先ほど書いたものを消し、簡単な十字を描いた。上段にコンシューマー、プロフェッショナルと書き入れ、下段にポータブル、デスクトップと書き入れる。これがアップルの新製品戦略だ、と言った。売るマシンは4種類だけ。ノートブックとデスクトップ、それぞれプロ用と家庭用だ。)製品戦略は非常にわかりやすく、どんなミッションステートメントよりも社員の力を一つの方向にフォーカスさせることに役に立ったようだ。その結果、iMacの発売からわずか1年足らずで残り3製品をもたてづつけに発表していく。いい経営者の条件の一つに、市場と社員に対して「明快でシンプルな方針」を示せることがあるだろう。トップの方針が曖昧だと、社員はどのような方向に進めばいいかわからないし、市場もこの会社の商品を買っていいのかわかりにくい。責任感ジョブズ復帰前のアップルは失敗してもなんの責任も問われない、悪い意味で自由な会社だったそうだ。責任を問われないので、ちょっと面白いものであればなんでも製品化された。最後までフォローもしないので失敗する。ジョブズは復帰後に、個々の役割と責任を明確にして、結果が出なければ責任を問うということを徹底した。その結果、仕事に緊張感が生まれ、仕事へ集中するようになり、常に前年度を上回る成長をするように努力する組織になったそうだ。"僕がアップルから学んだこと"の中に書いてある面白いエピソードで、著者の方が管理職に抜擢されたタイミングで「お前はこのグループの独裁者になるんだぞ」と、上司から言われたそうだ。要は、自分の部署の独裁者になる代わりに、自分の部門の失敗には全責任を取らされる立場になるというとこ。日本でこういう感覚でやっている管理職の方は少ないだろう。アップルほどの企業になれば常に世界中の優秀な候補者が応募してくるので、代わりなど世界中にいくらでもいるのだろう。企業側としては、責任を追求できる環境を作るためにも優秀な候補者が入りたいと思うような採用ブランディングを徹底して作っていくことが大切だ。続きは後編で書こうと思う。後編はデザイン思考や、開発プロセスなど、より現場に近い部分の話になりそうだ。Tumblr広告を非表示にするもっと読むコメントを書く2015-12-20あなたのプロダクトチームは機能してますか?プロダクトのチームでは、プロダクトマネージャー、エンジニア、デザイナー、マーケッター、営業、カスタマーサポートなどなど、本当に様々な役割の人間が関わりながらプロダクト開発を行っている。これらの人達が1つのチームになり、有機的に連携しながらパフォーマンスを出すのが理想的だが、その環境を作り出すのは本当に難しい。優秀な人達が揃っていても陥ってしまう罠みたいなものがあるので、過去の成功や失敗を振り返って、プロダクトチームをマネージするに辺り大切にしていることをチェックリストにしてみた。企画担当、エンジニア、デザイナー、関係部署のメンバーが毎日雑談しているか?良好なチームのベースには信頼と結束が必要だが、それらが揃っているチームは日常的なコミュニケーション量も自然と増える。プライペートにも突っ込んだ話もしたりするんじゃないだろうか?挨拶から始まり、週末の話や家族の話、この本何?とか、ホットトピックなど。雑談ができるということはお互いの背景や大切にしている価値観などを相互理解できているということ。この状態を作り出すことが大切だ。チーム結成時などにはまず下記のようなツールを利用して相互理解を深め、信頼と結束の土壌を作るといい。雑談の中で自然に議論をしているか?自然な議論がうまれるという事は、チームの課題共有と目標設定が共有できているという事。サービスの未来をお互いに語り合ったりする事で、目の前の問題だけではなくメンバー全員がサービスの目指すべき方向や、より本質的な課題についての理解が深まる。チーム全体の課題設定や目標設定などの共通認識を作るためには、下記のようなツールを使って、課題について共有、議論するといい。他のチームメンバーが今日何をやっているか把握しているか?変化の早い時代、スピーディーな意思決定が求められる。それに対応するためには、毎日の適切な情報共有は必須となる。これができていれば、自然と他のメンバーが何をやっているかについても共有できているはずだ。逆に毎日適切な情報共有ができていない場合、チームの意思決定やチームの置かれている状態をメンバーが理解できないため、メンバーは変化への対応が遅れる。結局は大きい無駄が発生することが多い。優先順位が下がった案件についてデザイナーやエンジニアが作業し続け、優先度が高い案件についてリソースが割かれないなど、こういう事故が発生する。出社したらまず数字を確認するか?チーム全員の役割分担が明確になっていて、各自数字にコミットしている状況であれば、メンバー全員が自然と数字を確認するようになる。Analyticsなど様々な分析ツールを安価な価格で利用できるので、工夫次第では比較的簡単に環境を整えることができると思う。ここで大切なのが、すぐに誰でも数字確認できるということである。集計が必要だと、数字を見るのが億劫になってしまう。デザイナーやエンジニアは主務が物作りなので、簡単に確認できる環境しないと見ない人も出てくる。スピーディーに仮説検証サイクルを回せているか?1から4を実施できていても、スピーディーに仮説検証サイクルを回せなければ、結果は出ない。その場合は、スピーディー施策を回すことができない原因を分析して、対処する必要がある。厄介なのが一つ目の意思決定プロセスだ。あるのが経営陣や影響力がある人間が横からチャチャを入れるパターンだ。横からチャチャを入れている人は良かれても思ってやっているがそれがよくない。現場の責任者に任せるのであれば一定期間任せてみて、結果が出なければ現場の責任者を変えるべきだ。これがひどい状況になると現場のメンバー自分たちで意思決定できないので、自分たちは何も決定できないことを悟り、上からの指示を待つようになってしまう。結局チームパフォーマンスを下げてしまう。最後に、全員が結果に対して執着しているか?いいチームでは目標設定に対して絶対に達成したい!という、非常に高いモチベーションが保たれている。これはリーダーだけが思っていても達成不可能で、メンバー全員で想いを共有し、全員の知恵と努力を結集しなければ達成できない。1から5を実践できていると自然とそういう空気感が生まれてくる。エンジニアもデザイナーも関わっているメンバー全員が結果に対して執着していれば、そのチームはとても大きなことを達成できると信じている。まとめ要するに、チームに関わるメンバー全員が全員のやっている事を把握し、全体の課題や個々の課題をみんなで認識し、役割を明確にし、チームメンバー全員がチームパフォーマンスを意識した行動ができていればいい。その状態を保つの非常に難しい。マネージャーは常にそこに注視し、問題が発生したら対処しなくてはならない。見る最近読んだチームビルディングの本の中で、一番参考になった。このブログタイトルもこの本のタイトルを参考にさせてもらっている。この本の中で出てくる下記のフレームワークはどんなチームでも同じだと思う。チームビルディングで悩んでいる方は是非読んでみてほしい。最近どんな本を読んでるんですか?と質問を受けることが多いので、テーマ別にプロダクト開発に関連する良書と思うものをリスト化しよう。私は、テクノロジー全般からプロダクト開発プロセスまでを広く網羅していこうとしているため、テーマが多岐にわたるが、エンジニア、デザイナーの方や、プロダクトマネージャーの方にも参考になると思う。Tumblr広告を非表示にするもっと読むコメントを書く2015-08-23情熱プログラマー6年前、ITコンサルタントをやめて、Web系のソフトウェア技術者になること、マンションの一室でやっていたベンチャーに飛び込むことを決めた頃に読み、非常に影響を受けた本を再度読み返した。ソフトウェア技術者にとって、とても大切な事が書かれてると思ったので紹介する。Fowler氏の「情熱プログラマー」。偉大なソフトウェア技術者になるためのキャリアを、製品のライフサイクルと同じように考え、4つの側面から分析した本である。見るRuby業界では知らない人がいないレベルの有名人で、開発マネージャーや、CTOなどもやってきた人が書いている内容なので、6年経って様々な経験をしてきた今でも様々な発見があった。6年前駆け出しのエンジニアだったころに響いた言葉と、今読んで響いた言葉は自分の成長もあり少し変わってきていると思うが、いいこと言ってるな〜と思うトピックをピックアップしてみる。コーディングはもう武器にならない一番下手くそでいよう万能選手になろうスペシャリストになろうビジネスの仕組みを学ぶ師匠を探す師匠になる業界で名を売ろう自分のブランドを築こう世界を変えよう君は既に職を失っている一貫して「技術者として自分の分野においては一流でいよう」、「自分の技術をビジネス価値に変換しよう」、「自分を売り出そう」ということを言っていて、改めその通りだなと思った。ビジネスの仕組みを学ぶため「MBA系の本を一通り読め!」って書いてあるところは面白い。この本の中でブログを書くことは、文章力のトレーニングや自分を売り出すことにも繋がる、と書いてあるので4回目になるがブログを改めて始めようと思う。今度は挫折せずに続くか?私は「プロダクトとユーザーをつなげ、ビジネスを生み出す」ことに情熱を傾けているので、ブログのタイトルを「情熱プロダクト開発」にしようと思う。Tumblr広告を非表示にするもっと読むコメントを書くプロフィールid:yappy727一人のソフトウェア技術者、開発マネージャー、プロダクトマネージャーとして、大切だと思っていることを書いていきます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。