久々のイベント物理参加。冒頭から高密度なAI活用に関する発表が続いて、AIの勉強会かと錯覚した。が、それほどにAI活用が「AIすごい！」を超え、エンジニアのコーディングにとどまらずQAや顧客対応にも浸透していると感じた時間だった。発表の中で、Claude Code/Copilot/Devinの使い分けの勘所に言及されていて参考になった。仕様駆動が当たり前の様に語られていて、弊社でも実践している。ただ「仕様駆動」で満足するだけでなく、いかに効率性や確実性を高められるかに、世の中の関心ごとが移っていることは明らか。こうした会を通じて各社のナレッジに触れられるのは大変ありがたい。
イベントページ：https://mobiletechflex.connpass.com/event/381976/
AIとなら実現できる事業と品質のシン化の両立
@a_key_bako さん
- シン化とは？
- AIによる外部環境の変化（CodexでSoraが28日で）
- 専門のAndroidチームがいたわけではなかった
- 爆速で使えるが、品質要求は自ずと高いものが要求される
- 各社のAI活用法や課題共有に価値がある
- 現状
- Deploys/Developer/Day 指標の変化推移
- デプロイされた数を、開発者x営業日で割る
- 1を超えた：かなり高い
- Mobileはデプロイを意識しない：masterブランチへのマージ数をdeployとカウント
- 変わったこと
- ジュニア：アウトプット出しながら学習（先輩への質問以外という選択肢）
- シニア：自身の知識が生産性に直結（ボイラープレートをAIに任せる）
- 役割での使い分け
- コーディングはCC、レビューはCopilot、越境はDevin（テストケースを尋ねたり、いろんな職能が使う）
- CC：低コストでペア作業
- CLAUDE.md、git worktree、ghコマンド（巨大PRの分割もスムーズ）
- Devin：
- 専門街プラットフォーム越境に便利（mobile→BE）
- 作業プロセスがチームに見える
- これからの課題
- 課題1：技術的夫妻
- 返済はできない
- 課題2：AI活用の限界
- 今のプロセスだとせいぜい一人ができることの効率化で限界がある（2倍にはなってもそれ以上には）
- 納期ベース下での事業と品質のトレードオフ
- リソースが潤沢でないと大規模リファクタリングができない
- 課題をブレストすると、課題の洗い出しと優先度づけをした（重要度、漸進可能性、楽しさ）
- 重要度：プロダクトへの影響度→やらざるを得ない
- 漸進可能性：少しずつ進められるか（Viewごとに進められる？画面ごと？or一気に置き換え必要？）
- 高いものはAIによる自律的置き換えに向いている
- 楽しさ：学びの多さ、賞味期限→投資効果が高い
- 課題1：技術的夫妻
- AI支援によって、専門外でも一定品質でコード生成可能に
- ガードレイルの重要性が増す
- 原理原則をガードレイルにする
OSアップデート：年に一度の「大仕事」を乗り切るQA戦略
- OSアップデートはなぜ大仕事なのか
- リリースが多く、クライアントによって機能の紐付け設定が多様
- OSアップデートによる調査工数が増大
- リグレッションテストケースが肥大化
- 現状のテスト戦略の課題
- テストケースが肥大化しQAリソースが不足
- 機能仕様の理解の属人化（QA担当者が一番詳しい）
- 担当者による観点粒度に差分
- 対策
- 観点粒度を汎用的にし、テストケースを見直し
- テスト自動化（勉強会を開催し共有）
- ↑アウトプットのテストコードをGitHubで一元管理
- 相互機能影響をAIで抽出（過去実施のテスト観点や実装PRを用いて）
“レビュー”だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか？
@ko_yack さん
- 活用深化と活用領域のマッピング
- チームでの半年前はコーディングとレビュー
- CCに設計テストレビューするまで全て行っている
- アプリビルドはDevin経由
- 問い合わせ調査はAtlassian Rovoでエンジニアが一時解凍できる様に
- CCの活用における課題
- コンテクストの枯渇：AIが参照不要な情報を読み取ろうとし、コンテクスト枯渇し忘却する
- AI用ドキュメントをどこに置くか：CLAUDE,mdだとツール入れ替えた時にスイッチできない
- 広い範囲の修正をしたい
- メンバー習熟度の違い
- 課題の解決
- ドキュメントの構造化：root.instructions.mdを起点として、アーキやコーディングプラクティスを記載する
- ドキュメントは読むべきタイミングと参照先をセットで管理し、無駄な参照を防ぐ
- Spec-Driven Development (SDD) の導入
- Proposal phase, Research & Planning phase, Implementation phase, Retrospective phase
- フェーズごとにsubagentで分ける
- 例: Swift移行のために、設計やマイグレーションのナレッジを構造化
- 例: iOSで作った設計ドキュメントをもとにAndroidでもなぞらせた
- Snapshotテストを導入
- UIテストもAIに自律的に修正させる
- Skills の活用
- 問い合わせチケット切られたらRovo AgentにJiraなどの情報をRAG経由で参照させ、回答させる
謎現象の解決手段を発見して プチ英雄になりました
@shiosioco40 さん
- Androidだと、React移行後JSInterface経由のインタラクションができなくなった
- zod: プロパティアクセスと呼び出しの分離が原因
- 参照と実行顔同時でないとJSInterfaceのメソッドをWeb側が実行できない
- 回避策：JSInterfaceの参照を無名関数でラップする（アクセス実行の寸前まで触れない）
Claude × Markdown で仕様書をいい感じに管理したい
@AtriaSoft さん
- Claude Code を使った仕様書作成管理の便利さと課題
- 仕様書の老朽化問題（Confluenceの最終更新が2年前、、）
- メンバー入れ替わりでメンテナンスが宙ぶらり
- エンジニアに書くモチベーションがない、余裕がない
- サブエージェント4体
- reader, writer, reviewe, simpler(簡潔に書き換える)
- 自然言語で指示したら、readerが既存仕様書やコードベースを読み解いて、writerに渡して仕様書を作成、更新。reviewrがその仕様書の生合成をチェックし、simplerが仕様書を簡潔に書き換える
- エンジニアがレビューしてPR、レビュー、マージ
- honkitを利用して、mdファイルは見やすい形にエクスポート
- 良かったこと
- 「書く」でなく「レビューする」で知り的ハードルが激減
- 課題
- 出力が冗長になりがち、コンテクスト共有に最適化されていない、図表表現に限界（Mermain導入したい）
Kotlin Multiplatform + iOS アーキテクチャの実践
株式会社ディップ 権 さん
- KMPの実運用での使い分け
- ビジネスロジックをKMP共有、UIは各OSネイティブ
- Presentationは書くOS
- sharedで、Domain/DataをKMP共有
- modelはPure domain model
- データ変換フローは、
- Entity
- DTO
- Model
- iOS側のUIアーキテクチャ
- 画面ごとの状態管理がバラバラだと、状態遷移の追跡とKMP連携の責務分離が難しくなる、自作アーキテクチャ(Store Pattern)を採用（Intent(ユーザー操作)/Store/State/View）
- iOS側はMVIをStore Patternで実装し、Android MVIと読み方揃t、チーム認知を統一
- ObservableでState変更を購読
- Store Patternのメリット
- 複雑な機能にスケールしやすい：小規模から大規模まで設計を継続可能
- チーム運用しやすい：Androidと似た設計で読み方統一、UIイベントの扱い方を共有化でき、レビュー観点揃えられる
- KMPのSwift側の呼び出し体験をSKIEで改善
- 今後、Swift Exportで、Obj-Cヘッダ経由の負荷を減らせる可能性があり、experimentalだが、よりSwiftらしいAPI公開に期待
バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計
株式会社ディップ 宮川さん
- 20年以上続くシステム課題の解消
- ドメイン駆動設計、AI前提の開発プロセス、AIネイティブな体制
- SwiftUI、デザインシステム、KMP、Strinct Concurrency Checking…
- Swift Package Managerによるパッケージ管理
- 分割の基準、機能画面ごと、外部依存の隔離(Firebase, KMPなど)、再利用性の担保(UI components, design system)
- 全体構成が把握しやすくなり、循環参照を抑止できた
- SwiftPMにおける課題
- KMPなど外部に依存している状態で、SwiftUI Previewが不安定（タイムアウト）
- 外部サービス依存のモジュールを限定的にし、protocolやmockのみを定義したInterfaceモジュールを定義し、中間に挟む様にし、KMPなどへの直接依存を回避した
- poinfree / swift-dependencies により実現
- AIコーディングによる課題（CC）
- 意図しないモジュールにコードが生成される
- モジュールごとに定めた依存関係のルールを守らない
- CLAUDE.mdに全ルールを記述していたが、コンテクスト肥大化するため、.claude/rules/を活用して最適化した
- レイヤー概念を導入してルールをシンプル化：モジュール数の増大で依存関係が複雑化する、AIにとっての認知負荷も増大するため、モジュールの責務ごとにグルーピングしたレイヤーを導入した（同じレイヤーは、同じ依存ルールに則る）
- ruleファイル自体が設計ドキュメントとして機能