Engineering
2021.08.10
CTO漆原とテクニカルPdM談義 ―前編― BEENOSでのエンジニアリングとテクニカルPdMに必要なこと
BEENOSの掲げる「野心とテクノロジーで世界の可能性を拡げるNextスタンダードを創る」。そんな指針を支える根幹がテクノロジーサイド、エンジニアなのですが今回はCTOである漆原に主にテクニカルPdMとして必要なことや実際のエンジニアリングに求められることを伺いました。
プロダクトを創るということはどういうことなのか、プロダクトのその後とは?変化するプロダクト・ビジネスのフェーズを見つめる漆原の経験の一部を覗きます。
前編・後編でお届けします。
―今日のテーマはテクニカルPdM。改めてCTOの漆原さんに色々話を伺いたいと思っていますが、始めに当社のエンジニア組織についてもう少し分解したいと考えています。そこで、CTOとして漆原さんの仕事について教えてください。
漆原:「野心とテクノロジーで世界の可能性を拡げるNextスタンダードを創る」ことがBEENOSのPurposeですが、Purposeの中のテクノロジー全般について責任をもって遂行するというのが自分の仕事だと思っています。具体的には、BEENOSの各事業の技術的な相談、新規事業の「こんなことがやりたい」が実現可能かどうか、また、どのように実現するか、エンジニアチームの組織マネジメントなどを日々行っています。
CTOの役割をテックリードとエンジニアリングマネージャーに分けることがありますが、そもそもテックリードは技術によってエンジニア組織をけん引していくような役割で、エンジニアリングマネージャーはピープルマネジメントなどのエンジニア組織をマネージメントするのが役割になります。BEENOSでは、各開発チームがテクノロジーの中心になって開発を進めているので、私の役割はエンジニアリングマネージャー寄りですね。
―漆原さんはエンジニアとしての強みはデータモデリング寄りでしたね。
漆原:個人事業主だった頃、開発に関わることは全て行なっていましたが、特色がないとなかなか売り上げが伸ばせなかったんです。何を色にするかと考えた際に、データを扱うというのがITの根幹の部分だと思いまして。管理したいデータをコンピュータで扱えるように構造化することをデータモデリングというのですが、この部分には自分の興味もすごいありましたし、正しくデータモデリングを行うのは大変難しいことですが・・・これをエンジニアリングのライフワークとしてやっていきたいと思い選択しました。
新規事業の開発に入るときに技術選定や設計などは開発チームに一任することが多いのですが、データモデリングはいまだにチェックさせてもらうこともあります。エンジニアとしてぐっと入るのはデータモデリング領域なのかなとおもいますね。
―データモデリングは難しい、と。
漆原: ビジネス全体を対象としてデータモデリングを行うことが必要です。例えばECでモノを販売する際、仕入れから配送完了までのモノの流れに意識が集中しがちですが、売上計上までのお金の流れや返金の事実とか、そのようなことも漏れなく対象としてデータモデリングを行う必要があります。
データモデリングの際、テクニカルに重要なキーワードというのは、例えば「One Fact in One Place」とか「リソースとイベント」のようなものですが、多くはない。ですが、システムが提供するのは「情報」です。この「データ」と「情報」を適切に区別できず、情報まで管理してしまうと、データ不整合に起因するシステム不具合を発生させることになりますし、プログラムが煩雑になります。データは管理します(データモデリングします)が、情報は管理せず都度導出できるようにする必要があり、「都度導出」がシステムのパフォーマンス上無視できない場合でも、ビューや導出結果のキャッシュによって情報を取得するように、分けて考える必要があります。
妥当なデータモデルを見ると、システムのかなりのことが理解できます。ビジネスもかなり理解できますね。また、システム不具合が発生した時は、データモデルや実データの状態から、不具合を発生させている処理に辿り着きやすくなったりします。複数のシステムを同時に担う方法の一つは、各システムのデータモデルの把握にあると思います。
―BEENOSに関わってもうどれくらいになりますか?
漆原:受託開発会社を経営していた時から数えると11年目になります。当時を振り返ると、ただ言われた通りにシステムをつくるのではなくて、直井さん達の「こんなことを実現したい」を、「本当に今必要だろうか、本当にこの形なのだろうか」と、一緒になって考えてつくっていましたね。予算感もあるので「突き詰めていったらあなたたちのやりたことはこれじゃないですか?」とアプローチしながら仕事をやっていたんですね。
そして直井さんがBEENOSの代表に就任された際に意気揚々と営業を掛けてみたんです、「tenso社のサービスだけじゃなくて、他のBEENOSのサービスもやらせてください」って。 (笑) そしたら「一緒にやりませんか」と逆に声を掛けられて会社ごとジョインしました。当時からBEENOSは、野心の部分、「日本を元気にしたい」という課題に真っ直ぐシンプルに向き合っていましたが、テクノロジー部分を強化できそうだと感じて。野心を見ているテクノロジーの担い手をもっと増やしたいと感じていましたね。
野心とテクノロジーの両輪があって初めてネクストスタンダードが実現できます。そう考えると事業側・野心側をしっかりと見ているテクノロジーの担い手が必要だと感じて。でも、私はその点には自信があったんです(笑)。受託開発で仕事を受けてもお客様の言われたことをただ作るんじゃなくて、「それ必要ですか?」と問いかけたり。お客様の言った金額よりも安く提示したこともあります。「それいらないから作らなくていいですよ」と。(笑)
―いいですね、野心とテクノロジーはくっついて初めてネクストスタンダードができる、Purposeをエンジニアとしてそういう形で分解されているのですね。
漆原:そんな風にBEENOSの中で芽生える野心をただただ「はい、わかりました」と形にしていくのではなくて、「今まさに何が必要ですか」ということを一緒に考えられる人。プロジェクトオーナーが見ているマーケット、まだ存在していないかもしれないマーケットを含めて一緒に見ることができるエンジニアが必要だと思っています。プロダクトマネージャー、今だと事業レベル・ビジネスレベルを指しますが、そこにちゃんと興味を持つ人。かつテクノロジーの担い手であるので、テクニカルなところにエッジを持ったプロダクトに責任と興味をちゃんと持っている人がとても必要です。
―今、PdMを必要としているんですよね。PdMに求めていることはありますか?
漆原:サービスのライフサイクルに一貫して興味と責任を持ってくれる人を求めます。サービスのライフサイクルをスタートアップフェーズ(0→1)とグロースフェーズ(1→10)に分けた際、どちらにも興味を持って欲しいです。
わかりやすいスタートアップ、0から1への部分は誰でもワクワクするんですよね。一方でグロース期に入ったものについては事業サイドは「新たにこんな機能を付けていくからすごいワクワクするよね」、という感じで継続的に刺激があるんですけれど、システムは日々、古くなっていくわけです。
保守開発、古いものがいまだにあるということは利益が出ているからなんです。なぜかというとそのシステムに価値があるから。年々劣化し、古くなっていくものをどう新しい状態にしていくか。サービスがそこまで成長し、エンジニアとしてその状況に直面することは案外多くないんです。
しかもスタートアップフェーズでは経験することのできない難しさです。システムリプレースは「面倒」なのではなく「難しい」ことなんですよね。グロースフェーズの開発に向き合った際の試行錯誤、失敗と成功が、エンジニアの技術を全方位的に醸成させると思います。
ただただ新しい技術を触る以外に、こういった場面で技術的な難易度だったり学びってあるんですね。プロダクトというのは作って終わりじゃなくてそこから使ってもらって価値があればずっと使い続けてもらうものなので、ライフサイクル全体を見たうえで技術負債にちゃんと対峙していこうという観点もPdMなら必要です。新しいものを一緒になって作ることだけがプロダクトマネージメントじゃなくて、存在している間もずーっと続ける、対峙していくことも大切。
求めている人材像はモノ作りが好きな人はベースで、貪欲に吸収する人、今の事業領域に共感している人、日本を元気にしたい、という想いに共感できる人。そういう人は事業サイドにナチュラルに働きかけることができます。
新しい事業を創るだけがPdMではない。ずっと続ける、この難しさに対峙するのもプロダクトマネージメントだから。スタートアップ期もグロース期もできるPdMを希望しています。BEENOSが提供するサービスのテクノロジー部分に責任を持ち遂行するのが、我々エンジニアに求められていることです。ビジネスサイドと協調して事業を推進するテクニカルPdMには殊更、サービスのライフサイクルに対する一貫した興味と責任、そして、責任を遂行するための全方位的な技術を求めます。
後編は、漆原から見た活躍するPdM、求められるPdM。BEENOSで働くPdMの多彩さやPdMの難しさと面白さについてお話しします。
プロダクトを創るということはどういうことなのか、プロダクトのその後とは?変化するプロダクト・ビジネスのフェーズを見つめる漆原の経験の一部を覗きます。
前編・後編でお届けします。
Purposeの中のテクノロジー全般について責任をもって遂行するのがエンジニアの仕事
―今日のテーマはテクニカルPdM。改めてCTOの漆原さんに色々話を伺いたいと思っていますが、始めに当社のエンジニア組織についてもう少し分解したいと考えています。そこで、CTOとして漆原さんの仕事について教えてください。
漆原:「野心とテクノロジーで世界の可能性を拡げるNextスタンダードを創る」ことがBEENOSのPurposeですが、Purposeの中のテクノロジー全般について責任をもって遂行するというのが自分の仕事だと思っています。具体的には、BEENOSの各事業の技術的な相談、新規事業の「こんなことがやりたい」が実現可能かどうか、また、どのように実現するか、エンジニアチームの組織マネジメントなどを日々行っています。
CTOの役割をテックリードとエンジニアリングマネージャーに分けることがありますが、そもそもテックリードは技術によってエンジニア組織をけん引していくような役割で、エンジニアリングマネージャーはピープルマネジメントなどのエンジニア組織をマネージメントするのが役割になります。BEENOSでは、各開発チームがテクノロジーの中心になって開発を進めているので、私の役割はエンジニアリングマネージャー寄りですね。
―漆原さんはエンジニアとしての強みはデータモデリング寄りでしたね。
漆原:個人事業主だった頃、開発に関わることは全て行なっていましたが、特色がないとなかなか売り上げが伸ばせなかったんです。何を色にするかと考えた際に、データを扱うというのがITの根幹の部分だと思いまして。管理したいデータをコンピュータで扱えるように構造化することをデータモデリングというのですが、この部分には自分の興味もすごいありましたし、正しくデータモデリングを行うのは大変難しいことですが・・・これをエンジニアリングのライフワークとしてやっていきたいと思い選択しました。
新規事業の開発に入るときに技術選定や設計などは開発チームに一任することが多いのですが、データモデリングはいまだにチェックさせてもらうこともあります。エンジニアとしてぐっと入るのはデータモデリング領域なのかなとおもいますね。
―データモデリングは難しい、と。
漆原: ビジネス全体を対象としてデータモデリングを行うことが必要です。例えばECでモノを販売する際、仕入れから配送完了までのモノの流れに意識が集中しがちですが、売上計上までのお金の流れや返金の事実とか、そのようなことも漏れなく対象としてデータモデリングを行う必要があります。
データモデリングの際、テクニカルに重要なキーワードというのは、例えば「One Fact in One Place」とか「リソースとイベント」のようなものですが、多くはない。ですが、システムが提供するのは「情報」です。この「データ」と「情報」を適切に区別できず、情報まで管理してしまうと、データ不整合に起因するシステム不具合を発生させることになりますし、プログラムが煩雑になります。データは管理します(データモデリングします)が、情報は管理せず都度導出できるようにする必要があり、「都度導出」がシステムのパフォーマンス上無視できない場合でも、ビューや導出結果のキャッシュによって情報を取得するように、分けて考える必要があります。
妥当なデータモデルを見ると、システムのかなりのことが理解できます。ビジネスもかなり理解できますね。また、システム不具合が発生した時は、データモデルや実データの状態から、不具合を発生させている処理に辿り着きやすくなったりします。複数のシステムを同時に担う方法の一つは、各システムのデータモデルの把握にあると思います。
事業側・野心側を見ているテクノロジーの担い手がすごく必要、事業責任者がみているマーケット、まだ存在していないかもしれないマーケットを含めて一緒に見る。
―BEENOSに関わってもうどれくらいになりますか?
漆原:受託開発会社を経営していた時から数えると11年目になります。当時を振り返ると、ただ言われた通りにシステムをつくるのではなくて、直井さん達の「こんなことを実現したい」を、「本当に今必要だろうか、本当にこの形なのだろうか」と、一緒になって考えてつくっていましたね。予算感もあるので「突き詰めていったらあなたたちのやりたことはこれじゃないですか?」とアプローチしながら仕事をやっていたんですね。
そして直井さんがBEENOSの代表に就任された際に意気揚々と営業を掛けてみたんです、「tenso社のサービスだけじゃなくて、他のBEENOSのサービスもやらせてください」って。 (笑) そしたら「一緒にやりませんか」と逆に声を掛けられて会社ごとジョインしました。当時からBEENOSは、野心の部分、「日本を元気にしたい」という課題に真っ直ぐシンプルに向き合っていましたが、テクノロジー部分を強化できそうだと感じて。野心を見ているテクノロジーの担い手をもっと増やしたいと感じていましたね。
野心とテクノロジーの両輪があって初めてネクストスタンダードが実現できます。そう考えると事業側・野心側をしっかりと見ているテクノロジーの担い手が必要だと感じて。でも、私はその点には自信があったんです(笑)。受託開発で仕事を受けてもお客様の言われたことをただ作るんじゃなくて、「それ必要ですか?」と問いかけたり。お客様の言った金額よりも安く提示したこともあります。「それいらないから作らなくていいですよ」と。(笑)
―いいですね、野心とテクノロジーはくっついて初めてネクストスタンダードができる、Purposeをエンジニアとしてそういう形で分解されているのですね。
漆原:そんな風にBEENOSの中で芽生える野心をただただ「はい、わかりました」と形にしていくのではなくて、「今まさに何が必要ですか」ということを一緒に考えられる人。プロジェクトオーナーが見ているマーケット、まだ存在していないかもしれないマーケットを含めて一緒に見ることができるエンジニアが必要だと思っています。プロダクトマネージャー、今だと事業レベル・ビジネスレベルを指しますが、そこにちゃんと興味を持つ人。かつテクノロジーの担い手であるので、テクニカルなところにエッジを持ったプロダクトに責任と興味をちゃんと持っている人がとても必要です。
対峙し続けることの難しさを問われる。スタートアップフェーズもグロースフェーズも対応できることがテクニカルPdMに必要
―今、PdMを必要としているんですよね。PdMに求めていることはありますか?
漆原:サービスのライフサイクルに一貫して興味と責任を持ってくれる人を求めます。サービスのライフサイクルをスタートアップフェーズ(0→1)とグロースフェーズ(1→10)に分けた際、どちらにも興味を持って欲しいです。
わかりやすいスタートアップ、0から1への部分は誰でもワクワクするんですよね。一方でグロース期に入ったものについては事業サイドは「新たにこんな機能を付けていくからすごいワクワクするよね」、という感じで継続的に刺激があるんですけれど、システムは日々、古くなっていくわけです。
保守開発、古いものがいまだにあるということは利益が出ているからなんです。なぜかというとそのシステムに価値があるから。年々劣化し、古くなっていくものをどう新しい状態にしていくか。サービスがそこまで成長し、エンジニアとしてその状況に直面することは案外多くないんです。
しかもスタートアップフェーズでは経験することのできない難しさです。システムリプレースは「面倒」なのではなく「難しい」ことなんですよね。グロースフェーズの開発に向き合った際の試行錯誤、失敗と成功が、エンジニアの技術を全方位的に醸成させると思います。
ただただ新しい技術を触る以外に、こういった場面で技術的な難易度だったり学びってあるんですね。プロダクトというのは作って終わりじゃなくてそこから使ってもらって価値があればずっと使い続けてもらうものなので、ライフサイクル全体を見たうえで技術負債にちゃんと対峙していこうという観点もPdMなら必要です。新しいものを一緒になって作ることだけがプロダクトマネージメントじゃなくて、存在している間もずーっと続ける、対峙していくことも大切。
求めている人材像はモノ作りが好きな人はベースで、貪欲に吸収する人、今の事業領域に共感している人、日本を元気にしたい、という想いに共感できる人。そういう人は事業サイドにナチュラルに働きかけることができます。
新しい事業を創るだけがPdMではない。ずっと続ける、この難しさに対峙するのもプロダクトマネージメントだから。スタートアップ期もグロース期もできるPdMを希望しています。BEENOSが提供するサービスのテクノロジー部分に責任を持ち遂行するのが、我々エンジニアに求められていることです。ビジネスサイドと協調して事業を推進するテクニカルPdMには殊更、サービスのライフサイクルに対する一貫した興味と責任、そして、責任を遂行するための全方位的な技術を求めます。
後編は、漆原から見た活躍するPdM、求められるPdM。BEENOSで働くPdMの多彩さやPdMの難しさと面白さについてお話しします。
Profile プロフィール
- BEENOS株式会社 執行役員 兼 CTO(Chief Technical Officer)
テクノロジー推進室長
漆原 明尚(うるしばら あきひさ)
- 独立系SIer、組み込み系からオープン系まで様々な開発を行う。3年3ヶ月在籍
- 個人事業主となる。持ち帰りにこだわり、オープン系やインターネット系の開発を行う。4年8ヶ月事業を営む
- VCと自身を含む複数人のFunderの資金を元にスタートアップを設立、代表取締役兼開発者。PC向けWebコンテンツをフィーチャーフォン向けWebコンテンツに変換するトランスコーディングエンジンの開発。11ヶ月経営するも、製品化も次ラウンド資金調達も実現できず会社をたたむ
- 受託開発会社を設立、代表取締役。持ち帰りにこだわった、主にインターネット関係の開発を受託。代表業以外にも各種事務作業、営業、人事、要件定義・設計・開発等の必要な事を行う。9年4ヶ月経営
- 2015年4月、上記受託開発会社を事業譲渡する形でBEENOS株式会社に入社
- 個人事業主から受託開発会社の間に、サンフランシスコ・ロサンゼルス・ニューヨーク・上海での開発実績と、ニューヨーク・大連での営業実績あり
- スタートアップ会社では産学協同と特許出願を経験
過去インタビュー:CTOに聞きました「機会や裁量権の大きい環境だからこそ、エンジニアは”プログラムオタクより課題解決オタク”であれ」