2017年の振り返りと今後目指す姿について

概要

今年の振り返りとして、2017年（2017年1月〜12月まで）の間の自分の感情のログを残しておく。

正直、他社の優れたPMの人たちと比べるとお粗末な内容もあるだろうけど、備忘録的な意味合いと、自分の中の思考・キャリアの整理として。

※色々と書いていますが、ただのまとめで、関係者には何の感情もないので悪しからず

リハビリからのスタート

PMとしては厳しいスタートだった。
私は、前年にアサインされたプロジェクトを自分の知識・経験の無さからマネージできず、自己申告でプロジェクトから外してもらっていた。 しかもそのプロジェクトの責任者（PM兼開発部署マネージャー）を感情的に強く拒否してしまっていた。

※結構メンタルやられていて、自己防衛としてプロジェクトを外れるか、自分が退職するかしかないような状況だった
※誤解のないように言っておきたいのだけど、その彼は自分とは違って天才肌で、エンジニアとしてもPMとしても優れた人物であった

ただその彼も退職が決まっていて、誰かが引継ぎをしないといけなくて、その一部を結局自分がやらなければいけないことになっていた。彼は自分の部署のマネージャーではなかったのだけどやはり引継ぎをするのも複雑な思いがあった。とは言え、仕事なので彼の退職する3月末までに引継ぎをしつつ、案件サポートを覚えていった。これはやはりメンタル的に辛かった。

一方で、今だから言うけど、不遜にも自分は退職するマネージャーの彼の後釜になれるんじゃないかって思っていた（感情的な詳細は後述）。しかしプロジェクトを途中で投げ出してしまった時点でそれはあり得ないことだった。それに弊社FreakOutはTech Drivenな会社であるためエンジニアの発言力が圧倒的に強い。前職時代にエンジニアとして開発リードをしていた自分でさえも、第一線を引いていたのもあり、その発言力・影響力はほぼゼロに等しかった。実際、当時一緒にやっていたエンジニアからの信頼感もほぼないと肌で感じていたので、仮にプロジェクトをうまく回せていたとしても自分がマネージャーになるなんてことはなかっただろうと思う。

そんな状況からのスタートで、仕事としては本当にリハビリそのものだった。一度無くした自信と信頼をどう取り戻すか。そしてその先の自分にどういうキャリアがあるのかを模索しているような時期だった。

新人PMのメンターになる

そんな折、4月から中途で採用したPMのメンターになった。
彼女は自分が採用にも関わった人で、今の時点で考えても、未だ1年経ってもいないのに驚くほどのスピードで成長している。育てるのも成功しているとは思うけど、今では彼女から日々刺激を受けて自分の成長スピードも加速しているのを実感している。

自分は前職時代に何人かの新人育成をしているので、人を育てるのに苦手意識はないし、過去の後輩を見ていても育成に成功してるんじゃないかと思っているけど、今回ほど成功したことは過去にないので、もともとのポテンシャルによるところが大きいのかなと思っている。

それはそうと、彼女の加入で一番変わったのは自分だったかもしれない。PM経験、業界経験のない人物を採用から関わって、入社後もゼロから教育する中で、自分の浅い知識のブラッシュアップができたし、自分自身の浅いPM経験の正しさの裏付けをいちいち上司に確認するようになったので、曖昧な自信が確信になっていった。

ただそれでも、4〜6月の時点ではまだまだ自分もPMとして自立できてるとは到底言い難い状態だったと思う。それまで2年やっていたけれど、やれているという実感はなかった。救いがあったのは、それまでのPM経験の中でモバイルアプリ広告の仕様には精通していたので、そこを軸に幅を広げているところではあった。

この頃は未だ、プロダクトロードマップも上司のHead of PMが全て決めているような状況で、ちょいちょい自分のアイデアがロードマップに採用され始めた程度であった。

そんな状況ではあったものの、担当してるプロダクトもテクニカルサポートも増える中で、自分の作業を少しずつ担当してもらいつつ、OJTと座学での教育で新人を育てていた。

担当プロダクトのPMチームができる

7月。1つ前のエントリーでも書いた通り、1つのプロダクトを4人でマネージするPMチームができた。この時点でHead of PMを除けば実質的にただ一人のシニアPMということになった。このあたりから自分の感情に変化が起き始める。

やはりたった一人のシニアということもあり、プロダクト、テクニカルサポートの面で他のPMメンバーを（意識するしないに関わらず）リードすることになった。それにより徐々にメンタル面でも、自分がPMの模範にならないといけないと思うようになったし、準備をしっかりとして、自信を持って判断していかないといけないと考えるようになった。

この頃から、それまでHead of PMの上司が対応していた社外の取引先とのやりとりを自分に集めてもらって一手に対応するようにした。これは個人的なコミュニケーションスキル向上を狙ったものであった。実は年初から、コミュニケーション・プレゼンスキルの改善を目的に、社外でのプレゼン・LTを積極的にやっていて、ある程度度胸がついてきたのもあり、社内の業務も巻き取ってさらなるスキル向上に繋げようと考えていた。

またこれまでのPM経験の中で（2年経ってようやくではるが）業務知識や自社プロダクトの数字勘が多少身についてきていて、今ならなんとかできるかなと思えるようになっていた。また、さらなる知識・スキルの向上には自分のスキルの1段上のトライをする必要があると思い、思い切ってやらせてもらうことにした。

これは目論見以上の成果があって、取引先とのコミュニケーションを円滑に取り仕切って新しいプロダクトのアイデアや連携を考えられるようになったし、同業他社の人たちと業界全体のことについてディスカッションができるようになった。これは単にプレゼン・コミュニケーションスキルが高いだけではできないことではないかなと思っていて、あえて1段高いトライをしたことが良い結果に繋がったかなと思う。

