工藤hacomonoでCTOを務めている工藤と申します。受託開発やBtoBプロダクトをつくる会社で10年ほどエンジニアとして働いたのち、サイバーエージェントでソーシャルゲームの開発を経験しました。

その後、2015年に現在のhacomono（当時の社名：まちいろ）に入社し、創業代表の蓮田と共に受託開発をしながらプロダクトをつくっていました。2019年以降は、ローンチした自社サービス『hacomono』を中心とした事業を展開する会社になりました。現在10期目と意外と歴史が長い会社になります。

『hacomono』は会員管理・予約・決済の3つをコアドメインとするウェルネス領域の店舗に利用していただくSaaSです。ターゲットは幅広く、お客様が店舗に行く前に行う予約や決済といった操作だけではなく、チェックイン・チェックアウト、契約管理など、店舗現場で発生しているさまざまなオペレーションを、機能として包括的に提供しています。

現在の導入店舗数は3,000以上。フィットネス領域が多いと思われがちですが、駅前などにあるようなインドアゴルフ店舗やエステ、そして公共施設にも導入が広がっています。

また、さらに領域を横に広げていこうとしていまして、たとえばスクール向けに新たなプロダクトをつくり、さらなるグロースを実現しようとがんばっているところです。

現状はシリーズCで38.5億円の資金調達が完了したところで、これからミドル～レイターといわれるステージに向かっていくフェーズになります。

工藤我々はビジョンを5つぐらいに分けて説明しているのですが、まだまだウェルネス店舗、DXというフェーズ1だと思っています。ここからフェーズ2、3と進んでいきたいところです。

戦略については、「ホールプロダクト（Whole Product）」と呼んでいて、さまざまなテーマに対して優先順位を付けながらやっているという感じですね。

工藤フェーズ2のテーマで1つご紹介すると、FinTech、いわゆる決済領域がやはりテーマになってくるなというところです。月会費の支払いやスタッフへの給与の支払いなどを滑らかにしていく事業領域が次のテーマになると考えています。

我々は“インフラ”という言葉をあえて使っていまして、ウェルネスを支えるインフラになっていくフェーズに入ってきていることを示そうと、シリーズC調達時のメインビジュアルに“SMART WELLNESS SAAS　共に、この国のウェルネスを支えるインフラへ。”をメッセージとして出しています。

工藤最後に、我々の開発組織を簡単にご紹介します。POSというエンタープライズのお客様に求められる要件をやっている組織、ドメインカットしているような組織が会社内にあります。その他、フィーチャーというあえて抽象的に用意しているチームもありまして、こちらは本当にいろいろな抽象度の高いテーマを扱う開発組織チームです。オールプロダクトと呼び、注力しているところをチームで分けて開発を進めているという体制です。

石川10XのCTOの石川です。弊社はチェーンストアECの垂直立ち上げプラットフォーム『Stailer（ステイラー）』を提供しています。主にネットスーパーやネットドラッグストアを提供するために必要なシステムを提供するプラットフォームです。

具体的には主に3つのアプリをつくっています。1つ目がお客様が実際にネットスーパーで買い物をするためのアプリ。2つ目がお客様から入った注文を店舗スタッフがピッキングするためのアプリ。3つ目が配達スタッフ向けの配達アプリです。それ以外にも、商品情報のマスタや管理画面など、運営に必要なあらゆる機能を提供しています。

都内で身近なのはライフ、あとは広島のスーパーのFRESTA、東北のドラッグストアの薬王堂、長野のスーパーデリシアなど、さまざまな地域の企業と組み、あらゆる地域にネットスーパー・ネットドラッグストアを浸透させていくことを目指しています。

取り扱っている領域は幅広く、基幹システムから発注データをどう取り扱い、どの商品をネットスーパーに掲載するかであったり、お客様の会員情報をどう取り扱うかであったり、何を売り場の特集として出すべきか、入った注文をどう管理するのか、ポイントカードとの連携はどうするのか、ピッキングの状態はどうなっているのか、配達状況はどうかなど、さまざまなドメインがあります。

