2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。

本記事では、株式会社UPSIDERでVP of Engineerを務める泉 雄介さんと、STORES 株式会社でCTOを務める藤村 大介さんによるディスカッション「その開発、本当に利益につながる？ エンジニアが考えるべき3つの問い」の内容をお届けします。

このセッションでは、ファインディ株式会社 取締役CTOの佐藤 将高がモデレーターを務め、「そのテスト書く意味あるの？」、「バックログの優先順位は正しいのか？」、「その新技術導入、本当に意味あるのか？」の3つの問いを中心にディスカッションが行われました。

■登壇者プロフィール 泉 雄介(@yizumi) 株式会社 UPSIDER VP of Engineer

アメリカの音楽大学を卒業後、メディア制作会社で作曲家として勤務したのち、システム開発で起業。モルガン・スタンレー証券会社での債券取引のシステム開発や、ディー・エヌ・エーにおけるゲームプラットフォーム事業やヘルスケアサービス開発のリードエンジニア、ラクスル取締役CTOを経て、株式会社UPSIDERに入社しVP of Engineerを務める。

藤村 大介(@ffu_) STORES 株式会社 執行役員 CTO

新卒でSAP導入支援企業に入社し、ソフトウェア開発に従事。その後、株式会社 Aiming、Quipper Limited社で開発チームのリーダーを務め、2015年10月に株式会社マチマチを共同創業、取締役CTOに就任。2020年にヘイ株式会社（現：STORES 株式会社）に入社、2020年8月よりCTO、2024年3月に執行役員に就任。

■モデレータープロフィール 佐藤 将高(@ma3tk) ファインディ株式会社 取締役CTO

東京大学 情報理工学系研究科 創造情報学専攻(*)卒業後、グリーに入社し、フルスタックエンジニアとして勤務する。2016年6月にファインディ立上げに伴い取締役CTO就任。 *大学院では、稲葉真理研究室に所属。過去10年分の論文に対し論文間の類似度を、自然言語処理やデータマイニングにより内容の解析を定量的・定性的に行うことで算出する論文を執筆。

UPSIDERと STORES、それぞれが持つミッションと事業

――このセッションでは、「その開発、本当に利益につながる？ エンジニアが考えるべき3つの問い」ということで、面白いテーマを準備してまいりました。最初に、お二方から自己紹介と会社紹介をいただきたいと思います。まずは、泉さんからお願いします。

泉：泉と申します。キャリアとしては、もともと音大を卒業して、メディア制作会社で作曲家としてキャリアをスタートしました。その後、ソフトウェア開発が面白くなって起業し、そこから金融やDeNAなど転々とした後、前職のラクスルではCTOを経験。現在は、UPSIDERでVPoEをしています。

UPSIDERという会社は、「挑戦者を支える世界的な金融プラットフォームを創る」というミッションを掲げ、いくつかサービスを展開しています。主力サービスとしては法人カード「UPSIDER」を発行しており、おかげさまで非常に成長しています。

その他には、請求書カード払いサービスの「支払い.com」。それから、日本では初となる、レイターステージのスタートアップ向けのデットファンド「UPSIDER BLUE DREAM Fund」。デットファンドは、欧米では資金調達の方法として確立されてきているものですが、それを提供しており、多くのスタートアップ企業にご利用いただいています。

泉：事業規模は急成長していて、スタートしたときと比べてトランザクションの数は100倍どころか1,000倍ほどのレベルになり、アーキテクチャもいろいろと改修しながら、ここまでやってきています。従業員の規模は、全社で約280名。そのうち、プロダクト開発に関わっているのが約120名、エンジニアが約70名となっております。

――続いて、藤村さんもお願いいたします。

藤村：STORES でCTOをしている藤村と申します。僕は文系出身なのですが、新卒でプログラミングを始めて、そこでプログラミングの面白さを知りました。スタートアップの経営も面白いなと感じて、日本のスタートアップ何社かでコードを書いたり、チームを率いたり、技術戦略をつくったり、採用したりしてきて、2020年に STORES に入ってCTOを4年ほどしています。

続いて、STORES という会社についてです。世の中には、自分のこだわりや情熱で事業やサービスをされている方がたくさんいらっしゃいます。そういう人たちがつくっているものがもっと増えてほしいし、僕らはそれを助けるデジタルインフラとなるプロダクトをつくりたい。ということで、「Just For Fun」というミッションを掲げています。この言葉は、リーナス・トーバルズの本にヒントを得て生まれたそうです。