こうして少しずつ、シニアとしてリードしながらスキル面も磨いていった。それでもリードPMとして動けるまでにはなっていないかった。

実質的なリードPMへ

転機になったのは、取引先とのMTGでの失敗だった。ちょうど取引先とのMTGもこなれてきたタイミングで、油断していたのもあるのだけど、完全に予期していないプレッシャーをかけられてテンパってしまったことがあった。この時以下のことを学んだ。

  • 取引先とのコミュニケーションは単なるコミュニケーションスキルだけではなく駆け引きの技術が必要
  • 強いプレッシャーの中で交渉を有利に進めるためには準備が重要
  • プレッシャーに負けない強いメンタルとその維持が必要

ここを改善することで交渉で負けないだけでなく、ディスカッションをリードすることが以前よりもできるようになった。簡単に言うと折れない自信が身についたとも言えるかもしれない。この自信は、もちろん強いメンタルを構築できたことによるところも大きいけど、深い業務知識、数字勘、社内でのプレゼンスなど自分を形作る多くのものがスケールアップしていたことも大いに影響していると感じている。それまで積み上げてきた知識・スキルがメンタル強化により花開いたと言えるのかもしれない。（もちろんどんなにメンタルが強くなっても準備を徹底することは怠ることはできない）

それにより、これまで自社開催のイベントや取引先とのMTGで「担当PMの一人」として自己紹介していたのを、今では「リードPM」として自己紹介している。単に自分の役割の説明が面倒というのもあるけど、実質的にそうなのでそう名乗るようにしている。以前はそこまで言い切る自信もなく、肩書負けするような気もしていたけど、今では「リードPM」というのがしっくりきているなと思っている。

ここまでが2017年の年末までの自分でした。

目指す姿とこれから

前述の通り、自分は開発のマネージャーを目指していた時期があった。なぜかというと、弊社の開発組織での出世という概念上での道筋がそこしかないからである。Head of PMは役員だけど、そこまでのマイルストーンとしては開発のマネージャーしかパスがないのが現状ではある。

なぜ自分が出世にこだわるかは以下である。（正直くだらない理由もある）

  • 前職でなしえなかったことを実現することで自分の選択の正しさを証明したい
  • これまで関わってきた多くの人（親兄弟、親戚含む）に、頑張ってる、結果出してるってことをわかりやすく伝えたい
  • 自分のチームを持ち、リーダーシップを取ることが単純に好き

一方で自分はPMだし、正直エンジニアとしては第一線を引いてるし、弊社のエンジニアとして通用するなんてはなっから思ってもなかった。（上記の自分の思いとは別に）開発のマネージャーはエンジニアがやるのが一番良いと思っているし、開発マネージャー with PMが一番プロダクトや組織にとって良い構成なのかなと思っていたりもする。

そんなことを考えていると結局マネージャーやりたいのかPMやりたいのかみたいなジレンマがあったりするのだけど、リードPMな今、少し視点を変えられてきているかなと思っている。やりたいこととしてはPMだし、（キャリア云々を考えなければ）最終的には事業責任者を目指しているわけで、やはりそこで開発のマネージャーとリンクしないところはあるのかなと思っている（その正しさはわからないけど）。

それにPMとして事業責任者になるということは、営業も含めた組織全体のリーダーシップが取れる存在ということになる。そうなれれば（肩書はともかく）自分がやりたかったことはできるのかなと思っている。まぁそうなれた時は名刺に「事業責任者」って勝手に書こうと思ってるけど。

そうなるとまた自称が増えてしまうけど、2018年はリードPMから事業責任者になれるようにやっていきたいと思っている。ということで今年のまとめを締めたいと思います。

2018年もよろしくお願いいたします。

PMをチームでやったら全員が成長した話

Product Manager

また今年もアドベントカレンダーのためだけにブログを更新します。 こうして1年ごとにそれまでの振り返りを書いていくと、自分の成長度合いを振り返ることができて良いなぁと思っています。

ということで今年は表題の「PMをチームでやったら全員が成長した話」という話を書いていきたいと思います。

概要

これまで個々のスキルと暗黙知で戦っていたFreakOutのProduct Manager（以下PM）メンバーをチーム化して起きた変化についてまとめてみます。

PMチーム化以前

弊社FreakOutでは、PMを明確にポジションとして用意しております。一方でPM自体の頭数は決して多くはなく、私が入った時点から今年の6月までは4人で回していて、そのプレースタイルは以下のようなものでした。

  • Head of PM（弊社役員）が基本的にほぼ全ての方針を決める
  • 個人スキルに寄った、人によって違うプロダクト開発スタイル
  • 他のPMがどの程度の知識があり、何をやっているのかをちゃんと把握できていない

こうして書くと問題があるように見えますが、FreakOutくらいの規模感（100人強）の会社だとPMは少数精鋭の人員配置をしておけば、個々のプレースタイルに任せた方がうまく回ったりします。これはエンジニアや営業でも同じことが言えるかと思います。

PMはプロダクト責任者なので、担当プロダクトについて他のPMにガチャガチャ言われたくかったりするというのもあります。

ただしこのやり方は当然課題があります。

  • 知識が個人ごとの暗黙知の継承だけで行われるので、知っていることの範囲がPMごとに、担当プロダクトごとに違ってしまう
  • Head of PMの意思決定が多く、Head of PMの発想以上のアイデアが生まれてこない
  • PM間での相互サポートが行われない

上記の課題には、今年の6月くらいまでは実は全く気づいていませんでした。前述の通り、FreakOutのPMは少数精鋭でしたので、皆自分で全部できてしまうのであまりチーム化する意味も感じていませんでした。また前述の通り、自分のやってることを他のPMにガチャガチャ言われたくないというのもありました。

