組織づくりをエンジニアリングする / Engineering Organizational Development

by tbpgr

Slide 1

Slide 1 text

#devsumi  2023年2月10日  てぃーびー（@tbpgr）  組織づくりを  エンジニアリングする  1 ～組織づくりにエンジニアの手法を転用する～  

Slide 2

Slide 2 text

自己紹介  ● てぃーびー（TaBei Katsuhiko）  ○ Employee eXperience Engineer  ● 個人のミッション  ○ 人が成長し、充実して働ける場を作る   ● 所属  ○ クラスメソッド株式会社（2021年11月入社）   ○ エンジニアリング統括室室長   ■ ミッション - 開発者の従業員体験向上   ○ 全社人事業務を兼任   ○ https://dev.classmethod.jp/author/tb/   ● Twitter  ○ @tbpgr  ● e-Book  ○ Zenn Book - ITエンジニア採用入門   ■ https://zenn.dev/tbpgr/books/214cd4a0052a92   ● 経歴  ○ 2001年～2019年 - ウェブエンジニア   ○ 2019年～現在 - 人事、組織領域   2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

3年間、人事業務をして感じていること  未経験から人事領域にきたが、  すんなりとキャッチアップできた  4

Slide 5

Slide 5 text

3年間、人事業務をして感じていること  5 エンジニア採用について実際に取り組んだ内容  ● 開発採用チームの立ち上げ  ● 組織が求める人材像の明確化  ● 求人票の明確化  ● ペルソナの作成  ● 訴求要素の明確化  ● 選考の質向上  当時のブログ記事「Recruiting Operations のお仕事 Part 1 - 質向上編」  https://tbpgr.hatenablog.com/entry/studist-advent-2019-1 

Slide 6

Slide 6 text

3年間、人事業務をして感じていること  6 エンジニア採用  ソフトウェア開発  ● 現状を整理した ● 実装が必要な対象を整理した  ● 優先順に並べた ● 優先順に並べた  ● 一つずつ順に対応した ● 一つずつ順に対応した  ○ 完了の定義を定めた ○ テストを実装した  ○ 解決方法を調べた ○ 実装方法を調べた  ○ 解決策を実施した ○ 実装した  ○ 完了の定義を満たした   ○ テストを通した 

Slide 7

Slide 7 text

3年間、人事業務をして感じていること  あれ？エンジニアのときとあまり変わらないぞ  7

Slide 8

Slide 8 text

3年間、人事業務をして感じていること  「採用の改善」に役立つ情報を「ITエンジニア採用入門」のZennBookで公開したら大きな反響があった  ● ZennBook 1,002 likes (2023/01/22時点)  ● はてなブックマーク 1,959 users (2023/01/22時点)  8

Slide 9

Slide 9 text

3年間、人事業務をして感じていること  エンジニアの手法を組織づくりに転用する価値を実感した  9

Slide 10

Slide 10 text

3年間、人事業務をして感じていること  エンジニアの手法の転用の例  10

Slide 11

Slide 11 text

3年間、人事業務をして感じていること  11 エンジニア採用  ソフトウェア開発  求人要件定義 - 求人の分割  責務の分割  求人票 - 求人票のレビュー成果物のレビュー  選考 - マッチング・インタビュー  期待値の明確化 

Slide 12

Slide 12 text

エンジニアの世界は優れた手法の宝庫  ● 情報共有  ● タスク管理  ● ペアプログラミング  ● モブプログラミング  ● ふりかえり  ● 妥当性確認(Validation)  ● 検証(Verification)  ● 継続的インテグレーション  ● バージョン管理  ● モニタリング  ● リファクタリング  12

Slide 13

Slide 13 text

具体と抽象  エンジニアにとって具体と抽象の扱いは日常  ● Extract Method - メソッドの抽出  ● Composed Method - メソッド内の各処理の抽象度を揃える  13

Slide 14

Slide 14 text

具体と抽象。そして概念化  具体的な対象を抽象化し、概念化できれば、広く転用できるようになる  同じことを繰り返したくない  繰り返しを減らしたい  DRY原則抽象化  転用  Don’t Repeat Yourself Principle  同じことを繰り返さないようにする  14

Slide 15

Slide 15 text

