―― ラクスへの入社を決めた理由を教えてください

私は新卒入社で、決め手は2つありました。

1つは、上流工程から下流工程まで一貫してものづくりに関われる環境だったこと。
私が入社した当時はプログラム未経験でも採用しており（※現在は新卒の採用要件が異なります）、未経験から一貫して開発に関われる点に強く惹かれました。
もう1つは、業績とビジネスモデルです。私が就職活動をしていた当時は、リーマンショックの余波が残り、景気の先行きが見えにくい時期でした。そんななかで、ラクスはまだ規模こそ小さいながら右肩上がりの業績を維持していて、その業績とビジネスモデルに強い将来性を感じたのです。

入社後の最初の数年は「言われたことを言われたとおりにやることに必死」でした。その私を変えたのが、当時の上司の言葉です。「言われたことをそのままやるのではなく、なぜそれをやるのかを常に考え、考えても不明なのであれば尋ねなさい。気になったことがあればそれも解消しなさい」。この「なぜ（Why）」を起点に考える姿勢が、その後ブリッジSE・PjM・PdMとキャリアを広げていくなかで、ずっと自分の軸になっています。

入社後に感じた、良い意味でのギャップは「ものづくりに関わる」が想像以上に幅広かったことです。コードを書くことだけが価値ではなく、事業と開発の架け橋になって、お客様に価値を届けることそのものが仕事になっていきました。

―― 所属組織の役割とミッションを教えてください。

私が課長を務めるプロダクトマネジメント2課は、プロダクト部に属する組織です。
プロダクト部は、プロダクトマネジメントとプロダクトデザインに責任を持つ部門で、そのうちプロダクトマネジメント組織が楽楽精算・楽楽明細・楽楽債権管理・楽楽電子保存を担当しています。
私たち2課は、その中で楽楽明細・楽楽電子保存・楽楽債権管理を担当する、要求整理とディスカバリーを担うPdMの組織です。

私たち2課のミッションは、「楽楽明細・楽楽電子保存・楽楽債権管理の売上増につながるプロダクト機能と活用の価値創出に責任を持つ」こと。これは、プロダクト部のミッション「プロダクトの機能と活用の価値創出に責任を持つ」を、私たちの担当領域で具体化したものです。
開発部門と事業部門の中間に立ちながら、お客様に届く価値を最大化する。これが私たちの役割です。

だからこそ私たちは、自分たちだけで完結するのではなく、さまざまな専門職の仲間と力を合わせてはじめて価値を生み出せます。実際に作る開発、市場に価値を届けるPMM、現場の声を持つフィールドセールスやCS。こうした仲間と、週次の定例や案件DBを通じて密に連携しながら、「何を、なぜ、どの順番で解くか」を決めて前に進めます。

PdMは「お客様・開発・ビジネス」の3つを別々に扱うのではなく、その関係性すべてを扱う役割だと考えています。私自身は課長として、担当する3プロダクトの戦略と、PdMが力を発揮できる組織づくりに責任を持っています。

―― チームの日々の業務の流れを教えてください。

私たちの仕事は関係する部署が多いので、定例を通じて認識をすり合わせることをとても重要視しています。定例には、各プロダクトごとの開発とPdMの定例、PdMとPMM・事業責任者の定例、そして楽楽精算・楽楽明細・楽楽債権管理・楽楽電子保存のPdMが集まる楽楽シリーズPdM定例など、いくつもの種類があります。

定例で私たちが意識しているのは、単に情報を右から左に流すのではなく、付加価値を加えて受け渡すことです。その情報が何のために使われるのかを意識して、先の工程を見据えて意味づけを足したり、受け取る人が意思決定しやすいように判断ポイントを整理したりする、ということです。

なかでも楽楽シリーズPdM定例は、他のプロダクトがいま何に取り組んでいるかを共有できる場で、担当メンバーに質問したり、一緒に考えたり、ディスカッションしたりできます。こうした環境は個人的にもすごく気に入っていて、毎回かならず気づきや学びがあります。

