新卒プロダクトマネージャーが苦労した3つのポイント

こんにちは、タケノコプロダクトマネージャー*1のktaroです。

先日、「freeeのPMチームと語る、本当に泥臭い現場でのプロダクトマネジメント談話会」というイベントを開催しました。私を含む弊社の3名のプロダクトマネージャー(以下「PM」)(執行役員PM、エンジニア兼務PM、若手PM)が、PMのリアルな苦悩とその乗り越え方について共有させて頂きました。今回は、その中で若手PMの私がお話しした、非常にチャレンジングな体験についてご紹介させて頂きます。

突然ですが、下記の自己紹介スライド*2にてびっくりされるような事実が1点ありますが、お気づきでしょうか?

f:id:noraemon10:20170726173910p:plain

正解は、入社1.5ヶ月目の新卒*3がPMに就任していることです。PMというロールは、その担当するプロダクトにおいて最大の責任を持つロールであり、PMの実力がプロダクトの生死を左右すると言っても過言ではありません。そんなロールに新卒を就かせるという決断を、よく弊社はしたなと自分でも思いますが、実際にチャレンジングながらも非常に有益な体験をすることができました。

丸裸でエベレストを登るようなもの

まず、なぜチャレンジングであったかというと、下記3つの能力についてゼロスタートであったからと言えます:

  • ベーススキル:会議ファシリテーション力、資料作成力、プレゼンテーション力、プロジェクトマネジメント力等
  • ドメイン理解:プロダクトが解決する課題の分野に関する深い理解。弊社の場合は中小企業のバックオフィス業務
  • PMスキル:ビジョンや戦略を作る力や、人を動かす力等

この状態でPM業をやるということは、登山初心者が丸裸でエベレストを登るようなものです。この人が当然ながら最速でエベレストを登ることができないように、ベストなプロダクト戦略を導き出すことは非常に困難です。

突然訪れた機会

そして、なぜこのような機会を得たかというと、下記3つの条件が偶然にも重なったためです:

  • 前任の方が起業し、freeeを卒業したため、空きポストができた
  • プロダクトがまだインキュベーションフェーズにあり、事業としての価値は限定的であった
  • 弊社内にプロダクトマネージャーはまだ少なく、今後増員するにあたり、育成の知見を溜める必要があった

以前からPM職に強い興味があった私にとっては、この上ないチャンスでした。

四半期開発プラン作りで四苦八苦

実際に、どれだけチャレンジングであったかを具体的なタスクを例に、上述のゼロスタート3点セットに沿って(赤裸々に)ご説明します。それは、次の四半期の開発プランを作るというタスクです。つまり、今どういったユーザーさんのどの課題を解くべきかを決め、社内の意思決定者が納得できるストーリーを作り上げ、それに沿って具体的に開発する機能と順序を3ヶ月分決めるというタスクです。

まず、このタスクを遂行する上で、ベーススキルがゼロであったために下記の様な単純な失敗をしました:

  • 関数の対象セルがズレていて開発工数の計算を間違う
  • 資料がごちゃごちゃしていて見にくい
  • 議論のファシリテーションが出来なく、真剣に心配される
  • 大人数を呼んだミーティングでグダグダしてリソースを無駄にする
  • スケジュールやタスク管理ができておらず、締め切りを過ぎてしまう

次に、ドメインの理解がゼロであったために、下記の様なことが分からず苦労しました:

  • 労務管理(給与計算freeeが対象とする分野)って何!?何が大変なの!?
  • みんな労務管理をどうやってるの?給与計算freeeを使うと何が違うの?
  • 複数の給与締日支払日設定って何で必要なの?
  • 今、給与計算freeeでは何ができて、何ができないの?
  • 労務手続きってどんなのがあるの?

そして最後に、PMスキルがゼロであったために、下記の様なことが分からず苦労しました:

  • 皆が納得するストーリーってどうやって作るの?
  • 優先度ってどうやって決めるの?AとBの機能で、どっちの方が優先度高いの?
  • 事業的にインパクトが大きいのはどのストーリー?
  • 市場は今どんな状況なの?競合の動向は?

