KMP導⼊において、マネジャーとして考えた事

■ イベント
食べログ x ANDPAD x Sansan モバイル勉強会 #3
https://andpad.connpass.com/event/350366/

■ 発表者
技術本部 Sansan Engineering Unit Mobile Applicationグループ
赤城 史哉

■ iOS エンジニア 採用情報
https://media.sansan-engineering.com/ios-engineer

■ Android エンジニア 採用情報
https://media.sansan-engineering.com/android-engineer

Transcript

1. KMP導⼊において、 マネジャーとして考えた事 Sansan株式会社 技術本部 Sanan Engineering Unit Mobile Application Group ⾚城 史哉
2. ⾚城 史哉(Fumiya Akagi) Sansan株式会社 技術本部 Sansan Engineering Unit/Mobile Application Group 前職ではAndroidアプリの受託開発に従事。 2019年にSansanに中途⼊社し、Sansan Androidアプリの開発・ 運⽤を担当。 直近数年は、Sansan Mobileアプリ開発チームのマネジメントを ⾏っている。 X: @ginyolith_tech
3. 会社紹介 Company Profile
4. © Sansan, Inc. Sansan株式会社 会社概要 「Sansan」に込めた想い “San”（〜さん）は、英語の“Mr.”や“Ms.”にあたる 「⼈」を象徴する⾔葉です。 Sansanは、⼈と⼈、そして出会いを表します。 “世界を変える出会い”を⽣み出したい。 ⾚いラインには、そんな想いがこめられています。 Sansan Bill One Contract One Eight 主な提供サービス 2007年6⽉11⽇ 71億30百万円（2025年2⽉28⽇時点） Sansan神⼭ラボ Sansan Innovation Lab Sansan⻑岡ラボ Sansan Global Pte. Ltd. （シンガポール） Sansan Global Development Center, Inc. （フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ） ログミー株式会社 株式会社ダイヤモンド企業情報編集社 クリエイティブサーベイ株式会社 株式会社⾔語理解研究所 設⽴ 資本⾦ 本社 関⻄⽀店 福岡⽀店 中部⽀店 拠点 サテライト オフィス グループ会社 東京証券取引所 プライム市場 上場証券取引所 働き⽅を変えるDXサービスの企画・開発・販売 事業 寺⽥親弘 代表者
5. © Sansan, Inc. 出会いから イノベーションを⽣み出す いつの時代も、世界を動かしてきたのは出会いです。 ⼈と⼈、企業と企業、 その出会いの連鎖が社会を前進させます。 私たちは出会いが持つ可能性を再発⾒し、 未来につなげることでビジネスを変えていきます。 イノベーションにつながる新しい出会いを⽣み出す。 出会いの⼒でビジネスの課題にイノベーションを起こす。 そして、ビジネスの出会い、そのもののあり⽅を変えていきます。 Mission 会社概要
6. 働き⽅を変えるDXサービス サービス Sansanは、名刺というアナログ情報をデジタル化して データとして活⽤できるようにすることで、 企業の課題解決を⽀援してきました。 これからは、名刺管理という分野に限らず、 営業、経理、契約といった より幅広い領域でサービスを展開していくことで、 DXを推進し、働き⽅を変えていきます。 Sansanの働き⽅を変えるDXサービスが、 企業とビジネスパーソンの課題解決を後押しします。
7. 働き⽅を変えるDXサービス サービス 請求 ⼈や企業との出会いをビジネスチャンスにつなげる「働き⽅を変えるDXサービス」を提供 ビジネスフローにおけるさまざまな分野でサービスを展開 営業 営業DX 契約 契約DX 経理DX 法⼈向けDX 必要な情報を すぐに⾒つけられる 情報の管理がしやすく すぐに共有できる 情報を分析・活⽤しやすく データに基づいた判断ができる SansanのDXサービスの活⽤で変わる働き⽅ 名刺管理 名刺DX 個⼈向けDX
8. 名刺管理から、収益を最⼤化する 営業DXサービス「Sansan」 Sansanは、名刺や企業情報、営業履歴を ⼀元管理して全社で共有できるようにすること で、 売上拡⼤とコスト削減を同時に実現する 営業DXサービスです。 サービス ｜ Sansan
9. Kotlin Multiplatform 導⼊の概要
10. - 2023年10⽉: ⽣産性向上を⽬的とした、KMP導⼊の検討開始 - 2023年11⽉: KMP導⼊の決定 - 2023年12⽉〜2024年4⽉: 基盤開発および設計 - 2024年4⽉〜5⽉: トレーニング期間 - 2024年6⽉: プロダクション環境での開発開始 - 2024年8⽉: KMPを使⽤した機能が初リリース - 2025年3⽉: Polyrepo構成からMonorepo構成に移⾏ Kotlin Multiplatform導⼊のタイムライン
11. - SansanアプリにおけるKotlin Multiplatform導⼊の効果と アーキテクチャ紹介 - Sansan Mobile iOS/Androidエンジニア全13名でKotlin Multiplatform導⼊ に向けた開発演習を実施しました - 【Sansan Tech Talk】モバイル開発の技術的挑戦 〜KMP導⼊で⽬指す開 発⽣産性の向上〜 SansanのKMP導⼊に関するTech Blog
12. SansanのKMP導⼊に関する過去登壇資料
13. - 2023年10⽉: ⽣産性向上を⽬的とした、KMP導⼊の検討開始 - 2023年11⽉: KMP導⼊の決定 - 2023年12⽉〜2024年4⽉: 基盤開発および設計 - 2024年4⽉〜5⽉: トレーニング期間 - 2024年6⽉: プロダクション環境での開発開始 - 2024年8⽉: KMPを使⽤した機能が初リリース - 2025年3⽉: Polyrepo構成からMonorepo構成に移⾏ 今⽇話す内容
14. KMP導⼊において、 マネジャーとして考えた事
15. フレームワーク導⼊のような⼤きな技術の変化の際 皆さんはどのような事を考えますか？
16. すぐに思い浮かぶこと - 公式ドキュメントや書籍を読み込んで、 これから本格導⼊する技術の使い⽅をキャッチアップする？ - 同じような技術を採⽤している他社の事例をリサーチする？ - 有識者に教えてもらう？
17. マネジャーとして考えた事は...
18. 「マネジャー4つの役割」 を満たすために リスクを最⼩化し リターンを最⼤にする
19. そもそもマネジメントとは？
20. マネジメントの役割（ドラッカー） 1. ⾃らの組織に特有の使命を果たす。 マネジメントは、組織に特有の使命、すなわちそれぞれの⽬的を果たすために存在する。 2. 仕事を通じて働く⼈たちを⽣かす。 現代社会においては、組織こそ、⼀⼈ひとりの⼈間にとって、⽣計の資、社会的な地位、コミュニティ との絆を⼿にし、⾃⼰実現を図る⼿段である。当然、働く⼈を⽣かすことが重要な意味を持つ。 3. ⾃らが社会に与える影響を処理するとともに、社会の問題について貢献 する。 マネジメントには、⾃らの組織が社会に与える影響を処理するとともに、社会の問題の解決に貢献する 役割がある。 出典: Ｐ Ｆ ドラッカー. マネジメント［エッセンシャル版］
21. ミドルマネジャー寄りに捉え直す
22. マネジャー4つの役割 1. 経営からオーダーされた成果を残す 2. ⼈的資産を維持・活⽤する 3. ⼈を育てる 4. 会社の中でチームを機能させる 出典: ⻑村 禎庸. 急成⻑を導くマネージャーの型
23. Kotlin Multiplatformを リスク/リターンで捉え直してみる
24. （⼀般的な）KMP導⼊のリターン/リスク リターン（期待される効果） - iOS/Android間の共通ロジックを書くコストが 1/2 に - iOS/Android間の仕様差異が無くなり、品質が向上 リスク（想定された問題） - iOSエンジニアのKotlin学習コスト - エコシステムが成⻑過程であり、モジュールの再実装の必要性 - 導⼊事例・情報が少なさ
25. 本当にこれだけか？ 組織観点の 潜在的なリスク・リターンもあるのでは
26. 組織・⼈の観点に着⽬して 考え直してみる
27. KMP導⼊のリターン/リスク（組織観点） リターン（期待される効果） - 採⽤広報での訴求⼒向上（モダン技術への挑戦） - エンジニアの成⻑機会の創出（新技術の習得） - iOS/Android エンジニア間のナレッジ共有 リスク（想定された問題） - 知⾒の属⼈化（特定メンバーへの集中） - ボトルネック化（KMP担当者に負荷集中） - 技術選定の背景が⾵化し、陳腐化時に対応困難 - 学習不⾜で導⼊後に⾼いキャッチアップコストが発⽣
28. リスクを未然に防ぎ、 最⼤のリターンを得るためには？
29. リターンの損失 / リスクの顕在化 シナリオを考える 1. 導⼊準備が⻑引く中で、熱が冷めていく 2. ⾃然に偏りが⽣まれ、挑戦と共有の場が閉じていく 3. 設計と技術選定の背景が失われ、“柔軟に⼿を加えられない状態”に
30. 悪いシナリオを避けるために マネジャーの権限・役割を活かす
31. シナリオ① 導⼊準備が⻑引く中で、熱が冷めていく 最初は「これで開発効率が上がる」「採⽤広報にも効く」と期待されていた が、準備期間が⻑期化。 試験導⼊のフェーズで⾜踏みが続き、「KMPって結局いつ使うの？」 という空気がチーム内に広がる。 得られるはずだったリターン（学習機会、ナレッジ拡張、採⽤訴求）は少し ずつフェードアウトしていった。
32. リターンの損失 / リスクの顕在化 シナリオ を防ぐために 1. 導⼊準備が⻑引く中で、熱が冷めていく a. OKRとして組織の重要⽬標に位置付け、開発リソースの投下を⾏う 2. ⾃然に偏りが⽣まれ、挑戦と共有の場が閉じていく 3. 設計と技術選定の背景が失われ、“柔軟に⼿を加えられない状態”に
33. OKRの威⼒ 1. 優先事項を決め、有限なリソースを今注⼒すべき事に フォーカスさせる事で、成果を最⼤化させる 2. 事業⽬標・隣接組織・上位組織と⼀定同じ⽅向性の⽬標を設定する事 で、部署間での連携を⽣む 3. ⽬標に対しての進捗をトラッキングする事で、 責任を明確にし推進させる 4. 組織としてコンフォートゾーンを抜け出し、120%の成果を出す。その事 により、コンフォートゾーンにとどまっている競合を追い抜き、突き放 す 出典: ジョン・ドーア; ラリー・ペイジ. Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功⼿法 OKR (⽇本経済新聞出版)
34. OKRの威⼒ 1. 優先事項を決め、有限なリソースを今注⼒すべき事に フォーカスさせる事で、成果を最⼤化させる 2. 事業⽬標・隣接組織・上位組織と⼀定同じ⽅向性の⽬標を設定する事 で、部署間での連携を⽣む 3. ⽬標に対しての進捗をトラッキングする事で、 責任を明確にし推進させる 4. 組織としてコンフォートゾーンを抜け出し、120%の成果を出す。その事 により、コンフォートゾーンにとどまっている競合を追い抜き、突き放 す 出典: ジョン・ドーア; ラリー・ペイジ. Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功⼿法 OKR (⽇本経済新聞出版)
35. - KMP導⼊のプロジェクトチームを発⾜ - 期限を３ヶ⽉後に設定し、コミットメントを⽬指すと宣⾔ - できる限りSMARTなKRを設定する。具体的にする。 - 「KMPを導⼊する」ではなく「プロダクションに導⼊可能な状態にする」 組織としてフォーカスを定め、進捗を推進する
36. 組織としてフォーカスを定め、進捗を推進する - 期限を3ヶ⽉後までに設定し、 KMPを導⼊した改修案件をリリースすると宣⾔ - 毎週進捗を確認する
37. シナリオ② ⾃然に偏りが⽣まれ、挑戦と共有の場が閉じていく PoCや導⼊初期に関わったメンバー、そしてKotlinに慣れたAndroidエンジニアが、 ⾃然とKMPの実装やレビューを担うようになっていった。 「詳しい⼈に任せた⽅が早い」「KotlinならAndroidメンバーで」という判断が積み重なり、 気づけばKMPは⼀部の⼈の専⾨領域になっていた。 iOSエンジニアや他メンバーは関わる機会を失い、挑戦もナレッジ共有も、静かに⽌まって いく。 本来、全員で育てるはずだった技術が、属⼈化とボトルネックを内包した仕組みへと変わっ ていった。
38. 1. 導⼊準備が⻑引く中で、熱が冷めていく a. OKRとして組織の重要⽬標に位置付け、開発リソースの投下を⾏う 2. ⾃然に偏りが⽣まれ、挑戦と共有の場が閉じていく a. チーム再編成やトレーニングにより、当たり前をアップデートする 3. 設計と技術選定の背景が失われ、“柔軟に⼿を加えられない状態”に リターンの損失 / リスクの顕在化 シナリオ を防ぐために
39. ⽬指す「当たり前」を具体的にイメージする To-Be - モバイルエンジニアは、それぞれに軸⾜を置くOSがありつつも、 当たり前にiOS/Android/KMP のコードを読み・開発できる
40. As-Is - 各OS担当のエンジニアはそれぞ れのOSのみが関⼼毎となってい る - 他OSの仕様について分からない 事があったら、 他OS担当のエンジニアに聞く ⽬指す「当たり前」を具体的にイメージする To-Be - モバイルエンジニアは、それぞれ に軸⾜を置くOSがありつつも、 当たり前にiOS/Android/KMP の コードを読み・開発できる
41. As-Is - 各OS担当のエンジニアはそれぞれの OSのみが関⼼毎となっている - 他OSの仕様について分からない事が あったら、 他OS担当のエンジニアに聞く To-Beとのギャップを考える To-Be - モバイルエンジニアは、それぞれ に軸⾜を置くOSがありつつも、 当たり前にiOS/Android/KMP の コードを読み・開発できる ギャップ - KMPの開発スキルと⾃信の獲得 - iOS/Android/KMP のコードを読み・開発する機会
42. KMPの開発スキルと⾃信 の獲得
43. KMP キャッチアップを実施
44. KMP キャッチアップを実施（個別のキャッチアップ） - キャッチアップPJを⽴ち上げ クリアに⽬標を⾔語化 - マネージャー含め、Mobile App メンバー全員でキャッチアップを 実施 - Featureの開発に⽀障が出ない範囲 で、キャッチアップ⼯数を確保して 実施をお願いした。
45. KMP キャッチアップを実施（開発演習） - オフラインでのキャッチアップ会を実施 - 「Kotlin Multiplatformを使って仕事として開 発していく事に、⾃信を持っている状態と なる。」を⽬指した。 - 擬似的なPBIを書き、 2⽇間での開発を実施 - “進捗感” を全員で共有し、KMPを プロダクションに導⼊できる⾃信を チーム全員で得た
46. iOS/Android/KMP のコードを 読み・開発する機会
47. システム（広義に定義）を設計するあらゆる組織は、 組織のコミュニケーション構造をコピーした 構造を持つ設計を⽣み出す。 ―メルヴィン・コンウェイ 出典:wikipedia; https://en.wikipedia.org/wiki/Conway's_law
48. ⽬指す組織像から逆算して、チームを設計する Team Topologiesを参考に、 各チームがKMP/iOS/Android全ての開発を責務となるように Before iOS Team Android Team After Product Growth Dev Product Growth Dev Android App iOS App 開発 開発 Mobile App(iOS/Android/KMP) 開発 開発 Architecture Team ⽀援
49. ⽬指す組織像から逆算して、チームを設計する Product Growth Devチーム - 機能開発を⾏う - ≒ ストリームアラインドチーム - チームの裁量で、どのエンジニアが どのOSの開発を⾏ってもOKとした - 設計/コードレビューで品質は引き続き担保 Architecture & OPS チーム - 設計や運⽤観点で統制を取る - Product Growth Devチームの⽀援を⾏う - ≒ プラットフォームチーム、 イネイブリングチーム Product Growth Dev Product Growth Dev Mobile App(iOS/Android/KMP) 開発 開発 Architecture&Ops ⽀援
50. シナリオ③ 設計と技術選定の背景が失われ、“柔軟に⼿を加えられない状態”に 導⼊初期に設計された共通コードやライブラリの選定には、確かに意図やトレードオフの判断があった。 しかし、それらの意思決定は導⼊メンバーの頭の中だけにあり、記録や共有が不⼗分だった。 時が経ち、KMPコードをメンテナンスするメンバーが変わったとき、 「なぜこの構造なのか？」「このライブラリを選んだ背景は？」 といった疑問があちこちで⽴ち上がる。 背景が⾒えない設計には⼿が加えづらくなり、必要な⾒直しが進まない。 変えたくても理由がわからず⽌まってしまう── そんな“静かな詰まり”が、少しずつ積み重なっていく。
51. 1. 導⼊準備が⻑引く中で、熱が冷めていく a. OKRとして組織の重要⽬標に位置付け、開発リソースの投下を⾏う 2. ⾃然に偏りが⽣まれ、挑戦と共有の場が閉じていく a. チーム再編成やトレーニングにより、当たり前をアップデートする 3. 設計と技術選定の背景が失われ、“柔軟に⼿を加えられない状態”に a. ADRを導⼊し、意思決定の記録を残す リターンの損失 / リスクの顕在化 シナリオ を防ぐために
52. テキストベースの軽量なテンプレートを使⽤して、 アーキテクチャ上の設計判断を記録する。 軽量なアーキテクチャデシジョンレコード（Architecture Decision Records: ADR)は、実績のあるアーキテクチャ⼿法に対する開発者よりのアプローチだ。 設計判断を記録していく事で、それらを共有し分析することが容易になる。 意思決定の履歴を残すことで、現在のアーキテクチャについての コンテキストを、その過程と結びつけて提供できる ADRとは ※書籍「Design It!」（O'Reilly）より引用
53. - KMP導⼊に関するものだけで、 約50個のADRが作成された - 設計判断の質とスピードを⾼めることが 出来た。 - 重要ではない設計判断については、あえ てスピード重視で決めることも出来た - 2025新卒メンバーが学習材料として 輪読会を実施。 設計の意図が引き継がれている ADRを導⼊し、意思決定の記録を残す
54. まとめ - マネジャーは「経営から求められる成果」を実現するために、 技術選定も⼿段として考える - 技術を選ぶだけでなく、 選んだ技術で成果を出すためにどう動くかが重要 - 選定時は「リスクとリターン」「組織への影響」「最悪のシナリオ」を 考えると、具体的な打ち⼿が⾒えてくる
55. ▪ 書籍・出版物 - マシュー・スケルトン、マニュエル・パイス（2021）『チームトポロジー：チームトポロジー 価値あ るソフトウェアをすばやく届ける適応型組織設計』⽇本能率協会マネジメントセンター - ⻑村 禎庸（2021）『急成⻑を導くマネージャーの型』技術評論社 - ジョン・ドーア（著）、ラリー・ペイジ（序⽂）（2018）『Measure What Matters：伝説のベンチャ ー投資家がGoogleに教えた成功⼿法 OKR』⽇本経済新聞出版 - P.F.ドラッカー（2001）『マネジメント［エッセンシャル版］』ダイヤモンド社 - マイケル・キーナン（原著）『Design It! ソフトウェアアーキテクトのための問題解決ガイド』オライ リー・ジャパン ▪ ウェブ・オンライン情報 - Wikipedia contributors. (n.d.). Conway's law. Wikipedia. https://en.wikipedia.org/wiki/Conway%27s_law 参考資料 References