事業としては、お店をやるにあたって、ソフトウェアの力やデジタルツールの力が必要なところを、丸ごと STORES でサポートすることを目指しています。ECサイトの会社というイメージが強いかもしれませんが、今はネットショップ以外にも、オンライン予約システム、キャッシュレス決済サービス、顧客管理のシステム、それにつながる店舗のアプリ作成など、いろいろなプロダクトを展開していっています。

藤村：少しデータが古いですが、2023年7-9月期のGMVが800億円くらい。GMVというのは、STORES のなかでどれくらいお金が流通したかを示すもので、これが800億円という規模になっているので、ちょっとした社会インフラと言えるくらいの規模にまで成長しています。従業員数も少し数字が古いですが、全体で379名。そのうちエンジニアが3割くらいで、だいたい100名くらいのエンジニア組織になっています。

エンジニアとして、自分の時間をどこに投資するかを考える

――本日ファシリテーターを務めさせていただきます、ファインディCTOの佐藤です。『エンジニア組織を強くする開発生産性の教科書』という本を出していまして、まだ読んでいない方はぜひお手に取っていただければと思います。ここで泉さんから、今回なぜこのテーマになったのかについて、お話しいただけますか？

泉：今回テーマが開発生産性ということで、藤村さんとブレストしていた際に、そういえばこんな記事を書いていましたねと。「商売としてのソフトウェア開発、そのコード1行がいくら稼ぐのか」というタイトルの記事で、自分が4年くらい前に日経xTECHで出したものです。

生産性というのは、開発がスムーズに進む方がみんな気持ちよく仕事ができるとか、そういったエンジニアの美学的なところもあると思います。ただ、前職も今も金融系にいる私としては、「結局利益につながるの？」というところで考えているんですね。

考えてみると、ソフトウェアには物理的な実態がないので、なんとなく軽いものに感じやすい。だから、経営者の人が「エンジニアが頑張ったらパッとつくれるんでしょ」なんて言ったりするわけです。物理的な実態があるビルが建っていくとなれば、目に見えてわかりやすいですが、物理的な実態がないソフトウェアのことは勘違いしやすいんですね。それに対して私は、「とんでもない！」と思っています。

例えば、『みずほ銀行システム統合、苦闘の19年史』という書籍があります。有名な話ですが、過大な投資とアセットが生み出す収益が見合わなくなり、4,600億円の損失を計上したと。4,600億と言われるとピンときませんが、有形資産で例えたら、六本木ヒルズの総工費が約2,700億円だと言われています。六本木ヒルズが1.7本分くらいと考えると、その規模たるやという感じじゃないですか。

泉：六本木ヒルズは一度建ててしまえば、ブランドの店舗や飲食店などが入って、オフィスからも賃料がどんどん収益として入ってきます。これが資産というものですよね。ソフトウェアも実態がないように見えるけれど、定義は何も変わらないと思っていて、同じような資産になると考えなければなりません。

例えば、今もし皆さんが3人くらいのチームをマネージしているとしたら、それだけで数千万円の事業になっているわけですよね。コストという見方もありますが、投資という見方をしたとき、そこでつくったソフトウェアが資産になって、その資産が稼働することによって収入を得なければいけない。当然その収入は、投資を上回らなければならないし、それができなければ企業価値が下がる、上場している会社なら株価が下がることにつながります。

なので、私はエンジニア＝投資家だと思っています。資本家というのは、お金をどこにアロケートしてどういう資産に投資すれば、その後のリターンが得られるかを考えます。エンジニアの場合は、自分の時間をどこに投資すれば、効率よくお金が返ってくるかを考えなければならない。そういう価値観を持たなければならないと思っています。

ここにいる皆さんも、自分でつくったシステムが稼動しているからこそ、今こうしてカンファレンスにいるときも、ご飯を食べているときも、システムが稼いでくれているわけですよね。まさに資産じゃないですか。だから、生産性について立ち返って考えると、いかに時間を効率よく使うかという部分に無駄があってはいけないと思っているので、普段やっていることに改めて疑問を持ってみようというのが今回の趣旨です。

問1：「そのテスト書く意味あるの？」

――まず1つ目の「そのテスト書く意味あるの？」という問いから、始めていきたいと思います。藤村さんいかがでしょうか？

藤村：まさに先ほどの話とつながってきますが、投資対効果があるかに尽きるんでしょうね。テストをなぜやっているのかに立ち戻った方がいいと思っていて、リグレッションテストやDDDでソフトウェアをつくるためなど、いろいろあると思いますが、僕は広い意味でのQAだと思っているんですね。ソフトウェアを出す前に、正しく動いているかどうかを確認するQAの一部だと。

