【元ヤフーCTO 明石氏 × ユアマイスター VPoP × VPoE 対談】日本有数のCTOから見たユアマイスターとプロダクト

先日、”YOURMYSTAR ENGINEER SPECIAL TALK”の第1弾として「【元ヤフーCTO 明石氏 × ユアマイスター開発責任者 星】日本有数のCTOが語るエンジニアのキャリアとは / https://www.wantedly.com/companies/yourmystar/post_articles/341148 をリリース。

これに続く第2弾として、ユアマイスターのプロダクト内製化の始まりから全てをご存知の明石さんに、ユアマイスターの事業やプロダクトの面白さ、難しさ、そしてプラットフォームをつくるエンジニアとして求められることをインタビューしました。

元ヤフーCTOが思うユアマイスターの魅力

ーーまずは、明石さんとユアマイスターの出会いについて教えてください。

2017年の頭ぐらいでしょうか。2年ほど携わっていたフリークアウトのCTO業務も落ち着き、世の中の情報をキャッチアップしたく情報収集のためにビジネスマッチングアプリを使っていました。そこで代表の星野さんと出会ったのがきっかけです。リリース間もないビジネスマッチングアプリだったため、「そのアプリを利用している星野さんは、ビジネスやITの感度が高い人なんだな」と思って興味を抱き、会って話すことになりました。

星野さんと何度かやり取りする中で、「システム開発を業務委託から内製に切り替えるためにどうしたら良いか」という相談を受けました。ユアマイスター内のエンジニア組織は全く0の状態だったので、「キーになる人物をまずは探すと良い」とアドバイスしたらすぐに、開発責任者が決まったと連絡を受けました。それが星さんでしたね。雨の日にオフィス近くの喫茶店で、ガチガチに緊張した星さんと初めてお会いしました（笑）。

ーーユアマイスターの技術顧問に興味を持たれた理由を教えてください。

ユアマイスターのビジネスが、自分では「取り組もう」と思わない領域だったからです。「エアコンクリーニングなどの領域の職人とのマッチングというかなり泥臭いことをやってるな」というのが正直な感想でしたが、そこに面白さを感じ、そして「こういった企業はどのように成長していくのだろうか」と興味を持ったので、技術顧問の依頼を受けました。

ーー明石さんが取り組まない領域というのは、具体的にどのような点についてそう思われたのでしょうか。

個人事業主の多いパートナーを集める必要のあるマーケットづくり、特にハウスクリーニングやリペアなどの訪問や集配の必要な特定セグメントでのサービスの立ち上げはオペレーションの観点で非常に複雑であり、難易度が高いからです。実作業が伴うためITだけでは解決できない部分も多い領域でもあります。

また、パートナーの方々は、業務や経営において自分なりのやり方を確立しており、自負もある。さらに、業務は手帳と自動車、作業道具、電話、これさえあればできるため、ITからかけ離れた環境にある人たちは多い。そのようなアナログ最適の環境に置かれたマーケットを如何にDX化するのか。どのようなアプローチをしていくのか好奇心が湧きました。

技術顧問の第二フェーズの始まり

ーーユアマイスターの技術顧問として参画されてから今までどのように関わってくださっているのでしょうか。

初めて星野さんと出会ってからは、時々連絡をもらって相談に乗ってはいましたが顧問は気軽に請けないと決めていました。理由は、大抵の企業は課題解消のための提案をしても実行できる体制がなく、十分な効果を生み出すことが出来ないからです。そのため、私が課題解決の提案をした際に、継続的に実行に関われる課題と実行環境があると判断した場合のみ技術顧問を請け負っていました。

ユアマイスターは星野さんはじめ実行力の高い組織だったこともあり、顧問をお受けすることにしたのですが、例に漏れず、当初はなかなか形になりませんでした。その時点では、プロダクトに関わる人も技術も不足していたからです。当時の状況でいうと、定期的にMTGを行い、取り組んで欲しい課題を提示するのですが、なかなか進捗しない。そして、徐々にエンジニアの採用が進んでくると社内のメンバーで上手くいっている感覚が芽生えてくると、私とのMTGの間隔が空くようになり、気付けば難しい問題にぶつかった時にだけ相談をもらうような関わり方になっていました。ただ、それ自体は悪いことではなく、順調に成長していく際の一つの形だと思っていましたので、側面支援という形で関わろうと決めていました。

