1. GeekOut
  2. コラム
  3. 「リリースしてから考える」 アウトプット思考で駆動する、freeeのプロダクトマネジメント
ログアウトしました

「リリースしてから考える」 アウトプット思考で駆動する、freeeのプロダクトマネジメント

クラウド会計ソフトfreee」をメインに、スモールビジネスのバックオフィス業務支援に特化したプロダクトを続々リリースしているfreee株式会社。ERPパッケージの会社でのエンジニア経験を経て、2015年にfreeeへジョインし活躍する泉 祐一朗さんに、プロダクトマネージャーの仕事について伺いました。

プロダクトアウトからユーザー起点に開発体制を変更

――泉さんが担当しているプロダクトについて教えてください。

 パートナー事業部の開発責任者として、freeeの中でも社労士や税理士など専門家向けのプロダクトを担当しています。メインは会計事務所向けの「クラウド会計ソフトfreee」、他には税理士の方向けの「クラウド申告freee」や、いくつかの小さなプロダクトですね。

従来はプロダクトごとに担当分けがされていたのですが、2018年7月からはユーザーセグメントごとにエンジニア、セールス、マーケティングで一緒にチームを組む体制になりました。チームメンバーには、公認会計士、税理士の資格の保有者が在籍しています。ユーザーの立場でプロダクトの使い方が分かる人がジョインすることで、さらにいいものを作るチャレンジを始めています。

f:id:blog-media:20181204150139j:plain
プロダクト開発本部 エンジニアマネージャー 泉 祐一朗氏

 創業当初のfreeeのターゲットは個人事業主やSOHOのお客さまでしたが、徐々に中小企業からミッドマーケット、そして士業にまで広がり、ユーザーセグメントが変わってきています。同じ業務であっても、個人事業主と専門家の方では、要件や使い方、求められる品質が異なります。

――専門家向けのプロダクト開発にはどのような難しさがあるのでしょうか。

 士業、専門家のお客さまは、当然ながらご自身の専門分野には精通していますし、その分プロダクトに細かい機能を求められます。私自身には財務、会計、人事などの経験がないので、まだまだ勉強中です。ただ、開発にあたっては、お客さまがどのようにプロダクトを使うのか、といった業務理解が大切だと思います。

会計や人事などのレガシーな領域は、これまでモダンテクノロジーが入ってきていなかった分野でもあります。そこをfreeeのようなユーザーエクスペリエンス(UX)にこだわったアプリで、技術の力を使って効率化していくこと、そして数字として結果が現れることに、やりがいを感じます。

不確実性に強いアジャイル開発

――開発の課題としては、「新しいプロダクトや機能の実装」と、「現在提供されているものに生じている問題の解決」の2種類があると思います。どちらを優先すべきだと考えていますか?

 「その問題で困っているユーザーの数はどれくらいか」と「会社としてやるべきことはなにか」を基準に判断します。目標管理にはOKR(Objective and Key Result)というフレームワークを採用しており、3カ月単位で目標が設定されます。会社全体のOKRからブレイクダウンして開発チームのOKRが設定され、達成のためのタスクが最優先されるような仕組みです。例えば、「クオーターごとに品質をこのくらい上げる」「ユーザーのこの業務における効率を○%上げる」などの目標を設定して取り組むことになります。

OKRとは
OKRは、Objectives and Key Resultsの略。大きな目標の「O」(Objectives)と具体的な数値目標の「KR」(Key Results)を設定するフレームワーク。一週間単位で振り返りを行うため、目先の数字に振り回されず、ポジティブに目標を達成でき、生産性が向上する。

 

 

 

――どのように開発業務をマネジメントされていますか?

 開発に関わるメンバーを3つのプロジェクトチームに分けています。プロダクトマネージャー(PM)とエンジニア、デザイナー、QA(品質保証)エンジニアで1チームとなって、アジャイル開発の手法の1つであるスクラムを採用しています。

PMはスクラムのプロダクトオーナーの役割で、プロダクトのバックログを作成し、スプリント計画を提示します。その計画を実現していくのがエンジニアの役割となります。

スプリントとは
定められた期間内に特定のユーザーストーリーのセットを実現し、動作する機能を生み出す時間枠。

 

 

 