チーム化のきっかけ

そんななか、ある日突然チーム化の機運が高まります。営業組織内にあった事業企画（商品開発等を行う部署）チームが解散するということになったのでした。

彼らはFreakOutのプロダクトアセットを使って、商品開発（プロダクト開発ではない）をしたり、アライアンスを組んだりといったことを仕事にしていました。 一方で、プロダクトに直接関われないが故に、やっていることが大きな成果に繋がりにくいという辛みを抱えていました。その辺が解散の理由になったのかもしれません。

私はかねてより、PMと一緒にやることで彼らを活かせないかと考え、コミュニーケーションを始めていて、ちょうど次週から一緒にプロダクトを考えようと言っていた矢先でした。

そして解散して彼らの行き先がどうなるのかと思っていたところ、なんとPMとして合流するということになり、FreakOut初の営業組織からのPMが誕生することになったのでした。

PM増員の過程で考えてたこと

合流したと言っても増えたのは事業開発を担当していた2名だけなので4名が6名になった程度でした。ただ合流した2名は、これまでのPMメンバーとの大きな違いがありました。

  • ソフトウェアのプロダクションコードを書いたことがない
  • 当然、開発・運用の知識がない
  • プロダクトの技術検証の経験がない（できない）

FreakOutの中心事業であるインターネット広告の世界は、プロダクトのアップデートが早く、使っている技術も製品仕様も超複雑な世界です。エンジニア経験のある私でも正直ついていくのがやっとといった具合です。そんな世界で、果たして彼らをPMとして一人立ちさせることができるのだろうか、と思っていました。

一人はSIerでプロジェクトマネージャー経験があり、新規事業にアサインされHead of PMと一緒にやっていくということで何とかなるかなと思っていました。

もう一人はFreakOutの管理画面の営業要件をかき集めてプロダクトにフィードバックする仕事をしていた経験があるので、管理画面開発のプロジェクトマネージャーとしては機能するかなと思っていました。ただそれ以上の存在になってもらわないと受け入れた意味がないし、PMの価値を認識してもらえないと思っていました。

当時自分は以下のようなことを考えていました。

  • PMがもっと機能する組織を作りたい
    • 「機能する」とはPMの意思決定が尊重され、開発・営業問わずプロダクトの方向性について真っ先にPMに話が集まる、ということ
  • そのためにはPMのプレゼンスを上げる必要がある
    • 「プレゼンスを上げる」とは、PMが何をやっている人で、何が得意で、何で価値を出す存在なのかということを全社員に認知させるということ
    • もっと言うと、価値ある存在であると認知させるということ

上記を実現するには、PM個々人のスキル強化と社内へのアピールをしていく必要がありました。

知識を揃える

それまでHead of PMと二人でやっていた週次の1on1をPMメンバーでの情報共有の場に変えました。プロジェクトの状況、プロダクトの状況、営業からのヒアリング状況などを週次ですり合わせることで、皆がプロダクト開発・改善にコミットしていけるようにしていきました。

また前述の管理画面担当のメンバーには時間を取ってinputすることで管理画面以外の部分も担当できるように引き上げました。やったこととしては以下。

  • HTTPのプロトコルレベルの話
  • インターネット広告がどのような通信で配信が行われているのか
  • データをやりとりするするのにどのようなインターフェースが使われているのか
  • どのプレイヤーがどこに絡んでくることでエコシステムがなりたっているのか

本当に基礎の基礎から説明しました。

一方で私にも変化がありました。営業組織から来た2名のPMは圧倒的地頭の良さを持っていて、かつこれまで多くのドキュメント作成経験があり、どのようにプレゼンをすれば人に刺さるかといった知識と経験を豊富に持ち合わせていました。私は彼らから資料作成やプレゼンの方法、戦略の立て方などの知見をもらうことができました。

こうして、お互いに積極的な情報共有をして知識を揃えていくことで、メンバー全員でディスカッションをできるレベルまで（私含め）全員引き上がったのでした。

プレゼンスを上げる

FreakOutではQiita::Teamを情報共有のツールとして使っているのですが、これまでPMが頭の中だけで考えていたことや仮説とその検証結果を言語化して、Qiita::Teamに投稿するようにしていきました。

これはPMが普段考えていることや、市場調査の内容、その頭の中にある情報が価値の源泉になりうることを、全社員に伝えることを目的にしていました。またエンジニアに対しては、自分たちが今作っているプロダクトにどのような価値があるのかを正しく伝える目的がありました。

またこれによって、結果として言語化することの価値にPMメンバーが気づけたのではないかと思っています。言語化する過程で思考が整理されるし、課題が見つかったりするし、何より全社員と目的を共有することでこれまでなかった角度から社内の協力を得られるようにもなりました。

またプレゼンスを上げるという意味でもう一つやったことが、週次朝会で毎週プロダクトアップデートを報告するというものでした。PMメンバーが週変わりで全社員の前でプロダクトのアップデート情報を話すというものです。

これには4つの目的がありました。

  • PMという存在自体の認知向上
  • PMがプロダクト開発をリードしている存在であると認識してもらう
  • 誰がPMなのか顔を正しく覚えてもらう
  • PMメンバーのプレゼンスキルの向上

プレゼンスキルはPMの個人スキルの話なので別ですが、それ以外は正にプレゼンスを上げるためでした。

PMは自分ではコード書かないし、自分では売らないわけです。必ず誰かの協力が必要で、それなくしてPMは価値を発揮できないわけです。

つまりPMの価値を理解してもらい、PMに協力してもらい、PMに情報を集めてもらう必要があるのです。そのためにはまず役割と顔を覚えてもらうという活動をしていくことが大事になってくるのです。

また営業組織から開発組織に来た新しいPMメンバーをエンジニア陣に認識させたかったというのもありました。