結果として、四苦八苦しながら、いろいろの方に助けられながら、何とか開発プランを作ることができました。そして、一度この課題を乗り越えたからこそ、今の自分であれば、より短期間でより優れたものを作れる自信があります。その理由は次にご説明します。

ロールモデル登場

6ヶ月間エベレストを登り続けた後、担当プロダクトの事業的な重要性が急速にあがりました(参考プレスリリース:freee がHR事業の軸となる新サービス「人事労務 freee」を発表。人事労務に関する業務をクラウド上一気通貫で対応しHRtechを推進)。そういったこともあり、よりシニアなPMがアサインされ、私はそのPMと一緒に働くことになりました。

実は、一緒に働き始めた最初の3ヶ月間が、自分自身が最も成長できた期間であったと思います。なぜなら、そのPMは、自分が四苦八苦していたPM業の理想的な熟し方を体現していたからです。自分にとっては答え合わせのように、そのPMと自分とのギャップを目の当たりにし、自分が目指すべき姿を理解することができました。すなわち、エベレストを登頂できる人が一体どの様な人なのかを理解していないまま登るのと、具体的なイメージを持って登るのとでは、圧倒的に成長スピードが違うということではないでしょうか。一度頂上を見ずに、最初からアシスタントとして働いていたら、同じような成長は遂げられなかったと思います。

最後に

非常にチャレンジングな機会を頂いた中で、目指すべき姿を正確に理解できたことが一番の収穫であったと言えます。やはり新卒はずっと下から見上げることが多いので、中々頂上のイメージが付きづらいです。そのため、新卒には少しの間でも頂上を体験させ、合わせてロールモデルを見せてあげることで、圧倒的に早く成長するのではないでしょうか。PMに限らず、新卒を育成する機会がある方は、ぜひ試してみてください。

freeeでは大きな山にチャレンジするPMを募集しています。若手からベテランの方まで、幅広く仲間を探しておりますので、ご興味あればぜひご連絡ください(こちらより)。

*1:タケノコプロダクトマネージャー:プロダクトマネージャー(以下「PM」)の下で修行を行う者。一般的には、アシスタントPMやアソシエイトPMとも呼ぶ。筍のように早く、強く、しなやかに成長する期待の意味が込められている。

*2:イベントで使用したスライド資料は、かなり攻めた内容や表現になっておりますので(”泥臭さ”を重視したため)、公開は控えさせていただきます。

*3:実は正確には出戻り第二新卒です。freeeでインターンを経験した後、新卒で外資システム系企業に入社し、半年でfreeeに戻ってきた経緯があります。ただし、PMとはかけ離れた仕事内容でした。

Azure Machine Learningが便利なことを布教したい

おはようございます。 スモールビジネスAIラボ 研究員のKenji Usuiです。

クラウド機械学習流行りですね。かく言う私も最近使い始めたらその便利さにハマってしまいました。
ここではメインで使っているAzure Machine Learning(以下Azure ML)の良さについて語っていきます。

Azure Machine Learningのここがよい

私がメインで使っているクラウド機械学習ツールはAzure MLです。なぜAzure MLを選んだかというとザックリ次の3点が大きな理由になります。

  1. GUIが使いやすい and わかりやすい
  2. 簡単にWebサービスとしてデプロイできる
  3. SQLやPythonも使える

それぞれ詳細を説明していきます。

1. GUIが使いやすい and わかりやすい

モデル構築は試行錯誤の繰り返しなのでサクサク変えていけると楽です。
その点ではGUIは非常に便利でAzure MLはGUI上でユニットを変えるだけで処理を変更することができます。後で見返してもわかりやすいのも良いですね。加えてテスト結果を可視化してくれます。これが見やすくてカッコイイのでそのままドキュメントに使えます。
便利ですね。 f:id:Grahamian:20170726145935p:plain

2. 簡単にWebサービスとしてデプロイできる