f:id:blog-media:20181204150223p:plain

 中長期的なロードマップを作成する時には、コンセプトをドキュメントにまとめます。そこには、「なぜこれをやるのか」「どのような利点があるのか」「どんなユーザーを対象にするのか」といったことが記述されています。それをPM間でレビューして、コンセプトベースのドキュメントを完成させます。

一方で、細かい仕様はドキュメント化をせず、PMとエンジニアが密にコミュニケーションしながらスプリントのサイクルで実際のものづくりを行います。MVP(Minimum Valuable Product)を見極めた上で、しっかりとそれをエンジニアに伝えていくことが重要になります。

MVPとは
MVPはMinimum Valuable Productの略。プロダクトを提供する上で必要最小限のシンプルな機能。ユーザーにとって価値があり、利益を生む最小限のもの。

 

スプリントのサイクルは、チームによりますが、おおむね1、2週間単位です。最初の計画時に作成したスプリント・バックログを順番に実行し、スプリント・レビューのタイミングでチェックします。出来上がったものは社内の詳しい人や、場合によってはお客さまにも見ていただき、次のスプリントにフィードバックします。

――問題解決のフローについて教えてください。

 問題発生時の明文化されたルールは決まっておらず、私とプロダクトマネージャーが都度判断します。OKRも重要ですが、プロダクトの健全な状態とチームとしての健全な状態を考慮します。指標としては不具合発生率と発生から開発までのリードタイム、新規開発についてはステップに対する不具合率、チームに対してはベロシティと企画からリリースまでのリードタイムを見ています。

ベロシティとは
1スプリント中に完了したプロダクトバックログ項目の見積りの合算値。決められた期間の中で、チームが要求に答えられる量。

 

――全面的にアジャイルを取り入れた開発体制ですが、定着させるのは難しかったですか?

 そうですね。初めは手探りで、「なんとなくアジャイル風」という状況だったのは確かです。エンジニアリーダーと一緒に本を読んで理解を深め、スクラムマスターからチームへと広げていった感じです。リードタイムとベロシティを見える化して追っていくことで、意識が強まりました。アジャイルが社内に定着するには半年ぐらいかかりましたね。

――そこまでしてアジャイルを選択したのはなぜですか?

 個人的には、アジャイルの良さは市場と見積りの不確実性に強いことだと思っています。市場の不確実性とはつまり、「リリースしてみないと分からない」ということなのですが、これはアウトプットから思考に落とし込むことと相性がいい。いくら考えても、その通りに進まずに失敗するのが開発というものです。それなら、3カ月かけて1つのものを出すのではなく、3つ出して小さく失敗する方が良い。freeeの市場はそれほど不確実性が高い領域ではないですが、小さく失敗し、改善を重ねることでプロダクトは強くなります。

f:id:blog-media:20181204150256j:plain

見積りの不確実性はどうしても避けられません。最初の見積り通りに進まなければ、サボるか、頑張るか、人を増やすかしかないですよね。アジャイルのいいところは、時間と規模を分けて、見積りが不確実なことを受け入れてやっていくことだと思います。

――「不確実」では困る部分もあるかと思います。会社とのすり合わせについては、どのようにしていますか。

 会社にとっては、製品としてのロードマップが重要なんです。つまり、売るためには、いつ製品ができるのかが知りたい。そこは保守的に、「確率は8割」「確率は5割」というように含みを持たせて伝えています。MVPを見極めて、製品としてのリリースは死守するけれども、プラスアルファの機能についてはスケジュールが厳しくなれば切り捨てます。

つまり、製品ロードマップは作った上で、それでも柔軟にやることを宣言しています。会社としてプロダクトが尊重される文化なので、そこは助かっています。

アウトプットから思考を経て、動く

――泉さんご自身の仕事について、もう少し詳しくお聞かせください。

 大きく分けると、プロダクトのマネジメントとエンジニアのマネジメントの2つです。現在はマネジメントが主で、業務として自分がコードを書くことはほとんどなくなりました。

プロダクトマネジメントでは、実際にプロダクトの仕様を決めるよりはもう少し上のレイヤーで、パートナー事業全体を考えて、予算管理と、製品ロードマップを決めていきます。専門家のプロダクトマネージャーと一緒に、3カ月先に何をレビューするかを考えながら次の企画を考えています。

