前回に続き、二度目の4社合同勉強会 Mobile Tech Flex 開催にも参加してきた。
イベントページ：https://mobiletechflex.connpass.com/event/391245/
他技術領域へ越境するエンジニアに限らず、QAやエンジニアからPdMへのジョブチェンにあたっての越境話など盛りだくさんで非常に刺激を受ける発表ばかりだった。懇親会で他社さんの話を聞く中で、会社からの命によって「プロダクトエンジニア」となりフルスタックで駆け出されている例を複数知って、確かにAI時代はその変化が自然だとは頭の中で思っていたが、世の中すでにその方向に動き出しているのだと驚きがあった。
チームの仕組みで作る心理的ハードルを下げる越境
@tokotoko_kt さん
- 越境ハードル高い
- 前提知識の壁：そもそもどこから手をつけて良いかわからない
- 設計思想の違い：OS、言語異なりキャッチアップが億劫
- 失敗への不安：不慣れなコード扱う、レビュー不可を気にする
- チーム：Android 5名/iOS 5名、KMP採用
- 担当OS縛られずにタスク取っていこう → 文化で許容しても手が出なかった
- ある取り組みで変化が起きた → チーム全員が両OSのタスク取れるようになった
- ガードレールを作った
- 基盤とルールの明文化
- ドキュメントをすべてリポジトリで管理（ユーザーストーリー、設計ADR、実装タスク）
- コードを開いて元で実装意図文脈をすぐに知れて、コンテクストスイッチなど迷う時間を減らせた
- ADRはAIも参照しやすい
- Claude 環境の整備
- FIgma MCP連携
- UI作成のスキル作成（情報収集、分析、修正、検証）
- Roborazzi 使って Figma デザインと比較している
- UI作成のスキル作成（情報収集、分析、修正、検証）
- 各OSのビルド／テスト実行スキル
- Xcode/AS 起動せずにビルドテストが完了して開発効率向上
- FIgma MCP連携
- AIでの1次レビュー→OS専門のエンジニアが2次レビュー
- 効果
- 迷う時間の削減：明文化されたルールとAI
- 心理的安心感：セーフティネットの存在
- 柔軟なチーム運用
Androidエンジニアが大規模プロダクトの
Webフロントエンドとバックエンドに越境して
感じたギャップと習得したマインド
- 「プロダクトエンジニア」の役割
- オーナーシップを持ってプロダクトを実現する
- プログラミングするだけで無く価値を出すことに向き合う、そのためにやれることはなんでもやる
- オーナーシップを持ってプロダクトを実現する
- モバイルエンジニアの越境
- モバイルの機能はアプリだけでは完結しない：API、Webフロントエンド
- BEチームの対応を待たず自分で撮りにいく → バックエンドやフロントエンドのタスクを手がけて書けるコードの幅を広げていく
- 越境は、簡単にできるのでは？
- Android に比べて越境先のコードベースは60倍、チーム20倍、開発歴史2倍
- いけるっしょと思ったが、想像とは規模が違った
- Java、InteliJなどAndroid開発者にとっては親しみやすい
- 一方、DBやコンテナのセットアップなど開発環境構築に苦労
- 慣れた頃に起き始めたギャップ
- APIは一度出したら仕様変更が大変（マイグレーション、古いモバイルへの互換性）
- BE、モバイルのリリースタイミングのコントロールが難しい
- 自分たち都合で延期できない
- 乗り越え方、マインド
- 序盤：類似実装を探して真似したり、たくさん書いた、人に聞く（ペアプロモブプロレビュー）
- 慣れてきてから：AI活用しながら開発、TDDで仕様を説明するテスト書く習慣
- ひとつひとつ積み重ねるしかない
- 他領域が分からなくても、今の専門性が後ろ盾になり、人を頼るちからになる
- AIを、楽をするためではなく、好奇心を満たすために使う（成果物を頭の地図として残す）
QAから越境できるところに染み出てみた
@Cp6rrR さん
- 上流から下流までみれるQAならではの仕組みの話
- PdMとの垣根を超えて仕様書を直した
- 仕様書と実態のズレが生じる：会議の内容が反映されない、情報分散
- QAがその場で修正した：仕様確認はQAが一番している、PdMと定期ミーティング、分散した情報を振り返る時間をとった
- 仕様書が常に最新に保たれる状態を実現できた
- テストをエンジニアに託した
- 開発ラインに対してQAが不足
- エンジニアにテスト設計を託した、QAはレビューと観点共有を専念し、最終確認はQA実施
- 予定通りにリリースできた
- 役割を委譲する判断
越境するプロダクトエンジニア
〜 1人1プロジェクト × AI でどこまでやれるか 〜
@tomodev0015 さん
- 全員がプロダクトエンジニアになっていった、働き方が大きく変わった
- これまで：チームで分担してひとつの機能を開発（iOS+Android+Web+Backend）
- これから：ひとりで1プロジェクト
- AIを使いながらどこまでやれるか？
- どう越境したか？
- 知識のキャッチアップ：AI投げっぱなしでは無く最低限わかる領域を増やす（SQL/Go?kubernates）
- とはいえやりながら吸収
- AIで敵対的レビュー：実装計画や実装をレビューさせた
- 知識のキャッチアップ：AI投げっぱなしでは無く最低限わかる領域を増やす（SQL/Go?kubernates）
- AR使えばなんでもできる？専門外でもなんとかなる？
- そんなに甘くなかった
- AIできるようになった
- 実装コストが激減（やりなおしも効きやすい）、慣れない領域でモスポード維持できる、挑戦のハードルが下がった
- AIがあっても苦労したこと
- 生成物への理解が追いつかない、大量の生成物を理解し続けなければいけない
- 慣れない領域で知らないことを理解しながら意思決定する必要がある
- DBテーブル設計、パフォーマンス、あるべきがわからない
- つまり、認知コストが増大した
- 自分が知っている領域だけ → 企画ふくめて全領域へ
- 技術的判断が難しい（バックエンド領域で、SQLパフォーマンス、テーブル設計、インデックス）
- 動くかどうかはわかるが、正しいかの判断には技術力が問われる
- 変わったこと
- 視野が広がった、価値提供のスピードが上がって増えた、全体最適の視点が得られた
- ARと人の役悪の境界を考える
- 技術の本質は変わらない、トレードオフを伴う技術的な課題も大きく変わらない、基本的な技術知識は引き続き価値がある
エンジニア兼PdMが企画を通すためにやったこと
@horitamon さん
- 企画への越境
- AI使うと実装が一瞬で終わる
- 工数7割がリファクタになり始めた：新機能が作れていない、プロダクトが進化していない
- アイデアもたくさんあるからエンジニア主導で企画していこう
- 通った企画は半年で1件だけ → PdM専任になり2ヶ月5件通過
- なぜ通らなかった？
- 時間が作れなかった
- 草案を書いてPdMに投げてもレビューが止まっていた
- 指摘のポイントが毎回異なるので承認の基準がわからない（コードレビューと異なる）
- 通すためにやったこと
- 並行作業はしない、もとの仕事は任せられることは任せる
- チームにも並行作業を求めない：最初から仕組み化、非属人化を狙わない
- まず自分→それから型作り
- 企画の通し方を理解して、できそうな人をピックアップした上で型作りをする
- レビュー状況を自分でマネジメントする
- 忙しそうなPdM、企画のオーナーシップは自分にあるので臆さずリマインドする
- PdMの中にも優先度がある、そこに乗せてレビューしてもらう
- PdMのやり方をいちから学ぶ
- 課題を明確にする
- 顧客からのフィードバックを深掘りする（フィードバックを鵜呑みにした機能だと、本当に課題を解決できているんだっけ？となる）
- 使われない機能を作らない
- e.g. アクションボタンにショートカット登録しては？？ → 顧客層にそもそもアクションボタン対応の機種ユーザーが少ない
- ちょっとでも使われていない機能を出すと、廃止も難しくなる
- 4つの視点で必要性を語る
- いまやるべきか
- 買いたい機能も別にある
- 売りたい機能と使われる機能
- ジョブから理解する
- アプリの世界で考えがちだが、アプリを使うためでは無くやりたいことをするためにツールとしてアプリを使う（現場の人がどういうことをしたくてアプリを使っているのかを理解する）
- 課題を明確にする
- 越境で一番大変なのは：インプット
輪読会を開いて他職種の人と交流を持とう
mikan さん
- デザイナーと仕事終わり技術入門
- バックエンド+デザイナーとデータモデリング
- デザインの本読んだり
- いろんな視点の話が聞ける
- 同じ段落でも職種によって引っかかりポイントが違う e.g. アクセシビリティ
- 一人で読んだら素通りするポイントで、職種によってくるお話が聞けたり、議論が起こる
- 本を権威にして自分の主張が届けられる
- 自分がこう思う → 本にこう書いてある
- e..g. オーバーエンジニアリングやめよう → 結合バランスを読む
- 読み終わる頃には共通言語ができている
- 自分がこう思う → 本にこう書いてある
- 「他職種と話す口実」
- 交流が目的だと気まずくて続かない
- 輪読会は目的が本と設定されているのでネタに尽きない
- 続けるコツ
- 人数は五人以下、多いとしゃべらなくなる
- 限界まで緩く
- 予習なし
- 交代で音読するだけ（進行スキル不要）
- 記録ノート取らない（義務化して集中できない）
- 読みたい よりも課題解決本（盛り上がる）
iOS/Androidの二刀流エンジニアがFlutter & TypeScriptへ越境後の現在地
@fumiyasac さん
- 越境で直面した壁
- 技術面よりも大変だったこと：背景、ドメイン知識、現行仕様
- 技術は事前素振りで埋めれる余地はあるがドメイン知識は業務に入らないとわからない
- ドメイン知識の壁
- 断片的理解で進めてしまうリスク、仕様背景、影響範囲（IoT、不動産、認証など幅広い）
- AI活用の落とし穴：調査段階でズレることがあった（土台がないと方向性の誤りに気づけない）
- ブレイクスルーのきっかけ
- 新製品対応で全体像が見えた（それまでは細かいタスクで断片的だった）
- 問い合わせ対応でドメイン理解が深まった
- 問題報告→ドメイン知識に基づく切り分け、→仮説の立案→検証→対応
- 過去の経験が生きた瞬間
- ネイティブ知識があって得した：ネイティブに絡む不具合が見つけやすいなど
- ドメイン知識を深めるための取り組み
- 業務知識を自分で整理してみる：AIを使いながらドキュメント化する
- ドキュメントをコードから作る
- スキルセットが変わった時の心構え
- 未知の領域を楽しむ
- 知見を深める機会を自分で作る
- e.g. カンファレンスアプリへのコントリビュート
- 越境の醍醐味
- できることが増えて、仕事の達成感や成長実感が得られる
- 継続的な学びのプロセス