Azure MLは学習したモデルを5分でwebサービス化できます。しかもスケーラブル。
学習のために設計した状態からほぼ自動でwebサービスへ変換することができます。
f:id:Grahamian:20170726154043p:plain 学習器を使うためにコードを書く必要もありません。普通だとwebサービス化やその保守に手間がかかってしまいますが、これを圧倒的に短縮できます。
呼び出しもREST APIなので簡便でJSONを渡すかcsvを渡してバッチ処理できます。
便利ですね。

3. SQLやPythonも使える

前処理をちまちまと変更しながらテストしたいことは多々あると思うのですが、これもクラウドで完結できます。
Azure MLはデータをSQLで抽出したりPythonで簡単な処理を追加したりできます。またPythonのライブラリとしてAnacondaが用意されています。これを使って大概の処理はできるためローカルと変わらない処理をクラウド上で完結することができます。地味ですがこの機能のおかげて痒いとこに手が届きます。
便利ですね。

Azure Machine Learningのここが気になる

機械学習アルゴリズム自体を変更できない自由度の低さは悪い点かもしれません。
f:id:Grahamian:20170726151407p:plain
↑こんな感じにAzure ML上ではパラメータチューニングはできますがアルゴリズムの変更はできません。Neural Networkもhidden layerの数やnodeの数を変更することはできますが複雑な変更はできません。「既存のアルゴリズムを改修したい!」「新しい論文のアルゴリズムを実装したい!」というのはほぼ無理です。
これはAzure MLがコモディティ化した技術を簡単に扱えるようにするツールなので方向性が違うのだろうな、と思います。Deep Learningをガッツリ活用するならAzure MLではなくコードを書いてスクラッチするか、用途に合うものが有るならばGoogleの学習済みAPIを使うのが良いと思います。
加えてUIがモッサリすることがちょっと気になりました。そのため前処理のテストなど「処理は軽いけどトライ&エラーが多い」みたいなケースはローカルで処理するほうが早いことがあります。

Azure Machine Learningはいいぞ

Azure MLを用いることで多くのビジネス課題の解決やプロダクトへの応用が手軽かつ高速に行えます。
最先端の機械学習技術を用いたプロダクトには向きませんが、多くのビジネス課題やデータ分類にはAzure ML上のアルゴリズムで十分です。機械学習のコモディティ化がよく話題になりますがAzure MLはそれを具現化したツールだと感じます。
エンジニアリングで効率化のためにツールを活用しているように、AIラボでは機械学習の場面でも最新のツールをガンガン活用していきます!

GYOMU Hackers Night vol.2をセールスフォース・ドットコム様のオフィスで開催しました

どうも、こんにちは。freeeでGYOMUハックという社内の業務改善系エンジニアをしている廣野です。

4月にfreeeとビズリーチさんで協力して、業務改善系エンジニアを集めたGYOMU Hackers Guildというコミュニティーを立ち上げました。経緯としては、社内に閉じがちになってしまう社内向けシステムを触るエンジニアが、同じような悩みを抱えているのではないかと考え、それを相談して、さらなる高みに行けるような集まりができればいいなと考えたことがきっかけでした。

そして先日、セールスフォース・ドットコム様のオフィスをお借りして、GYOMU Hackers Night vol.2を開催したので、その様子を紹介します。

peatix.com

Lightning Talk

LTは株式会社LIFULL・藤原裕也さんとランサーズ株式会社・土屋雅彰さんに発表していただきました。 LIFULL藤原さんは、Salesforceと業務システムを連携した業務改善の事例、ランサーズ土屋さんはコミュニケーションツールとSalesforceを連携したコミュニケーションの改善の事例を発表してくださいました。 とても参考になる内容でした!

f:id:mirygoaround:20170627201344p:plain

発表資料については、GYOMU Hackers GuildのFacebookページで公開されているのでぜひご覧ください。

パネルトーク

vol1のときは、テーブルトークがメインでしたが、今回は趣向を変えてコミュニケーションをテーマにしてビジネスチーム側、エンジニアチーム側にわかれてのパネルトークを行いました。

