キャッシュレス決済サービス「PayPay」は、いまや「生活に欠かせないインフラ」と言えるほどに普及しています。その成長を支える重要な組織の一つが、社内向けの業務系システムの開発・運用を担うSystem Development部です。「金融系システムの開発」というと、レガシーな技術を用い、開発スピードが遅いイメージを持つ読者も多いかもしれません。しかし、System Development部ではローコードツールなどのモダンな技術も積極的に採用しており、時には数週間という短期スパンで新システムをリリースすることもあります。また、今後はAI Agentic IDEの活用も視野に入れています。System Development部 部長の藤田文彰さんに、開発方針や組織の取り組み、今後の展望を伺いました。参考記事：<a href="https://whatweuse.dev/article/paypay_system_division" target="_blank" rel="noopener noreferrer nofollow">生成AIやデータ分析も取り入れた内製開発の魅力。PayPayの事業成長を支える社内業務システム</a><h2 id="h3e52d94190">「内製開発」に徹底的にこだわる</h2>――System Development部の役割や業務内容について教えてください。私たちは、「PayPay」の事業を運営するうえで必要な業務システムの開発・運用を担う部署です。たとえば、マーケティングや営業、顧客対応といった社内業務を遂行するために必要なシステムを作っています。金融領域で事業を展開するうえで欠かせない、審査機能の構築も私たちの担当です。法人向けの審査に加え、ユーザーのeKYC（オンライン上での本人確認）システム、サービス利用中の途上審査、不正取引のチェックなどの仕組みを開発・運用しています。――金融系のシステム開発では、社内システムを外部委託するケースもありますが、内製での開発・運用を行う意図は何でしょうか？いくつか理由があります。まず、外部業者に委託する場合、プロジェクトの初期フェーズで要件を確定させる必要があるため、後からの仕様変更が難しくなってしまいます。PayPayの事業では、数カ月ほどでサービス企画や仕様が変わることも珍しくありません。柔軟なシステム開発が求められるため、外部委託では対応が難しいです。もう一つの理由は、事業運営に直結するシステムだからこそ、トラブル発生時に迅速な対応が求められる点です。開発を外部業者に任せすぎると、緊急時の即時対応が難しくなるだけでなく、システムがブラックボックス化して、自分たちで対応できなくなるリスクがあります。こうした理由から、私たちは内製化を推進しています。<h2 id="hf2ee354594">大切なのは「事業価値の創出」。それに適した技術を採用する</h2>――System Development部が、技術選定において重視していることは何でしょうか？私たちは技術を「事業価値を生み出すための手段」として捉えています。そのため、基本的には開発・運用のしやすさを重視し、チームメンバーにとって扱いやすく、実績のある技術を選定しています。一方で、特定技術を導入することでより大きな価値を創出できると判断した場合には、新しいものも積極的に採用しています。――具体的には、どのような技術を用いていますか？前提として、私たちの部署ではスクラッチ開発とローコードツールによる開発という2つのアプローチを取っています。そして、スクラッチ開発では、メインの言語としてJava、フレームワークにはSpring Bootを使用しています。インフラはAWSで、コンテナ技術を活用しておりAmazon ECS上でシステムを運用しているのが特徴です。また、AI関連技術としてAmazon SageMakerも導入しています。マネージドサービスを用いることで運用コストを抑えつつ、システム開発の速度向上や品質改善に注力しています。 一方、ローコードツールによる開発では、「OutSystems」というプラットフォームを使用しています。「OutSystems」はドラッグ＆ドロップでUIを構築できるほか、エンタープライズ向けシステムに必要なセキュリティ機能やAPI連携機能なども備えています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/88369ef440304cbda2f616ca88fd9ad6/image3.jpg" alt="" width="1999" height="1334"></figure>スクラッチ開発とローコード開発は、主に用途に応じて使い分けています。社員向けのツールでは、ローコード開発を選択することが多いです。ローコードでアプリのデータモデルと画面を構築したうえで、社内のニーズやユースケースに合わせてカスタマイズしています。一方、スクラッチ開発は大規模かつ複雑性の高いシステムに適用しています。また、開発の効率化を目的に、生成AIの利用も進めています。各プロジェクトでGitHub Copilotを導入し、コード補完やリファクタリングの自動化によって開発スピードを向上させています。さらに、AIエージェントのClineも社内で一部利用が認められており、今後さらに活用を進める予定です。ただし、金融領域での開発であるため、やみくもに導入を進めるのではなく、セキュリティやプライバシーとのバランスもかなり重視して方針を検討しています。<h2 id="hca36a368a5">必要最小限の機能を見極め、場合によっては“作らない”選択を</h2>――開発において大事にしている指針はありますか？開発の優先度を明確にし、必要な部分から段階的にシステムを成長させることです。たとえば、新しい取り組みを始める際に、最初から100点満点のシステムを目指し、業務フローも抜本的に変えようとすると、完了までにかなりの時間がかかります。まずは、システムが30点程度の状態でも、プロセスが回るならば十分だと考えています。そこから段階的にシステムを作り込み、100点にしていくイメージですね。これは、スピードと品質を両立するための戦略です。真の意味でシステム化が必要な箇所と、そうでない箇所を見極め、最小限の機能からスタートして段階的に開発を進めています。――具体的に、これまでのプロジェクトでどのような事例がありましたか？この考え方に沿ったプロジェクトとして、2024年に行った寄付・お賽銭の事例をご紹介します。もともと私たちは「PayPay」を通じて、「商品やサービスの対価としてお金を支払う」「個人間で送金する」といった機能を提供していました。そこからさらに、「寄付などのための送金機能を設ける」という構想が立ち上がりました。このプロジェクトでは、金融に関する各種法令を遵守しながら開発を進める必要がありました。加えて、既存の仕組みよりも厳格な審査プロセスの設計が求められました。資金洗浄や詐欺といった不正な取引に悪用されるリスクがあるためです。しかし、すべての要件を一度に実現しようとすると、大掛かりなプロジェクトになり、スピードが落ちてしまいます。こうした構想が進む中で、本サービスの利用を予定されていた最初のお客さまから、利用スケジュールについてのご相談がありました。そのスケジュールに間に合わせるために、サービスインのために最低限必要な機能を定義し、それ以外の部分は既存の仕組みを流用するとか手作業で補うという方針を取りました。具体的には、このプロジェクトでは個人情報や機密情報を扱うため、セキュアな環境で書類を扱うことが必須でした。これを、既存のシステムの仕組みを活用し、運転免許証やマイナンバーカードの画像をストレージに保存することで、開発工数を抑えたのです。その結果、予定通りのスケジュールでサービス稼働を間に合わせ、PayPayから募金を行えるようになりました。もう一つ、類似した事例として過去に取り組んだ自治体のキャンペーンがあります。このプロジェクトでは、「特定の県に住む人・働いている人」を対象としており、住民票や就労証明書を提出してもらう必要がありました。しかし、これまで「PayPay」には、こうした書類を受け取る仕組みがありませんでした。加えて、施策を実行するにあたっては設計や実装を2週間程度で終わらせる必要がありました。このプロジェクトには、大きく分けて「県内在住・勤務者から書類を受け取る」「書類を審査し、ストレージに格納する」「条件に合致する人を対象にキャンペーンの抽選を行う」という3つの処理が必要でした。すべてをシステム化すると2週間では間に合わないため、一度きりの処理は手作業でカバーし、何度もくり返し処理する部分のみを優先的にシステム化する方針を採用したのです。このプロジェクトでは、テックリードのメンバーを中心に、少数精鋭でシステム構築を進め、予定通り約2週間で開発を完了しました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8ec9c2fdd82d4c54a537db50c63f5adf/image5.png" alt="" width="1854" height="887"><figcaption>証明書アップロードから抽選、本人確認書類の審査、抽選結果通知までの業務フロー</figcaption></figure>――いずれのプロジェクトも、かなりのスピード感ですね。そうですね。かつ、スピードがあるだけではダメで、金融系サービスである以上はセキュリティやプライバシーの担保も欠かせません。そのバランスを常に考えながら開発を進めているのが、私たちの部署の特徴です。<h2 id="h040e1e0b2e">これまでの常識にとらわれず、積極的に越境してほしい</h2>――今後、System Development部として特に注力したいことはありますか？圧倒的な生産性向上です。前回、<a href="https://whatweuse.dev/article/paypay_system_division" target="_blank" rel="noopener noreferrer nofollow">システム本部長 兼 システム本部 AI活用推進室長の岡田が出演したインタビュー記事</a>でも解説していましたが、私たちは生成AIに注目しており、開発プロセスに取り組むことに積極的です。2025年度は、生成AIの活用を前提としてプロジェクトを推進したいです。余談ですが、生成AIの普及に伴い、エンジニアの役割もこれまでの「製造する」フェーズから「創造する」フェーズへと進化していると感じています。過去のやり方に固執せず、世の中の変化に適応しながら働く意識が重要だと考えています。――他の金融系サービスの企業と比較して、System Development部だからこそ得られる経験はありますか？まず、「PayPay」自体の事業成長のスピードですね。2018年にサービスを開始してから、現在はユーザー数7,000万人（2025年7月時点）を突破しています。これほどの速さで成長を続けている事業は、なかなかありません。また、System Development部では、ビジネスプロセス全体を俯瞰しながら開発を進めています。ビジネスの変化を最前線で体感しつつ、システムを開発・運用する経験を積めます。一般的に、金融系の企業は新技術の導入に慎重な姿勢を取ることが多いですが、PayPayでは柔軟にチャレンジできる環境が整っています。新しい技術に挑戦できる環境を求める方にとっては、非常に魅力的な職場だと思います。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/2518ad5f0c7d4a9e82cad6ff32b23d90/image4.jpg" alt="" width="1999" height="1334"></figure>――どのようなマインドの方が、System Development部にマッチするでしょうか？「今まで当たり前だったことを、当たり前だと思わない」という姿勢を求めています。要するに、これまでの慣習や成功体験にとらわれず、新しい領域に果敢に挑戦できる方。そのほうが、入社後に大きく成長し、パフォーマンスを発揮できると考えています。また、「自分の技術を過信しない」ことも重要です。自分の持っている知識やスキルが、今後も必ず正しいとは限りません。次々と新しい技術が登場するなかで、それらをどのように活用し、価値を生み出せるかを考えられる人であってほしいです。――最後に、読者へメッセージをお願いします。「PayPay」を盛り上げる気持ちを持つことに加えて、常にチャレンジする姿勢を大切にする方であればPayPayで活躍できると思います。また、メンバーには「私はエンジニアだからシステム開発以外はやらない」と考えるのではなく、積極的に領域を越境してほしいです。既存の役割だけに縛られてしまうと、将来的なキャリアの可能性が限定されてしまいます。新しいことに挑戦したいと思ったら、どんどん声を上げていくような積極性を持つ方と、ぜひ一緒に働きたいです。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

PayPay株式会社のSystem Development部ではローコードツールなどのモダンな技術も積極的に採用しており、時には数週間という短期スパンで新システムをリリースすることもあります。また、今後はAI Agentic IDEの活用も視野に入れています。System Development部 部長の藤田文彰さんに、開発方針や組織の取り組み、今後の展望を伺いました。

フルスクラッチだけではなくローコード開発も駆使。AI Agentic IDE利用も見据える。なぜPayPayの社内システム開発はスピードと品質を両立できるのか？

