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

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

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.
Avatar for Yuki Shiho Yuki Shiho
January 16, 2026

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

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