定例以外では、大半の時間を「一次情報を取りに行き、課題を明らかにすること」と、そこからの「要求整理」に使っています。お客様の声を自分で取りに行き、本当の課題を見極めて要求として整理する。ここがPdMの仕事の中心です。

実際に開発フェーズに入った案件は、開発やデザイナーと自席でこまめに相談しながら、密にコミュニケーションを取って進めています。

―― チームではAIをどのように活用していますか？

前提として、PdMメンバーは全員、Claude Codeを共通のツールとして使っています。なかでも私を含めたメンバーが最も活用しているのが、要求づくりです。ここでは、SDD（仕様駆動開発）の考え方、つまり実装されたコードではなく「意図・要求」を正（source of truth）に置くという発想を取り入れ、一次情報の整理から要求仕様・PRDの作成までをAIと進めています。議事録や分析の初稿もAIに任せています。

これによって、私たちPdMの働き方は「作業する人」から「判断する人」へ大きく変わりました。正直に言うと、以前は「AIに修正指示を出している自分の手が、一番の渋滞ポイント」になっていた時期もあります。いまは初稿づくりをAIに任せ、私たちは方向性や設計を決める判断に専念できるようになりました。

ただ、活用するうえで大事にしている考え方があります。個人の作業が部分的に速くなることと、プロダクトが世に出てお客様に価値が届くスピードが上がることは、別物だということです。だからAIを「個人の時短ツール」で終わらせず、短縮できた時間をどこに投資するかを重視しています。私はその時間を、一次情報の取得・課題の見極め・最終的な判断に振り向けています。

そのために、ツールを足すだけでなく、今ある業務フローそのものを変えていくことも、開発やPMMなど関連する組織と相談しながら実行しています。切り口はいくつかあって、たとえば要求づくりから開発への受け渡し方を見直したり、誰か一人が見つけた工夫をチームで使える共通の型にして広げたり、といった取り組みです。これはお客様の業務でDXが進むかどうかと同じで、ツールではなく業務のやり方を変えられるかが分かれ目だと感じています。

方針として大切にしているのは、「全自動化」をうたうのではなく、AIが担える"自動化の領域"を着実に広げていくという誠実なスタンスです。

―― 事業へのかかわり方、ビジネスとの接点を教えてください。

私たちは顧客課題を「肌感」ではなく構造で把握します。失注・解約の主因をMRR換算でランキング化して開発計画に接続し、商談インタビューで業務フローを図に起こし、案件DB（数百件規模）を分析してニーズと競合の出現頻度まで定量化する。一次情報を自分たちの手で取りに行くのが基本姿勢です。

意思決定への関与も深く、最近はGTM（市場投入）の領域にまで踏み込むようになっています。たとえばチームのあるメンバーは、商談に同席してお客様の業務内容をヒアリングし、新しい機能がそのお客様の想定する運用にきちんと適応することをデモで説明して、商談を後押ししています。実際に機能を売り込むところまで関わるのです。

単に「機能が売れるか」だけでなく、「どういうお客様に刺さるのか」というGTMの問いに、PdM側から積極的に越境していく。効率と効果の両方を見いだせるなら、組織の境界にこだわらず動く、というのが私たちのスタイルです。

もちろん、踏み込むからこそ事業判断もシビアに行います。撤退ラインを事業責任者と明示的に握ったり、インフラなどの原価がどれくらいかかるかからROIをきちんと算出して事業責任者とすり合わせたりします。そうやって、「作る／作らない」「続ける／やめる」を数字で語れる状態をつくっています。

―― チームの雰囲気を教えてください。

正直に言うと、私たちのチームの雰囲気は少し説明が難しいです。というのも、全員で1つのものを作る、という形のチームではないからです。メンバーはそれぞれ別のプロダクトを担当していて、日々の仕事の中身は一人ひとり違います。

では一人ひとりがバラバラかというと、まったく逆です。担当が違うからこそ、お互いの持っている情報や学びが自然に行き交うのが、このチームらしさだと思っています。

