本記事では、2025年5月14日に開催されたオンラインイベント「【技術選定を突き詰める】Online Conference 2025」内のセッション「newmoの創業を支えるSoftware ArchitectureとPlatform Engineering」の内容をお届けします。同セッションでは、newmo株式会社の伊藤雄貴（@mrno110）さんに、実践しているプラットフォームエンジニアリングの取り組みを事例とともにお話しいただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
伊藤： まず始めに自己紹介させていただければと思います。私はnewmo株式会社というモビリティの会社で、プラットフォームエンジニアリングの推進をしている伊藤雄貴と申します。newmoではGoogle Cloudを使い、最適なシステム・ネットワーク構成、ソフトウェアアーキテクチャ設計などを推進しています。スタートアップ企業なので、実際にビジネスドメインのコードも書いています。また、Google Developer Expertとして主にコンテナやマイクロサービスのクラウドアーキテクチャに関するノウハウを共有しています。
まずは私たちの会社についてお話しします。newmoは「移動で地域をカラフルに」をミッションに掲げたモビリティのスタートアップです。主に大阪で利用できる配車アプリを提供しており、タクシー、ライドシェア、配車アプリ、オートリースのサービスを展開しています。2024年に創業し、1年少し経った今、ゼロからスケールさせていく上で、どのような技術を選定すべきか、newmoで取り組んでいるプラットフォームエンジニアリング、その考え方を取り入れたソフトウェアアーキテクチャやクラウドアーキテクチャについて本日はお話ししたいと思います。
プラットフォームエンジニアリングの取り組み
まずプラットフォームエンジニアリングとは何でしょうか。私がよく参考にしているCNCF （Cloud Native Computing Foundation）が出しているホワイトペーパーにおいて、プラットフォームエンジニアリングとは、「アプリケーションを実装していく上で必要な様々なことを、コレクションとしてアプリケーション開発者に提供していく」と抽象的に定義しています。さらに、著名なソフトウェアエンジニアであるマーチン・ファウラーも同様に定義しており、プラットフォームエンジニアリングとは「セルフサービス、ツール、ナレッジ、サポートなどを内部のプロダクトとしてアプリケーション開発者に提供していく」ものとしています。
この概念を具体的に見ていきましょう。この図も先のホワイトペーパーからの引用ですが、一番上が内部のプロダクト開発チームやアプリケーション開発チーム、いわゆるビジネスドメインの開発をしているチームに対し、プラットフォームのインターフェースとしてドキュメンテーション、テンプレート、API、CLIなどを提供します。その裏側では、データベースの種類、アプリケーション実行環境、メッセージング、認証認可の仕組み、セキュリティをデフォルトにするためのガードレールなどをプラットフォームのケーパビリティとして定義し、インターフェースを通じてアプリケーション開発者やプロダクト開発者に提供していきます。これは、アプリケーション開発者がビジネスロジックに極力集中できる環境を提供することを目的とした取り組みです。
このホワイトペーパーでは、プラットフォームのキーとなる属性も同様に定義しています。まず非常に重要なのが、プラットフォームもプロダクトとして実装していくことです。プラットフォームはインフラストラクチャーの要素が強いと思われがちですが、単にインフラを構築するだけでなく、それを抽象化し、内部のアプリケーション開発者に対してそれをプロダクトとして提供していくことを目指します。そのため、ビジネスドメインの開発と目線を合わせていくことが大切です。内部開発者が何に困っているかを理解し、どのようなプラットフォームを誰に届けるべきかという考え方が非常に重要になります。それゆえに、内部の開発者であるユーザーに対し、どのようなユーザーエクスペリエンスを提供していくかが大切です。インフラストラクチャーやプラットフォームは構築しただけでは使いにくいので、ドキュメントを整備し、複雑な仕組みであれば、オンボーディングを設計して使えるようにすること。そして利用者がプラットフォームチームに問い合わせることなく、ドキュメントやオンボーディングを通じて自律的にプラットフォームを使えるセルフサービスであることがかなり重要になります。
また、プラットフォームの大きな目的として認知負荷をなるべく減らすことも挙げられます。認知負荷とはアプリケーションを顧客に提供し、ビジネスを実行する上で開発者が考えなければならないことの多さに起因します。アプリケーションの実装だけでなく、デプロイ環境、ネットワーク構成、CDNの利用、リクエストの認証認可など、考えるべきことが多く、認知負荷が高まります。プラットフォームエンジニアリングのそもそもの目的は、このような認知負荷、つまりアプリケーション開発で考慮すべき様々なことを極力減らし、プラットフォームのプロダクトとして内部の開発者に提供することにあります。他にもコンポーザブルであることや、デフォルトでセキュリティが確保されていることが重要です。このホワイトペーパーには良いことがたくさん書かれているので、ぜひ読んでみてください。
これを踏まえて、newmoではプラットフォームエンジニアリングチームを作っています。このチームは、ビジネスロジックの開発をする個々のチーム（ストリームアラインドチーム）に対し、様々な認知負荷を減らすためのプラットフォームを提供する役割を担っており、私もそこで活動をしています。プラットフォームエンジニアリングチームやストリームアラインドチームといった考え方は、「チームトポロジー」という書籍や考え方で多くの場所で参照されており、newmoではこの考え方に沿ってチーム分けをしています。
チームトポロジーを簡単に言うと、様々なモノづくりをするチームを構成する際、特定の種類のチームがどうコラボレーションすることで生産性を上げられるか、という考え方をまとめたものです。この理論では、チームの種類を4つに分けています。
- ストリームアラインドチーム：ビジネスの中核となるロジックを開発するチーム。
- コンプリケイテッドサブシステムチーム：MLのような複雑で専門的な領域を、独立して担当するチーム。
- イネイブリングチーム：ストリームアラインドチームなどを支援し、全体的な生産性向上を助けるチーム。
- プラットフォームチーム：ビジネス開発チーム（ストリームアラインドチーム）の認知負荷を下げるため、開発基盤（プラットフォーム）を提供するチーム。
この4種のチームで構成することで生産性が向上するという考え方が、チームトポロジーです。
これを踏まえ、newmoにおけるプラットフォームチームを以下の文章で定義しています。
newmoのプラットフォームチームは、配車アプリにおける乗客向け、ドライバー向けなど、様々なストリームアラインドチームをサポートしています。これらのチームはビジネスロジックに集中したい一方で、ネットワークやデータベースのスケーリングといった共通課題に直面します。プラットフォームチームは、これらの課題を吸収し、例えばアプリケーションサーバーのスピンアップ時にネットワークや認証認可を意識せず、ビジネスロジックに特化したAPIサーバーがデプロイできるように隠蔽して提供しています。
「チームトポロジー」では、チーム間のコミュニケーションを3タイプに分類します。新しいプロダクトを密に作る「コラボレーション」、支援する「ファシリテーション」、そしてプラットフォームチームに重要な「X-as-a-service」です。
「X-as-a-service」は、プラットフォームチームが提供するサービスを、ドキュメントやテンプレートを通じて、各チームが問い合わせなしで自律的に利用できる状態を目指します。プラットフォームチームが多くのチームと密に連携しすぎると、ボトルネックとなり各チームの自律性が損なわれるため、このようなセルフサービス化が望ましいとされています。具体的には、ドキュメントやテンプレートで利用方法を示し、「これらを読めば自分で使える」状態にするのが理想的なインタラクションです。
しかし、newmoは創業1年ほどのスタートアップです。提供すべきプラットフォームやビジネスドメインがまだ流動的な時期でもあります。そのため、創業初期においては、あえてプラットフォームチームとストリームアラインドチームが「コラボレーション」のように密に連携し、開発者が何に困っているかをプラットフォーム側が積極的に吸収して基盤を開発するアプローチを取っています。
会社創業期には、1人か2人のエンジニアがストリームアラインドチームとプラットフォームチームの両方の役割を担う時期もありました。
newmoにおけるプラットフォームエンジニアリングチームの定義は、内部のデザインドキュメントで明文化されています。私たちは、「各ビジネスに沿った開発チームが生産性を極限まで高めつつ、ビジネスのフェーズに応じた信頼性と安全性を担保したプロダクトを開発できるようにするために、技術基盤を構築し開発チームに導入する」チームと定義しています。
特にスタートアップでは実際のお客様に価値を届けるのが重要だと考えているため、生産性、つまりものを作っていくスピードを極限まで高めようと明確に掲げています。チームのビジョンを達成するためには、まず技術基盤として、クラウドリソース、データプラットフォーム、ネットワーク、共通ライブラリ、CI/CD、監視、アラート、オブザーバビリティなど、アプリケーションを作る上で個々のビジネスドメインには関係しない共通課題に対する基盤を構築し、その設計、実装、運用を行うことです。また、アプリケーションを開発している人がどのような点に困っているかといった課題の抽出もセットで行っていきます。
また、基盤を構築するだけでなく、実際に使う人が使えるようオンボーディングから導入まで責任を持っています。良い技術を構築するためには、様々な新しい技術動向のキャッチアップをすることが大切です。最新技術を取り入れれば良いというわけではありませんが、技術動向を把握し、どのような技術を基盤として導入すれば価値を生むのかを、きちんとキャッチアップすることも私たちのミッションです。
プラットフォームチームにとって重要な要素は、先ほど紹介したホワイトペーパーが示してくれています。
●内部のアプリケーション開発者が抱える課題を正確に把握し、プラットフォームの要件としてロードマップに落とし込む。
●内部のエンジニアに対して、構築したプラットフォームがどのような課題を解決し、どのように開発を改善するのかを積極的に伝え、使ってもらうための「マーケティング」をきちんと行う。
●開発者へのインターフェースの質や、プラットフォームが提供する機能（ケーパビリティ）を適切に定義し、改善していくこと。
以上がプラットフォームチームの成功には欠かせない要素だとされています。
ここまでホワイトペーパーを参考に、newmoにおけるプラットフォームエンジニアリングの考え方を紹介してきました。スタートアップで最初からプラットフォームエンジニアリングを行うのはやりすぎでは？とよく聞かれますが、私としてはこの2点が、newmoにおいて最初からプラットフォームエンジニアリングを行っている理由だと考えています。
まず、技術選択のバラつきをなくし、会社全体で生産性を高めたいからです。ビジネス開発チームは顧客への価値提供に集中すべきであり、技術選択といった共通課題はプラットフォームチームが一元的に担うことで、組織全体の生産性向上を目指しています。
もう一つの理由は、私たちの事業ドメインにあります。モビリティは、最速開発だけでなく中長期的な視点が不可欠な事業です。経営陣の資金調達への信頼性もあり、将来的にエンジニアを増員する計画です。その際、最初からプラットフォームエンジニアリングを入れておく方が、長期的なコストパフォーマンスが良いと判断しました。このように、newmoでは初期段階からプラットフォームエンジニアリングを推進しています。
ソフトウェアアーキテクチャ 3つの原則
では、ここからはプラットフォームエンジニアリングとしてどのようなものを提供し、どのようなアーキテクチャで開発しているかといった具体的な話となります。まずはソフトウェアアーキテクチャからお話しします。
newmoでソフトウェアを作っていく上で大事にしている考え方、原則は3つあります。まずは、「APIのフェデレーション（これについては後ほど詳しく説明します）」、そしてそれを元に何らかのスキーマから機械的にコードを生成すること、あとは初期段階からマイクロサービスのような複雑なアーキテクチャを取り入れるのは大変なため、「モジュラーモノリス」という考え方と「モノレポ」という手法を導入しています。これら3つの点について、技術的な側面から詳しく解説していきます。
APIのフェデレーション
まずはAPIのフェデレーション、つまりAPIのアーキテクチャについてです。newmoでは、この図のように、ドライバーが利用するモバイルアプリを例に挙げると、モバイルアプリから当社のAPIサーバーを叩く時のインターフェースとしてGraphQLを採用しています。しかもGraphQLのフェデレーションという考え方を取り入れています。
GraphQLを採用している理由のひとつにエコシステムの成熟度が挙げられます。モバイルアプリやWebアプリといったインターネット上のクライアントからサーバーを叩く時のエコシステムという点では、gRPCなども使えますが、流行や様々なツール・仕組みを見ると、クライアントtoサーバーのエコシステムではGraphQLに利点があると考えています。また、newmoは一つのサービスでも様々なクライアントが存在します。例えば、ドライバーの方はモバイルアプリだけでなくタブレットを車にマウントして使っている場合もあります。
このような多様なクライアントに対し、それぞれに最適なAPIをgRPCやRESTで提供しようとすると、クライアントに過不足なく情報提供するために、どうしてもそれぞれに特化したAPIを作っていかなければなりません。
それに対してGraphQLはクライアントからサーバーが定義しているスキーマに対し、どのようなデータを取りたいかをクエリなどで記述する形式です。これにより、サーバー側では「様々な情報をグラフで取得できるようなスキーマ」を一つ定義するだけで済みます。例えばモバイルアプリがユーザー名だけを取得したい場合や、タブレットが表示領域に応じてユーザー名と車種一覧など、さらに多くの情報を取得したい場合でも、それぞれに特化したAPIを提供することなく、サーバー提供のスキーマをクライアントが利用することで、特別な開発をすることなく、様々なデバイスに最適な情報を提供できるのです。これはGraphQLでよく「オーバーフェッチがない（情報を取りすぎない）」「アンダーフェッチがない（情報が足りない）」という形で表現されますが、これがなく、それぞれに最適なAPIを提供するには、やはりGraphQLが最適なインターフェースだと考えています。
APIのフェデレーションについて具体的に話していきます。NetflixはAPIの進化を4段階で説明しており、まず1段階目がモノリシックなサーバーです。これは従来のAPIの作り方で、皆で大きなAPIを開発するため、作用も責任範囲も不明瞭で非常に大変です。
そこで出てきたのがAPI進化の2段目となるマイクロサービス化です。個々のビジネスドメインがたくさん存在し、連携してAPIとして提供します。例えばドライバーのプロフィールページにドライバーの情報と車の情報を両方表示したい、といったnewmoらしい要件があったとします。この場合、個別のマイクロサービス（ドライバーコンポーネント、ビークルコンポーネントのようなマイクロサービス）が存在すると、クライアントからドライバーのマイクロサービスを取得し、そのIDを元にビークルサービスを叩いて車両情報を取得し、合体してレンダリングする、という流れです。
しかし、このアプローチには大きな問題が2点ありました。まず1点目ですが、複数のAPIを叩いて画面を構成する処理を、iOSやAndroidなどOSごとに再度実装する必要がありました。さらに、その処理は、HTTPとしてのラウンドトリップが連続して発生することになるため、数が増える毎にどんどん遅くなり、単純な体験としても悪化していきます。これらの課題を解決するために登場したのがいわゆる BFF（Backend For Frontend） という考え方、つまりアーキテクチャパターンです。
BFFは、クライアントが複数のマイクロサービスを直接叩く代わりに、バックエンドのAPIサーバーの領域として隠蔽していく考え方です。例えば、ドライバーのプロフィールページを叩く際、BFFレイヤーを叩くだけで、BFFが裏でドライバー情報と車両情報をそれぞれのマイクロサービスから取得・結合し、クライアントに返してくれるというようなアーキテクチャパターンです。このパターンを使うと、先ほど言ったように複数回のランドトリップやアグリゲーション処理の重複といった問題点は解決されます。
しかし、多くの方をはじめNetflixや私も経験しているように、このパターンだとやはりいくつか問題が出てきます。マイクロサービスとして様々なサービスを分けたのにBFFのようなものを提供すると、結局個々のビジネスチームが真ん中のBFFレイヤーをいじらなければなりません。そうなると次第に大きなモノリスのようになっていきます。これにより各チームの自律性が損なわれ、開発のスピードも下がってしまうといった問題が生じます。これの解決策として出てきたのが、API進化の4段階目であるAPIフェデレーションの考え方だとNetflixが言っています。newmoではこの考え方を採用しています。
APIフェデレーションとは、個々のマイクロサービス（図の黄色い部分）が、何かAPIを提供する際、そのAPIスキーマに「このマイクロサービスのAPIはこのように集約してくださいね」というアグリゲーションの仕様（図の青い部分）を、設定ファイルとして提供するものです。そしてメタデータに書かれた仕様に基づき、スキーマを集め、各APIサーバー、つまりマイクロサービスから情報を集めてくるのがAPIのフェデレーションという考え方なのです。
GraphQLのフェデレーションでは、この中央の紫のレイヤーのコンポーネントは、OSSとしてすでにその仕様に沿って実装されたものがあります。これによりAPIスキーマを元に自動で集約してくれるため、この真ん中の部分の開発が不要になります。個々のコンポーネントがAPIを提供する際に、「外から見える時にBFFのような領域で集約してくださいね」という定義を書き続けることで、自動で集約し、外部にAPIとして提供していくという考え方がAPIのフェデレーションです。RESTやgRPCなど様々なAPIがある中で、特にGraphQLフェデレーションがエコシステム的にもかなり流行っています。そのため、GraphQLを採用している大きな理由の一つが、このAPIフェデレーションを実装可能な仕様が存在している点にもあります。
GraphQLのフェデレーションが実際にどういうものか、スキーマベースで見ていきます。例えば、先ほどのドライバーに対してマイページを表示する機能で、ドライバー情報と車両情報を表示したいとします。
ドライバーコンポーネント：ドライバーのIDや名前など、様々な情報を管理
ビークルコンポーネント：ドライバーが所有する車の一覧などを管理
これらのコンポーネントから情報を取得して表示したい時、GraphQLフェデレーションではどうなるでしょうか。
左上がドライバーコンポーネント、右上がビークルコンポーネントのGraphQLのスキーマ定義です。ドライバー側は、ドライバーの諸情報として名前などがあります。ビークルコンポーネントは、ドライバーのIDに関連付けて車両情報を持っています。
ここで注目すべきは「@key」という記述です。GraphQLフェデレーションの仕様によるスキーマへのメタデータの付与なのですが、このIDをキーにして束ねることで、機械的に合体したGraphQLスキーマを生成できるのです。これはGraphQLフェデレーションの仕様が「@key」を提供しており、それに基づいたツール群を使うことで、スキーマを統合できます。
そして真ん中のGraphQLフェデレーションレイヤーは、newmoではApollo RouterというOSSを利用しています。Apollo Routerにはドライバーグラフやビークルグラフが、それぞれURLのどこに存在するかという設定ファイルをOSSに渡すことで、このGraphQLフェデレーションレイヤー自体に直接手を加えることなく、OSSとしてデプロイし続けるだけで機能します。結果として、外部から見れば一つの大きく集約されたGraphQL APIに見えますが、内部的には個々のビジネスドメイン開発チームがそれぞれ独自のコンポーネントを持っており、各チームが自律的に自分たちのAPIを提供できるようになるのです。
さらにメリットとして、自分たちがやりたいことを、他のチームやBFFなどを変更することなく外部に提供できる点があります。GraphQLフェデレーションはグラフ構造であることもあり、フェデレーションという考え方と非常に親和性が高いのです。
さて、ここまではクライアントtoサーバーの話をしましたが、一方で、サーバーtoサーバーのやり取りではgRPCを採用しています。クライアントtoサーバーのエコシステムはGraphQLなどが強いですが、サーバーtoサーバーのエコシステムではgRPCの方が強いと考えています。
例えば、Kubernetesやサービスメッシュといったコンテナオーケストレーションツールは、ネイティブでgRPCをサポートしています。これによりマイクロサービス間のやり取りにおいて、gRPCでスキーマ定義を書いておくと自動で認証認可される仕組みなどを提供してくれます。一方、サーバーtoサーバーのやり取りの仕組みでGraphQLがサポートされていることはかなり稀です。そういった面でも適材適所として、このサーバーtoサーバーはgRPCを採用しています。デメリットとしては、個々の開発者がGraphQLとgRPCの両方を理解する必要がありますが、プラットフォームの仕組みとして、様々なコード生成ツールやライブラリを提供していくことで、なるべく認知負荷を減らし、デメリットを緩和しています。
newmoでは、GraphQLやgRPCなどは必ずAPIスキーマを書いてから、それをコミットすることで、Go、Kotlin、Swift、TypeScriptなど、様々な言語のコード生成を行っていく開発フローが中心となっています。特にリクエストのバリデーションを自動化したい場合など、適したOSSツールなどがないこともあります。そのような場合でも、なるべく自動でコード生成できるように、独自にGraphQLアノテーション（メタデータやディレクティブ）を定義し、さらに独自のコード生成ツールを作ることで、極限まで自動生成されたコードで処理が行われるように、かなり重点を置いています。
その一部として、例えばTypeScriptやReact向けのコードジェネレーターのようなもののOSS化もしています。なるべくコード生成していくことで生産性を上げ、さらに、既存のコード生成ツールで不足する部分があれば自作するところまで踏み込み、生産性向上に注力しています。
そして、様々なコンポーネントがありますが、最初からマイクロサービスを行っているのではなく、モジュラーモノリスという考え方を取り入れて開発しています。
モジュラーモノリスの採用
モジュラーモノリスとは、マーチン・ファウラーやGoogleの論文でも言及されていますが、最初からマイクロサービスを行うと、デプロイのコーディネーションやネットワーク間の通信など、色々と考えなければならずオーバーヘッドが大きく非常に大変です。しかし、ただモノリスとしてアプリケーションを作ってしまうと、後で分割するのが困難です。そのため、分割しやすいようにモジュールとして切りつつも、最初はモノリスとして同じサーバーに入っているような考え方を取り入れていくのが良いとされており、私たちもその考え方をフォローしています。
これが実際のnewmoの様々なコンポーネントです。例えば、newmoには乗客向け、ドライバー向け、車両向けなど様々なコンポーネントがありますが、これらを最初からマイクロサービスとして個別にデプロイするのではなく、一つのサーバーとして登録し、コンポーネント間はgRPCで通信しています。つまりgRPCをインターフェースとしてモジュールを切りつつ、一つのデプロイメント（一つのモノリスのサーバー）として運用するモジュラーモノリスの考え方です。
モノレポの導入
また、各コンポーネントのソースコード、Webアプリ、iOS、Android、ハードウェアのファームウェアまで、すべてのコードを一つの「newmo-app」というリポジトリにまとめています。これがモノレポという考え方です。コードスキャニングやCI/CDの設定ファイルの統一化など、多くのメリットをもたらし、スタートアップにおいては、iOSやAndroidのコードなども同じリポジトリに入れる形でスタートしてみるのが個人的には非常におすすめです。newmoでも最初は大変になるかと思いましたが、1年経って振り返ると、最初からモノレポでやっていて非常に良かったという声を、様々なエンジニアから聞いています。
クラウドアーキテクチャーと技術選定の哲学
最後に、クラウドのアーキテクチャについてですが、私たちはGoogle Cloudを採用しています。
Google Cloudを選んだ主な理由は以下の通りです。
これらの理由からGoogle Cloudをメインのクラウドとして使っています。AWSのサービスなども一部で利用していますが、メインはGoogle Cloudです。
コンテナのプラットフォーム、つまりアプリケーションの実行環境には、Cloud Runを利用しています。デプロイすると自動でスケールしてくれるため、1年間使ってきましたがこれからも使うでしょう。またネットワーク構成については、スタートアップながらも最初からShared VPC構成にしています。ネットワークの構成変更はかなり骨の折れる作業なので、スタートアップにおいてもサービスをスケールさせる1年後、2年後を見据え、最初からネットワーク構成だけは少し考えておく方が良い、というのがここで伝えたいことです。
アーキテクチャパターンとしてはAPI Gatewayを取り入れています。認証認可、ログ、トランスコーディング、TLS、ドメイン管理、IP管理、CDNとのインテグレーションなど、ビジネスドメインのロジックとは関係ないものの、アプリケーション、つまり様々なサービスを提供する上で非常に多く考えなければならないことがあります。このような部分をプラットフォームエンジニアリングとして、API Gatewayレイヤーで吸収することで、個々のビジネス開発者は何も知らなくても自動で認証認可されている状態を実現しています
本日はnewmoのエンジニアリングの考え方について話をしました。その中でも、技術で意識している重要な点としてこれらが挙げられます。
まず、技術選定、特に大きな選定をする時は、経営状況や事業状況を理解することが非常に重要だと考えています。現在の経営方針、ロードマップ、資金調達、人材増員の計画、採用方針など、様々な要素がどのようなものを作るべきか、あるいは作らずにもっとショートカットすべきかの判断に影響してくると思います。あとは、なるべく技術の選択肢を減らすことを心がけています。技術に時間を費やすよりも、プロダクトの価値を届けるところに時間を費やしたいので、ここを意識しています。また、インターフェースを工夫し個々の開発者の認知負荷を減らすこと。これはプラットフォームエンジニアリングの重要な考え方です。そして、最近の技術的な潮流としてどのような技術が出てきているか、エコシステムの観察も非常に重要だと考えています。これらを総合的に意識し、様々な技術選定を行っています。私からは以上になります。ありがとうございました。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
newmoの創業を支えるSoftware ArchitectureとPlatform Engineering
※動画の視聴にはFindyへのログインが必要です。