0→1製品の毎週リリースを支えるGoパッケージ戦略——AI時代のPackage by Feature実践

2025/9/28 開催「Go Conference 2025」での発表資料です。

https://gocon.jp/2025/talks/1030797/

Transcript

1. © 2019-2025 OPTiM Corp. All rights reserved. 0→1製品の毎週リリースを支えるGoパッケージ戦略 〜AI時代のPackage by Feature実践〜 株式会社オプティム Go Conference 2025 2025/09/28 15:00 ～ 15:20 @ROOM2
2. © 2019-2025 OPTiM Corp. All rights reserved. 2 自己紹介 上原 技術統括本部 プラットフォームサービス開発部 マネージャー  生まれ: 沖縄県  入社: 株式会社オプティム 新卒入社  入社後: 開発リーダーとしてAI製品の開発  現在: 開発マネージャーとしてAI製品の開発 o OPTiM Contract（LLM 契約書管理） o OPTiM 電子帳簿保存（LLM 帳票管理） o OPTiM 文書管理（LLM 文書管理）
3. © 2019-2025 OPTiM Corp. All rights reserved. 3 会社紹介
4. © 2019-2025 OPTiM Corp. All rights reserved. 4 会社紹介 商号 株式会社オプティム（プライム市場：3694） Tokyo Kobe 設立 2000年 オフィス OPTiM TOKYO（東京本社@浜松町） 総スタッフ数 700名 ※正スタッフ 433名 OPTiM SAGA（佐賀本店＠佐賀大学キャンパス内） OPTiM KOBE （神戸オフィス＠三ノ宮） TECH CENTER IIZUKA （テックセンター飯塚＠九州工業大学飯塚キャンパス前） 代表者 菅谷 俊二 うち７割がエンジニア職 Optimization:最適化 Optimism:楽観主義 × （2025年4月現在） Saga
5. © 2019-2025 OPTiM Corp. All rights reserved. 5 オプティムのミッション
6. © 2019-2025 OPTiM Corp. All rights reserved. 6 オプティムは、AI・IoT・Cloud・Mobile・Roboticsを使った新しい価値を創造し続け、あ らゆる産業のDXを推進し、あらゆる人々に、豊かでサステナブルな未来を実現する企業です 事業・提供サービス概要
7. © 2019-2025 OPTiM Corp. All rights reserved. 7 生成AI分野への取り組み AIエージェントを中心的価値とした新サービス 顧客価値を創造する多様なAIサービスポートフォリオと市場展開 ※1 2024年11月7日時点、当社調べ。電子カルテと連携し、オンプレミスとして導入されるLLM搭載サービスとして。 ※2 2024年6月26日時点、当社調べ。AI（LLM）を使った自動写真報告書作成サービスとして。 ※3 2024年10月17日時点、当社調べ。 【オフィス業務汎用型AIエージェント】 オフィスの社内文章探索から 顧客対応まですぐに利用できるAIエー ジェント 【医療文書生成AIエージェント】 国内初※1、医師・看護師の文書作成 業務を生成AIが支援する、 オンプレミスAIを搭載した サービス AI統合によるUX刷新 【報告書生成AIエージェント】 生成AIを用いた世界初※2の 報告書自動作成カメラアプリ 国内初※3となる生成AIが実現 するカスタマーサクセスサービス AI電子帳票管理システム クラウドAI文書管理サービス MDM・PC管理サービス 「OPTiM Biz」へのAI統合 オフィス業務汎用型AIエージェントから特定業界向け特化型AIまでをラインナップ さまざまなAIサービスを1年でリリースし、素早い市場展開を実現 2025年度も特許技術などを活用した新しい数多くのAIサービスのリリースを計画
8. © 2019-2025 OPTiM Corp. All rights reserved. 8 生成AI分野への取り組み 全社的なAI活用による抜本的な生産性改革とイノベーション加速 全従業員のAIリテラシー向上と、開発現場へのAIツール導入により、全社レベルでの生産性向上を達成 全社的なAI活用推進 開発プロセスの革新 AI活用ワーキンググループの 立ち上げにより、より全社的 な浸透・推進。全スタッフ 向けにLLMチャットを提供し 日常業務を効率化 AI開発支援ツールを全開発チー ムへ導入・活用し開発スピード と品質の向上を推進中 活用ツール：Continue/Cline/ Cursor/PR-Agentなど テックブログとして公開
9. © 2019-2025 OPTiM Corp. All rights reserved. 9 生成AIを用いたプロダクト: OPTiM Contract 設定不要のAI-OCRで 契約書管理台帳を自動作成！ 電子帳簿保存法に対応 連携機能で電子契約を保管可能！ 契約期間をAIが取得し 期限前に自動通知！
10. © 2019-2025 OPTiM Corp. All rights reserved. 10 生成AIを用いたプロダクト: OPTiM 電子帳簿保存 取引年月日 タイトル 取引先 取引金額 AIが電帳法関連項目を解析し台帳化！かんたん法令対応！ AI解析による電子帳簿保存法対応 取引情報を扱う書類全般に対応 自社・他社など専用フォーマット問わずAI解析！ 初期費・従量費不要！月額9,980円～でお手軽に導入可能！ ？ 電子帳簿保存法対応の工数が捻出できない 保存要件項目の入力の手間が大きい 書類の保管場所が点在し対応状況が不明 アップロードだけの作業で細々したお悩みをAI解析で解決！ OPTiM 電子帳簿保存は、AIを活用して請求書や注文書などを電帳法の義務化要件に対応して管理できるサービスです アップロードを行うだけで書類情報をAIが自動的に抽出・台帳作成し電子帳簿保存のコスト削減を実現いたします インボイス 登録番号
11. © 2019-2025 OPTiM Corp. All rights reserved. 11 生成AIを用いたプロダクト: OPTiM 文書管理 全文検索機能 キーワードだけでなく文書に含まれる 全文情報から簡単検索可能 期限通知機能 有効期間など文書に紐づく作業を 担当者へ自動通知し対応漏れを防止 外部サービスから自動取込 メール添付からの自動取り込み 特定ストレージから簡単取り込み可能 AI解析により法定文書・業務書類などの文書管理のコスト・リスクを削減するサービスです AI解析・自動台帳作成 文書データをアップロードするだけ！ フォーマット不問！かんたんAI台帳化 OPTiM 文書管理なら AIであらゆる文書を一元管理！ 今回はOPTiM 文書管理の0→1立ち上げにあたっての話
12. © 2019-2025 OPTiM Corp. All rights reserved. 12  新規製品の市場投入において、変化するビジネス要件に対する迅速な機能開発・デプロイ  法定文書の電子保管システムとして、法的要件を満たす10年以上の長期運用・保守 OPTiM 文書管理のバックエンドにGo言語を選定 製品要件 Go言語の選定理由  軽量バイナリと高速起動により、拡張性に優れたマイクロサービス環境との高い親和性  シンプルな言語仕様と強固な後方互換性により、長期運用における高い保守性を担保  明示的な依存管理と循環参照の禁止により、機能単位での分離・構成が容易でPackage by Feature構成（今回のテーマ）との親和性が高い
13. © 2019-2025 OPTiM Corp. All rights reserved. 13 1. Goパッケージ構成 Package by Layer の課題感 従来製品の開発において 2. Goパッケージ構成 Package by Feature の実践と効果 OPTiM 文書管理の新規立ち上げにおいて 今日話すこと
14. © 2019-2025 OPTiM Corp. All rights reserved. 14 Package by Layer 構成の課題感 従来製品の開発において
15. © 2019-2025 OPTiM Corp. All rights reserved. 15 Package by Layer とは 処理のレイヤに基づいたパッケージ構成 handler/ ├── upload_hander.go ├── search_handler.go └── notice_handler.go usecase/ ├── upload_interactor.go ├── search_interactor.go └── notice_interactor.go repository/ ├── upload_repository.go ├── search_repository.go └── notice_repository.go ・・・アップロード機能 ・・・検索機能 ・・・通知機能 機能数の少ない開発初期において、 役割の明確化と構成のシンプルさを 重視して採用
16. © 2019-2025 OPTiM Corp. All rights reserved. 16 【従来製品】Package by Layer の課題感 課題感を受け、OPTiM 文書管理の立ち上げ時はパッケージ構成を再整理 2. 保守性の低下 製品規模拡大に伴い機能間の結合度が増大 変更影響範囲が拡散eca 1. 開発効率の低下 機能毎に開発担当を置く体制であるため、 体制拡大と共にレイヤ間の実装競合が頻発 repository/ └── document_repository.go usecase/ ├── upload_interactor.go ├── search_interactor.go └── notice_interactor.go repository/ … usecase/ … 変更影響範囲が不明瞭 A機能 B機能 C機能 コンフリクトが頻発 修正
17. © 2019-2025 OPTiM Corp. All rights reserved. 17 Package by Feature 構成の実践と効果 OPTiM 文書管理 0→1 立ち上げにおいて
18. © 2019-2025 OPTiM Corp. All rights reserved. 18 Package by Feature とは 製品の機能に基づいたパッケージ構成 handler/ ├── upload_hander.go ├── search_handler.go └── notice_handler.go usecase/ ├── upload_interactor.go ├── search_interactor.go └── notice_interactor.go repository/ ├── upload_repository.go ├── search_repository.go └── notice_repository.go upload/ ├── upload_hander.go ├── upload_interactor.go └── upload_repository.go search/ ├── search_handler.go ├── search_interactorgo └── search_repository.go notice/ ├── notice_handler.go ├── notice_interactor.go └── notice_repository.go ・・・アップロード機能
19. © 2019-2025 OPTiM Corp. All rights reserved. 19 【OPTiM 文書管理】Package by Feature の実践 ディレクトリ構成 feature/ └── health // 例: ヘルスチェック機能 ├── handler/ ├── usecase/ ├── repository/ ├── entity/ ├── health.go shared/ ├── usecase/ ├── repository/ └── entity/ pkg/ └── ... feature • 各機能を管理する独立したディレクトリ • 機能内では4層構造（handler～entity） • 各層に実装,テスト,モックを配置 shared • 複数機能で共有するレイヤ（handler〜entity） • 機能に依存しつつ共通で参照する操作など pkg • 全体で使用する汎用的な共通パッケージ • 機能に依存しない再利用可能なコンポーネント Goの明示的な依存管理と構成自由度を活かし プロジェクトに最適なディレクトリ構成を設計
20. © 2019-2025 OPTiM Corp. All rights reserved. 20 【OPTiM 文書管理】Package by Feature の実践 運用ルール 1. feature の単位はRESTful APIにおけるリソースと対応づけること ◼ 例えば、 GET documents/{document_id} の実装は feature/document 配下へ 2. feature 単位ではクリーンアーキテクチャで実装すること 3. feature 間は依存させずコード重複は許容、必要性があれば共通化すること 4. feature 横断の共通処理は shared, pkg, commons いずれかに配置すること ◼ shared: 該当リポジトリの複数機能で共有するレイヤ（handler～entity）の実装を格納 ◼ pkg: 該当リポジトリのアプリケーション全体で共有するパッケージを格納 ◼ commons: リポジトリを横断してマイクロサービス全体で共有するパッケージを格納
21. © 2019-2025 OPTiM Corp. All rights reserved. 21 【OPTiM 文書管理】Package by Feature で得られた効果 1-1.【開発効率】機能別の並行開発によるコンフリクト発生率を 1/3 に削減 upload/ ├── handler/ ├── usecase/ └── repository/ search/ ├── handler/ ├── usecase/ └── repository/ notice/ ├── handler/ ├── usecase/ └── repository/ アップロード機能 検索機能 通知機能
22. © 2019-2025 OPTiM Corp. All rights reserved. 22 【OPTiM 文書管理】Package by Feature で得られた効果 1-2.【開発効率】機能境界の明確化によりAIコーディングとの親和性が向上 csv_export/ ├── ... └── .cursor/rules/ user_setting/ ├── ... └── .cursor/rules/ .cursor/rules/ 機能毎にAI向けのルールファイルを配置 機能単位でAIへのコンテキスト入力 機能単位のコンテキスト設計とGo言語の静的型付けの 組み合わせでAIコーディングの精度と一貫性が向上
23. © 2019-2025 OPTiM Corp. All rights reserved. 23 【OPTiM 文書管理】Package by Feature で得られた効果 2-1.【保守性】機能単位の独立性によりアーキテクチャ変更・分割が容易 upload/ ├── handler/ ├── usecase/ └── repository/ activation/ ├── handler/ ├── usecase/ ├── repository/ └── producer/ 機能単位でアーキテクチャ変更が容易 例えば、特殊な要件を持つアクティベーショ ン機能のみproducer処理層を追加可能 機能単位でアーキテクチャ分割が容易 Go Modulesの活用により、feature単位での モジュール分割やマイクロサービス化も容易
24. © 2019-2025 OPTiM Corp. All rights reserved. 24 【OPTiM 文書管理】Package by Feature で得られた効果 2-2.【保守性】ディレクトリ構造と依存関係の可視化により設計理解が促進 upload/ ├── handler/ ├── usecase/ └── repository/ shared/ pkg/ ディレクトリ構造の理解 新規ジョインした開発者にとっても、アップ ロード機能が feature/upload 配下に実装さ れていることが明確 機能の依存関係の理解 アップロード機能は feature/upload 配下か shared, pkg のみに依存していることが明確
25. © 2019-2025 OPTiM Corp. All rights reserved. 25 【OPTiM 文書管理】Package by Feature で得られた効果 2-3.【保守性】機能別テスト環境の構築・管理が効率化（testcontainer） search/ ├── handler/ ├── usecase/ ├── repository/ └── search_test.go 機能別テスト環境 検索機能の複数レイヤを横断したテストは feature/search/search_test.go として配置 Go言語のtestingとtestcontainer-goにより ユニットテスト内でDBコンテナを起動し、 handlerからrepositoryまでを含む機能単位 の一貫した統合テストが可能
26. © 2019-2025 OPTiM Corp. All rights reserved. 26 【OPTiM 文書管理】Package by Feature で得られた効果まとめ 1. 開発効率 1. 機能別の並行開発によるコンフリクト発生率を 1/3 に削減 2. 機能境界の明確化によりAIコーディングとの親和性が向上 並行開発とAI活用により、少人数でもクイックな立ち上げが可能に 2. 保守性 1. 機能単位の独立性によりアーキテクチャ変更・分割が容易 2. ディレクトリ構造と依存関係の可視化により設計意図の理解が促進 3. 機能別テスト環境の構築・管理が効率化（testcontainer） 構造の明確化と依存管理により、拡張・分割を見据えた設計が可能に 開発効率と保守性が寄与し、製品立ち上げ後平均3.6回/月のリリースを実現
27. © 2019-2025 OPTiM Corp. All rights reserved. 27 パッケージ戦略の比較 Package by Layer 小規模や横断処理重視の製品に適し、構造がシンプルで一貫性を保ちやすい Package by Feature 中規模以上や拡張性重視の製品に適し、複数機能の並行開発やAI支援に優れる 観点 Package by Layer Package by Feature AI支援 △ ◦（機能単位のコンテキスト設計が可） 並行開発 △（小規模なら◦） ◦（中～大規模で特に◦） 拡張性 △ ◦（将来の分割・マイクロサービス化に強い） 可読性 △ ◦（新規参画者が多い場合に特に◦） 横断対応 ◦（機能の横断処理が多い製品に強い） △ 一貫性 ◦（実装の統一方針を維持しやすい） △（機能ごとにばらつきやすい）
28. © 2019-2025 OPTiM Corp. All rights reserved. 28 まとめ
29. © 2019-2025 OPTiM Corp. All rights reserved. 29 Package by Layer の運用課題 • 開発効率の低下: 並行開発増加に伴い同一レイヤでの実装競合が頻発 • 保守性の低下: 機能間の結合度の増大に伴い変更影響範囲が拡散 Package by Feature の導入と運用 • featureはRESTful APIにおけるリソースと対応づけること • feature間の依存は発生させず、コード重複は許容、必要性があれば共通化すること • feature横断の共通処理は shared, pkg, commons いずれかに配置すること Package by Feature の実践を通して • 並行開発とAI活用により、中規模以上の製品でもクイックな立ち上げが可能に • 構造の明確化と依存管理により、拡張・分割を見据えた設計が可能に • 一方、構造のシンプルさや実装方針の一貫性を求める場合には適用が困難な可能性あり まとめ Go言語の柔軟性を活かして、プロジェクトに最適なパッケージ構成を模索できました！
30. © 2019-2025 OPTiM Corp. All rights reserved. C O N F I D E N T I A L