それが自動テストであれば、継続的にできるということが、テストコードの資産価値だと思います。主にリグレッション対策になると思いますが、それが今後に渡ってもうまく発揮されるテストコードになっていれば意味がある。大きく捉えると、そこが意味があるかないかの判断軸になるかなと思います。

泉：おっしゃる通りで、テストコードは反復されることにすごく価値があると思っています。テストは、そのソフトウェアがどう振る舞うかを定義しているという意味では、実装よりも価値があるという見方もできると思うんですね。テストを書いた瞬間というのはすごく気持ち良くて、なぜかというと2回目、3回目とテストしたら使っている時間が、今この瞬間なくなっていると実感するからです。

ただ、これが行き過ぎて、カバレッジを何%キープしたいという話になってくると、それは「意味あるの？」と。カバレッジのためにテストを書く意味は、まったくないと自分は考えています。

もう1つは、リグレッションのなかでも、例えば100個の機能があったら、その重要度にはグラデーションがあると思うんですね。決済や注文に関わるような幹の部分だったら、顧客が何百回も何千回も使うわけですから、そこがFailしたときの損害を考えると、書く意味はものすごく重いと考えられます。

逆に、ニッチな機能のような枝葉の部分であれば、最終的にカバーしたい気持ちはあったとしても、優先度はあまり高くないでしょう。そういう観点で、書く意味があるのかというのは、常に自問自答すべきだと思っています。

――事前にお伺いした内容も含めて、1つ目の問いについてまとめたいと思います。こちらの内容について補足があればお願いします。

藤村：おそらくここに参加されている皆さんも、売り切りのソフトウェアではなく、SaaSをつくっている方がほとんどだと思います。継続的に新しい機能をデリバリーしていくことが我々の宿命だと思うので、その品質保証のコストを下げるかどうかで判断すること。そして、先ほど泉さんもおっしゃっていたように、本当に重要なところに投資することが重要だと思います。

問2：「バックログの優先順位、それは本当に正しいのか？」

――2つ目の問いは、「バックログの優先順位、それは本当に正しいのか？」です。こちらに関して、まずは藤村さんからお伺いできればと思います。

藤村：バックログの優先順位は難しくて、正しくないときもあるというのが僕の考えです。バックログは限られた時間で積んだり順番を変えたりするものなので、事業の状況が少しずつ変わっていくなかで、「これは必要ないのではないか」とか、「優先度を下げた方がいいのではないか」というときは、広い視点で建設的に疑うことが重要だと思います。

短期的、中期的に事業として追っている数字に、今取り組んでいるバックログアイテムがどう貢献するかという途中式はすごく長くて、想像力も必要だし時間もかかるし難しいかもしれません。でも、自分が参加している事業や製品ですから、しっかりと価値を理解して途中式を埋めて、その機能が本当に価値があるのかを、遠くから眺めて考える必要があると思います。

あとは、先ほどのテストコードの話ともつながりますが、ソフトウェアは資産なんですね。積み上がったソフトウェアの資産のうえに、新しいものを継ぎ足していく仕事がSaaSの開発の特徴だと思いますが、「この方向性で継ぎ足すと、とんでもないことになるぞ」となったら、勇気を持って「引き返した方がいい」と言うことも重要です。

例えば、これを足すと、コアなドメインモデルをめちゃくちゃに壊してしまうから、この方向にはいかない方がいい、とかですね。先ほど挙げた事業の観点とは逆側で、これからプロダクトを拡張していくうえで、積み上げていくソフトウェアの資産として価値があるかという観点から、良し悪しを判断することも重要だと思います。

――バックログの優先順位に関して、泉さんいかがでしょうか？

泉：手短に言ったら、PdMやビジネスメンバーといった構想を持ってきたメンバーとバトる、というのが一番わかりやすいんじゃないかなと（笑）。ROI（Return on Investment）という言葉がありますが、問題はそのIの部分がわかっているかということです。

エンジニア出身のPdMだったら、感覚的にわかるところもあるかもしれません。ただ、実際にフロントの実装を考えてみると、難しいところが出てきたりして、実はバックログ通りにやらない方が効果が得られるようなこともあると思うんですよね。場合によっては、オペレーションでカバーすればいいのではないかとか。

