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

#devlove 2023/01/23 てぃーびー(@tbpgr) 開発の手法を組織へ  ～Extract Method from Dev to Org～ 
1

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

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

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

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

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

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

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

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

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

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

エンジニアの世界は優れた手法の宝庫  • タスク管理  • イテレーション開発  • ペアプログラミング  • モブプログラミング  •
コードレビュー  • 妥当性確認(Validation)  • 検証(Verification)  • 継続的インテグレーション  • バージョン管理  • モニタリング  12

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

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

優れた手法を概念化  • タスク管理  • イテレーション開発  • ペアプログラミング  • モブプログラミング  •
コードレビュー  • 妥当性確認(Validation)  • 検証(Verification)  • 継続的インテグレーション  • バージョン管理  • モニタリング  組織づくりの領域に転用  概念化  15

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

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

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

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

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

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

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

エンジニアの手法の例💻 - モニタリング - 解決策の実施  • 原因に対する解決策を実施する  24 異常値の発見  原因の特定 

エンジニアの手法の例💻 - モニタリング - 正常化の確認  • 正常値に戻ったことを確認する  25 異常値の発見  原因の特定 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

思いつきましたか？ 

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

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

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

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

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

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

More Decks by tbpgr

Featured

Transcript