なぜ“優秀なメンバー”がTVerを選ぶのか？月間ユーザー数4,120万、今まさに再構築フェーズにあるサービスの舞台裏 民放公式テレビ配信サービス「TVer（ティーバー）」は、創業以来、右肩上がりで成長を続けてきました。2024年12月には月間動画再生数が4.96億回を突破し、2025年1月には月間ユーザー数（ユニークブラウザベース）で4,120万を記録*。名実ともに日本最大級の動画配信サービスのひとつとなっています。<blockquote>*…自社調べ。出典：「<a href="https://tver.co.jp/news/20250109.html" target="_blank" rel="noopener noreferrer nofollow">[TVer] 2024年12月の再生数　過去最高の4.96億回を記録</a>」「<a href="https://tver.co.jp/news/20250210.html" target="_blank" rel="noopener noreferrer nofollow">【TVer】2025年1月の月間ユーザー数 過去最高の4,120万MUBを記録</a>」。</blockquote>一見すると、事業・システム・組織のすべてがすでに整っているように見えるTVerですが、サービスプロダクト本部 副本部長 兼 バックエンド部部長の脇阪博成さんは「課題がたくさんある。むしろその課題こそが魅力でTVerに来た」と語ります。放送局・広告会社出身者に加え、メガベンチャーやスタートアップで実績を積んだ多種多様なバックグラウンドのメンバーが集まる企業。なぜ“優秀なメンバー”たちはTVerを選ぶのでしょうか。脇阪さんに、開発組織の現在の取り組みやこれからの挑戦について話を聞きました。<h2 id="h83cbd36c36">事業基盤が強固、かつエンジニアリングで解決できる課題が多い</h2>――脇阪さんはこれまで、株式会社ディー・エヌ・エーのエンジニアリングマネージャー、株式会社ZOZOの開発本部長、スタートアップのCTOなど、要職を歴任されています。なぜ、次なる挑戦の場としてTVerを選ばれたのでしょうか？前職のスタートアップでは、予算やリソースが限られた中でエンジニア組織の強化を進めていましたが、なかなかうまく成長させることができませんでした。それに加えて入社時に想定していた事業の方向性も変わったため、自身のキャリアを再考し、次なるチャレンジの場を探していました。複数の企業と採用面接を行いましたが、エージェント経由で紹介されたTVerの“課題”に強く興味を持ったことが大きな決め手でした。通常、採用面接では担当者が企業の良い面を話すものですが、TVerは「うちはここができていない」と赤裸々に語ってくれました。――具体的には、どのような課題だったのでしょうか？プロダクトはすでに一定の認知があり、事業の方向性も固まりつつあります。ですが、開発組織はまだまだ発展途上で、「成長を支えるマネジメント人材が足りない」という課題が伝わってきました。前職では、開発組織を大きくできなかったという反省があります。これは自分の力不足でもありますし、事業を軌道に乗せられなかったことも要因のひとつです。TVerはすでにプロダクトの成長が見込める状況にあるため、組織づくりに集中できると考えました。経営陣の多くも「現状に満足せず、さらにプロダクトを成長させたい」と語っており、そこにも大きな魅力を感じました。また、友人や元同僚にTVerの印象を尋ねてみると、「普段から使っているし、良いサービスだけれど、ここを改善してほしい」といった反応が多く寄せられました。ユーザーの生活に根ざしていて、かつ多くの要望がある。つまり、エンジニアリングが力を発揮できる余地がたくさんあるということです。私はもともと、難しい課題を解くのが好きな性格なので、課題の多い環境のほうが面白いと感じます。だからこそ、TVerは自分に合ったチャレンジができる場所だと思いました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/3b8c6d9e4c314222b6e1f4776a24c7de/image3.jpg" alt="" width="1999" height="1334"></figure>――入社後、開発組織ではどのような方針を掲げましたか？「品質とスピードの両立」をミッションとして掲げました。というのも、現在のシステムには古いコードも多く、手を加えると他の部分にバグが発生してしまうケースがあります。その結果、障害が起き、影響範囲の調査や修正対応、場合によっては謝罪対応まで求められることになります。こうした対応により、ユーザーへ価値を届けるまでの時間が長くなってしまう。これが大きな課題でした。そこで現在は、「技術」「組織」「開発プロセス」の3つの切り口で改善を進めています。まず「技術」面では、フロントエンド・バックエンド・インフラのリアーキテクチャに取り組むとともに、自動テストの追加やQAの強化を進めています。QAについては、いわゆる「シフトレフト」を実践し、要件定義の段階から品質やセキュリティを意識しています。次に「組織」面です。これまではプロジェクト単位で人が集まり、終われば解散するという流動的な体制だったため、ナレッジの蓄積が困難でした。今後はチームをある程度固定化し、プロダクトマネージャーやデザイナーも含めたクロスファンクショナルな体制で、チーム単位にミッションを持たせて動く方針に変えています。最後に「開発プロセス」について。以前はプロジェクトの進め方が各メンバーに委ねられていたため、ばらつきによって進行に支障が出るケースがありました。そこで、ドキュメントの標準化や開発プロセスの整備を進めることで、最終的には品質とスピードの両立につなげたいと考えています。<h2 id="hca9f7c9703">現場の裁量の高さゆえに、リアーキテクチャの決断も高速</h2>――それらの改善について、具体的な事例をピックアップしてお話しいただけますか？システムのリアーキテクチャについてお話しさせてください。社内で「枠切れ」と呼んでいる事象があります。これは地上波放送の番組が終了した後、「TVer」で引き続き視聴できる場合に、ユーザーからのアクセスが一斉に集中する現象のことです。これに対して同時接続数を事前に予想し、多めのサーバー台数を立ち上げて待ち構えていたのですが、それでも突発的なスパイクには耐えられなかったり、または逆に想定していたよりもアクセスが来ずコストの無駄が大きくなったりして、この状態を継続するのは厳しいと感じていました。また、アプリケーション内ではパフォーマンス向上のためにキャッシュ処理を導入していたのですが、その処理も次第に複雑化していました。対応方針を考えていたところ、CTOから「より良い設計になるように、作り直したらいいんじゃない？」という提案があったんです。「それ、アリですか？ ではやります！」となり、現場のリーダーたちと集まって方針を議論し、翌週にはリアーキテクチャを直ちに開始することが決まりました。一般的に、ある程度の規模のサービスではリアーキテクチャの決断に至るまでの計画段階で相当な時間がかかります。こうしてスピーディーに動けたのは、TVerの開発組織における柔軟性や現場の裁量の高さが影響しており、大きな方向転換も即断即決で進めることができました。――たとえばインフラがどのように変わるのか、ピックアップしてお話しいただけますか？現状、インフラの技術スタックとしてはAWSのマネージドサービスを主に活用しており、アプリケーションサーバーはAmazon ECS、データベースはAmazon Aurora MySQL、検索にはAmazon OpenSearch Serviceなど、オーソドックスな構成です。ただし、現在のアーキテクチャでは急激なスパイクが発生した際にオートスケールが間に合わないケースがあるため、リアーキテクチャ後はCDNによるキャッシュ構成の導入を検討しています。前述のアプリケーション内でのキャッシュは実装が複雑になるという課題があったので、そちらの課題を合わせて解決するという狙いもあります。CDNキャッシュも万能ではありませんが、「TVer」のトップページは、一部ユーザー向けの出し分けはあるものの、基本的には同一のコンテンツです。だからこそ、キャッシュが効果的に機能すると考え、このようなアーキテクチャにすることに決めました。また、これとは別に急激なスパイクにもスケールが可能なように、インフラ面でのリアーキテクチャも検討しています。<h2 id="h3cc0f74fce">「チームとしての目標がない」状態からの、SREチーム再構築</h2>――他の事例についても教えてください。直近の半年ほどで、組織体制を変更していった事例についてお話しします。私がバックエンド部の部長に就任したのは2024年4月です。就任後しばらくして、SREチームには「チームとしての目標がない」という課題があると感じました。目の前の必要なタスクには対応できていたものの、チームとして何を重視し、どのような状態を目指すのかが明確になっていなかったんです。とはいえ、私自身はもともとSREのバックグラウンドがあるわけではなく、どんな目標を設定すればよいか迷っている状況でした。そんなとき、採用活動に注力していたところ、2024年10月にマネージャー候補のメンバーが入社しました。その方と議論を重ねる中で、「今の組織の状況を踏まえ、まずは品質改善に注力しよう」と方針を決定しました。2024年度の上期に発生したトラブルを、Slackの投稿やポストモーテムの記録から洗い出した結果、半年間で相応の件数の配信トラブルが起きていたことがわかりました。実際には、より小規模な障害も数多く発生していたはずです。サービスの信頼にも関わる部分ですし、一度ここで「血を止める」必要があると感じました。そこで、「配信トラブルを○○件まで減らす」「トラブル発生時の影響時間を○○まで短縮する」といった具体的な目標を立て、その実現に向けて「アラート情報の整理」や「重要情報のログ出力」といったタスクへ落とし込んでいきました。この施策を進めている間、SREチームのリソースが不足し、開発チームからのインフラ関連の要望に応えられなくなる可能性もありました。そこで、開発チームにAWSのIAM権限を付与し、組織全体の生産性に影響が出ないような方針を取りました。――この記事はSRE候補の方も読まれるはずです。そうした方に、どのような役割を期待されていますか？お願いする内容は、その方のスキルセットによって異なりますが、大きく3つの領域があります。1つ目はインフラ構築で、DevOpsチームの強化を進めています。2つ目はオブザーバビリティで、ダッシュボードやSLOの整備が課題です。3つ目はセキュリティで、セキュリティ関連業務の標準化・自動化や、脆弱性対応をリードできる方を求めています。また、インフラだけに特化している方よりも、アプリケーション開発の経験がある方が望ましいですね。TVerのSREチームは、今後ものすごく大規模にする予定はありません。だからこそ、個々のエンジニアの役割を完全に分けるのではなく、必要があれば領域を越境するような体制にしていきたいと考えています。SREのメンバーにも、アプリケーションのコードを読み、ときには修正してPull Requestを出せるような方に来ていただけると理想的です。<h2 id="h6492f2051a">優秀な人たちにとっての「ちょうどいい」チャレンジの場</h2>――ではここから、採用候補者向けの質問です。いわゆるWebサービス系の企業と比べたとき、TVerならではの面白さや特徴があれば教えてください。TVer社内には、放送局や広告会社出身の人や、放送局や広告会社から出向で参画している方が多く在籍しており、一般的なIT企業とは少し毛色が異なるところがあります。一方で、中途採用で入社してきた方々は、メガベンチャー出身者やスタートアップでCTOを務めた経験のある方など、幅広い経歴の持ち主が集まっています。この規模の会社としては人材の多様性が際立っており、それがTVerの組織としての面白さだと思います。サービス面では、ユーザー数の多さがやはり特徴です。日々、フィードバックが山のように届くんですよ。自分たちの取り組みの影響範囲が大きいですし、TVerという会社でしか見えない世界があります。――有名企業を経験してきたような、いわゆる“優秀な人たち”が、TVerに惹かれる理由は何でしょうか？やはり、課題が多いという点に惹かれる方は多いですね。余談ですが、最近入社した開発組織のマネージャーたちに話を聞いたところ、「TVerはいろんな意味でちょうど良い」と言っていました。要するに、組織のサイズやサービスのフェーズが程よく、なおかつ社会的意義のある事業を提供している。それらを魅力に感じているようです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b2e818f622cc4cc3a2e1f12dd1cd52bf/image1.jpg" alt="" width="1999" height="1334"></figure>――どういった要素を持ったエンジニアを、組織としては求めていますか？私が採用基準として重視しているのは、笑顔があることです。これは単にニコニコしているという意味ではなく、「相手とより良い会話をしようという気持ちがあるかどうか」です。良いプロダクトをつくるには、さまざまな方と協力することが不可欠ですから、そうしたやり取りを自然にできる人を求めています。そして、「TVer」というサービスと真剣に向き合い、成長させていきたいという思いがあること。そのために必要な手段は問いませんが、自分の専門領域はしっかり持っている。そういう人と一緒に働きたいと思っています。また、エンジニアはつい「要件をはっきり決めてください」とか「納期はいつですか」と言いがちですが、そうした考え方をしないこと。未確定な要素があるのであれば、みんなで一緒に考えていくというスタンスが大切です。他にも、できればtoCサービスの開発経験がある方が望ましいです。要するに、事業会社で自社サービスを開発・運用した経験があること。受託開発とは異なり、サービスは出して終わりではなく、そこからがスタートです。ユーザーの声を聞きながら改善していく経験が重要だと考えています。――TVerにジョインしたエンジニアが得られる成長機会について教えてください。TVerでは、裁量を持って自ら考え、自ら動くことができます。自分の担当領域にとどまらず、周囲を巻き込みながら動ける。それが大きな成長の機会になると思います。そして何より、社会的な影響力の大きいサービスの中で、それを実践できるという点が魅力です。組織としても失敗を許容しながら前に進む文化がありますし、優秀なマネージャーがそろってきているので、チャレンジしやすい環境が整っています。きちんと自分で動ける方であれば、ご自身が描くキャリアをTVerの中で実現できると思います。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

放送局・広告会社出身者に加え、メガベンチャーやスタートアップで実績を積んだ多種多様なバックグラウンドのメンバーが集まるTVer。
サービスプロダクト本部 副本部長 兼 バックエンド部部長の脇阪博成さんに、開発組織の現在の取り組みやこれからの挑戦について話を聞きました。

なぜ“優秀なメンバー”がTVerを選ぶのか？月間ユーザー数4,120万、今まさに再構築フェーズにあるサービスの舞台裏

