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向上を促進するエンジニア文化をどのように作り上げてきたかを説明しています。

D6b7aaaec7e911cf7657153c9bbc5c53?s=128

株式会社カオナビ

April 12, 2021
Tweet

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. 3 © kaonavi Inc.

  4. © kaonavi Inc. 4 © kaonavi Inc.

  5. © kaonavi Inc. © kaonavi Inc. カオナビで出来る戦略的人事 5

  6. © kaonavi Inc. DX 6

  7. © kaonavi Inc. Developer eXperience 開発者体験 7

  8. © kaonavi Inc. この言葉を 初めて聞いたのは? 8

  9. © kaonavi Inc. 本題に入る前に ちょっと調べてみた 9

  10. © kaonavi Inc. 元々はAPIやSDKを 利用する開発者に向けた概念 10 https://uxmag.com/articles/effective-developer-experience https://www.infoq.com/news/2015/10/api-developer-experience ▪ [UX

    Magazine] Effective Developer Experience (DX) ▪ [InfoQ] What is API Developer Experience and Why It Matters
  11. © kaonavi Inc. DX = Developer eXperience 11 API 顧客

    システム UX = User eXperience UI ユーザ 開発者 開発者 開発者
  12. © kaonavi Inc. プロダクトを利用する開発者と プロダクトを開発する開発者、 両方を対象にした概念も 12 https://developerexperience.io/practices/good-developer-experience ▪ [DEVELOPEREXPERIENCE.IO]

    Good Developer Experience API 顧客 システム 開発者 開発者
  13. © kaonavi Inc. CTO協会の定義は? 13

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

    実現するための文化・組織・システムが実現されているかを 意味する開発者体験(Developer eXperience) API 顧客 システム 開発者 開発者
  15. © kaonavi Inc. 15 API 顧客 システム 開発者 開発者 それぞれ概念が違う

    初期の概念 CTO協会 DEVELOPEREXPERIENCE.IO
  16. © kaonavi Inc. 今日話すのは CTO協会が定義するDX (2つのDXのうちDeveloper eXperienceのみ) 16 API 顧客

    システム 開発者 開発者
  17. © kaonavi Inc. 17 いまさら聞けない DXの4つのポイント 〜DX向上を促進するカルチャーとは〜

  18. © kaonavi Inc. 18 4つのポイント

  19. © kaonavi Inc. from DEVELOPEREXPERIENCE.IO 19

  20. © kaonavi Inc. DEVELOPEREXPERIENCE.IO? 20

  21. © kaonavi Inc. DEVELOPEREXPERIENCE.IO? 21 https://developerexperience.io/practices/good-developer-experience

  22. © kaonavi Inc. 素晴らしいDXを実現する4つの要素 22 アーキテクチャ ツール プロセス チーム カルチャー

  23. © kaonavi Inc. 素晴らしいDXを実現する4つの要素 23 アーキテクチャ ツール プロセス チーム カルチャー

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

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

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

    カルチャーは開発者にインストールされ、最 も重要な判断軸となる 優れたDXのチームカルチャー • チームや会社の存在意義を理解 • チームや会社に対して オーナーシップと責任感を持つ • チームや会社で共通のゴールがある • 優しさと誠実さを持つ • 失敗を許容できる
  27. © kaonavi Inc. 27 アーキテクチャ ツール プロセス いずれもDX向上には欠かせない チーム カルチャー

  28. © kaonavi Inc. 28 アーキテクチャ ツール プロセス DX向上の促進にはチームカルチャーが重要! チーム カルチャー

  29. © kaonavi Inc. 29 © kaonavi Inc. チームカルチャーを作り上げながら DX向上に取り組み中

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

  31. © kaonavi Inc. 31 カオナビが取り組む DXの4つのポイント 〜DX向上を促進するカルチャーを         どのように醸成してきたか〜

  32. © kaonavi Inc. カオナビの エンジニア組織の歴史 32

  33. © 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 マザーズ上場
  34. © 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 黎明期 サービス リプレース 急速な 組織化
  35. © 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中心の開発 エンジニアが 徐々に増加 職能別組織へ エンジニア人数 エンジニアが急増 チーム開発へ
  36. © kaonavi Inc. 36 詳しくはXP祭り2020の資料で https://speakerdeck.com/kaonavi/kaonabifalsekaizensutori-douyatuteaziyairunakai-fa-zu-zhi-wozuo-rishang-getafalseka

  37. © kaonavi Inc. 急成長してきたカオナビが、 どのようにDX向上を促進してきたか 37

  38. © kaonavi Inc. チーム カルチャー 38 アーキテクチャ ツール プロセス

  39. © kaonavi Inc. システムリプレース後のアーキテクチャ 39 • 開発効率を最優先にしたアーキテクチャ フロントエンド バックエンド インフラ

  40. © kaonavi Inc. • 最適なアーキテクチャも、対策せずに運用を続ければ最適ではなくなる ◦ 技術スタックの陳腐化 ◦ 属人化 ◦

    スパゲッティコード システムリプレース後のアーキテクチャ 40 開発スピードの低下 組織が拡大してもスケールできない
  41. © kaonavi Inc. 攻めのカイゼン 41 • 最新技術への取り組み フロントエンド バックエンド インフラ

  42. © kaonavi Inc. 守りのカイゼン • PHP, Laravelの継続的なバージョンアップ • 着実なリファクタリング •

    Clean Architectureの導入 • AWS Well-Architectedに沿う構成へアーキテクチャを見直し https://aws.amazon.com/jp/solutions/case-studies/kaonavi/ • マイクロサービス化の推進
  43. © kaonavi Inc. 43 アーキテクチャ ツール プロセス チーム カルチャー

  44. © kaonavi Inc. GitLabによる自動化 44 • 単体テスト、E2Eテスト • セキュリティチェック •

    コーディング規約チェック • Swaggerカバレッジ計測 • ビルド • デプロイ
  45. © kaonavi Inc. Slackによる自動化 45 • GitLab連携 ◦ コードレビューの依頼を自動化 ◦

    テストやビルドエラーの通知
  46. © kaonavi Inc. Slackによる自動化 46 • ワークフロー機能でオンボーディング支援を自動化 ◦ Slackの設定や推奨チャンネル紹介 ◦

    Confluenceの設定、利用説明 ◦ GitLabの個人設定 ◦ ローカル開発環境の構築 ◦ 開発ルール説明 ◦ 開発フォロー
  47. © kaonavi Inc. インフラの自動化 47 • CloudFormationやTerraformで環境を自動作成 • CodePipelineでデプロイを自動化

  48. © kaonavi Inc. 48 アーキテクチャ ツール プロセス チーム カルチャー

  49. © kaonavi Inc. システムリプレース後の開発プロセス 49 • 職能別組織による開発 ◦ 生産性も向上 PM/企画職

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

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

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

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

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

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

    リリース回数、リバート数、デプロイ成功率などの指標で常にカイゼン Operation グループ リリース依頼 ◦◦チーム リリース 対象リスト リリース
  56. © kaonavi Inc. 安定運用のためのリリースプロセス 56 • ポストモーテム運用 ◦ 失敗に対するふりかえり、学習、再発防止活動 ◦

    実施対象 ▪ 一定深刻度以上のインシデント ▪ リリース後の巻き戻し
  57. © kaonavi Inc. 57 アーキテクチャ ツール プロセス チーム カルチャー

  58. © kaonavi Inc. 良いチームカルチャーは 良い会社のカルチャーから始まる 58

  59. © kaonavi Inc. カオナビのカルチャー 59

  60. © kaonavi Inc. カオナビのカルチャー 60 相互選択 POLICY 従業員と会社が選び選ばれる対等な関係

  61. © kaonavi Inc. カオナビのカルチャー 仮説思考 VALUE 相手の言葉を鵜呑みにせず、その背景や理由を考えること 1 仕組み化 自分ができるコトを、他の人でもできるようにすること

    2 シンプル 必要なものを見極め、捨てる重要性を知ること 3
  62. © kaonavi Inc. カオナビのカルチャー 62 MY WORK STYLE ハイブリッドワーク 働く場所を選択可能(出社

    or 自宅 or 許可された就業スペース) スーパーフレックス制度 フレックスタイム内の任意の時間帯で勤務 ※ 1日4時間以上の勤務、月の所定労働時間あり スイッチワーク制度 連続して勤務できない場合も、時間を細切れにして働ける制度 1 2 3 兼業推奨 異なるフィールドでの経験がカオナビでの活躍にもつながるという考え 4
  63. © kaonavi Inc. カオナビのカルチャー 63 NEW OFFICE 「仕事をしにいく場所」ではなく、 「カオナビのサービスや思想に共感する人たちが集まる場所」としての空間

  64. © kaonavi Inc. エンジニア組織のカルチャー 64

  65. © kaonavi Inc. • Slackはほとんどオープンチャンネル、透明性を大事に • 助け合いの文化 ◦ 分報やチャンネルへ投稿するといろんな人が助けてくれる •

    プロダクトアウトの考え方が定着 • ボトムアップで判断 ◦ 現場が自ら考え、主体的に行動 • 仮説思考でロジカルに考える • 限られた時間内できちんと成果を出す ◦ 1日あたりの残業時間はわずか4分 雰囲気・マインド 65 エンジニアがよく使う Slackの絵文字たち
  66. © kaonavi Inc. • 全社スプリントレビュー(毎週) ◦ 全社で参加者を募って行うスプリントレビュー ◦ 各チームの成果物を共有し、営業・事業戦略・サポートチームなどから多角的な フィードバックが得られる場

    ◦ 多い時には100人以上集まるときも! 組織的な取り組み 66
  67. © kaonavi Inc. • エンジニア分科会(毎週) ◦ 参加はテックリード + CTO ◦

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

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

    CTO ◦ プロダクトにおけるあらゆるリスクを共有し、問題が顕在化する前に 対策を行うためのミーティング 組織的な取り組み 69
  70. © kaonavi Inc. 組織的な取り組み 70 • エンジニア勉強会(隔週) ◦ 横断的に知見を共有、属人化解消やエンジニアの成長を促す ◦

    開催回数は47回、発表回数は151回(2021年4月10日時点)
  71. © kaonavi Inc. エンジニア組織のカルチャーを どのように醸成してきたか 71

  72. © 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中心の開発 エンジニアが 徐々に増加 職能別組織へ エンジニア人数 エンジニアが急増 チーム開発へ
  73. © kaonavi Inc. エンジニア 組織なし 混乱期 Storming 形成期 Forming タックマンモデルで見るエンジニア組織

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

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

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

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

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

    期日コミットがゴールに ◦ 仕様変更への対応が鈍化 ◦ 意思疎通不全 アジャイルソフトウェア 開発宣言と真逆状態に プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、
  79. © kaonavi Inc. ここからのカイゼンの動きが いまのカルチャーを醸成 79

  80. © kaonavi Inc. 3つのカイゼン 80 開発体制のカイゼン 開発プロセスのカイゼン 開発マインドのカイゼン

  81. © kaonavi Inc. 3つのカイゼン 81 開発体制のカイゼン 開発プロセスのカイゼン 開発マインドのカイゼン

  82. © kaonavi Inc. • 組織をミッションベースのグループに変更し、グループ内でチーム開発 職能別組織からチームによる開発へ 82 PM/企画職 グループ エンジニア

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

    自分の仕事が終わるかどうか 企画職と開発者のコミュニケーション不足 認識のズレ Whyを理解した上で開発 自分たちで成し遂げる仕事 チームで成果を出す チームとしての仕事が終わるかどうか 疑問・相談は直接その場で速攻で 同じ質で同じ情報量
  84. © kaonavi Inc. 権限の移譲 84 • 権限と同時に責任を移譲し、トップダウン型から自立型の組織へ マネージャー リーダー メンバー

    マネージャー リーダー
  85. © kaonavi Inc. 専門的なポジション 85 • EMやテックリードなどを用意 ◦ メンバーのスキルマネジメントや文化醸成など専門知識が必要な場面に対して 責任を持つ

    EM/TL リーダー メンバー
  86. © kaonavi Inc. ポイント 86 • トップダウンとボトムアップの使い分け チーム 組織 組織構造といった大きな変化は

    トップダウンで 現場のカイゼンは ボトムアップで
  87. © kaonavi Inc. 3つのカイゼン 87 開発体制のカイゼン 開発プロセスのカイゼン 開発マインドのカイゼン

  88. © kaonavi Inc. スクラムの導入 88 • 最適化されていない開発プロセス • 不確実性との付き合い方 スクラムの導入

  89. © kaonavi Inc. スクラムの導入 89 • 最初は原理主義に走りうまくいかず スクラムの導入 スクラムの実践と学習

  90. © kaonavi Inc. • やがて開発プロセスに変化が起こり、アジャイルな考え方が組織に浸透 スクラムの導入 90 プロジェクトの終盤まで不確実性が残る スケジュールもスコープも変えられない …?

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

  92. © kaonavi Inc. 3つのカイゼン 92 開発体制のカイゼン 開発プロセスのカイゼン 開発マインドのカイゼン

  93. © kaonavi Inc. 土壌づくり 93 技術課題の一覧可視化 テックリードによるサポート ナレッジ共有の場としての エンジニア勉強会 週に2時間の

    技術品質カイゼン推奨 ボトムアップでの 技術選定
  94. © kaonavi Inc. ポイント 94 技術革新は エンジニアの 好奇心から生まれる 技術的カイゼンの 種を育むための

    環境と文化 小さく試す 実験を繰り返す
  95. © kaonavi Inc. 3つのカイゼン 95 開発体制のカイゼン 開発プロセスのカイゼン 開発マインドのカイゼン

  96. © kaonavi Inc. こうしたカイゼンの動きが いまのカルチャーを作り上げた 96

  97. © kaonavi Inc. エンジニア 組織なし 混乱期 Storming 形成期 Forming タックマンモデルで見るエンジニア組織

    97 2013/3 2014/3 2015/3 2016/3 2017/3 2018/3 2019/3 2020/3 2021/3 統一期 Norming エンジニア人数 成果
  98. © kaonavi Inc. さらなる取り組み 98

  99. © kaonavi Inc. ライブラリアン 99 情報に秩序をもたらし、 情報を減らし、 情報を整理し、 情報をコントロールする。

  100. © kaonavi Inc. エキスパートの配置 100 サービスリード エキスパート マネージメント テックリード 専門性

    管理・育成 ドメイン 一般 歴史、ドメイン、コア概念の 全体的ボトムアップを図る 環境や仕組みを整え メンバーの能力を最大化 プロダクトの課題解決を エキスパートとして導く 生産性の最大化のために メンバーを強化
  101. © kaonavi Inc. 生産性向上 101 • 生産性向上を専門的に行うグループ Productivity Group

  102. © kaonavi Inc. スキルアップの促進 102 • 忙しいときほどゆとり時間が大事 サバイバルモード 学習モード 自己組織化モード

    • 学ぶ時間がない • 定期的に火消し作業 • 遅れと残業 • 十分なゆとり時間 • スキルの習得時間がある • 誤りを許容する • チームにスキルがある • 自分たちで意思決定できる • 衝突を内部解決できる • ゆとり時間を作る • 残業を減らす • 見積もりし直す • チーム自身で 自分たちの問題を解決 できるように教える
  103. © kaonavi Inc. スキルアップの促進 103 • スナバ(週2H) ◦ 将来的に事業貢献・プロダクト改善に繋がる可能性がある、あらゆる活動を自由 に行える時間(活動報告不要)

    ◦ 未来の自分、未来の誰かのために、ゆとり時間を用意する制度
  104. © kaonavi Inc. スキルアップの促進 104 • イドバタ(不定期) ◦ 業務時間外に開催する勉強会などの活動 ◦

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

  106. © kaonavi Inc. 106 アーキテクチャ ツール プロセス 4つのポイントが大事 チーム カルチャー

  107. © kaonavi Inc. 107 アーキテクチャ ツール プロセス チーム カルチャー DX向上の促進にはチームカルチャーが重要!

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

  109. © kaonavi Inc. 109 カオナビが取り組む DXの4つのポイント 〜DX向上を促進するカルチャーを         どのように醸成してきたか〜

  110. © kaonavi Inc. 少しでもカオナビに 興味を持ってくださった方、 110 各ポジション募集中!!! https://corp.kaonavi.jp/recruit/list.html