チーム化の副産物

週次のプロダクトアップデートのために毎週ディスカッション、日常的な情報共有、そういったことをやっていく過程で、これまで得られなかった様々な副産物が生まれました。

  • 営業組織が持っている顧客や代理店の情報が集まり易くなった
  • PMメンバーのプレゼンスキル向上
  • PMメンバーのファシリテーション、思考プロセス、仮説思考などのビジネススキル向上
  • PM間の積極的な相互サポート
  • プロダクト課題の改善
    • ディスカッションすることで、違う角度からの改善案が出るように
    • 知識を揃えたことで的外れな意見がなくなり、一人で考えていてはたどり着かなかったような価値あるアイデアが出るようになった

PMチーム化以後

PMをチーム化し、改善を重ねることで、以前と比べるとPMのプレースタイルは下記のよに変わりました。

  • それぞれが得意なスキルを活かしつつも、皆が同じ仕事ができるようになってきた
  • Head of PM一人の考えを超えるアイデアが生まれたり、プロダクトロードマップをPMチームで考えられるようになった
  • パラレルでより多くのプロジェクトを動かせるようになった
  • PM間の相互サポートが機能することで一緒に問題を考えられるようになった

チーム化する前は不安もありましたが、実際チームとして動くようになってから、表題の通り（私含め）全員が成長できたし、現在も成長を実感できていると感じています。この先、もっとPMチームをスケールさせていくには、制度面も含めもう一歩深い改善をしていく必要があるかと思っています。しかし今のPMチームなら自分たちで改善していけると自信を持って言える、そんなチームになれたなと思っています。

まとめ

PMをチーム化して機能させるには、

  • 知識を揃える
  • 積極的な情報共有を行う
  • 定期的にディスカッションの機会を持つ
  • 社内でのプレゼンスを上げる

そうしてチーム化すると、「全員が成長する」ということになります。


てことで、今年のアドベントカレンダーは以上になります。

以下宣伝です。
弊社FreakOutではPMにキャリアチェンジしたいエンジニアを募集しております。面接外でカジュアルに話をすることも可能ですので、ご興味ありましたら私のTwitterアカウント（@shinjukujohnny）に是非ご連絡ください。

また隔月で弊社FreakOutのPMメンバー主催のPM Meetupイベントを開催してますのでそちらにも遊びに来てもらえればと思います。登壇いただける方も絶賛募集中です。
https://pm-roppongi.connpass.com/

プロダクトマネジャーが行う市場調査と製品設計について

Product Manager

ここ最近、弊社に新たにプロダクトマネジャー（以下PM）がJOINしたことで自分の仕事に余裕がで出てきて、考えながら仕事ができるようになりつつある。

PMの仕事の仕方として、既にある数字とこれまでの経験から解を見つけ出すのはそれほど難しくない。しかしPMの仕事には、市場に対して新しい商品の見せ方を考えたり、ポジショニングを考えながら製品を設計したりする必要があったりする。オペレーションが多いとそういったことについて深く考えることができないこともあるので、新しいPMのJOINは負荷分散や、一緒に考えることができるという意味で大変ありがたい。

Basicな市場調査

PMの行う市場調査としてまずは私の市場調査方法について書いてみる。「私の」と言っているのは、市場調査は会社によってはPMの仕事でないこともあるだろうし、PMの仕事であったとしてもやる人によってやり方が異なったりするだろうと考えているのであえてそう書いている。

市場調査初心者の私としては、まずはメジャーな分析手法「3C」で考えてみたりしている。

FYI: blog.kairosmarketing.net

別にフレームワークで考える必要はないのだが、Salesと共通認識として考えられる分析手法を用いることでなぜその分類方法を採用しているかの説明が省けるというのと、ある考えを様々な確度から整理できるのは利点と考えている。

市場に関するinputをいかに増やすか

フレームワークを使って情報を整理するにしても、整理すべき情報がなければ何もできない。まずは情報（可能な限り一次ソース）を集める必要がある。ネットで検索して出てくる情報に価値のある情報はそれほど多くはない。もちろん公開されている情報から次のプロダクトへのヒントを見つけ出せることもあるかもしれない。しかし実際にはどこの会社も（当たり前だけど）競争力の源泉となる情報を公開していない。

そんな中でいかに情報を見つけ出すかと考えた時、私はまず人に会いに行くようにしている。自社内、同業者、競合問わず、とにかく人に会って話すということをしている。その中で競合の情報、業界のトレンド、自社内のプロダクトに対するSalesの認識などをinputしていき、時にはその中で他社・パートナーのプロダクトの技術検証を行い、それらと自社製品が連携することが可能かどうか、連携するとした場合どういった製品設計をして商品化していくのかを考えるよにしている。

※ここで言う製品設計とは、プロダクトに実装する機能・サービスのこと。実装上の設計の話ではない。

製品設計は誰がすべきか

ここまで来るともはや市場調査の域を超えて技術検証まで行っているわけだけど、弊社FreakOutでは私の在籍している過去2年の間、PMメンバーはわりとこうして新製品の設計を行ってきている。

PMが市場調査から製品設計まで一気にやることの利点は、市場状況に合わせた製品のアイデアをベースに設計まで一気に行えることで、エンジニアに開発を依頼しやすくなるという点があると思っている。製品化するかどうかも明確ではない技術検証をエンジニアにやってもらうのは余程のスモールチームかスタートアップでないと必ずチームから不満が出るもの。うまくいけばエンジニアは最大限の評価がもらえるが、そうならないことも多く、責任の一旦をエンジニアに担わせることになってしまう。

またケースバイケースではあるが、エンジニアにとってのスキルアップに繋がらない場合もある。そう考えると、製品設計はPMがやった方が作るべきものを明確にできるし、何より市場状況に即した製品を設計できるのではないかと考えている。

