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

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

自己紹介  • てぃーびー（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

自己紹介  • てぃーびー（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年～現在 - 人事、組織領域   エンジニアのバックグラウンドを持ち、人事領域に取り組んで3 年    →それを踏まえての「組織づくりをエンジニアリングする」   3

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

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

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

💻エンジニアの考え方 - 怠惰 - 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 怠惰とは、全体として必要となる労力を減らすためとなれば、  努力を惜しまないような姿勢 

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

エンジニアの考え方 - 短気 - 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 短気とは、単に目の前のニーズを満たすだけではなく、  先を見越してプログラミングするような姿勢 

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

エンジニアの考え方 - 傲慢 - 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 傲慢とは、他者に文句を言わせないような質の高い成果物を作るような姿勢 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/ 

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

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

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

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

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

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

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

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

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

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

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

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

More Decks by tbpgr

Other Decks in Business

Featured

Transcript