優れた手法を概念化  ● 情報共有  ● タスク管理  ● ペアプログラミング  ● モブプログラミング  ● ふりかえり  ● 妥当性確認(Validation)  ● 検証(Verification)  ● 継続的インテグレーション  ● バージョン管理  ● モニタリング  ● リファクタリング  組織づくりの領域に転用  概念化  15

Slide 16

Slide 16 text

持ち帰ってもらいたいこと  エンジニアの手法を組織づくりに転用する例を知ること。  そして、皆さんの現場でエンジニアの手法を組織づくりに転用してもらうこと  16

Slide 17

Slide 17 text

目次  ● エンジニアの考え方 - 三大美徳💻  ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻  ● エンジニアの手法で組織課題を解決 - 短気🏢💻  ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻  ● 組織づくりにエンジニアの手法を転用する📡  17

Slide 18

Slide 18 text

目次  ● エンジニアの考え方 - 三大美徳💻  ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻  ● エンジニアの手法で組織課題を解決 - 短気🏢💻  ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻  ● 組織づくりにエンジニアの手法を転用する📡  18

Slide 19

Slide 19 text

エンジニアの考え方 - プログラマーの三大美徳💻  ● 怠惰 - Laziness  ● 短気 - Impatience  ● 傲慢 - Hubris  19

Slide 20

Slide 20 text

💻エンジニアの考え方 - 怠惰 - Laziness  “The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it.”   from C2 Wiki, 「Laziness Impatience Hubris」 - https://wiki.c2.com/?LazinessImpatienceHubris  20 怠惰とは、全体として必要となる労力を減らすためとなれば、  努力を惜しまないような姿勢 

Slide 21

Slide 21 text

エンジニアの考え方 - 怠惰 - Laziness💻  21

Slide 22

Slide 22 text

エンジニアの考え方 - 短気 - Impatience💻  “The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.”   from C2 Wiki, 「Laziness Impatience Hubris」 - https://wiki.c2.com/?LazinessImpatienceHubris  22 短気とは、単に目の前のニーズを満たすだけではなく、  先を見越してプログラミングするような姿勢 

Slide 23

Slide 23 text

エンジニアの考え方 - 短気 - Impatience💻  23

Slide 24

Slide 24 text

エンジニアの考え方 - 傲慢 - Hubris💻  “Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.”  from C2 Wiki, 「Laziness Impatience Hubris」 - https://wiki.c2.com/?LazinessImpatienceHubris  24 傲慢とは、他者に文句を言わせないような質の高い成果物を作るような姿勢 

Slide 25

Slide 25 text

エンジニアの考え方 - 傲慢 - Hubris💻  25

Slide 26

Slide 26 text

目次  ● エンジニアの考え方 - 三大美徳💻  ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻  ● エンジニアの手法で組織課題を解決 - 短気🏢💻  ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻  ● 組織づくりにエンジニアの手法を転用する📡  26

Slide 27

Slide 27 text

組織づくりの考え方 - 怠惰 = 効率化🏢  27 組織づくりにおける怠惰とは、組織全体として必要となる労力を減らすために、協力者を巻き込み、効率化を実現していく努力を惜しまないような姿勢  怠惰とは、全体として必要となる労力を減らすためとなれば、努力を惜しまないような姿勢  エンジニアの考え方💻  組織づくりの考え方🏢 

Slide 28

Slide 28 text

● 良い施策のノウハウが部門内に閉じている  ● 問題解決のノウハウが部門内に閉じている  組織課題 - 効率化に関わる組織課題  28

Slide 29

Slide 29 text

自由と責任。自律と主体性を大切にする社風。  それゆえに、各部内で様々な工夫を独自に実施している。  全社の意思決定を待たずに柔軟に部内の取り組みを実施できる。  反面、良い取り組みが部門をまたいで横展開されにくい。  組織課題 - 効率化に関わる組織課題 - 背景  29

Slide 30

Slide 30 text

ノウハウが広がっている部分もある。  社員同士の交流範囲で偶発的に取り組みが広がる  「お祭り」的な展開がある。  組織課題 - 効率化に関わる組織課題 - 背景  30

Slide 31

Slide 31 text

例 - 評価制度リファレンスもくもく会  評価制度改定に合わせて制度理解のための「評価制度リファレンスもくもく会」が草の根的に1つの部門で実施された。  たまたまそれをみかけた複数の部門が「私たちも」と「評価制度リファレンスもくもく会」を実施した。  組織課題 - 効率化に関わる組織課題 - 背景  31

