Tweet
Tweet

Slide 1

Slide 1 text

© kaonavi Inc. Developer eXperience Day CTO/VPoE Conference 2021 いまさら聞けない DXの4つのポイント 〜DX向上を促進するカルチャーとは〜 株式会社カオナビ CTO 松下雅和 2021/04/10

Slide 2

Slide 2 text

© kaonavi Inc. 自己紹介 2 ● 松下 雅和 / @matsukaz ● 株式会社カオナビ CTO（2020年2月入社、2020年9月就任） SIer2社 → サイバーエージェント → トランスリミット CTO ● AWS, Node.js, Ruby, Python, PHP, Go ● カメラ, 自転車（BD-1）, テニス, 卓球, ボウリング ● 二児の姉妹の父

Slide 3

Slide 3 text

© kaonavi Inc. 3 © kaonavi Inc.

Slide 4

Slide 4 text

© kaonavi Inc. 4 © kaonavi Inc.

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

© kaonavi Inc. DX 6

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

© 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

Slide 11

Slide 11 text

© kaonavi Inc. DX = Developer eXperience 11 API 顧客 システム UX = User eXperience UI ユーザ 開発者 開発者 開発者

Slide 12

Slide 12 text

© kaonavi Inc. プロダクトを利用する開発者と プロダクトを開発する開発者、 両方を対象にした概念も 12 https://developerexperience.io/practices/good-developer-experience ■ [DEVELOPEREXPERIENCE.IO] Good Developer Experience API 顧客 システム 開発者 開発者

Slide 13

Slide 13 text

© kaonavi Inc. CTO協会の定義は？ 13

Slide 14

Slide 14 text

© kaonavi Inc. 14 https://cto-a.github.io/dxcriteria/ ■ [DX Criteria] 「２つのDX」とデジタル経営のガイドライン 開発者にとっての働きやすい環境と高速な開発を 実現するための文化・組織・システムが実現されているかを 意味する開発者体験(Developer eXperience) API 顧客 システム 開発者 開発者

Slide 15

Slide 15 text

© kaonavi Inc. 15 API 顧客 システム 開発者 開発者 それぞれ概念が違う 初期の概念 CTO協会 DEVELOPEREXPERIENCE.IO

Slide 16

Slide 16 text

© kaonavi Inc. 今日話すのは CTO協会が定義するDX （2つのDXのうちDeveloper eXperienceのみ） 16 API 顧客 システム 開発者 開発者

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

© kaonavi Inc. from DEVELOPEREXPERIENCE.IO 19

Slide 20

Slide 20 text

© kaonavi Inc. DEVELOPEREXPERIENCE.IO？ 20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

© kaonavi Inc. 27 アーキテクチャ ツール プロセス いずれもDX向上には欠かせない チーム カルチャー

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

© 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 マザーズ上場

Slide 34

Slide 34 text

© 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 黎明期 サービス リプレース 急速な 組織化

Slide 35

Slide 35 text

© 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中心の開発 エンジニアが 徐々に増加 職能別組織へ エンジニア人数 エンジニアが急増 チーム開発へ

Slide 36

Slide 36 text

© kaonavi Inc. 36 詳しくはXP祭り2020の資料で https://speakerdeck.com/kaonavi/kaonabifalsekaizensutori-douyatuteaziyairunakai-fa-zu-zhi-wozuo-rishang-getafalseka

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

© kaonavi Inc. ● 最適なアーキテクチャも、対策せずに運用を続ければ最適ではなくなる ○ 技術スタックの陳腐化 ○ 属人化 ○ スパゲッティコード システムリプレース後のアーキテクチャ 40 開発スピードの低下 組織が拡大してもスケールできない

Slide 41

Slide 41 text

© kaonavi Inc. 攻めのカイゼン 41 ● 最新技術への取り組み フロントエンド バックエンド インフラ

Slide 42

Slide 42 text

© kaonavi Inc. 守りのカイゼン ● PHP, Laravelの継続的なバージョンアップ ● 着実なリファクタリング ● Clean Architectureの導入 ● AWS Well-Architectedに沿う構成へアーキテクチャを見直し https://aws.amazon.com/jp/solutions/case-studies/kaonavi/ ● マイクロサービス化の推進

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