エンジニアマネジメントでは、メンバーとの1on1が主になります。自分の直属(リーダー)とは週1~隔週、メンバーとは月1で実施してます。3カ月単位でキャリブレーション(人事考課)の準備と本人へのフィードバックを行っています。

あとは開発プロセス改善ですね。最近では、アジャイル開発を根付かせるための勉強会に取り組んでいます。体制強化も私の役割で、業務委託先の検討や採用面接を行っています。

――あらゆることに携わっている印象がありますね。事業全体を考えて製品ロードマップを作っていくということですが、どのように戦略を立てていくのでしょうか。

 事業部長やセールス担当者との1on1を通して仮説を作り、検証しながら正しいと思う方向にマイルストーンをセットしていきます。とはいえ、決めた通りに作ってもうまくいくとは限りません。その不確実性に対応するために、先ほどお話しした通りアジャイル開発を取り入れて、「小さく作り、小さく失敗して、小さく改善する」。マイルストーンも最初は大きな粒度で作って、修正しながら少しずつ精度を上げていきます。

f:id:blog-media:20181204150323j:plain

――これまで失敗はありましたか?

 失敗のパターンとしてよくあるのは、エンジニアとセールスの認識の齟齬(そご)があり、期待どおりのものが作れずに足並みがそろわないというものですね。原因はコミュニケーション不足。こちらが良いと思って作った機能が、セールスの現場からすると「なぜこんなものを作ったのか」というようなものだったり、要件をしっかりと決めずに進めてできた結果が求められていた内容と異なってしまっていたりといったことが起こります。

――どのように改善したのでしょうか。

 改善するには、開発プロセスが見える状態であることが重要だと考えています。作り終わってから見せるのではなく、途中のプロセスを見せ、迷ったら確認・相談します。

セールスとエンジニアで、お客さまが求めていることを共有する。その時に大事なのが、「言われたことをうのみにしない」ということです。セールスの言う通りに作るのではなく、意見を聞きつつ、どのように作るかはエンジニアが考えて共有する。お客さまからのフィードバックも大切ですが、うのみにすることなく「なぜそれが欲しいのか」「なぜその理由なのか」を深掘りして抽象化し、機能化する。そして本質的な価値を実現することが大切だと考えています。

f:id:blog-media:20181204150356j:plain

――多くの方々から意見を聞くと、深みにはまってしまい、計画通りのリリースができなくなったりしませんか。

 「リリースしてみないと分からない」というアウトプット思考から、必ずリリースはします。freeeには「本質的(マジ)で価値ある」「理想ドリブン」「アウトプット→思考」「Hack Everything」「あえて、共有する」という、5つの価値基準があります。とことん考え抜きながらも、まずはリリースしていくというのがfreeeらしい行動であり、価値判断となるのです。

「成長」にフォーカスした1on1によるマネジメント

――マネジメントでは、1on1をとても重視していますね。

 会社の文化として重視しています。自分のチームだけでなく、自分の上司や、セールス、マーケティングとも1on1で話をします。1on1用に、横並びに座れるような会議室も用意されています。新任マネージャーも、1on1の進め方について、社外研修を受けたり推薦図書を読んだりして学んでいます。

f:id:blog-media:20181204150418j:plain
1on1用ミーティングルーム。カウンターに肩を並べて会話をする

 ミーティングはアジェンダがあって結論を出すものですが、1on1は結論を出すのではなく、成長支援の機会であることが大きな違いです。人事考課でも、「どうすれば成長できるか」にフォーカスしています。

私自身の1on1の進め方も、「本人に気付きを与えることの大切さ」を意識するようにしています。最初の頃は具体的な進捗確認や、コードを見ながら議論するようなことも多かったのですが、それは業務でもできることなんですよね。それよりも、プライベートな話も含め、本人を知り、考えてもらう時間になるようにと心がけています。

――こんな話ができて良かった、という経験はありますか?

 最近の例でいえば、私から見て「頑張っているんだけど、もうひと踏ん張りが足りないな」と思える若手がいました。彼と1on1で話していると、「他人からライバル視されることが嫌だ」という、根本的な考え方を知ることができました。ライバルの存在でやる気が出る人もいますが、彼のようなタイプの人もいます。「競争するのではなく、『実現のために頑張っている人は素敵だな』と思えるようにマインドチェンジした方がいいんじゃないか」とアドバイスしました。彼にも納得してもらい、さらに力を発揮してくれています。

