登壇者プロフィール

株式会社LayerX　花村 直親氏
2020年6月LayerXに入社、バクラク請求書のプロダクトマネージャー兼エンジニアを担当。WEB開発・コンサル・データ分析などで一貫してB2Bに携わってきた経験を活かしてSaaS立ち上げに注力。B2Bの世界でコードを書くことがもっと重要と思われるように日々努力している。

Ubie株式会社　松村 直樹氏
2019年10月にUbie株式会社に入社。事業開発メンバーとして、病院向けカスタマーサクセスの立ち上げ等を行う。その後、ユビーAI問診のプロダクトオーナーに転身し、COVID-19向け機能開発や問診改善などを推進。現在は、生活者とクリニックをつなぐサービスの立ち上げに従事。

Chatwork株式会社　高柳 龍太郎氏
2019 年にChatwork株式会社へオーガニックを中心としたWebマーケターとして入社。サービスサイトのリニューアル・オウンドメディアの立ち上げを経て、2020 年にプロダクトマネージャーへ転身する。グロース施策やクライアントサイド施策を中心に、数々のプロジェクトを担当している。

株式会社オープンエイト　古山 亜人氏氏
広告プランナー→フリーランスのクリエイター→エンジニアという謎の経歴で、2018年オープンエイトにジョイン。PdMのリードとしてプロダクト全体のサービス品質向上に取り組んでいる。

“爆速開発”を支える寄り道しないロードマップの作り方

このような課題解決に取り組んでいるのが、LayerXの開発した「バクラク請求書（旧LayerX インボイス、2021/12/10にリブランディングを発表）」だ。紙の請求書をOCRで読み取るとAIが内容を把握し、自動で仕訳を行う。さらには社内の会計帳簿や決算書、オンラインバンキングにも、自動かつシームレスにデータ連携する。

「手入力をできるだけ減らすことで、業務時間はこれまでに比べ大幅に削減します。人が介在しないため、人的ミスも激減。AIですから作業を継続すればするほど賢くなります。属人化対応ならびに、引き継ぎ業務もスムーズになります」（花村氏）

最初に登壇したLayerXの花村直親氏は、「バクラク請求書」の概要や導入メリットについて説明した後、事業の成長状況について説明した。

「2021年の1月にリリースして以降、導入企業は30倍以上、処理する請求書の枚数は約40倍に成長しました。このような状況下でPMF (プロダクトマーケットフィット)を継続するためには寄り道をせずに、お客様からの要望に的確に応えていく“爆速開発”が必要だと考えました」（花村氏）

爆速開発を実現するためには、上記のような「地図」と「コンパス」からなるロードマップを設計することを決め、以下の4つのステップで進めた。ステップ１では、ユーザー、CS（カスタマーサービス/サポート）、営業など、様々なチャネルから要望が上がってくるが、大切にしたのは「ユーザーの行動ログや直接ユーザーに話を聞く一次情報」だと、花村氏は強調した。

ステップ２では大量に抽出された要望をまとめていった。例えば「支払の上長確認を行いたい」「上長の許可なく支払金額を変更させたくない」といった要望は、「上長による支払の承認機能」に集約する。

ステップ３・４では抽出された機能を企業の属性を企業規模、業界などに振り分け、マッピングしていった。花村氏は、地図を作成した理由を改めて次のように説明した。

「機能要望は無限に増えていきますから、どこから開発をしていくのか。また、自分たちのプロダクトはどこの領域で求められているのか。マッピングすることで、これらの情報が可視化しますから、戦略を立てることができます。そして戦略がそのまま、開発の優先順位の指針ともなります」（花村氏）

例えば、SMB（Small and Medium Business：中小企業）全般で機能開発を行い、PMFを達成した後、SMB製造業におけるPMFを繰り返す。その後、MMB（Middle-Market Business：中堅企業）製造業におけるPMFの戦略をロードマップに描いていく。

具体的には四半期、月次ごとにタスク分けし、可視化したロードマップとする。花村氏は最後にPdMとして大事にしていることを以下のように述べ、セッションを締めた。

「PdMの役割は、不確実性を下げることだと捉えています。機能要件を抽出する際、本当にニーズがあるのかどうかが重要です。実装における課題などを事前に調査・検証しています。ただし、1人ではやりません。新しい機能を実装したら、どのようなUXが加わるのかを紙芝居（スライド）を作成することで具体化し、エンジニア、デザイナー、CSなど全メンバーで議論します。実際、検証段階でマッピングから外れる機能もあります」（花村氏）