1994年に初代のコンソールが発売されて以来、世界中のゲームユーザーから愛される製品となったPlayStation。PlayStation事業に欠かせないものとしてPlayStation Networkがあります。これはPlayStationから接続できるオンラインネットワークサービスであり、世界中のプレイヤーとのオンライン対戦や協力プレイ、デジタル版のゲーム・追加コンテンツの購入・ダウンロード、他のプレイヤーとのやりとりなどが可能。オンラインの強みを活かした機能を有しています。PlayStation Networkは世界でも有数のユーザー数やトラフィック規模を誇るネットワークサービスであり、開発・運用に携わるエンジニアの腕が試される環境です。また、自分たちの作ったネットワークサービスを世界中のユーザーに使ってもらえるという、やりがいの大きい仕事でもあります。今回はPlayStationのハードウェア、ソフトウェアおよびサービスの企画・開発・製造・販売を手掛ける、株式会社ソニー・インタラクティブエンタテインメントの方々にインタビュー。PlayStation Networkにおけるユーザー向けアクティビティサービスのサーバサイド開発のシニアマネージャ―の西海持 雅隆さんとパートナー向けサービスのプロダクトオーナー・チームリードの宗像由さん、パートナー向けサービスのテックリードの半田祐一さん、プッシュ通知やキャッシュ機構のサーバーサイドエンジニアの濱野拓人さんに、プロジェクトの事例や仕事の面白さなどを聞きました。<h2 id="h8e0fd8cb05">ハードウェア・コンテンツ・ネットワークという3本の柱</h2>――ソニー・インタラクティブエンタテインメントの事業の特徴をお話しいただけますか？西海持：ソニー・インタラクティブエンタテインメントは、PlayStationのハードウェア・ソフトウェアおよびサービスの企画・開発・製造・販売を手掛けており、現在は2020年にローンチしたPlayStation 5と2024年に発売したPlayStation 5 Proを重点に提供しています。PlayStationのビジネスにはハードウェア、コンテンツ、ネットワークという3つの重要な要素があります。私たちの部署はネットワークの要素を担当しており、オンラインでのマルチプレイやダウンロードコンテンツなどで付加価値を提供し、新たなユーザー体験を作り出すことが、私たちのビジネスの強みであると考えています。2024年9月30日時点で、PlayStation Networkの月間のアクティブユーザー数は1億1600万人を超えており、相当に規模の大きなネットワークとなっています。――どのような組織体制で開発を行っていますか？西海持：私たちの開発拠点は、グローバル各地に展開されています。本社はカリフォルニア州のサンマテオ市にあり、拠点はカリフォルニア州の別の場所とロンドン、東京をはじめ各国にあります。PlayStation Networkのサービス開発は、グローバルなチームで密にコミュニケーションをしながら進めています。宗像：さまざまな文化・国籍の人が所属していますし、家庭環境もそれぞれ違いますから、すべての人が働きやすいようにダイバーシティ、エクイティおよびインクルージョンの推進にも積極的です。私自身が2児の母なのですが、育児と仕事のバランスを取りながら生活できています。規模の大きな会社ですと「エンジニアの技術的な裁量があまり無いのでは」と思われる読者もいるかもしれませんが、決してそんなことはありません。たとえば、PlayStationの開発に合わせてアーキテクチャを抜本的に変えたことも過去にはありましたし、サーバーサイド開発だけをやっていたエンジニアがインフラにも携わったりするなど、チャレンジの機会が数多くあります。<h2 id="h4aea5ad969">クラウドネイティブなアーキテクチャへの刷新</h2>――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的な意思決定の事例について語っていただいております。みなさんそれぞれから、エピソードをいただけますか？<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/071ab74b0888493699a5a6163e37ea6b/image5.jpg" alt="" width="2000" height="1334"><figcaption>半田祐一さん</figcaption></figure>半田：先ほど宗像から技術的な裁量の話がありましたので、関連する話をさせてください。私の担当する「サブミッション」というサービスは、ゲームを開発するデベロッパー（ゲーム開発者）の方々からゲームパッケージを受け付けて、ファイルの変換処理を行い、世の中にゲーム発売するという一連の流れを担当します。かつては、オンプレミスのサーバーを100台規模で抱え、処理に余裕がなくなればさらにサーバーを購入・調達するという運用を行っていました。この運用はサーバーの物理的な管理が非常に大変なので、アマゾン ウェブ サービス（AWS）のAmazon Elastic Compute Cloud （Amazon EC2）が使えるようになったタイミングで、サーバーのクラウド移行を実施しました。ただ、ここでは単に物理サーバーが仮想マシンに置き換わったというだけで、まだまだ改善の余地がありました。そこで、PlayStation 5がリリースされるタイミングで、クラウドネイティブなアーキテクチャへと刷新することを決めました。アーキテクチャのうち一部分をピックアップして説明しますと、デベロッパーの方々からパッケージを受け付ける箇所はAWS Transferで対応しています。受け取ったパッケージはAmazon Simple Storage Service（Amazon S3）で管理。それらに対してバリデーションやファイル変換などの処理を行うわけですが、そうしたワークフローはAWS StepFunctionsで構築しています。実際の処理は、規模の小さなものはAWS Lambda、規模の大きなものはAmazon Elastic Kubernetes Service（Amazon EKS）で対応していて、スケールしやすい仕組みです。仮に処理の量が増えても、エンジニアがサーバーを増強するなどの対応をする必要はありません。私はこのプロジェクトに携わる前までは、インフラの構築・運用の経験がなかったものの、そうした領域に携わるチャレンジができました。――濱野さんからもアーキテクチャ関連の事例をお願いします。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/747e9b7872114150a031c8d4786b5dd0/image1.jpg" alt="" width="2000" height="1334"><figcaption>濱野拓人さん</figcaption></figure>濱野：私たちのチームはキャッシュサーバーの開発・運用に携わっています。PlayStation Networkには1億1600万人の月間アクティブユーザー（2024年9月30日時点）ユーザーがいますから、もし仮にデータベースのマスタデータに毎回アクセスする仕組みにすると、システムの負荷が高くなってしまいます。そこで私たちは、キャッシュサーバーにマスタデータの情報などを蓄積し、キャッシュを返却する仕組みを構築しています。キャッシュサーバーは歴史のあるサービスであり、もともとはAmazon EC2でAPIを動かし、キャッシュはMemcachedに蓄積していました。ですが、このアーキテクチャですと運用の負担が非常に大きいんですね。そこで去年、アーキテクチャの移設を行いました。Amazon EC2からAmazon EKSに置き換えて、かつキャッシュもMemcachedではなくAmazon ElastiCache for Redisに蓄積する方針を選びました。これだけだと「ただ採用する技術を入れ替えるだけか」と単純な話に聞こえるかもしれませんが、実はそうではありません。このキャッシュサーバーには、10万rpsを超える規模のアクセスがあります。万が一、移設に際してトラブルが起きると影響が大きいんです。――10万rps……。一般的なWebサービスの運用ではまず経験できない規模ですね。濱野：そこで移設前に検証用の環境で本番環境相当の負荷を実際にかけて、問題なくパフォーマンスを発揮できるか負荷試験を行いました。うまく性能が出ない部分については、チーム内外の優秀なエンジニアたちに相談をしたり、サーバー監視サービスで細かくメトリクスを見てパフォーマンスチューニングをしたりして改善を重ね、何十回もの負荷試験を経てようやく十分な性能に達しました。世界中で使われるPlayStation Networkの開発・運用に携わるからこそ、こうした経験を積むことができています。<h2 id="h799f644dfe">各国のチームと力を合わせ、ユーザー体験を改善する</h2>――宗像さんや西海持さんには、組織運営やプロジェクトマネジメントに関することをお聞きします。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/7ab8a0a3bea34320b0bc3096370bcfd7/image3.jpg" alt="" width="2000" height="1334"><figcaption>宗像由さん</figcaption></figure>宗像：「サブミッション」サービスの改善についてお話しさせてください。かつて、初代PlayStationやPlayStation 2の時代にはゲームのダウンロード販売は行っておらず、ゲームを開発するデベロッパーの方々からゲームの情報が入ったDVDなどのメディアを郵送してもらい、納品を行っていました。PlayStation 3になるとデジタル配信を行うPlayStation Storeができて、納品フォーマットもダウンロード用のデジタルデータとディスクといったように種類が増えました。効率的に運用をするために、PlayStation 4ではバラバラだった納品用のパッケージフォーマットを、1つにして提出可能にするプロジェクトを推進したんです。ただ、これでもまだデベロッパーの方々の大変さは軽減されていませんでした。それはどういうことか説明すると、世の中はグローバル化が進んでおり、PlayStationで遊べるゲームも世界の複数の国で発売されるケースが増えています。過去の「サブミッション」サービスはそれぞれの国・地域ごとにシステムが分かれており、複数の場所でゲームを販売したければそのすべてに納品用のパッケージを作成し、提出する必要がありました。また、国や地域によって法律なども違うので、ゲームそのものの中身を変える必要も生じます。――かなり煩雑な対応が求められたわけですね。宗像：そこで、PlayStation 5からは、日本だけではなく世界各国の拠点とも連携を取りながら、運用を効率化できるよう、システムの仕様を考えていきました。この事例が典型的な例なのですが、私たちは日常的に国内外のメンバーとコミュニケーションを取りながらプロジェクトを進めます。多種多様な人たちと働きたいとか、グローバルで使われるプラットフォームを開発したいという方には、すごく適した環境です。また、ゲームのエンドユーザーだけではなくゲームを開発するデベロッパーの方々にとっても、使い勝手が良くユーザー体験に優れたシステムの提供を目指しているのも、大きな特徴になります。PlayStation 4では、デベロッパーの方々は3カ国でゲームを販売する場合に3種類のパッケージを作成する必要があったのが、PlayStation 5からはゲーム情報の共通部分と各国の差分をまとめたファイルを1つだけアップロードする、より効率的な仕組みになりました。――西海持さんはいかがでしょうか？<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/50019bf1ecb54eccb0a16ecd7201fc34/image2.jpg" alt="" width="2000" height="1334"><figcaption>西海持 雅隆さん</figcaption></figure>西海持：PlayStation 5のホーム画面でコントローラーのPSボタンを1回押すと、画面の下にメニューが表示されます。これはコントロールセンターという機能なのですが、このなかにユーザーがどのような行動を取れるかを示すアクションカードがあります。PlayStation 5のリリース前の段階で「PlayStation Networkでイベントが発生してから、アクションカードに反映されるまでの速度を速くしたい」という要望が、社内で挙がりました。目標となった時間は具体的な数字はお伝えできないのですが、ユーザーの快適さを実現するために野心的な数字を目標値としています。この数値を改善するのはかなり大変でして、なぜならアクションカードへの反映までに複数のチームのシステムが関与しているからなんです。イベントを発行するシステムや、それをリソースに反映するシステム、そのイベントを誰に届けるかを判定するシステム、プッシュ通知によってユーザーに情報を知らせるシステム、実際にユーザーのアクションカードに情報を届けるシステムなどがあり、それらを別々のチームが開発・運用しています。このプロジェクトにおいてソニー・インタラクティブエンタテインメントの強さを感じたのが、それぞれのチームが自己組織化されているということです。アーキテクトが実現したい目標について共有し、方針策定をしたところ、特定のメンバーだけではなくみんながオーナーシップを持って「このような方法があるのではないか」というアイデアを提案し、改善を続け、最終的には無事に目標数値を達成できました。<h2 id="h2961ca933b">エンジニアの仕事を通じて世界中にインパクトを与えられる</h2>――ソニー・インタラクティブエンタテインメントでは、サーバーサイドエンジニアを積極的に採用していると伺っています。優秀なエンジニアにとって、PlayStation Networkの開発・運用に携わる面白さはどのような点にあるでしょうか？濱野：今回の事例でもインパクトのある数字がいくつか出てきましたが、これほど規模の大きなデータやトラフィックを扱える会社はあまり多くはありません。それから私が入社して感じたのは、これはエンターテインメントの会社であることも影響しているかもしれませんが、優秀かつフレンドリーな方が多いということです。困ったときはみんなでアイデアを出し合うので、チーム全体で成長して成果を出す文化が醸成されています。西海持：システム開発だけではなく、ビジネス環境の変化もすごく速いです。変化を受け入れて、それを楽しめる人にとってはすごくおすすめです。また、自分のやった仕事が真の意味で世界中にインパクトを与えられるのは貴重な体験ですね。そして私にとって何より大切なポイントは、妻もゲームが好きなので、私たちが何かを作るとそれを家族に喜んでもらえるということです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/a5a49a0abf1e4d1c82a248307123a752/image4.jpg" alt="" width="2000" height="1125"></figure>――ソニー・インタラクティブエンタテインメントならではの魅力がたくさんありますね。では最後に、御社への応募を考えている方に向けてメッセージをお願いします。半田：新しい技術を積極的に取り入れて、自分たちのサービスをさらに改善しようという思いを持ったエンジニアたちが働いています。優秀で向上心を持った方と、一緒に働いて成長していきたいです。宗像：この会社ではフルスタックな開発が経験できますし、先ほどの話にもあったようにグローバルで密に連携を取りながらものづくりができます。私もそうであるように、多種多様なライフスタイルの方が働きやすい環境がありますし、各々の意見が重視される文化も魅力的です。濱野：PlayStation Networkのように、世界規模で使われるネットワークサービスの開発は非常に面白いです。自分の携わった仕事が世の中に影響を与えていると実感できるので、興味を持たれた方はぜひ応募してみてください。西海持：みなさんが言ってくれたように、この会社だからこその魅力があり、そこに共感していただける方と一緒に働きたいです。エンジニアとしてチャレンジしたいこと、今後のキャリアで実現したいことがあるならば、ぜひ力を発揮する場所としてソニー・インタラクティブエンタテインメントを選んでください。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

PlayStationのハードウェア、ソフトウェアおよびサービスの企画・開発・製造・販売を手掛ける、株式会社ソニー・インタラクティブエンタテインメントの方々にインタビュー。プロジェクトの事例や仕事の面白さなどを聞きました。

月間アクティブユーザー数・1億人以上。世界規模のネットワークサービス開発の妙味