ところが、2020年の夏に改めて星野さんに呼ばれ、お会いした際に「IPOを目指すために、強いプロダクトチームにしたい。その未来を一緒に実現したい」と熱く語っていただきました。その期待を受けて、ユアマイスターとの関わり方をハンズオン型に変更し、目指す世界の実現を近づけるための開発を進められるような方針提案と私のこれまで蓄積したサービスづくりの知見も反映しながら3か年のプロダクトロードマップを星さんはじめリーダー陣と一緒に作成し、再始動しました。

ユアマイスターが作るのはパートナーと一緒に成長していくプロダクト

ーー技術顧問第二フェーズをスタートさせて、ユアマイスターのビジネスモデルの面白さに触れてくださいましたが、プロダクトの面白さはどのような点にありますか？

ITリテラシーの高くない業界で、「パートナーの方々にどのようにITの効率性を体感してもらい、事業者の皆様のリテラシーをあげていくか」のストーリーづくりが非常に面白いと思っています。

ーー僕らから見れば「それは課題だ」と思うようなことも、あまりにアナログ最適されているばかりに、事業者様が「課題だ」と認識していないケースも多々ありますよね。

今、ユアマイスターが取り組んでいることは、シンプルなんです。パートナーの方々がITツールを使わなくても不便なく業務ができている中で、押し付けられている感覚をいかに作らずにDXを実現していくか。

私たちは、サイトに登録してくださった職人の方々をパートナーさんと呼んでいるのですが、そのパートナーさんだけが成長するのではありません。ユアマイスターの事業もプロダクトもともに成長していきます。パートナーさんがDXによって業務効率の改善に効果を感じ、収益が上がり、事業が成長することで、さらにプロダクトを使いたいと思ってくれれば、ユアマイスターの事業も成長し、プロダクトに求められる機能も増えるという循環が出来上がり、関わる人皆が成長していくと思います。

つまり、彼らがITの必要性を認識し、リテラシーをあげ、事業を成長をさせていくに至るストーリーがユアマイスターのプロダクトそのものだと言えます。

ーー負がない人に負の状況を指摘するよりも、成長を実感してもらうことが重要ですね。

そもそも1日4件分の業務をしていて5件に増やそうとは思う方は少ないと思います。たとえ増やすにしても、それまでとやり方を変えなければ単に営業時間を伸ばすことに行きつく。なのでまずは、私たちが4件分と同じ時間で5件の業務を実現できる状況にすることが大切です。

ただ、パートナーさんの稼働効率の向上を可能にしたと同時に「働かされている」という感覚を抱かせてしまっては、私たちもパートナーさんもお互い幸せになれない。僕らもGoogleカレンダーを使っていて「今日のこの時間は余裕を持って動きたい」と思うことがありますよね。そう言った個人の気持ちが入る余地のあるスケジューリングができる優しさのあるプロダクトになることが良いと思っています。

ーー確かに、余裕を作れないプロダクトだと息苦しさを感じますね。

パートナーさんが手帳を使わなくなることは、1つのプロダクトの成功だと思います。手帳はタスク管理だと使いやすいですが、行動管理だと使い勝手が悪いので。

パートナーとユーザー双方への真のDXを目指す

ーーパートナーさんの生産性が上がることはパートナーさん自身にとっては十分価値があるかもしれません。しかし、「ユーザー（消費者）への提供価値に反映される」までに至らないと本当の意味でDXを推進したとは語れないと思うのですが、明石さんはどうお考えでしょうか。

プラットフォームの本質は、お金を支払って利用している人の価値が向上すること。より高い価値を得たいパートナーさんには「ユアマイスター」への利用料をいただいていますが、そもそもその利用料はパートナーさんからサービスを受けたユーザーが料金を支払うことが原資と考えられます。ですから、最終的にサービスを受けるユーザーが嫌な思いをせず、価値のあるより良い体験に反映させることができればユアマイスターでのDXと呼べると考えています。

最近、社内のカスタマーサクセスチームでは、パートナーさんの代わりにユーザーとの調整業務を全てユアマイスターが引き受けることを価値にできるのでは、という議論も上がっています。それは、「パートナーの先に居るユーザーに価値を提供する」という重要な視点に基づいているからこそ生まれる発想だと思います。

ーー具体的に他にもユアマイスターとしてどのような価値を生み出せるでしょうか。

今後は、パートナーさんに生み出せた余剰時間を、ユーザーに提供するサービスの品質向上のために使えるよう介入していくことが必要だと思っています。