ロードマップを作成しない。柔軟に優先順位を変更できるホラクラシー型組織

「テクノロジーで人々を適切な医療に案内する」というミッションを掲げ、医師とエンジニアが2017年に創業したUbie。現在は大きくBtoC、BtoB向けのSaaSを展開する。

まずは、「ユビーAI受診相談」について説明された。不調があった場合、Webやスマホに表示される20ほどの質問に答えていくことで、関連する病名や診療科、さらには位置情報をリンクすれば、近くのクリニックなどを提示してくれる。すでに利用者は300万人を突破している。

もうひとつは、医療機関向けの「ユビーAI問診」だ。問診をタブレットに置き換えることで、カルテ入力時間を削減。医師・看護師の業務効率化に寄与するのはもちろん、問診の深堀りもできるため、診察の質を高めると期待されている。500以上の医療機関で導入が進んでおり、今後はこれらのSaaSをもとに、さらなるプロダクトやサービスを展開していく。

登壇した松村直樹氏は、ロードマップについて次のように説明した。

「以前はロードマップを作成していましたが、今はしていません。ゼロイチフェーズの開発業務が多い状況だからです。新規開発プロダクトやテーマや機能の陳腐化などから、優先度が変わることが多く、ロードマップを書き換えることが多かったからです」（松村氏）

ロードマップがない状態で、どのように優先順位を決めているのか。特定のプロダクトで優先順位を決めるのではなく、会社全体で調整しながら、常に全社最適化を考え進めている。松村氏は3つのキーワードを挙げ、詳しく説明していった。

１．OKR（目標設定と管理）
２．スクラム（アジャイル開発）
３．ホラクラシー（権限分散組織）

トップダウンのようにも思えるがそうではなく、各レイヤーのメンバーが意見をすり合わせた上で、優先順位を決めていく。

中でも最も重視しているのが、ユーザーの声だ。ただし、コストはかかる。説明を聞いただけでは、優先順位がスピーディーに導き出せるようには思えない。松村氏は次のように補足した。

「なぜ、このようなフローで優先順位を決めているのか。目標やロールに応じて組織や体制を瞬時に、そして大幅に変えることができる『ホラクラシー』というティール組織を実現するためのフレームワークを採用しているからです」（松村氏）

Ubieにはスケールに特化したUCS（Ubie Customer Science）というチームがあり、松村氏が所属する事業開発組織のUbie Discoveryとは完全に別の組織として動いている。そのため松村氏が説明したホラクラシーなどの取り組みは、UbieDiscoveryに限られる。

このホラクラシー型の組織のおかげで、新しい機能やプロダクトの開発が、柔軟に行われている。ただし、すべてが開発されているわけではなく、優先度が低くなったテーマに携わっているチームはあっさりと解散する。そして、優先度の高いチームにアセットをつぎ込むロジックであり、スタイルだ。これを「目標をコロコロ変えている」と松村氏は表現した。

このような開発体制のためロードマップはもちろん、具体的な機能や短期的な計画は提示しない。一方、ビジョンや2つのサービスのリンクなど、中期的な展望は明確に提示する。また、顧客・マーケットと共に、プロダクトを作り上げる考えは同じくしっかりと明示することで、顧客からの信頼を得ているという。

PdMに必要なのは事前のルール作成共有ならびにコミュニケーションスキル

コロナ禍以降、オンラインによる業務が浸透すると共に、業務効率化ツールが次々と登場している。Chatworkはそのオンラインツールのひとつである。

リリースは2011年と歴史があり、「グループチャット」「タスク管理」「ファイル共有」「ビデオ・音声通話」といった機能が1プロダクトで完結することから、ビジネスチャットとして利用する企業も多い。

登壇した高柳龍太郎氏は、ロードマップの全体感を示しながら、優先順位がどのようなフローや指標で決められているのかを説明していった。

「弊社では大きく3つの組織があり、方向性を決めるのはメタスクラム組織です。メタスクラムで決めた方向性を左側の本部、ビジネスサイドや役員が属するカウンシル組織に提案し、承認されます」（高柳氏）

メタスクラムでは、具体的にどのような議論が交わされているのか。業務ツールのJIRAを使い、企画の背景や期待する効果を共有する。その上でPMやPdMが集まり、どの企画を優先していくのかを決めていく。「事業戦略」「開発リソース」「ユーザー体験」など、指標は様々あるという。