石川一つひとつの領域が複雑なロジックを要し、それぞれの領域で正確性を求められるという特性がある。そこが大変なところだと思います。

立ち上げ時期には、各パートナー企業に対して事業部をつくり、その事業部内にアプリケーションエンジニアが入り、各社がどのようなシステムを求めているのかを理解しながら開発をしてきました。そうすることでタイムリーに各社の課題感を掴め、検証しながら必要な機能をつくってきたのです。

石川ただ、プロジェクトが成熟してくるにつれ、要求に応えるタイムリーさよりも、長期目線に立ってプロダクトの価値を大きくしていくことが重要になってきていまして、その状況に合わせて組織体制を変えていっているのが今の状態です。

我々のなかではドメインベースの開発体制と呼んでいまして、ある程度の独立性がある各ドメインにチームを置き、エンジニアやプロダクトマネージャー、デザイナーがチームに入っています。パートナー企業により近い組織として事業部があり、その事業部がパートナー企業と一緒にどのようにネットスーパーを伸ばしていくかを考える体制になっているのが現在の状況です。hacomonoさんの話を聞いていて、フェーズが近そうだなという感じがしています。

榎本よろしくお願いいたします。弊社のミッションは“すべての経済活動を、デジタル化する。”でして、新しい経済基盤をソフトウェアテクノロジーを元につくり、そのなかで生産性を向上させ続けることを目指しています。

現在の事業は、バクラク事業、Fintech事業、PrivacyTech事業の3つ。私が携わっているのは1つ目のバクラクというSaaS事業です。Fintech事業は三井物産様などとのジョイントベンチャーでアセットマネジメントのデジタル化を行う事業、PrivacyTech事業はプライバシーデータの秘匿化に関するソリューションを提供する事業です。

榎本バクラク事業部では、「圧倒的に使いやすいプロダクトを届け、わくわくする働き方を。」をビジョンとして掲げています。B向けのSaaSは必ずしも使いやすいものが多いわけではないと思っていまして、私自身もコーポレートの方たちに迷惑をおかけすることがあります。そうした「事務処理能力が高くない人」でも直感的に使いやすい、みんなが働いていて楽しくなるようなプロダクトをつくりたいというのが我々の想いです。

一昨年の1月に最初のプロダクトとして『バクラク請求書』をリリースしてから、『バクラク経費精算』『バクラク申請』『バクラク電子帳簿保存』『バクラクビジネスカード』と5つのプロダクトを展開してきました。テーマは支出管理ですね。企業には、クレジットカード払い、請求書払い、経費精算といくつかの支払い方法があり、そうしたお金の流れを滑らかに楽にするぞという想いでプロダクトを生み出してきました。

ありがたいことに、さまざまな業種業態、規模の4,000社以上の企業に利用されています（※登壇時。その後5,000社突破を発表）。ちなみに宣伝になりますが、バクラクビジネスカードは現在キャンペーンを行っていて、最大2％のキャッシュバックをしているので、ぜひ社内にシェアをしていただけると助かります（笑）。

榎本最後に組織についてです。各プロダクトに部署をつくった上で、共通してQAやデザインのチームがあります。あとは新規・横断プロジェクトで新プロダクトの開発も行っています。さらにそれを支えるML&Data部があったりですとか、DevOpsチームがあったりといった形ですね。

工藤そうですね。我々が取り組んでいるフィットネスという領域は総合フィットネスと呼ばれる大きなプールがあるようなところもあれば、24時間営業店、パーソナルなど、結構いろいろな種類に分けられまして、よく我々は「バーティカルと言うけれども、業界内ではホリゾンタルだよね」といった話をすることがあります。

種類によってニーズや求められるレベルの高さに違いがあるので、優先度を付けるですとか、汎用的につくるところの判断みたいな部分に難しさを感じます。ある程度1つのもので解決できるものを増やさなければ、1つずつ開発していく感じになってしまいますから。ただ、そこがおもしろさでもあるかなと思っていますね。