例えば、従来丸1日かけて行っていた電話応対やビラ配りの時間を30分に減らせるなど、IT化によって業務効率をあげることでできた余剰時間に対して、サービスの品質についての教育の機会を作っていきたい。「ユーザーのためにもっと成長しよう」という姿勢をパートナーさんに身につけてもらえる環境をユアマイスターなら作れると思っています。

ーーユーザーのためになる余剰時間の使い方を支援するということですね。ユーザーのために頑張ろう、成長しようと思ってもらえないと、「サービス産業のDX」という実現したい世界には近づかないと思います。

「モノを直す」「何かをきれいにする」ということを職業とするパートナーさんは、もともとユーザーを喜ばせるのが好きな人間性の人たちが多いだろうと思っています。性善説として、忙しさの中でそれを忘れてしまっているかもしれないと思い、パートナーさんに思い出してもらえるように動いていくことが肝心です。

ーーそれは信頼できるパートナーさんに集まってもらうのか、パートナーさんを性善説で信頼しながらサービスを作っていくのかどちらが良いのでしょうか。

彼らがなぜそのサービスを提供しようとしているのかという原点を理解して、サポートしていくことがユアマイスターの立ち位置であるべきです。プロダクトの提供者である私たちがパートナーさんたちを指導・教育していく、という立ち位置になると誰もついてきてくれませんよね。しかし、原点回帰し、品質がよりよいユーザーへの価値提供であることを思い出し自走し始めた時の彼らは良きパートナーになると考えています。だから、私たちは「パートナーDXとは何か」をキーワードにしているんです。

ユアマイスターで磨かれるエンジニアの本質的な強さと設計論

ーーよりサービス志向を求められるように感じるのですが、他社のプロダクトと比べてユアマイスターのプロダクトに関わるエンジニアにとっての難しさはなんでしょうか？

2つの難しさがありますね。1つは自分ごとにしづらいこと。サービスや作業をいくら体験したとしてもエンジニアがパートナーさんになることはない。いかに自分ごとに置き換えられるかでプロダクトづくりの深度が変わってきます。

2つ目は、本質的な強さを求められること。本質的な強さとは汎用性のあるものを作れるということです。ユアマイスターは「プラットフォーマーになる」と言っていますが、これはものすごい難しいことです。実際、プラットフォーマーとは何か。プラットフォーム開発で重要なことは、いかにカスタマイズ性高く基本機能を作っていくかです。例えば、1年に1回変更のある要件を言われた通りに毎回作るのではなく、「その可変性」を1つの機能にしてしいく。それをできるかがプラットフォーマーになれるかどうかですね。

ーー何かのアクションに対して1対1で作るのではなく、汎用性や冗長性を持たせるんですね。

毎年同じようなものを作ることはナンセンスで、何かの機能を作ることには意味がある。作るならば色々な施策に適用できないかという前提で要件を読み込み、変更の継続性や修正可能性、汎用性まで考えて提案できてこそエンジニアと呼べると思います。プロダクトマネージャー側の久保さんが「汎用性」を保持した仕様で持ってきたら「めんどくさい」となるけど笑 エンジニア自身が発案できるならば発展性がある。

ーー確かに私からだと（笑）。そういった意味では、ビジネスを作れるエンジニアがユアマイスターには必要です。その本質的な強さをもつエンジニアは意外と多くはないと思うのですが、どうやってその力を磨けば良いのでしょうか？

基本はコンピューターサイエンスなんです。テーブル定義など詳細設計や開発するフェーズで結局は考えていることを、手前の要件定義のフェーズから考えているだけです。僕はそれを毎回考えるようにしてきたおかげで今できます。

ーープロダクトマネージャーが要件定義をしてから開発する体制だと、それを実行することは難しそうですね。より上流から入り込める環境だと、訓練できてエンジニアとして強くなれると思います。

ユアマイスターに限らず、最近のエンジニアの設計の仕方に課題を感じています。最近の設計は文章で作られていて、僕からすると、非常に読み込みづらいと感じます。ITエンジニアの本来の設計は、表とかマトリクスで多用すべきなんです。それをそのままアルゴリズムに落とせばマトリクスが内部定義になる。しかし、文章だとコードになるのでケースの網羅性など検証しずらい。

マトリクスだと自動的にプログラミング化されるし、コードの中にテーブルを書くか、DBに移管するかも考えられる。裏を返すとコード設計、ステータス設計ができればほとんどの開発はできてカスタマイズ性のある仕組みを作れるようになるんです。

ーーある種、国語と算数の違いですね。僕も仕様を言葉にするときは、論理式を前提にして思考していますね。