高柳氏は、自身が担当した1つのモバイルアプリ内で、複数のアカウントを利用できる「モバイルマルチアカウント機能」を紹介した。Webブラウザでの利用はセキュアではないという懸念から、ユーザーアンケートで追加してほしい機能の2位だったこともあり、開発は急がれた。

さらに実際に開発を進める上で、PdMとして注意していることを、実際の開発フローをもとに紹介された。

「開発メンバーに対しては、プロダクトの機能や仕様を『RPD（product requirements document：プロダクト要求仕様書』に落とし込み、共有する。役員をはじめとするビジネスサイドのステークホルダーにも共通認識を持ってもらうため、コミュニケーションハブになることを意識していました」（高柳氏）

高柳氏は、4つに分けたフェーズの適するタイミングでの注意点を挙げた。例えばリリースフェーズでは、ユーザーに対して機能価値をどういう見せ方で届けるのか。デリバリーのスケジュール感の詳細を、広報・CS・ビジネスサイドと連携しながら、最終的な調整を行っていった。

高柳氏はPdMとしてのこれまでの取り組みを振り返り、それぞれのスコープでの課題と取り組みを紹介すると同時に、改めてPdMが求められる役割やマインドを話し、セッションを締めた。

「やはりコミュニケーションスキルが重要だと感じています。また、意思決定や仕様変更時の共有ルールは事前に決めておく。クリティカルパスを通じ、プロジェクト全体を把握することで、プロダクト間の連携でミスコミュニケーションを防ぐことも重要です」（高柳氏）

PMFするプロダクトをスピーディーに開発する組織体制

動画編集の知識がない人でも、AIのサポートで気軽に使える動画編集ツール「Video BRAIN」を開発しているのがオープンエイトだ。登壇した古山亜人氏は、まず2018年にVideo BRAINが生まれるまでの歩みを紹介した。

「当初はUIの上部に、最適な動画広告を掲載するプラットフォームの開発からスタートしました。その後、すべて内製で制作を行う動画と記事のメディア『ルトロン』というサービスに発展。同サービスで数多くのデータを得たこと、実際に動画を制作した経験を活かし、現在のプロダクトにつながっています」（古山氏）

Video BRAINの立ち上げ時は、テクノロジー開発本部内のSaaS部が開発を担っていた。また、PMFを探るフェーズであったことからスピードを優先し、市場に投入。品質がまだまだアーリーなところもあったが結果として市場ニーズを得ることができ、プロダクトの目指すべき方向性を得る。

その結果、プロダクトマネジメント部が発足。CPO（Chief Product Officer)などのポジションも生まれ、現場から上がってきたニーズを機能に落とし込んでいく体制が整っていった。

現在は、エンジニアやデザイナーなど、機能（スキル）で分けていた体制を、プロジェクト別の開発体制へと移行した。またプロジェクトでは、機能開発チーム、品質改善チームにも分けられた。いわゆる、クロスファンクショナルな組織である。

「新規開発と改善が並行して動かせるようになったことで、プロダクトのクオリティが確実に高まっていると実感していますし、チームとして目線も合わせやすくなったと手応えを感じています」（古山氏）

続いては、プロダクトの開発サイクルが紹介された。フィールドセールスからの失注要因、CSからの機能要望、社内からの事業戦略、プロダクト方針などをかけ合わせ、優先すべき機能を決定し、開発ロードマップを作成していく。

それぞれの領域・フェーズにおいても、詳細に説明された。例えば、CSが顧客から頂いたフィードバックも内容を精査、定量的にスコアリングを行っている。スコアリングされた要望はPdMがチェックし、似たような要望を課題（issue）としてまとめる。issueにまとめる際には、自分の言葉でしっかりと整理・理解した課題となっており、課題の大きさは定量化されている。

こうしてまとまったissueをさらに関連づけ、機能リリース単位としてバックログに取りまとめ、バックログとして具体的にどの程度、現場の要望やニーズに応えられるのかを定量化する。その上で優先すべきバックログを開発ロードマップに組み込み、機能要件がかたまったらPjMと協力して開発を進め、リリースまで持っていく。

「バックログの優先度においては、事業目標のKPIに寄与するかどうか。具体的には、チャーンレート（解約率）が大きな指標となっています。品質の指標に関しては、狩野モデルを参考にしています」（古山氏）

狩野モデルとは、東京理科大学名誉教授の狩野紀昭氏が提唱した、顧客満足度と品質の関係を表したモデルを指す。海外でも「Kano Model」として広まっているフレームワークだ。オープンエイトのモデルを見ると根本は同じだが、オリジナルとはやや表現を変えていることが分かる。

