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