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

いまさら聞けないDXの4つのポイント 〜DX向上を促進するカルチャーとは〜

いまさら聞けないDXの4つのポイント 〜DX向上を促進するカルチャーとは〜

Developer eXperience Day CTO/VPoE Conference 2021で登壇した際の発表資料です。
https://dxd2021.cto-a.org/developer-experience-day-2021

皆さんはDX向上のための4つの重要なポイントをご存知ですか?
それぞれのポイントの説明とともに、カオナビがどのような取り組みをしてきたか、そしてDX向上を促進するエンジニア文化をどのように作り上げてきたかを説明しています。

株式会社カオナビ

April 12, 2021
Tweet

More Decks by 株式会社カオナビ

Other Decks in Business

Transcript

  1. © kaonavi Inc. Developer eXperience Day CTO/VPoE Conference 2021 いまさら聞けない

    DXの4つのポイント 〜DX向上を促進するカルチャーとは〜 株式会社カオナビ CTO 松下雅和 2021/04/10
  2. © kaonavi Inc. 自己紹介 2 • 松下 雅和 / @matsukaz

    • 株式会社カオナビ CTO(2020年2月入社、2020年9月就任) SIer2社 → サイバーエージェント → トランスリミット CTO • AWS, Node.js, Ruby, Python, PHP, Go • カメラ, 自転車(BD-1), テニス, 卓球, ボウリング • 二児の姉妹の父
  3. © kaonavi Inc. DX = Developer eXperience 11 API 顧客

    システム UX = User eXperience UI ユーザ 開発者 開発者 開発者
  4. © kaonavi Inc. 14 https://cto-a.github.io/dxcriteria/ ▪ [DX Criteria] 「2つのDX」とデジタル経営のガイドライン 開発者にとっての働きやすい環境と高速な開発を

    実現するための文化・組織・システムが実現されているかを 意味する開発者体験(Developer eXperience) API 顧客 システム 開発者 開発者
  5. © kaonavi Inc. 素晴らしいDXを実現する4つの要素 23 アーキテクチャ ツール プロセス チーム カルチャー

    プロダクトやチームに合った最適な アーキテクチャ(シンプル ↔ 複雑) • 優れたDXのアーキテクチャ ◦ 高可用性と耐障害性を実現 ◦ リリースまでのリードタイムが短い ◦ システムの可視性が高い
  6. © kaonavi Inc. 素晴らしいDXを実現する4つの要素 24 アーキテクチャ ツール プロセス チーム カルチャー

    可能な限りツールで自動化 • テスト • ビルド&デプロイ • コーディングスタイルへの準拠 • インフラの構築 • セキュリティチェック
  7. © kaonavi Inc. ツール チーム カルチャー 素晴らしいDXを実現する4つの要素 25 アーキテクチャ プロセス

    プロセス化で手順が安定化し、精神的負担 が軽減、チームに規律が生まれる • 開発 • QC • デプロイ • フィードバック • オンボーディング
  8. © kaonavi Inc. チーム カルチャー 素晴らしいDXを実現する4つの要素 26 アーキテクチャ ツール プロセス

    カルチャーは開発者にインストールされ、最 も重要な判断軸となる 優れたDXのチームカルチャー • チームや会社の存在意義を理解 • チームや会社に対して オーナーシップと責任感を持つ • チームや会社で共通のゴールがある • 優しさと誠実さを持つ • 失敗を許容できる
  9. © kaonavi Inc. カオナビの歴史 33 導入社数 2000 1750 1500 1250

    1000 750 500 250 0 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 1789 1293 854 445 203 98 40 21 2000以上 2021/3 マザーズ上場
  10. © kaonavi Inc. カオナビの歴史 34 導入社数 2000 1750 1500 1250

    1000 750 500 250 0 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 1789 1293 854 445 203 98 40 21 2000以上 2021/3 黎明期 サービス リプレース 急速な 組織化
  11. © kaonavi Inc. カオナビの歴史 35 導入社数 2000 1750 1500 1250

    1000 750 500 250 0 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 1789 1293 854 445 203 98 40 21 2000以上 2021/3 黎明期 サービス リプレース 急速な 組織化 SES中心の開発 エンジニアが 徐々に増加 職能別組織へ エンジニア人数 エンジニアが急増 チーム開発へ
  12. © kaonavi Inc. • 最適なアーキテクチャも、対策せずに運用を続ければ最適ではなくなる ◦ 技術スタックの陳腐化 ◦ 属人化 ◦

    スパゲッティコード システムリプレース後のアーキテクチャ 40 開発スピードの低下 組織が拡大してもスケールできない
  13. © kaonavi Inc. 守りのカイゼン • PHP, Laravelの継続的なバージョンアップ • 着実なリファクタリング •

    Clean Architectureの導入 • AWS Well-Architectedに沿う構成へアーキテクチャを見直し https://aws.amazon.com/jp/solutions/case-studies/kaonavi/ • マイクロサービス化の推進
  14. © kaonavi Inc. GitLabによる自動化 44 • 単体テスト、E2Eテスト • セキュリティチェック •

    コーディング規約チェック • Swaggerカバレッジ計測 • ビルド • デプロイ
  15. © kaonavi Inc. Slackによる自動化 46 • ワークフロー機能でオンボーディング支援を自動化 ◦ Slackの設定や推奨チャンネル紹介 ◦

    Confluenceの設定、利用説明 ◦ GitLabの個人設定 ◦ ローカル開発環境の構築 ◦ 開発ルール説明 ◦ 開発フォロー
  16. © kaonavi Inc. システムリプレース後の開発プロセス 49 • 職能別組織による開発 ◦ 生産性も向上 PM/企画職

    グループ エンジニア グループ QA グループ 仕様作成 リリースコントロール 実装 品質保証 リリース Operation グループ
  17. © kaonavi Inc. システムリプレース後の開発プロセス 50 • ところが、組織が大きくなるにつれてセクショナリズムが深刻化 ◦ 仕様書の読み込みが大変 ◦

    期日コミットがゴールに ◦ 仕様変更への対応が鈍化 ◦ 意思疎通不全 アジャイルソフトウェア 開発宣言と真逆状態に プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、
  18. © kaonavi Inc. • 組織をミッションベースのグループに変更し、グループ内でチーム開発 職能別組織からチームによる開発へ 51 PM/企画職 グループ エンジニア

    グループ ミッションベース グループ ◦◦チーム ◦◦チーム リリースまでの 全行程に責任 QA グループ チーム内は QA→QCへ リリース 依頼 リリースまでの 全行程に責任 Operation グループ Operation グループ
  19. © kaonavi Inc. チームごとに開発プロセスを選択 52 • 開発規模が大きいチームの多くはスクラム開発 • 少人数体制の改善/保守タスクはRedmineのチケット駆動開発 デイリースクラム

    バックログリファインメント スプリント レビュー レトロ スペクティブ プランニング1 プランニング2 開発 スクラム イベント スプリント
  20. © kaonavi Inc. 安定運用のためのリリースプロセス 53 • 品質管理(Quality Control) ◦ チーム開発の場合は専任のQCメンバーを配置

    ▪ 品質の重要性をチーム内で啓蒙 ▪ アジャイルテストの取り組み リリース(テスト)計画更新 リグレッションテスト 受け入れ条件 チェック テストケース 設計&作成 テスト実施 テストレベル 定義 テスト観点 テスト見積り レポート テストケース レビュー アジャイル テスト スプリント
  21. © kaonavi Inc. レビューマスター 安定運用のためのリリースプロセス 54 • コードレビュー体制 ◦ フロントエンドやバックエンドなど、

    領域ごとの担当者(レビューマスター)を複数人配置 ◦ チーム内レビューも徐々に展開 レビュー 依頼 フロントエンド バックエンド レビュー依頼 ◦◦チーム ◦◦チーム
  22. © kaonavi Inc. 安定運用のためのリリースプロセス 55 • 安定のリリース体制 ◦ Operationグループによるスケジュール管理されたリリースプロセス ◦

    リリース回数、リバート数、デプロイ成功率などの指標で常にカイゼン Operation グループ リリース依頼 ◦◦チーム リリース 対象リスト リリース
  23. © kaonavi Inc. カオナビのカルチャー 62 MY WORK STYLE ハイブリッドワーク 働く場所を選択可能(出社

    or 自宅 or 許可された就業スペース) スーパーフレックス制度 フレックスタイム内の任意の時間帯で勤務 ※ 1日4時間以上の勤務、月の所定労働時間あり スイッチワーク制度 連続して勤務できない場合も、時間を細切れにして働ける制度 1 2 3 兼業推奨 異なるフィールドでの経験がカオナビでの活躍にもつながるという考え 4
  24. © kaonavi Inc. • Slackはほとんどオープンチャンネル、透明性を大事に • 助け合いの文化 ◦ 分報やチャンネルへ投稿するといろんな人が助けてくれる •

    プロダクトアウトの考え方が定着 • ボトムアップで判断 ◦ 現場が自ら考え、主体的に行動 • 仮説思考でロジカルに考える • 限られた時間内できちんと成果を出す ◦ 1日あたりの残業時間はわずか4分 雰囲気・マインド 65 エンジニアがよく使う Slackの絵文字たち
  25. © kaonavi Inc. • エンジニア分科会(毎週) ◦ 参加はテックリード + CTO ◦

    議題により他のメンバーも任意参加 ◦ プロダクトにおける技術的な課題の解決や方針を決める場 組織的な取り組み 67
  26. © kaonavi Inc. 組織的な取り組み 68 • エンジニア定例ミーティング(毎週) ◦ 原則として全エンジニア参加 ◦

    技術課題や開発方針、各チームの開発状況を共有する場 ▪ 解決したい課題が出てきた場合は、エンジニア分科会に持ち込む
  27. © kaonavi Inc. • リスク管理ミーティング(毎週) ◦ 参加はマネージャー + QC責任者 +

    CTO ◦ プロダクトにおけるあらゆるリスクを共有し、問題が顕在化する前に 対策を行うためのミーティング 組織的な取り組み 69
  28. © kaonavi Inc. カオナビの歴史 72 導入社数 2000 1750 1500 1250

    1000 750 500 250 0 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 1789 1293 854 445 203 98 40 21 2000以上 2021/3 黎明期 サービス リプレース 急速な 組織化 SES中心の開発 エンジニアが 徐々に増加 職能別組織へ エンジニア人数 エンジニアが急増 チーム開発へ
  29. © kaonavi Inc. エンジニア 組織なし 混乱期 Storming 形成期 Forming タックマンモデルで見るエンジニア組織

    73 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 2021/3 統一期 Norming エンジニア人数 成果
  30. © kaonavi Inc. エンジニア 組織なし 混乱期 Storming 形成期 Forming タックマンモデルで見るエンジニア組織

    74 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 2021/3 統一期 Norming エンジニア人数 成果
  31. © kaonavi Inc. • SES中心の開発 • 売上重視 • 技術負債の蓄積 •

    運用もだんだんと不安定に… 2015年 75 サービスリプレース開始
  32. © kaonavi Inc. • 現行バージョンへの移行完了 • エンジニア組織ができあがり、組織体制の強化へ • 職能別組織で安定化、生産性も向上 2017年

    76 PM/企画職 グループ エンジニア グループ QA グループ 仕様作成 リリースコントロール 実装 品質保証 リリース Operation グループ
  33. © kaonavi Inc. エンジニア 組織なし 混乱期 Storming 形成期 Forming タックマンモデルで見るエンジニア組織

    77 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 2021/3 統一期 Norming エンジニア人数 成果
  34. © kaonavi Inc. 2019年 78 • やがてセクショナリズムが深刻化 ◦ 仕様書の読み込みが大変 ◦

    期日コミットがゴールに ◦ 仕様変更への対応が鈍化 ◦ 意思疎通不全 アジャイルソフトウェア 開発宣言と真逆状態に プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、
  35. © kaonavi Inc. • 組織をミッションベースのグループに変更し、グループ内でチーム開発 職能別組織からチームによる開発へ 82 PM/企画職 グループ エンジニア

    グループ ミッションベース グループ ◦◦チーム ◦◦チーム リリースまでの 全行程に責任 QA グループ QA→QCへ リリース 依頼 リリースまでの 全行程に責任 Operation グループ Operation グループ
  36. © kaonavi Inc. • チーム開発で生じた変化 職能別組織からチームによる開発へ 83 何のために開発しているのか分からない やらされ仕事 個人で成果を出す

    自分の仕事が終わるかどうか 企画職と開発者のコミュニケーション不足 認識のズレ Whyを理解した上で開発 自分たちで成し遂げる仕事 チームで成果を出す チームとしての仕事が終わるかどうか 疑問・相談は直接その場で速攻で 同じ質で同じ情報量
  37. © kaonavi Inc. • やがて開発プロセスに変化が起こり、アジャイルな考え方が組織に浸透 スクラムの導入 90 プロジェクトの終盤まで不確実性が残る スケジュールもスコープも変えられない …?

    QAは他のグループがやるもの 手を動かすまで開発の難易度は分からない プロジェクトが終わってからのふりかえり 全て開発し終わるまでリリースできない アジャイルな見積もりと計画の実践 自分たちでプロジェクトのハンドルを握る チームで完結できるようコラボレーション プラニングが終了時点で把握、対策を打つ 毎スプリント小さなカイゼンを試す α、βリリースでフィードバックループを回す
  38. © kaonavi Inc. エンジニア 組織なし 混乱期 Storming 形成期 Forming タックマンモデルで見るエンジニア組織

    97 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 2021/3 統一期 Norming エンジニア人数 成果
  39. © kaonavi Inc. エキスパートの配置 100 サービスリード エキスパート マネージメント テックリード 専門性

    管理・育成 ドメイン 一般 歴史、ドメイン、コア概念の 全体的ボトムアップを図る 環境や仕組みを整え メンバーの能力を最大化 プロダクトの課題解決を エキスパートとして導く 生産性の最大化のために メンバーを強化
  40. © kaonavi Inc. スキルアップの促進 102 • 忙しいときほどゆとり時間が大事 サバイバルモード 学習モード 自己組織化モード

    • 学ぶ時間がない • 定期的に火消し作業 • 遅れと残業 • 十分なゆとり時間 • スキルの習得時間がある • 誤りを許容する • チームにスキルがある • 自分たちで意思決定できる • 衝突を内部解決できる • ゆとり時間を作る • 残業を減らす • 見積もりし直す • チーム自身で 自分たちの問題を解決 できるように教える
  41. © kaonavi Inc. スキルアップの促進 104 • イドバタ(不定期) ◦ 業務時間外に開催する勉強会などの活動 ◦

    CTOやEMが積極的に場を用意 ◦ 社外の人を巻き込んでやることも検討中 ◦ 第1回 あなたのターニングポイントは?〜私、その時に覚醒しました〜 ▪ 登壇者5名(各10分〜15分) ▪ 参加者30名以上