前職時代にエンジニアも製品設計に関わっていこう、という動きを開発チームとしてしたことがあるが、多分、Salesサイドからするとナンセンスにうつっていたことだろうと想像する。それはエンジニアがダメなのではなく、視点が違うの一言に尽きるのではないかと思っている。エンジニアはシステムの全てを把握しているので、どう拡張すれば自分たちの製品が成長しそうか考える。一方で、Salesサイドはクライアントがこう言ってるんだからこういう機能を作らないと売れないと言うわけだ。

PMがすべきことは、この両方の意見を聞いた上で、エンジニアの言う今のシステムを理解し、Salesの言う顧客要望を理解し、ハイブリッドな、時に角度の違うプロダクトを作ること。よくある話ではあるが、必要なのは「速い馬」ではなく「自動車」だということだ。ここを整理することこそがPMに最も求められているのではないかと思っている。

FYI: dqn.sakusakutto.jp

それを導き出すためにもPMは市場調査から製品設計まで一気にやる必要があるのではないか、と最近考えています。

PMスキルを身につけるための試行錯誤とその結果について

Product Manager

今年もこの季節がやってまいりました。Qiitaアドベントカレンダーです。 一年にこの時しかブログ更新できていませんが、毎年の振り返りとして続けていければなと思っています。

今年はPM業を始めてから２年目になりました。PM１年目の昨年は、PMとは何をする人か、弊社FreakOutにおいての役割とは何か、それを考えながら走り続けた一年でした。 昨年はすべてが初めてで自分の役割を整理することも十分にできていなかったように思います。今年は、自分自身PM業について向き合うという準備ができている状態でやってきたので、改めて自分が定義した課題とその結果について書いていきたいと思います。

PMとしての課題感

PM１年目のときは主に取引先ベンダー・クライアント様と弊社エンジニアの間に立って仕様調整、結合テストサポート、仕様ドキュメントの整理を中心に行っていました。それはそれで問題なく仕事できていたのですが、下記について課題感を感じてもいました。

  1. 売上へ貢献する機能改善
  2. コミュニケーション力、プレゼン力
  3. 新製品を提案し実現する

売上へ貢献する機能改善

課題1. については新製品開発プロジェクトだったので簡単に結果が出ないのはわかってはいました。しかし自分はPMであるにも関わらず、恥ずかしながら売上やKPIも十分に見れていないような状態でした。

その頃の自分はエンジニアのフロントとして社内外のエンジニアとのコミュニケーションが仕事の中心だったので、作った製品がどのように使われているかについてあまり考えられていない状態でした。そこで上司と相談して「より多くの営業と関わる」という目標を設定しました。なぜなら営業は売上の責任を追っていて、KPIも当然把握している。さらに顧客に最も近いところにいて、製品の改善要望も当然彼らから上がってくる。営業からの改善要望のすべてが汎用的な仕様にできるものではありませんが、彼らとのコミュニケーションから新しい製品や機能に関するヒントをもらえることを期待してのことでした。 とは言え営業との関係値がほぼ無い中、営業側から声がかかることを待っていても永遠にその機会が訪れないことはわかっていたので、数少ない親しい営業に営業組織のキーマンを紹介してもらい、一緒にランチに行くところから始めたりしていました。

その後、自分が担当した新製品について社内での問い合わせ窓口を自分にしてもらって、営業からの問い合わせがほぼすべて自分に向くようにしてもらい、積極的に営業とコミュニケーションを取るようにしました。今年はエンジニアとの仕事の時間よりも営業との仕事の時間の方が圧倒的に多かったと思います。

営業の追っている売上目標を一緒に追い、日々一緒になってKPIをウォッチして製品に問題ないか確認し続けているうちに数字に対する理解や意識が深まるようになりました。また当初の目論見どおり、営業から様々な製品改善のヒントや他社製品情報の収集も行えたことで、製品にフィードバックが行えるようになりました。それもあってか、担当していた製品は（様々な要因はあるものの）結果的に大成功し自分の人生でもかつてないほど売れました。

コミュニケーション力、プレゼン力

他人と話す能力はPMにとってあらゆるところで役にたってきます。社内外の多くの人に会って製品説明をする機会の多いPM職において、コミュニケーションが苦手というのは圧倒的に不利だと思っています。

自分は製品説明をクライアントにする際は特に問題なく話せていたかと思うのですが、例えばイベントでのネットワーキングタイムなど、自分から能動的にコミュニケーションをしていかないと何も成果を上げられないような場面において、うまく話せないこともあり課題に感じていました。また自分で資料を用意してそれについて説明するプレゼン能力、これについてもこれまでの場数が足りていないという認識がありました。

ただこの課題については、もうとにかく場数を踏むしかないと思っていて、今年は話す場、プレゼンする機会を自分から作っていくということをやりました。具体的には勉強会でのネットワーキングタイムで「名刺を○枚集める」など事前に目標を定義し毎回必ずその目標を達成するようにしました。またLTの機会のある勉強会では発表の機会をもらって話したりもしました。これをやったことで、コミュニケーションに対して物怖じしなくなり、かつ多くの取引先やクライアントと話したことでその後の仕事が格段に進めやすくなりました。

余談ですが、弊社FreakOutはSlackを使ったコミュニケーションが営業含め社内で浸透していて、対面コミュニケーションがなくても仕事が回るような体制ができています。ですが、自分は対面コミュニケーションの方が、細かい事情や自分の感情含めより多くの情報を伝えることができると思っているので、直接会って話すということを大事にしています。もちろんエンジニアに声をかける際は、彼らの集中力を乱さないように頻度とタイミングに気をつけていますが、100%チャットツールに頼りすぎないように気をつけています。

