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

つよみをいかして!AndroidエンジニアからEMになる

ussy / @sudo5in5k
September 25, 2024
260

 つよみをいかして!AndroidエンジニアからEMになる

ussy / @sudo5in5k

September 25, 2024
Tweet

Transcript

  1. さまざまなOS・端末・表現方法の考慮が必要 • OS ~15まで (公式のOSもあればメーカー独自にカスタマイズされたOSもある) • 端末 ◦ Androidスマートフォン, タブレット

    ▪ 通常 orフォールダブル ▪ ノッチorノッチレス ▪ 物理キーボードあり or なし ▪ 3ボタンナビゲーションあり or なし ◦ AndroidTV, AndroidCar, Chromebook, Android Watch など ◦ 端末幅・高さの違い ◦ 解像度の違い • 表現方法 ◦ アプリ ◦ Push通知, ショートカット, Widget など 12
  2. カメラ・センサーも多い • カメラ ◦ 全面・背面 (複数) • センサー ◦ 加速度

    ◦ 気温 ◦ ジャイロスコープ ◦ 心拍 ◦ 光 ◦ 近接 ◦ 圧力 ◦ 相対湿度 ◦ など、位置情報・BluetoothやNFCなど日常的に使うものも数多くあります 13
  3. 動かす・魅せる手段も多くある • View Animation • Animator • ViewPropertyAnimator • Dynamic

    Animation • LayoutTransition • Transition • Shared Element Transition (Compose) • 非同期処理時 ◦ スケルトンローディング ◦ placeholder • オンボーディング ◦ ウォークスルー型, ツールチップ型, パーソナライズ型, ダイアログ型 14
  4. よりユーザーにとって使いやすくもできる • ユーザビリティ ◦ アクセシビリティ ◦ Material Designや自社のデザインシステム構築 ◦ UIの情報設計

    ▪ グルーピング, ラベリング, 配置関係のレイアウト, ナビゲーション ◦ ANR/Crashを極力なくす・起動速度改善などによるユーザーペイン解消 • マーケティングの意思決定 ◦ データログの埋め込みとその結果から仮説検証・効果測定・ABテスト などにつなげる • もっと早く価値のあるものをリリースすることへのcommit ◦ 開発プロセス改善 ◦ アーキテクチャ変更 ◦ CI/CDの改善 ◦ 生産性改善 (Four keysなど) 15
  5. 視座を高く 21 CTO, VPoEなど: ROI・プロダクト事業戦略をふまえ、中長期的な エンジニア組織とその組織が使う技術の意思決定を行う EM: エンジニアが属する部署のピープル・プロジェクト・プロダクトやテ クノロジーマネジメントを通じて短期・中期の部署成果を最大化する テックリード・リーダー:

    チーム内の短期・中期の技術的なリードを行う 先頭にたって実装を進めていく、一部チームマネジメントを担う など エンジニア: (リーダーやマネージャーの意図を理解したり・オーダーがく るなどして) 短期のアプリと周辺技術の実装を進めていく ※あくまで目安であり、企業規模や職種の役割によります
  6. 例: KMP (Kotlin Multiplatform) 導入によるビジネスロジック共通化を検討 • 「Android」の視野を持つ「メンバー」の視座からは ◦ (+) 新しい技術がいけてる!

    ◦ (+) DroidKaigiでも取り上げられている! ◦ (+) バージョンが安定版だし信頼性もある! ◦ (+) JetBrains最高! ◦ (+) ロジックが共通化できてよさそう! ◦ (+) Kotlinなので学習コストが低い! など... • しかし、「iOS」の視野を持つ「メンバー」の視座からは ◦ (-) KotlinやGradleの学習コストが高い... ◦ (-) 結局Platform独自で書かなきゃいけないこともあったりするのでは?... ◦ (-) 予約語がありRenameを強いられる... などマイナスな意見もあるかもしれません 26
  7. 例: KMP (Kotlin Multiplatform) 導入によるビジネスロジック共通化を検討 • モバイルエンジニアをマネジメントしている「EM」の視座からは ◦ コスト ▪

    (-) Android, とくにiOSエンジニアの学習コストやリファクタリングコスト ▪ (-) 採用コスト (=要件によっては採用が難しくなるかもしれない) ▪ (+) 仕様差異による手戻りやコミュニケーションコストが削減される ▪ (+) 運用保守の効率化がみこめる ◦ 開発プロセス・組織文化・キャリア形成 など ▪ (-) JetBrains, Kotlinを中長期的に信用できる? ▪ (-) 開発プロセスとして他部署への説明が必要 ▪ (+) リソース効率があがる ▪ (+) エンジニア同士のコミュニケーション・組織組成に寄与 ▪ (+) モバイルエンジニアの新たなキャリア形成の提示 27 など様々な要素を検討しながら中長期的な意思決定する必要があります
  8. 例: ではどうすればいい? 28 • 「Android」の視野を持つ「メンバー」の視座から ◦ iOSメンバー・モバイルのEMという視点に移ったうえでKMPを提案をするなら ◦ コスト面の課題に対して、 ▪

    以前のベロシティをベースにロジック実装が半分になる際のデリバリーを提示 ▪ OS間実装差異やリソース状況により片方が歩留りになっていたときの状況精査をし リソース効率が向上できることを提示 ◦ 開発プロセス・組織文化・キャリア形成に対して、 ▪ 新しい採用要件の提案、そもそもの採用ターゲットを他部署とすり合わせ ▪ KMPのアーキテクチャ・各PFとの接続をどう果たすか設計方針を提示 ▪ 社内勉強会やオンボーディングなどKMPの走り出しを支援する会議体の設定 ▪ 他社のKMP導入状況とメリット・デメリットをみつつデファクトになりそうか調査 などアクションできるとより前向きにKMP導入がなされるかもしれません ※あくまで1例です