イオン株式会社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」の受賞者でもある武藤さんは、これまでどのような決断をして開発組織をけん引してきたのでしょうか。


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

<a href="https://litalico.co.jp/">LITALICOグループ</a>では、障害福祉・教育・介護領域で300拠点以上の事業所を運営し、主に発達障害のある児童への教育や、働くことに障害のある大人への就労支援などを行っています。また、そうして培われた支援や事業所運営のノウハウをもとに、当事者やご家族や福祉従事者向けのWebサービス、福祉事業所や学校向けのSaaSなどの数多くのプロダクトを提供しています。こうした数々のサービスの可用性や信頼性を高く保ち、かつ開発生産性も向上させるには、適切なアーキテクチャ設計が必要不可欠です。これまで、LITALICOではどのような技術的意思決定をしてきたのでしょうか。今回は同社の執行役員CTO/エンジニアリング統括部長である市橋佑弥さんにインタビューしました。<h2 id="h514061eba8">目的を達成するための技術選定</h2>――最初に、LITALICOの開発組織において技術選定で大事にしている考え方をお伺いしたいです。私たちは多種多様なプロダクトを運営しているため、それを前提とした技術選定が必要になります。具体的には、各プロダクトの特性に合わせた技術戦略を、プロダクトチームのリードをしているエンジニアに立ててもらうケースが多いです。そのリードエンジニアには大きな裁量を渡して、それぞれのプロダクトにおけるCTOのような役割を担ってもらっています。私たちの技術選定において共通しているのは、あくまで「目的を達成するための技術選定」であるということです。企業やプロダクトの大きなビジョンがまずあり、ユーザーに届けたい価値や解決したい課題がその下にあります。技術はそういった目的を実現していくための手段だと捉えています。一方で、技術の本質を見極めなければ適切な判断はできないため、技術が好きなエンジニアが多いのもLITALICOの開発組織の特徴です。他に技術選定に影響を与える要素としては、障害者総合支援法の改正が挙げられます。これは障害のある方への支援を定めた法律なのですが、3年ごとに法改正が行われます。この改正では、障害福祉サービスを運営する上でのルールや給付費の報酬体系などの変更があります。そのため、プロダクトのロジックもそれに合わせて変えていく必要があるんです。――LITALICOで用いている技術スタックについても知りたいです。複数のプロダクトがあるため扱っている技術の差はありますが、基本的にはインフラはAWSを用いており、Amazon ECS on AWS Fargateを採用しています。SaaS系プロダクトを例にすると、フロントエンドはVue+Nuxt.jsでSPAの設計になっているシステムが多いです。バックエンドは主にPHPとLaravelで作っていますが、部分的にGoやJavaを採用しています。たとえば、パフォーマンスが求められる箇所はGoを、帳票出力の処理でJavaを採用するなどですね。その他、toC向けのWebサービスではRuby on RailsやReact.jsなどを採用しています。また、SaaS系プロダクトでは扱う業務ロジックも複雑かつ量が多いため、DDD（ドメイン駆動設計）を設計に取り入れてサービスを分割しています。関心事によってシステムを分離しているため、マイクロサービスというよりはもう少し粒度の大きい分割の仕方です。1つのプロダクトごとに、20〜30くらいの小さなサービス群から構成しています。DDDを導入した経緯については、この後に話します。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/55e5cdca3d01491586dd3bfaf49d5b8e/image1.jpg" alt="" width="1999" height="1334"></figure><h2 id="h109b7db7d2">DDDを導入。そして法令単位でシステムを分割</h2>――ここからは、過去に取り組んできた技術的な意思決定の事例を伺います。まず、先ほど述べた法改正に関するアーキテクチャ設計の事例をお話しします。障害者総合支援法では、レセプト（給付費計算）の不備があった際などに過去のデータを最大で5年分さかのぼって参照するケースがあるため、過去の法令用のロジックもプロダクトにそのまま残しておかなければなりません。私がLITALICOに入社したのは7年ほど前だったのですが、当時は「どの法令を用いて処理を行うか」を、プロダクトのコードの中にたくさんの条件分岐を書くことで判定していました。しかし、この実装方法にはいくつもの課題があります。法改正のたびに条件分岐が増えていくため、徐々に複雑性が増します。既存のコードに手を入れることになるので、改正後の法令のテストだけではなく改正前の法令のテストもすべて実施する必要が生じます。そこで対応策として、設計手法としてDDDを取り入れサービス分割をした上で、障害者総合支援法における給付費計算を担うような部分を、法令の年度ごとにリポジトリを分けて別々のアプリケーションとしてデプロイする方針を選びました。そして、リクエストの内容に応じてALBで適切なアプリケーションに振り分けています。――アプリケーションではなく、インフラで分岐させたということですね。はい。これによって新しい法令に対応する際に、古い法令の側のアプリケーションには一切手を入れずに済みます。古い法令の側のロジックが壊れないことを保証できますし、テストにかかる工数もまるまる削れるんです。そして、アプリケーション内には法改正に起因した条件分岐が入り込まないので、実装がシンプルになります。――この事例を踏まえて、読者に伝えたいことはありますか？私はこれまでのキャリアでアプリケーションからインフラまでさまざまな領域のエンジニアリングに携わってきたため、この事例で「ALBで振り分ければよい」というアイデアが浮かびました。もし、設計をするエンジニアがアプリケーションのことしか考えていなければ、こうした分岐をアプリケーションで実装する案しか浮かばなくなってしまいます。だからこそ、インフラやデータベース、アプリケーションといった幅広い技術領域に触れておくことをおすすめしたいです。<h2 id="hb97d45da1a">開発にドメイン知識が必要なロジックを共通基盤化する</h2>――3年ごとの法改正に対応したシステム改修について、今後さらに改善したい点はありますか？各種の障害福祉サービスでは、給付費計算を行ったうえで国民健康保険団体連合会を通じて自治体に請求処理をかけるような業務が発生します。LITALICOはそういった業務で扱えるようなシステムをSaaSや社内システムなどでたくさん持っているんですね。そして、そうした計算処理や帳票作成の処理などは、各システムで処理内容が共通する部分や似通っている部分がたくさんあります。そこで、そのコアロジック部分を切り出した共通基盤を作り、各プロダクトからその共通基盤を呼び出すようなアーキテクチャを構築しています。この移行作業を、今まさに進行中です。――基盤構築の意図や利点などを知りたいです。この共通基盤のコンセプトは、プロダクト間でデータを共有したいというようなことではなくて、法令の専門知識が必要な部分の処理をいかにして局所化するかにあります。これは技術戦略でもありますし、組織戦略でもあるんですよ。LITALICOでSaaS系プロダクトに関わるエンジニアの多くは、障害者総合支援法についての知識が求められます。しかし、みんながこの法令の深い知識を持っていなければプロダクト開発ができないという状況では、プロジェクトに支障が出てしまいます。もちろん、ある程度の知識はみんな持っておくことが必要ですが、法令以外にも必要なドメイン知識は色々あります。そこで、特に深い法令知識が必要な箇所を共通基盤に局所化することを目指しています。要するに、共通基盤の開発に携わるメンバーだけが法令の複雑な部分を正確に理解すればよいという状態にするということですね。先ほど述べたように障害者総合支援法は3年おきに改正されますし、新しい法令が発表されてからシステムをそれに対応させるまでは時間が限られているため短期決戦になります。それもあり、こうした方針を採用していますね。――この事例を踏まえて、読者に伝えたいことはあるでしょうか？世の中にある設計のプラクティスや開発手法などは、先人たちの実践や経験からエッセンスを抽象化して汎用化されているものです。それらを学ぶことは前提として、原理主義的に「こうでなければならない」と考えるのではなく、「自社に最適な状態で反映させるには何が必要だろう」と考えていく必要があります。たとえば私たちの事例では3年おきに法改正のための対応を行うという状況において、フォーカスすべき課題は何か、その課題を取り除くには何をするべきかなどを考える必要があります。だからこそ、技術のことだけではなくそのプロダクトや事業ドメインのことを知らなければ、適切な設計はできません。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/04659fa8e5a345cb8e9a7870a0cf6085/image3.jpg" alt="" width="1999" height="1334"></figure><h2 id="hdc352033f7">Electronを用いた現代的なデスクトップアプリ開発</h2>――他の事例についてもお話しください。私たちは2年ほど前から、公立の小中学校向けの事業を開始しました。主には、その学校の特別支援教育において、障害のある子どもたちのための支援や教育を支える事業です。その先生たちが使うための、パソコンで動くデスクトップアプリを開発したのですが、その事例についてお話しさせてください。――Webアプリではなく、デスクトップアプリなのですね。このプロダクトでは、児童・生徒の要配慮個人情報などを扱います。そのため、小中学校では、クローズドなネットワーク内で情報を扱いたいニーズが強いです。そうした情報もクラウドで扱っていく動きはあるのですが、まだまだ時間もかかるでしょうし、現状では自治体も導入しづらい状況です。今は、特に若いエンジニアはWebアプリの開発経験はあるもののデスクトップアプリの開発経験がない方がほとんどです。そこで、HTMLとCSS、JavaScriptといったWebアプリの技術を用いてデスクトップアプリを作れるElectronというフレームワークを使いました。また、スタンドアローンで動くシステムは、そのサポートにかかるコストをなるべく減らさなければなりません。Webアプリのようにサーバー側にログなどが残らないため、サポートでのトラブルシューティングの難易度が非常に高いからです。そのため、開発においてなるべくハードウェアやOS、ブラウザへの依存度を減らす必要があります。Electronにはブラウザのエンジンとかも内蔵されているため、環境にあまり依存せずにアプリが動作します。この事例においては、ポイントは開発の持続可能性ですよね。社内にどのようなスキルの人たちがいるか、将来的にも開発体制を維持しやすいか。そして、サポートにかかる工数なども考慮して、技術選定を行ったのが重要だと思っています。今回はせっかくなので、この技術選定における振り返りのポイントもお話しますね。将来的には、このプロダクトをWebアプリとして提供したいと思っています。そのときのために、Electronで開発したアプリの中に擬似的にフロントエンドとバックエンドがあるような設計にしたんです。SPAのような設計にして、のちのちクラウドに移行する際にそのままフロントエンドとバックエンドに変換することを目指していました。でも、もしもこのプロジェクトをやり直せるならば、その構造にはしないかもしれません。その設計方針にしたことで、Electronが想定しているオーソドックスな設計のパターンからは外れてしまいました。そのため、開発において意図せぬ動作が起きたり、その調査が難しかったりという課題が生じてしまったんです。この事例においては、将来のことを考え過ぎた選択をしたかもしれません。――この事例を踏まえて、読者に伝えたいことはあるでしょうか？今回の事例では、擬似的にフロントエンドとバックエンドがあるような設計にすることの利点を享受できるのは数年先で、でもシステムの複雑性と戦うのは今という状態です。新規事業というのはビジネスの行く先がわからないにもかかわらず、今のリターンを捨てて将来的なリターンを取り過ぎたかもしれません。一見するときれいなプランなんですけれど、理想像を見過ぎていました。今回のような新規事業においては今後ビジネスがどう変化するのかわからないので、あまり先のことを想定し過ぎるよりも、必要になったらその都度対応する考え方のほうがうまくいくことも多いです。技術レベルが上がるほど、「いろいろなケースを考慮してシステムを作り込み過ぎる」ということに気をつける必要がありますね。<h2 id="hd1a549d7d3">プロダクト間のデータ連携を行い、サービスの質を向上させる</h2>――LITALICOの開発組織における今後の目標を教えてください。引き続き、新規事業や新規プロダクトの数も増える見込みのため、組織力や開発プロセスを磨いていきます。さらにビジョナリーな話をすると、「障害のない社会をつくる」というビジョンを実現するには、何か1つの困難さを解消するだけでは不十分です。人間の生活のいろいろな場面やさまざまなライフステージの困難さを解消するために、事業を多角化していく必要があります。現在は、各プロダクトや学校・施設などで、扱っているデータがそれぞれ独立しています。これを、たとえばユーザーのIDを統合して、IDをキーにして横断的にデータを扱えるとか、別々のプロダクト間で相互にデータ連携できるというような施策を推進していきたいです。これによって、ユーザーへの提供価値は飛躍的に高まると考えています。実際、すでに私を含む一部のメンバーで、システムの設計方針やアーキテクチャのグランドデザインなどを検討して、技術検証やプロトタイプ開発といったことに手をつけています。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/87a1691abd824d54a16f129b16466f08/image2.jpg" alt="" width="1999" height="1334"></figure>――事業のさらなる飛躍が楽しみですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？どれほど長くエンジニアを続けても、一人の人間が経験できることには限界がありますよね。でも、世の中にはたくさんの優れたエンジニアがいて、その人たちが自らの経験や学びを発信してくれているわけですから、それを学ばないのはナンセンスだと思います。それに、自分がエンジニアとして成長していく過程では、より責任の重い仕事や裁量の大きい仕事に携わる機会に必ず遭遇します。その業務において、これまで経験したことがないようなチャレンジをすると思うんですが、その課題に対して手ぶらで挑むのか、先人の知恵を学んでヒントを自分の頭の引き出しに入れて挑むのかでは、結果がだいぶ違うはずです。エンジニアリングに限らず、歴史を学んでより良い状態で未来に引き継いでいくことは、人類として大切なことだと思います。ただ、書籍やWebの記事などで学んだことを、うのみにするのはおすすめしません。普段の業務の中で、学んだことを活かして小さな意思決定をくり返してみるとか、他のメンバーとの議論に参加してみるなどして、「覚えた知識」を「活用できる知識」にしていくことが重要になります。私が若い頃によくやっていたのは、たとえばプログラミング言語やフレームワークに触れているときに「こういう仕様なんだな」と思うだけではなくて「どうして開発者はこういう仕様にしたのだろう」とか「私だったらこうする」といったことを考えながら使ってみる。そういった習慣が、エンジニアとしてのスキルを向上させるための良いトレーニングになると思います。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

LITALICOグループでは、障害福祉・教育・介護領域で300拠点以上の事業所を運営し、主に発達障害のある児童への教育や、働くことに障害のある大人への就労支援などを行っています。また、そうして培われた支援や事業所運営のノウハウをもとに、当事者やご家族や福祉従事者向けのWebサービス、福祉事業所や学校向けのSaaSなどの数多くのプロダクトを提供しています。今回は同社の執行役員CTO/エンジニアリング統括部長である市橋佑弥さんにインタビューしました。

「3年に1回の法改正」にシステムをどう対応させる？LITALICOの事例に見る、事業特性に合わせた設計のヒント

<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としてどのような技術選定を行ってきたのでしょうか。


identify CTO兼「ワインと鍋」オーナー岩崎さんに聞く。過去の技術選定とそこから得た学び

Sansan株式会社で執行役員VPoE／VPoPを務める西場正浩さんに、Sansanで実践するマネジメントの事例とノウハウについて聞きました。


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