新製品を提案し実現する

これについては現在も模索しつづけているところです。製品の提案は、自分は次の項目が理解できていないとまともな提案はできないと思っています。

  • 数字から導き出せること（市場調査、自社のログ、KPI）
    • 数字が出せないと説得力がない。
  • 業界のトレンドと競合他社の売上状況
    • 市場がないのに製品を作っても売れない。
  • その業界のサービス・商品・製品への深い理解。
    • 浅い知識では浅い提案しかできない（既に実現されているかもしれないか、的外れになりがち）

今はできることとして、ログをサマってデータを見て、KPI進捗を確認し、営業から業界トレンド・他社情報をヒアリングして、業界の情報収集もしていくというところを地道に続けているというところです。

今年は去年に比べるとだいぶ自分の課題が浮き彫りになり、しかし地道に課題に向き合ってやってきた一年だったと思います。少しずつではありますが、もっと良い製品を世の中に出していけるように日々精進したいと思っています。

エンジニアからPO、PMと転身してきた一年の振り返り

Product Manager

エンジニアからPO、PMへ

自分がエンジニアからプロダクトオーナー（以下PO）、プロダクトマネージャー（以下PM）と転身してきた一年の振り返りを書いてみます。POをやっていたのは前職時代の3ヶ月。その後は現在の会社でPMとして働いています。

昨年11月中頃、自分はエンジニアリーダーからPO（正式な肩書はプロデューサー）に転身しました。それまでのキャリアを変えてエンジニア職から転身したのには色々な思いがありました。自分はこれまで、良いプロダクトを生み出せるのは技術からだけと信じていました。

転機となったのは、夜間と土日に通っていた産業技術大学院大学で単位を埋めるためだけに受講した「サービスサイエンス」という科目でした。そこではビジネスになるサービス・プロダクトをどう定義すれば良いかを学びました。大学院にはもともと情報工学やその周辺の知識を埋めるために通っていたのですが、一気にビジネスにも興味が湧くようになりました。そんな折、現在の会社に誘ってくれた前々職の先輩からPMという職があることを教えてもらい、Inspiredという書籍を紹介されました。www.amazon.co.jp

それから自分はPMという働き方自体に興味を持つようになり、日々PMになるために必要なことを技術そっちのけで学ぶようになりました。その後社内転職を果たしてPOになり、最終的には自分がPMとして働ける環境はないかと思うようになり、PMとして明確にポジションのある現在の会社に転職したのでした。

PO時代

POになった時に最初にやっていたことは、それまでの開発リーダーの延長で、主にプロジェクトマネージャーとして仕事をしていました。それ以外ではヘルプデスクのサポート、事業部（仕様は基本的にここが全てROIを出して決めていた）の提案や開発タスクをドキュメントに落としてエンジニアに展開するなどしていました。エンジニア時代にも当然部署のKPIは存在していて、自分たちもある程度意識はしていたのですが、それほど数字については理解していませんでした。

扱っていたKPIは、当時の部署は広告系でしたので、CTR（インプレッションあたりのクリック割合）と広告を通してどれだけ商品が売れたかを示す広告経由流通総額が主なKPIでした。それらの数字については大まかな理解はしていたものの、CTR一つとってもプロダクトごとの細かな数字が頭に入っておらず、自分たちの作っている主要プロダクトのCTRや広告経由流通総額、加えてそこにどれだけのコストをかけてどのように運用（システム運用ではなく広告運用）されているか、市場競争力はどの程度なのかなどについて正しい理解がありませんでした。この点については改めて思い知らされて本当に衝撃を受けました。エンジニア時代もある程度理解していると思っていたKPIを自分が正しく理解しておらず、またプロダクトの改善にどのような数字が必要で、どうすれば数字が上がるのか下がるのか、何を持ってその数字の良し悪しを評価するのかが見えていなかったのです。これにはとにかく日々数字を見てそこから自分なりの考察をするということを繰り返すことをしていましたが、それは現在も続けていたりします。

また数字の話とは別に、この頃思っていたのが、エンジニアとPOの業務内容の違いでした。エンジニアはコードと向き合う時間が多い仕事だと思っています。しかしPOは開発プロジェクト全体の状況や日々の数字のチェック、上司への報告、営業とのコミュニケーションなど、エンジニアがコードと向き合うのとは逆に、コード以外の全てと向き合う仕事であると感じました。そこにはコードの外の大海原のような世界があるのだと感じました。（もちろんコードという大海原が存在することも認識していますが）

そんな具合に始めたPO業ですが、しばらくして当時のPOの役割や責任範囲について、自分が目指していたPMとは大きくかけ離れているように感じ始めました。前述の通り、事業部が決めた仕様を開発に落とし、プロジェクトマネジメントをし、ヘルプデスクサポートをする。それが必要な仕事なのは理解していたのですが、プロダクトをマネジメントをしているということではなく、開発チームやその周辺のマネジメントに終始していると感じていました。もちろん自分の力不足や理解不足もあったと認識しています。さらに、プロダクトについて考える際、エンジニアだった自分はどうしても、どう作るか（How）から考えてしまい、なぜそれが必要なのか（Why）を考えきれていなかったと思います。また、日々数字を追っている専任の担当者が多数いる中に、エンジニア上がりの自分が入っていくことの困難さも感じていました。

これらはもちろん自分の能力や知識のなさに起因することではあったのですが、組織的にもエンジニアに近い人がPMとして責任を持って役割を果たすという組織構造にはなっていないように感じていました。そんな折、現在の会社でPMとして働いていた先輩から誘われ、未経験ながら専任のPMとして働き始めるのでした。

PM時代