あとは業界的にエンタープライズが多い業界でして、プロダクトの初期フェーズからエンタープライズが求めるセキュリティ、オペレーションについて言及されることがありました。早期に視座を高められた部分もありますが、レベルの高さに応じて個社要求をどうしていくのかといったテーマが早い段階から多かったかなと思います。

石川そうですね、似たような課題は確かにあります。そこに少し違った視点を付け加えるとすると、我々が目指すところはオンラインにおける生鮮食品や日用品の購買を、都市部だけではなくあらゆる場所に住んでいる人たちが現実的な選択肢として選べるようにすることだと思っているんですね。

まだそういうものが実現されている世界がない状態なので、目指すところに至るまでに必要なものは何かという答えも明確に存在していません。そのなかで探索をしながら必要なものを見極めていく必要があるのが我々のプロダクトの難しさかなと思います。

その探索はスタートアップである我々1社だけでやるわけではなく、地域の大きな小売企業と一緒に行っていくわけですが、そこにも難しさがあるんですね。我々のパートナー企業は各地域で信頼を築いているため、その信頼を毀損するわけにはいきません。各企業との良好な関係性と、プロダクトの安定性を維持しながらも、できるだけ速く新たな探索を進めていなかなければならないのが、我々の直面している状況という感じですかね。

榎本難しいなと思っていることは3つですね。1つ目は先ほどお話した「圧倒的に使いやすいプロダクトを届け、わくわくする働き方を。」というビジョンに関して、“圧倒的に使いやすい”をつくるのは難しいなと強く感じています。これは「ボタンの配置がいい」みたいな単純なことだけではないな、みたいな。

やはり今までにない業務フローをつくるとか、これまで当たり前にあった業務をなくせないかとか、そういった思考をしていかなければいけない。そのなかでようやく「圧倒的に使いやすい」が生まれるなと。

先ほど10Xさんでもあった“これまでにないものをつくる難しさ”ということを、非常にシンプルに感じています。お客様から「こうしたい」と言われたときに、「いやでも、そもそもその業務があるのが何か違うんじゃないか」と考えるようにしたほうがいい。言われた通りやるのは違う、と、落ち着いて、一歩一歩すべて考えなければいけないのが難しいですね。

2つ目はSaaS同士が絡み合っている点。バクラクシリーズの5つのプロダクトは、お客さまの業務上、密接につながっているんですよね。バクラク申請で請求書を受け取り、承認されたらバクラク請求書に反映され、それを元に仕訳がつくられる、といった具合に。

そうした連携があるから使いやすさにつながっていますし、これまでにない世界をつくれているわけですが、それがシステムやプロダクトの設計に難しさを生んでいる要因でもある。データ基盤やプロダクト基盤がどうあるべきなんだろうというところに最近直面しています。

3つ目は、先ほど工藤さんからもお話があったエンタープライズですね。まさに我々もエンタープライズに向かっているフェーズで、要求の違いを感じているところでして。これまでは1セットでプロダクトを使ってもらったら便利になりますといった話をしてきたんですが、エンタープライズの場合は1セットでいろいろなシステムを入れ替えるのが難しかったりする。ちょっとこれまで通りにはいかないなというところでがんばっている状況です。

榎本非常にありがたいことにいろいろなご要望をいただくことが増えていまして、プロダクトが進化できるポテンシャルを感じています。しかし、さまざまな業種業態サイズのお客様からの要望すべてにお応えすることはできませんし、先ほどお話したようにそもそも応えるのが正しいのかわからないものもある。優先順位付けが難しくなっているなと感じています。

榎本ずっとやっているのは抽象化してつくることですね。複数の要望をすべて叶えようとしたらプロダクトがわけのわからないもの、社内では「キメラになっていく」と話しています。要は誰も使えないプロダクトになっていく。そうならないよう、いかに汎用的にきれいに解決するのかを常に考え続けたいと思っています。

あとは迷ったときにはビジョンへの適合を考えています。どういう業務をやりたいのか、どういう業務があるべきだと思うのか。ただ紙を電子化すればいいのか、いや、それは違うよねみたいな話ですね。あるべき姿って何だっけみたいなことを考えて選んでいる感じです。