登録ユーザー数6,700万人以上*。日本の人口の約2人に1人以上が利用するキャッシュレス決済サービス「PayPay」は、いまや「生活に欠かせないインフラ」と言えるほどに普及しています。加えて、決済にとどまらずクレジットカードや銀行、証券、保険などを「PayPay」ブランドに統一し、金融Platformとして事業を拡大しているのです。そんな「PayPay」の特徴として、社内システム開発組織であるシステム本部の強さがあります。社内業務システムの開発・運用や各種ツールの導入、コーポレートIT業務などを担うこの部署は、企業の体制強化をけん引し、事業成長を支えてきました。また、フルクラウドのインフラ構築や業界最先端技術によるeKYCシステムの開発、AI・機械学習やデータ分析、ローコード開発プラットフォームを活用した高速アプリ開発など、数々の技術的な挑戦も続けています。PayPay株式会社のCIO Product統括本部 システム本部長 兼 システム本部 AI活用推進室長である岡田寛史さんに、部署の魅力やこれまでの事例、今後の展望を聞きました。*…2024年12月末時点。<h2 id="h72ffa142a7">社内システムの改善を通じて、事業の成長を支える</h2> ――システム本部の構成や、各部署の役割について聞かせてください。システム本部のなかには、Corporate IT部とSystem Development部、PMO部、System Platform部、SFA&amp;CRM部、Data Management部、AI活用推進室、IT戦略室という8つの部署が存在しています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/7352cc1b0c0f4f6991afaf3395abc5d9/%E7%B5%84%E7%B9%94%E5%9B%B3.jpg" alt="" width="1200" height="648"></figure>Corporate IT部は社員が使用するPCやiPhoneなどのデバイスキッティングや社内の問い合わせ対応、会計/人事システムの構築運用、各種SaaSツールの導入・運用といった、全従業員が使用するツールやコーポレート業務に必要なツール機能を提供するうえで必要な仕事をしています。System Development部は社内で使用する業務系システムの開発・運用を担います。インフラはAWS・GCP、主なプログラミング言語はJavaを使用して、各部門のニーズに合ったシステムを作る部署です。PMO部はSystem Development部が着手する案件のロードマップ策定やプロジェクト推進を行います。System Platform部は、いわゆるSREの役割でありシステムの信頼性や可用性に責任を持ち、マルチクラウドで構成された各種のインフラを管理しています。SFA &amp; CRM部はSalesforce活用を推進する部署です。PayPayでは大きく分けて、2種類の業務でSalesforceを使っています。まず、「PayPay」の加盟店を開拓する営業社員が営業活動を記録する用途。そして、「PayPay」のユーザーや加盟店からの問い合わせを管理するCS用途です。Data Management部は全社データ分析基盤の構築・管理、AI活用推進室は生成AIを用いた社内システム/ツールの開発や利活用推進、IT戦略室はITガバナンスの策定・実行、コストコントロールなどを担います。――システム本部は、2024年9月以前はコーポレート統括本部に属する組織でしたが、2024年10月よりProduct統括本部の配下に移られたと伺っています。この変更にはどのような理由があったのでしょうか？PayPayが設立されたのは2018年6月で、まだ人間で言えば6歳の会社です。そして、私が入社したのは2019年で、当時はまだコーポレート機能を提供するためのツールや仕組みがほとんど整っておらず、会社の成長を支えるためのシステムを早急に整備する必要がありました。参考 : <a href="https://insideout.paypay.ne.jp/2022/09/26/leader-interview_vol07-jp/" target="_blank" rel="noopener noreferrer nofollow">CIOが語る PayPayの事業スピードを支える社内業務システム開発</a>ここのところ、そうした社内基盤の整備にある程度の目途がついてきました。そして最近は、PayPayプロダクト開発チームと連携をするようなシチュエーションが増えています。たとえば、「PayPay」のユーザー情報やトランザクション情報をプロダクトインフラから安全な形で共有してもらい、システム本部側で審査アプリケーションに利用する、などです。そこで、プロダクトとの連携をより強化しようということで、2024年10月から体制を変更しました。――社内の業務からプロダクトとの連携まで、幅広い領域をカバーする部署なのですね。そうですね。他にも、システム本部の特徴として内製化へのこだわりが挙げられます。PayPayは創業当初から「事業のコアになる部分は内製する」という意識が強く、システム本部も同じような考え方をしてきました。スピードを意識した事業展開と「まだ世にないサービス」を創ることに本気な会社だからこそ大切にしている考えです。そして、2018年創業の新しい会社ということもあり、積極的にモダンな技術を採用しているのも特徴です。もちろん、内製よりも既存のSaaSを導入したほうが利点が大きい領域もあるので、そうした場合は積極的に活用しており、その方針は都度判断しています。また、最近ではPayPayカード株式会社が2022年10月にPayPayグループの一員になりましたが、私たちよりも会社としての歴史が長いため部分的にレガシーシステムも残っています。そこで、システム本部のメンバーたちにPayPayカードへと出向してもらい、先方のエンジニアとともにアーキテクチャ刷新などの技術的な改善を推進しているところです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5109fabbf2dd468484b52d2e2c8bd4eb/image1.jpg" alt="" width="1999" height="1334"></figure><h2 id="h0296da4ef9">eKYCのリードタイムを数日→数分に短縮。セキュリティ・パフォーマンスの両方が求められた</h2>――システム本部では、積極的に新しい技術を取り入れているということですが、その特徴が表れているようなプロジェクトの事例はありますか？eKYCの審査システムについてお話しします。免許証の画像などを用いる従来型の本人確認のプロセスでは、免許証に記載されている顔写真と、本人が提出したセルフィー画像を比較することで、提出者が本人であるかを確認します。この写真の真贋判定に画像認識のAIを用いたり、免許証の住所・氏名の画像情報をテキストに変換する処理にAI-OCRを用いたりといったことを創業間もない頃から行ってきました。これに加えて、マイナンバーカードのICチップに格納された情報を利用するeKYC審査システムを3年ほど前に構築しました。先ほど述べた従来型では、本人確認プロセスの一部にサードパーティー製のシステムを使用していました。業務プロセスやシステムの制約上、審査のリードタイムが数日ほどと長くなっており、ユーザーのみなさまにご不便をおかけしていたんです。そこで、ICチップ読み取り方式のシステムを業界に先駆けて導入し、本人確認リードタイムを短縮する方針にしました。この審査システムではプロダクト側のデータやインターフェース連携も必要でしたので、部署をまたいだコラボレーションが発生するプロジェクトでした。また、「PayPay」のユーザー規模は膨大なので、サーバーの負荷対策や冗長化、クエリ最適化などの細かなチューニングも行う必要があり、技術的にもチャレンジングだったと感じます。加えて、eKYCで受け取るユーザーの個人情報というのは機密性が非常に高いデータですので、厳格に管理をする必要があります。そこで、プロダクト側が管理しているセキュア環境にデータを保持し、システム本部のアプリケーションから安全に情報連携できるようなアーキテクチャを構築しました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/1d158cead2a5464e90d6a4c1bff7b8e5/image2.png" alt="" width="1189" height="538"></figure>①本人確認の申請②オペレーターによる審査③確認書類はセキュアな環境にデータを保持④AIによる審査プロセスの自動化このシステムによって、本人確認プロセスの審査リードタイムは数日から数分に短縮できましたし、この事例以降はプロダクト側と連携しながら機微なデータをセキュアに管理しながら、連携先システムで安全に業務活用するケースが増えています。<h2 id="h8045541ade">eKYCを軸とした、新サービス開発を支える業務システム作り</h2>また、「PayPay」の本人確認済みユーザーは現在3,200万人（2024年11月時点）を超えていますが、2024年2月からはこの「PayPay」アプリの本人確認済み情報と連携することで、「PayPay銀行」と「PayPay証券」の口座開設手続きが大幅に改善する<a href="https://about.paypay.ne.jp/pr/20240205/01/" target="_blank" rel="noopener noreferrer nofollow">ユーザー体験を実現</a>しています。これは、システム本部の開発した業務システムがPayPayグループのユーザー獲得に貢献できている、象徴的な機能だと思っています。加えて2024年8月から、寄付団体や寄付サービス運営企業が「PayPay」の法人向けビジネスアカウントを開設し、本人確認済みユーザーが<a href="https://about.paypay.ne.jp/pr/20240819/01/" target="_blank" rel="noopener noreferrer nofollow">オンライン寄付を行うことができる</a>ようになりました。さらに、2024年12月からは一部の神社や寺院などでの<a href="https://about.paypay.ne.jp/pr/20240819/01/" target="_blank" rel="noopener noreferrer nofollow">お賽銭でも利用できる</a>ようになりました。システム本部は、こうした一連の新サービスをユーザーに安心してご利用いただけるようにするための、企業や団体に対する厳格な審査業務や取引モニタリング、不正検知などを行うための業務システムの開発にも深く関わっています。こうした例はほんの一部ですが、いままでなかった新サービスをユーザーに届ける機会に直接的に関われることは、技術者として本当に幸せなことだと思います。<h2 id="hefdf1ec41d">生成AIを活用し、データ分析や営業業務の最適化を行う</h2>――業務プロセス改善を実施した別の事例はありますか？2年ほど前から、業務への生成AIの導入を積極的に行ってきました。生成AI活用による全社横断のプロジェクトを発足させ、各部のメンバーたちに参加してもらいました。そのうちシステム本部のメンバー数名が開発を担当し、それぞれの部の意見を聞きながら、各部のユースケースをもとにシステムを作っています。社内システムは「作って終わり」ではなく現場とのコミュニケーションを通じた改善でなければならないので、一体感を大事にしました。――すでに実現できているシステムについて、詳しく教えてください。Slackでの投稿を経由してLLMのAPIを呼び出し、DWHやRAGに格納された各種の社内データを参照して回答を返す仕組みを構築しています。営業社員が調べものをする際にSQLすら書く必要がなく、Slackで「○○店の2024年の売り上げを月次で知りたい」とか「○○に提案営業したいのですが、最適な営業ルートを教えてください」などと投稿するだけで、適した答えが返ります。現在はさらに、Salesforceの画面から生成AIアプリケーションを直接利用して業務効率化を図る仕組みを構築しています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/803ba15709e74b51be53689311b48ada/image3.jpg" alt="" width="1999" height="1334"></figure>――積極的に業務改善に取り組まれているのですね。これはPayPayの企業文化ですね。ご存じの方も多いかもしれませんが、PayPayは創業以来、とてつもないスピードで加盟店や利用者の数を増やしてきました。組織の成長よりも事業の成長のほうが圧倒的に伸び率が大きいんですよ。だからこそ、業務を常に効率化していかなければ、事業グロースの足枷になってしまいます。一方で、新しい仕組みの導入のような攻めの施策だけではなく、セキュリティを堅牢にするための守りの施策も絶対に手は抜きません。我々が扱っているのはお客様の大事な金融資産やデータなので、高いセキュリティ水準が求められます。その両方に決して手を抜かない、ユーザーが安心して使っていただける社会インフラの構築を体験できるのは、PayPayならではだと思います。<h2 id="h3ceb8f3971">日本のIT企業で、これほど恵まれた環境はそうそうない</h2>――岡田さんは、システム本部のメンバーを採用する際に、どのような要素を大事にしていますか？技術や専門性のマッチングは現場の部長陣の意見を信頼していますので、私はどちらかといえばカルチャーフィットやメンタリティを見ています。具体的には、背中を預けても大丈夫な人かどうか。たとえば、過去のプロジェクトで課題に直面したときや、失敗したプロジェクトから何を学んだかといった、ハードシングスに直面した時の行動や反応を確認するようにしています。なぜかというと、新しいことに挑戦するプロジェクトでは、トラブルは少なからず起こるんですよね。だからこそ、ある程度の失敗を受け入れつつも、被害を最小限に食い止めるために何をするか、それを次の機会にどう生かすかが大事だと考えています。それに、私はメンバーに対していつもややレベル高めのボールを投げるので、難易度の高いプロジェクトであっても前向きにがんばれる人であってほしいです。――岡田さん自身は、いま何に挑戦していますか？PayPay単体だけではなく、クレジットカードや銀行、証券、保険などの関連グループ会社を横断した金融エコシステムを最短最速で作り上げるための土台づくりとは何か？が、私にとって最大の関心事です。異なる企業同士で連携するのは大変なことも多いんですが、実現できればビジネスがグロースするのは間違いないと信じているので、やりがいを感じています。――エコシステムとは、具体的に何を実現できるのでしょうか？たとえば、「PayPay」のデータがあれば、人々がいつ、どこで、いくらの決済をしたかというお金の流れがわかります。これに加えて先日リリースされた給与デジタル払い対応サービス「<a href="https://about.paypay.ne.jp/pr/20241105/01/" target="_blank" rel="noopener noreferrer nofollow">PayPay給与受取</a>」はお金の入り口になります。つまり、お金の入り口から出口まで、一気通貫でデータがPayPayに集まるんですね。しかし、私たちはまだそれらのデータを十分に活用できていません。これらを用いれば、ユーザー1人1人に応じた金融サービスの提供が可能になります。そうすれば、新しい金融サービス体験ができるでしょうし、5年後・10年後にはいまとは違う世界観が広がっているはずなんです。そんな未来をいち早く実現したいと考えています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b207ad57e2f4478aaebb2a4497de609f/image2.jpg" alt="" width="1999" height="1334"></figure>――単なる決済サービスという枠組みを超えて、金融の未来をつくるような仕事ですね。最後に、これからPayPayの求人に応募したいと考えている方々へメッセージをお願いします。システム本部の仕事は、圧倒的なユーザー基盤を持っている「PayPay」というサービスを、業務システム開発やコーポレートITなどの仕組み作りでサポートできるのが醍醐味です。社会に対してインパクトの大きい事業に関われます。また、今回のインタビューではあまり触れませんでしたが、PayPayはとても国際色豊かな環境でもあります。プロダクト側の開発組織のメンバーは、8割ほどが外国籍なんです。事業やデータの規模が大きく、求められるシステムの品質も高い環境で、グローバルなエンジニアたちと切磋琢磨して働くことで、自分の市場価値を高められるはずです。そういう意味では、日本においてこれほど恵まれている職場はそうそうないんじゃないでしょうか。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