入社前から言われていたのですが、現在の会社のPM職はエンジニア出身者で構成されています。そして自分たちが決めたことがプロダクトに反映されていくのです。なぜそうしているかという点を考えてみると、まずプロダクトが技術的に非常に複雑だということが挙げられると思います。また、弊社はエンジニアが中途入社するのに高いハードルを設けているため、PMはそんなレベルの高いエンジニアたちとコミュニケーションが取れる人であることが望まれているからだと考えています。正直自分は今だにビジネスの話よりも技術の話の方が分かります。

そういった技術に対する理解が求められる一方で、お客様や取引先担当者様との対話も非常に重要な仕事となっています。エンジニア時代はお客様先に出向くこともほぼなかったのですが、現在のPM職になってからは、お客様先や取引先に営業と一緒に出向いて、弊社プロダクトの説明をする機会ができました。これまで接することがほとんどなかったコードの外側の声を聴く機会が増えたのです。また、自社内においても、営業や経営企画の方たちと一緒にプロダクトの方向性、プロダクトを伸ばす方法、どうすれば利益に繋がるか、短期的な施策になっていないかなどを議論しています。そしてその結果から開発計画を立て、実行し、結果を検証していく、所謂PDCAを回すというようなことをしながら日々プロダクトを成長させる方策について考えたりもしています。

こうした技術、ビジネス両面の知識や考え方が求められるPM職に就いて思うのは、自分たちはそれこそ必要であればあらゆることをやらなければならないということ。エンジニアは作り、営業は売る。PMはそれ以外全部だと思っています。ただし、会社の利益を考えて、やるべきではないことは断固やらないと決めること。これが重要なのだろうと思っています。

先月行われたPOStudy祭りで、どなたかの発表で「PMが倒れたらプロダクトは世に出ない。だからストレスをうまく処理し、自分を守る必要がある」とおっしゃっていましたが、それは非常に正しいと思いました。それだけ重い立場だと考えて、日々しっかり仕事をしつつも根を詰め過ぎないよう、自分なりに最もパフォーマンスを出し続けられる方法を模索しながら今後もPMとしてやっていきたいと思っています。

iOSでグラフ表示

iOS

iOS始めました

このところ、仕事でメインの広告関連システム開発のディレクションとは別に、iOS開発でのディレクションも行っている。プライベートでも、週末に通っている大学院でiOSアプリの開発をしていて、大分iOSに浸かった日々を送っている。
今回はその中でグラフを表示するiOSのライブラリを使ってみたので備忘録として残しておく。

BEMSimpleLineGraph

使ったのはこれ。
github.com
グラフ表示に使えるライブラリはいくつかあったものの、開発がアクティブで手軽に使えそうなものという観点でこれを選んだ。

今からどうせやるならSwiftということで、以下を参考にしながら使ってみた。
d.hatena.ne.jp
また下記を参考に、cocoapodsからライブラリをインストールできるようにした。
CocoaPodsを使う – e.lab

まずはプロジェクトディレクトリのトップにPodfileを作成し、pod install実行。

$ cat Podfile
pod 'BEMSimpleLineGraph'
$ pod install
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
Installing BEMSimpleLineGraph (4.1)
Generating Pods project
Integrating client project
Sending stats
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.

cocoapodsでインストールしたライブラリを使うには.xcworkspaceから起動する必要があるということで下記で起動。

$ open <APP名>.xcworkspace

BEMSimpleLineGraphはObjective−Cのライブラリなので、Swiftで使う場合は連携させるためのファイル（<APP名>-Bridging-Header.h）を作成する必要がある。
最近自分が作っている万歩計アプリ（QuestWalk）でいうとこんな感じ。
QuestWalk-Bridging-Header.hという名前でヘッダファイルを作成し、BEMSimpleLineGraphView.hのimport文を記載する。
f:id:shinjukujohnny:20151109012611p:plain
プロジェクトのBuildSettingsを開いてSwift Compiler - Code GenerationのObjective-C Bridging HeaderにBridging Headerのパスを記載。
f:id:shinjukujohnny:20151109013019p:plain
これで使う準備は整った。
自分の場合は、CMPedometerで一週間分の歩数データを取得して、それをグラフに書き出すというのをやってみた。実装はViewControllerに下記のようにした。（一週間分の歩数データが取得できない場合は、画面に"No Data"と表示される。BEMSimpleLineGraphの仕様？）

//
//  QWStatusGraphViewController.swift
//  QuestWalk
//
//  Created by Johnny on 11/1/15.
//  Copyright © 2015 SBR2015. All rights reserved.
//

import UIKit
import Foundation
import CoreMotion

// BEMSimpleLineGraphDelegateとBEMSimpleLineGraphDataSourceの2つのプロトコルを追加
class QWStatusGraphViewController: UIViewController, BEMSimpleLineGraphDelegate, BEMSimpleLineGraphDataSource {
    
    // メンバー変数でないと動作しないので注意
    let pedometer = CMPedometer()
    var weekList:Array<Float>!