石川優先順位の話とまさに同じような課題感がありますね。我々の場合だと、1年～1年半ぐらい前に、組織体制を少し変えました。パートナー企業が何に困っているのか、何を必要としているのかをタイムリーに掴めるようにしたんです。そのおかげもあって、以前よりも新たな事業機会を逃しにくくなり、結果的に事業拡大につながった部分があると思っています。

一方で、デメリットというほどではないですが、どうしても個社ごとの対応に偏ってしまう状況になり、長期的な目線で1つの領域について考えることが難しくなってくる可能性はあります。機会は掴めたけれど、都度対応に近いかたちとなるため、運用していくだけですごく大変といった状態になってしまいます。そんな状況でプロダクトを開発しようとなると、一部の機能を変更したときに何が起こるのかという認知コストが大きくなったり、わかりにくくなったりして、変えること自体のリスクや検証コストも高まっていく。

このような、急拡大のメリットデメリット、言い換えるなら諸刃の剣といった感じがありましたね。

なので今は、組織としてさらに変わっていくべきタイミングになってきているかなと思っていまして、よりドメインベースで、長期的にドメインごとの課題を汎用的に解いていけるように組織を構築することが、今まさに直面している課題ですね。

工藤先ほど触れた“インフラ”という言葉ですが、ここに関しては我々があまりうまくできていないところがありまして、例えばジムに通っているエンドユーザーさんにご迷惑をおかけしてしまうといったことに直面したことがありました。急拡大するなかで、アーリーフェーズでやっていたやり方だけではなく、守りみたいなところにも一定のコストを払って体制をつくらなければなりませんし、どんどん出していく一方で品質を確保するにはどうしたらいいのかといった点にも向き合う必要が出てきていると思っています。

その変化にどう組織として適応していくかもそうですし、これまでやったことがあることも壊して考え直さなければいけないところも出てきているんじゃないかなというところですね。

優先順位の話についてですが、いろいろなテーマがあるなかで優先度をつけてチームを構築してやっているというのが我々の回答になります。事業全体の優先順位付けはボーリングに例えてお話することがあります。例えばこれまではフィットネスがセンターピンだったとすると、次のテーマとして選んだスクールは単独ビジネスでもありセンターピンであるフィットネスにも関連するものでもあるんですね。このように、最初のピンからつながるところが次のテーマだという考え方をしています。

榎本爆速開発の定義について、社内では「アウトプットじゃなくアウトカムだよね」とよく話しています。単純に「この機能を1週間じゃなくて3日でつくれた」も爆速の1つではありますが、つくった機能が使われずに負債になってしまうのは1番遅いよねと。なので、ちゃんとお客様の声を聞いて、どうしたらアハ体験を生めるのか、使ってもらえるのかを考え、結果的に使われて残る機能を早くつくるのが1番早い。

アウトプットの部分では「使われないものをつくらない」という標語を元に、PdMはもちろん、エンジニア一人ひとりが場合によってはお客様との商談動画を見たりヒアリングに同席したりして、どうしたら使ってもらえるのかを考えて一つひとつ当てにいっています。

BtoBのSaaSは、動かなくなるとお客様の業務が回らなくなってしまうため、「出してみてダメでした」は基本的に許されないと考えています。そういう意味でも、絶対に負債にならないものをつくるという覚悟を持ってやっているのが定義の話になりますね。

そして、「最近ぶっちゃけ爆速ですか？」は良い問いだなと思っていまして。ぶっちゃけ、やはりグラデ―ションにはなってきています。ローンチから時間が経つプロダクトほど、フェーズが変わっていっているなとは思っていまして、当初つくっていたメンバーがいないといったこともどうしても起きてきて、当時の文脈がわからないといったこともありますので。運用が入ってきたときに爆速で機能開発ができているかというと、最初のわかりやすいボーナスタイムのようにはいかない。