Slide 32

Slide 32 text

解決策 - 情報共有  32 組織施策に関わるノウハウを全マネージャーに共有する  ● 良い施策を把握し、転用できる  ● 問題解決の方法を把握し、転用できる 

Slide 33

Slide 33 text

具体例 - 組織施策一覧の作成  33 組織施策を共有する一覧を作成した。  施策名  概要  部内課題共有カンバン  部への問題提起、リクエストをかんばんで管理  部門ダッシュボード  部の目標と成果の可視化  マネージャーズMTG  隔週で部長・マネージャー間で部内施策およびメンバー状況等に関する相談・共有を行う  RACI図  RACI図によって部門内の責務を可視化  Welcomeティータイム  入社メンバーとの雑談コミュニケーション 

Slide 34

Slide 34 text

具体例 - 組織施策一覧の作成 - 進め方  34 小さくはじめる  ● 4部門のマネージャーに趣旨を説明  ● 協力を得て、4部門の組織施策を記録 

Slide 35

Slide 35 text

具体例 - 組織施策一覧の作成 - 進め方  35 大きく広げる  ● 組織施策一覧への追加手順を整備  ● 組織施策一覧を全マネージャーに共有 

Slide 36

Slide 36 text

具体例 - 組織施策一覧の作成 - 今後の展開  36 こんなことができたらいいかも？  ● 横展開可能な施策の確認と展開  ● マネージャーが集まる雑談会での情報交換  ● マネージャー同志の1対1での情報交換  ● 社外へのノウハウ開示や未来の同僚に向けたブログ発信 

Slide 37

Slide 37 text

まとめ - エンジニアの手法で組織課題を解決 - 怠惰編  37 ● 課題 - 効率化に関わる組織課題  ○ 良い施策のノウハウが部門内に閉じている  ○ 問題解決のノウハウが部門内に閉じている  ● 解決策 - 情報共有  情報共有の実施 

Slide 38

Slide 38 text

目次  ● エンジニアの考え方 - 三大美徳💻  ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻  ● エンジニアの手法で組織課題を解決 - 短気🏢💻  ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻  ● 組織づくりにエンジニアの手法を転用する📡  38

Slide 39

Slide 39 text

組織づくりの考え方 - 短気 = 先見性🏢  39 組織づくりにおける短気とは、単に目の前の状況に対するニーズを満たすだけではなく、先を見越して仕組み化するような姿勢  短気とは、単に目の前のニーズを満たすだけではなく、先を見越してプログラミングするような姿勢  エンジニアの考え方💻  組織づくりの考え方🏢 

Slide 40

Slide 40 text

組織課題 - 先見性に関わる組織課題  40 ● エンゲージメントセンサスサーベイを半年に1回実施している  ○ 社員のエンゲージメントの確認が半年に1回しかできない  💡エンゲージメントとは「社員が会社に貢献したいという意欲を持っている状態」です。単なる社員満足度とは異なります。   最近話題になっている Developer eXperience では、開発者の社員満足度が取り上げられがちですが、本来重要なのはエンゲージメントです。 

Slide 41

Slide 41 text

解決策 - モニタリング  41 定期的にモニタリングをすることで、定量的な状況把握が可能になる。 

Slide 42

Slide 42 text

月次でエンゲージメントパルスサーベイ（以降EPSと表記）を実施  ● 10問～15問程度の少数の設問のアンケートによってエンゲージメントチェック  ● 設問ごとに5段階でスコアリング  具体例 - エンゲージメントパルスサーベイ  42

Slide 43

Slide 43 text

EPS  独自サーベイの作成  ● 自社の文化を踏まえた設問が作成可能  ● 設問の継続改善が可能  設問の例  ● Q2. 資源 - 仕事を進めるために必要となる資源（人、時間、予算、情報、権限、設備等）が提供されている  ● Q11. 文化「情報発信」 - 社内外への情報発信（ブログ、登壇、ポッドキャスト、動画配信など）を行うことの価値を実感している  43

Slide 44

Slide 44 text

説明スライド - 目的をしっかりと伝える  ● 組織の状態把握  ● 組織の継続改善    EPS - 目的説明 

Slide 45

Slide 45 text

伝えないとどうなるか？  EPS - 目的説明  45

Slide 46

Slide 46 text