    required init(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)!
        setup()
    }
    
    override init(nibName nibNameOrNil: String!, bundle nibBundleOrNil: NSBundle!) {
        super.init(nibName: nil, bundle: nil)
        setup()
    }
    
    convenience init() {
        self.init(nibName: nil, bundle: nil)
    }
    
    func setup() {
        // init の中身
        getWeekData()
    }
    override func viewDidLoad() {
        super.viewDidLoad()
        // 描画の方が早いのでタイマーで遅延させる
        NSTimer.scheduledTimerWithTimeInterval(1, target: self, selector: "onUpdate:", userInfo: nil, repeats: false)
    }
    
    func onUpdate(timer:NSTimer) {
        // グラフのViewを作成（今回はメインビューと同じ大きさのビューを作ります）
        let graphView: BEMSimpleLineGraphView = BEMSimpleLineGraphView(frame: CGRectMake(0, 50, self.view.bounds.width, (self.view.bounds.height - 50)))
        // データソースを設定 (今回はこのクラスの中にメソッドを書くので、selfを設定)
        graphView.dataSource = self
        // delegateを設定 (今回はこのクラスの中にメソッドを書くので、selfを設定)
        graphView.delegate = self
        graphView.enableTouchReport = true
        graphView.enablePopUpReport = true
        graphView.enableYAxisLabel = true
        graphView.enableXAxisLabel = true
        graphView.enableReferenceAxisFrame = true
        graphView.enableReferenceXAxisLines = true
        graphView.enableReferenceYAxisLines = true
        graphView.enableBezierCurve = false
        graphView.widthLine = 2
        graphView.colorLine = UIColor.orangeColor()
        graphView.colorTop = UIColor.whiteColor()
        graphView.colorBottom = UIColor.whiteColor()
        // メインビューにグラフのViewを追加
        self.view.addSubview(graphView)
    }
    
    // Y軸の値を返すメソッドを作成
    func lineGraph(graph: BEMSimpleLineGraphView, valueForPointAtIndex index: NSInteger) -> CGFloat {
        //何個目のX軸のポイントかはindexで取得できるので、今回はSampleData配列の中にあるindexの要素をそのまま返します
        return CGFloat(self.weekList[index])
    }
    
    func numberOfPointsInLineGraph(graph: BEMSimpleLineGraphView) -> NSInteger {
        return self.weekList.count
    }
    
    func getWeekData() {
        weekList = Array<Float>()
        for i in 0...6 {
            // CMPedometerが利用できるか確認
            if CMPedometer.isStepCountingAvailable() {
                // 今日の0時
                let df = NSDateFormatter()
                df.locale = NSLocale(localeIdentifier: "ja_JP")
                df.dateFormat = "yyyy/MM/dd 00:00:00"
                let fromDate = df.dateFromString(df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*(i+1)))))
                print("###from date### " + df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*(i+1)))))
                // 現在時刻
                let toDate = df.dateFromString(df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*i))))
                print("###to date### " + df.stringFromDate(NSDate(timeIntervalSinceNow: Double(-24*60*60*i))))
                
                // 本日の成果
                pedometer.queryPedometerDataFromDate(fromDate!, toDate: toDate!, withHandler: {
                    [unowned self] data, error in
                    dispatch_sync(dispatch_get_main_queue(), {
                        if error != nil {
                            print("エラー : \(error)")
                        } else {
                            //let lengthFormatter = NSLengthFormatter()
                            // 歩数
                            let steps = data!.numberOfSteps
                            // 距離
                            //let distance = data!.distance!.doubleValue
                            print("Steps: \(steps)")
                            //    + "\n\nDistance : \(lengthFormatter.stringFromMeters(distance))"
                            self.weekList.insert(steps.floatValue, atIndex: 0)
                        }
                    })
                })
            } else {
                print("Cannot use CMPedometer")
            }
        }
    }
    
    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }
    
    /*
    // MARK: - Navigation
    
    // In a storyboard-based application, you will often want to do a little preparation before navigation
    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
    // Get the new view controller using segue.destinationViewController.
    // Pass the selected object to the new view controller.
    }
    */
    
}

結果は下記の通り。
f:id:shinjukujohnny:20151109014325p:plain
一点、参考にしたサイトの下記の実装（X軸のラベル表示）は自分が試した際には動かなかった。よく調べきれてないが、Objective-CのライブラリをSwiftから全く同じように使うことはできないのかもしれない。

    // X軸のラベルを返すメソッドを作成
    func lineGraph(graph: BEMSimpleLineGraphView, labelOnXAxisForIndex index: NSInteger) -> NSString {
        //何個目のX軸のポイントかはindexで取得できるので、今回はSampleLabel配列の中にあるindexの要素をそのまま返します
        return NSString(string: SampleLabel[index])
    }

また今回の実装ではCMPedometerから歩数を抽出している間に、先にViewにグラフが描画されてしまいデータが渡らない現象が起きていた。デバッグしたところ、dispatch_sync内で歩数データを配列に入れる処理がViewの描画の後になってしまっているようだった。苦肉の策としてviewDidLoadメソッド内でタイマーを設定して、Viewにグラフを描画するのを遅らせることで対応したが、もっと良い方法があるような気がしている。
この辺の同期・非同期処理の順番やiOSのライフサイクルなどは引き続き調べてみたいと思いました。

プロダクトマネージャーと健康

Product Manager
この二週間近くよくわからない病気（副鼻腔炎）に悩まされていた。高熱と頭痛、鼻水。症状が治まってもなかなか完治はせず、大きく仕事のパフォーマンスを落とすこととなってしまった。

今回、病気で戦線離脱を余儀なくされたことで、新しい開発プロジェクトのスタートダッシュにも影響してしまった。自分が見ていた既存のプロジェクトも同様だ。

これは何もプロダクトマネージャーに限ったことではないのだろうが、健康の維持や睡眠、ストレスのコントロールは重要だ。ことプロダクトマネージャーにおいては、プロジェクトを進め顧客をサポートする立場上、基本的に長いこと開発現場や顧客の前から消えて良いポジションではない。幸い今回は周囲の助けもあり休むことができたが、改めて今後は健康の維持というところはしっかりと意識していきたいと思った。具体的には、風邪の予防や日頃の運動、疲労やストレスのコントロール、そういったことを意識的にやっていきたい。

しかし考えてみると、プロダクトマネージャーはその仕事の性質上、心身ともに健康で強くなければつとまらないなと思った。これはプロダクトマネージャーが持つべきスキルの一つ、というには言い過ぎかもしれないが、製品について全ての責任を負う以上、意識しておかないといけないことなのかなと思った。