けれども、中長期的に良い開発を持続させ続けられるということも、爆速の1つなんだなというのが最近自分の考えを改めているところです。

私の役割は事業部CTOで、一言で言うと新規立ち上げ屋なんですね。その新規立ち上げの爆速は失われていないんですが、中長期的なところを見据えると、もっといいやり方があるはずだと思う場面が少なくありません。でも事業的には、短期の速度も絶対に落とせないという感じです。

スタートアップはやはりスピードが正義ですし、成長がすべてだとも思っているので、短期スピードを妥協しないという気持ちも同時にあります。

工藤個人的には爆速ですと言い切るのはちょっとあれかもなと思ったりしていますね。というのも、ある程度のクオリティで出すことも一定必要な考え方かなとも思っていまして、リリースした機能が現場で使い物にならないとか、余計業務が遅くなってしまったなったみたいなことはやはり許されないと思うんですよね。そういう品質を、初手からより強く求められるフェーズに弊社はきているのかなと思っていまして、スピードと品質、品質に関しては不具合だけではなく価値の大きさも含めたところをいかに両立させていくかがテーマだと考えています。

いきなり完璧に当てにいくのはなかなか難しいので、お客様とのリレーションといいますか、聞きに行くことが一定大事かなと思いますね。

ここはプロダクト側というよりビジネスサイドが本当にがんばってくれていまして。いつでもお客様に聞きに行ける環境をつくってくれているんですよね。そこに我々は大いに甘えて、お客様に話を聞きに行き、聞いたものをアウトプットしようという目線なのかなと思っています。全体としてのスピードと価値を高めていきたいです。

榎本それ、すごくよくわかります。本当にビジネスサイドの方が良好な関係性をお客様と築いてくれているからプロダクトとしてヒアリングもできるし要望がわかる。感謝しかないですよね。

工藤ええ。顧客アンケートで「対応してくれたカスタマーサクセスの人が良かったから点が上がる」みたいなことがありまして、ビジネスサイドの方とのやり取りがプロダクトの一部体験になっている部分が確かにある。本当にありがたいです。

榎本プロセスもプロダクトという話をしたりします。サクセスや手前のセールスなどを含めて一連のプロダクト体験になるのはまさにその通りです。

石川今のフェーズにおける速さは、事業を始めたときの速さとは変わってきているかなと思っています。立ち上げ段階はプロダクトとしてカバーできる範囲がそこまで広くはないため、全体を認知することも簡単ですし、開発チームも限られた人数なのでやり取りも容易です。ですから、初期段階では個人主義的にバンバン開発できたのが速度を上げられていた要因かなと思います。

ただ、事業を伸ばしていく今のフェーズで求められる速さは初期に求められる速さとは異なると考えています。ネットスーパーという領域自体、ものをバリバリつくることで伸びるというよりは、コアに眠っている深い課題をより良くしていかなければならない領域だと思っているんですね。

領域自体が広がってきているので認知コストが高いですし、チームにおける責任も分割されてきている状況にある。個人がバンバン開発するというよりは、組織として価値のあるソフトウェアを成長させ続けることが今求められているもので、価値がどんどん生まれていることこそが開発速度かなと思っています。平たく言うとROIですね。

会社としては、まさに腰を据えてROIを分析しています。いかにして組織的にシステムを動かしていけるかを突き詰め、それが続くようにガイドラインを引いていこうとしています。

たとえば、「このビジネスロジックはどのレイヤーに入っていて、それはこの自動テストでどう担保すべきか」みたいなものを、開発の標準規約として定義しています。それにより、このレイヤーの変化であればこのテストがあれば大丈夫といったことが言えるようになり、組織的に変更に対するリスクが平準化できるようになります。

その結果、恐れることなく失敗することなく価値を見続けるための変更を積み重ねられる状態になると思っています。まだうちも完璧にできているわけではありませんが、そこを整備していって、価値を生み出すための変更を素早くできる状態を組織として獲得するのが今やるべきことだと考えていますね。

