開発者フレンドリーで顧客も満足？Platformの秘密

2025年4月23日に開催されたALGO ARTIS Tech Talk #1でPlatformチームの古屋が発表に使用した資料です。
https://algo-artis.connpass.com/event/350992/

Transcript

1. 2025年4⽉23⽇ 1 開発者フレンドリーで顧客も満⾜？Platformの秘密
2. ⾃⼰紹介 古屋佑樹（Yuki Furuya） 2024年にALGOARTISにジョイン。 前職は⼤規模システムのインフラエンジニアとして従事。 ⼊社時はPlatformとPlaniumのフロントエンドを主に担当 現在はPlatformのマネージャー 万博の年パスを買おうか⾮常に悩んでいる
3. ALGOARTISにおけるPlatformとは？ 3
4. ⽬次 4 1. 導⼊（Platformのイメージアップ） 2. Platformの裏側⼤紹介！ 3. 感想、まとめ
5. Platformがない時代(=サービス開発者がフルスクラッチで開発する時代) （クラウドができたとはいえ）環境構築に多⼤な時間がかかり、 ビジネス上重要でない部分に時間が取られる ※弊社もOptiumのシングルテナント開発時代に⾮常に苦労した部分
 サービス作ってください！ クラウドサービス契約して。。 インフラデプロイして。。。 バックエンドロジック書いて。。。 CICDの設定もしなくちゃ フロントも書いて。。。 ‧ ‧ まだかな。。 顧客 or 社内ビジネスメンバー 開発者
6. 皆が思っているPlatformのイメージ ケース① 開発環境の払い出し ケース② 新機能の追加 申請書の記載お願いします サービス開発者 Platform担当者 1~2週間かかります！ 提供の迅速化を期待したはずが 
 コミュニケーションコストが高くつくことに。。。 
 汎⽤的な機能ではないので難 しいです。。 できますが、時間がかかります or （⾃分でやった ⽅が早 い。。。） 環境の払い出しお願いします 個別機能はなかなか実装しづらい。。。 
 実装できるとしても時間がかかる。。。 
 と私が勝⼿に思っている （顧客に断る か。。。） 機能Aの追加お願いします
7. 弊社のPlatformのイメージ ケース① 開発環境の払い出し ケース② 新機能の追加 （数分して。。。） 作成できました！ サービス開発者 Platform担当者 環境を作成して、開発を開始するまで 数十分程度 ！
 ご⾃由にどうぞ！ （早すぎ！） 環境の払い出しお願いします サービス開発者の裁量で 柔軟な機能開発ができる 
 （良いの！？） 機能Aの追加お願いします