最近伸び悩んでいる、と相談してもらえれば、「ちょっと仕事を変えてみようか」という提案ができたりもします。技術的なところで成長できていない人であれば、新しい技術を使うタスクをアサインしてみることで、チャレンジと成長の機会になります。

タスクのアサインについても、新人には具体的に「この機能をこのように実装して」という言い方をしますが、シニアのメンバーにはもう少し抽象的な話をします。例えば「これヤバそうだから、何とかしてくれない?」みたいな言い方ですね。

具体的なやり方は、私よりシニアメンバーの方が詳しいことが多いんです。教えることができないので、どう取り組んでいるのか、なぜそう考えたのか、こうした方が良かったのではないか、という壁打ち相手をします。質問されたら質問を繰り返す、いわゆるコーチングですね。
 
――1on1で気を付けていることはありますか?

 「あまり褒めない」ということを心がけています。褒めると、短期的には良い効果もありますが、中長期的に見ると、褒めることが成長につながるということはあまりないんです。感謝を伝えることは意識しますが、なるべく本人に厳しいことを多めに言うようにしています。

――それではモチベーション維持が難しいのではないでしょうか?

 モチベーション維持に大事なのは目標設定だと思います。チームとしてのOKRと、本人の意欲と、適性をすり合わせて、チャレンジングな目標を立てること。簡単でも難し過ぎてもダメで、ギリギリ達成できるかどうかの難易度を設定することが前提です。

フィードバックでは、一般的なことを言うのではなく、「俺はこう思う」ということをなるべく伝えるようにしています。そして、達成できた時には感謝し、チームでお祝いをすることですね。

f:id:blog-media:20181204150441j:plain
広々としたfreee社のフリースペース。週次のOKRの確認やイベントはここで行われる

エンジニアリングを知っているプロダクトマネージャーは強い

――これからプロダクトマネージャーを目指したいというエンジニアの方に、アドバイスをお願いします。

 プロダクトマネージャーの一番大事な仕事は「意思決定」。そのためのデータ分析や、人から意見を聞く力、エビデンスを集める力が求められます。エンジニアリングを知っているということは間違いなく強みになります。あとは、製品が好きで、他社製品を見てもつい改善点を考えてしまうような人は、いいプロダクトマネージャーになれるでしょうね。

とはいえ、私自身は「作ること」と「考えること」を両方やっているので、あまりエンジニアからプロダクトマネージャーへスイッチしたという意識はないです。

――プロダクトマネージャーとエンジニアの違いって何なのでしょう。

 実施すべき課題を見つけてくるのがプロダクトマネージャー、解決するのがエンジニア。課題を見つけること自体は難しくないですが、本質的な問題を見つけるのは難しいです。情報を集めて、分析して、仮説を立てる必要があります。

エンジニアのスキルは分かりやすいですが、プロダクトマネージャーのスキルは分かりにくい。名乗れば誰でもできる仕事ですが、「デキるプロダクトマネージャー」になるのは、「デキるエンジニア」になるより難しいでしょうね。

――泉さん自身は、どんなプロダクトマネージャーと仕事をしてみたいと思いますか?

 実体験として、「こんなことを実現したい」と思っている人と仕事をしてみたいですね。あと、今のチームのマネージャーには専門家が多いので、エンジニアとしてすごいスキルを持っているけど自分の意志でプロダクトマネージャーに転身した人ともやってみたいです。

f:id:blog-media:20181204150511j:plain

――これからプロダクトマネージャーとして実現したいことはありますか?

 自分自身は、今の会社の方向性に共感しているので、freeeを広めるために必要な役割であれば、何でもやります。実現したいのは、世の中を効率化するモノづくりに関わることで、世の中に貢献したい、ということです。

――ありがとうございました。

(取材・構成:板垣朝子)

  • このエントリーをはてなブックマークに追加

関連記事

自分で作ったロボットをプログラミングで動かす! 子どもが夢中になる「タミヤロボットスクール」の魅力
最初から完璧な人はいない――DATUM STUDIOが唱えるデータサイエンティストの「採り方」「育て方」とは
SI系エンジニアからWEB系エンジニアへの転職って実際どうなの?~ファンコミュニケーションズ 鈴木航 編~