その感覚に近いと思います。私もどんな難しい文章もマトリクスに落とし込むようにしています。そう考えると、設計論はディフィニション。コード設計とデータ設計ができればほとんどのプロダクトは作れます。カスタマイズ性のあるシステムも十分に作れると言えるでしょう。

ーーこれは設計論ですね。この基礎がないままにモダンな開発しようとすると色々抜け落ちる。プラットフォーマーになるにも基礎がないまま作れば「っぽい」ものを作るだけになる。

エンジニアとして設計ができることは大切です。コードは数学。だからそのコードから遠い表現をしてうまく組めるわけがない。エンジニアでなくとも多くの日本人は高等教育で数学を学んでいるので、マトリクスや数式を理解できると思っています。

ーーちなみに数学を学んでいたとしても、それを必ずしも「論理」として理解していない人も多いと思うのですが、そういった人たちはどのように身に着けていったら良いでしょうか。

設計の際にどのようなものも、論理として落とし込み続けるのが良いと思います。集計のためだけではなく、表現方法としてのエクセルとしてです。マトリクスができれば、コードが変わっていっても表が重要視され、共通理解に繋がっていきます。例えば今だとノーコードが開発でも用いられ始めましたが、そもそもみんなが使っているツールはノーコードの先駆けですからね。

ーー直近、ノーコードツールのを導入した際にもその実感はありました。プラットフォームは拡張性が要求されるため、設計力が何よりも重要である。翻って言えば、「ユアマイスターは設計力の高いエンジニアが本質的に強いエンジニアに成長できる環境だ」と言えますね。

それを今、ユアマイスターの皆ができるようになろうと進めています。そうすればモダンな技術にチャレンジした時にも基礎があるので取り組みやすいです。

ーー今のユアマイスターが成長するにはどんなエンジニアが必要でしょうか？

これまでの話の流れでいくと、「正しい設計ができるエンジニア」でしょうか（笑）。

ーーPOやPdMだとどうでしょうか？

プロダクトマネージャーだと「正しい価値を提供できる人」ですね。

そして、エンジニアでもプロダクトマネージャーでも共通して言えることは、「価値」や「プロダクト」の全体感を考えられる人。エンジニアは、システム構成がこうなってるから修正方法によって影響が出ると言った全体感を持って、正しい設計ができて数字で語れることが大切。プロダクトマネージャーも全体感を持った上で、機能拡張時の機能間やデータの依存を説明できることが大切です。

現状のユアマイスターのプロダクトは単機能が多いので、それ同士が接点を持った時の全体感を考える機会が増えてくると言えます。私じゃなくても、この全体感がわかる人が上にいれば、それを見て成長するメンバーも増えて、強く成長するプロダクトを作れるチームになると思います。

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

プロダクト部MTGの風景

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

＜インタビュー後記＞

今回は明石さんに「ユアマイスターのプロダクト」をテーマにインタビューさせていただきました。

インタビューを通じて改めて感じたのは、技術的な側面は元より、経営や事業、オペレーションも踏まえて「本質的な価値とは何か？」を常に問い続けていらっしゃるということ。

明石さん自身は、ユアマイスターに関わる以前、直接サービス産業に携わったご経験はないのですが、一緒に仕事をさせていただいていると、課題のど真ん中を射貫くフィードバックを沢山いただきます。

マーケット環境、業界構造、ステークホルダーの業務環境を捉えた際に、「あるべきプロダクトの姿はどんなものか」の仮説が自然と視えてくるのだと思いますし、その前提として、明石さんの中に確固たる「原理原則」があり、それが羅針盤の様に進むべき方向を正しく指し示しているのだと思います。

我々はまだ成長途上のスタートアップであり、暗中模索の中で経営判断や意思決定を行うことも多々あります。その時に明石さんのようなプロフェッショナルがいらっしゃることで、外してはならないポイントを常に押さえながら、「安全に挑戦的な冒険が出来る」「冒険したい道筋の仮説精度を高められる」ということは本当に心強いですね。

ユアマイスターは、これからも「パートナーと共に成長するプロダクト」を形にし、サービス産業の構造変革に挑戦していきます。

一緒にこのプロダクトを創っていきたいと思われた方、明石さんのフィードバックを受けながら成長していきたいと思われた方、是非お声がけください。

ーーーーーーーーーー

ユアマイスターでは現在、エンジニア、プロダクトマネージャー、デザイナーの方、積極採用中です。