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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2019-2025 OPTiM Corp. All rights reserved. 2 自己紹介上原技術統括本部プラットフォームサービス開発部マネージャー  生まれ: 沖縄県  入社: 株式会社オプティム新卒入社  入社後: 開発リーダーとしてAI製品の開発  現在: 開発マネージャーとしてAI製品の開発 o OPTiM Contract（LLM 契約書管理） o OPTiM 電子帳簿保存（LLM 帳票管理） o OPTiM 文書管理（LLM 文書管理）

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 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サービスのリリースを計画

Slide 8

Slide 8 text

© 2019-2025 OPTiM Corp. All rights reserved. 8 生成AI分野への取り組み全社的なAI活用による抜本的な生産性改革とイノベーション加速全従業員のAIリテラシー向上と、開発現場へのAIツール導入により、全社レベルでの生産性向上を達成全社的なAI活用推進開発プロセスの革新 AI活用ワーキンググループの立ち上げにより、より全社的な浸透・推進。全スタッフ向けにLLMチャットを提供し日常業務を効率化 AI開発支援ツールを全開発チームへ導入・活用し開発スピードと品質の向上を推進中活用ツール：Continue/Cline/ Cursor/PR-Agentなどテックブログとして公開

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2019-2025 OPTiM Corp. All rights reserved. 10 生成AIを用いたプロダクト: OPTiM 電子帳簿保存取引年月日タイトル取引先取引金額 AIが電帳法関連項目を解析し台帳化！かんたん法令対応！ AI解析による電子帳簿保存法対応取引情報を扱う書類全般に対応自社・他社など専用フォーマット問わずAI解析！初期費・従量費不要！月額9,980円～でお手軽に導入可能！？電子帳簿保存法対応の工数が捻出できない保存要件項目の入力の手間が大きい書類の保管場所が点在し対応状況が不明アップロードだけの作業で細々したお悩みをAI解析で解決！ OPTiM 電子帳簿保存は、AIを活用して請求書や注文書などを電帳法の義務化要件に対応して管理できるサービスですアップロードを行うだけで書類情報をAIが自動的に抽出・台帳作成し電子帳簿保存のコスト削減を実現いたしますインボイス登録番号

Slide 11

Slide 11 text

© 2019-2025 OPTiM Corp. All rights reserved. 11 生成AIを用いたプロダクト: OPTiM 文書管理全文検索機能キーワードだけでなく文書に含まれる全文情報から簡単検索可能期限通知機能有効期間など文書に紐づく作業を担当者へ自動通知し対応漏れを防止外部サービスから自動取込メール添付からの自動取り込み特定ストレージから簡単取り込み可能 AI解析により法定文書・業務書類などの文書管理のコスト・リスクを削減するサービスです AI解析・自動台帳作成文書データをアップロードするだけ！フォーマット不問！かんたんAI台帳化 OPTiM 文書管理なら AIであらゆる文書を一元管理！今回はOPTiM 文書管理の0→1立ち上げにあたっての話

Slide 12

Slide 12 text

© 2019-2025 OPTiM Corp. All rights reserved. 12  新規製品の市場投入において、変化するビジネス要件に対する迅速な機能開発・デプロイ  法定文書の電子保管システムとして、法的要件を満たす10年以上の長期運用・保守 OPTiM 文書管理のバックエンドにGo言語を選定製品要件 Go言語の選定理由  軽量バイナリと高速起動により、拡張性に優れたマイクロサービス環境との高い親和性  シンプルな言語仕様と強固な後方互換性により、長期運用における高い保守性を担保  明示的な依存管理と循環参照の禁止により、機能単位での分離・構成が容易でPackage by Feature構成（今回のテーマ）との親和性が高い

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 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 ・・・アップロード機能・・・検索機能・・・通知機能機能数の少ない開発初期において、役割の明確化と構成のシンプルさを重視して採用

Slide 16

Slide 16 text

© 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機能コンフリクトが頻発修正

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 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 ・・・アップロード機能

Slide 19

Slide 19 text

© 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の明示的な依存管理と構成自由度を活かしプロジェクトに最適なディレクトリ構成を設計

Slide 20

Slide 20 text

© 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: リポジトリを横断してマイクロサービス全体で共有するパッケージを格納

Slide 21

Slide 21 text

© 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/ アップロード機能検索機能通知機能

Slide 22

Slide 22 text

© 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コーディングの精度と一貫性が向上

Slide 23

Slide 23 text

© 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単位でのモジュール分割やマイクロサービス化も容易

Slide 24

Slide 24 text

© 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 のみに依存していることが明確

Slide 25

Slide 25 text

© 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までを含む機能単位の一貫した統合テストが可能

Slide 26

Slide 26 text

© 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回/月のリリースを実現

Slide 27

Slide 27 text

© 2019-2025 OPTiM Corp. All rights reserved. 27 パッケージ戦略の比較 Package by Layer 小規模や横断処理重視の製品に適し、構造がシンプルで一貫性を保ちやすい Package by Feature 中規模以上や拡張性重視の製品に適し、複数機能の並行開発やAI支援に優れる観点 Package by Layer Package by Feature AI支援 △ ○（機能単位のコンテキスト設計が可）並行開発 △（小規模なら○） ○（中～大規模で特に○）拡張性 △ ○（将来の分割・マイクロサービス化に強い）可読性 △ ○（新規参画者が多い場合に特に○）横断対応 ○（機能の横断処理が多い製品に強い） △ 一貫性 ○（実装の統一方針を維持しやすい） △（機能ごとにばらつきやすい）

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 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言語の柔軟性を活かして、プロジェクトに最適なパッケージ構成を模索できました！