2023年6月14日から15日にかけて開催された「Developer eXperience Day 2023」（主催：日本CTO協会）。「開発者体験」（Developer Experience）をテーマに多方面の話題が議論されたなか、株式会社Gunosy（以下、Gunosy）執行役員CTOの小出幸典氏と日本CTO協会理事/株式会社LayerX代表取締役CTOの松本勇気氏は「シフトレフトで向き合うDeveloper Experience」と題してディスカッションをおこないました。
開発スピードの高速化が進む現代において、テスト工程を前倒しでおこなう「シフトレフト」は、開発者体験にどのような影響を与えるのでしょうか。CTO2名によるディスカッションの模様を紹介します。
日本CTO協会 理事/株式会社LayerX 代表取締役CTO 松本勇気氏
東京大学在学時に株式会社Gunosy入社、CTOとして技術組織全体を統括。またLayerXの前身となるブロックチェーン研究開発チームを立ち上げる。2018年より合同会社DMM.com CTOに就任し技術組織改革を推進。大規模Webサービスの構築をはじめ、機械学習、Blockchain、マネジメント、人事、経営管理、事業改善、行政支援など広く歴任。2019年日本CTO協会理事に就任。2021年3月よりLayerX 代表取締役CTO就任。開発や組織づくり、およびFintechとPrivacy Techの2事業の推進を担当。2023年にLayerX LLM Labsを立ち上げ、所長に就任。
株式会社Gunosy 執行役員CTO 小出幸典氏
慶應義塾大学政策・メディア研究科修了。アクセンチュア株式会社を経て、2014年株式会社Gunosyへ入社。メディアプロダクトの配信アルゴリズム開発や、全社データ基盤構築などを担当し、2019年7月より執行役員 最高技術責任者（CTO）。
目次
事業ごとに独立した開発組織を形成
松本：もともとは私もGunosyのCTOを務めていて、実は小出さんとは5年前まで一緒に仕事をしていた間柄ではあるわけですが（笑）。まずはGunosyとLayerXの事業について紹介したいと思います。
小出：ご存知の方も多いと思いますが、当社では情報キュレーションサービス「グノシー」をはじめとするメディア開発、広告配信などの事業をおこなっています。事業領域としてはメディア広告事業が大きく、そのほかにもD2C事業として気分に合わせたお茶選びを提案する「YOU IN」というサービスをつくっていたり、投資事業もおこなっていたりします。
更に大規模言語モデル(LLM)を活用したシステムの開発も進めており、6月にはGuosyAI(仮称)の開発を発表しました。
エンジニア組織としては60名ほどで、とくにデータ領域に注力しています。現在の構成では40名ほどが開発、20名ほどがデータ領域となっています。
松本：LayerXは「バクラク」という経理の方向けの支出管理SaaSやFintech事業をおこなうほか、PrivacyTech事業も展開しています。PrivacyTech事業に関してはプライバシーを保護しながらパーソナルデータを利活用するというものです。また、4月からは大規模言語モデル（LLM）の事業化を始めています。
事業規模は5000社ほど（2023年6月時点）がバクラクを導入いただいており、エンジニア組織は開発主体で60名ほどの構成となっています。
小出：LayerXは新しいサービスが出てくるスピード感が本当に早いですよね（笑）。
松本：開発については爆速に振り切っていますね（笑）。これからはいくつかのテーマについて話し合っていきたいと思いますが、まず最初のテーマとして「私たちはどのような方針で開発組織を形成しているのか」という点について議論したいと思います。
小出：Gunosyの場合、プロダクト単位での開発チームを主軸にしています。サービスをデリバリーし続けるなかで、サービスレベルの維持やセキュリティリスクを減らすといった取り組みは、プロダクトチームが主体となって意思決定をおこなえる組織を志向しています。特定の事象を別のチームに依頼するのではなく、なるべくチームが自走してプロダクトを維持し続けられるようなチームを作っていきたいと思っています。
松本：では、組織を横断する組織というのはあまりおかない方針なのでしょうか？
小出：もちろん横軸の組織ではSREチームなどがあります。しかし、サービスの質についてはSREが責任を持つのではなく、プロダクトチームが責任を持つようにしています。SREはトリアージのルールなどをつくって組織横断的に布教していますが、SRE自体が手を動かしつづけるというものではありません。
松本：プラットフォームを敷いてその上でチームが動くというよりは、それぞれのチームが独立してそれぞれのプロダクトをつくっていて、専門的で難しい部分の突破をSREチームがサポートするようなかたちをとっているのだと思います。そうなると採用技術がバラバラになる可能性もありますが、技術を揃えていくことはしていないのですか？
小出：それが面白いところで、勝手に揃っているのが実情です。松本さんが在籍していたころからgolangを使っていますが、サーバサイドとしてはgolangだったりPythonだったりがあるなかで、最近だんだんその言語を変えるコンテキストスイッチが大変だという点もあり、機械学習の方々もPythonからGoにシフトしたりといった傾向がありますね。
バックエンドでは現在、それぞれのプロダクトでコンテナ化を進めている状態ではあります。コンテナ化については当初Amazon ECSを使っていたのですが、実際に使っているなかで起動時の細かい挙動など、工夫が必要だったりうまくいかなかったりしたところがあり、現在はKubernetesを主に採択しています。
松本：LayerXのチームについてもここで紹介させていただくと、基本方針としては私たちも事業ごとに独立した開発組織を形成しています。緩やかに各チームの取り組みが伝播していって、お互い似たような技術を使っているけれど、積極的に揃えることはしないというイメージですね。
バクラクの開発組織でいえば、まずプロダクトのストリームアラインドチームとイネーブリング専門のチームがいて、あとはエンジニアリングマネジメントがあります。この3つのセクションにわかれ、それぞれにリーダーを立てて有機的に連携していくような構成です。
私たちの開発の心情として「爆速」が最優先なので、半年に1回は新規プロダクトをリリースする目標に振り切った開発をおこなっています。新規のプロダクトをつくるのに最速な技術選定をして、後からそれに揃えていくようなイメージです。
このような話を聞くと、「そんなことしたら技術的負債が溜まってしまうのでは？」と思う方も多いと思います。そこで負債が溜まるかどうかは、ある種そのときの開発者の技量にもよると思っていて、そこにはある程度、属人性を持たせる方針を取っています。ただ、DevOpsやセキュリティのような横軸展開のプラットフォームチームもあります。
また、それに加えてML（機械学習）のチームがあります。GunosyとLayerXの共通点として、MLのチームをしっかりとつくっている点があると思いますが、Gunosyではどのようなチームになっているのですか？
小出：たとえば、メディア事業であればアプリ上に並ぶ記事のリストをパーソナライズしつつ、CTRやCVRを予測してコンバージョンされやすそうな広告を推定する予測モデルを作って、オンライン上で予測するシステムを作ってもらってます。MLのチームとしてはモデルをつくるところで終わりではなく、サービングの部分まで責任を持ち、予測APIの提供や、サービスレベルの向上もMLのチームで担保するかたちをとっています。
脆弱性から得た学び シフトレフトにいかに生かすか
松本：両社の開発方針について話し合ったところで、徐々に今回のテーマである「シフトレフト」への話題に移っていきたいと思います。プロダクトの成長に合わせて、過去さまざまな脆弱性と戦ってきたと思いますが、やはり「事件」は起こります。そういった「過去の事件からの学び」について、なにか印象的な事件とその対応のエピソードはありますか？
小出：印象に残っているのは、2014年シェルショック脆弱性や、近年ではLog4j脆弱性がありますね。人海戦術でなんとか対応し、かなり大変だった記憶がありますね……（笑）。
松本：開発段階で、事件に備えて基盤を組むのはなかなか難しいですよね。LayerXはまだ若い会社ですが、プロダクトを運営しているなかでnpm内に危ないパッケージがあったり、Log4j脆弱性のときもかなり慌てた記憶があります。
一方で、このような事件は見方を変えれば、セキュリティにどう向き合っていくかを考えるいいきっかけだと思っています。恒久的にそういった事態を防ぐ取り組みなどはしていますか？
小出：やはり痛感したのは、人海戦術でしらみ潰しに脆弱性を探していく作業はもうやめたいということですね。どう進めていくかを検討したときに、たとえば現在動いている環境やコンテナのリポジトリなどをスキャンして脆弱性を見つけたり、GitHubのソースコードを巡回したりなど、脆弱性を常時見つけられるような仕組みを第一段階として始めました。
松本：そういった静的解析ツールを導入したというイメージですか？
小出：そうですね。たとえばAmazon ECRのスキャンのほか、OSSの静的解析のスキャンツールをいくつか試していったイメージですね。それに加えて、やはり本番環境でのスキャンも必要だと思っています。
しかし、いざ本番になってスキャンすると、後で脆弱性があるとわかれば、その時間的なラグがリスクになってしまうし、開発者にとっても新しい作業チケットが切られることになります。本番環境でのスキャンも必要ですが、心理的負荷を減らすためにも、やはりその前の段階で解消することが求められます。
松本：やはりシフトレフトが求められるということですね。私たちのような小さなスタートアップでは、そのような脆弱性の解消と人的コストは悩ましい問題です。もし小出さんがスタートアップでシフトレフトしていくなら、どういったことから始めますか？
小出：スタートアップや新規プロダクトのスタート期では、リソースに限りがあるためセキュリティ専門のチームをおくことは難しいですよね。しかもセキュリティのスキャンをしたなかで、なにをしたら回避できるのかや、そもそも脆弱性を直したバージョンがリリースされているのかなど、直し方の情報収集も大きなコストになります。
当社では現在「Snyk（スニーク）」を活用していて、このツールを使うとスキャンだけではなく、脆弱性を解消するためのサジェストを出してくれます。そのため「なにをしたらこの問題を解消できるのか」の調査時間を抑えられます。
現状、すべての脆弱性を解決するのは難しい部分もありますが、こういったツールを使うことで、外部のアクセスがある部分や攻撃手法などがわかっている脆弱性などから優先して解消するといった、優先順位やグラデーションを決めていく取り組みが進んでいます。
松本：たしかに、ツールを活用することで、スキャンと解決方法の両面を示してくれるのは便利ですね。そのような機能があることで調査の手間が減り、放置することなくすぐ解決できる流れができそうです。当社の場合、定期的な脆弱性検証は外部に任せているのが現状ですが、静的解析ツールの導入は大きな学びになりました。
開発者が気持ちよくデプロイできる環境づくりを
松本：ここからはMLでのOpsや品質管理について話していきたいと思います。
当社では現在、OCRや項目推定エンジンを中心に注力しています。私たちの場合はヒューマンインザループな仕組みづくりを徹底していて、ベースモデルをデプロイしてその差分をチェックしたり、推論データのタグ付けの方法も人間で確認したりといったサイクルを回して、MLの品質管理をモデル開発プロセスのなかで早めに検証しています。
Gunosyでは2013年からMLに取り組んでいますが、品質管理はどのようにやっているのでしょうか？
小出：当社としてMLには早めに取り組んでいましたが、まだまだ課題が多いのが現状です。
たとえば広告やメディアでリクエストがあったときのレイテンシーの問題。オンラインで推定をおこなって返すなかで、結構レイテンシー問題があるんです。機械学習をやっていると、フレームワークを使ってサービングするのが一般的だと思いますが、推論しつつかつ早く返したい場合には課題がありますね。当社ではGoをメインで使っているので、たとえばベクトル演算の部分といった行動をダイレクトに書いて、なんとかパフォーマンスを出そうとしていました。
しかし、新しい手法やまったく違うモデルをつくりたいとなったときに、また1からコードを書く必要があることが課題になっています。
松本：Gunosyの場合は、PythonでモデルをつくってGoで推論していたと記憶しています。Pythonで学習してインファレンスは別言語にすると、推論部分が同じ答えを返しているのかを担保するのが、とても難しいように思えます。MLOpsとしてはどのように品質保証をしているのでしょうか？
小出：その点でいえば、以前は一部同じデータを用意して出力の数字が合っているのか、といったテストはおこなっていましたが、本当に一緒かという点では、少し疑わしい部分もありました。
しかし、現在では同じモデル、トレーニングとインファレンスができるようになったので、そこについては解決できるようになりましたね。
松本：たしかに、乱暴な話ですがMLを使う領域は確率的なアウトプットを許容するユースケースなので、アウトプットが何%結果をリフトさせたのかを把握していれば、ある程度追って検証していく手法もありだと思っています。品質を担保しすぎると、反対にコストがかかり過ぎるという話も出てきてしまいます。それよりもPDCAを早く回していくほうが重要だと思います。
このような話を踏まえて、現状の課題や今後取り組んでいきたいことを教えてください。
小出：今まで話してきたDevOpsやシフトレフトの文脈とは少し外れてしまいますが、たとえば今台頭してきているLLMを使って、社内の生産性を向上させる部分があるのではないかと思っています。
このイベントのなかでもGitHub Copilotなどの話がたくさん出てきたと思います。Gunosyにはデータカタログがしっかりあって、リダッシュで書かれた大量のクエリのスナップもあります。これをLLMのLangchainなどを使っていくことで、もしかしたらMLやデータ分析そのものも自動化できるのではないかと思っています。今試してみたいと思っているのは、そこですね。
現状、分析のチームが雑多な依頼で忙殺されている姿などを見ていて、そこを自動で代替できるようになれば、分析エンジニアもハッピーになれるのではないかと考えています。
松本：とても興味深い話ですね。DevOpsの基本もやはり計測と改善のプロセスだと思っていて、これからはLangchainやエージェントをうまく活用していけば、これまで計測してきた データからインサイトを導き出すことをLLMが自動化してくれそうです。
小出：それに加えて、BIツール向けにつくっているデータセットなども、そのまま食わせたらどうなるのかという面にも興味を持っています。私たちの場合、いわゆる事業的なところの数値だけではなく、たとえば「モニターのどのアラームが何回に鳴った」といったシステム監視のデータもあり、アプリのクラッシュなどについても持っているので、そのあたりでもうまく自動化できるのではと期待感を持っていますね。
松本：私たちのようなスタートアップの場合は、まずは計測をしていくことや、より早く検知できるようにすること、さらにテストを充実させるといった基本的なところから向き合っていく必要があると感じました。
今回のお話をまとめると、シフトレフト、そして開発者が気持ちよくデプロイできる環境づくりは大事です。できる限り後工程での手戻りをなくすことが、結局はエンジニアにとって幸せな環境であると思います。早めに検証できて、それをすぐにロールバックできる環境づくりに、長期的な目線で投資をしていくことも必要だと感じました。
（取材／文／撮影：川島大雅）
