開発組織が採用するプログラミング言語やアーキテクチャ、組織構造には、企業の経営方針やビジネスモデルが反映されるケースが多いです。たとえば「マルチプロダクト展開をしたい」「特定事業を短期間でグロースさせたい」といったコンセプトを掲げているならば、それに適した技術選定や組織設計が行われるのです。「飲食をもっと楽しくおもしろく」というミッションのもと、飲食店向けのモバイルオーダーや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の技術選定指針

「サービスが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年間プロダクトを開発。ミニマムな体制で効率的な価値検証を行う知見

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


「Startup CTO of the year 2023」獲得。世界トップクラスの最適化技術を有するALGO ARTISの開発思想

ENECHANGE株式会社でフロントエンドエンジニアおよびテックリードを務めている小野と申します。私が所属しているエネチェンジ事業部では、電気とガスの料金シミュレーションサービス「エネチェンジ」を開発しています。この記事では、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。<h2 id="h47a2082ce8">リプレース前の技術スタック</h2>リプレース前の「エネチェンジ」のフロントエンドは、jQueryがメインで使われていました。たまに、HTML（正確にはRailsのerbテンプレート）に直接scriptタグで記述されていることもあり、ルールが整備されておらず、既存のコードを読み解くのが大変な状況でした。加えて、Vueの2系を一部導入しており、同じページの中にjQueryで制御している部分とVueのコンポーネントで記述されている部分が混在していました。それも、コードを難解にする大きな要因でした。<h2 id="h6e4c81a0fd">リプレースに向けた技術選定</h2>最初、Vue2を使っていると聞いたときは、Vue3への移行に気持ちが傾きました。しかし、実際のコードを見てみると、そもそもVue2が使われているのはごく一部であり、Vueの資産を活かすことはほとんど考える必要がないと判明しました。そのため、フラットな視点で、今導入するならReactとVue3どちらが良いかを検討することになりました。調査する前から、明らかにReactが良いだろうとは思っていたのですが、技術選定にあたっては自分や周りの人を納得させられるだけの根拠が必要です。そこで、ライブラリのダウンロード数や、他社の事例などを調査しました。ReactやVueを拡張したフレームワークであるNext.jsやNuxtも併せて調査しました。2022年4月当時、npm trendsでダウンロード数を比較した結果、React + Next.jsがVue + Nuxtに圧倒的な差をつけて使用されていることが判明しました。↓当時の React と Vue の npm trends のグラフ<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5fd95a4d4db14d538f7ab47dae8099ae/image%20(1).png" alt="" width="2048" height="742"></figure>↓当時の Next と Nuxt の npm trends のグラフ<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/3fbfbfd1acd24bcc983322789bbc1dc5/image.png" alt="" width="2048" height="744"></figure>また、リプレースの事例を調査したところ、Vue→Reactに移行したという記事はたくさん見つかりましたが、その逆は一つも見つかりませんでした。もうこの時点でReactが良さそうに思えましたが、単にReactの方が多く使われているというだけであり、なぜReactまたはVueを使うのかについてはまだ調べられていません。そこで、数多くの技術記事を読み込み、また、自分自身が両方触った経験も踏まえ、それぞれの特徴をまとめました。React + Next.jsの特徴<ul><li>TypeScriptとの相性が良い</li><li>Vueに比べ、品質の担保や開発者体験に優れている</li><li>Nuxtは覚えることが多いのに対し、Next.jsはシンプルで覚えることが少ない</li></ul>Vue + Nuxtの特徴<ul><li>マークアップを直感的に書ける。ReactのJSX記法に比べてとっつきやすい</li><li>コンポーネント単位のCSSがデフォルトでサポートされている</li><li>Vue3 + Nuxt3の登場によりTypeScriptのサポートが手厚くなった<ul><li>逆に言えば当時は過渡期で、主要ライブラリのVue3対応が終わらないと手を出しづらかった</li></ul></li></ul>このようにまとめることによって、どちらを選ぶべきかの方針が見えてきました。一言で言うと、品質や開発者体験を優先するならReact、新人育成のしやすさを優先するならVueという方針で選ぶと良さそうです。当時の社内ではジュニアレベルのエンジニアを育成するということはあまりなく、品質や開発者体験を優先するという判断で、Reactを選択することになりました。付け加えると、Reactで開発したいエンジニアが増えていることから、採用にも良い影響がありそうというのも一つの理由となっています。<h2 id="h64ba7c16c2">どのようにリプレースしたか</h2><h3 id="h80f1e5b496">静的なページはNext.jsで</h3>React化を進めるにあたり、まずはLPなどの静的なページから移行を始めることにしました。なぜなら、LPは以前から速度を改善したいという要望があり、リプレースするにはちょうどよかったためです。大きな方針としてはReactを使うことになっていましたが、リプレースするページが決まったところで、さらに詳細な技術選定をする必要が出てきました。そこで、表示速度やSEO面で有利になり、かつ開発者体験も良いNext.jsのSSGを使うことにしました。また、CSSの書き方についてもいろいろ調べたり実際に触ってみたりした結果、使いやすくて利用者も多いEmotionを使うことにしました。詳細な技術スタックは下記のようになりました。<ul><li>Next.js</li><li>TypeScript</li><li>Emotion</li><li>Jest</li><li>ESLint</li><li>Prettier</li><li>Storybook</li></ul>最初の1ページは、ほぼ私一人で開発を進めていき、基盤作りもかねてリプレースをしました。正直、思っていたよりも大変でした。ページ内のすべての要素をNext.jsで実装し直す必要がありましたし、一部Railsから電力会社のプランなどのデータを引っ張ってきて表示する必要もありました。そのために、Rails側にAPIを実装しなければならないのですが、そのAPIも私が開発しました。また、インフラの構成としてはAWSのCodeBuildでビルドし、それをS3にアップロードするという形をとりました。インフラの構築自体はインフラチームにお任せしましたが、構成を考えるところや、ビルド設定ファイルの作成は私が行いました。CodeBuildを使うのは初めてだったので、ビルドが成功するまで設定をいろいろと変えながら試行錯誤をくり返しました。最初の1ページを完成させるのに大体4カ月ぐらいかかりました。苦労したかいがあり、ページ速度はPageSpeed Insightsのスコアが40点台だったのが、70点台にまで大幅に改善しました。それに自分自身のスキルアップにもつながる貴重な経験でした。その後は、他のフロントエンドエンジニアにも協力してもらいながら、さらに各ページのリプレースを進めました。半年ぐらいかけて、ページ数でいうと1000ページ以上のリプレースに成功しました（ページの種類でいうと4種類ほどです）。リプレース後のページは表示速度が改善したとともに、ソースコードも読みやすくなり、保守しやすくなったと思います。<h3 id="h08794f3c7e">「マイエネルギー」の開発でReactの導入が進んだ</h3>2023年10月にスマートメーターのCルート開放が実施されることが決定し、我々もスマートメーターのデータにアクセスできるようになりました。それに向けて、そのデータを活用するサービス「マイエネルギー」を開発することになりました。新規開発ということで、当然フロントエンドはReactを使用しました。ただ一つ問題があり、それはスケジュールがタイトだということです。ENECHANGEは「電力データを活用した機能を日本で一番早くリリースする」という方針を掲げていたので、2023年10月のリリースが決まっていました。また、諸事情により開発に入る前の工程（企画・デザインなど）が遅れていたため、2カ月ちょっとでリリースできる状態まで持っていく必要がありました。そこで、今回はページ全体をリプレースするという方法ではなく、新規要素のみをReactで実装し、共通パーツ（ヘッダーやサイドバーなど）はRails上の既存のものをそのまま使うという方針で進めました。これにより、工数を最小限に抑えることができたと思います。なお、それを実現するには、Rails上でReactのアプリケーションを読み込む必要があります。それの基盤作りも苦労したので少しお話ししたいと思います。今までのフロントエンドの構成は、Vueのソースコードがwebpackでビルドされる仕組みになっていました。このwebpackが非常に遅く、開発サーバーの起動やビルドに1分近くかかっていました。この仕組みをそのまま流用すれば楽に開発環境を構築できますが、これだけ遅いと開発スピードに支障をきたしてしまいます。そこで、チームで話し合った結果、Viteを使うことにしました。その結果、一瞬で開発サーバーが起動するようになり、ソースコードの変更も一瞬で反映されるので、かなり開発者体験が良くなりました。なお、Viteで構築したものをRails側で読み込めるようにするのも苦労しました。調べたところ、vite_railsというGemを使うのが一般的らしく、逆にGemを使わずに自力でRailsとViteを連携させた事例は一つも見つかりませんでした。しかし、実際にvite_railsを使ってみたところ、以下のような問題が発覚しました。<ul><li>Viteの設定ファイルやpackage.jsonなどがRailsのルートディレクトリに置かれてしまう<ul><li>上記はreactディレクトリに置きたいのに、それができず、ファイルが散らばってしまう</li><li>設定ファイルの場所を変更するオプションもなさそう</li></ul></li><li>そもそも、フロントエンドのためにGemに依存するのはあまりやりたくなかった</li></ul>念のため、他のフロントエンドのメンバーにも意見を聞いてみたのですが、やはりvite_railsは使いたくないという意見で一致したので、Gemを使わずに自力でRailsとViteの連携を実装することにしました。<a href="https://ja.vitejs.dev/guide/backend-integration.html" target="_blank" rel="noopener noreferrer nofollow">https://ja.vitejs.dev/guide/backend-integration.html</a> を参考にしながら、実装を進めました。これも試行錯誤のくり返しでしたが、バックエンドエンジニアにも相談しながら、なんとか実装できました。今回、バックエンドの実装が終わる前にフロントエンドの開発が始まりました。そこで、バックエンドのAPIが完成しなくても進められるように、OpenAPI（Swagger）のファイルを作成し、そのAPI定義をもとにフロントエンドとバックエンドの開発を並行して進めました。おかげで、なんとかスケジュール通りにリリースすることができました。<h2 id="h28b62bc2c0">今後の課題</h2>このように1年半にわたる「React化」の結果、モダンなフロントエンド開発が進んだとはいえ、まだまだレガシーなコードがたくさん残っています。特にVueで書かれた箇所が結構読みにくくて管理コストがかかっているので、その部分を優先的にReact化していきたいなと考えています。また、「マイエネルギー」の開発で、フロントエンドとバックエンドの連携に関する課題が見えてきました。APIスキーマをあらかじめ共有することによりうまくいった部分もありますが、時間がなかったこともあって、どのような値を入れてほしいのかについての意思疎通が十分にできていませんでした。結果として、意図したものとは異なる動きになっている箇所が出てしまいました。今後は、APIスキーマの説明をできる限り詳細に書くことや、必要に応じてフロントエンドとバックエンドですり合わせのミーティングを実施するなどの工夫をしていきたいです。<h2 id="ha214098e44">まとめ</h2>ENECHANGEにおけるフロントエンドのリプレースプロジェクト「React化」について紹介しました。フロントエンドのリプレースは決して簡単なことではありません。既存のレガシーなコードを読み解きながら、最新の技術で実装し直す必要があり、高度なスキルが求められます。だからこそ、リプレースは、エンジニアがスキルアップするチャンスです。私もこのプロジェクトを通して、エンジニアとしてのスキルに磨きがかかった実感があります。また、React化は、開発組織の士気を高めることにもつながったと思います。メンバーからは「新しいコードは読みやすくて修正しやすい」と言ってもらえました。本当にやってよかったなと思いました。最近は弊社だけでなく、さまざまな現場でフロントエンドのリプレースを進めていたり、検討していたりすると思います。スキルアップしたいエンジニアのみなさん、チャンスがあれば、ぜひチャレンジしてみてはいかがでしょうか。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