PayPay株式会社のCIO Product統括本部 システム本部長 兼 システム本部 AI活用推進室長である岡田寛史さんに、部署の魅力やこれまでの事例、今後の展望を聞きました。


生成AIやデータ分析も取り入れた内製開発の魅力。PayPayの事業成長を支える社内業務システム

「生きるに、遊びを。」をミッションとし、日本最大級の遊び予約サイト「アソビュー！」やレジャー業界のDXを推進するSaaS「ウラカタ」シリーズなどを提供するアソビュー株式会社。同社の開発組織の人数は、1年半前と比較して1.5倍の約100人となっています。また「アソビュー！」の累計会員数は1,000万人を突破し、サービスの規模も大きくなっているのです。開発組織やサービスを成長させるうえで、アソビューではどのような工夫をしているのでしょうか。VPoT 技術本部副本部長 技術戦略部部長の兼平大資さんに聞きました。<h2 id="h61de5f0b86">全員が「フルサイクルエンジニア」であるために</h2>――兼平さんは2023年までVPoEの役割を担われていましたが、2024年からはその役割を服部毅保さんにバトンタッチされ、ご自身はVPoTになりました。この経緯からまずはご説明ください。もともと、私がVPoEをしていたのはCTOの江部さんからの依頼がきっかけでした。開発組織がだんだんと大きくなっていくなかで、江部さんから「開発組織の全体を見てもらえないか」と声をかけられたんです。それを受けて、VPoEとテックリードを兼任しつつ働いていました。そこから数年が経ってアソビューの開発組織は100名規模になり、このまま私が兼務でVPoEを担当するよりも、他の誰かに専任で任せたいと思うようになりました。服部さんは人や組織を見ることに長けているので、彼にVPoEを任せて私はVPoTとして技術面を見ることに注力すると決めました。――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的な意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。前提としてアソビューが重視していることをお伝えすると「顧客の課題を解決すること」「ユーザーの方々に喜んでいただけること」が大切だとみなが思っていて、私たちマネジメント層は「エンジニアに、その思いをいかにして仕事で実現してもらうか」を考えています。しかし、開発組織の規模が大きくなるとタスクが徐々に細分化されていき、「目の前の仕事をやっていけばいい」と個別最適化が起こってしまいます。そうではなく、エンジニア個人が事業やユーザーのことを俯瞰して捉えて、全体最適の動きができることが重要です。そこで、CTOやエンジニアリングマネージャーたちと話し合って決めたのが「アソビューのエンジニアには、フルサイクルエンジニア*になってもらいたい」というビジョンでした。*…設計や開発だけでなく顧客への価値提供が仕事であると捉え、運用とサポートを含めたサービスライフサイクルの一連のタスクすべてを担うエンジニアのこと。――フルサイクルにするために、どのような制度や仕組みを構築していますか？具体的な施策についてはこれから整備していくところですが、いまはエンジニアリングマネージャーには各メンバーに「フルサイクルエンジニアを目指す意義」について伝えてもらい、意識付けをしています。この先の目標としては、メンバーの何割かに定期的なジョブローテーションをお願いして、開発組織のなかでいろいろなポジションを経験してもらおうと考えています。そうした施策が最終的には、事業やユーザーのことを考えられるエンジニアを増やし、組織が継続して成長することにつながります。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/846369e60d874a5ab29e4126b5ceab9b/image2.jpg" alt="" width="1999" height="1334"></figure><h2 id="h02d5dfb346">3種類のSREがサービスを支える</h2>――他の事例についても教えてください。私たちの開発組織にはService SREとPlatform SRE、Embedded SREという3種類のSREが存在しているのですが、その経緯や意図をお話しします。私たちが事業を開始してシステムの開発を始めたばかりのタイミングでは、エンジニアは細かな役割に分かれておらず、全員がどんなタスクでも担当していました。そして、だんだんと事業が成長してエンジニアが20～30名ほどになり、「アソビュー！」や「ウラカタ」などのユーザーや契約施設も増え、「サービスの信頼性を高めよう」という流れになったんです。そこで、約6年前に独立した専門のSREチームを設立しました。これによりサービスを安定して運用できる体制にはなったものの、一方でDevとOpsが分離しているという、ありがちな問題が生じてきました。SREがプロダクトの課題を理解して最適解を見つけることが難しいとか、逆に開発チームから見るとインフラやCI/CDがブラックボックスになりやすいという傾向にあったんです。そのため開発チームから有志を募り、業務時間を10%程度使って開発チームとSREチームの橋渡しを行ってもらうEmbedded SREを設置し、SREチーム+Embedded SRE体制に移行しました。こうして、開発チームとSREチームとの間の情報連携やシステムの全体最適化の促進ができるようになったんです。その後、さらに運用体制を強化するためService SRE+Platform SRE+Embedded SREという体制に変化しました。これにも理由があり、事業やシステム、開発組織が成長していくにつれ、可用性・セキュリティ向上、開発生産性の改善、アーキテクチャ最適化などの多種多様なタスクをすべてSREチームが抱えて、負担が大きくなっていたんです。そこで、開発生産性や長期的な課題を解決することをミッションとしたPlatform SREチームと、システムの信頼性を高めることにフォーカスしたService SREチームとに、チームを分離することにしました。――アソビューはかなり柔軟にSREの体制を変化させていますが、どのような考え方をすればこうした体制変更を実現できるでしょうか？課題をどのように捉えるかと、将来像をどう考えるかが重要だと思っています。ここで言う“課題”には顧客の課題や社内のメンバーが抱える課題など、複数の種類があります。それらのフィードバックを常に得ながら、「どのような状態になれば解決し得るのか」を考え続けていくことです。そして、社内だけではなくて社外からのインプットを増やし続けることも大切です。たとえば、今回のインタビューで出てきたようなフルサイクルエンジニアやプラットフォームエンジニアリングなどの概念も、もとは他社が提唱し始めた概念です。それを、自分たちの開発組織に適用するためにはどうするかを考えたうえで、現在のような仕組みにしています。＜参考記事＞<a href="https://tech.asoview.co.jp/entry/2024/04/12/090000">アソビューを支える3つのSRE。それぞれの専門性を活かすための組織体制</a><h2 id="h3c439f51b9">守りの施策に振り切った可用性向上プロジェクト</h2>――他にはどのようなエピソードがあるでしょうか？2021年から2022年5月にかけて取り組んだ、可用性向上プロジェクトの話をさせてください。2021年は、サービスが高い成長率を維持しており、契約している事業者の数も商品数もアクセス数も順調に伸びているタイミングでした。しかし、それに伴ってシステムの障害が多発するようになり、利用者にご迷惑をおかけする事態になっていたんです。それまで私たちの会社は、事業成長していくための「攻めの施策」が中心でした。しかし、この事態を重く捉えて、事業推進関連の施策をいったん止めて開発チーム全体で半年かけて可用性向上に総力を上げることにしたんです。サーキットブレーカーの設置やCDNの利用拡大、SQLの性能劣化の検知、システムのデプロイ速度を向上させることによるリカバリ速度向上など、複数の施策を同時に推進しました。――記事を読まれる方々のなかにも、システムの可用性向上のために何らかの対策を講じなければならない立場の人もいるはずです。この事例を踏まえて、伝えたいことはありますか？費用対効果を考えるということを挙げたいです。このプロジェクトは「半年間でやりましょう」という期限が決まっていたので、開発チーム全体で取り組むとはいっても実施できることは限られていました。そこで、手当たり次第にいろいろな施策に手を付けるのではなく、システムの可用性を維持するうえで問題になりやすい箇所と、それに対応するための選択肢があるかを初期フェーズで洗い出したんです。それらにかかる工数や、実現した場合にどれくらい可用性が上がるかを鑑みて、費用対効果の高いものからやっていくという進め方をしましたね。その結果、対応してから現在まではかなり安定してサービスを運営し続けられています。サービスのトラフィックは毎年1.5倍のペースで増加していますが、それでも障害は発生しにくくなりました。それから副次的な効果として、開発チーム全体で取り組んだプロジェクトだったことから、エンジニア一人ひとりにサービスの可用性や信頼性を大切にする意識が根付いたのも大きかったです。＜参考記事＞<a href="https://tech.asoview.co.jp/entry/2022/12/25/092015" target="_blank" rel="noopener noreferrer nofollow">分間約50,000リクエストに耐えられるように、可用性向上に全集中した話。開発チーム全体で半年かけて挑んだ改善</a><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/fd76197d815f42a5addf1bda75de7089/image1.jpg" alt="" width="1999" height="1334"></figure><h2 id="h2ad04e6c4c">集約と分散をコントロールする</h2>――他にはどのような事例がありますか？モジュラモノリス化やMonorepo化についてお話しします。アソビューのシステムはモノリスなアーキテクチャから始まって、会社が成長するに伴って新規事業を立ち上げる際には、システムも新規に構築してきました。そして、さらに事業や組織が拡大するにつれて、よりアジリティを向上させるためにマイクロサービス化を推進したんです。これは短期的には成長に効果的だったものの、サイロ化の促進や全体最適化の難易度の上昇など、複数の問題が発生するようになりました。また、マイクロサービス化に伴っていくつもリポジトリが作られ、最も多い時期には120個ほどにまで増えていました。それだけたくさんあると、メンバーがシステムの全容を把握するのも困難になってしまいます。私たちがモノリスとマイクロサービスの運用を経験して学んだのは「集約と分散をうまくコントロールするのが重要」ということでした。 そこで私たちは、モジュラモノリスへのアーキテクチャ変更を進めました。モジュラモノリスは、デプロイするアプリケーションは1つであるものの、システム内部は複数のモジュールに分割されています。マイクロサービスの抱えていた課題の多くを回避しつつも、システムの集約・分散を適切に管理しやすいという利点があります。また、これに伴って山ほど存在していたリポジトリも1つに集約し、Monorepo化も進めました。＜参考記事＞<a href="https://tech.asoview.co.jp/entry/2021/12/05/000000">マイクロサービスによって起こったサイロ化に対する取り組み</a><a href="https://tech.asoview.co.jp/entry/2022/12/23/095914">3ヶ月で120のリポジトリを1つのMonorepo(モノレポ/モノリポ)に移行した話</a><h2 id="hcba1773ce2">「顧客の課題を解決する」意識が強い会社</h2>――今回のインタビューの内容を踏まえて、「アソビューの開発組織の良さ」はどのような点にあると思われますか？私は個人的に、「顧客の課題を解決しよう」という意識を、エンジニア一人ひとりが非常に高いレベルで持っているのが良さだと思っています。採用するうえでも、そこを重視しているんですよね。だからこそ、何かの方針を考える際にメンバー同士の目的意識が揃いやすいですし、共通認識を持ったうえで「どのような方法を取ろう」とか「どのような技術を使おう」と話し合えるのが強みだと思います。――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？そうした事例は、成功した内容だけではなく背景にあった課題や失敗なども含めて公開されていることが多いです。私たちのシステムや開発組織は、もちろん独自の部分もあるんですが、他社のシステムや開発組織と似ている部分もたくさんあります。だからこそ、他の人々がどのような課題を抱えていたか、どう解決したかを知るのは、自分たちの事業をより成長させていくうえで非常に役立つと思っています。そうした知識を得ておくことで、自分たちが同じような課題に直面した際、解決するためのひとつの選択肢になります。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

開発組織やサービスを成長させるうえで、アソビューではどのような工夫をしているのでしょうか。VPoT 技術本部副本部長 技術戦略部部長の兼平大資さんに聞きました。

SRE強化・可用性向上・モジュラモノリス化。アソビューの事例から開発組織拡大の知見を学ぶ