工藤そうですね。我々も同じような局面で意識を高めていったりしている部分はあると思います。チーム内で小さく認知して意思決定するところにすごく共感できるところがありまして、やはりプロダクトもドメインが深くなると認知が拡大したりメンバーがどこまで把握するのかが難しくなってきますよね。チーム内で意思決定をスムーズにやっていくにはどうしたらいいのかという点は我々も課題に思っている感じです。

榎本石川さんから出た“品質”という言葉は、私たちも今のフェーズでかなり直面しているものだなとおもっています。先ほど、プロダクトが出てしばらくしたら爆速から落ちてきても致し方ないという話をしましたが、やはり当時とは前提状況が変わってきて、今となっては当時の設計が最適なものじゃなかったなみたいなことは正直あるんですね。体験にこだわっていると、特にフロントエンドに複雑さをもたらしているなという部分もあって。

その複雑さをどうするのかという技術的な話と、QAの体制をどうつくるかみたいなところ。QA全体として自動テストがきちんと備わっているわけではないので、そこを一歩一歩どうしていこうかという感じです。

あとはデリバリーのサイクル。うちは今2週間に1回なんですが、本当にこれでいいんだっけみたいな話がまさにホットトピックですね。

石川私に答えがあるわけではありませんが、弊社が今取り組んでいるのは自動テストの活用法や、活用できる状態にするために必要なアーキテクチャを考えることですね。レイヤーの分離を社内で進めていまして、そうするとドメインロジックを基本的に網羅的に書く必要がある。

その一方で、アプリケーションサービスですと単純に処理の呼び出しの組み合わせなので、適切にロールバックできているのか、整合性を担保できているのかというところに集中し、パターンとしては結構小さくするみたいなことを今やろうとしています。

より下のドメインのビジネスロジックに対して、いかにQAのメンバーが入るかで会ったり、自動テスト設計にQAメンバーが入ることで、下のレイヤーが上手く守られている状態にして、ビジネス的にあってほしくない状態を防げる状態にしようと奮闘中です。

工藤我々の場合はQAチームがいまして、エンジニアが開発したものの品質を多角的に検証してくれています。それだけでは下請けのような構図になりがちなので、どのようにシフトレフトしていくかをちょうど今検討しているところです。自動テストには1年取り組んでいまして、弊社の場合は決済や会員登録が止まると上が止まってしまうため、自動でぶん回して壊れないようにするところをQAチームとエンジニアが頑張ってくれています。

石川プロダクトマネージャーとデザイナーとソフトウェアエンジニアがいるのが今の開発組織になっていまして、買い物チームであれば買い物体験から生まれる価値を高めていく責任がそのチームにあるという状態です。重要な役割を果たすのはプロダクトマネージャーで、事業開発メンバーはフィードバックや情報のインプット、検証機会を掴んでくるという形になっています。

弊社もロードマップの運用を始めていまして、半期に1回「こういう事業価値を生み出すためにこういう開発をしますよ」という合意を取っているんですが、その意思決定は事業部に受け入れられるものでなければなりませんし、プロジェクトチームに対しても価値があることなんだと伝えきらなければなりません。そのせめぎ合いを私は“適切な綱引き”と呼んでいるんですが、両者が適切に自分たちの責務を果たしていくための緊張関係の綱引きを健全に持てている状態にしたいなと考えていますね。

榎本綱引きをするための場があるんですか？

石川半期に1回プロダクトロードマップを決める会議があり、ドキュメントに考えていることをまとめるのですが、それをつくる過程で事業部メンバーといろいろ話したり、プロダクトの事情を考えたりしています。ドキュメントに落とし込んだあと、ロードマップ承認会という場がありまして、そこで経営チームと事業部、プロダクトチームの3者から見て「確かにこれをやるのが1番いいよね」と確認するという感じです。そんなに多い人数ではないです。

榎本すごく面白いです。ドキュメントの準備が大変そうだなと感じました（笑）。

石川どちらかというとドキュメントの中身、その意思決定をきちんと説明できるかのほうが大変ですね。

榎本その緊張関係がいいですね。

