プロダクトコードからライブラリの境界を見つける

1. プロダクトコードから ライブラリの境界を見つける 「ほかでも使えそう」を、 公開できるSwift Packageへ再設計するまで elmetal Cybozu, Inc. iOSDC Japan 2026 2026-09-12 #iosdc #c 1
2. About me @el̲metal̲ iOS App Developer 複数チームの 技術支援 #iosdc #c 2 競馬 対戦ゲーム 育児
3. サイボウズについて #iosdc #c 3
4. チームワークあふれる 社会を創る #iosdc #c #チームワークあふれる社会を創る 4
5. サイボウズについて iOSアプリ kintone サイボウズ O ce Garoon サイボウズでは複数のプロダクトを開発しています #iosdc #c ffi 5
6. Intro #iosdc #c
7. 🤔このコード他でも使えそう #iosdc #c 7
8. 🤔ライブラリにできないか #iosdc #c 8
9. サイボウズでは色々ライブラリ作りました WebUI LicenseList #iosdc #c 9 認証（社内ライブラリ）
10. 新規アプリの基盤構築を 4~5ヶ月から約2週間へ短縮 #iosdc #c 10
11. サイボウズではどのように ライブラリに再設計しているかお話しします #iosdc #c 11
12. ライブラリの境界を見つける #iosdc #c 12
13. 「ほかでも使えそう」から始める • ライブラリの境界：ライブラリ側の責任と利用側の責任の線引き • 共通部分っぽいところを見つけて抜き出してみる • 基盤でも共通アルゴリズムでも、なんでもok • 共通部分を大きく取ろうとしない • 大きく取れるところは取ろうとしなくても自然と大きく取れる #iosdc #c 13
14. ライブラリ、リポジトリの名前を決める • 責務を表現する命名を試みる • 一言で表現するくらいの粒度で • 細部はまだ決めない • APIを作る時に自然と境界が決まっていく • 被りがないかGitHubで検索しておく #iosdc #c 14
15. ライブラリのための再設計をする #iosdc #c
16. 責務を分析して境界を再設計する • コードを別のモジュールに移動してpublicにするだけでは機能するライブラリ にならない • 元のコードのスメルが残りがち • 移動元にあった固有の型に依存している • 特定の状態管理や画面構成が前提になっている • 内部実装の都合が反映された呼び出しになっている #iosdc #c 16
17. 責務を分析して境界を再設計する • 疑似コードを使って複数の呼び出し案を考える • 実装が全くない状態で議論している • これらの選択肢を使って議論した上でADRに記録を残す #iosdc #c 17
18. 責務を分析して境界を再設計する 擬似コードの例 WebUIで検討していた時の疑似コード struct ContentView: View { var body: some View { WebViewReader { proxy in VStack { Button("Go back") { proxy.goBack() } WebView(url: URL(...)) } } } } #iosdc #c 18
19. ライブラリが担う責務を決める • プログラム上の責務 • ライブラリ側と利用者側の責任分解点の線引き • 先に全部決めるのは難しい • 存在を認識した上で決めるのを後でやる部分があっても良い #iosdc #c 19
20. プロダクト固有の依存を探し出す コードレベル • プロダクト独自の型 • ViewModel/Store 基盤 暗黙の前提 • Navigation • デザインシステム • ログ・分析基盤 • 認証基盤 #iosdc #c 20 • 状態管理 • 画面構成
21. 不要な依存を取り除く • そもそもライブラリ内に依存が必要かを考える • 積極的に利用側へ戻す • アプリごとに異なるものは利用側の責務とする • プロダクトの状態管理やデザインシステムとの接続はプロダクト側のAdapter が行う #iosdc #c 21
22. API設計 • 利用側の呼び出しを決める • API Documentを書く • この型が何か, メソッドの返り値が何か • この時点での実装可能性は考慮しない #iosdc #c 22
23. 利用者のためのAPIを設計する • よくある用途が自然に書けるか • 高度な機能が段階的に使えるか • 内部の概念が漏洩していないか • 不正な組み合わせを型レベルで防げるか • Swift/SwiftUIの語彙に馴染んでいるか #iosdc #c 23
24. API設計Tips インターフェースに標準の型を使う • Swift標準ライブラリの型 • swift-lang・appleのライブラリの型 • 利用側に安定したインターフェースを提供できる #iosdc #c 24
25. API設計Tips ポリシーに従って決める • 何でも差し替え可能にしない • 提供するスコープを超えた拡張を考慮しない • 責務を超える要求を受け入れない #iosdc #c 25
26. 呼び出し側から設計を精査する #iosdc #c
27. 利用例で評価する • 抽象度が適切かどうか利用例を使って評価する • ドキュメント • テスト • サンプルアプリ • API設計の精度を高めていく • 線形のプロセスでなくてよい #iosdc #c
28. DocC • APIリファレンスはAPI設計時に書く • API Design Guidelines | swift.org • 設計がおかしいとドキュメントがうまく書けないので設計へのフィードバ ックになる • API以外にもライブラリのOverviewや基本概念、重要な制約について書く • Apple Developer Documentationのスタイルを踏襲する #iosdc #c 28
29. テスト • テストは最初の利用者 • コードレベルでAPIがおかしくないかフィードバックする • 公開APIの振る舞いを検証する • 入出力の契約 • エラーの挙動 • プラットフォーム差異 #iosdc #c 29
30. サンプルアプリ • サンプルアプリで統合する • 機能レベルだけでなくコードレベルでもうまく統合されているか確認する • アプリの利用例として機能させる • 実行可能なドキュメントとして扱う #iosdc #c 30
31. 運用の設計 #iosdc #c
32. CIを動かす • ビルド・テスト • 複数プラットフォームでのビルド • サンプルアプリでのビルド • DocCのドキュメント生成とGitHub Pagesへのデプロイ #iosdc #c 32
33. 公開後の運用ポイント • Issueはライブラリの責務範囲内か • どこまでをライブラリ側API追加で、どこまでを利用側で解決すると線引きするか • 破壊的変更を行う価値があるか • APIやサポート対象の廃止 • Deprecatedによる移行期間設定 • セマンティックバージョニング #iosdc #c 33
34. 最近のサイボウズでは • 最近はいきなり別リポジトリを立てることが多い • 設計や責務のスコープを決めるのに慣れてきた • プロダクトコードの中で価値が出そうなところは大体やり切ってしまった • リポジトリ作成時点でOSSを射程に入れている • 社内ライブラリで開発開始しつつOSSにできそうか見てみる • 社内ライブラリのままでもOKのスタンス #iosdc #c 34
35. まとめ • 共通の責務を見つけ、抽象度を上げて、機能するライブラリに再設計する • APIドキュメント、テスト、サンプルアプリ、実アプリと段階の異なる利用者 でAPI設計を精査する • 公開するとライブラリの境界をメンテナンスすることになる #iosdc #c 35
36. ありがとうございました #iosdc #c