開発組織が採用するプログラミング言語やアーキテクチャ、組織構造には、企業の経営方針やビジネスモデルが反映されるケースが多いです。たとえば「マルチプロダクト展開をしたい」「特定事業を短期間でグロースさせたい」といったコンセプトを掲げているならば、それに適した技術選定や組織設計が行われるのです。「飲食をもっと楽しくおもしろく」というミッションのもと、飲食店向けのモバイルオーダーやID-POSを開発・提供する株式会社dinii（ダイニー）も、事業やプロダクトを成長させるために適切な技術や組織構造を選択してきた企業。これまで取り組んできた意思決定について、取締役CTOの大友一樹さんとエンジニアリングマネージャーの浦山裕史さんに聞きました。<h2 id="hada982814d">飲食店向けに幅広いサービスを提供する</h2>――diniiが提供している事業について教えてください。大友：当社は主に飲食店向けのサービスを提供している企業です。モバイルオーダーPOSの「ダイニー」が主力サービスですが、それ以外にも飲食店経営者が直面するさまざまな課題を解決するとか、飲食店を利用する消費者がより良い体験を得られるようにするためのサービスも幅広く提供しています。たとえば、POSレジシステムやスタッフが使用するハンディ端末、キッチンでの注文内容を表示するプリンター、最近では決済サービスも提供しています。また、私たちは「ダイニー」を通じて飲食店に来店した方の情報を収集できるため、そのデータをもとにしたCRMシステムも提供しています。diniiは飲食店での各種業務をテクノロジーで総合的に支援する会社です。――他社製のモバイルオーダーサービスと比べて、「ダイニー」の特徴はどのような点にありますか？大友：当社のモバイルオーダーサービスの特長は、消費者の体験を重視して開発しているところにあります。他社サービスの場合、注文を自動化・効率化することのみにフォーカスしていることがほとんどですが、私たちのサービスは画面の使い勝手が良く、メニューのおすすめをしたり来店回数に応じて特典を提供したりと、消費者が楽しみながらモバイルオーダーを使用できる点が高く評価されています。また、「ダイニー」ではモバイルオーダーの利用と同時に、消費者が店舗の会員となります。これにより、性別・生年月日・来店回数・最終来店日・よく注文するメニューなど会員の細やかな属性情報を取得できます。こうした点は他のサービスでは実現できていない、「ダイニー」固有の特徴になっています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b058927503034fe2a3cee878a8891809/image3.jpg" alt="" width="1999" height="1334"><figcaption>大友一樹さん</figcaption></figure><h2 id="h093697bd96">採用技術をTypeScriptで揃える</h2>――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。大友：私たちは合計で20種類くらいのサービスを提供しており、そのすべてをTypeScriptで開発しています。フロントエンドやバックエンド、モバイルのいずれもTypeScriptであり、かつバックエンドはHasura*などを用いてGraphQLのAPIを構築しています。「エンジニアがフルスタックにどの領域でも担当できること」を重視した技術選定が特徴です。*…dinii社のメンバーは「<a href="https://hasura-tokyo.connpass.com/" target="_blank" rel="noopener noreferrer nofollow">Hasura User Group Tokyo</a>」の運営にも携わるなど、Hasuraのコミュニティ活動も積極的に行っています。――なぜ、このような技術選定にしたのでしょうか？大友：diniiでは創業当初から飲食業という事業ドメインのなかで、テクノロジーを用いてさまざまなチャレンジをしてきました。そして、どのような事業を行う場合でも複数のシステムを開発します。たとえば、テイクアウトやデリバリーの注文ができるプラットフォームを実現する場合には、最低でも消費者側と店舗側の2種類のシステムが必要です。事業をスタートしたばかりの頃はすべてTypeScriptではなく、例を挙げるとモバイルアプリはAndroid・iOSそれぞれのネイティブアプリとして作っていました。ですが、今後もさらにシステムが増えていくならば「極力、採用する技術を統一したほうが良いだろう」という見立てをしていたんです。そこで、事業が一定以上に成長しそうだと見越したタイミングで、あらためてTypeScriptで全面的に書き直しました。――モバイルアプリのシステム移行にあたり、工夫したことはありますか？大友：Android・iOSのネイティブアプリとして作っていたものをReact Native・TypeScriptに書き換えたんですが、全機能を実装するまではある程度のリードタイムがかかります。書き換えを完全に行ってから「この機能が不足している」とか「使い勝手が良くない」となるわけにはいかないので「可能な限り早めのタイミングでサービスへのフィードバックをもらうこと」を重視しました。具体的には、モバイルアプリを導入している店舗に検証作業のお手伝いをお願いし、1日のうち数時間だけReact Native・TypeScript版を使っていただいたうえで改善すべき点をフィードバックしてもらうという運用を行っていました。実店舗での検証を日々行いながら、移行作業を進めましたね。――採用言語をTypeScriptに統一していることで、組織としてプラスになっていることはありますか？大友：エンジニアがさまざまな領域をフルスタックに担当できることは強みになっています。私たちのサービスの場合、たとえば「モバイルオーダーで⚪︎⚪︎をしたらレジで⚪︎⚪︎を出し、そしてキッチンプリンターで⚪︎⚪︎をする」といったように複数のシステムにまたがる機能要件が多いんですよね。それを1人ですべて担当できるので、作っているエンジニアも楽しいですしサービス全体を俯瞰的に考える習慣ができました。浦山：1人のエンジニアがそうした一連の機能改修を担当することで、より開発へのオーナーシップを持てるんですよね。それに、エンジニアとして純粋に成長できる環境だと感じています。私もそうなんですがdiniiは元メルカリのメンバーが多くて、かつそのメンバーたちは全員がもともとフロントエンドエンジニアでした。でも、私が昨年diniiに入社したときにはバックエンドやインフラをメインで担当するようになっていた人もいて、扱える技術の幅が広がっていることに驚きました。エンジニアがフルスタックでどのようなシステムも担当できることで、より本質的に事業と向き合えますし自分自身のスキルの幅も広げられるのが良いですね。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/bddb57fcb30242968d28999ebc8446de/image1.jpg" alt="" width="1999" height="1334"><figcaption>浦山裕史さん</figcaption></figure>――この事例を踏まえて、読者へのアドバイスはありますか？大友：技術選定はビジネスモデルやプロダクト展開と合っているかどうかが重要だと思います。事業展開にあたってそもそも複数のプロダクトが必要ないならば、私たちも違った技術選定をしていた可能性があります。それに、私たちの場合はものすごくハイトラフィックなシステムではないため、技術選定の軸として「パフォーマンスに優れていること」の優先度が低く、それよりも「開発効率が良くなること」の優先度のほうが高かったです。だからこそ、技術的な差分を抑えたほうがバリューを発揮しやすかったので、この技術選定になったと考えています。<h2 id="h9c94ce0c23">技術スタックではなくミッションでチームを分ける</h2>――次のエピソードもお話しください。大友：チーム編成についての事例をお話しします。私たちの開発組織は、最初の頃チームがひとつだけで、どのエンジニアもフルスタックですべての作業を担当していました。その状態を3年くらい続けて、人数が10人前後になった段階で、フィーチャーチームとプラットフォームチームに分割したんです。フィーチャーチームは主に機能開発を、プラットフォームチームはシステムの基盤構築や開発効率の向上、システムの信頼性向上などを担います。当時はプロダクト数やユーザー数が増えており、かつ飲食店のコアな業務に組み込まれていたため、運用やリリースにエンジニアがみんな気を遣っていました。さすがに全員が運用を考えるのはきついので、基盤構築やリリースサイクル改善を専任で見るチームがあったほうが良いと考えたんです。その後、より各種のデータが蓄積されてきた時期にデータチームが作られました。私たちの事業の強みは、飲食店のデータと消費者のデータの両方を取得できることです。それらのデータを基軸にして、より事業そのものを強化するためのチームです。このチームはデータ基盤を扱うだけではなく、データを活用して新しい価値につなげるためのプロダクトも作っています。浦山：今後さらに検討したいのは、「フィーチャーチームは本当にひとつのチームのままでいいのか？」という点です。現在、モバイルオーダーやPOSレジなどに加えて新しく決済関連の機能開発もしています。モバイルオーダーやPOSレジの機能が複雑な一方で、最近チームに加わって決済機能の開発をしている人は、モバイルオーダーやPOSレジについての知識をキャッチアップする機会がなかなかないんですよね。フィーチャーチームについても一枚岩で運用を続けるのではなく、特定のミッションなどに基づいてチームを分けて、より効率良く開発・運用を進められるようにするというような施策が必要かもしれません。――チーム作成において、大切にすべきノウハウはあるでしょうか？大友：チームを作るということは、そのチームに対して持続的にリソースを割くということです。逆に言えば、特定の課題がリソースを割くべき規模にまで大きくなっていない限りは、基本的にはチームを作るべきではないと思っています。チームが増えると、それだけマネジメントも大変になってしまいますから。浦山：チームを増やしてマネジメントコストだけが上がるというのは避けたいですね。大事なのは、技術スタックなどでチームを分けるのではなくミッションでチームを分けることで、1つの目的を達成するために1つのチームがフルスタックにオーナーシップを持って担当できることがdiniiの良さだと思っています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8d23963130b74924b29cc642a06f06dc/image4.jpg" alt="" width="1999" height="1334"></figure><h2 id="hbd3e13b86a">複数のサービスをスピーディーに立ち上げ、運用していく</h2>――事業展開に合わせて、組織の形もまた変わっていくのですね。大友：そうですね。私たちは飲食店という事業ドメインのなかで、今後はさらに取り扱う領域も広げていく予定です。既存事業で扱っている領域だけではなく、今後は金融関係の事業や飲食店で働く方々向けのHR領域、サードパーティー企業も巻き込んだ事業展開などやりたいことがたくさんあるんですね。これに伴って、複数のさまざまなフェーズのプロダクト開発を同時並行で進められる組織体制が必要になります。すでに、ディスカバリーチームという新規事業立ち上げに特化したチームも存在しています。このチームはプロダクトマネージャーとデザイナー、エンジニアを1人ずつで組成されていて、このメンバーでミニマムのプロダクトを作ります。ディスカバリーチームの制度を導入してから半年以上が経ちますが、かなりワークしている実感がありますね。浦山：今後の組織設計においては、「プロダクトのフェーズごとに、担当チームをどう切り替えていくか」を考えていかなければならないと思っています。たとえばディスカバリーチームは立ち上げに特化していますが、そのプロダクトがPMFしてグロースさせていくフェーズでは、中長期的なプロダクト開発に適したチームに開発の担当をバトンタッチするなども考えられます。また、各チームで伸ばせるスキルや個々人の適性、各メンバーの今後のキャリアプランなどはさまざまですから、長所を活かすとか成長につながるようなアサインを検討したいです。特定のチームで働いている人が別のチームにも移れるようにして成長の機会を生み出すとか、専門的なスキルを持つ人はその領域に特化したキャリアパスを歩めるようにするとか。事業の成長とメンバーの活躍を両立できる組織にしていきたいですね。<h2 id="h2eb593ab3a">飲食業界全体に価値を届ける</h2>――diniiの今後のビジョンについて教えてください。大友：「飲食業界のすべての領域に価値提供していく」という価値観が、diniiの事業の根本にあります。私たちは飲食店と消費者両方のデータを持っていますし、システムが飲食店のコアの業務に入り込んでいます。よく「外食産業はデジタル化が進んでいない」とか「従業員の待遇が悪く離職率が高い」などの課題が語られますが、私たちの事業にはそれらの課題を解決できるポテンシャルがあると思っています。特徴的な例として、「ダイニー」には店員に投げ銭ができる「推しエール」という機能があります。これによって、店員のやる気が上がりますし離職率の低減に貢献します。店員のなかには、この機能によって月間数万円ほどの収入を得ている人もいるそうです。テクノロジーが少し加わるだけで「一生懸命に接客をすれば報われる」という理にかなった好循環が生まれています。こうしたポジティブな変化を、飲食業界全体で起こしていきたいです。――今後の事業展開が楽しみですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？大友：エンジニアは他の職種と比べても、インターネットや本などで得られる情報の量が多いですし、それを学ぶことでスキル向上につながります。それに、OSSという存在も大きいと思っていて、「世の中のエコシステムに頼ったもん勝ち」だと思うんですよ。エンジニアという仕事は、賢い人たちが残してくれた資産の恩恵にあずかりやすい職種だと思うので、その利点を最大限に活かすためにも、いろいろな事業を知ることには価値があると感じます。浦山：単にベストプラクティスを知るだけではなく、「企業や組織がどのような状況に置かれていて、そうした背景があったなかでどんな意図で何をして、結果どうなったのか」をセットで知ることで、エンジニアは効果的にスキルを向上させられると思っています。そうした背景を学ぶのは自分自身が体験するのが一番良いんですけれど、本やWeb記事で事例を読むことによって、それに近いことを追体験できるのは良いですよね。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

「飲食をもっと楽しくおもしろく」というミッションのもと、飲食店向けのモバイルオーダーやID-POSを開発・提供する株式会社dinii。これまで取り組んできた意思決定について、取締役CTOの大友一樹さんとエンジニアリングマネージャーの浦山裕史さんに聞きました。

使用言語はTypeScriptで統一。フルスタックであることを重視したdiniiの技術選定指針

「生成AI時代を代表する企業になる」ことを表掲する株式会社Algomaticは、領域を問わず生成AIネイティブなプロダクトを次々と生み出すことを目指しています。今回はAlgomatic 取締役 横断CTO の南里勇気さんにインタビューしました。


目指すは「打席に立ちまくる」企業。20億円調達生成AIスタートアップが考える事業の勝ち筋

イオン株式会社CTO・イオンスマートテクノロジー株式会社CTOである山﨑賢さんは「歴史の長い巨大企業だからこそ味わえる、エンジニアリングの面白さがイオンにはある」と語ります。山﨑さんは、エンジニアリングを活用してイオングループをどのように変革しようとしているのでしょうか。

「真の課題を捉えるために、自ら店舗にも立つ」イオンをテクノロジーで変えるため、現場と徹底的に向き合う

