https://event.shoeisha.jp/devsumi/20190927/session/2120/ で発表した資料

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!!