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がこれまで選択してきた開発組織の方針について聞きました。


エンジニア1人で4年間プロダクトを開発。ミニマムな体制で効率的な価値検証を行う知見

株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションのもと、薬局DXを起点に日本の医薬業界の課題解決に取り組むヘルスケアスタートアップです。国内に約6万店舗が存在する薬局ですが、まだまだアナログな業務がたくさん残っており、テクノロジーを用いて変革し得る余地があるとともに成長可能性が高いマーケットなのです。今回はカケハシの黎明期から同社で働き薬局体験アシスタント「Musubi」のテックリードを務める松山哲也さんと、2023年10月に入社し新サービスの開発に取り組むソフトウェアエンジニアの荻野淳也さんにインタビューしました。<h2 id="hb6fd6c6510">AWS Elastic BeanstalkからAWS Lambdaへの切り替え</h2>――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。松山：まずは、「Musubi」のバックエンドで使用していたAWS Elastic BeanstalkをAWS Lambdaに乗り換えたエピソードについてお話しさせてください。もともと私たちはWebアプリケーションをデプロイするサーバーとして、AWS Elastic Beanstalkを使っており、創業から数年は特に問題なく使い続けていました。ですが、数年ほどが経過した頃から、なぜかAWS Elastic BeanstalkのサーバーのCPU使用率が100％に達する障害が時折発生するようになりました。おそらく、AWS Elastic Beanstalkもしくは利用している何らかのミドルウェアの珍しいバグを踏んでしまったのではないかと思います。特定のサーバーを長時間稼働させ続けると、その事象が発生するようでした。簡単にはバグの原因を解明できなかったため、しばらくはサーバーがあまり長く稼働しないように、ある程度の時間が経ったらローリングさせる運用をしていました。また、AWS Elastic Beanstalkは設定が複雑であるなど運用面でも課題があり、何か誤った設定を入れてしまった場合にサーバーの動作に不具合が生じるなどのトラブルも発生しました。その状況を改善するための方針を考えていたところ、ちょうど世の中でサーバーレスアーキテクチャが流行していたんです。AWS Elastic BeanstalkをAWS Lambdaに置き換えてはどうかという意見が、社内で挙がりました。AWS Lambdaを用いることのデメリットとして、コールドスタートの場合に起動まで時間がかかることが挙げられます。しかし、「Musubi」は薬局の基幹業務で使われるサービスなので、BtoCのサービスのように遅延によって即座にユーザーの離脱が発生しないことと、導入件数の増加に比例してアクセス数も増えており、相対的にコールドスタートの発生確率が低くなることから、ユーザーへの影響は小さいだろうと考えました。そこで、AWS Lambdaに切り替える方針を3年前くらいに選択しました。荻野：この事例のAWS Lambdaを使う方針もそうですが、他にもカケハシではメインのストレージとしてAmazon DynamoDBを使っているなど、AWSのマネージドサービスを使い倒しています。可能な限り運用にかかる工数を減らして、サービス開発に集中できる体制にしていることが大きな特徴ですね。――この事例では、どのような方法でシステムの移設を行いましたか？松山：1回ですべてのWeb APIをAWS Lambdaに入れ替えるのは難しそうだったので、機能単位で移設を行いました。Web APIの前段にはNginxがあるので、設定を入れてURLでのリクエストの振り分けを行い、「このURLならばAWS Elastic Beanstalk側、このURLならばAWS Lambda側」という感じに分岐させたんです。こうしたインフラ移設系のプロジェクトは、一度にすべてを切り替えるのではなく、段階的に進めるほうが良いと思います。どれだけいろいろなことを考慮しても、必ず想定外のトラブルは発生しますから。たとえば私たちのプロジェクトでも、AWS Lambdaで使用していた特定のライブラリの処理が極端に重たくなったり、AWS Lambdaのレスポンス6MBの制限に引っかかったりという事象が起こりました。すでにユーザーに利用されているサービスの場合は、利用不可能な状態になってはならないので、特に注意深く移設を進めるべきだと思います。いまでは完全にAWS Lambdaに移行して、運用がかなり楽になっています。ただ、実はこのインフラ移設のプロジェクトを実施している間に重要度の高い別のプロジェクトが発足し、そちらの対応を行う必要が生じました。そのため、このインフラ移設が完了するまでに2年ほどを要してしまったんです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8110cfa9ed1a400d82e01b8e04c5d027/20240131_kakehashi_144%20(2024-02-05T10_21_45.609).jpg?w=1600&amp;h=1066" alt="" width="1600" height="1066"><figcaption>松山哲也さん</figcaption></figure><h2 id="hd4dd6bed7c">「ナショナルクライアントを獲得する」方針に舵を切った</h2>――重要度の高い別のプロジェクトとは何だったのでしょうか？松山：会社としてナショナルクライアント（全国的な知名度やブランドを持つ大企業の顧客）を獲得していく方針を打ち出したのが大きいです。「Musubi」というサービスは、初めは小規模な薬局を対象として顧客の獲得を進めていました。その次に、数店舗から10店舗ほどの規模の薬局を顧客としていきました。そうしたフェーズを経たうえで、ナショナルクライアントを対象としてサービスを導入していくことを選んだんです。しかし、小規模・中規模な企業と比べて、ナショナルクライアントから求められる基準は高いものがあります。なかにはMusubiがその基準に達していない点もあり、不足している機能を開発組織のすべてのリソースを集中して開発しました。人が足りないため、エンジニアの採用やパートナー企業の開拓なども進めました。その状況が2年近く続き、かなりバタバタでした。エンジニアの方であれば想像がつくと思いますが、急ピッチで機能開発を進めるとどうしても品質が犠牲になるんですよ。技術的負債が生じたり、バグが頻発したりといった課題も起きました。――開発組織にはかなり負荷のかかる状況だと思いますが、なぜナショナルクライアント獲得のための新機能開発に踏み切ったのでしょうか？松山：規模の大きな薬局の場合、使用している基幹システムを置き換えるのは5年おきなどの長期スパンになります。その企業が導入システムを検討するためのコンペも、チャンスを逃すとその後しばらくは実施されないんです。スタートアップがその大きなチャンスを自分たちのものにできず5年が経ってしまえば、資金が尽きて倒産するかもしれません。だからこそ、当時のカケハシとしてはかなり背伸びをしましたが、成長痛を受け入れて急ピッチで新機能開発を進めることにしました。荻野：それが原因で、後々に技術的負債に苦しむことにもなるけれど、カケハシの事業が成長していくためには必要なことだったわけですね。松山：そうです。大変な思いはしましたが、ナショナルクライアントへのシステム導入は成功して、事業が大きくなりました。もしこのプロジェクトが失敗していたら、私たちはここにはいないかもしれませんね。――この事例のように、読者のなかには「大手企業を顧客として獲得していきたい」というフェーズのスタートアップで働く方々もいるはずです。そうした人に向けて、カケハシの事例を踏まえて伝えたいことはありますか？松山：メンバー全員の“納得感”があることが一番重要だと思います。スタートアップはその性質上、基本的には事業が急成長するかダメになるかのどちらかしかありません。だからこそ、大手企業を顧客として獲得するために、無理をしてでも機能開発を進めなければならないケースもあると思います。会社で働くみんなが、その認識を持っていることが大切ですね。そういう意味では「Musubi」の開発チームは恵まれていました。会社の掲げるビジョンや事業に共感して、「今は会社の重要なフェーズだから」と理解していただける方が多かったです。<h2 id="hcc45b2f686">新規サービスの技術を「Musubi」にもフィードバックしたい</h2>――荻野さんは2023年10月からカケハシに参画されましたが、プロダクトや技術などで今後改善していきたいところはあるでしょうか？荻野：私がいま所属しているチームは新規事業を担当しており、新しいプロダクトを開発しています。「Musubi」と比較すると、採用している技術はさまざまな点が実験的です。たとえば、「Musubi」はAWS Lambdaを中心としたサーバーレスなインフラ構成を用いてストレージはAmazon DynamoDBをよく用いていますが、私たちのチームではコンテナを採用しストレージはAmazon RDSを使っています。積極的に技術的なチャレンジをして、私たちのチームでうまくいった手法は「Musubi」側にも取り入れるといったことが将来的に実現できるといいですね。基幹プロダクトである「Musubi」の開発チームは業務の負荷が高い状態なので、そちらのチームの役に立てるようになっていきたいです。また、現在はそれぞれのプロダクトのチームが自由に技術選定をしていますが、今後は採用技術を統一するような構想も考えています。その際に私たちのチームで用いている、既存プロダクトとは異なった技術を比較材料として使ってもらうことができるはずです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/1c49b0e8b9e645d085b8ad4ee3386d69/20240131_kakehashi_011%20(2024-02-05T10_17_31.324).jpg?w=1600&amp;h=1067" alt="" width="1600" height="1067"><figcaption>荻野淳也さん</figcaption></figure>――荻野さんがカケハシに対して感じている、企業としての魅力はありますか？荻野：私は完全に、“人”に惹かれて入社したんですよ。入社前の段階から、一緒に働くことになるメンバーとの会食の場を設けてもらいましたが、すごく心地良くコミュニケーションができました。松山さんが先ほど、「会社の掲げるビジョンや事業に共感している人が多い」という話をしていましたが、そういった特性を持つ人が集まっているからこそ、快適な雰囲気が生まれていると思うんですよね。入社してからも、それを毎日実感しています。それから、採用面接の段階でVPoEである湯前慶大さんから「ぜひ、エンジニアとして手を動かすことに専念してほしい」という声をもらったこともうれしかったです。私は年齢が50歳近いんですが、一般的にはこのくらいの歳になると会社から「マネジメントをしてほしい」と要望されることが多いです。ですが私は、もっとコードを書くことを追求したいという思いがありました。だからこそ、プロダクト開発の最前線でお客さんと向き合いながらエンジニアとして働けるカケハシの環境は、すごくありがたかったです。<h2 id="hf31e81c6d6">エンジニアが最優先にすべきは“事業”</h2>――今回のインタビューを踏まえて、プロダクト開発に携わるエンジニアが大切にすべきマインドをお話しください。松山：私が思うのは、エンジニアが最優先にすべきは“事業”だということです。会社がどのような状況で、何を目指しているのかをエンジニアも理解する必要があります。お話しした事例のように、大手企業の顧客を獲得するための機能開発が求められるフェーズも、その逆に機能開発を止めてでもシステムの安定性を向上させるべきフェーズもあると思います。技術はあくまで何かを実現するための手段だと私は思っているので、達成すべき目標が何なのかを自分なりに考えて、そのうえでメンバー同士で議論して認識を合わせていくことが大事ですね。荻野：松山さんが言われたように、あくまで技術は手段であると捉えて、その道具を使っていかに会社のビジョンを実現していくか、自分たちの住む世界をより良い状態にできるかを考えて、行動していくべきだと思います。一方で、エンジニアはやはり自分の思い入れのある技術に触れていないと、力がフルに発揮できないという側面もあるじゃないですか。だからこそ、個人的なこだわりは捨ててほしくないところでもあって。事業が目指している目標と自分の好きなこと・やりたいことをどうすり合わせるかを考えていくと、エンジニアはより良いキャリアを実現できると思います。松山：それと近いことを、私はメンバーとの1on1でよく話しています。ベン図で「会社としてその人にやってほしいこと」と「自分自身がやりたいこと」を可視化した場合に、2つの円が重なった箇所の仕事をするのが、一番良いですね。荻野：それに加えて、「自分自身がやりたいこと」の円を広げていく作業も大事ですよね。事業や技術についての勉強をすると、自分が面白いと思える領域はどんどん広がっていくので、会社が求める役割と自分のしたい仕事が重なる部分がより大きくなっていくはずです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/b58a54d6ec1d4664a6934bcf27a2bad5/20240131_kakehashi_153%20(2024-02-05T10_22_07.040).jpg?w=1600&amp;h=1067" alt="" width="1600" height="1067"></figure>――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？松山：「論点を学べること」が重要だと思っています。要するに、何かの技術的な方針を決める際に「YESかNOか」は企業や人によって判断が分かれます。でも「何を判断軸として方針を考えなければならないか」という技術的な論点は、どんな企業や人でも似通っているはずなんです。先人たちが何を論点として挙げてきたのかを学ぶことで、より良い決断をできるようになると思います。荻野：私は勉強会などに参加して、参加者同士で悩みを共有したり、すでに他の人が経験した事例を教えてもらったりすることがよくあります。やはり、情報交換をすることでお互いにとっての学びになりますし、それによって業界全体が前進していくと思うんですね。エンジニア仲間と飲み会などでワイワイ話して、優秀な人たちからいろいろな事例やノウハウを聞けると、いつも元気をもらえます。エンジニアとしてたくさんの仲間を作ることや、その仲間たちと良い議論をすることは、キャリアを豊かにしてくれると思います。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションのもと、薬局DXを起点に日本の医薬業界の課題解決に取り組むヘルスケアスタートアップです。今回はカケハシの黎明期から同社で働き薬局体験アシスタント「Musubi」のテックリードを務める松山哲也さんと、2023年10月に入社し新サービスの開発に取り組むソフトウェアエンジニアの荻野淳也さんにインタビューしました。



「事業の目標」を踏まえて技術的方針を決める。薬局業務DXスタートアップが急成長できた理由

キャディ株式会社の図面データ活用クラウド「CADDi DRAWER」の開発・運用を担う​​DRAWER事業本部のVPoEとして、元Sansan株式会社 CTOの藤倉成太さんが就任しました。今回はキャディ CTOの小橋昭文さんと藤倉さんにインタビューしました。


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