古山氏は最後に次のように述べ、セッションを締めた。

「今後の展望としては、分析サービスにも注力していきたいと考えています。また、他のSaaSと連携し、新たなシナジーを生む機能追加を考えています」（古山氏）

【Q＆A】参加者からの質問に登壇者が回答

続いては、参加者からの質問に登壇者が答える質疑応答が行われた。

Q．ユーザー調査はどのような手法で行っているのか

花村：実際の業務フローを聞き、それを視覚化してどこに課題があるのかをヒアリング。実体験による課題やニーズを聞くようにしています。

松村：まずは仮説を立て、社内のヒアリングでニーズの解像度を上げていきます。その上で実装、リリースします。ただし作り込まず、簡易機能とするように心がけています。その方が、現場から多くのニーズやアイデアを聞けるからです。

高柳：アプリの「ご意見・ご要望欄」から得た情報を収集しています。また、ユーザー導線をチェックし、事前に立てた仮設が正しいのかも検証しています。

古山：CSがユーザーから直接伺うケースが多いです。その上で詳細なヒアリングを行い、具体的なニーズを分析するようにしています。

Q．優先度は最終的に誰が決めているのか

花村：最終的には事業部長と協議して決めますが、プロセスはオープンかつ多くの人が介在するようにしています。具体的には、セールス、CSからランダムにメンバーを呼び、1週間に一度の頻度で、要望や優先度を決めるミーティングを開催しています。

松村：スコープごとに推進を担うプロモーターがアサインされ、様々な人から意見を聞き、擦り合わせた上で決定していきます。チームにおいてはプロモーター、開発バックログであれば、スクラムチームのプロダクトオーナーといった具合です。

高柳：先に紹介したカウンシル組織で議論され、最終的にはCEOが承認します。議論の内容は議事録として公開されるのと同時に、月一の定例会で、CEOから全社員に説明があります。

古山：CSが顧客から頂いた情報をPdMがとりまとめ、CPOやCTO経由でCEOに稟議を上げます。最終的な決裁はCEOが行っています。

Q．プロダクト単位のPO/PdM、デザイナー、エンジニアなどの人数・構成を聞きたい

花村：1プロダクト2～3人ぐらいの体制で、エンジニアがPdMを兼任したりしています。現在少人数ではありますが、人員拡大している最中です。

松村：スクラムチームで分けていて、1つのスクラムチームは少なくても3人。また、ツーピッツァルールが適用されているので、多くても8～9人といった状況です。

高柳：スクラム形式で開発を行うフィーチャーチームの場合は、POが1名、PMが兼任していることが多く、エンジニアが5～6名、デザイナーが1名という体制です。一方、ロードマップのプロジェクトに関しては、サーバーサイド、Webフロントエンドチームから1～2名アサインし、PM ・PjMが1名ずつ。全体で10～12名の場合が一般的です。

古山：プロジェクトにより異なりますが、基本的にはデザイナーとQAは兼務でプロジェクトを横断しています。人数としては兼務のメンバーも含め8～13名です。

Q．ロードマップ作成の失敗談は？

花村：すぐに実装する必要があるという声があったため、機能のすべてを把握していないまま、ロードマップに載せて開発を進めたものの、初期把握していなかった部分で推進が難しくなる部分が見つかることがありました。ほかにも、解像度が低い段階で開発を進めたら、プロダクトの思想とはかけ離れていた機能であったため、すぐに開発を止めました。

松村：具体的な機能を書きすぎると、違うものを開発しづらくなる課題があります。一方で抽象的な課題のまま開発を進めると、逆に機能やプロダクトのイメージが湧きづらい課題があり、そのバランスで苦労しています。

高柳：ロードマップ（機能追加）では部署横断でチームが組まれ、開発を進める体制です。そのため、リソース状況や他のプロジェクトの優先度の変更により、プロジェクトの優先度が下がってしまったり、開発がストップしてしまったりなど、調整が難しいと感じたことがありました。

古山：初期のフェーズでは、ロードマップに不確実性が高く中長期の開発が必要なプロジェクトを盛り込んでいました。そのためデリバリーの1カ月に前に達成できないことが判明し、大きなリリース計画の変更が発生してしましました。

株式会社オープンエイト
https://open8.com/

株式会社オープンエイトの採用情報
https://open8.com/recruit/