サーベイ疲れ(Survey Fatigue)が発生する  ● 目的がわからない  ● 何に使われてるのかわからない  ● 意味があるのかわからない  EPS - 目的説明  46 1回目の  サーベイ実施  回答  用途不明  2回目の  サーベイ実施  回答意欲低下  真剣に  回答しない 

Slide 47

Slide 47 text

EPS - トライアル  トライアル実施  MVP(Minimum Viable Product)での実施  ● 5ヶ月間の実施  ● 2事業部4部門約100名が対象（全社だと約500名）  ● アンケート - Google Form  ● レポート - Google Spreadsheet + Google Docs  47

Slide 48

Slide 48 text

トライアル実施  ● サーベイフィードバックの実施  ○ アンケートの実施  ○ 結果レポートの作成   ○ 結果レポートの共有   ○ 参加部門のマネージャーと協力   ■ 問題選定  ■ 原因特定  ■ 解決策の実施  ■ 改善確認    ※2023年1月から全社への本番導入を開始しました  EPS - トライアル  48 アンケートの実施  問題選定  解決策の実施  改善確認  サーベイフィードバック  

Slide 49

Slide 49 text

EPS - プロセス  49 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 50

Slide 50 text

EPS - プロセス - 異常値の発見  50 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 51

Slide 51 text

EPSにおける異常値の発見  明確な基準を置くかどうか検討中  ● 単月スコア  ● 推移スコア  ● 分析軸 - 部門、職種、入社時期、etc  51

Slide 52

Slide 52 text

EPSにおける異常値の発見  的を絞る  ● 低スコアの項目のうち、どの項目に着目するかを決定する  ○ 単月で比較的スコアが低い設問   ○ 推移で大きく低下している設問   52

Slide 53

Slide 53 text

EPS - プロセス - 原因の特定  53 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 54

Slide 54 text

EPSにおける原因の特定  追加調査  ● EPSの設問は抽象度が高い  ○ Q2. 資源 - 仕事を進めるために必要となる資源（人、時間、予算、情報、権限、設備等）が提供されている  ● 低スコアの原因を特定するためには追加の情報が必要  ○ どの資源が不足しているのか？   ○ なぜ不足しているのか？   54

Slide 55

Slide 55 text

EPSにおける原因の特定  追加調査の方法  ● チームでの対話  ● アンケート  ● インタビュー  55

Slide 56

Slide 56 text

EPSにおける原因の特定  追加調査の方法  ● チームでの対話  ● アンケート  ● インタビュー  56 トライアルでは主にこちらで原因特定を実施

Slide 57

Slide 57 text

EPSにおける原因の特定 - Tips 事実を引き出す  質問のコツ  解釈を確認する質問ではなく、事実を確認する質問をする  ● 解釈質問 - Why  ○ 「なぜ、リソースが足りないのですか？」   ■ 解釈の回答「みんな忙しいからだと思います」   ● 事実質問 - When、Where、Who、What、How  ○ 「具体的に、どの程度リソースが足りないのですが？」   ■ 事実の回答「本来4名必要なプロジェクトを3名で実施しています」   57

Slide 58

Slide 58 text

EPS - モニタリング - 解決策の実施  58 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 59

Slide 59 text

EPSにおける解決策の実施  ● 解決策の立案  ● 解決策の実施  59

Slide 60

Slide 60 text

EPSにおける解決策の実施  解決策の実施に関する具体例  ● 低スコアの設問 - 資源の不足  ● 追加調査の実施 - 追加調査個別インタビュー  ● 原因の特定 - 人の工数の不足。コンテキストスイッチの時間  ● 解決策の立案 - コンテキストスイッチを加味した見積もり  ○ 20%余力を持てるように調整をする  ● 解決策の実施 - 契約の切れ目で段階的に実施  60

Slide 61

Slide 61 text

EPS - モニタリング - 正常化の確認  61 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 62

Slide 62 text

EPSにおける正常化の確認  解決基準の確認  ● 施策の実施時に定めた解決基準を確認する  ● 解決に至っていない場合は、追加調査で原因を把握する  62

Slide 63

Slide 63 text

EPSにおける正常化の確認  EPSのスコアを確認  ● 施策の効果が出る時期に対象の設問に関わるスコアを確認  ● スコアの改善が見受けられない場合は、他の要因の影響が考えられる  63

Slide 64

Slide 64 text

