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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

6
エンジニア採用  ソフトウェア開発 
● 現状を整理した ● 実装が必要な対象を整理した 
● 優先順に並べた ● 優先順に並べた 
● 一つずつ順に対応した ● 一つずつ順に対応した 
○ 完了の定義を定めた ○ テストを実装した 
○ 解決方法を調べた ○ 実装方法を調べた 
○ 解決策を実施した ○ 実装した 
○ 完了の定義を満たした   ○ テストを通した 

View Slide

あれ？エンジニアのときとあまり変わらないぞ 
7

View Slide

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

View Slide

エンジニアの手法を組織づくりに転用する価値を実感した 
9

View Slide

エンジニアの手法の転用の例 
10

View Slide

11
エンジニア採用  ソフトウェア開発 
求人要件定義 - 求人の分割  責務の分割 
求人票 - 求人票のレビュー成果物のレビュー 
選考 - マッチング・インタビュー  期待値の明確化 

View Slide

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

View Slide

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

View Slide

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

View Slide

優れた手法を概念化 
● 情報共有 
組織づくりの領域に転用 
概念化 
15

View Slide

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

View Slide

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

View Slide

目次 
18

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

目次 
26

View Slide

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

View Slide

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

View Slide

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

View Slide

ノウハウが広がっている部分もある。 
社員同士の交流範囲で偶発的に取り組みが広がる 
「お祭り」的な展開がある。 
30

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

目次 
38

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

伝えないとどうなるか？ 
45

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

EPS - プロセス - 異常値の発見 
50
原因の特定 

View Slide

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

View Slide

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

View Slide

EPS - プロセス - 原因の特定 
53
原因の特定 

View Slide

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

View Slide

追加調査の方法 
● チームでの対話 
● アンケート 
● インタビュー 
55

View Slide

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

View Slide

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

View Slide

EPS - モニタリング - 解決策の実施 
58
原因の特定 

View Slide

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

View Slide

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

View Slide

EPS - モニタリング - 正常化の確認 
61
原因の特定 

View Slide

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

View Slide

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

View Slide

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

View Slide

EPS - モニタリング - ポストモーテム 
65
原因の特定 

View Slide

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

View Slide

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

View Slide

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

View Slide

目次 
69

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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/ 

View Slide

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

View Slide

目次 
79

View Slide

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

View Slide

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

View Slide

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

View Slide

組織づくりにエンジニアの手法を転用する - 対象 
● 情報共有 
83
今回はこれらを紹介

View Slide

組織づくりにエンジニアの手法を転用する - 対象 
● 情報共有 
● ＋α 
84
あなたが発見し、 
転用できるものもある 
 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

tbpgr

More Decks by tbpgr

Other Decks in Business

Featured

Transcript