© kaonavi Inc. GitLabによる自動化 44 ● 単体テスト、E2Eテスト ● セキュリティチェック ● コーディング規約チェック ● Swaggerカバレッジ計測 ● ビルド ● デプロイ

Slide 45

Slide 45 text

© kaonavi Inc. Slackによる自動化 45 ● GitLab連携 ○ コードレビューの依頼を自動化 ○ テストやビルドエラーの通知

Slide 46

Slide 46 text

© kaonavi Inc. Slackによる自動化 46 ● ワークフロー機能でオンボーディング支援を自動化 ○ Slackの設定や推奨チャンネル紹介 ○ Confluenceの設定、利用説明 ○ GitLabの個人設定 ○ ローカル開発環境の構築 ○ 開発ルール説明 ○ 開発フォロー

Slide 47

Slide 47 text

© kaonavi Inc. インフラの自動化 47 ● CloudFormationやTerraformで環境を自動作成 ● CodePipelineでデプロイを自動化

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

© kaonavi Inc. システムリプレース後の開発プロセス 49 ● 職能別組織による開発 ○ 生産性も向上 PM/企画職 グループ エンジニア グループ QA グループ 仕様作成 リリースコントロール 実装 品質保証 リリース Operation グループ

Slide 50

Slide 50 text

© kaonavi Inc. システムリプレース後の開発プロセス 50 ● ところが、組織が大きくなるにつれてセクショナリズムが深刻化 ○ 仕様書の読み込みが大変 ○ 期日コミットがゴールに ○ 仕様変更への対応が鈍化 ○ 意思疎通不全 アジャイルソフトウェア 開発宣言と真逆状態に プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

Slide 51

Slide 51 text

© kaonavi Inc. ● 組織をミッションベースのグループに変更し、グループ内でチーム開発 職能別組織からチームによる開発へ 51 PM/企画職 グループ エンジニア グループ ミッションベース グループ ○○チーム ○○チーム リリースまでの 全行程に責任 QA グループ チーム内は QA→QCへ リリース 依頼 リリースまでの 全行程に責任 Operation グループ Operation グループ

Slide 52

Slide 52 text

© kaonavi Inc. チームごとに開発プロセスを選択 52 ● 開発規模が大きいチームの多くはスクラム開発 ● 少人数体制の改善／保守タスクはRedmineのチケット駆動開発 デイリースクラム バックログリファインメント スプリント レビュー レトロ スペクティブ プランニング1 プランニング2 開発 スクラム イベント スプリント

Slide 53

Slide 53 text

© kaonavi Inc. 安定運用のためのリリースプロセス 53 ● 品質管理（Quality Control） ○ チーム開発の場合は専任のQCメンバーを配置 ■ 品質の重要性をチーム内で啓蒙 ■ アジャイルテストの取り組み リリース（テスト）計画更新 リグレッションテスト 受け入れ条件 チェック テストケース 設計＆作成 テスト実施 テストレベル 定義 テスト観点 テスト見積り レポート テストケース レビュー アジャイル テスト スプリント

Slide 54

Slide 54 text

© kaonavi Inc. レビューマスター 安定運用のためのリリースプロセス 54 ● コードレビュー体制 ○ フロントエンドやバックエンドなど、 領域ごとの担当者（レビューマスター）を複数人配置 ○ チーム内レビューも徐々に展開 レビュー 依頼 フロントエンド バックエンド レビュー依頼 ○○チーム ○○チーム

Slide 55

Slide 55 text

© kaonavi Inc. 安定運用のためのリリースプロセス 55 ● 安定のリリース体制 ○ Operationグループによるスケジュール管理されたリリースプロセス ○ リリース回数、リバート数、デプロイ成功率などの指標で常にカイゼン Operation グループ リリース依頼 ○○チーム リリース 対象リスト リリース

Slide 56

Slide 56 text

© kaonavi Inc. 安定運用のためのリリースプロセス 56 ● ポストモーテム運用 ○ 失敗に対するふりかえり、学習、再発防止活動 ○ 実施対象 ■ 一定深刻度以上のインシデント ■ リリース後の巻き戻し

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

© kaonavi Inc. カオナビのカルチャー 仮説思考 VALUE 相手の言葉を鵜呑みにせず、その背景や理由を考えること 1 仕組み化 自分ができるコトを、他の人でもできるようにすること 2 シンプル 必要なものを見極め、捨てる重要性を知ること 3