我々の関わり方でいうと、先ほど工藤さんもお話されていたお互いの良いサイクルを回すことですね。プロダクトチームがいいものをつくり、それによりお客様が喜び、あとはBizがお客様と良好な関係性を築いてくれてヒアリングができて、それがまたプロダクトに繋がっていくみたいな良い循環を回していきたいと思っています。

なので、他社さんでビジネスサイドとプロダクトサイドの関係があまり良くないみたいな話を聞くと、やはり言われたものがつくられていないとか、つくられてもかなり遅いみたいなことが起きていたりするなと。それは嫌だなと思っているので、良い関係を築きたいです。何より我々はつくることはできても売ることや届けることはできないので、お互いにリスペクトしてやっていきたいなと思っています。

プロダクトチームとしてはすごく愛を込めてプロダクトをつくっているので、その愛を伝播させたいんですよね、社内に。一つひとつのこだわりを伝えて、その愛が結果的にお客様にも伝わる流れにしたいと思っていまして、毎週社内で事業部全員を集めてレビュー会を開いています。30分間、プロダクトチームが「今週つくったものはこれです」「こういう嬉しさがあります」と熱弁し、その話を聞いてビジネスサイドの方もテンションが上がってくれるといった場です。社内では闘魂注入と呼んでいます。

工藤いいですね、非常にエモい話を聞けました。やはりビジネスサイドの皆さんをリスペクトするというのは本当にその通りだと思っています。我々ができないところをやってくれていますし、お客様の生の声を1番聞いているので、圧倒的に解像度が高いんですよね。

エンジニアはもちろん刺さるプロダクトを獲得しに行くんですが、社内にも有識者がいるので、ぜひ一緒にやりたいなと意識しています。

組織も大きくなってくると社内でベクトルを向ける先が自分や所属しているチームになってしまうことがあり、「何のためにこういう機能にするんだっけ」となることがあります。そのときにプロダクト、お客様のほうをちゃんと向いているのかという話をすることがあります。

工藤存在感なのかどうかはわかりませんが、エンジニアとしてやはり大事なのは「こうなっているほうが楽しいんじゃないか」と自律的に動いたり仮説を立てたりすることかなと思っていまして。一定の解像度から想像力をもってして検証し、その成果物がプロダクトだと思っています。

もしかしたら綱引きのなかで別の意見が出てきて、ディスカッションから自分の意見が進化することもあると思います。インプットとアウトプットがぐるぐる回ると成長にもなるでしょう。そういう方が頼られるエンジニアになるのかなと思いました。

石川先ほど開発速度の速さについてお話しましたが、私は「事業価値をいかにつくれているのか」が速さの物差しだと思っていまして。そういうことを考えたとき、どのロールであっても、今の自分たちの取り組みが価値を生んでいるのかどうかについて常に自覚的でいないといけないと思いますね。

その上で、必ずしも全員が経営者視点をもって仕事をするのがベストかというと、そうではないと思っていまして、そこには役割分担があると思っています。ただ、それぞれのロールのなかで誰かが「これって本当に価値があるんだっけ」と常に考えなければいけないとは思っていて、それが会社や組織が生み出す価値に大きな影響を与えるものだと思っています。自分がその役割を担うかどうかはさておき、頭の片隅には置いておいてほしいですね。

質問にあった「綱引きのなかで存在感を示す」というのはまさに自分たちの取り組みがどう価値を生み出すのかというところに意思を入れることだと思っています。それはビジネス的な観点でもできるかもしれないし、技術的な観点からでもできるかもしれない。情報はチームに開かれているべきだと考えていまして、例えば「このコストを下げるために、我々チームとしてはこうやりますよ」ときちんと言えて、その結果が価値に繋がると実例を示せると存在感があると思います。まさに事業に対して貢献できるエンジニアだといえるでしょうね。

榎本全部言われちゃいましたね（笑）。やはり価値をつくる、課題を解くのがエンジニアだと思っているので、ユーザーが求めているものをつくるためにどうしたらいいのかを考えればいいのかなと思います。単純に機能をつくるだけではなく、機能を届け切るための仕組みや体制も含めてだと思っていて、うまくそのベクトルが外に向いていることがとても大切なのかなと。

