Sansanの技術カンファレンスです。 2トラックのサイレントセッションで、受付時にレシーバーが配られました。 自分はサーバーレスが気になったので、トラック１の方に陣取りました。
https://sansan.connpass.com/event/138134/
14:30-15:00 【オープニング】 CTO 藤倉 成太、VP of Engineering 宍倉 功一
- 社員数550人中、ものづくに理に関わっているのが220名
- Sansanは何を目指しているのか
- 世界中の名刺をすべてデジタル化
- ビジネスパーソンの出会いのデータベース
- この１年の振り返り
- 新規事業への取り組み
- いくつか立ち上げ中
- グローバルへの取り組み
- 海外エンジニアの採用
- 海外展開を見据えて
- 英語だけでも仕事がまわせる環境
- 新規事業への取り組み
- これからの挑戦
- 組織を強くしていく
- 新規事業、事業の加速
- 事業の成果にクリエイターが向き合う
- 成果の出しやすい環境
- 協働・変容
- 研究のネタを議論する
- R&Dが事業をリードする
- 組織を強くしていく
15:10-15:35 「Sansanアーキテクチャ史」荒川 聖悟
sansanは12年間の歴史がある
C#
v1
- WinForms(UI), BLL(busineslogic layer), DAL(DataAccessLayer)
- DALはSQLを手作業で組み立てている
- Pros: とにかくシンプル、画面と業務ロジックの結びつきが明確
- Cons: 画面駆動アーキテクチャになりがち、各レイヤの責務が曖昧
v2
- Service, DomainModel, Repository
- DDDっぽい雰囲気
- ORマッパーを自作した
- リポジトリ層が超肥大化
- 課題
- リポジトリの肥大化によりサービス層の実装が困難に
- 共通化の認識を共通化させることができなかった
- FE固有のロジックが共通されたりしていた
- パフォーマンスが出ない
- クエリが多い＆謎
- 画面駆動からは脱却できた
V3
- UI, App, Domain, Infra
- UI層（WEB, API）にQueryServiceを置く（SELECT文のみ）
- ORマッパーは使わず、SQLを直書きに変更
- シンプルと共通化のバランスが取れている
- 無駄な抽象化は避けている
- 課題
- モジュールの場所や実装の悩み
まとめ
- 時代とともに流行のアーキテクチャは移り変わる
- アーキテクチャの浸透は想像以上に難しい
- プラットフォームとアプリケーションにあったアーキテクチャを選ぶ
15:40-16:05 「Eightのフロントエンド〜改善の歴史と今後の展望〜」青山 修平
- バックエンドはRails
- 2012/2 jQuery UI
- 2013/4 Backbone.js + jQuery UI + CoffeeScript
- 2015/12 React + Redux + ES6
- 課題と改善
- UI
- モノリシックCSS
- 影響範囲がわからず、ちょっとした修正ができなくなる
- →CSSのコンポーネント化で解消
- 影響範囲がわからず、ちょっとした修正ができなくなる
- バラバラなスタイル、コンポーネント
- 同じようなコンポーネントが微妙に違ってあちこちに点在
- →スタイルガイドを作成して改善
- 同じようなコンポーネントが微妙に違ってあちこちに点在
- 新スタイルガイド刷新中
- デザイナを巻き込んですすめる
- モノリシックCSS
- 煩雑な提携コード作成
- OpenAPI(Swagger)採用
- 194個
- →swagger-client, normalizr を利用してコードを生成する
- UI
16:15-16:40 「GCP サーバーレス サービス × 少数チームで新たなデータ化サービスを立ち上げる」木田 悠一郎
- 名刺の高精度なデータ化を支えるノウハウ
- 機械の力と人の力を合わせる
- GCPサーバーレスサービス紹介
- GAE, CFirestore, CTasks, Sd, CStrage, CFunction
- GAE: スケールアウト・デプロイが高速
- FIrestore: NoSQLデータストア、オートスケーリング
- Tasks: 処理を非同期で実行できるタスクキューサービス
- Stackdriver: ロギング、エラー通知、モニタリングで使用
- アーキテクチャ
- 導入の背景
- 運用負荷を下げたい
- マルチクラウドを推進
- チャレンジ
- 本気で使ってみることで、メリデメを理解する
- 導入の背景
- メリット・注意点・課題
- アプリケーションのコードに集中できる
- サーバー管理不要
- コスト最適化
- 限られたリソースでもスピード感を持って開発できる
- GAE環境
- 可能な限りスタンダード環境を使う（フレキシブル環境ではなく）
- AWS環境とVPN接続したいとき
- 特定のライブラリを使いたいとき
- いまはCloudRunで代用できる
- AppEngineファイアウォール
- グローバルサービスがブロックされて住まう
- FirestoreのDB設計
- count関数はない
- 分散カウンタを使う
- 課題
- 開発環境
- Firestore: 1プロジェクトに1DB
- Tasks: ローカルに向けられない
- 動作確認
- HerokuReview
- 分析計クエリ
- エラー通知
- タイムラグ・カスタマイズ
- 開発環境
- Q&A
- AWSとGCPのサーバーレスの違い
- マネージド具合はCGPのほうが心地よい
- GAEの使い勝手が良い
- AWSとGCPのサーバーレスの違い
16:45-17:10 「新規事業の開発メンバーが1人→n人に増えるのを支えた技術」加藤 耕太
- データ不正更新事件
- id:1のデータを編集したあとにid:2を編集すると、意図せずid:1のデータも変更されてしまう
- 3000件を目視確認
- 問題が起きると、調査対応に莫大な工数がかかる
- 安定したインフラで素早く動け（Facebookのモットーより）
- 対策
- コードフォーマッターの導入
- 融通がきかないルールもそのうちなれる
- リポジトリ一括フォーマットはマージのタイムングが難しいので、なるべく初期に導入する
- CIの導入
- Cloud Build
- とりあえずビルドだけでもやっておくと安心
- 静的型付け言語（Kotlin）への移行
- 言語選定条件：GAEスタンダード第2世代のランタイム＆静的型付け言語
- Pythonからの段階的な移行
- コアドメインの機能をKotlin化して切り出し
- BFF部分を徐々に移行
- テストを書きやすい環境づくり
- コントローラーのテストを気軽に書きたい
- テストクラスごとに異なるスキーマに接続して並列実行
- CI環境ではコミットIDごとにスキーマを分ける（並列ビルド対策）
- テストがあると安心してリファクタリングできる
- GAEのデプロイ自動化
- リリース作業に時間がかかる
- トラフィック移行は手動で実行する
- フレキシブル環境を自動デプロイする場合は要注意
- トラフィックを受け取らなくてもデフォルト2インスタンスが起動し続ける
- コードフォーマッターの導入
17:25-17:50 「プロダクトをどう磨いていくか」片芝 亮友
- Eight Carrier Design
- ダイレクトアプローチとリファラル両輪
- 開発するにあたっての悩み
- 自分が想定ユーザーではないので、何がほしいかわからない
- ドメイン（人事部）知識が不可欠
- 意思決定者が多層的で、どう価値が伝わるかわからない
- 顧客によって重みが違う
- シナリオ：価値、ストーリー
- 営業
- シナリオの言語化
- 価値の検証
- 事業進捗ミーティング
- 事業的な優先度
- 現場の閑職
- 提案方法の変化
- 営業
- ユーザビリティ：
- ユーザー会
- 実際の使い方
- 不具合・改善要望
- 顧客の声アーカイブ
- 営業時の違和感
- 顧客からの要望
- 喜びの声
- 自部門採用
- ユースケースの確認
- 不具合・改善箇所の確認
- ユーザー会
- どう整理するか
- プロダクトレビュー
- シナリオの精査
- 施策・改善の優先度判断
- プロダクトレビュー
- まとめ
- ビジネス側へ以下に近づくか：聴く、観る、やってみる
- 定期的なサイクルを作り、習慣化する
- 役割と主導を決め、巻き込む
- プロダクトの洗練と合意形成を両立する
17:55-18:20 「チームづくりから組織づくりへ〜事業成長に立ち向かうEMの戦略と戦術」谷内 真裕
- 背景
- いまは想像以上に挑戦的なフェーズ
- 開発組織の今まで
- 機能ドメイン別チーム体制
- PM, Designer, TL, Engineer
- 機能ドメインの知識理解を深める
- 機能ドメイン担当を明確化
- 事業拡大のスピードに追いつけなくなってきた
- 全体の優先度順に開発できない
- 全体に影響する技術的に意思決定が困難
- 目的別チーム体制
- データドリブン
- 解約率と利用率の相関仮説→利用率（KPI)を追う
- 機能ドメインに関わらず数値を追う
- Engineering ManagerがUnitをマネージする
- 想像以上に複雑で強大なものと戦うことに
- 利用率の分解が困難で手応えを感じられず
- 顧客の担当者を巻き込む戦いと言える
- EMとはなんだろう
- 多すぎる変数（技術・組織・人）
- 雲を掴むような日々
- 機能ドメイン別チーム体制
- 開発組織のこれから
- 10倍にスケールする組織へ
- 慣れ親しんだやり方を捨て、変化を恐れず挑戦していく
- 体制の再構築
- 開発グループをプロダクトの粒度に
- 開発チームはエンジニアだけで構成
- PM&Designersは開発グループをまたいで連携
- 開発プロセスの再構築
- バックログメンテ（PM）
- プロダクトマネジメント
- プロダクトバックログ一本化
- 短期・中期・長期目線でプロダクトを育てる
- バックログアイテムをシャープにする
- ソリューションレビューを通ってから開発着手
- PdMはプロダクトに与える価値に責任を持つ
- プロジェクトマネジメント
- プロジェクトマネジメントの対象となるルールを決める
- 小さなものや機能改善は対象外にする
- PdMはプロジェクトマネジメントもする
- プロジェクトマネジメントの対象となるルールを決める
- 組織マネジメント
- 組織デザイングループの立ち上げ
- 組織戦略を立て、戦術の実行と調整を行う部門内人事
- 部内の育成・評価・環境・採用
- 育成・評価
- キャリアマネージャー制度
- チーム横断で担当がつく
- 育成の主担当を明確化
- キャリアマネージャー制度
- 組織デザイングループの立ち上げ
- 数字に向き合う
- プロダクト
- APM, NPS, データ分析基盤
- 組織
- 部で育成。評価制度を作り、数字での運用を試みる
- 部で背採用計画を建てる
- プロダクト
- 10倍にスケールする組織へ
- 事業と組織の成長に立ち向かうために
- リーダーとメンバーの心理的柔軟性
- Unlearn（学びほぐし）
- 心理的柔軟性が ちーmの成果を後押しする
- 思考と間表を分けて受け入れる
- 今にフォーカスする
- リーダーとメンバーの心理的柔軟性
- この組織、故障かな？とおもったら
- 群盲象を評す
- 責任が異なるので見え方と関心が番うだけ
- 知ろうとする行動自体が組織を良くする
- ハンロンの剃刀
- 意図せず伝わっていないことがほとんど
- 伝達ができていないだけ
- 群盲象を評す
- 学んだこと
- 自分とうまく付き合う
- 最大の関心事は人それぞれ
- 一人で頑張ってはいけない
18:30-18:55 【クロージング】 「明日の当たり前を作る」CPO 大津 裕史
- 消費者に、何がほしいかを聞いてそれを与えるだけではいけない 完成する頃には、彼らは新しいものを欲しがる（Steve Jobs）
- 顧客の要望の先を作る
- 明日の当たり前を作る
- 2種類のワクワク
- どこでもドア
- 強烈で分かりやすい
- 明日が遠い
- ショートカットキー
- 適度でわかる人にはわかる
- 明日が近い
- どこでもドア
19:00-20:30 【懇親会】 Builders Night
感想
- 合意形成、役割間の連携が大事である
- お互いに同じ方向を向いて、決めながらすすめる