たとえば、あるメンバーはインタビューや商談でお客様について分かったことを、自席でふっと話してくれます。それを聞いているだけで、いま現場で何が起きているのかが分かりますし、「そんなところまで考えて行動しているのか」と、こちらの学びにもなります。担当プロダクトは違っても、お客様に向き合う姿勢は地続きなので、聞いていて純粋に面白いのです。

雑談も、自己研鑽にまつわる話が本当に多いです。「この書籍よかったよ」「この記事もう読んだ？」といった会話が、日常的に飛び交っています。それぞれが自分で学び続けていて、その学びを惜しみなく共有し合う。誰かに言われてやるのではなく、自然とそうなっている。この空気感は、私が個人的にもとても気に入っているところです。

―― チームで感じられるやりがいを教えてください。

最大のやりがいは、自分の関わったことが「製品の成長」として返ってくる実感を、定量・定性の両面で語れることだと思っています。

私たちのチームは、PdMが上流の課題定義から開発、リリース後の検証までの責任と情報をひとつながりで持てるように設計しています。ここが分断されると、PdMの仕事はどうしても「調整と吸収」に寄ってしまい、貢献の実感が薄くなる。そうならないよう、一次情報を自分で取りに行ける環境を整えています。

たとえばあるディスカバリーでは、複数社にヒアリングした結果ニーズがないと分かり、「これは作らない方がいい」と方向性を定めたことがあります。逆に、お客様の声から次のリリース機能を起案して形にしたこともあります。とはいえ、PdMがすべてを独断で決めるわけではありません。事業の方針を含めた大きな戦略の方向性は、事業責任者と話し合い、認識をすり合わせながら決めます。一方で、具体的なプロダクトに関わる戦術は、PdMがリードして決めていく。この役割分担そのものが、私は大きなやりがいだと感じています。

しかも、それを国内でも数少ない規模に成長したクラウドサービス群の中で担えます。緊張の連続ではありますが、こうした環境が合う方にとっては、他では得がたいやりがいと成長実感のある場所だと思います。

そしてもう一つ、強く実感したやりがいがあります。それは、それぞれの専門職と協働して物事が動き始めたとき、組織はとんでもなく大きな力を発揮するということです。

どれだけディスカバリーを重ねて的を外していない機能を作ったとしても、それだけではお客様には届きません。営業が商談で紹介してくれて、はじめてお客様の手元に届く。BtoBのサービスでは、これが本当に顕著です。

以前、まったく売れていなかったオプション機能を、PMMとPdMで協力して目標値まで届けたことがあります。PMMが営業に、一度ではなく、定着するまで何度も何度も説明を重ね、説明と仕組みの両方で売れる状態をつくってくれました。そのとき、「作るだけでなく、"届ける"とはこういうことなのか」と腹落ちしました。1つの目標値の裏には、たくさんの人の協力と、そこにつながるまでの数えきれないアクションがある。それを組織の力で実現すると、こんなにも莫大な効果が出るのか。一人では決して得られない手応えでした。

―― マネジメントにおいて重視されていることを教えてください。

私のマネジメントは、ひと言でいうと「設計するマネジメント」だと思っています。人を直接動かそうとするのではなく、人が自分で動ける構造を先に設計して、それを本人にきちんと開示する。これが、私のやり方の芯にあります。

たとえば評価でも、私の基準はシンプルで、「そのアウトプットを、自信を持ってステークホルダーの前に出せるか」の一点です。そして、この基準を後出しにせず、最初に本人へ開示します。評価は「認められたからお願いする場」ではなく、「現在地を確認する場」だと考えているからです。

その上で大事にしているのが、答えを渡すのではなく、ギャップを"自分で見える形"にして返すことです。出せないアウトプットには、良し悪しだけを言うのではなく、「この要求定義だと、ステークホルダーからこういう質問が来てここで詰まる」と、なぜ出せないのかを具体的に言語化して返します。伴走はしますが、答えは出さない。本人が自分とのギャップを自分で確かめられるようにするためです。

もう一つの軸が、お互いの役割をはっきりさせることです。私自身が抱え込まないし、メンバーにも抱え込ませない。施策も「個人ではなく組織の資産」として、担当が変わっても続く状態を作ることを意識しています。一人でできることには限界がある。その実感こそが、私がマネジメントに向かった原点でもあります。