榎本引き続き爆速で事業拡大をしていきたいと思っています。プロダクト一つひとつの深さもですし、ラインナップを横に広げていきたいとも思っていますね。引くくらいの勢いでまだまだ続けたいなと。人は裁量やポジション、意思決定の数で成長すると思っているので、とにかく打席を増やしていきたいです。いろいろなポジションの人が意思決定をどんどんできるぐらいの拡大の仕方をしていきたいです。

石川開発組織が幸せなときは、やはり余裕はありつつも自分たちのやっていることに価値があり、その価値があらゆる人に認められている状態だと思っています。

その時々で求められるものは全然違うと思っていまして、適切な問題解決ができているのか、より良い状態で向かえているのかを組織として担保出来ている状態にしたいです。今は全社で100人程度（※登壇時）ですが、500人、1,000人になってもあらゆる組織が調子良さそうに開発をして、価値を生み出している状態にしたいですね。

工藤似たような話ですが、我々はプロダクトドリブンという言葉をよく使っていて、開発だけではなく会社としてそういう組織をつくっていくと明言しています。

そこを継続しながらスケールさせていきますが、当時の勢いは変わってくるところがあると思います。それでも「僕らが出しているプロダクトってめちゃくちゃいいよね」と言えるものを出し続けたいのが基本目線ですね。

あと1つテーマにしているのは、組織のメンバーが楽しめているかどうか。ふわっとした話になるんですが、私としてはみんなが楽しめる仕組みやカルチャーをつくっていくところもテーマに持ちつつ、基本的にみんながプロダクトに向いている状態を今後もつくっていきたいと意識しています。

榎本難しい問題ですよね。社内では“優しさ”と呼んでいまして、明らかにそうした方がお客様に優しいよねみたいな話をしています。その優しさをどうするかが話に上がるんですが、やはり一定のリソースを覚悟して取るしかないのが教科書的な答えかなと思います。

例えば、スクラムのうち5％や10％は優しさに割くと事前に決めておくとか。品質に対して70％は事前に取ると決めておくとか。一つひとつ説得するのは無理だと思うので、全体としてまず確保することですね。

とはいえ我々の現状としては、覚悟を持って優しさにパーセンテージを割くことはできておらず、歯がゆい思いをしているというのが正直なところです。私の一存で決められる立場ではあるのですが、なかなか難しいのが現実ですね。

石川前提として、多少不便でも使っていただけているのはニーズが捉えられているんだなと思います。優しさにどう時間を割くかですが、やはり開発チームとして自分たちが何に時間を割くのかについて話す時間をもう少し長く取ってもいいのかなと思っていまして。

なぜ今これをやっているのかを納得できると、捉え方が少し変わるかもしれません。とはいえ、フリクションをなるべく小さくしたいのであれば、意思決定の大きさを小さくすればプロダクトマネージャーとしても取りやすくなるかもしれないなとも思っています。

自分のスプリントのなかで、「自分のタスクはこれぐらいで、残りの時間はフリクションの開発に対して検証してみたい」「取り除いた結果、こういうことが起きました」と言えるようになると、事前に議論を尽くすよりも判断しやすくなるんじゃないかなと。

工藤小さいコストで大きいインパクトを出せるものもいくつかあるかもしれないので、ROI の観点を入れつつイシューを深堀りするのは良いかなと思います。売上に寄与するかどうかでいうと、こういう一つひとつの改善が顧客満足度に繋がっていると思っていて、結果として LTV に繋がるものだと思います。

我々の場合もあまり上手くやれているわけではないですが、一定まとまった時間を確保しながらやってみたりはしていますね。月のうち1週間をカイゼンウィークと称して細かいけど現場の人にとっては喜んでもらえるような改善をする時間に当ててみることにトライしたこともありました。継続することは別の難しさがありますが、少しずつそういった取り組みを積み上げていただくのもいいんじゃないかなと思います。