Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マルチプラットフォーム開発で広がる リードエンジニアのキャリア

マルチプラットフォーム開発で広がる リードエンジニアのキャリア

Avatar for Yuki Shiho

Yuki Shiho

January 16, 2026
Tweet

More Decks by Yuki Shiho

Other Decks in Technology

Transcript

  1. ©Tribeau, inc.| 2 志甫 侑紀 / Yuki SHIHO Software Engineer

    at Tribeau, Inc. @shihochan @shihochan_jp @shihochan    👉 Cat LOVER
  2. 本⽇のメッセージ: “技術選定=事業判断” ©Tribeau, inc.| 3 • リードエンジニアは、様々な要素、変数によって責務は会社毎に千変万化 • (トリビューの) リードエンジニアの責務は「最⾼の技術」を選ぶことではなく、「今この事

    業に最適な技術」を選ぶこと • 本⽇は、複雑なマルチプラットフォーム開発の現場で、どのように意思決定し事業成果に繋 げたか、その実践知を共有します! 2013年 サイバーエージェント 新規事業でのフルスクラッチ開発に没頭 AbemaTV (現Abema) ⼤規模サービスの開発を学ぶ 2019年 スタートアップ リードエンジニア‧PdM‧EMの三役を経験 現在 株式会社トリビュー モバイルアプリ開発チームをリード 様々な規模の事業を経験し “事業のための技術” の必要性を痛感
  3. マルチプラットフォーム開発で直⾯する3つの課題 ©Tribeau, inc.| 8 課題①: 技術スタックの分断 vs 統一 具体: iOS/Android/Webで同じ機能を

    どこまで共通化すべき? 統一: React Native, Flutter, KMM等 制約: 既存コード資産、チームのスキ ルセット、採用市場 課題②: チーム間の認識のズレ 具体: プラットフォーム毎のUI/UX慣 習やAPI解釈の違い 対策: Design Doc記載の徹底、実装 前のすり合わせ会の実施(作戦 会議) 課題③: リソース配分の難しさ 具体: 限られたリソースの中で全てを 同時に作れない。どこから着手 すべき? 判断材料: ユーザー比率、機能の性質、開 発コスト
  4. モバイルアーキテクチャ: OS別に最適化すべき理由 ©Tribeau, inc.| 9 共通化しない領域 領域 理由 API仕様 エンドポイント定義、リクエスト/レスポンス設計

    モデル命名 ドメインモデルの命名規則 エラーハンドリング リトライポリシー、オフライン時の挙動 Analyticsログ イベント名の統⼀ 揃えている領域 領域 理由 UI/UX 各OSのガイドラインとユーザー体験を尊重 アーキテクチャ OS毎の推奨(公式サンプル等)が異なる 状態管理 UIフレームワークの設計思想が異なる
  5. なぜクロスプラットフォームを採⽤しなかったのか? ©Tribeau, inc.| 10 Q. React Native や Flutter, KMM

    を採⽤しなかった理由は? A. 既存のネイティブコードベースが⼗分に機能しており、  価値を提供できていたため 技術的な優劣の議論ではなく、「全⾯移⾏コスト」と「得られる メリット」のバランスで考える ※もしこれが新規プロダクトであれば、判断は異なる可能性あり 常に “現状からの変化” にかかる投資対効果で技術選択を考える
  6. マルチプラットフォーム開発でのAI活⽤の現在と実感 ©Tribeau, inc.| 11 Q. AI開発時代におけるマルチプラットフォーム開発は? A. AI開発時代において最終的なアウトプットはどの⾔語、  どのフレームワークかは重要ではない(と思う) ✅

    実践: ‧とにかくAIを導⼊してみて、使い倒してみる ‧⾃分で設計‧実装できないものは、AIにも実装移譲させることはできない ‧仕様‧ドキュメント作成、テストケース作成の効率化 ⚠ 注意: ‧AIの提案をレビューせずマージ  ‧ハルシネーション ‧機能への思い⼊れ、実装する楽しさへの影響
  7. “全部やる” は無理、事業数字に基づく優先順位設定 ©Tribeau, inc.| 12 トリビューでは、iOS → Android → Web

    の優先順位で機能リリースを考えることが多い ユーザーの70%以上がiOSアプリを利⽤している これは “技術的な正しさ” ではなく、 “事業としての正しさ” に基づく判断 リードエンジニアとして: トレードオフを可視化し、ステークホルダーと合意形成
  8. 技術投資を事業⾔語に翻訳し、KPIへの貢献を可視化 ©Tribeau, inc.| 14 ❌. リファクタリングに2週間ください ✅. この改善で今後の機能開発が30%速くなり、 3ヶ⽉で投資回収できる⾒込みです Case

    Study: 宣⾔型UI移⾏ 技術的メリット 事業⾔語への翻訳 コード量削減‧可読性向上 開発速度向上 → Time to Market短縮 状態管理の⼀元化 バグ減少 → クラッシュフリー率改善 プレビュー機能でUIの即時確認 デザイン適⽤⼯数削減 → 開発コスト削減 再利⽤可能なコンポーネント 新機能開発の⾼速化 → 施策実⾏回数増加 “A/BテストのUI差し替えが従来⽐60%(⽬標)の⼯数で可能になり、年間の施策実⾏回数を増やせる”
  9. リードエンジニアへ:意識の転換と実践 ©Tribeau, inc.| 16 エンジニア (現在のトリビューにおける) リードエンジニア ⾃分のコードへ責任を持つ チームのアウトプットに責任を持つ 狭く深く

    広く、必要な領域は深く 実装に時間を使う 設計‧レビュー‧共有‧合意形成に時間を使う エンジニアとしての意識転換 ビジネス視点は、当事者として関わることで⾝につく ❌ 誤解: 経営の書籍や記事を読めば⾝につく ✅ 実践: ‧ 経営会議の議事録を読む ‧セールス、CSと定期的にゆるいコミュニケーションをとる ‧分析チームと連携し、KPIダッシュボードを毎⽇⾒る ‧「なぜこの機能を作るのか」を必ずPdMに聞く
  10. 1. 技術選定は事業判断である  ”最⾼の技術” ではなく “今、最適な技術” を選ぶ 2. トレードオフの可視化が責務  全ては実現できない、選択と集中の根拠を明確にする 3.

    技術投資を事業⾔語で語る  成果を数字で計測し、事業への貢献を説明する 4. ビジネス視点は、当事者として関わることで⾝につく  勉強より実践、現場に⾶び込み背景を理解する 本⽇のまとめ ©Tribeau, inc.| 17