"Supporting culture and technology to accelerate" new businesses

■イベント
Developers Summit 2019 KANSAI
https://event.shoeisha.jp/devsumi/20190927

■登壇概要
タイトル：
新規事業を支える文化と加速させる技術～DevOps/GCP/DDD～

登壇者：
新規事業開発室 エンジニアリンググループ グループリーダー
大西 真央

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

Transcript

1. 新規事業を ⽀える⽂化と加速させる技術 ~ devops / GCP / DDD ~ @mmmmao0530
2. ⾃⼰紹介 - 名前 : ⼤⻄ 真央(@mmmmao0530) - 所属 : 新規事業開発室 エンジニアリンググループ 関⻄⽀店勤務 - 社歴 : - Sier - Biglobe : スクラム推進、ドメイン駆動設計導⼊ - Sansan : > Sansanプロダクト Webエンジニア ⼤阪拠点⽴ち上げ > Sansanプロダクト エンジニアリングマネージャー > 新規サービス 開発リーダー 兼 グループリーダー
3. 今⽇話すこと エンジニアの⽴場から 事業⽴ち上げ時に⼤切にしている ポイントを紹介します
4. アジェンダ - チェックイン - ⽂化的な取り組み - ⽂化の⼤切さ - ⽬指すべき⽂化 - ⽬指すべき⽂化に向けて - 技術的な取り組み - ドメイン駆動設計 - GCPサーバレスサービス - まとめ
5. チェックイン
6. 組織体制(エンジニア関連のみ) Sansan事業部 Eight事業部 DSOC CSIRT CxO室 新規事業開発室 約150名のエンジニア 2019年5⽉時点
7. 組織体制(エンジニア関連のみ) Sansan事業部 Eight事業部 DSOC CSIRT CxO室 新規事業開発室 7名のエンジニア 2019年9⽉時点
8. 新規事業開発室の体制と⾃⾝の関わり⽅ 新規事業開発室 Bサービス Aサービス Cサービス 開発リーダー アジャイルコーチ アジャイルコーチ 7名のエンジニア
9. 新規事業開発室の体制と関わり⽅ 新規事業開発室 Bサービス Aサービス Cサービス 開発リーダー アジャイルコーチ アジャイルコーチ メインの話 7名のエンジニア
10. B2Bサービスを開発（社内トライアル中）
11. 体制 エンジニア 3名 × PdM 1名 × 営業 1名 ×
12. ⽂化的な取り組み ~ ⽂化の⼤切さ ~
13. VUCAの時代 • Volatility (不安定で変化が激しい) • Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧)
14. VUCAの時代 • Volatility (不安定で変化が激しい) • Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧) 予測不能で 具体的な解決策が存在しない 世界
15. VUCAの時代 • Volatility (不安定で変化が激しい) • Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧) 新規事業は VUCAの時代の ど真ん中
16. VUCA時代に必要な考え 学習 適応 変化 VUCA マインド VUCAマインドは勝⼿に名付けました
17. VUCA時代に必要な考え エンジニア組織として、⼤切にするポイント • ⽂化？ • 技術？ • ツール？
18. VUCA時代に必要な考え エンジニア組織として、⼤切にするポイント • ⽂化 • 技術 • ツール 全部⼤事
19. なぜ⽂化も含まれるのか？ ソフトウェア開発上の問題の多くは、技術的という より社会学的なものである ピープルウェアより
20. なぜ⽂化も含まれるのか？ • devopsとは⽂化運動だ • devopsとは思考の⽅法であり、仕事の ⽅法である • devopsとは効率的に仕事をするために、 社会構造、⽂化、技術を⾰新する⽅法 を⾒つけること Effective DevOpsより
21. ⽂化を中⼼に捉える ツール 技術 ⽂化
22. ⽂化の⼤切さの別観点
23. VUCAマインドをどのレイヤーが受け⼊れるべきか？ 会社 組織 チーム 個⼈
24. VUCAマインドをどのレイヤーが受け⼊れるべきか？ 会社 組織 チーム 個⼈
25. なぜ個⼈なのか ⼀番影響を受ける個⼈が VUCAマインドを持つことで 会社全体が変わる
26. 過去経験則として ⾃分⾃⾝を変えることは出来る
27. 過去経験則として リーダー(⼈)はメンバー(他⼈)を 変化させることができない
28. 過去経験則として ⽂化はメンバーを変化させることができる
29. ⽂化的な取り組み ~ ⽬指すべき⽂化 ~
30. 会社から期待されていること 持続的に成果を出し続ける組織
31. ⽂化を考える上での外的要因 学習 適応 変化 VUCA マインド
32. ⽬指す⽂化 学習・適応・変化を 楽しむことができ 成果を加速させる⽂化
33. ⽂化的な取り組み ~ ⽬指すべき⽂化に向けて ~
34. ⽬指すべき⽂化に近づく考え • 成⻑思考 • ⾮難のない⽂化 / not ヒューマンエラー • 信頼マネジメント • チーム学習 • 早期フィードバック • エッセンシャル思考
35. 成⻑思考 • ⽣まれつきのスキルより、努⼒して学習することによりス キルを向上させる • xxxは⾃分だと出来ないと考えるより、出来るために⼩さな ⾏動を起こし、学習していく • 未知のものを拒絶せず、興味を⽰す • リスクを背負うことを推奨
36. ⾮難のない⽂化 / not ヒューマンエラー • インシデントは罰ではなく、学習のチャンス • インシデントは犯⼈探しではなく、環境・仕組みの改善探し • 恐怖感のある環境だと保守的になる https://www.irasutoya.com/2014/10/blog-post_90.html
37. 信頼マネジメント • リーダーはマイクロマネジメントしない • 信頼しつつチームとして確認する • 可能な限り権限を委譲する • 全員が主体的に・⾃信を持って⾏動する https://www.irasutoya.com/2017/10/blog-post_327.html
38. チーム学習 • 積極的に⾃分の学びを共有する • 積極的に他⼈の学びを共有してもらう • 「知らない」は当たり前で、学習のチャンス
39. 早期フィードバック • プロダクトが進むべき道に関する フィードバック • 働いた結果に対するメンバーからの フィードバック • 新しいことにチャレンジした結果の セルフフィードバック
40. エッセンシャル思考 • 最⼩の時間で成果を最⼤にする • 80:20の法則 • 答えがわからないので、最⼩の時間で答えを ⾒つけにいく
41. ⽬指すべき⽂化に近づく考え • 成⻑思考 • ⾮難のない⽂化 / not ヒューマンエラー • 信頼マネジメント • チーム学習 • 早期フィードバック • エッセンシャル思考
42. 補⾜：具体的な取り組み • プランニング・チーム振り返り • プロダクトミッション・営業資料作成 • プロダクトデモ • ⾏動⽬標を中⼼とした⽬標設定&プランニング • YWTによる個⼈振り返り&チームからのフィードバック • ペアプロ・バディプロ・モブプロ • ラーニングセッション
43. ⽂化的な取り組み：まとめ ⽂化を中⼼に捉え 個⼈が変えていく・変わっていく
44. 技術的な取り組み
45. 開発コンセプト 安定したインフラですばやく動け Facebookからお借り
46. 使⽤⾔語 • フロントエンド • React、Redux、TypeScript • BFF • Python、Django • バックエンド • Kotlin、Ktor
47. 技術的な取り組み • ドメイン駆動設計 • GCP サーバレスサービス
48. 技術的な取り組み ~ ドメイン駆動設計 ~
49. ドメイン駆動設計とは
50. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない
51. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない • ビジネス と 開発 でギャップが⽣まれやすい状況
52. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない • ビジネス と 開発 でギャップが⽣まれやすい状況 • 良いサービスが作りにくい環境(完全に個⼈の意⾒です)
53. 採⽤理由 エンジニアもビジネスに向き合い、開発に繋げたい
54. 実践していること • ビジネスの構造をドメインモデルで定義(PdMと対話) • 概念ごとの関連性 • ビジネスルール • PdMからビジネスの切れ⽬を教えてもらう • 境界づけられたコンテキスト = マイクロサービスの単位 • 得られた知識（ドメインモデル）をコードに落とし込む
55. 技術的な取り組み ~GCPサーバレスサービス~
56. アーキテクチャ App Engine Frontend Cloud SQL Cloud Storage Cloud Tasks Stackdriver Cloud Build Cloud Functions App Engine BFF App Engine Backend アプリケーション CI / CD ロギング/ エラー通知 ストレージ / データベース 認証 Auth0(予定) 画像変換 ConvertAPI
57. アーキテクチャポイント • インフラ構築 Ø GAE にデプロイするだけで⾃動構築 • デプロイ Ø GAE で⽤意されたコマンドを実⾏することで、Blue-Green デプロイメント Ø GAE - GitHub 連携による⾃動デプロイ(トラフィック移⾏だけ⼿動) • 認証 Ø Auth0 により開発レスでテナントに応じた認証に対応 • ログ調査 Ø Stackdrier Logging によるログの可視化・検索・分析 • エラー通知 Ø Stackdriver Error Reporting による Slack・メール・アプリ への通知 • ⾮同期実⾏ Ø Cloud Tasks によるメッセージング制御
58. アーキテクチャポイント ビジネスの本質に注⼒する アーキテクチャを構築
59. 技術的な取り組み：まとめ • ビジネスの本質に向き合う（DDD） • ビジネスの本質に注⼒する（SaaS / Paas）
60. まとめ
61. 予測不能な時代を受け⼊れ ビジネスの成功を最優先に考え・⾏動していく
62. We are hiring!!