ファシリテーターはコードキャンプ株式会社・矢野目佳太さん(写真一番右)、 ビジネスチーム側パネリストは株式会社ビズリーチ・白石剛爾さん、freee株式会社・坪井亜美、エンジニアチーム側パネリストは株式会社ビズリーチ・田中聡さん、freee株式会社・廣野美里、でした。(写真の左から名前順) f:id:mirygoaround:20170627141846p:plain

パネルトークではビジネスチーム側とエンジニアチーム側の感じ方の違いと歩み寄り方について、盛り上がりました。

ここが変だよエンジニアチーム

1.要件の持ち込み

坪井:エンジニアとビジネスサイドでは時間間隔が違う。ビジネスサイドでは明日から効果測定したいのに数週間かかると言われてしまう。そのスピード感では次の施策が決められない。

白石:エンジニアからそもそもそんなことはできないと言われることもある。ビジネスサイドの説明が足りていないのは自覚しているが、汲み取って欲しい。

坪井:ビジネスサイドで内容を6割くらい考えて持っていっても、エンジニアから要件がわからないと撥ねられる。

田中:エンジニアとしては、依頼されたその数字が見えることでどうなるのかが分からない。可視化した先が知りたい。

廣野:エンジニアサイドからするとシステム要件よりも何をやりたいのか言って欲しい。毎回依頼が来るたびにビジネスサイドにヒアリングすることになる。

坪井:スピード感が大事だからと、ビジネスサイドでやりたいことでできることを全部やってたら、Salesforceが散らかってしまった。

廣野:そして余計に闇が広がるんだよね……笑。

2.ビジネスサイドとのコミュニケーション

廣野:ビジネスサイドからの依頼はJIRAで来るが、文字のコミュニケーションが辛い。依頼をもらった時点で対面でのコミュニケーションをしに行く。

田中:自分も同様。文字では相手の感情が分からない

3.エンジニアからの歩み寄り

田中:エンジニア的にスピード感が必要だと感じたら、PDCAサイクルを回すために一旦要件の曖昧さは度外視する。 →実装/運用後にビジネスサイドからフィードバックをもらい、目的がずれていないことを確認している。

4.具体性が分からない要件への対応について

白石:相談という形で、一旦エンジニアサイドに話を聞いている。話を聞いてくれ、対応案を出してくれるので助かっている。

廣野:エンジニアとしても要件がふわっとしているなら、具体的な依頼ではなく相談なのだと伝えてくれると嬉しい。

田中:エンジニアもビジネスサイドの情報を常に収集し、先にビジネスサイドに働きかけるようにしている。

ここが変だよビジネスチーム

1.施策の実行について

廣野:ビジネスサイドは短期間にたくさんの施策が実施されては無くなっていくのでそのスピードについていくのが大変。それに、それぞれのステークホルダーが分からない。

坪井:数が多すぎて、ビジネスサイドもよく分かっていない。

廣野:組織全体として、うまいやり方をするために体制から考える必要もあると思う。

コミュニケーションをより良くするために……

白石:ビジネスサイドとしてはコミュニケーションとリソースの調整が大事。役割とスケジュールをはっきりさせる。分からないことは積極的にコミュニケーションを取って溝を解消していく。

坪井:エンジニアに完璧を求めすぎない。ビジネスサイドもSalesforceが使えることが一種の営業スキルだという想いで自ら学ぶことも怠らない。

廣野:ビジネスサイドから相談が来た場合は、他にも同様の件で困っている人がいるのではないかと意識しながらフォローに入る。

田中:使うのはあくまでもビジネスサイドのメンバー。使っているビジネスサイドの業務フローや各場面での使われ方を知っておく。

ー結論ー:ビジネスサイドとエンジニアサイドがそれぞれ歩み寄ることが大事!!

Q&A

Q:YES/NOしか答えてくれないエンジニアにはどうコミュニケ―ションを取れば良いか?

A:廣野:かつてリソース面で対応ができなかった場面があった。自分はYES/NOだけでは答えないよう心がけている。なんでNOなのか、なんでYESなのかの理由もセットで聞くと良いのではないか。

  田中:ミスを恐れて、確実に対応できるものでないとYESと言いづらいのかもしれない。その方の上司も巻き込んでコミュニケーションを図ることが良いかもしれない。