そういうIの部分を考えるのは、エンジニアしかできない場合もあるし、違うと思ったなら言えないとおかしい。構想を考える側のメンバーが、Iの部分まで解像度を高く持っているなら別ですが、そうでなければどこかでバトっているはずなので、そういう形で現れてくるのかなと思っています。

――「これって本当に要ります？」というような健全な議論を起こしていかないと、どうしても言われたものをつくるだけになりがちですよね。

泉：まさにその通りです。

藤村：ソフトウェアをつくる側の専門家として、やらなければいけない仕事ですよね。例えば、些末でそんなにインパクトがないものだけど、実はものすごく時間がかかるというとき、「これはこう見えてめちゃくちゃ大変なので、投資対効果が合わないですよ」とちゃんと言うのは、ソフトウェアエンジニアという専門職の仕事だと思います。

泉：この前、フロントエンドエンジニアのメンバーと話していたんですが、やっぱり要件のところまでさかのぼるんですね。これ以上やると時間がかかるから引き返す、つまり「ここはやらない」という判断をしたりするんです。そういうときに、いい判断をしているなと思うし、エンジニアがそういう裁量を持っているべきだなと思います。

藤村：本当に大変かどうかは、紐解いてみないとわからないこともそこそこあるので、そういうときはちゃんと引き返す判断が重要ですよね。

――こちらが2つ目の問いのまとめになりますが、泉さんから今お話しされていなかった部分の補足をいただければと思います。

泉：データと客観指標をベースにすることも大事だと思っています。私は優先順位に疑問を持ったら、実際にデータを見てみて突き返すこともあります。やはりエンジニアがそこを判断できることが重要で、そういう場面が普段の開発のなかでも見られることは大事だと思いますね。

――もちろん相手の意見を押しつぶすような議論をするとか、そういう話ではなく、投資対効果を上げるために健全に議論していきましょうということですよね。

泉：おっしゃる通り、正しいことを議論する必要はなくて、納得できたらそれでいいと思うので、そこは勘違いしてほしくないですね。

藤村：一言追加すると、ここまでと少し矛盾するような話ですが、「これはそれほど使われるものではないけど、秒でつくれるからいいか」と言ってつくる手の早さも、それはそれで重要かなと思います。

問3：「その新技術導入、本当に意味あるのか？」

――それでは、3つ目の問い「その新技術導入、本当に意味あるのか？」に移りたい思います。泉さん、こちらいかがでしょうか？

泉：この問いを考えて思ったことが2つあります。1つは、当たり前だけどやっぱり新しいものを使いたくなりますよねと。我々もつい最近、あるツールの導入について議論していたのですが、新たなものを入れるときは、自分たちでメンテすることを想像しなければならないですよね。

例えば、オブザーバビリティが少し足りていないから、そこも自分たちでつくらなければいけないとなると、それはそれでコストもかかってくるわけで、総合的な判断が必要です。新技術を導入することは、いろいろな不確実性と戦うということなので、そこのコストが本当に勘定に入っているかは気になるところです。

もう1つ、これは少し本題から外れますが、本職の開発で実験をすべきなのかというテーマがあるなと思っていて。不確実性がある新しいものを導入して、本業を実験台にすることが果たして許されるのか。そういうテーマでも話したかったところですが、議論が発散しそうなので一旦ここまでにします。

――後ほど時間があったら触れたいですね。新技術の導入に関して、藤村さんいかがでしょうか？

藤村：新しい技術は、いかにも自分の目の前の問題を美しく解決してくれるかのように思えることが多いんですよね。ですが、泉さんがおっしゃる通りメンテナンスもそうだし、今あるものでつくるのと、新しいものでつくるので、どれくらい差分があるかを正しく見極める必要もあります。今あるものでもつくれることが多いですし、新技術を導入せずにプログラミングの力で何とかなるパターンも結構多いと思うので。

ただ逆に、本当に新しい技術を導入しなくていいのか、という話もあります。枯れた選択をするとき、例えばEC2にアプリケーションサーバーを置いてやるのか、Fargateでやるのかという選択で、慣れているからという理由で前者の方でやるとしたら、場合にもよりますが、新しいものを使わないことの損失もそこそこあると思うんです。

新しくて最適なもので生産性が上がる、長期的なメンテナンスも簡単でコストも低くて、プロダクトを新しく出すのも楽になるものがあるなら、それを正しく取り入れるということも、やらなければならないと思います。

――先ほどの泉さんのお話について、僕は本業を実験台にしながらファインディのサービスをつくってきた側ではあるのですが、深堀ってお伺いしてもいいですか？