顧客志向も、同じ発想で根付かせます。号令をかけるのではなく、「一次情報を自ら獲得し、課題を言語化する」ことを目指す状態として掲げ、各メンバーの顧客ヒアリングやVoC起点の改善を具体的な行動として記録・評価する仕組みにしています。そしてそのすべての根っこで見ているのは、業務を「ジョブだからやらなきゃいけない」という義務でこなすのではなく、内発的な動機で顧客に向き合えるか。そこを引き出すことが、私のマネジメントの役割だと思っています。

―― 活躍できる方の人物像を教えてください。

ひと言でいえば、「なぜ（Why）」と「何を（What）」にこだわることができる方です。

スキル面では、相手の関心とリテラシーに合わせて伝えられるコミュニケーション、物事を構造化して捉える思考力、そして当事者意識を持って前に進める力。このあたりを持っている方は、すぐに力を発揮できる環境だと思います。

それ以上に大事にしたいマインドセットは、一次情報を自分の足で取りに行けること。与えられた情報を待つのではなく、「お客様の本当の課題は何か」を自分であぶり出しにいける方です。

そして、私が一緒に難題を解きたいと心から思うのは、こういう経験を痛みとして放置しなかった方です。「仕様通りに作ったのに、誰にも使われなかった」「エンジニアとビジネスの間で何度もすり減った」「顧客の声が、どこにも届いていないと感じた」といった違和感を見過ごさず、「もっと良くできるはずだ」と踏みとどまれる人。AIが初稿を作ってくれる時代だからこそ、AIには代替できない"人の判断"に向き合いたい方と、ぜひご一緒したいです。

―― 入社後に一緒に取り組みたい課題を教えてください。

前提として、私たちのプロダクトは長く使われていて「もう完成しているのでは？」と見られがちです。でも、毎日向き合っている側からすると、「機能が揃っている」ことと「お客様の真のジョブが解けている」ことは、まったく別の話です。解けていないペインは、まだ山ほど残っています。

そのうえで、いま私たちのPdM組織で「働きの厚み」が足りていない領域が、はっきり3つあります。これが、入社された方と一緒に取り組みたい課題そのものです。

1つ目は、AI時代の業務変革です。AIで個人の生産性を上げるだけでは限界があり、業務フロー自体をAI活用前提に作り変える必要があります。お客様の業務を解像度高く理解する力と、AI活用の事業価値・コストを見極める力、そしてそれらを矛盾なく結ぶ力を兼ね備えた取り組みを強化したい領域です。

2つ目は、複数プロダクトを横断する統合です。単体で機能を作るフェーズから、楽楽明細・楽楽電子保存・楽楽債権管理のように複数プロダクトを跨いでお客様に価値を届けるフェーズへ、組織は移りつつあります。各プロダクトのフェーズが違い、担当も分かれているので、放っておいては連携が起きません。お客様から見た「価値の流れ」と、組織から見た「機能の境界」のズレを埋める働きが必要です。

3つ目は、判断基準を組織に残す「継承」です。経験豊富なPdMの判断プロセスが本人の頭の中に留まっていて、組織の資産になっていない。最近その共有を試したのですが、「人」を起点にした設計には限界があると分かりました。ここから先は、「人」ではなく「判断基準」そのものを引き出して残す仕組みへ移していきたいと考えています。

新しく入っていただく方には、ぜひこの3つ、つまりお客様の業務と課題を深掘りする働き・複数プロダクトの文脈を統合する働き・判断基準を継承する働きの、いずれかの働きを担ってほしいと思っています。

大事なのは経験年数や肩書きではなく、組織の中でどの「働き」を発揮できるかです。長く使われるプロダクトであり続けるには、機能を作る人だけでなく、軸を深掘りする人・文脈を統合する人・判断基準を継承する人が必要だからです。

ラクスのプロダクトは、まだ未完成です。だからこそ、この"未完成"に面白さを感じてくださる方と、一緒に取り組みたいと思っています。