Slide 62

Slide 62 text

© kaonavi Inc. カオナビのカルチャー 62 MY WORK STYLE ハイブリッドワーク 働く場所を選択可能（出社 or 自宅 or 許可された就業スペース） スーパーフレックス制度 フレックスタイム内の任意の時間帯で勤務 ※ 1日4時間以上の勤務、月の所定労働時間あり スイッチワーク制度 連続して勤務できない場合も、時間を細切れにして働ける制度 1 2 3 兼業推奨 異なるフィールドでの経験がカオナビでの活躍にもつながるという考え 4

Slide 63

Slide 63 text

© kaonavi Inc. カオナビのカルチャー 63 NEW OFFICE 「仕事をしにいく場所」ではなく、 「カオナビのサービスや思想に共感する人たちが集まる場所」としての空間

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

© kaonavi Inc. ● Slackはほとんどオープンチャンネル、透明性を大事に ● 助け合いの文化 ○ 分報やチャンネルへ投稿するといろんな人が助けてくれる ● プロダクトアウトの考え方が定着 ● ボトムアップで判断 ○ 現場が自ら考え、主体的に行動 ● 仮説思考でロジカルに考える ● 限られた時間内できちんと成果を出す ○ 1日あたりの残業時間はわずか4分 雰囲気・マインド 65 エンジニアがよく使う Slackの絵文字たち

Slide 66

Slide 66 text

© kaonavi Inc. ● 全社スプリントレビュー（毎週） ○ 全社で参加者を募って行うスプリントレビュー ○ 各チームの成果物を共有し、営業・事業戦略・サポートチームなどから多角的な フィードバックが得られる場 ○ 多い時には100人以上集まるときも！ 組織的な取り組み 66

Slide 67

Slide 67 text

© kaonavi Inc. ● エンジニア分科会（毎週） ○ 参加はテックリード ＋ CTO ○ 議題により他のメンバーも任意参加 ○ プロダクトにおける技術的な課題の解決や方針を決める場 組織的な取り組み 67

Slide 68

Slide 68 text

© kaonavi Inc. 組織的な取り組み 68 ● エンジニア定例ミーティング（毎週） ○ 原則として全エンジニア参加 ○ 技術課題や開発方針、各チームの開発状況を共有する場 ■ 解決したい課題が出てきた場合は、エンジニア分科会に持ち込む

Slide 69

Slide 69 text

© kaonavi Inc. ● リスク管理ミーティング（毎週） ○ 参加はマネージャー ＋ QC責任者 ＋ CTO ○ プロダクトにおけるあらゆるリスクを共有し、問題が顕在化する前に 対策を行うためのミーティング 組織的な取り組み 69

Slide 70

Slide 70 text

© kaonavi Inc. 組織的な取り組み 70 ● エンジニア勉強会（隔週） ○ 横断的に知見を共有、属人化解消やエンジニアの成長を促す ○ 開催回数は47回、発表回数は151回（2021年4月10日時点）

Slide 71

Slide 71 text

© kaonavi Inc. エンジニア組織のカルチャーを どのように醸成してきたか 71

Slide 72

Slide 72 text

© 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中心の開発 エンジニアが 徐々に増加 職能別組織へ エンジニア人数 エンジニアが急増 チーム開発へ

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

© kaonavi Inc. ● SES中心の開発 ● 売上重視 ● 技術負債の蓄積 ● 運用もだんだんと不安定に… 2015年 75 サービスリプレース開始

Slide 76

Slide 76 text

© kaonavi Inc. ● 現行バージョンへの移行完了 ● エンジニア組織ができあがり、組織体制の強化へ ● 職能別組織で安定化、生産性も向上 2017年 76 PM/企画職 グループ エンジニア グループ QA グループ 仕様作成 リリースコントロール 実装 品質保証 リリース Operation グループ

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

© kaonavi Inc. 2019年 78 ● やがてセクショナリズムが深刻化 ○ 仕様書の読み込みが大変 ○ 期日コミットがゴールに ○ 仕様変更への対応が鈍化 ○ 意思疎通不全 アジャイルソフトウェア 開発宣言と真逆状態に プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも 動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

Slide 79

Slide 79 text

© kaonavi Inc. ここからのカイゼンの動きが いまのカルチャーを醸成 79

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

