Downloaded 16 times
Uploaded byMao Ohnishi
新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~
https://event.shoeisha.jp/devsumi/20190927/session/2120/ で発表した資料
![[db tech showcase Tokyo 2018] #dbts2018 #A11 『システム開発によろこびと驚きの連鎖を』](https://cdn.slidesharecdn.com/ss_thumbnails/dbts2018a11keynote-181002065434-thumbnail.jpg?width=640&height=640&fit=bounds)
新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~
- 1. 新規事業を ⽀える⽂化と加速させる技術 ~ devops /GCP / DDD ~ @mmmmao0530
- 2. ⾃⼰紹介 - 名前 :⼤⻄ 真央(@mmmmao0530) - 所属 : 新規事業開発室 エンジニアリンググループ 関⻄⽀店勤務 - 社歴 : - Sier - Biglobe : スクラム推進、ドメイン駆動設計導⼊ - Sansan : > Sansanプロダクト Webエンジニア ⼤阪拠点⽴ち上げ > Sansanプロダクト エンジニアリングマネージャー > 新規サービス 開発リーダー 兼 グループリーダー
- 3.
- 4. アジェンダ - チェックイン - ⽂化的な取り組み -⽂化の⼤切さ - ⽬指すべき⽂化 - ⽬指すべき⽂化に向けて - 技術的な取り組み - ドメイン駆動設計 - GCPサーバレスサービス - まとめ
- 5.
- 6.
- 7.
- 8. 新規事業開発室の体制と⾃⾝の関わり⽅ 新規事業開発室 BサービスAサービス Cサービス 開発リーダー アジャイルコーチアジャイルコーチ 7名のエンジニア
- 9. 新規事業開発室の体制と関わり⽅ 新規事業開発室 BサービスAサービス Cサービス 開発リーダー アジャイルコーチアジャイルコーチ メインの話 7名のエンジニア
- 10.
- 11.
- 12.
- 13. VUCAの時代 • Volatility (不安定で変化が激しい) •Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧)
- 14. VUCAの時代 • Volatility (不安定で変化が激しい) •Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧) 予測不能で 具体的な解決策が存在しない 世界
- 15. VUCAの時代 • Volatility (不安定で変化が激しい) •Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧) 新規事業は VUCAの時代の ど真ん中
- 16.
- 17.
- 18.
- 19.
- 20. なぜ⽂化も含まれるのか？ • devopsとは⽂化運動だ • devopsとは思考の⽅法であり、仕事の ⽅法である •devopsとは効率的に仕事をするために、 社会構造、⽂化、技術を⾰新する⽅法 を⾒つけること Effective DevOpsより
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 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.
- 46. 使⽤⾔語 • フロントエンド • React、Redux、TypeScript •BFF • Python、Django • バックエンド • Kotlin、Ktor
- 47. 技術的な取り組み • ドメイン駆動設計 • GCPサーバレスサービス
- 48.
- 49.
- 50.
- 51. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない •ビジネス と 開発 でギャップが⽣まれやすい状況
- 52. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない •ビジネス と 開発 でギャップが⽣まれやすい状況 • 良いサービスが作りにくい環境(完全に個⼈の意⾒です)
- 53.
- 54. 実践していること • ビジネスの構造をドメインモデルで定義(PdMと対話) • 概念ごとの関連性 •ビジネスルール • PdMからビジネスの切れ⽬を教えてもらう • 境界づけられたコンテキスト = マイクロサービスの単位 • 得られた知識（ドメインモデル）をコードに落とし込む
- 55.
- 56. アーキテクチャ App Engine Frontend Cloud SQLCloud 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.
- 60.
- 61.
- 62.