「生きるに、遊びを。」をミッションとし、日本最大級の遊び予約サイト「アソビュー！」やレジャー業界の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の小橋昭文さんと藤倉さんにインタビューしました。


前代未聞の速度で成長する「CADDi DRAWER」。その根幹を支える組織作りのビジョンとは

株式会社Kyashは「新しいお金の文化を創る。」というビジョンのもと、デジタルウォレットアプリ「Kyash」を展開する、Fintechスタートアップ企業です。Kyashでは決済に関する機能を内製開発し、リアルタイム通知やカードロック、上限金額設定などユーザビリティの高い機能を実装してきました。また、「Kyash Card」のリリースや資金移動ライセンスの取得、3Dセキュア対応など、デジタルウォレットとしてさまざまなチャレンジをしています。同社の開発組織を支えてきたのが、VP of Engineering （以下、VPoE）の小西裕介（通称：こにふぁー）さんです。「組織作りやプロダクトの方針策定、採用、開発など、VPoEとしての業務内容は企業のフェーズに応じて変化してきました」と語るこにふぁーさん。今回はこにふぁーさんに、Kyashがどのような判断基準のもと、開発組織の方針を策定してきたのかを聞きました。<h2 id="h50887dfa77">Kotlin Multiplatformの導入で開発効率化を実現</h2>――今回のインタビューでは、過去に取り組んだ技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきたいです。まずはモバイルアプリ開発の事例です。KyashではAndroid・iOSの両方でアプリを展開しています。通常であれば、Android側はKotlin、iOS側はSwiftを用いて、画面やビジネスロジックなどをそれぞれのプラットフォームで別々に実装することが多いですよね。Kyashも昔はそうだったのですが、ある時期からKotlin Multiplatformという仕組みを導入しました。画面はそれぞれKotlinとSwiftで別個に書くのですが、ビジネスロジックやデータ取得の処理などをKotlin Multiplatformで共通化したんです。これは、当時モバイルアプリチームのエンジニアリングマネージャーを務めていた<a href="https://twitter.com/kkagurazaka">@kkagurazaka</a>が推進してくれた施策です。――どのような経緯でKotlin Multiplatformの採用を決めたのでしょうか？もともと、モバイルアプリチームのメンバーたちは「AndroidアプリとiOSアプリの両方に同じ処理を別々で実装するのは二度手間だ」とか「仮にAndroidアプリ側のエンジニアの手が空いていても、Swiftを書けないとiOSアプリ側のヘルプに入ることができない」といった課題を抱えていました。その状況の改善に向けて、当時のエンジニアリングマネージャーがみんなを集めて、「1年後に、Kyashのモバイルアプリ開発の状況はどうなっていてほしいか」の認識を合わせるためのミーティングを実施したんです。そのミーティングでは、「なるべくAndroidアプリとiOSアプリでロジックを共通化して、爆速で開発できるといいよね」という話で盛り上がりました。もしコードベースを統合して開発できれば、AndroidアプリとiOSアプリの両方で同じ処理を書かなくて済みます。かつ、人員のアサインもかなり柔軟にできるようになります。そこで、Kotlin Multiplatformを導入してロジックを共通化しました。ただ、画面に関してはそれぞれ別個で実装するほうがユーザー体験のよいUIを実現しやすいので、そこは共通化しない方針を選びました。――Kotlin Multiplatformの導入における工夫はありましたか？当時のエンジニアリングマネージャーがかなり上手にプロジェクトを推進してくれて、導入がスムーズにいきました。具体的には、Kotlin Multiplatform導入プロジェクトの初期フェーズで、そのエンジニアリングマネージャー自身が一気に手を動かして手本になるようなコードを書き、その内容を共有したんです。また、業務委託のメンバーでKotlin Multiplatformに詳しい方がいたので、その人からも知識を上手に吸収して、アプリの一部分をスピーディーにKotlin Multiplatformへと移行しました。この一連の流れが、移行プロジェクトにおいてかなり有効に働きました。こうした技術刷新のプロジェクトは、うまくいかないパターンがあります。たとえば、新しいアーキテクチャをそもそも設計しきれなかったり、設計方針は決まったものの移行プロジェクトの進め方がまずくて頓挫したり。でも、この事例ではそれが起きなかったんです。この事例を踏まえた教訓として、まずは一部分でもいいから新しい技術を導入して運用に乗せること。そして、小さな成功体験を作ってそこから範囲を広げていくことの重要性が挙げられると思います。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/bfa09fbef2584500a1c837520221bd54/image4.jpg" alt="" width="1999" height="1334"></figure>――Kotlin Multiplatformを導入したことによる成果はいかがでしょうか？開発効率が良くなり、タスクのアサインの調整もしやすくなりました。それから副次的な効果として、他の部分をKotlin Multiplatformに載せ替えていく作業そのものにエンジニアたちが楽しさを覚えて、モチベーションが向上しています。新技術の導入プロジェクトですし、移行にあたって考えることが適度な難易度で存在しているので、技術的探究心をくすぐられる状況になったんだと思います。<h2 id="h207d811fa9">組織の形態がアウトプットやアウトカムにも影響を与える</h2>――他の事例についてもお話しください。次は組織についての話で、これは失敗した事例なのですが、2022年頃に「開発組織全体でタスクの優先順位づけをして、最も優先度が高いタスクから順に担当するプロジェクトチームを組成して進めていく」という方針を選んだことがありました。社内のリソースをなるべく有効に活用するための方針策定で、ウォーターフォール開発などでは一般的に用いられる方法ですよね。エンジニアリングマネージャーたちとも会話をしたうえで、「今のフェーズならばこの方針が良いだろう」ということで決めました。良かった点として、予定していた機能は確かにリリースできました。でも、だんだんとメンバーが主体的に物事を考えにくくなってきて、タスクの割り振りや人のアサインなどを考えるのが中央集権的になり、マネジメント層の負荷がどんどん大きくなってくるんですよね。そしてメンバーからマネージャーに対して、「次は何をやりましょうか」という趣旨のコミュニケーションが増えていきます。なぜなら、優先度の高いタスクというのは事業を左右するくらいの影響度があるので、企業や開発組織全体の状況を鑑みたうえでリソースの配分を決める必要があるからです。となると、マネージャー以上のレイヤーでないとなかなかリソースプランニングができません。そうすると、だんだんとメンバーは「これをやるべきだと思います」「私がこれをやります」といった意見を出しにくくなり、「何かを上長やプロダクトマネージャーが決めてくれることが当たり前」というスタンスになってしまうんです。自発的に動かなくなってしまいます。また、障害対応のように突発的に発生するタスクもすべてマネージャー以上のレイヤーが判断して優先順位づけをせざるを得なくなってしまいました。結果として、調整作業が大変だったわりにはアウトプットも増えず、プロダクトとしてのアウトカムもついてこない。そして、エンジニアリングマネージャーやプロダクトマネージャーも疲弊して、メンバーのモチベーションも下がるという悪循環になってしまいました。現在はその仕組みをやめて、もっとみんなが主体的に動けるような組織にしていくために、プロジェクト単位ではなくプロダクトのフィーチャーごとにチームを分割しています。例を挙げると「ユーザーを新規に呼び込むことを担当するチーム」などで、昨年の11月にリリースされた新機能「Kyashコイン」を担当したのはそのチームです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/aba45b17735c41b48abdc84e6207229c/image1.png" alt="" width="1950" height="1024"><figcaption>「Kyashコイン」は「Kyash」での決済またはルーレットで獲得できる「Kyash」アプリ内のコインだ。ユーザーは貯まった「Kyashコイン」を使用して、人気商品に応募するチャレンジに参加可能になっている。</figcaption></figure>――この事例を踏まえて、チーム編成における読者へのアドバイスはありますか？『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』のように、組織構造のデザインパターンを紹介している書籍が世の中には存在します。そういった本をエンジニアリングマネージャーや事業責任者たちが読んだうえで、チームメンバーにも内容を共有し、チーム編成の方針を決めていくのが良いと思います。ただ、あくまでその知識はメンバー同士が共通認識を得て、考えるとっかかりにするくらいに留めるべきかなと思っていて。自社の組織構造をすべて書籍で紹介されているような「あるべき論」に当てはめようとすると、どこかで無理が生じると思うんですよね。ある程度、自分たちの組織の状況に合わせた調整や、チーム間での役割の越境なども必要だと考えています。<h2 id="he9c913acf6">「VPoE自身が手を動かすこと」が最善のケースもある</h2>――他にはどのような事例がありますか？VPoEとしての動き方に関する事例として、2023年の中頃から終わり頃にかけて「自分自身もプレイヤーとしてコードを書く」という選択をしました。Kyashでは多言語対応や「Kyashコイン」、ユーザー登録フローの改善など複数機能の開発が予定されており、かつ2023年中にそれらの成果を見たいという方針を打ち出していました。実現するためにさまざまな選択肢がありましたが、自分で手を動かそうと決めました。Kyash社内には、プレイヤーとして私より優秀なメンバーはたくさんいるんですよ。でも、社内のステークホルダーとの調整とかプロジェクトの進め方といった面で、私自身が直接的にプロジェクトに関与したほうが進めやすいのは確かでした。そこで、昨年の後半はそういった動き方をしたほうが良いと判断し、プレイヤーに徹しました。そうして各種の機能がリリースできたので、今後は徐々にチームから抜けて、より長期のスパンを見据えた仕事に手をつけていきたいです。――読者のなかにも、エンジニアリングマネージャーやVPoEなどを務めていて「自分自身が手を動かすべきか、そうでないか」を判断しなければならない局面に置かれている人がいると思います。どのような基準で方針を決めるべきでしょうか？「どのくらいのタイムスパンでどういった成果を出したいのか」によると思います。冒頭で述べたKotlin Multiplatformの事例のように「まずは誰かが短期間で目に見える成果を出して、その実績を踏まえて後続の作業を他の誰かに任せるほうがうまくいく」というケースもあります。その場合は、むしろマネージャーが率先して例を示すほうが良いですよね。私自身の事例のように、「2023年のうちに成果を見たい」という短期的なスパンでプロジェクトを進める場合も、自分が手を動かすほうが良い結果が出ると予想できます。でもこれが、たとえば数年がかりでプロジェクトを進めていきたいというように、より長期のタイムスパンでものごとを考える場合は、その役割を担ってくれる人を採用するなど組織作りにフォーカスした動き方になったと思います。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/a9cf076e94d14ddb846558e8637f68ac/image3.jpg" alt="" width="1999" height="1500"><figcaption>こにふぁーさんは2023年12月に「6年のスケジュールの変化」というブログ記事を公開した。このブログ記事内では、会社や組織の状況、自分自身の担当業務やライフスタイルの変化などに合わせて柔軟に働き方を変えてきたことが記載されている。VPoEの担う役割は固定的ではなく、臨機応変に変化していくものだという好例だ。</figcaption></figure><h2 id="h7d6aef9323">腰を据えて、Kyashの成長に貢献していきたい</h2>――今後、こにふぁーさんがKyashで実現したいことは何ですか？2023年にはいろいろなことが改善して、Kyashの事業や開発組織はすごく良い状態になってきました。VPoEとして、これをさらに良くしていきたいです。これは余談ですが、以前自分は他の人に「Kyashで働きませんか」と声をかけるとき、すごく緊張していたんですよね。スタートアップは事業がうまくいくかどうかが保証できないですし、その人の考えや働き方と、企業の文化とが合うかどうかもわからないですからね。「音楽性の違い」みたいなハレーションが起きる可能性もあります。だから、これまでは「この人をKyashに誘って、本当に幸せにできるだろうか」と考えてしまっていたんですよ。でも今は、徐々に自信を持って誘える状態になりつつあります。Kyashに所属していたことを、その人のキャリアにとってプラスにできると思います。それから、事業や組織と長く向き合い続けられる人になりたいですね。私は株式会社一休の執行役員CTOである伊藤直也さんを一方的に尊敬しているんですが、その理由として彼は一休という会社と真摯に向き合い続けていて、時にすごく悩みながらも「どうすれば事業に貢献できるか」ということをずっと考えているように見えます。それを見ると「格好良いな」と思うわけですよ。私はKyashで働き始めてから6年ですが、そのうちエンジニアリングマネージャーが1年半くらい、VPoEが2年くらいで、開発組織のリーダーとして働いた年数はまだまだ短いです。過去の職場も、長くて4年くらいで転職していたんですよ。だからこそKyashでは腰を据えて、長期的な目線で事業や組織を成長させていくことに挑戦したいですね。――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。書籍やWeb記事などを通じてエンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？一般論としてよく言われるのは、「他の方々の事例を疑似体験して、同じ轍を踏まないようにする」といったことですよね。それに加えて、特にインタビュー記事のようなコンテンツの場合、「その人の生の声が伝わること」はすごく重要だと思っています。「みんな、これくらい悩んでいるんだ」とか「誰しも失敗しているんだ」とわかるじゃないですか。「この人はこんなに頑張っているんだから、自分もやらなければ」という気持ちを持てるのも良い点です。「what we use」で以前取材されていた<a href="https://whatweuse.dev/article/toricls" target="_blank" rel="noopener noreferrer nofollow">株式会社カミナシの取締役CTOのHara Toriさん</a>は、実は新卒入社した会社の同期なんです。彼がいろいろな技術イベントやメディアなどに登場しているのを見ると、自分と比較してめちゃくちゃ焦るんですよね。そういった、自分の成長につながるような健全な焦りや悔しさを持てることも、他の方々の事例を学ぶことの価値だと思います。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

株式会社Kyashの開発組織を支えてきたのが、VPoEの小西裕介（通称：こにふぁー）さんです。今回はこにふぁーさんに、Kyashがどのような判断基準のもと、開発組織の方針を策定してきたのかを聞きました。

こにふぁー氏は何を基準に、開発組織の方針を決めている？ 事業・プロダクト・人の状況次第で変化するVPoEの動き方

ALGO ARTISは「社会基盤の最適化」というコーポレートミッションを掲げ、複雑で高度な運用計画策定業務の最適化を行う企業です。今回はALGO ARTISの取締役VPoEである武藤悠輔さんにインタビュー。「Startup CTO of the year 2023」の受賞者でもある武藤さんは、これまでどのような決断をして開発組織をけん引してきたのでしょうか。


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