こんなかんじで、かなり盛り上がったパネルトークとなりました。

テーブルトーク

そのままの流れでコミュニケーションをテーマにしたテーブルトークを実施。ものすごく盛り上がっていて、真剣に話されていました。同じ悩みを抱える方は多いみたいでした。

次回

次回のGYOMU Hackers Night vol.3は8/23にビズリーチさんのオフィスで行います! ご興味のある方はぜひご参加ください!!!

詳細はGYOMU Hackers GuildのFacebookページにてご連絡いたします。

New Relic で取得したデータや独自に集計したパフォーマンスログを Re:dash で可視化する

こんにちは、エンジニアの foostan です。 freee では法人向けの決算や申告まわりの開発を主に行っています。

先日「【AWS・New Relic・freee】合同セミナー AWSで実現するクラウド・ネイティブ ITサービス」というイベントに登壇して来ましたのでまずはその報告をさせて頂きます。

私の発表内容の概要は以下のとおりです。

freeeのクラウドサービス活用術とパフォーマンス改善活動のご紹介

freeeでは会計freeeや給与計算freeeなどのクラウドサービスを開発・運営していますが、実際にはAWSやNew Relicといった様々なクラウドサービスを活用しています。freeeでのクラウドサービス活用術として、いくつか事例を交えながら紹介したいと思います。またサーバのレスポンスタイムの改善にフォーカスして、どのように行っているかをより具体的に、技術的な観点と組織的な観点でご紹介いたします。

発表で使用したスライドが少々長いので、本ブログでは事例をひとつピックアップしてご紹介します。 なお、パフォーマンス改善活動については昨年のアドベントカレンダーに投稿しましたので、よろしければこちらも御覧ください。

qiita.com

パフォーマンスログを Re:dash で可視化する

freee ではパフォーマンスを測る指標として New Relic で取得したデータや独自に集計したログを用いており、それらを Re:dash で閲覧できます。

f:id:foostan:20170621012225p:plain

New Relic のデータを Re:dash で可視化する

New Relic のデータは保存期間が短く、APMBrowser の場合は PRO 版にしても最大で 90 日までです。 また Insights を利用すると独自のグラフとダッシュボードを作成することが出来ますが、こちらは最大で 8 日までです*1

パフォーマンスを中長期的に監視したい場合これだけの期間しか見れないとなると少々物足りません。 またダッシュボードを作るにしても New Relic 以外から取得したデータも一緒に見たい場合は Insights では実現できません。

そこで freee では New Relic のデータを API で取得し、そのデータを Redshift に取り込んで Re:dash で可視化できる仕組みを作りました。 技術的に難しい点はあまりなく既存のツールやサービスの組み合わせだけで実現できました。

具体的には以下のようなグラフなどを作成し、日々の改善に利用しています。

f:id:foostan:20170621020048p:plain

独自に集計したパフォーマンスログを Re:dash で可視化する

サービスをご利用して頂いている事業所毎に扱うデータ量は異なるため、それに伴いパフォーマンスも事業所毎で異なってきます。 freee では Controller/Action *2 毎のプロセスタイムをログとして取っていますが、パフォーマンスを監視/改善するにあたって事業所のIDを付与しています。 またそのログは fluentd 経由で S3 に保存され、最終的に Redshift に取り込まれて Re:dash で可視化できるようになっています。

具体的には以下のように事業所の特徴毎に分類してパフォーマンスを監視しています。

f:id:foostan:20170621021727p:plain

最後に

イベントではクラウドサービスの活用事例の紹介ということでいくつか挙げさせて頂きましたが、どれもトリッキーな使い方はしておらず、シンプルな組み合わせで利用しています。 会場にいらした方々やこれを見ている方々にとって少しでもご参考になれば幸いです。

freee では既存のサービスを組み合わせて効率化したり、パフォーマンスを改善するのが好きな仲間を募集しています!

発表で使用したスライドはこちらになります。

*1:https://newrelic.nissho-ele.co.jp/price (代理店などにより多少異なります)

*2:Ruby on Rails の Controller/Action のこと