泉：スポーツのプロ選手だったら自主トレをしていて、キャンプでは合同で練習するときの練習をします。そこで個人でやれるような練習はすべきではないと思うんですね。つまり、リスクを減らす作業をどこでやるかという話かなと。もし本業でやるなら、R&Dにかける時間を初めに何時間と決めて、そのなかで上手くいかなければ一度諦めて、また別のタイミングで試すことにしてもいいと思います。

ただ、藤村さんがおっしゃっていた話はすごく大事な話だと思っていて、新しく出たものを我々のシステムに取り込んだときに、どういうインパクトが生まれるのかを常に検証する必要があります。この数年で言えば、LLMの活用などもそうですが、そういったものに常にアンテナを張っていなければいけないと思っています。

藤村：15年くらいこの業界にいて、ゆでガエル的に古いテクノロジーで取り残されるということがあるなと思うところがあります。悲しいことに、会社全体がゆでガエルになってしまうこともあると思うんですね。そういう意味では、戦略的に新しいものに少しずつ切り替えていくことも、CTOの仕事としては必要なのかなと思うときがあります。

泉：もう1つ無視できないのが、採用市場ですね。新しい技術を使っているからという理由で、興味を持っていただけることもあるので、そこも案外無視できないと思います。

――僕も採用に効きそうかという観点で、技術を取り入れていたことがあります。でも、新しすぎて誰も扱えないとか、そこに採用したい人がたくさんいるけど実は競合もたくさんいるとか、そういう難しさもありますよね。

藤村：僕は関数プログラミングがすごく好きだったので、そのジレンマを悲しいほど味わいました。

――ここで1つ聞いてみたいのが、メンバーの方から「新しい技術を入れたい」と言われたときにどうするかです。お二人は、どのように反応されますか？

泉：つい最近あったツール導入の検討では、少し機能がリッチすぎるようにも感じたんですが、値段はそれほど高くない。かつ、表に出てくる部分ではなく、バックオフィスで使われるコンポーネントのための技術だったんですね。テクニカルなフィジビリティとしては問題なさそうだったのと、ちょっとした隙間をあげることも大事だと思ったので、まずは1回やってみて評価しましょうという形でOKを出しました。

藤村：その技術が解こうとしている問題が、やろうとしてることの問題に正しくミートしていて、かつある程度の商用利用がされていて大丈夫そうだという確証が持てる、安全マージンが取れているものであればいいでしょうと。ただし、本当に自分でちゃんと面倒を見るならいいですよという話をしますね。

――それでは、3つ目の問いのまとめに入りたいと思います。

泉：1つは藤村さんがおっしゃったように、課題とのフィットというのは、改めて聞いていてそうだなと思いました。あと、やはりチームで開発している以上、対話を通じていろいろな角度で見て決めることも大事なので、対話を通じて総合的に考えて採択するというステップは挟んだ方がいいと思います。

藤村：安易に飛びつかず、今やれるものでやれないかどうかを考えるというのは、1つ必要なステップです。そのうえで、その問題に対してはそのソリューション、そのソフトウェアを使った方が、筋よく自然な形で解決できるのであれば使うという判断になると思います。逆に、プロブレムソリューションフィットが上手くいっているのであれば、学習やトレーニングのコストはリーズナブルな範囲でかけるべきだと思っています。

――個々のテーマでイベントをしてもいいくらい面白い内容だったと思いますが、お時間の都合上、本日は以上となります。最後に、お二方から告知をお願いします。

泉：積極的に採用しております。バックエンド、フロントエンド、フルスタック、データ、モバイルApp、いろいろな領域で採用しています。金融という領域は堅く捉えられる方もいると思いますが、我々はモダンな技術を使って、我々らしいやり方で金融の課題を解いていると自負しています。ご興味を持っていただけた方はぜひ「Findy」で“いいかも”していただけると、こちらからご連絡差し上げられると思いますので、ぜひよろしくお願いします。

藤村：僕らもエンジニアを募集しています。先ほどのお話にもありましたが、金融って面白いんですよ。僕らも決済端末があって、金融サービスが中にあって、お金がたくさん流れるシステムなんですが、それをモダンな技術を使って上手くやっていく。金融ならではのレギュレーションもありますが、それと戦いながらやっていくのは、エンジニアにとって面白いところなので、ぜひご応募いただければと思います。

また、Podcastをやっていまして、技術やそうでない話まで僕がいろいろ話していますので、ぜひよろしければご覧ください。

――それでは、本セッションを終了させていただきます。泉さん、藤村さん、ありがとうございました。