ブログサービス「はてなブログ」やソーシャルブックマークサービス「はてなブックマーク」、SaaS型サーバー監視サービス「Mackerel」などの有名サービスを開発・運営する株式会社はてな。同社は他にも、株式会社KADOKAWAと共同で小説投稿サイト「カクヨム」を、株式会社集英社と共同でマンガ家のための作品投稿・販売プラットフォーム「マンガノ」を開発するなど、技術力やシステム構築の実績を活かして大手企業との協業を積極的に行っています。はてなのCTOである大坪弘尚（通称：motemen）さんは、2008年に同社へと新卒入社して以来、15年近くにわたりプロダクト開発を支え続けてきました。そんな大坪さんに、過去に行った組織的・技術的意思決定のなかで印象に残るものを聞きました。<h2 id="h8e902f88b1">エンジニア自身がプロダクトオーナーシップを持てるように</h2>――今回のインタビューでは、過去に取り組んだ組織的・技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。大きな意思決定としてまず思い浮かぶのは、社内で「プロダクトオーナーシップ」と呼んでいた動きですね。ここに至った経緯なんですが、はてなはかつて「はてなブックマーク」や「はてなブログ」に限らず、もっとたくさんの「はてな○○」サービスをたくさん作っていました。はてなスタッフのアイデアで面白いサービスを多く、素早く世に出す、というのが会社としての戦略だったのだと思います。そうしたサービス開発を支えるための共通システム基盤が社内には構築されており、それを運用するチームもありました。その後、はてなはtoB事業の「Mackerel」や、toCだけれど他社と共同で開発した「ジャンプルーキー！」のように、性質の異なるプロダクトも徐々に作るようになりました。本来であれば「はてな」サービス向けの基盤はそれらの新しいプロダクトにはミスマッチなわけで、事業の変化に合わせて、開発や運用のありかたも変わっていくのが望ましいはずです。ですが、そうはならなかった。当時のはてなはいわゆるDevとOpsの分断が起きていました。システム基盤が進化していくにつれ、開発メンバーの運用に対する意識が薄くなってしまっていたんですね。そういう状態で開発したシステムを運用チームに渡すことを続けてきた結果、運用チームの負荷が高くなっていきました。運用チームは本当ならば基盤を進化させたいのにその余力がなく、一方で開発チームは運用を半ば手放してしまったことで、自分たちが選定する技術の責任を取れない状態になっていました。そこで、この状態を是正するためのプロジェクトを推進しました。このプロジェクトで目指したのは、開発チームがプロダクト全体のオーナーシップを持てるようになることです。技術選定や開発、運用という一連のプロセスを、すべて開発チームが担うことを目指しています。これによって運用チームの業務負荷を下げて、運用チームは基盤そのものの進化に力を注げるようにしようと考えました。具体的には、まず障害発生時の一次対応を開発チームに担ってもらうことから始めました。もちろん、調査したうえで技術的にわからないことがあれば、運用チームが助けにいきます。ただ、この施策を推進したものの、移行途中は組織のみんなにすごく大変な思いをさせてしまいました。苦労の多い運用を開発チームも担うようになったので、移行途中はむしろ“組織全体としての大変さ”が膨らんでいるような状態だったんですね。その期間はみんながすごく疲弊していましたし、私はそれをうまくサポートできていませんでした。――大変さの原因は何にあったのでしょうか？「プロダクトオーナーシップ」というゴール自体はよいものだったと思っています。ただ、その正しい目標にみながそれぞれ全力で取り組んでしまうこととなり、全体としてどういう経路で、どういうテンポで進んでいくのか、という統制や具体的な計画が欠けてしまっていました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b0c6c7337aff42cf97e3b5eb7c5550d6/PIXTA-78.jpg" alt="" width="1920" height="1280"></figure>――もし、今の大坪さんが、当時と同じ状況に置かれたらどうしますか？自分自身も開発チームに参画して、彼らと同じ仕事をすると思います。当時の私は、ゴールを示すのが自分の仕事だと勘違いしていたんですね。つまり、抽象度高く会社や組織の方針を策定して、実行はメンバーに任せることがCTOのあるべき姿だと思っていました。でも、解像度高くチームのことを理解するには、実際に現場に入らなければなりません。それから、開発組織以外の部署との調整もうまくできていませんでした。その頃の私は、エンジニアとのコミュニケーションが中心だったんですね。ですが、エンジニアの業務負荷や開発・運用体制が変わるということは、事業やプロダクトにも確実に影響が出ます。その点について説明し、協力を取り付けるといった全社レベルでの巻き込みが足りていませんでした結局、途中でこのプロジェクトの再編成をして、エンジニアだけではなく事業部全体を巻き込んで進めるように変えたんですね。その結果、時間はかかりましたが、今では各開発チームのメンバーがプロダクトオーナーシップを持ったと言える状態になっています。<h2 id="h5fcf3adce7">「事業の成功に責任を持つ立場」として、エンジニアリングマネージャーを設置</h2>――他の事例はいかがでしょうか？他の大きな変更は、エンジニアリングマネージャーの設置ですね。はてなは開発組織が80人規模になるまで、職種横断でエンジニアの評価・育成・採用などに責任を持つチーフエンジニアという役割の人間はいたものの、プロダクトやチームを管轄するエンジニアリングマネージャーを置いていなかったんです。それを、プロダクトチームにつくエンジニアリングマネージャーと、さらにそれを束ねるチーフエンジニアリングマネージャーを設置するという構造に変えました。――体制を変更した背景は？もともと、はてなにはプロダクトを開発する部署がひとつしかありませんでした。それが、2022年の組織変更で「はてな○○」系のサービスを作る事業部と、toBプロダクトや他社との協業を担う事業部に分割されたんです。かつ、先ほどのプロダクトオーナーシップにより、決まったインフラ基盤からシステムが解き放たれたこともあり、各プロダクトチームの独立性は今後さらに高まるだろうと考えました。また話が前後しますが、その前の段階からtoCサービス以外の事業の比重が増えるにつれて「規模の大きなプロジェクトをうまく進めていく知見が必要だ」ということで、プロダクトのデリバリー（高品質なプロダクトをスピーディーに作り、ユーザーへ届けること）の練度を高める機運がエンジニアを中心に高まっていました。ですが、開発チームがエンジニアリングだけに注目してデリバリーを改善できたとしても、それだけでは本当の意味で事業への貢献ができるわけではありません。そこで、エンジニアリングに軸足を置きつつ事業の成功に責任を持てる人として、エンジニアリングマネージャーを配置しました。――具体的にエンジニアリングマネージャーはどのような動き方をするのでしょうか？事業のボトルネックによって変わります。たとえば技術的な観点での計画を事業計画とすり合わせ、長期的な価値につながるよう調整したり、プロダクトのディスカバリー（何を作るかを決定すること）とデリバリーをうまくつないだりといった仕事ですね。エンジニアリングのことだけを考えるのではなくて、もし仮に事業としてのボトルネックがプロダクトマネジメントやディスカバリーにあるならば、そちら側にも積極的に関与する役割です。また、こうした業務を担いつつ各エンジニアがモチベーション高く働けるようなタスクの割り振りや育成などの役割も果たすことになります。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/d96eb23356134ec98c118a25dd063c4e/PIXTA-54.jpeg" alt="" width="3113" height="2075"></figure>――「事業に関心を持つこと」を苦手とするエンジニアも多いですが、どうすればその視点を身に付けられるでしょうか？もちろん、最初から事業について全容を把握しようとするのは難しいので、まずはユーザーのことをきちんと想像しながらプロダクトを作るのが、事業視点を持つための第一歩だと思います。自分たちの仕事はプロダクトを作って終わりではなくて、ユーザーに対して何かしらの価値を提供するまでがゴールです。ユーザーがどのような人たちなのか、プロダクトがどのように使われているのかなどを開発チームが知る必要があります。開発組織のなかでは、ユーザーインタビューを積極的にしているチームも出てきており、こういった動きを社内でより広めていくことを目指したいです。もともと、はてなが作っているのはtoCのプロダクトがほとんどでしたし、toBにしてもMackerelのように、エンジニア自身がそのプロダクトのユーザーであるケースも多いです。だからこそ、特別なことをしなくてもユーザーのことを理解できるのが当たり前、という感覚もあります。ですが、最近は扱っているプロダクトも多様化しています。「もしかしたら、自分はユーザーのことを正しく理解できていないのかもしれない」という前提のもと事業と向き合わないと、いつの間にか視野が狭くなっている可能性があると思います。<h2 id="he8b3ceb648">「あるべき論」に盲従しない。使える手段はすべて使う</h2>――他の事例も教えてください。CTOである自分自身が、開発チームに入って手を動かしていることですね。最近機会があって、いちエンジニアとして開発チームのヘルプに入りました。そして、実際に手を動かしてみると、「はてなの技術」というものが現場に近い解像度で見えた感覚がありました。これが意外と、自分にとって大きな発見でした。実は開発チームの技術のことを、全くわかっていなかったんだと気づいたんです。その経験をすることで、はてなとして技術的により良くできそうな部分や今後の課題になりそうな部分が、肌で感じられました。これを皮切りに、そのチームのヘルプを終えた後には、いくつかのチームを順に回っています。もちろん、私が開発にかけられる時間は少ないですし、チームの技術をキャッチアップできていないところはあります。それでも、組織の状況を知るうえで価値の高い活動なので、今も続けています。――開発組織のマネージャーやCTOのなかには「自分はなるべく手を動かさず、マネジメントに集中しなければ」と考えている方もいると思います。大坪さんの経験を踏まえてアドバイスはありますか？マネージャーのポジションになったからといって仕事の幅を狭める必要はなくて、使える手段はすべて使うほうがいいということですね。よく言われる、エンジニアがマネージャーになったらなるべく手を動かさないという「あるべき論」にとらわれ過ぎないほうがいいです。自分が使える手段があるのならば、それをシャットアウトしてはならないと思います。抽象的なインプットからは、抽象的な判断しかできません。そのインプットだけでは自分が適切に判断できないならば、もっと現場や一次情報を見て、ある程度の手触りがある状態にしておく必要があります。私の場合は、おそらくCTOになってすぐの頃はそういった感覚が残っていたのだと思います。ですが、マネジメントに注力し続けているうちに感覚が鈍ってしまい、組織の変化に自分が追いつけていなかったのかもしれないですね。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/6a77146e16be4388b389f62760e14279/PIXTA-143.jpg" alt="" width="4500" height="3000"><figcaption>大坪氏は他にも将来的なプランとして「Perlで書かれたシステムをリアーキテクチャしたり、他のプログラミング言語に置き換えたりといった施策を推進し、より開発・運用しやすい状態へと変えていきたい」と語ってくれた。Perlで書かれた数多くのシステムを抱える同社にとって、「今後、Perlとの折り合いをどのようにつけていくか」は重要なテーマだという。</figcaption></figure><h2 id="h06b4eacd80">はてなの遺伝子を今後も残していきたい</h2>――この先、はてなをどのような会社にしていきたいですか？これは、私がこの会社に入社した理由にも通じるんですが、はてなはエンジニアが面白いものを作って、それが世の中に受け入れられて大きくなった会社です。そのブランドや遺伝子を、今後も残していきたいです。昔とは違って、プロダクトを作るにあたって考慮すべきことは相当に増えました。かつては、Webサービスを作って、ヒットさせて、広告を貼るというシンプルなモデルで収益を上げられましたが、世の中にサービスが増えている昨今ではそう簡単にはいかなくなっています。事業やプロダクトのアイデアを検証して、世に出して大きくすることは昔よりずっと難しくなりましたが、その高い壁にエンジニアが挑戦していけるようにしたいです。要するに、「システムを作って終わり」とか「自分の好きな技術を扱えたから満足」ではなくて、プロダクトによって世の中に価値を発揮することに、エンジニアが主体となって取り組んでいきたいですね。――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「組織的・技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？「経験しなければ学べない」と、私はずっと思っています。今回、インタビューを受けるにあたって過去の事例などを事前に振り返ったんですが、その過程で「昔の自分はなんて浅い考えだったんだろう」と実感しました。逆に言えば、その分いろいろな経験をして、そこから多くを学んできたのかなと思います。そうした各種の事例について、書籍やWeb記事などを通じて追体験することは、すごく大事です。自分と似たような立場や境遇の人々がどのような課題に直面して、何を考えて方針を選んだのか、その結果どうなったのかなどを学べることには意義がありますね。取材・執筆：中薗昴撮影：石田博紀提供：<a href="https://haulinc.jp/">株式会社Haul</a>

はてなのCTOである大坪弘尚（通称：motemen）さんは、2008年に同社へと新卒入社して以来、15年近くにわたりプロダクト開発を支え続けてきました。そんな大坪さんに、過去に行った組織的・技術的意思決定のなかで印象に残るものを聞きました。


「CTOという立場にとらわれ過ぎていた」はてなmotemen氏が、今あえて現場でコードを書く理由