ENECHANGE株式会社でフロントエンドエンジニアおよびテックリードを務めている小野さんが、長年の開発によって積み重なったフロントエンドの技術負債をどのように解消しているのかについてご紹介します。

レガシーなフロントエンドをリプレースするプラクティス。エネチェンジが挑む「React化」

<a href="https://identify.co.jp/" target="_blank" rel="noopener noreferrer nofollow">identify株式会社</a>は、個人が販売した動画素材を企業が購入して、マーケティングへ活用することを支援する「DeLMO」というクリエイタープラットフォームを運営しています。その「DeLMO」では、クリエイターがスキマ時間に動画を撮影・販売し、報酬を得ることができる複業支援サービス「<a href="https://www.delm0.jp/" target="_blank" rel="noopener noreferrer nofollow">DeLMO for creator</a>」と、企業が縦型ショート動画素材を簡単に収集し、クリエイティブ制作に活用できるサービス「<a href="https://biz.delm0.jp/" target="_blank" rel="noopener noreferrer nofollow">DeLMO for advertiser</a>」の2つを提供しているのです。同社の取締役CTOを務めるのが岩崎 裕馬さん。彼は水天宮前（茅場町、人形町、日本橋）にあるレストラン「<a href="https://winenabe.jp/" target="_blank" rel="noopener noreferrer nofollow">ワインと鍋</a>」のオーナーでもあるという変わった経歴の持ち主です。これまで岩崎さんは、CTOとしてどのような技術選定を行ってきたのでしょうか。<h2 id="h540e03485e">GoやNext.jsを採用。“攻めた”技術選定をした意図とは</h2>――このインタビューでは、岩崎さんがidentifyで取り組んできた技術的意思決定の事例について伺います。「DeLMO」の技術選定においては、「長期的に見た場合のプロダクト開発効率」「エンジニアの採用難易度」「自分自身にとっての面白さ」という3つの観点を大切にしました。まず、サーバーサイドの言語としてGoを採用したことについて話します。私がソフトウェア開発において大切にしているのは、改善をスピーディーにくり返せることです。プロダクトを作る際には、自分たちの立てた仮説がそもそも本当に正しいのかわからない状態で開発を進めることが多いです。もし仮説が誤っていたり、方向性を変えるべきだったりする場合には、柔軟に軌道修正することが必要になります。その際、Goではある程度の型の支援があるため作り直しやリファクタリングが容易なんです。何か問題があっても、ビルドが失敗するためすぐに気づけます。それから、コードベースの規模が小さくても大きくても、かけたエネルギーに対して書けるコードの量が一定であるのがGoの良いところです。Goでは、プロダクトの規模が小さいフェーズでも、大きくなってからも、エンジニアが1のエネルギーを使ったら1のコードを書けます。言語やフレームワークによっては、プロダクトの規模が小さいうちは1のエネルギーで10のコードを書けるけれど、規模が大きくなったら10のエネルギーでようやく1のコードが書けるといったように徐々に開発生産性が落ちるものもあります。Goの場合はそれがないですね。開発効率という観点で言えば採用技術としてRuby on Railsなども候補に挙がりましたが、現代のWebアプリケーションはSPAを取り入れていることによってフロントエンドとバックエンドが分離されることが多く、バックエンドはJSONを返却する役割に徹することがほとんどです。そこで、「Goを使ってもそこまで開発効率が変わらないのではないか」と考えました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/c5c092a0ac6c4139b58adeb1be058d32/image4.jpg" alt="" width="1999" height="1334"></figure>「エンジニアの採用難易度」についても話すと、RubyやPHPなどは採用候補者がたくさんいる言語であるものの、初学者のエンジニアの割合も高いため、スキルの高いエンジニアかどうかの判断が難しいかもしれないと感じていたんです。反面、当時Goをやっていたのは技術的好奇心の強いエンジニアが多かったため、Goを採用することでスキルの高い方と出会いやすくなるのではないかという感覚を持っていました。また、「自分自身にとっての面白さ」については、私は個人的に新しい技術を使うのが好きなので、そういった点からもGoを面白いと感じています。それに、Goは使用できる文法が良い意味で限られているため、コードを書く際に迷いが少ないです。仮にモチベーションが低いときであっても、一定の開発生産性をキープできます。――フロントエンドに関してはいかがですか？フロントエンドはNext.js＋TypeScriptを採用しています。私がidentifyに参画してプロダクトを開発し始めたのが2019年7月なのですが、当時はVue.jsとNuxt.jsが全盛期でした。でも、「フロントエンドにおいてもいずれは型安全性が重視されるようになるため、Vue.jsとNuxt.jsではなく、TypeScriptフレンドリーなフレームワークが流行するだろう」と予想していました。そして、私はモダンなフロントエンド開発のスキルがそれほど高くないため、何か大きめのフレームワークのエコシステムに乗って開発を進めたいという思いもありました。そんなタイミングで、2019年7月にNext.js 9がリリースされ、Dynamic Routingがサポートされたんです。これなら実戦投入できると思い、採用を決めました。当時、フロントエンドのスペシャリストである<a href="https://twitter.com/mizchi">mizchiさん</a>が「Next.jsを使うといい」という話をしていたのも、導入する理由になりました。結果的に、サーバーサイドはGoでフロントエンドはNext.jsという構成はスタートアップでは当たり前に使われる構成になりました。これによって、エンジニアの採用にもかなりプラスの影響が出ています。それから、フロントエンドとサーバーサイドの両方に関係する話として、GraphQLを使いたかったためgqlgenのライブラリを採用しています。知人であるgfxさんから「GraphQLはいいぞ」という話を聞いていて、きっと今後流行するだろうなという予想をしていました。私はgfxさんの技術的な審美眼を信頼しており、実際に調べてみると利点が大きかったため、採用を決めました。<h2 id="hea581b21e4">CIや単体テストなどを初期フェーズから整備しておくべきだった</h2>――ここまでは技術選定のポジティブな点ですが、その逆に反省点はありますか？事業を立ち上げた当時は、売れるプロダクトを作ることが第一だと考えて、機能開発を優先して技術的負債を蓄積してしまいました。ですが、それらを後から解消するのにかなり苦労したため、もっと早めのフェーズから課題に向き合っていくべきだったと思います。――この記事を読まれる方のなかにも、同じようにアーリーフェーズのスタートアップで働いており、なるべく早急に売れるプロダクトを作らなければならない状況のエンジニアもいるかと思います。その方々に、ご自身の経験を踏まえてアドバイスはありますか？アプリケーション開発の定石を理解したうえで、100点は無理でも70点くらいの開発環境の整備を目指すのがいいと思います。“70点くらいの状態”の具体例を挙げると、1つ目はCI環境を構築して、Lintや単体テストなどが自動実行される状態を作ることです。2つ目は単体テストを書いておくこと。決してすべての分岐を通るようにする必要はなくて、特定メソッドの1つの分岐しか通らないテストだとしても構いません。テストが全くない状態のアプリケーションにテストを足していくのと、最低限のテストが書かれている状態のアプリケーションを改善していくのとでは、労力がまるで違います。3つ目は、インフラの環境をなるべくマネージドサービスに切り替えること。私たちはかつて、Jenkinsを用いてジョブの実行などを行っていました。でも、サーバーの管理作業を自分たちで行う必要があるため運用の工数がかかるとか、ミドルウェアやインストールされている言語のバージョンを上げづらい、スケーラビリティに難があるなどの問題が生じていたんです。現在はJenkinsを脱却して、すべてのジョブをCloud Run jobsとBatch for Google Cloudで動かしています。これによりシステムのポータビリティが向上し並列実行も容易になりました。「DeLMO」では事業の特性上、1日あたり数百件から数千件の動画の変換処理が発生します。そうした処理をBatch for Google Cloudで動かせるようにしたことで、変換がスピーディーに終わるようになりビジネス改善やコスト削減につながりました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/da876eed70a74f6caaa52c84060d5df9/image1.jpg" alt="" width="1999" height="1334"><figcaption>インタビュー取材は、岩崎さんがオーナーを務める「ワインと鍋」にて実施した。「クオリティの高い料理やワインを手頃な価格帯で提供したい」という思いから、岩崎さんは同店をオープン。「ワインと鍋」はITコミュニティ内で知名度の高い店舗であり、来店する顧客の8割以上はソフトウェアエンジニアやプロダクトマネージャー、デザイナーなのだという。</figcaption></figure><h2 id="hbdd0849bab">採用するライブラリを“取り替え容易な状態”にしておく</h2>――他の技術選定の事例はあるでしょうか？これは失敗談なのですが、社内向けの管理画面を作る際に、「UIライブラリを使って楽ができないだろうか」と思ってAnt DesignやHeadless UIを採用しました。Ant Designは、中国のAlibaba社が開発した、UIを作成する際に役立つ多数のコンポーネントを備えたUIフレームワークです。また、Headless UIについては私たちが用いているTailwind CSSとの親和性から選択肢に上がりました。素早く管理画面を作っていく必要があったことや、社内向けの管理画面だから3年くらい経てば作り変えればいいという思いもあり、これらのライブラリの導入を決めたんです。Ant Designはとても便利なライブラリなのですが、Reactのバージョン18との相性が悪く、特定のコンポーネントがかなりCPUを消費するようになってしまいました。Ant DesignのISSUEなどを追ってみたところ、その問題が解消される見込みはありませんでした。また、思っていたよりもAnt DesignやHeadless UIでの開発がしづらかったこともあり、当初の予想よりも早めに別のライブラリに切り替える必要性が生じてしまったんです。――この事例を踏まえての学びはあるでしょうか？これはUnix哲学にも通じる部分ですが、なるべく特定の役割だけを担うような薄いライブラリを使って、交換が容易な状態を維持しておくべきだと思いました。Ant Designはライブラリの担っている役割が広くて、UIに関する機能とFormの操作に関する機能をどちらも持っているんですよね。それもあり、React Hook Formを入れづらかったり、TypeScriptによる型の支援が受けづらかったりしました。幸い、管理画面の一部でしか使ってないライブラリなので、多くの苦労をせずに取り除けると予想しています。今後、Headless UIはshadcn/uiなどに切り替えていく予定です。余談ですが、これからのフロントエンドのUIライブラリにおいて大事なのは、「AIフレンドリーであること」だと私は思っているんですよ。基本的に、デザインのトレンドは数年スパンで変わりますから、どれだけ優れたライブラリであっても絶対に技術的負債になります。今後はそうした技術的負債を、人間ではなくAIが返済するような世界になっていくと予想しています。だから採用するUIライブラリも「AIが理解しやすいコードかどうか」を重要な判断軸にすべきだと思っていますね。<h2 id="h610163f11c">副業のメンバーに「わかりやすい正解がある仕事」をお願いする</h2>――それ以外の工夫はあるでしょうか？ライブラリのアップデートや型定義・単体テストの追加、技術的負債の解消といったタスクは「必ずやる必要があるが緊急度は低い仕事」です。そういった業務の多くを副業のエンジニアにお願いしているのは、identifyの開発組織の特徴だと思います。――副業のメンバーにうまくワークしてもらうために重要なことはありますか？まずは先ほどの説明にも通じますが、Lintや単体テスト、CI環境をきちんと整備することが大事だと思っています。私は副業や業務委託で参画した方に「既存コードを壊していいですよ」と言っているんですよ。要するに、機能が壊れることを恐れず、どんどんリファクタリングをやってほしいんです。仮に既存機能が壊れてしまったとしても、CIで守っているからすぐに気づけます。それから、「わかりやすい正解がある仕事」をお願いすることですね。たとえば「○○のライブラリのバージョンを○○に上げて、その状態ですべての機能が動く状態にしてほしい」とか「テストのカバレッジが○○％だけれど、これを○○％まで上げてほしい」などの要望であれば、目指すべき成果が明確なんですよね。認識の齟齬が生まれにくいので、副業のメンバーにも任せやすいです。<h2 id="h89ce011cd0">「すべてがアイデンティティになる時代をつくろう」</h2>――今後、岩崎さんがidentifyで実現したいことについても教えてください。identifyは「すべてがアイデンティティになる時代をつくろう」というビジョンを掲げていて、この状態に1歩でも近づけるように尽力していきたいと思っています。個人的な話をすると、私はもともと家が貧しかったのと低学歴だったため、いざ働くとなったときに就職先の選択肢が少なかったことを覚えています。そういった方々の選択肢を広げることに協力できたらと考えています。これまでどんなキャリアを歩んできた人でも、自分の個性を発揮して生きていける世界を作れたらいい。テクノロジーを活用することで生活や仕事のマイナスを取り除いて、みんなが楽しく生きられるような状態にしていきたいです。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/efa3a7ec2d094da1856bd0b3e08c5c3e/image3.jpg" alt="" width="1999" height="1334"></figure>――すてきなビジョンだと思います。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？「何の技術を採用すべきか」に、わかりやすい正解はないと思っているんですよね。でも、技術的意思決定において「何を考慮すべきか」については、方法論がパターン化されていると思うんですよ。そういった知識を持っておくと、自分自身も明確な判断基準に基づいて決断できますし、他の人たちにも納得感を持ってもらいやすいと思います。特定の事例を学ぶというよりも、事例の裏側にある“技術的な意思決定の意図や背景”を学ぶことが大切です。そして、その意思決定に用いる変数は事業の状況や世の中のトレンドによっても変化します。たとえば、最近では生成系AIが流行しており、それが技術選定にも影響を与えています。数年前までの自分であれば、“AIフレンドリー”という言葉は絶対に使っていなかったと思うんですよね。だからこそ、適切な意思決定ができるように、技術選定の方法論やその判断材料となる情報などを、常に学んでいくことをおすすめします。取材・執筆：中薗昴撮影：山辺恵美子取材協力：<a href="https://winenabe.jp/" target="_blank" rel="noopener noreferrer nofollow">ワインと鍋</a>提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

identify株式会社は、個人が販売した動画素材を企業が購入して、マーケティングへ活用することを支援する「DeLMO」というクリエイタープラットフォームを運営しています。同社の取締役CTOを務めるのが岩崎 裕馬さん。彼は水天宮前にあるレストラン「ワインと鍋」のオーナーでもあります。これまで岩崎さんは、CTOとしてどのような技術選定を行ってきたのでしょうか。


「TypeScript」の記事一覧