8. 弊社のPlatformはどこに当てはまるのか？ 1.フルスクラッチ型 2. インフラ共通型 3. バック共通型 4. アプリ共通型 柔軟性が最も高い 構築に時間がかかる 開発物の横展開が難しい セキュリティなどの対策が横串で実施で きる 共通化部のコストが圧縮できる 依然構築に時間がかかる フロントに注力すれば良い 汎用的な画面の横展開が難しい 個別画面に注力すれば良い 機能拡張の柔軟性に乏しい サービス担当 Platform担当 （開発者からみた）柔軟性 共通化による再利⽤性、コストメリット ⾼ 低 低 ⾼
9. 弊社のPlatformはどこに当てはまるのか？ 1.フルスクラッチ型 2. インフラ共通型 3. バック共通型 4. アプリ共通型 柔軟性が最も高い 構築に時間がかかる 開発物の横展開が難しい セキュリティなどの対策が横串で実施で きる 共通化部のコストが圧縮できる 依然構築に時間がかかる フロントに注力すれば良い 汎用的な画面の横展開が難しい 個別画面に注力すれば良い 機能拡張の柔軟性に乏しい サービス担当 Platform担当 （開発者からみた）柔軟性 共通化による再利⽤性、コストメリット ⾼ 低 低 ⾼ いずれにも当てはまらない
10. 弊社のPlatformはどこに当てはまるのか？ システムを共通化することはコストの圧縮や統制⾯で便利ではある⼀⽅、 開発者視点では柔軟性にかける、逆に顧客提供速度が下がるなどの負の側⾯も出てくる。 ⇨サービス開発者体験が必ずしも向上するとは限らず、開発者の視点で⾒るとUnHappy ではALGOARTISのPlatformはどのようにこの問題に対処しているのか？特別に裏側⼤公開！ 開発者の視点で柔軟性を上げるために使える3種の神器およびそれらを⽀える基本機能をご紹介！
11. ちょっとその前に。。。アドオンとは？ アドオンとは‧‧‧Platformを基本機能を⽀えるCoreとそれ以外に⼤別でき、 それ以外を⽀える機能として弊社内で定義しているもの。 いわゆる、ブラウザの拡張機能やエディタの拡張機能のようなもの アドオン
12. 全サービスで単⼀レポジトリ内で単⼀アプリケーションを開発 3種の開発者神器（FrontendAddon） ‧デプロイには管理チームの承認が必要  デプロイスピードが落ちる、毎回頼むのも⼤変 ‧コンポーネントの変更影響が他テナントに波及する恐れがある  気軽に更新しづらい ‧使⽤するライブラリを合わせないといけない  しがらみが多く⾃由に開発できない 前提 課題 ‧サービス開発者毎に関連コードだけを別レポジトリで管理できる  コンフリクトなどの⼼配がない ‧開発からデプロイまで⾃⼰完結  ⾼速なリリースが可能に ‧ライブラリも⾃由⾃在  必要なライブラリを使って柔軟性⾼く開発ができる 嬉しさ FrontendAddon導⼊ FrontendAddonとは‧‧任意のフロントエンドをデプロイできる機能 顧客の要望（敵）をバッサバッサと切り捨てる様はまるで剣のよう
13. FrontendAddonが実現する⾼速な開発サイクル 開発kit上で開発 1 ビルドしてzip化 2 画⾯上で登録& 動作確認 3 画⾯上で切り戻し +α 開発からリリース、問題発⽣時の切り戻しまでサービス開発者のみで実施可能 最新版 旧版 問題 発⽣ データ画⾯と開発画⾯の2画⾯ が提供されており効率的に開発 ローカル環境での開発、実機上での確認の サイクルを⾼速に⾏うことが可能 障害発⽣時の切り戻しも画⾯上 で完結 Platform担当 サービス担当
14. バックエンドは共通化されており、APIが提供されている 3種の開発者神器（ConnectAddon） ‧基本的には既存処理の中で対応する必要がある  固有要件が出た時に対応できない ‧要望を出しても基盤側でロジックを修正するのに時間を要する  アジリティが低く、迅速に顧客ニーズに応えることができない ‧⻑時間処理や定期実⾏などの柔軟な実⾏はフロントでは難しい  しがらみが多く⾃由に開発できない 前提 課題 ‧任意の⾔語で任意のバックエンド処理がデプロイ可能  Ex. 天候情報を外部から取得する、Excelを⽣成して外部に送信 ‧定期実⾏や負荷の⾼い処理を実⾏可能  ⾮同期で裏側で実⾏するなどより柔軟な処理のオプションを提供可能に 嬉しさ ConnectAddon導⼊ ConnectAddonとは‧‧任意のロジックをCloudRun上にデプロイできる機能 あらゆる処理をフロントとは隔離された裏側で安全に処理する様はまるで盾のような安定感
15. ConnectAddonによるデプロイフロー Docker等で開発 1 CICDでコンテナイ メージをクラウドに デプロイ 2 画⾯上でマスタ設定& 権限設定 3 開発者が意識する必要があるのはI/Fだけ。それさえ守っていれば任意の処理を実⾏可能。 またデータのスキーマに関しては基盤側の機能を活⽤し、開発者側で柔軟に定義可能 任意の⾔語で開発可能 実⾏トリガーは⼿動実⾏、イベ ント実⾏、定期実⾏など柔軟に 選択可能 データ⼊出⼒、 実⾏トリガーの設定 4 Platform担当 サービス担当 ※主にセキュリティ上の理由により Platform担当の操作が⼀部必要
16. UI/UX向上のため既存の処理をフロント側に処理を寄せたい （参考）弊社はフロントエンドがTypescript、最適化含むアルゴリズムがC#、 バックエンドがGo 3種の開発者神器（Wasm） ‧異なる⾔語に処理をマイグレーションする必要がある  ⾞輪の再開発であり、労⼒に対してビジネスインパクトが薄い ‧並⾏運⽤によるメンテナンスコスト⾼  コード変更時に、元の処理と移⾏した処理どちらも⼿を⼊れる必要がある  ことを鑑みると、並⾏稼働は現実的ではない 前提 課題 ‧既存のコードはそのままに容易にフロントに移植可能 ‧元処理をメンテナンスし続ければ、環境問わず実⾏可能  メンテナンスコストが少なくなる 嬉しさ Wasm導⼊ Wasm(WebAssembly)とは‧‧多様な⾔語からコンパイル可能なバイナリ形式のプログラム。ブラウザ等の実⾏環境で動作可能 あらゆるコードを実⾏可能にする様はまるで魔法のよう
17. Wasmの組み込みフロー バックエンド処理を Wasmビルド 1 開発kit上に組み込み 2 FrontendAddon上でWasmの利⽤をサポートしており、⼀貫した開発者体験でフロントの開発が可能 Platform担当 サービス担当 開発kit上で開発 3 以降はFrontendAddonの デプロイフローと同⼀
18. その他、Platformが提供する基本機能 サービスを分割できる最⼩単位は 組織であり、提供する会社ごと、 部署ごとなど柔軟な区分けが可能 組織管理 アプリケーションを分割できる最 ⼩単位は組織であり、提供する会 社ごと、部署ごとなど柔軟な区分 けが可能 ユーザ管理 管理者や閲覧者など⼀般的な権限 に加え、よりきめ細やかな権限を を管理できる機能も提供 権限管理 ExcelやJSON、CSVなど⼀般的な データ形式のダウンロード。アッ プロードに対応している データI/F 開発者が任意のデータスキーマを 定義可能。 画⼀的なスキーマにとらわれず、 より柔軟なデータ表現が可能に データスキーマ定義 Platform担当は計画業務含めサービスで必要となる機能すべてを強⼒にサポート! サービス担当者はそれ以外、すなわちビジネスの根幹となるコアロジックのみ磨けば良い。 計画間の⽐較やKPIの表⽰、計画 の複製など計画業務に求められる 共通的な機能をサポート 計画管理機能
19. つまり、Platformのアーキテクチャはどうなっているの？ サービスB担当 サービスA担当 Platform担当 クラウド担当 サービスA利⽤ユーザ サービスB利⽤ユーザ サービス利⽤ユーザはPlatform が提供する共通画⾯と、サービ スが提供する個別画⾯のいずれ も使⽤する ConnectAddonによる任意のロ ジックのバックエンド実⾏ FrontendAddon （Wasm含む）による任意の画 ⾯のデプロイ
20. 最後に、、個⼈的なPlatformの⾯⽩さ 私のバックグラウンドは⽐較的⼤規模システムのインフラ周りを担当することが多かったので、初めて ALGOARTISのプラットフォームの話を聞いた時は、あーSRE的な？ DevOps的なやつね？と当初は理解をしてお りました。 ただ、ALGOARTISのプラットフォームは私が当初イメージしていた概念よりももう少し広範であり、アプリケー ションの部分まで及んでいるのが印象的でした。 最近ではNintendo Switchのようなゲームプラットフォームと近しい部分があると思い始めてきました。 プラットフォーマはユーザ管理やソフトの配信管理を⼀挙に担う。 デベロッパーはそのプラットフォーム上で開発し、エンドユーザにサービス（ゲーム）を提供する。 エンドユーザはソフトを起動するまではプラットフォーマが⽤意した画⾯で操作をして、ソフトを起動したあと はそのデベロッパーが⽤意したサービス上で遊ぶ。 これは弊社のPlatform上でのPlatform担当領域と各サービス領域の関係と近しいものがあると感じます SRE的なやつね？ ⼊社当時の私 今の私 Switch的なやつね？ 参照元
21. ALGOARTISにおけるPlatformとは？ ⇨開発の柔軟性を落とさず共通化の恩恵を受けることができる仕組みのこと サービス開発者にとっては能⼒を存分に発揮できるようなワクワクできる基盤に 結果としてサービスの表現⼒が⾼まり、顧客が求めるサービスを提供できる！！ 21
23. 商標 ‧Nintendo Switchのロゴ‧Nintendo Switchは任天堂の商標です。