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

RSGT2021_シリコンバレースタートアップから日系大企業までの組織別DX

KAKKA
January 05, 2021

 RSGT2021_シリコンバレースタートアップから日系大企業までの組織別DX

ラーマンの法則
数百名規模日系メガベンチャーの変革
フェーズシリコンバレースタートアップCの変化
エンジェル〜シード(数名)
シリーズA(数十名)
シリコンバレースタートアップCの変革とその後
結論と考察

KAKKA

January 05, 2021
Tweet

More Decks by KAKKA

Other Decks in Technology

Transcript

  1. シリコンバレースタートアップから日系大
    企業までの組織別DX
    Nobuhisa “KAKKA” Hirata
    Jan 6th, 2021

    View Slide

  2. はじめに
    2

    本セッションにおけるDX:デジタルトランスフォーメーションには、Developer eXperienceの意味も含まれ
    ております。
    DX=組織のAgilityを上げる、高速な仮説検証能力を身につけるという認識で、すでにデジタル企業で
    あってもDXに取り組むものであると考えております。
    DX ≒ Agilityをあげる、高速な仮説検証能力を身につける
    AgileになればなるほどAgilityはあがる
    Agileとはそのカルチャーを持った状態である

    View Slide

  3. 自己紹介
    3

    2011年〜 日系メガベンチャーA
    ソフトウェアエンジニアとして新卒入社。エンジニアとして働きながら、全社的な
    DXの最中、現場
    で複数のチームのAgile化、運用に携わる。
    2014年〜 日系大企業B
    グループ全体でソフトウェアの内製化・
    DXを推進する最中、内製化リードプロジェクトである新規
    事業に携わる。自らエンジニアとして働きながら、複数の内製開発チームの
    Agile化、コーチング
    を行う。
    2015年〜 シリコンバレースタートアップC
    エンジニアリングをはじめ、組織の拡大に合わせてプロセス変革、プロジェクトマネジメント、ピー
    プルマネジメント、組織変革など幅広い業務を担当。
    2019年に日系自動車メーカーXにExitし、
    現在DXプロジェクトリードを担当。
    KAKKA (平田将久)
    ソフトウェアエンジニア、スクラム
    マスター(CSP-SM)、DX推進。
    日本CTO協会運営、
    ScrumMastersNight!運営(休)
    経歴

    View Slide

  4. 目次
    4

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  5. 目次
    5

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  6. 紹介する組織
    6

    日系メガベンチャーA(初期)
    日系メガベンチャーA(変革期)
    日系大企業B
    シリコンバレースタートアップC(エンジェル)
    シリコンバレースタートアップC(シード)
    シリコンバレースタートアップC(シリーズA)
    日系大企業X

    View Slide

  7. 目次
    7

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  8. ラーマンの法則
    8

    組織構造が文化を作ります。
    もしくは、体制や組織設計が文化、振舞い、マインドセットに影響を及ぼすといってもいいでしょう。すなわち、あなたが本当に文化を変えた
    いのであれば、組織の構造を変えなければなりません。それ以外に文化を変える方法はありません。ただし、これは大規模な組織の場合
    であり、スタートアップでは全くの逆です。文化が組織構造に影響を及ぼします(マインドセットが組織構造を作るのです)。
    そして、組織構造が文化を作る(大規模な場合)ゆえに、学習する組織といったような深い思考体制がが単体では定着しなかったり、影響
    を及ぼす事が難しい理由です。そしてスクラム(最初から組織に変更を及ぼす事を意識している)がより早く文化に影響を及ぼす事ができ
    る理由となります。ーもちろん、スクラムによる構造改革が実現可能であれば、という条件が付随されます。
    システム思考家であり、システム思考の提唱者であるJohn Seddon氏曰く、「組織の文化を変えようとする事は愚かな試みです。なぜな
    ら、そのような試みは常に失敗するからです。人々のふるまい(文化)は体制により作られるからです。もしあなたが体制を変えれば人々の
    ふるまいは変わるでしょう。」
    なんとなく頭の片隅に置いておいてください

    View Slide

  9. 目次
    9

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCのの変革
    ● 結論と考察

    View Slide

  10. 日系メガベンチャーAの旧構造
    10

    チーム
    チーム
    チーム
    チーム チーム
    チーム
    品質管理部
    事業部
    ※人数やチーム数など、細かい部分までは正確ではありません。イメージです。
    開発グループ
    チーム チーム
    チーム チーム チーム
    デザイングループ
    チーム チーム
    チーム チーム
    チーム
    チーム チーム
    企画グループ
    典型的な職能ヒエラルキー構造

    View Slide

  11. 日系メガベンチャーAの旧構造の特長(エンジニア目線の感想)
    11

    ● 効率の悪い仕事
    ○ 適当にプロジェクトにアサインされる。兼務もある。
    ○ デザインとかQAは部署外の人に頼む形になるので、調整大変だし、同じ社員同士でも腫れ物を扱うかのような対応をし
    ないといけないときもあった
    ○ 同じチーム内でも別プロジェクトの人はなんか炎上しているけど助けるすべはない。
    ○ コードレビューは全然プロジェクト関係ない技術者にしてもらう。期限は守られない。
    ● 個人のアイデアを活かすチャンスがなく、やりがいも感じられない
    ○ 企画がウォーターフォールで降ってくる。誰が何を根拠に企画を決めたのか全くわからない。
    ○ 企画がどっからどう決められたかわからないし、組織としての主要なビジョンがわからない。
    ○ 結果とりあえず技術力をあげようとすることを目的とする。
    ● ビジネス的に危機なのに、のんびりとした仕事スタイル
    ○ エンジニアを尊敬する宗教が布教されていて、納期とか簡単に引き伸ばせるし、企画も覆せた。

    View Slide

  12. 目次
    12

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  13. 日系メガベンチャーAの変革後構造
    13

    事業部
    ※人数やチーム数など、細かい部分までは正確ではありません。イメージです。
    PO
    SM
    フィーチャーチーム
    PO
    SM
    フィーチャーチーム
    ・・・
    ● 職能コンポーネントチームからクロスファン
    クショナルなフィーチャーチームへ変わった
    ● マネージャーは不在になった
    ● スクラムのオフィシャルな構造になった
    ○ POが価値の最大化に責任と権限を持つ
    ○ 開発チームがコードレビューも行う
    ○ スクラムマスターも定義される

    View Slide

  14. 日系メガベンチャーAの変革後構造の特長(現場目線の感想)
    14

    ● 圧倒的にアジャイルになった
    ○ あらゆるボトルネックが排除されてスピードが圧倒的にあがった。
    ○ 短期間で定期的にリリースするという習慣が身についた。
    ○ 自分で責任も持つので、自ら学習により意欲的になった。
    ○ コミュニケーションが活発になった
    ● 純粋に働いている意味が感じられ、やりがいを感じるようになった
    ○ 以前部外者との調整が大変だったが、同じチーム内にいるようになったので、仲間として仕事をできるようになった
    ○ なぜこれをやるのか、意思決定者がそばにいて、然るべきプロセスで決められ、納得感があった。
    ● その後、収益の柱となる新規事業が続々と生まれた

    View Slide

  15. 目次
    15

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  16. シリコンバレースタートアップC(エンジェル〜シード)の構造
    16

    Company
    ※人数やチーム数など、細かい部分までは正確ではありません。イメージです。
    図としての定義は全く無かったが、
    動きとしては数名の完全フラットなクロス
    ファンクショナルチーム
    =会社
    ≒プロダクト開発組織

    View Slide

  17. シリコンバレースタートアップC(エンジェル〜シード)の構造の特長
    17

    ● オープンなコミュニケーションと意思決定
    ● 全員がロックスター、圧倒的当事者意識
    ● 燃えすぎても燃え尽きない
    ● スクラムの真似事やプラクティスつまみ食いでAgileになっていた
    ○ PdMによるWhat to doの一元管理と週1のリファインメント
    ○ 属人性を排除したタスクマネジメントとクロスファンクショナル化
    ○ レトロスペクティブによるプロダクト以外の定期的な改善
    ● Scientificな仮説検証も当然のように行われていた
    つまり、勝手にすごく良い組織になっていた

    View Slide

  18. 目次
    18

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  19. シリコンバレースタートアップC(シリーズA)の構造
    19

    ※人数やチーム数など、細かい部分までは正確ではありません。イメージです。
    ● 10〜20名の組織
    ● 深いヒエラルキーの発生
    ● 同じプロダクトのインクリメントをプロジェ
    クトで開発する体制
    ● 図としては定義はされていなかったが、
    各職能の責任者が定義され、責任者だ
    けでのコミュニケーションがほとんどに
    なった
    Company
    エンジニアチーム デザインチーム 企画チーム
    QAチーム

    View Slide

  20. シリコンバレースタートアップC(シリーズA)の構造の特長
    20

    ● 全員でのオープンコミュニケーションに限界がくる
    ○ Slackでのオープンチャンネルでの会話がしづらくなり、DM率向上
    ○ 結果的に個人間でのコミュニケーションが発生
    ● ワンチームでの活動に限界がきて、プロジェクト駆動開発を行う
    ○ プロジェクト間の情報共有や引継ぎまでやる余裕はなかった
    ○ リソース調整難易度が一気に上がり、安定してプロダクトインクリメントを作り出すのが難しくなった
    ○ 忙しい時と暇なときの差が激しくなった
    ● 企画は企画へ、開発は開発へよりフォーカスしていく
    ○ 開発はそのユーザー価値について考えるというよりは、開発タスクを消化することに集中せざるを得なくなった
    ○ 企画職が企画をしなければならないが、複数プロジェクトをさばくリソースにも限界が来ていた
    Agileなマインドセットがある人たちが揃っているのに、
    なにか逆方向に引っ張られる引力が働いていた

    View Slide

  21. 目次
    21

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  22. 変革への道
    22

    このままでは会社が危うい。僕もストックオプション保持者なのでなんとかせねば。
    根本的に解決して、イケイケの組織にしたいが、セオリーがよくわからない。
    ふとしたきっかけで出会った本
    大規模スクラム
    フレームワークのガイドが書いてある
    んだろうと甘く見ていた
    ● スクラムの価値基準をそのまま導入したいけど、単純にスクラムやればOKとかそういう問題ではない。
    ● コミュニケーション構造とかSlackのDMの問題とかもわりと断片的であり、人々の習慣そのものなので、強制
    的に変えるのは難しい。
    ● 見えてる問題を解決しても、習慣・カルチャーの力でまたすぐに元通りになってしまう。
    ● カルチャー自体を変えなければならない。カルチャーがAgileでなければ、その組織はAgileではない。

    View Slide

  23. ラーマンの法則
    23

    組織構造が文化を作ります。
    体制や組織設計が文化、振舞い、マインドセットに影響を及ぼす
    スタートアップでは全くの逆です。文化が組織構造に影響を及ぼします

    View Slide

  24. 24

    組織構造が文化を作ります。
    体制や組織設計が文化、振舞い、マインド
    セットに影響を及ぼす
    スタートアップでは全くの逆です。文化が組
    織構造に影響を及ぼします

    View Slide

  25. ラーマンの法則とともに過去の組織を振り返る
    25

    Agile
    ● オープンなコミュニケーション、意思決定、自由
    と責任
    ● 全員がロックスター、圧倒的当事者意識
    ● 燃えすぎても燃え尽きない
    ● スクラムの真似事やプラクティスつまみ食いで
    Agileになっていた
    ● Scientificな仮説検証も当然のように行われて
    いた
    ● 圧倒的にアジャイルになった
    ● 純粋に働いている意味が感じら
    れ、楽しくやりがいが出た
    ● その後、収益の柱となる新規事
    業が続々と生まれた

    View Slide

  26. シリコンバレースタートアップCの変革
    26

    全員でのオープンコミュニケーションに限界がくる
    ワンチームでの活動に限界がきて、プロジェクト駆動開発を行う
    企画は企画へ、開発は開発へよりフォーカスしていく
    透明性が必要なコミュニケーションはオープンに
    安定したインクリメンタルな開発へ
    再びワンチームでのプロダクト開発スタイルへ

    View Slide

  27. シリコンバレースタートアップCの変革
    27

    エンジニアチーム
    デザインチーム
    QAチーム
    企画チーム
    CSチーム
    プロダクトAチーム
    プロダクトBチーム
    プロダクトCチーム
    習慣・カルチャーを変えるべく、再びクロスファンクショナルなプロダクト組織へ

    View Slide

  28. シリコンバレースタートアップCの変革
    28

    プロダクトAチーム
    Slackのチャンネルを整理することで、組織構造の概念定着を促す。
    Slackは毎日頻繁に見るので、概念定着に効率が良い。
    #pd_a
    #pd_a_engineering など
    終わりのあるプロジェクトBチャンネル #pj_b
    職能マトリックス組織をコミュニティという概念で
    くくり、オープンに
    #com_engineering
    #com_design など
    DM非推奨などのガイドラインも同時に定義、全社に周知

    View Slide

  29. シリコンバレースタートアップCの変革の経過
    29

    他、私以外のリーダーたちの尽力もたくさんあり、徐々に良い結果が出てきている。
    ● 様々な周辺環境の変化の影響もあるが、圧倒的にAgilityは上がった。
    ● プロジェクトの概念がなくなった
    ● 自然にスクラムみたいなプロセスを導入するようになっていった
    ● SlackのDM率はかなり改善。オープンなプロダクト組織用チャンネルが最も活発になった
    ● プロダクトチーム単位での活動も活発になっていっている。
    ● プロダクト開発活動はプロダクトチームのメンバーに任せながら、職能コミュニティでのコミュニケーション
    の機会も増えている。1on1も行われ始めた

    View Slide

  30. 目次
    30

    ● 紹介する組織例
    ● 事前知識: ラーマンの法則
    ● 日系メガベンチャーAの変革
    ○ 日系メガベンチャーA(旧)
    ○ 日系メガベンチャーA(新)
    ● シリコンバレースタートアップCの変化
    ○ シリコンバレスタートアップC(エンジェル〜シード)
    ○ シリコンバレースタートアップC(シリーズA)
    ● シリコンバレースタートアップCの変革
    ● 結論と考察

    View Slide

  31. 31

    DX ≒ Agilityをあげる、高速な仮説検証能力を身につける
    AgileになればなるほどAgilityはあがる
    Agileとはそのカルチャーを持った状態である
    カルチャーを変えるには組織構造を変えることが超重要

    View Slide

  32. 32

    経験主義 リーン思考
    透明性 検査 適応
    プロセスやツールよりも個人と対話を、
    包括的なドキュメントよりも動くソフトウェアを、
    契約交渉よりも顧客との協調を、
    計画に従うことよりも変化への対応を
    Agileな文化にしたい場合は、Agileな構造にすることが重要
    確約 勇気 集中 公開 尊敬

    View Slide

  33. 考察:なぜ組織構造で変わるのか
    組織構造は、オフィシャルで組織共通の不動の概念
    具体的な役割
    委譲されている責任や権限
    推奨されている価値観・行動・コンピテンシー
    推奨されているプロセス
    PO
    SM
    が可視化され、日々明確なオフィシャルメッセージが投げられている状態

    View Slide

  34. 考察:なぜ組織構造で変わるのか
    メッセージは投げるだけじゃ不十分ではあるが、
    メッセージは投げなきゃ伝わらない。
    組織構造を定義するということは、会社としての意思を明確にメッ
    セージとして投げるということ。
    組織全体が会社の意思を理解し、全員が自律的に同じ方向に向
    かって進んでいく土台となる。

    View Slide

  35. ご清聴ありがとうございました。

    35

    採用情報(2021/01)@KAKKA_BlogまでDM下さい


    Drivemode, Inc.: エンジニアリングマネージャー


    日本CTO協会: フルタイム総合職


    View Slide

  36. 付録

    36


    View Slide

  37. 現状の組織構造に甘えているとこのように変革失敗する
    37

    ● 例えばスクラムのアンチパターンにずるずるとハマっていく
    ○ 構造上仕方ないから既存のマネージャーが
    POとSM兼務でやってね!
    ○ POは何やるか決まったら上の人に承認取ってね!勝手にリリースしないでね!
    ○ 他の会議で忙しいし、振り返りはマンネリしてきたからやめよう!
    ○ 見積もりとかわからないよね、だから期限だけ決めるね!
    ○ あの人が一番速いからあの人に任せよう!
    ● 制約条件に甘えた「おままごと」が徐々に普通に思えてくる
    ● 長年アジャイルやってるので我々はアジャイルだと信じ込む。そしてもうアジャイルだから変えなくていい
    と思ってしまう
    ● アジャイル関連書籍を読み、そうそう知ってる、普通やん!って思ってそのままウォーターフォールの仕
    事に戻っていく。

    View Slide