モバイルアプリを含む法⼈向けサービスの開発体制や開発⼿法について / Mobile application development at corporate services such as Sansan

■イベント
公立はこだて未来大学での講演

■登壇概要
タイトル：
モバイルアプリを含む法⼈向けサービスの開発体制や開発⼿法について

登壇者：
Sansan事業部 プロダクト開発部 栗⼭ 徹

▼Sansan Builders Box
https://buildersbox.corp-sansan.com/

Transcript

1. モバイルアプリを含む法⼈向けサービ スの開発体制や開発⼿法について Sansan株式会社 Sansan事業部 プロダクト開発部 栗⼭ 徹 1
2. 2 栗⼭ 徹 (Toru Kuriyama) 公⽴はこだて未来⼤学 情報アーキテクチャ学科卒 (2004年⼊学) 北海道出⾝ 卒業研究は松原研究室、学部1・2年時の担任は三上先⽣ iOS / Android / Rust / ⾃作OS / CTF @kotetu Sansan株式会社 Sansan事業部 プロダクト開発部 iOS アプリケーション開発チーム Lead Engineer kotetuco
3. iOSDC 2019に登壇しました！ 3 YouTube https://youtu.be/eIzqemp6DCo
4. - 栗⼭ (iOSアプリエンジニア) から⾒たSansan事業におけるモバイルアプ リケーション開発について、俯瞰的に話をします。 - モバイルアプリケーションの役割 - 開発組織 - モバイルアプリ開発の特徴 - ⽇々取り組んでいる課題 - 技術的な話だけでなく、ビジネスやマネジメント観点の話も含みます 本⽇のテーマ 4
5. 組織構成 法⼈向け名刺管理サービス Sansanの開発、提供 個⼈向け名刺アプリサービス Eightの開発、提供 R&D データ分析・研究開発 （画像処理／機械学習・AI） Sansan事業部 Eight事業部 DSOC Sansan株式会社 データ統括部⾨ 5
6. 組織構成 個⼈向け名刺アプリサービス Eightの開発、提供 R&D データ分析・研究開発 （画像処理／機械学習・AI） Eight事業部 DSOC Sansan株式会社 データ統括部⾨ 6 法⼈向け名刺管理サービス Sansanの開発、提供 Sansan事業部
7. - 1社⽬ (6年くらい) - 受託開発 (某⼤⼿SIerの受託開発がメイン) > Windows / Androidメイン、たまにiOSやLinux上で動くJavaアプリ > 社内Windows Serverの管理 - 2社⽬ (Sansan、3年半ちょっと) - ⼤部分をiOSアプリエンジニアとして過ごす - ⼀時的にAndroid開発も担当 これまでの仕事遍歴 7
8. - ⼊社当初はEight事業部に所属 - 3ヶ⽉後にSansan事業部へ - 特命でR&Dへ2ヶ⽉間出向していたことも - 1年半後にiOS開発を主管することに (採⽤の仕事も任されはじめる) - 3年⽬(今年)からLead Engineer (LE) に - LEとは - チームリーダー的な役割 (開発 + 進捗管理, メンバーアサイン) - QCD (Quality Cost Delivery)に責任を持つ⽴場 Sansanでの仕事遍歴 8
9. 1. Sansanのビジネスモデル 2. Sansan事業とモバイルアプリ 3. Sansanモバイルアプリ開発体制 4. モバイルアプリ技術の話 5. モバイルアプリチームの取り組み 6. まとめ Agenda 9
10. 1. Sansanのビジネスモデル 10
11. - 法⼈向けクラウド名刺管理サービス - 当社の営業を通じて法⼈ユーザーと利⽤契約を結ぶ - サブスクリプション型ビジネスモデル - 利⽤料をお⽀払いいただくことで利⽤できる - 新規契約数を増やすこと、解約数を減らす(出来るだけ⻑期でご利⽤いた だく)ことが重要 Sansan事業のビジネスモデル 11
12. - ユーザーが必要とする機能を追加する - 競合他社より機能⾯や契約⾯で優位である - ユーザーの課題にフィットするような使い⽅を提案できる - 既存顧客の顧客満⾜度を上げる - ⼝コミ効果が期待できる 「新規契約数を増やす」ために 12
13. - 利⽤率を向上させる - 使われなければ投資効果がない(とユーザーが思う) - 導⼊⽀援を⾏うことも有効 - 顧客満⾜度を上げる - 機能の信頼性向上 (バグを減らす) - ユーザーが必要とする機能を追加する 「解約数を減らす」ために 13
14. - プロダクトの改善に活かすために追っている各種指標 - 利⽤率 - DAU (Daily Active User) - 顧客満⾜度 - NPS® (Net Promoter Score) SansanのKPI (Key Performance Indicator) 14 「NPS®をプロダクト改善に活かす」から引⽤ https://buildersbox.corp-sansan.com/entry/2019/08/06/113748
15. - 営業・エグゼクティブ層 (役員など) - Sansanの主要ユーザ層 - 名刺交換や名刺を活⽤する機会が圧倒的に多い - 情報システム部⾨ (システム管理者) - Sansanを含めた社内システムの管理者 - 上記以外の職種 (⼈事やエンジニアなど) - ⼈脈の管理など ユーザー企業の主要なステークホルダー 15
16. 2. Sansan事業とモバイルアプリ 16
17. - 主な機能 - 名刺管理 - スマホのカメラを使って名刺登録 - 登録した名刺に関連する企業のニュースを確認 - 商談メモや議事録 (コンタクト機能) - 社内チャット Sansanスマホアプリ (iOS / Android) 17
18. Sansanスマホアプリの歴史 18
19. Sansanスマホアプリの歴史 19 ・v3.0での全⾯リニューアルの成果が出てきた ・⼤⼿顧客のスマホアプリ利⽤が進展 ・利⽤率がWebアプリと拮抗するほどに
20. - 営業さんなどが商談の前に外出先で名刺情報やニュースを確認 - 展⽰会や社外打ち合わせで交換した名刺情報をその場で登録 - 移動中に営業先のニュースを確認する Sansanスマホアプリの利⽤シーン 20
21. - 新コンセプトをさらに体現していく - スマホアプリならではの機能の訴求 - 位置情報など - システム管理者のことを考える - 社員に社有スマホをもっと活⽤してほしいがセキュリティも⼤事 - 端末の利⽤を制限したい (アクセスするIPアドレスやログイン保持期間の制限) - 社内で使っている認証システム(Active Directoryなど)との連携 プロダクトとしてのSansanスマホアプリの課題 21
22. 3. Sansanモバイルアプリ開発体制 22
23. - 総勢100名以上 - プロダクトマネージャー (PM) - デザイナー - エンジニア(Web, モバイル, インフラ) - 展開中のプロダクト - Webアプリ - スキャナアプリ - スマホアプリ (iOS / Android) Sansan事業部プロダクト開発部 23
24. - PM 1名 - デザイナー 2名 - エンジニア - iOS 5名 (3名, 2名のチーム) - Android 6名 (3名, 3名のチーム) - サーバーサイド (スマホアプリ⽤Web API) 3名 Sansanスマホアプリ開発チーム 24
25. メンバーの役割 25
26. - プロダクトバックログを使って部全体の開発状況や優先度を管理 - 各チームではなく部全体で持つ - 部署外にも公開 (部署外の⼈でも開発状況を把握できる) - エンジニアによる開発着⼿前にバックログで開発する内容やスケジュール のレビューを⾏う プロダクトバックログ (バックログ) 26
27. プロダクト開発の流れ 27
28. プロダクト開発の流れ 28 ・PM, デザイナーが担当 ・要件定義 〜 基本設計まで ・バックログの優先度判断も⾏う
29. プロダクト開発の流れ 29 ・エンジニア, デザイナーが担当 ・詳細設計 〜 テスト・レビューまで
30. - 各プラットフォーム毎にLead Engineer (LE), メンバー(1〜2名)から構成 - バックログのアサインチーム決定後にチームとしての開発活動開始 - 担当者を決定し、詳細設計と⾒積もりを⾏った上で実装をはじめる - iOS担当者 / Android担当者 / サーバサイド担当者間で仕様調整しながら 進める - iOS / Androidでの仕様差異は極⼒減らす 開発チーム 30
31. 1. ストア審査 2. サポートするOSバージョン 3. User Interface (UI) 4. マルチプラットフォーム対応 開発スケジュールに影響するモバイルアプリ特有の要素 31
32. - モバイルアプリをリリースためにはストアで所定の⼿続きが必要 - 開発終了後、即リリースとはならない - App Store (iOSのアプリストア) でアプリをリリースするためにはストア 審査が必要 - App Store (iOSのアプリストア) の審査期間は1〜2⽇ - Google Play (Androidのアプリストア) でもついにストア審査が開始 - 審査に落ちたら再審査が必要 (複数回落ちることも) 1. ストア審査 32
33. - ストア審査をスケジュールに折り込む - スケジュールにストア審査⽤のバッファを⼊れる - (関係者間での合意のもとで)ストア審査に出すまでを開発側の責任範囲にする - アプリストアの規約変更が無いか⼩まめにチェックする - 新OSリリースなど、⼤きなイベントの前後で変わることが多い - アプリに関する規約やガイドラインは極⼒遵守する - ⾮推奨となったAPIは使わない ストア審査に対応するためのポイント 33
34. - 最新のOSバージョンがリリースされたら対応しなければならない - 最新OSの対応はバックログに載せやすい - 古いOSバージョンのサポートは簡単には切れない - プロダクト的にはアプリを触る機会を増やす意味で古いOSのサポートを切る メリットが無いため - 古いOSバージョンをサポートし続けることによる弊害 - 最新OSでなければ使えない技術が存在する - テスト⼯数が膨らむ 2. サポートするOSバージョン 34
35. - 特定のOSバージョンでしか発⽣しない不具合がありうる - 表⽰崩れや最悪の場合クラッシュすることも - サポートOSバージョンで⼀通りテストを⾏う - Sansan iOSアプリの場合 - 9⽉中旬まで：iOS10, iOS11, iOS12 - 9⽉中旬以降：iOS10, iOS11, iOS12, iOS13 - 1OSバージョンにつきテスト⼯数5⽇の場合、単純計算で15⽇ → 20⽇に 参考) モバイルアプリのテスト 35
36. - プロダクトの性質を踏まえ、事業部全体を巻き込む - OSバージョンごとのアプリの利⽤⽐率を⾒て判断する - サポートを終了可能な⽐率の閾値について合意をとる - ⼗分な猶予期間を設ける - Sansanの場合は最低半年以上の期間を設定 - 法⼈向けサービスの場合は社有スマホユーザを考慮する - 社有スマホは特定機種の⼀括購⼊ - サポートを切ることで社有スマホの買い替えが必要になるケースもある 古いOSバージョンのサポートを終了するために 36
37. - iOS, Android 共に、UIデザインのガイドラインがある - iOS : Human Interface Guidelines - Android : Material Design - なぜUIデザインガイドラインがあるのか？ - ストアアプリ間でUIの統⼀感が無いとユーザーにとって使い勝⼿が悪い - プラットフォーム(Apple, Google)にとってもデメリット - 時にはUIガイドラインの「型」をあえて外すようなデザインにすることも - メジャーなアプリで「型」から外れたUIのアプリは割とある 3. User Interface (UI) 37
38. - 実装⼯数が膨らむ - UI関連のAPIは通常、ガイドライン通りに実装した場合に最も楽になるように 作られている - 技術的負債につながる - 特に実装的に無理している箇所だと新しいOSバージョンでは急に動かなくな るケースも UIのガイドラインに沿わないUIを実装した場合 38
39. - UIガイドラインに対する正しい知識を持つ (エンジニア・デザイナー双⽅) - ガイドラインにはないUIが提⽰された場合 - 実現⽅式を検討する - ⼯数や実装難易度・メンテナンス性を考慮した上で場合によっては必要か どうか交渉する - UIガイドラインから逸脱するからと⾔って何でも突っぱねるのは良くない - ただしやる場合はピンポイントでやる UIに関するデザイナーとの調整での注意点 39
40. - iOS / Android 両対応しているモバイルアプリが多い - 両プラットフォームに対応するための組織体制を考える必要がある - 両プラットフォームのシェアは⽇本とグローバルで異なる - 必要な開発⼈員が変わってくる - モバイルアプリエンジニアは転職市場で枯渇状態 - 開発⼈員が不⾜する場合も - そもそも⼗分な開発⼈員を確保できる会社の⽅が少ないかも 4. マルチプラットフォーム対応 40
41. - AndroidとiOSが拮抗(若⼲Androidの⽅が多い) 参考) ⽇本市場のシェア 41 ドコモ「ケータイ社会⽩書2019年版」から引⽤ http://www.moba-ken.jp/whitepaper/wp19.html
42. - Androidが圧倒的に強い 参考) ⽇本以外のグローバル市場のシェア 42 IDC Media Center「スマートフォンの課題は2019年も続くが、2020年には5Gおよび新興市場によって市場成⻑率が持ち直す⾒通し」から引⽤ https://www.idc.com/getdoc.jsp?containerId=prJPJ45549419
43. - Flutter, React Native, Xamarinなど - 同じコードでマルチプラットフォーム対応アプリを開発できる - メリットはあるものの、将来のプロダクト展開を⾒据えた⾒極めが重要 - クロスプラットフォーム開発フレームワークが向く場合 - プラットフォームに依存する機能要件が少ない場合 - iOS / Android両⽅の開発リソースを確保できない場合 クロスプラットフォーム開発⽤フレームワーク 43
44. - ストアに出して終わり、というわけではない - モバイルアプリのプロダクトを展開する上で、運⽤作業は必須 モバイルアプリと⽇々の運⽤作業 44
45. - クラッシュ数が急増していないかチェック - 特にリリース直後は重要 - ストアの管理 - 紹介⽂やスクリーンショットの更新 - 特にApp Store (iOS)は多い - Push通知⽤の証明書更新 (1年毎に更新が必要) - ストアリリース⽤の証明書更新(1年毎に更新が必要) - Developer Programの更新 - 開発で使うサービスのアカウント管理 主な運⽤作業 45
46. 4. モバイルアプリ技術の話 46
47. - モバイルアプリはクライアント (フロントエンド) - サーバーから受け取ったデータを画⾯に表⽰することがメイン処理 - 必要なデータだけ適宜サーバーからもらう - モバイルアプリ側にいわゆるビジネスロジックは基本的に置かない - それでも少数ながら存在する ⼀般的なモバイルアプリのシステム構成 47
48. - 表⽰(UI)処理 - 通信処理 - (RESTful APIを使う場合は) JSONやXMLのパース処理 - アプリ内キャッシュ - Push通知 - カメラなどの各種センサーを使った処理 モバイルアプリの主な処理 48
49. - メインスレッドはUIの描画を⾏うスレッドとして使われる(UIスレッド) - UIスレッドをブロックしないように気をつけなけばならない - AndroidではUIスレッドを⻑時間ブロックすると警告ダイアログが出る (ANR) - UIスレッド以外で描画処理を⾏うとアプリがクラッシュする - 通信処理や重い処理はメインスレッドとは別スレッドで実⾏する - ⾮同期処理の考慮が必要 - プラットフォーム毎に⾮同期処理⽤フレームワークがある - Reactive Extension系のライブラリ(RxSwift, RxJava)を使うことも多い モバイルアプリとスレッド 49
50. - 不安定な通信状態を必ず考慮する (海外展開するアプリは特に) - 通信切断や通信速度が遅くてもある程度使えるようにする必要がある - 不要なデータをリクエストやレスポンスに載せない - アプリ内でデータをキャッシュすることも有効 不安定な通信との闘い 「グローバル展開のための改善」発表資料から引⽤ https://speakerdeck.com/sansanbuildersbox/just-do-not-english-translation-improvement-for-global-expansion-of-eight 50
51. - ソフトウェアアーキテクチャ(設計パターン) - よく「アーキテクチャ」と略して使われることが多い - アーキテクチャの話はネットを中⼼によく話題になる - 開発の現場で設計について⽇々考えたり悩むことが多いことの現れ - 開発体制やプロダクトの性質により、設計の最適解が変わってくる モバイルアプリの設計 51
52. - チームの⼈数や習熟度 - 複数⼈で同⼀のコードベースを変更するのかどうか？ - 使⽤する設計パターンに対する理解度 - プロダクトのライフサイクル - ⻑期的にメンテナンスしていくのかどうか？ - 頻繁に機能追加するかどうか - 変化に強い作りにする必要があるかどうか？ モバイルアプリの設計で考慮すべきポイント 書籍「iOSアプリ設計パターン⼊⾨」から⼀部引⽤ https://peaks.cc/books/iOS_architecture 52
53. - GUIアーキテクチャ - UIの処理とシステム本来の関⼼ (ドメイン) との間のレイヤー分けを主題にし た設計パターン - システムアーキテクチャ - UI部分だけにとどまらない、システム全体を主題にした設計パターン - 画⾯遷移に関するアーキテクチャ 設計パターンの種類 書籍「iOSアプリ設計パターン⼊⾨」から⼀部引⽤ https://peaks.cc/books/iOS_architecture 53
54. - モバイルアプリはPCに⽐べて画⾯が⼩さい - 1つの画⾯内に表⽰できる情報が限られる - 複数の画⾯を切り替えることにより情報を表⽰する - 画⾯遷移が多数かつ複雑になる - 何も考えずに実装すると保守性が下がる → 設計パターンの必要性 モバイルアプリと画⾯遷移 書籍「iOSアプリ設計パターン⼊⾨」から⼀部引⽤ https://peaks.cc/books/iOS_architecture 54
55. - MVC (Model – View – Controller) - MVP (Model – View – Presenter) - MVVM (Model – View – View Model) - Flux, Redux 主な設計パターン(GUIアーキテクチャ) 55 書籍「iOSアプリ設計パターン⼊⾨」から引⽤ https://peaks.cc/books/iOS_architecture
56. - Layered Architecture - Hexagonal Architecture - Onion Architecture - Clean Architecture 主な設計パターン(システムアーキテクチャ) 56 書籍「iOSアプリ設計パターン⼊⾨」から引⽤ https://peaks.cc/books/iOS_architecture
57. - Coordinatorパターン - Routerパターン - VIPER (iOSで最近使われるようになったパターン) で取り上げられた 主な設計パターン(画⾯遷移に関するアーキテクチャ) 57 書籍「iOSアプリ設計パターン⼊⾨」から引⽤ https://peaks.cc/books/iOS_architecture
58. 5. モバイルアプリチームの取り組み 58
59. - 開発スピードの向上 - 設計の改善 - ⽇常業務の効率化や⾃動化 - 信頼性の向上 - ⾃動テストの充実とQAチームとの連携 - 開発組織の拡⼤への対応 - 振り返りを軸としたチームビルディング活動 - ドキュメントやマニュアル類の充実 モバイルアプリチームが向き合っていること 59
60. - GUIアーキテクチャ：MVC, MVP - システムアーキテクチャ：Layered Architecture (APIなどバックエンド処 理と表⽰処理間の責務を分割) - ビジネスロジックはC(Controller)側で実装するか共通処理クラスで処理 - 共通処理クラスはstaticメソッドが多くテストを書くのが難しかった - CやV(View) にロジックが⼊り込んで肥⼤化したクラスも - 機能追加や変更に弱かった Sansan iOS アプリの設計 (これまで) 60
61. - VIPER (View, Interactor, Presenter, Entity, Router) - GUIアーキテクチャ：MVP (or MVVM) - システムアーキテクチャ：Clean Architecture - 画⾯遷移アーキテクチャ：Router - 画⾯遷移処理をViewからRouterへ集約 - InteractorやEntityを導⼊して具体的なフレームワークに依存しない形に - フレームワークの変更に強くなる - テストを書きやすくする 現在⽬指している設計 61
62. 例) 会社詳細画⾯(MVCアーキテクチャ) 62
63. 例) 会社詳細画⾯(VIPERアーキテクチャ) 63
64. - ストア⽤アプリのビルドを⾃動化 - ヒューマンエラー防⽌の観点からも⾃動化の効果は⼤きい - CI/CD サービスを使う (SansanではBitriseというサービスを使っている) - コードレビューの効率化 - Lint (ソースコード静的解析) の利⽤ - テスト⽤アプリの⾃動配信 - CI/CDでビルドしたテスト⽤アプリをアプリ配信サービスを使って配信 - Firebase App Distribution, DeployGateなど ⽇常業務の効率化や⾃動化 64
65. - ビジネスロジックから順次対応している途上 - ⾃動テスト(テストケースを書くこと) の効能 - リファクタリングする際の品質の担保として機能 - 良い設計のコードはテストが書きやすい - テストを書くことでコードがキレイになる - QAチームによる結合テスト - 少ない開発リソースを効率的に使える - 専任のスタッフがテストすることにより⾼度なバグ検知が可能に ⾃動テストの拡充とQAチームとの連携 65
66. - 定期的振り返りを⾏う - Sansanスマホアプリ開発チームは週1回振り返りを実施 - チームとしての改善施策を⽴てて、次の1週間で実施していく - 振り返りに使うフレームワーク - GKPT (Good Keep Problem Try) - YWT (Y：やったこと W：わかったこと T：次にやること) 振り返りを軸としたチームビルディング活動 66
67. GKPT(の⼀例) 67 タスク管理サービス Trello https://trello.com
68. - ⼈数が増えると効率的な知識の共有が不可⽋ - 状況によってはiOS / Androidで開発着⼿時期がずれることも - 形式知 (ドキュメント) を有効活⽤する - 開発案件着⼿時に仕様をドキュメントに残す - メンバー受け⼊れの増加への対応 - 職種毎(モバイル、サーバーサイドなど)に受け⼊れ⼿順を整備する ドキュメントやマニュアル類の充実 68
69. 6. まとめ 69
70. - ⾃分が関わっているビジネスの姿を知ること - ビジネスや組織規模に応じて常に体制はブラッシュアップされるべき - 法⼈向けサービスはエンドユーザだけでなくシステム管理者などのステークホ ルダーのことも考えないといけない - ⾃分が関わっている組織の姿を知ること - ⼈数や⼈員の傾向によって取るべき施策が変わってくる - モバイルアプリ開発特有の注意事項があること - ストアの存在やモバイル特有の技術課題があることを考慮して開発を進める 今⽇伝えたかったこと 70
71. Qiita Jobs iOSチームの開発の進め⽅や利⽤技術などを より具体的に紹介しています QRコード https://jobs.qiita.com/employers/sansan/development_teams/177 71
72. Sansan Builders Box – 技術サイト https://buildersbox.corp-sansan.com/ Sansanのものづくりを⽀える技術やデザイン、 プロダクトマネジメントの情報を発信する場 72