マルチプロダクトを支えるSelf-service基盤構築の軌跡

2026/07/07 Kyoto Tech Talk #10
https://hatena.connpass.com/event/397660/
『マルチプロダクトを支えるSelf-service基盤構築の軌跡』
有働 開（GitHub: u-kai, X: @u_kai1012）

Transcript

1. マルチプロダクトを支えるSelf-service基盤構築の軌跡 Kyoto Tech Talk #10 株式会社hacomono 有働 開 Last Update 2022.03.16
2. 目次 1. 自己紹介 2. Self-service基盤構築の背景 3. Self-service基盤構築/展開の軌跡と学び 4. 今後の展望 具体技術の話についてはhacomono Speaker Deckも参考にしてください！！ • https://speakerdeck.com/hacomono/choosing-crossplane-to-reduce-developer-cognitive-loadideals-vs-realities-of-self-service • https://speakerdeck.com/hacomono/platform-engineering-with-crossplane-resource-abstractionsimplified 2
3. section 1 自己紹介
4. 自己紹介 有働 開(Kai Udo) • 社歴 ◦ 2020/4 ~ 2024/6 某製造業 ◦ 2024/7 ~ 株式会社hacomono 現在: 共通基盤グループ所属 • GitHub: u-kai, X: @u_kai1012 • よろしくお願いいたします！ 4
5. section 2 Self-service基盤構築の背景
6. hacomonoについて hacomonoというWellness業界向けSaaSを提供中 6
7. hacomonoのこれから~マルチプロダクト戦略について~ これからはマルチプロダクトにも注力して事業拡大を狙う 各プロダクトは独立して開発してマイクロサービスの恩恵を受けたい 7
8. Self-service基盤構築の背景 旧体制のままだと、プロダクト毎にインフラ構築が必要... • プロダクトが増える毎にインフラ人材が必要 • プロダクト増加に比例して運用コストが増加 • 個別最適化されたインフラのガバナンス担保が必要 • etc… プロダクト開発者自身で必要なインフラを安全に構築できるようにするために K8sベースのSelf-service基盤を構築することに 8
9. section 3 Self-service基盤構築/展開の軌跡と学び
10. Self-service基盤構築・展開の軌跡 10 時期 出来事 2025/6 構想立て/チーム OKR として組織に宣言 2025/7~現在 機能毎に技術検証と構築（実装 1.2 人…） 2026/1 最初のプロジェクトが利用開始 2026/2〜6 プロダクトの利用拡大 2026/7 プロダクトの顧客提供開始予定 運用体制の強化開始
11. Self-service 基盤イメージ 11 リポジトリにリソースを記述してマージするだけの GitOpsベースのSelf-service基盤を提供中
12. Self-service基盤構築・展開で得られた学び • AIは基盤構築にもプロダクト開発者サポートにも効果抜群 • ただし、人間の理解も大いに大事 • Self-service・抽象化の功罪 • 組織への普及の大切さ 12
13. 基盤構築・展開におけるAI活用 1.2 人での基盤開発を成立させたのは間違いなく AI • 基盤の実装/検証/トラブルシュートをほぼ全てAIに • AIによってプロダクト開発者から基盤運用者への 問い合わせをほぼゼロ に コンテナをxxxというド メインで公開したい 開発者のため新機 能を追加して なんかバグってる から直して 13
14. AI活用に対して効果的と感じた施策 • ADRの記述 • AIがあらゆるものに安全にアクセスできるように整備 • 振る舞い駆動テストによる誤設定の駆逐 • PRレビューにグラデーションを • Agent Skillsを開発用途毎に用意 • ガードレールによって危険な実行はそもそもできないように整備 14
15. 人間の利用技術への理解 AIは指示されたことしかしない/古い情報を提案してくる/etc… • 利用する技術に対して網羅的に理解して正確な指示をする必要がある ◦ 漏れがあっても動くが、その漏れが一大事になるかも。。。 ◦ 理解のない指示はAIを一生路頭に迷わす • 網羅的な理解にドキュメント/コードリーディングは強力 ◦ 各エコシステムのドキュメントに大事なことは大体書いてある ◦ 設定可能なプロパティに目を通すと学びが多いはず！ ◦ AWS EKS Best Practices for Secuityには救われた。。。 15
16. Self-serviceや抽象化の功罪 • 複雑さを抽象化して簡単にインフラを提供できることは価値がある ◦ 認知負荷の軽減 ◦ ガードレールによるセキュリティ向上 • Self-service提供機能や抽象化をリッチにするほど運用はキツくなる。。。 ◦ 設計・開発・検証・運用作業が辛い。。。 ◦ 振る舞い駆動テストは自信になるが、重荷にもなる 少ない記述で多くのこ とを達成できる✅ 16 開発・検証・運用が大変💦 複雑になってきた💦
17. 組織への普及の大切さ 声を自ら拾いに行き、ファンを作るのが大事 • 利用者の近くで情報を取得・共有が、基盤利用に繋がった ◦ プロダクト定例に参加し、情報取得・共有 • 影響力のあるプロダクトエンジニアが推進力に ◦ 様々なプロダクトで基盤利用が勝手に広がる 機能追加しました！ 困りごとないですか？ この基盤使っていこう！ 17 実績あるし、いいらしいぞ
18. section 4 今後の展望
19. 今後の展望 • 新しい期になり基盤運用者が増えた ◦ オンボーディング中(ADRが役に立っている!) • 多くの機能をSelf-serviceとして追加予定 ◦ より多くのプロダクトが基盤にのっかれるように ◦ アプリ側の処理をより基盤へ • プロダクト開発者との同期的なコミュニケーション機会を増やす ◦ 基盤機能をfullに活用してもらえるように ◦ 困りごとや認知負荷を減らせるように • Inner Source文化の醸成(manifestベースだからいけるのでは？？) ◦ ◦ 基盤運用者への申請必須項目をPR提出へ プロダクト開発者による必要機能のIssue/PR提出 今後も基盤を強化していき、マルチプロダクトを量産していく！！ 19
20. https://www.hacomono.jp/