「サービスがPMFするまで、どのような体制で開発を進めるか」というテーマに、わかりやすい正解は存在しません。企業の創業メンバーの内訳や各々のスキル、会社の資金、世の中や他社の動向など、さまざまな変数が「開発組織のあり方」に影響します。CTOやVPoEといった企業の技術リーダーたちは、そうした変数を鑑みつつ自社の方針を決める重要な役割を担っています。営業活動支援のSaaS事業およびコンサルティング事業を展開するSALESCORE株式会社のCTOを務める成澤克麻さんは、MVP開発開始から4年間は「エンジニア1人でフルスタックにサービス開発すること」を選びました。そして事業が軌道に乗った現在は方針転換をし、人を増やしながらスケール可能な体制作りを目指しているのです。今回は成澤さんに、SALESCOREがこれまで選択してきた開発組織の方針について聞きました。<h2 id="he6fab41ed4">KPIを可視化し、営業組織の実行力を向上させる</h2>――SALESCOREの事業概要についてお話しください。SALESCOREは、再現性のある営業組織を作るためのコンサルティング事業と、営業組織の状態を可視化し課題を特定できる「SALESCORE」というSaaSを提供しています。SALESCOREは創業メンバーがDeNA出身者とキーエンス出身者です。キーエンスは日本でもトップレベルに、営業を科学している会社です。そのキーエンスやリクルートといった営業の強い企業のノウハウを、元DeNAのメンバーが体系化して、コンサルティングの事業に活用してきました。そして、そこから得た知見をSaaSとして提供しています。「SALESCORE」は、セールスイネーブルメントと呼ばれる、営業組織を強化・改善するための取り組みに寄与するプロダクトです。さまざまな機能がありますが、主な機能は営業組織の各種KPIの可視化です。エンジニアの世界には「推測するな、計測せよ」という言葉がありますが、まさにこの概念と同じようなことを営業の仕事に適用しようとしています。旧態依然とした営業組織では、担当者の「勘と経験」に基づいた業務が行われています。しかし、これでは成績の良い人のノウハウをうまく他の人に伝えることができませんし、成績の悪い人のどのような点を改善すればよいのかが具体的にわかりません。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/25d2ba4a324747a683e239deb676b127/image1.jpg" alt="" width="1999" height="1061"><figcaption>「SALESCORE」の画面。</figcaption></figure>「SALESCORE」を用いると、売上や受注数、案件数といった各種KPIを可視化することができます。これによって「⚪︎⚪︎さんは⚪︎⚪︎の数値が低いから、ここを改善すると成績を伸ばせるはず」というように、営業の業務改善に役立てることが可能です。これらの数値は目標を設定することもでき、ダッシュボードを閲覧した時点で目標を下回っているならば赤文字、上回っているならば青文字で表示されるようになっています。余談ですが、「SALESCORE」のユーザーが発案してくださった「オールブルー」という用語があります。要するに、すべての数値がKPI目標を上回っているという意味で、営業組織の朝会や夕会などで「今月はオールブルーを達成できるように頑張りましょう」という会話をしてくださっているようです。――「SALESCORE」は他の営業支援ツールと比較して何が優れているのでしょうか？「SALESCORE」は『戦略を、実行できる組織、実行できない組織。』という書籍の影響を強く受けています。この本で語られているのは「世の中の経営者の多くは、何をすればよいかという戦略を知っているものの、どうすればそれを実行できるのかを知らない」ということです。「SALESCORE」はこの課題を解決するために「営業組織の実行力を向上させること」にフォーカスしています。組織の朝会や夕会で必ず「SALESCORE」を見るという運用フローを推奨しており、定量化したKPIを全員で確認することによって、それぞれのメンバーの行動を変えることのできるサービスになっています。<h2 id="h4e09f1299f">SALESCOREの場合は、1人で作ることがベストだった</h2>――ここからは、成澤さんが携わってきた開発組織の意思決定について伺います。まず、MVP開発期間から4年間は1人で開発をしてきたそうですが、その理由についてお話しください。MVPを作っていたのは2019〜2020年ごろで、当時は「SALESCORE」とは別のプロダクトを開発していました。前提として、MVPの価値検証フェーズではとにかくクイックに開発をすることが大事です。スタートアップは無駄なことをしていると、どんどん資金が減って倒産してしまいます。開発組織の人員も、最小限の人数からスタートすべきです。価値検証に用いるプロダクトであれば、全く問題なく1人で作れると考えたため、その方針が最適だと思いました。実際に作業はスピーディーに進み、2週間ほどで最初のプロダクトの開発を一通り終えてファーストリリースをしました。そのサービスは1アカウントあたり2万円という価格で10人規模の会社に売れたため、1人でもそれなりのものを作れるという確信を得ましたね。――MVPを開発して「プロダクトを売る見通しが立ちそうだ」とわかったタイミングで人を増やす選択肢もあり得ると思います。SALESCOREの場合は、なぜ「1人の体制を続ける」という方針を選びましたか？私は株式会社ラブグラフで社員として働いた後にフリーランスになりましたが、前職では採用する立場を、退職後は採用される立場を経験して、エンジニア採用が超レッドオーシャンであると感じました。実際、ラブグラフ退職後には魅力的な企業から山ほどオファーレターが届きましたし、その状況のなかでSALESCOREが他社よりも目立つのは厳しいと思いました。もちろん、採用は将来的には必要なことであるためいつかは実施しなければならないのですが、エンジニア採用市場の過酷さや自社の強みが採用にあるとは思わなかったことから、1人の体制を続けることを選びました。もし、会社の資金が潤沢にあるとか、社内に知名度の高いメンバーがいて採用市場でのプレゼンスが大きいのであれば、そこで戦えばよいと思います。要は「どの選択肢を選ぶことで成果を最大化できるか」という話だと思います。その時点では採用にリソースを割くよりも、私が集中して開発することで得られるアウトプットのほうが大きいと考えました。――成澤さんは相当に実装スピードが速いエンジニアだと思うのですが、その要因はどのような点にあると思いますか？いくつかあり、まずは機能要件の取捨選択が得意だと思っています。これは、エンジニアリングだけではなく事業のことにも通じているからで、仮に「この機能の開発に3日かかるけれど、それほど事業へのインパクトがない」と判断した場合は「作らない方針にしませんか」と提案できます。経営戦略から細かい実装の話まで、幅広いレイヤーの知識を学んでいることが大きいです。では、なぜそのスキルを身に付けられたかというと、私自身が目的意識と批判的思考が強いことに起因していると思います。事業を成功させるために何をするべきかを常に考えているので、何かの機能開発ひとつを取っても、「本当にこの作業に時間をかけるべきなんだろうか。それはなぜか」という「そもそも論」を考えがちなんですよね。それから、なるべく最先端の技術を使うようにしていることも、要因として挙げられます。世の中のツールやライブラリはどんどん便利になっているので、それらを活用すると実装の手間を大幅に減らすことができます。たとえば、フロントエンドの各種技術スタック、特にUIライブラリなどが進歩したことは大きくて、前職のラブグラフの時代には1週間かかっていた実装が今ならば半日程度でできます。あとは、この10年くらい毎日のようにコードを書いているので、純粋に実装力が上がって開発が速くなっているのもあると思います。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/c2fed5401b444886b08b55d4adb0b6dc/image2.jpg" alt="" width="1999" height="1333"></figure><h2 id="h02cc5959e9">Rails+Nuxt.jsからフルTypeScriptへ</h2>――使用している技術スタックについても教えてください。MVPを作っていた初期フェーズでは、Ruby on RailsとNuxt.jsを使っていました。Ruby on Railsはプロダクトを高速に立ち上げるのに向いていますし、枯れている技術なのも良い点です。また、Nuxt.jsは手軽にUIを作れるライブラリだという印象がありました。ですがその後は、フロントエンドもバックエンドもTypeScriptを使用するように技術スタックを変更しました。Ruby on Railsは優れたフレームワークですし今でも好きですが、Rubyが動的型付けの言語であることから、複雑なサービスを作るときに課題が生じると思っています。スタートアップでは、特に初期フェーズにおいてサービスの頻繁な仕様変更やリファクタリングが発生します。TypeScriptの場合、そうしたケースではコードを書き換えた際のコンパイルエラーを解消すれば、それほどテストをしなくても一定以上の品質を保つことができます。気軽にリファクタリングをして、ドメインロジックをより良いものに変え続けることができました。――Ruby on RailsにおいてはActive Recordが非常に優秀ですが、TypeScriptの場合はO/Rマッパー系フレームワークの利便性はいかがでしょうか？確かにActive Recordは非常に便利で、それと比較するとPrismaは薄いフレームワークだと思います。「バリデーションをどの箇所で行うか」など、エンジニア自身が考えなければならないことが多いです。ただ、弊社の場合はO/Rマッパーの機能不足がそれほど大きな問題になっていません。なぜなら、私たちのプロダクトはドメインロジックが複雑である一方、データの取り扱いに関してはそれほど複雑な処理をしていないからです。またインフラについても話すと、個人的には必要がなければ初期フェーズではAWSやGCPなどのクラウドを使わなくてもいいと考えています。PaaSで賄えるならそれで十分です。そのほうが圧倒的に楽ですし、エンジニアがフロントエンドとバックエンドだけではなくインフラの知識も身に付けるとなると大変ですから。SALESCOREの場合は1年前にAWSに移行しましたが、それまではずっとPaaSを使い続けてきました。<h2 id="h3ae6ac1889">「本当にテストを書く意味があるのか？」を考える</h2>――他に開発スタイルの特徴はあるでしょうか？初めの1年くらいは基本的なE2Eテストを書いていたのですが、結局はやらなくなりました。もともとは、各機能に対する基本的なテストは毎回書くようにしていたのですが、それによってプロダクトの品質が向上したかというとそうでもなく、むしろ運用コストがかかるデメリットの方が大きく感じていました。そこで私の場合は、そもそもテストがなくても問題ないようなコードを書こうという意識に変わっていき、その結果としてテストを書かない方針を選ぶようになりました。加えて、E2Eテストを書かなくてもよいのは弊社の扱っているプロダクトの特性も影響していると思います。まずは、社内ユーザーが一番のヘビーユーザーであることです。私たちは営業支援のSaaS事業をやっている会社であるため、営業活動には当然ながら力を入れていて、社内で自社サービスをフル活用しています。だからこそ、自社のメンバーがクライアントよりも前に不具合に気づくケースが多かったんです。それから、ミッションクリティカル性の低さです。万が一サービスが止まったとしても、クライアントの日常的な業務が完全に停止するわけではありません。そのため、仮に細かな不具合を見逃しても、すぐに直せばユーザーに大きな不利益を与えることがありませんでした。また、不具合発生時に基本的に即応できていたことや、その対応がむしろ信頼につながるという側面もありました。仮に何かの不具合が発生しクライアントからの問い合わせがあれば、早ければ30分ほど、遅くとも数時間以内に修正してリリースすることがほとんどでした。その対応の速さを誉められて信頼につながることがよくありました。この事例を踏まえて「自動テストを書くか否か」について結論を話すと、書くべきかどうかは事業やチームの状況に合わせて考えるものだと思います。だからこそ、そうした前提条件を考えずに無思考に「書く・書かない」という選択をしないことが大事です。<h2 id="h20f802f265">「1人の開発」から「みんなの開発」への体制変更</h2>――直近の1年間はエンジニアを増やしているそうですが、方向転換した経緯をお聞きしたいです。PMFを目指す段階では1人のほうが良かったという旨の説明をここまでしてきましたが、事業が拡大するにつれて、さすがに1人では手が足りなくなってきました。そこで2023年の初頭から採用を始めて、業務委託のエンジニアに参画してもらったんですね。優秀な方だったものの、SALESCOREの受け入れがうまくいかず結果的には短期間で契約が終了してしまいました。これをきっかけに、私以外のエンジニアがしっかりワークできるような仕組み作りに、本気で取り組もうと思うようになりました。まずはドキュメントの整備から始めましたね。1カ月くらいの時間をかけて、サービスの思想や設計の意図などを伝えるための文章をがっつり書きました。そのうえで、週に1回のペースでそのドキュメントをみんなで読む会を開催しました。また、各種の定例や1on1などの仕組みを整備したり、内容を試行錯誤したりしていきました。そうした施策を2023年は続けていたのですが、秋の段階で「これではまだ足りない」と思うようになりました。というのも、私はサービスの全容を把握していますし会社のSlackのやりとりもすべて追っているので、何かの問題が起きたときに真っ先に自分で対応してしまったり、誰かに任せても途中で口を挟んでしまったりしていたんですね。そうすると、メンバーの活躍の機会を奪ってしまいますし、「結局CTOがなんとかするから大丈夫だろう」というような雰囲気を醸成してしまいます。そこで、できるだけ干渉しないようにグッとこらえて、なるべくみんなにお願いすることを最近では徹底しています。個人でプロダクトを作っていた体制から、チームでプロダクトを作る体制へと徐々に変化していますね。――今後の組織や事業のビジョンを教えてください。組織に関しては、引き続き自分がいなくても回るチーム体制を作っていきます。そのうえで、私はマネージャーよりもプレイヤーとして動くほうが会社全体のためになりそうなので、たとえば新規開発をゴリゴリと推進するとか、特に重要な箇所の改善に取り組むといったことに注力していきたいです。事業としては、セールスイネーブルメントという事業ドメインはかなり複雑で、何かひとつの課題を解けばそれで終わりではなく、複数の課題を解くことでようやく真に顧客の価値になるプロダクトを作ることができます。今後は「SALESCORE」の機能をより拡張することで、一気通貫の価値を提供できるようなプロダクトに成長させていきます。――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？結局のところ、メディアなどで誰かが語っている内容は、一面的な情報でしかありません。その企業や組織で何が起きていたのか、どのような事業特性を持っているのかなど、解像度高くその事例を理解しなければ、真の意味での学びにはならないと思います。とは思いつつも、各社の事例を見聞きしていると世の中のトレンドがある程度わかりますし、それをいったん自分で試してみることも大事です。「いろいろな会社がこの技術を良いと言っているから、うちでもやってみるか」という感じに。何かに取り組む際のきっかけとして、他社の事例を学ぶことには意義があると思います。取材・執筆：中薗昴撮影：金沢俊提供：<a href="https://haulinc.jp/">株式会社Haul</a>

営業活動支援のSaaS事業およびコンサルティング事業を展開するSALESCORE株式会社のCTOを務める成澤克麻さんに、SALESCOREがこれまで選択してきた開発組織の方針について聞きました。


「インタビュー」の記事一覧