© kaonavi Inc. ● 組織をミッションベースのグループに変更し、グループ内でチーム開発 職能別組織からチームによる開発へ 82 PM/企画職 グループ エンジニア グループ ミッションベース グループ ○○チーム ○○チーム リリースまでの 全行程に責任 QA グループ QA→QCへ リリース 依頼 リリースまでの 全行程に責任 Operation グループ Operation グループ

Slide 83

Slide 83 text

© kaonavi Inc. ● チーム開発で生じた変化 職能別組織からチームによる開発へ 83 何のために開発しているのか分からない やらされ仕事 個人で成果を出す 自分の仕事が終わるかどうか 企画職と開発者のコミュニケーション不足 認識のズレ Whyを理解した上で開発 自分たちで成し遂げる仕事 チームで成果を出す チームとしての仕事が終わるかどうか 疑問・相談は直接その場で速攻で 同じ質で同じ情報量

Slide 84

Slide 84 text

© kaonavi Inc. 権限の移譲 84 ● 権限と同時に責任を移譲し、トップダウン型から自立型の組織へ マネージャー リーダー メンバー マネージャー リーダー

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

© kaonavi Inc. ポイント 86 ● トップダウンとボトムアップの使い分け チーム 組織 組織構造といった大きな変化は トップダウンで 現場のカイゼンは ボトムアップで

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

© kaonavi Inc. ● やがて開発プロセスに変化が起こり、アジャイルな考え方が組織に浸透 スクラムの導入 90 プロジェクトの終盤まで不確実性が残る スケジュールもスコープも変えられない …？ QAは他のグループがやるもの 手を動かすまで開発の難易度は分からない プロジェクトが終わってからのふりかえり 全て開発し終わるまでリリースできない アジャイルな見積もりと計画の実践 自分たちでプロジェクトのハンドルを握る チームで完結できるようコラボレーション プラニングが終了時点で把握、対策を打つ 毎スプリント小さなカイゼンを試す α、βリリースでフィードバックループを回す

Slide 91

Slide 91 text

© kaonavi Inc. ポイント 91 分析 仲間 根気

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

© kaonavi Inc. ポイント 94 技術革新は エンジニアの 好奇心から生まれる 技術的カイゼンの 種を育むための 環境と文化 小さく試す 実験を繰り返す

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

© kaonavi Inc. さらなる取り組み 98

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

© kaonavi Inc. エキスパートの配置 100 サービスリード エキスパート マネージメント テックリード 専門性 管理・育成 ドメイン 一般 歴史、ドメイン、コア概念の 全体的ボトムアップを図る 環境や仕組みを整え メンバーの能力を最大化 プロダクトの課題解決を エキスパートとして導く 生産性の最大化のために メンバーを強化

Slide 101

Slide 101 text

© kaonavi Inc. 生産性向上 101 ● 生産性向上を専門的に行うグループ Productivity Group

Slide 102

Slide 102 text

© kaonavi Inc. スキルアップの促進 102 ● 忙しいときほどゆとり時間が大事 サバイバルモード 学習モード 自己組織化モード ● 学ぶ時間がない ● 定期的に火消し作業 ● 遅れと残業 ● 十分なゆとり時間 ● スキルの習得時間がある ● 誤りを許容する ● チームにスキルがある ● 自分たちで意思決定できる ● 衝突を内部解決できる ● ゆとり時間を作る ● 残業を減らす ● 見積もりし直す ● チーム自身で 自分たちの問題を解決 できるように教える

Slide 103

Slide 103 text

© kaonavi Inc. スキルアップの促進 103 ● スナバ（週2H） ○ 将来的に事業貢献・プロダクト改善に繋がる可能性がある、あらゆる活動を自由 に行える時間（活動報告不要） ○ 未来の自分、未来の誰かのために、ゆとり時間を用意する制度

Slide 104

Slide 104 text

© kaonavi Inc. スキルアップの促進 104 ● イドバタ（不定期） ○ 業務時間外に開催する勉強会などの活動 ○ CTOやEMが積極的に場を用意 ○ 社外の人を巻き込んでやることも検討中 ○ 第1回 あなたのターニングポイントは？〜私、その時に覚醒しました〜 ■ 登壇者5名（各10分〜15分） ■ 参加者30名以上

Slide 105

Slide 105 text

© kaonavi Inc. まとめ 105

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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