Upgrade to Pro — share decks privately, control downloads, hide ads and more …

"Supporting culture and technology to accelerate" new businesses

13d936e697fe0f4fa96f926d0a712f6c?s=47 Sansan
PRO
September 27, 2019

"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/

13d936e697fe0f4fa96f926d0a712f6c?s=128

Sansan
PRO

September 27, 2019
Tweet

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

  63. None