EPSにおける正常化の確認  正常化確認の具体例  ● スコアの確認 - 資源の不足に関する設問のスコアを確認。微増  ● 追加調査の実施 - 見積もり能力の個人差が影響  ● 追加施策の検討 - ペアワーク等、見積もり力を高める取り組み  ● 追加施策の実施  64

Slide 65

Slide 65 text

EPS - モニタリング - ポストモーテム  65 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 66

Slide 66 text

EPSにおけるポストモーテム  ● 解決した対象についてふりかえる  ○ なぜ発生したのか？  ○ 今後、仕組みによって未然に防ぐことは可能か？   ● ふりかえった内容を記録する  ○ 記録した内容を他部門が参考にできる   66 💡トライアル時点でポストモーテムは実施していません 

Slide 67

Slide 67 text

EPSにおけるポストモーテム  ありえそうなパターン  ● ポストモーテム  ○ サーベイ結果 - 最近入社したメンバーの貢献実感のスコアが低い   ○ 原因 - 入社直後に身につけるべきことが身についていないから活躍に至りにくい   ○ 解決策 - 部門特有の入社オンボーディングを整備する   ● 横展開  ○ 問題が発生した部門以外においても、部門特有の入社オンボーディングが十分でない場合は整備する  67

Slide 68

Slide 68 text

まとめ - エンジニアの手法で組織課題を解決 - 短気編  68 ● 課題 - 先見性に関わる組織課題  ○ 社員のエンゲージメントの確認が半年に1回しかできない  ● 解決策 - モニタリング  モニタリングの実施 

Slide 69

Slide 69 text

目次  ● エンジニアの考え方 - 三大美徳💻  ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻  ● エンジニアの手法で組織課題を解決 - 短気🏢💻  ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻  ● 組織づくりにエンジニアの手法を転用する📡  69

Slide 70

Slide 70 text

組織づくりの考え方 - 傲慢 = 品質維持🏢  70 組織づくりにおける傲慢とは、関係者から最終的に満足の声を得られるような質の高い組織施策を行うような姿勢  傲慢とは、他者に文句を言わせないような質の高い成果物を作るような姿勢  エンジニアの考え方💻  組織づくりの考え方🏢 

Slide 71

Slide 71 text

組織課題 - 品質維持に関わる組織課題  71 ● 組織施策の業務の質と効率を高めたい  ○ 組織施策は開発に比べて結果の確認が漏れたり、曖昧になりやすい  ○ 組織施策の実施は少人数で行うことになりやすく、効率を高めたい 

Slide 72

Slide 72 text

解決策 - ふりかえり  72 ふりかえりをすることで  ● よかった点を横展開できる  ● 問題点を解決できる 

Slide 73

Slide 73 text

週次のふりかえりを実施  ● KPTで組織開発業務をふりかえる  ○ 施策の良し悪しをふりかえる   ○ 施策に至る業務の進め方をふりかえる   具体例 - 組織施策のふりかえり  73

Slide 74

Slide 74 text

ふりかえりの運用 - 事前の運用  ● Keep、Problemに追加する内容があれば都度登録しておく  具体例 - 組織施策のふりかえり  74 💡ふりかえりまで1週間の間に対象について忘れてしまうことを防ぐ 

Slide 75

Slide 75 text

ふりかえりの運用 - 当日の運用  ● Keepを登録する - 5分  ● Keepのカテゴライズ + 説明 - 5〜10分  ● Problemを登録する - 5分  ● Problemのカテゴライズ + 説明 - 5〜10分  ● Keepから1件Tryを選ぶ  ● Problemから1件Tryを選ぶ  具体例 - 組織施策のふりかえり  75

Slide 76

Slide 76 text

ポイント  ● 週次で追加する改善対象はMax2件  ○ Keepから1件  ○ Problemから1件  ● むやみにTryを出して改善できないよりは重要なものに絞って着実に改善したほうがいい  具体例 - 組織施策のふりかえり  76

Slide 77

Slide 77 text

