新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~
•
10 likes•3,713 views
https://event.shoeisha.jp/devsumi/20190927/session/2120/ で発表した資料
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~
Similar to 新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~ (20)
More from Mao Ohnishi
新規事業を 支える文化と加速させる技術 ~ devops / GCP / DDD ~
- 1. 新規事業を ⽀える⽂化と加速させる技術 ~ devops / GCP / DDD ~ @mmmmao0530
- 2. ⾃⼰紹介 - 名前 : ⼤⻄ 真央(@mmmmao0530) - 所属 : 新規事業開発室 エンジニアリンググループ 関⻄⽀店勤務 - 社歴 : - Sier - Biglobe : スクラム推進、ドメイン駆動設計導⼊ - Sansan : > Sansanプロダクト Webエンジニア ⼤阪拠点⽴ち上げ > Sansanプロダクト エンジニアリングマネージャー > 新規サービス 開発リーダー 兼 グループリーダー
- 4. アジェンダ - チェックイン - ⽂化的な取り組み - ⽂化の⼤切さ - ⽬指すべき⽂化 - ⽬指すべき⽂化に向けて - 技術的な取り組み - ドメイン駆動設計 - GCPサーバレスサービス - まとめ
- 5. チェックイン
- 8. 新規事業開発室の体制と⾃⾝の関わり⽅ 新規事業開発室 BサービスAサービス Cサービス 開発リーダー アジャイルコーチ アジャイルコーチ 7名のエンジニア
- 9. 新規事業開発室の体制と関わり⽅ 新規事業開発室 BサービスAサービス Cサービス 開発リーダー アジャイルコーチ アジャイルコーチ メインの話 7名のエンジニア
- 12. ⽂化的な取り組み ~ ⽂化の⼤切さ ~
- 13. VUCAの時代 • Volatility (不安定で変化が激しい) • Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧)
- 14. VUCAの時代 • Volatility (不安定で変化が激しい) • Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧) 予測不能で 具体的な解決策が存在しない 世界
- 15. VUCAの時代 • Volatility (不安定で変化が激しい) • Uncertainty (不確実性が⾼く先⾏きが⾒えない) • Complexity (様々な要素が複雑に絡み合う) • Ambiguity (物事の因果関係が曖昧) 新規事業は VUCAの時代の ど真ん中
- 18. VUCA時代に必要な考え エンジニア組織として、⼤切にするポイント • ⽂化 • 技術 • ツール 全部⼤事
- 20. なぜ⽂化も含まれるのか？ • devopsとは⽂化運動だ • devopsとは思考の⽅法であり、仕事の ⽅法である • devopsとは効率的に仕事をするために、 社会構造、⽂化、技術を⾰新する⽅法 を⾒つけること Effective DevOpsより
- 22. ⽂化の⼤切さの別観点
- 29. ⽂化的な取り組み ~ ⽬指すべき⽂化 ~
- 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による個⼈振り返り&チームからのフィードバック • ペアプロ・バディプロ・モブプロ • ラーニングセッション
- 44. 技術的な取り組み
- 46. 使⽤⾔語 • フロントエンド • React、Redux、TypeScript • BFF • Python、Django • バックエンド • Kotlin、Ktor
- 47. 技術的な取り組み • ドメイン駆動設計 • GCP サーバレスサービス
- 48. 技術的な取り組み ~ ドメイン駆動設計 ~
- 49. ドメイン駆動設計とは
- 51. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない • ビジネス と 開発 でギャップが⽣まれやすい状況
- 52. 採⽤理由 • ⾃分たちがエンドユーザにならないサービス • エンジニアが営業をする機会は少ない • ビジネス と 開発 でギャップが⽣まれやすい状況 • 良いサービスが作りにくい環境(完全に個⼈の意⾒です)
- 54. 実践していること • ビジネスの構造をドメインモデルで定義(PdMと対話) • 概念ごとの関連性 • ビジネスルール • PdMからビジネスの切れ⽬を教えてもらう • 境界づけられたコンテキスト = マイクロサービスの単位 • 得られた知識（ドメインモデル）をコードに落とし込む
- 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 によるメッセージング制御
- 60. まとめ
- 62. We are hiring!!