開発の手法を組織へ / Extract Method from Dev to Org

by tbpgr

Slide 1

Slide 1 text

#devlove 2023/01/23 てぃーびー(@tbpgr) 開発の手法を組織へ  ～Extract Method from Dev to Org～  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エンジニア採用入門  ● 経歴  ○ 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 - 質向上編」 

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

エンジニアの手法の例💻 - モニタリング  モニタリングとは、システムの振る舞いや出力をチェックし続けることです。  これにより  ● 正常に稼働しているのか  ● 問題が発生したのか  ● 問題は修復されたのか  などを常に把握し続けることができます。  19

Slide 20

Slide 20 text

エンジニアの手法の例💻 - モニタリング - 設定  ● 監視対象を決める  ● 閾値を決め、アラート基準を設定  20

Slide 21

Slide 21 text

エンジニアの手法の例💻 - モニタリング - プロセス  21  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 22

Slide 22 text

エンジニアの手法の例💻 - モニタリング - 異常値の発見  ● アラート基準を超えた異常値を発見  22 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 23

Slide 23 text

エンジニアの手法の例💻 - モニタリング - 原因の特定  ● 異常値が発生している原因を調査する  ○ 関連情報の確認  ○ 問題の切り分け  ○ 仮説の検証  ● 正常だった場合は対応を完了する  ● 異常だった場合は原因を特定する  23 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 24

Slide 24 text

エンジニアの手法の例💻 - モニタリング - 解決策の実施  ● 原因に対する解決策を実施する  24 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 25

Slide 25 text

エンジニアの手法の例💻 - モニタリング - 正常化の確認  ● 正常値に戻ったことを確認する  25 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 26

Slide 26 text

エンジニアの手法の例💻 - モニタリング - ポストモーテム  ● 事象に対するふりかえりを実施し、文書として記録する  ○ ポストモーテムは「検死解剖」の意味   ● ふりかえりから得た知見をもとに改善を実施する  ○ 閾値の変更  ○ その他の対策の実施   ● 問題が再現しないか確認  26 異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 27

Slide 27 text

目次  ● エンジニアの手法の例💻  ● 組織づくりの手法の例🏢  ● エンジニアの手法の転用📡  27

Slide 28

Slide 28 text

組織づくりの手法の例🏢 - モニタリング  モニタリングは、システムの振る舞いや出力をチェックし続けることです。これを組織づくりにおける「メンバーのモチベーションのチェック」に転用します。  28

Slide 29

Slide 29 text

組織づくりの手法の例🏢 - モニタリング  「メンバーのモチベーションをチェックし続ける」ためのモニタリング方法としてエンゲージメントパルスサーベイ(以降 EEPS)があります。  29 💡エンゲージメントとは「社員が会社に貢献したいという意欲を持っている状態」です。単なる社員満足度とは異なります  

Slide 30

Slide 30 text

組織づくりの手法の例🏢 - モニタリング  EEPSによって  ● メンバーが充実して働いているのか？  ● メンバーがデモチベーションしているのか？  などを常に把握し続けることができます。  30

Slide 31

Slide 31 text

組織づくりの手法の例🏢 - モニタリング - 設定  EEPSの導入  ● 10問～15問程度の少数の設問のアンケートによってエンゲージメントチェック  ● 設問ごとに5段階でスコアリング  ● 月次で実施  31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

伝えないとどうなるか？  EEPSの導入🗳 - 導入目的の説明  34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

組織づくりの手法の例🏢 - モニタリング - プロセス  38  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 39

Slide 39 text

組織づくりの手法の例🏢 - モニタリング - 異常値の発見  39  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

組織づくりの手法の例🏢 - モニタリング - 原因の特定  42  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

組織づくりの手法の例🏢 - モニタリング - 解決策の実施  47  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 48

Slide 48 text

EEPSにおける解決策の実施🗳  ● 解決策の立案  ● 解決策の実施  48

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

組織づくりの手法の例🏢 - モニタリング - 正常化の確認  50  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

組織づくりの手法の例🏢 - モニタリング - ポストモーテム  54  異常値の発見  原因の特定  解決策の実施  正常化の確認  ポストモーテム 

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

目次  ● エンジニアの手法の例💻  ● 組織づくりの手法の例🏢  ● エンジニアの手法の転用📡  57

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

エンジニアの手法の転用📡 - 対象  ● タスク管理  ● イテレーション開発  ● ペアプログラミング  ● モブプログラミング  ● コードレビュー  ● 妥当性確認(Validation)  ● 検証(Verification)  ● 継続的インテグレーション  ● バージョン管理  ● モニタリング  59 今回はこれだけを紹介 

Slide 60

Slide 60 text

エンジニアの手法の転用📡 - 対象  ● タスク管理  ● イテレーション開発  ● ペアプログラミング  ● モブプログラミング  ● コードレビュー  ● 妥当性確認(Validation)  ● 検証(Verification)  ● 継続的インテグレーション  ● バージョン管理  ● モニタリング  ● ＋α  60 あなたが発見し、  転用できるものもある 

Slide 61

Slide 61 text

早速想像してみてください(30秒） 

Slide 62

Slide 62 text

思いつきましたか？ 

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

告知  Developers Summit2023(デブサミ)に登壇します  ● テーマ - 組織づくりをエンジニアリングする  ● セッションID - 10-C-4  ● 日時 - 2023年2月10日(金)、13:15 ～ 13:55  ○ 登壇後に5分間 Ask the Speaker（Q&Aコーナー）あり   ● 補足  ○ 参加登録が必要  ○ オンライン実施  ○ 登壇後に登壇内容の連動コンテンツを公開予定   64

Slide 65

Slide 65 text

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

Slide 66

Slide 66 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   ● 書籍「サーベイ・フィードバック」  66