1年間のふりかえりからの改善例  ● 2022/04/27 - 月次活動報告  ○ Problem - 何をしている部門か、部外に伝わりきっていない   ○ Try - 月次で活動報告を実施する   ● 2022/09/07 - ドッグフーディングをValueに追加  ○ Keep - 組織施策のドッグフーディングをやってみたが大事。有効   ○ Try - エンジニアリング統括室のValueにドッグフーディングを加える   ● 2022/12/14 - 組織施策紹介データベースを作成し、紹介する  ○ Keep - 自部門の組織施策を他部門に紹介したら役立ててもらえた   ○ Try - 組織施策紹介データベースを作成し、紹介する   具体例 - 組織施策のふりかえり  77 詳しくは以下の記事を参照ください  2022年の1年間、毎週ふりかえりから改善を続けた話〜各月の改善サンプル12件つき〜  https://dev.classmethod.jp/articles/continuous-retrospectives/ 

Slide 78

Slide 78 text

まとめ - エンジニアの手法で組織課題を解決 - 傲慢編  78 ● 課題 - 品質維持に関わる組織課題  ○ 組織施策の業務の質と効率を高めたい  ● 解決策 - ふりかえり  ふりかえりで  継続的な改善 

Slide 79

Slide 79 text

目次  ● エンジニアの考え方 - 三大美徳💻  ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻  ● エンジニアの手法で組織課題を解決 - 短気🏢💻  ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻  ● 組織づくりにエンジニアの手法を転用する📡  79

Slide 80

Slide 80 text

エンジニアの手法の転用 - 情報共有の事例  ● エンジニアの手法 - 開発の情報共有  ● 組織づくりに転用 - 組織施策の情報共有  80 開発の情報共有  組織課題の情報共有 

Slide 81

Slide 81 text

エンジニアの手法の転用 - モニタリングの事例  ● エンジニアの手法 - システムのモニタリング  ● 組織づくりに転用 - エンゲージメントのモニタリング  81 システムのモニタリング  エンゲージメントのモニタリング 

Slide 82

Slide 82 text

エンジニアの手法の転用 - ふりかえりの事例  ● エンジニアの手法 - 開発業務のふりかえり  ● 組織づくりに転用 - 組織施策のふりかえり  82 開発業務のふりかえり  組織施策のふりかえり 

Slide 83

Slide 83 text

組織づくりにエンジニアの手法を転用する - 対象  ● 情報共有  ● タスク管理  ● ペアプログラミング  ● モブプログラミング  ● ふりかえり  ● 妥当性確認(Validation)  ● 検証(Verification)  ● 継続的インテグレーション  ● バージョン管理  ● モニタリング  ● リファクタリング  83 今回はこれらを紹介

Slide 84

Slide 84 text

組織づくりにエンジニアの手法を転用する - 対象  ● 情報共有  ● タスク管理  ● ペアプログラミング  ● モブプログラミング  ● ふりかえり  ● 妥当性確認(Validation)  ● 検証(Verification)  ● 継続的インテグレーション  ● バージョン管理  ● モニタリング  ● リファクタリング  ● ＋α  84 あなたが発見し、  転用できるものもある   

Slide 85

Slide 85 text

組織づくりにエンジニアの手法を転用する  ぜひ、エンジニアの手法を  組織づくりに転用してみてください！  85 あなたが選んだ手法  組織づくりに転用 

Slide 86

Slide 86 text

告知  今回の登壇内容をより詳細に、「怠惰・短気・傲慢」ごとにそれぞれ5パターン・合計15パターンの事例を揃えた ZennBookをAsk the Speaker（Q&Aコーナー）の完了後に公開します。  Twitterの @tbpgr でお知らせいたします。Twitterをしていない方は、 https://zenn.dev/tbpgr?tab=books をご確認ください。  86

Slide 87

Slide 87 text

ありがとうございました！  87

Slide 88

Slide 88 text

Appendix  ● Extract Method - https://refactoring.guru/ja/extract-method   ● Composed Method - https://wiki.c2.com/?ComposedMethod   ● 従業員エンゲージメントサーベイの2種類の実施方法と2種類の作成方法とは？ - https://dev.classmethod.jp/articles/engagement-survey-types/   ● 従業員体験の改善におけるアドホックサーベイとは - https://dev.classmethod.jp/articles/adhoc-survey-for-ex/   ● 意見の裏にある解釈と事実を引き出す - https://tbpgr.hatenablog.com/entry/2020/04/13/005331   ● サーベイフィードバック超入門 - NAKAHARA-LAB.net - http://www.nakahara-lab.net/blog/wp-content/uploads/2020/04/surveyfeedback2020_nakaha ra_presentation.pdf  88