Engineering
2021.08.10
CTO漆原とテクニカルPdM談義 ―後編― 活躍するPdM、求められるPdM
CTOとしていちエンジニアとしてテクニカルPdMに求められるものをつぶさに観察する漆原。前編ではテクニカルPdMの仕事の実際について語りました。
BEENOSの独自の文化の中で醸成されるPdMとしての経験と、本人に求められていく資質をまっすぐに漆原は見つめます。技術面で全責任と裁量をもつPdMには何が必要とされるのか。どんなプロジェクトに携わるのか。PdM志願者なら気になるひとつひとつを「BEENOSの場合」どんなことができるのか、お話します。
―BEENOSでのPdMのミッションとはなんですか？
漆原：テクニカルPdMは、ビジネスの成功について技術面で全責任を持ちます。システムを構築する技術、フロントエンドやサーバーサイド、基盤などの技術は、日進月歩で変わります。早く安く作れる。そのために、息を吸うように新しい技術やサービスを吸収するナチュラルな興味がとても大切です。BEENOSには新しい技術や取り組みを取り入れる文化がありますし、機会もあります。
5年前、10年前の技術でもシステムは作れますが、新しい技術やサービスだともっと早く安く作れる可能性が高いので、プロダクトに適用していくことができます。ただし新しいものを適用しすぎて失敗してもだめじゃないですか。なので、新しいものを必ず適用するわけではないんです。その辺りのさじ加減が本当に難しい。でも逆をいうとその采配も全部自分でできるってことなんです。
BEENOSは「これで」という押しつけはありません。ですが、常に新しい技術やサービス、手法を学び、最適なコストでより早く顧客やユーザーに価値を届けることを実践し続けることが求められます。プロダクトオーナーは「何を作るか」を決定しますが、「どのように作るか」の全裁量・責任はPdMにあります。エンジニアの醍醐味だと思いますね。
―BEENOSにはどんなPdMがいるのかも気になります。
漆原：前編でPdMには「全方位的な技術を求めます」と言いましたが、「技術」は多岐に渡りますし、全て同じレベル・並列に求めているわけではありません。技術全般に興味と理解を持つことは基本。ですが、まず自身の専門性を発揮し、それ以外の部分はメンバーと協調して進めることで、結果、全方位的に責任をもって遂行できる人を求めています。
BEENOSにはいろいろなタイプの「専門性」を持つテクニカルPdMがいます。
開始当初から大規模サービスとすることを前提とした開発を担っているテクニカルPdMは、プロジェクトマネジメント能力が特に高いです。ビジネス・営業サイドや開発チーム、運用チーム、外部提携先関係者などステークホルダーが多い中で、「誰が何を担当すると効果的か」を考え進めてます。マネジメント業務の時間が圧倒的に多い中でも、サービスが提供する機能への理解だけではなく、データ構造やテストコードへの理解など、押さえるべきところをおさえてます。
中規模サービスの開発を担うPdMは、アジャイルなチーム運営を基本として、ビジネスサイドと要求分析・要件定義、システムのデザイン、開発から運用まで、自ら頭と手を動かしつつ、開発メンバーと協調してプロジェクトを進行しています。システム構築自体にエッジが立っているからできることですね。エンジニア組織の運営にも熱い想いを持っている人で、一緒に取り組んだりしています。
小さく始めてみるサービスもたくさんあります。それらを複数同時に担っているPdMは、スタートアップフェーズで特に必要となる技術全てを一人でまかなえる。それに、「それ価値がありそうですね、つくってみましょう、最初はこんな感じで」とフットワークがすごく軽いんです。インターン生が考えたことも単独サービス化することがあったりと、開発の相談が結構な頻度で発生するBEENOSなので、フットワークの軽さは重要。それに、小規模サービスの段階は、テクニカルPdMに進むための良いパイロットプロジェクトでもあります。経験の少ないエンジニアに寄り添いながら、実践を通して成長をうながす取り組みも行っています。
―ビジネス×技術のコミュニケーション体制を気にされるエンジニアが多い様です。当社は密接だと認識していますがどう感じていらっしゃいますか？
漆原：かなりの頻度でミーティングをしています。関係値はかなりイーブン、フラットだと思います。プロダクトオーナーは理想形がすごく強いじゃないですか、先ほども申し上げましたけど。こちらもそれをただ鵜呑みにして開発するんじゃなくて例えばUI・UXをユーザー体験の観点から提案したり「この機能は今いらないんじゃないですか」等、議論をフラットに続けていく。その結果サービスの仕様が決まる、という感じですね。結果的にプロダクトオーナーの決定通り作ることも多いです。ですがそれはただ作っているわけではなく、プロダクトオーナーの考えたことが妥当だよねと、チームが合意したから。
ビジネスサイドや運用サイドとの必要なミーティングは適宜行われます。さらに、開発進捗や営業進捗、直近のサービスの方向性などについても、定期的にミーティングで共有があります。
―開発環境や技術選定に制限を設けていますか？？
漆原：自由という言葉で終わってしまいそうなのですが、便利なモノや考え方、進め方はどんどん出てくるので、継続的にキャッチアップしながら、タイミングで導入してみようという裁量があります。ただ、サービス開発は趣味の場ではないため、導入の根拠やメリット（コストも含めて）、想定される影響などを、複数のメンバーで検討した上で決定しています。
―開発手法選定の基準は何でしょうか？
漆原：対象とするシステムの性質によって適宜選択しています。
一般的にシステムは、「System of Engagement（SoE）」と呼ばれる性質と「System of Record（SoR）」と呼ばれる性質に分けられます。
SoEは例えば、「使いやすいな」「ここで買ってよかった」「またここで買いたい」と思ってもらえるような、顧客やユーザーのエンゲージメントを高める体験ってなんだろう、正解がわからないし自分たちの思い込みかもしれないから実際に聞いてみよう、というようなシステムですね。この場合は、考えて・作って・リリースして・フィードバックをもらう、というループを高速に回すのが良くて、つまりアジャイルな進め方が適しています。
SoRは例えば、「経理的に正しい、お金に関するデータを管理する」「システム監査に必要なデータを管理する」のように、”あるべき”・”でなくてはいけない”ということが決まっているシステムです。この場合は、システムの機能要件を専門部署などと協調して定義し、まさにその通りになるようにシステムを構築していく、つまりウォーターフォールな進め方が適しています。
サービスはSoEとSoRのどちらかに必ず分けられるものではありません。例えばBEENOSの越境ECサービスであるBuyeeは、顧客が利用する部分はSoE要素を多く含みますが、バックオフィス系の部分は基本的にSoRです。アジャイルかウォーターフォールかという二元論ではなく、対象システムの性質に適した開発手法を選択できる必要があります。
―開発体制はどのように構築していますか？
漆原：僕は基本的に、会社が実現したいこととメンバーそれぞれがやりたいこと、それぞれをテーブルに並べた時に、可能な限り双方満足する状態を実現したい。だから日ごろから定期的に会話を行い、担当業務を決定しています。僕やマネージャー、リーダーから「これをお願いしたい。これを担当してみたらどうですか」という話をすることも、メンバーから「これがやりたい」と話があることもあります。ですが、基本的にメンバーの意見を採用します。もちろん、メンバーが担当している内容によって移行期間は異なりますが。
開発量や開発スピード、品質を担保するために、社外のメンバーにもご協力いただいています。国内外の開発会社さんや副業エンジニアの方など、私だけではなくマネージャーやリーダー自らが、新しい関係をつなげてきてトライしています。エンジニアインターンにも、基本的に実サービスの開発に携わってもらっているのも特徴的かもしれません。有意義だと思ってます。
―BEENOSでPdMとして働いたら、どんなプロジェクトを担当できますか？
漆原：既存事業のいずれか、もしくは新規事業ですね。タイミングによりますが、基本的にそれぞれの方の志向にお任せしています。私から断定的に指定したことはおそらくないですね。この人にこれが合うだろうなと思ったことを相談しますが、やるやらないの決定は基本的に各人にお任せしています。ちなみに、何度も言ったように、各所からの相談が多いので、「やるためにどうやって分担しようか、どうしたら体制組めるかな」とみんなで頭を悩ましていることも多々あります（笑）
―実際BEENOSでPdMとして働く場合、まず認識すべきことは何ですか？
漆原：グローバルコマースやバリューサイクル、エンターテインメントといった単一ドメインの理解だけではなく、BEENOSが提供している事業ポートフォリオを活用して、新たなサービスやマーケットを生み出せることを意識する必要があります。
例えば2021.06.14に、ブランディアが天猫国際（Tmall Global）に正式出店したプレスリリースを出していますが、これはバリューサイクルとグローバルコマースの掛け合わせです。また、Groobeeというサービスは、Buyeeと連携することで、海外ファンまでグローバルに日本のエンターテインメントを届けられます。これも、エンターテインメントとグローバルコマースの掛け合わせです。
BEENOSの事業ポートフォリオを活用した新たなサービスやマーケットは、今後も次々と考えられ、生み出されます。流れをさらに加速させるために、PdMは、自身が担当するサービスの開発だけでなく、BEENOSの各サービスの内容やシステム構成、システムの置かれている状況などを継続して理解しておく必要があります。
―面白いですね、確かに今、サービスの連携により新しい世界がどんどん生まれています。こんな世界が作り出せそう、というのをエンジニアでも思考しているのですね。案外このマインドは独特のカルチャーなのかもしれません。エンジニアチームはどうやってキャッチアップしていってるんですか？
漆原：まずは自分が担当しているサービスが提供している価値の理解からです。これは各所でかなりできていて、新規事業を開発するときや既存事業に機能を追加したりするときに、「なぜこれをやるのか。やった結果生じる効果は」ということの説明と理解を定常的に行います。新しくプロジェクトに参画したメンバーがいる時は、時にはプロダクトオーナーにも参加してもらいます。
一方、担当するサービスを越えた詳細な状況理解は、現在はテクノロジー推進室のリーダー陣で行っていることなのですが、これをBEENOSエンジニア全体に拡げようとしています。プレスリリースで発表させていただいた通り、BEENOSは越境EC流通総額No.1ですから、まずはグローバルコマースの状況理解を全エンジニアが継続的に行える状況作りを目指しています。
―これからのエンジニア組織で漆原さんは何を実現していきたいですか？
漆原：越境EC流通総額でNo.1になりました。バリューコマースでもエンターテインメントでもNo.1を獲りたいです。そしてそれらを当たり前にし、世の中のNextスタンダードを創りたい。BEENOSには考え方、企画力、システム構築・運用力、サービスの運用、それぞれに実績・ノウハウがあります。だから必ず創れると考えています。
Nextスタンダードを創るという野心と、それを実現するためのテクノロジーの担い手になるという野心、両方の野心をエンジニア組織で実現していきたいです。
―ありがとうございました。
BEENOSの独自の文化の中で醸成されるPdMとしての経験と、本人に求められていく資質をまっすぐに漆原は見つめます。技術面で全責任と裁量をもつPdMには何が必要とされるのか。どんなプロジェクトに携わるのか。PdM志願者なら気になるひとつひとつを「BEENOSの場合」どんなことができるのか、お話します。
BEENOSは押し付けがない。技術分野に全責任を持ち、裁量・責任を持つのがBEENOSのテクニカルPdMの醍醐味
―BEENOSでのPdMのミッションとはなんですか？
漆原：テクニカルPdMは、ビジネスの成功について技術面で全責任を持ちます。システムを構築する技術、フロントエンドやサーバーサイド、基盤などの技術は、日進月歩で変わります。早く安く作れる。そのために、息を吸うように新しい技術やサービスを吸収するナチュラルな興味がとても大切です。BEENOSには新しい技術や取り組みを取り入れる文化がありますし、機会もあります。
5年前、10年前の技術でもシステムは作れますが、新しい技術やサービスだともっと早く安く作れる可能性が高いので、プロダクトに適用していくことができます。ただし新しいものを適用しすぎて失敗してもだめじゃないですか。なので、新しいものを必ず適用するわけではないんです。その辺りのさじ加減が本当に難しい。でも逆をいうとその采配も全部自分でできるってことなんです。
BEENOSは「これで」という押しつけはありません。ですが、常に新しい技術やサービス、手法を学び、最適なコストでより早く顧客やユーザーに価値を届けることを実践し続けることが求められます。プロダクトオーナーは「何を作るか」を決定しますが、「どのように作るか」の全裁量・責任はPdMにあります。エンジニアの醍醐味だと思いますね。
―BEENOSにはどんなPdMがいるのかも気になります。
漆原：前編でPdMには「全方位的な技術を求めます」と言いましたが、「技術」は多岐に渡りますし、全て同じレベル・並列に求めているわけではありません。技術全般に興味と理解を持つことは基本。ですが、まず自身の専門性を発揮し、それ以外の部分はメンバーと協調して進めることで、結果、全方位的に責任をもって遂行できる人を求めています。
BEENOSにはいろいろなタイプの「専門性」を持つテクニカルPdMがいます。
開始当初から大規模サービスとすることを前提とした開発を担っているテクニカルPdMは、プロジェクトマネジメント能力が特に高いです。ビジネス・営業サイドや開発チーム、運用チーム、外部提携先関係者などステークホルダーが多い中で、「誰が何を担当すると効果的か」を考え進めてます。マネジメント業務の時間が圧倒的に多い中でも、サービスが提供する機能への理解だけではなく、データ構造やテストコードへの理解など、押さえるべきところをおさえてます。
中規模サービスの開発を担うPdMは、アジャイルなチーム運営を基本として、ビジネスサイドと要求分析・要件定義、システムのデザイン、開発から運用まで、自ら頭と手を動かしつつ、開発メンバーと協調してプロジェクトを進行しています。システム構築自体にエッジが立っているからできることですね。エンジニア組織の運営にも熱い想いを持っている人で、一緒に取り組んだりしています。
小さく始めてみるサービスもたくさんあります。それらを複数同時に担っているPdMは、スタートアップフェーズで特に必要となる技術全てを一人でまかなえる。それに、「それ価値がありそうですね、つくってみましょう、最初はこんな感じで」とフットワークがすごく軽いんです。インターン生が考えたことも単独サービス化することがあったりと、開発の相談が結構な頻度で発生するBEENOSなので、フットワークの軽さは重要。それに、小規模サービスの段階は、テクニカルPdMに進むための良いパイロットプロジェクトでもあります。経験の少ないエンジニアに寄り添いながら、実践を通して成長をうながす取り組みも行っています。
―ビジネス×技術のコミュニケーション体制を気にされるエンジニアが多い様です。当社は密接だと認識していますがどう感じていらっしゃいますか？
漆原：かなりの頻度でミーティングをしています。関係値はかなりイーブン、フラットだと思います。プロダクトオーナーは理想形がすごく強いじゃないですか、先ほども申し上げましたけど。こちらもそれをただ鵜呑みにして開発するんじゃなくて例えばUI・UXをユーザー体験の観点から提案したり「この機能は今いらないんじゃないですか」等、議論をフラットに続けていく。その結果サービスの仕様が決まる、という感じですね。結果的にプロダクトオーナーの決定通り作ることも多いです。ですがそれはただ作っているわけではなく、プロダクトオーナーの考えたことが妥当だよねと、チームが合意したから。
ビジネスサイドや運用サイドとの必要なミーティングは適宜行われます。さらに、開発進捗や営業進捗、直近のサービスの方向性などについても、定期的にミーティングで共有があります。
―開発環境や技術選定に制限を設けていますか？？
漆原：自由という言葉で終わってしまいそうなのですが、便利なモノや考え方、進め方はどんどん出てくるので、継続的にキャッチアップしながら、タイミングで導入してみようという裁量があります。ただ、サービス開発は趣味の場ではないため、導入の根拠やメリット（コストも含めて）、想定される影響などを、複数のメンバーで検討した上で決定しています。
―開発手法選定の基準は何でしょうか？
漆原：対象とするシステムの性質によって適宜選択しています。
一般的にシステムは、「System of Engagement（SoE）」と呼ばれる性質と「System of Record（SoR）」と呼ばれる性質に分けられます。
SoEは例えば、「使いやすいな」「ここで買ってよかった」「またここで買いたい」と思ってもらえるような、顧客やユーザーのエンゲージメントを高める体験ってなんだろう、正解がわからないし自分たちの思い込みかもしれないから実際に聞いてみよう、というようなシステムですね。この場合は、考えて・作って・リリースして・フィードバックをもらう、というループを高速に回すのが良くて、つまりアジャイルな進め方が適しています。
SoRは例えば、「経理的に正しい、お金に関するデータを管理する」「システム監査に必要なデータを管理する」のように、”あるべき”・”でなくてはいけない”ということが決まっているシステムです。この場合は、システムの機能要件を専門部署などと協調して定義し、まさにその通りになるようにシステムを構築していく、つまりウォーターフォールな進め方が適しています。
サービスはSoEとSoRのどちらかに必ず分けられるものではありません。例えばBEENOSの越境ECサービスであるBuyeeは、顧客が利用する部分はSoE要素を多く含みますが、バックオフィス系の部分は基本的にSoRです。アジャイルかウォーターフォールかという二元論ではなく、対象システムの性質に適した開発手法を選択できる必要があります。
―開発体制はどのように構築していますか？
漆原：僕は基本的に、会社が実現したいこととメンバーそれぞれがやりたいこと、それぞれをテーブルに並べた時に、可能な限り双方満足する状態を実現したい。だから日ごろから定期的に会話を行い、担当業務を決定しています。僕やマネージャー、リーダーから「これをお願いしたい。これを担当してみたらどうですか」という話をすることも、メンバーから「これがやりたい」と話があることもあります。ですが、基本的にメンバーの意見を採用します。もちろん、メンバーが担当している内容によって移行期間は異なりますが。
開発量や開発スピード、品質を担保するために、社外のメンバーにもご協力いただいています。国内外の開発会社さんや副業エンジニアの方など、私だけではなくマネージャーやリーダー自らが、新しい関係をつなげてきてトライしています。エンジニアインターンにも、基本的に実サービスの開発に携わってもらっているのも特徴的かもしれません。有意義だと思ってます。
―BEENOSでPdMとして働いたら、どんなプロジェクトを担当できますか？
漆原：既存事業のいずれか、もしくは新規事業ですね。タイミングによりますが、基本的にそれぞれの方の志向にお任せしています。私から断定的に指定したことはおそらくないですね。この人にこれが合うだろうなと思ったことを相談しますが、やるやらないの決定は基本的に各人にお任せしています。ちなみに、何度も言ったように、各所からの相談が多いので、「やるためにどうやって分担しようか、どうしたら体制組めるかな」とみんなで頭を悩ましていることも多々あります（笑）
単一ドメインの理解だけではなくBEENOSが持っている事業ポートフォリオを活用した新たな領域・マーケットの実現までエンジニアも思考する
―実際BEENOSでPdMとして働く場合、まず認識すべきことは何ですか？
漆原：グローバルコマースやバリューサイクル、エンターテインメントといった単一ドメインの理解だけではなく、BEENOSが提供している事業ポートフォリオを活用して、新たなサービスやマーケットを生み出せることを意識する必要があります。
例えば2021.06.14に、ブランディアが天猫国際（Tmall Global）に正式出店したプレスリリースを出していますが、これはバリューサイクルとグローバルコマースの掛け合わせです。また、Groobeeというサービスは、Buyeeと連携することで、海外ファンまでグローバルに日本のエンターテインメントを届けられます。これも、エンターテインメントとグローバルコマースの掛け合わせです。
BEENOSの事業ポートフォリオを活用した新たなサービスやマーケットは、今後も次々と考えられ、生み出されます。流れをさらに加速させるために、PdMは、自身が担当するサービスの開発だけでなく、BEENOSの各サービスの内容やシステム構成、システムの置かれている状況などを継続して理解しておく必要があります。
―面白いですね、確かに今、サービスの連携により新しい世界がどんどん生まれています。こんな世界が作り出せそう、というのをエンジニアでも思考しているのですね。案外このマインドは独特のカルチャーなのかもしれません。エンジニアチームはどうやってキャッチアップしていってるんですか？
漆原：まずは自分が担当しているサービスが提供している価値の理解からです。これは各所でかなりできていて、新規事業を開発するときや既存事業に機能を追加したりするときに、「なぜこれをやるのか。やった結果生じる効果は」ということの説明と理解を定常的に行います。新しくプロジェクトに参画したメンバーがいる時は、時にはプロダクトオーナーにも参加してもらいます。
一方、担当するサービスを越えた詳細な状況理解は、現在はテクノロジー推進室のリーダー陣で行っていることなのですが、これをBEENOSエンジニア全体に拡げようとしています。プレスリリースで発表させていただいた通り、BEENOSは越境EC流通総額No.1ですから、まずはグローバルコマースの状況理解を全エンジニアが継続的に行える状況作りを目指しています。
―これからのエンジニア組織で漆原さんは何を実現していきたいですか？
漆原：越境EC流通総額でNo.1になりました。バリューコマースでもエンターテインメントでもNo.1を獲りたいです。そしてそれらを当たり前にし、世の中のNextスタンダードを創りたい。BEENOSには考え方、企画力、システム構築・運用力、サービスの運用、それぞれに実績・ノウハウがあります。だから必ず創れると考えています。
Nextスタンダードを創るという野心と、それを実現するためのテクノロジーの担い手になるという野心、両方の野心をエンジニア組織で実現していきたいです。
―ありがとうございました。
Profile プロフィール
- BEENOS株式会社 執行役員 兼 CTO(Chief Technical Officer)
テクノロジー推進室長
漆原 明尚（うるしばら あきひさ）
- 独立系SIer、組み込み系からオープン系まで様々な開発を行う。3年3ヶ月在籍
- 個人事業主となる。持ち帰りにこだわり、オープン系やインターネット系の開発を行う。4年8ヶ月事業を営む
- VCと自身を含む複数人のFunderの資金を元にスタートアップを設立、代表取締役兼開発者。PC向けWebコンテンツをフィーチャーフォン向けWebコンテンツに変換するトランスコーディングエンジンの開発。11ヶ月経営するも、製品化も次ラウンド資金調達も実現できず会社をたたむ
- 受託開発会社を設立、代表取締役。持ち帰りにこだわった、主にインターネット関係の開発を受託。代表業以外にも各種事務作業、営業、人事、要件定義・設計・開発等の必要な事を行う。9年4ヶ月経営
- 2015年4月、上記受託開発会社を事業譲渡する形でBEENOS株式会社に入社
- 個人事業主から受託開発会社の間に、サンフランシスコ・ロサンゼルス・ニューヨーク・上海での開発実績と、ニューヨーク・大連での営業実績あり
- スタートアップ会社では産学協同と特許出願を経験
過去インタビュー：CTOに聞きました「機会や裁量権の大きい環境だからこそ、エンジニアは”プログラムオタクより課題解決オタク”であれ」
