$30 off During Our Annual Pro Sale. View Details »

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

tbpgr
February 10, 2023

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

2023/02/10 のDevelopers Summit2023の発表

ウェブエンジニアから人事・組織領域に転身して3年の私が、エンジニアの手法を組織に転用する方法について紹介します。

# Developers Summit2023イベントページ
https://event.shoeisha.jp/devsumi/20230209/session/4194/

tbpgr

February 10, 2023
Tweet

More Decks by tbpgr

Other Decks in Business

Transcript

  1. #devsumi

    2023年2月10日

    てぃーびー(@tbpgr)

    組織づくりを

    エンジニアリングする

    1
    ~組織づくりにエンジニアの手法を転用する~

    View Slide

  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年~現在 - 人事、組織領域

    2

    View Slide

  3. 自己紹介

    ● てぃーびー(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

  4. 3年間、人事業務をして感じていること

    未経験から人事領域にきたが、

    すんなりとキャッチアップできた

    4

    View Slide

  5. 3年間、人事業務をして感じていること

    5
    エンジニア採用について実際に取り組んだ内容

    ● 開発採用チームの立ち上げ

    ● 組織が求める人材像の明確化

    ● 求人票の明確化

    ● ペルソナの作成

    ● 訴求要素の明確化

    ● 選考の質向上

    当時のブログ記事「Recruiting Operations のお仕事 Part 1 - 質向上編」

    https://tbpgr.hatenablog.com/entry/studist-advent-2019-1


    View Slide

  6. 3年間、人事業務をして感じていること

    6
    エンジニア採用
 ソフトウェア開発

    ● 現状を整理した ● 実装が必要な対象を整理した

    ● 優先順に並べた ● 優先順に並べた

    ● 一つずつ順に対応した ● 一つずつ順に対応した

    ○ 完了の定義を定めた ○ テストを実装した

    ○ 解決方法を調べた ○ 実装方法を調べた

    ○ 解決策を実施した ○ 実装した

    ○ 完了の定義を満たした 
 ○ テストを通した


    View Slide

  7. 3年間、人事業務をして感じていること

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

    7

    View Slide

  8. 3年間、人事業務をして感じていること

    「採用の改善」に役立つ情報を「ITエンジニア採用入門」のZennBookで公開したら大きな
    反響があった

    ● ZennBook 1,002 likes (2023/01/22時点)

    ● はてなブックマーク 1,959 users (2023/01/22時点)

    8

    View Slide

  9. 3年間、人事業務をして感じていること

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

    9

    View Slide

  10. 3年間、人事業務をして感じていること

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

    10

    View Slide

  11. 3年間、人事業務をして感じていること

    11
    エンジニア採用
 ソフトウェア開発

    求人要件定義 - 求人の分割
 責務の分割

    求人票 - 求人票のレビュー 成果物のレビュー

    選考 - マッチング・インタビュー
 期待値の明確化


    View Slide

  12. エンジニアの世界は優れた手法の宝庫

    ● 情報共有

    ● タスク管理

    ● ペアプログラミング

    ● モブプログラミング

    ● ふりかえり

    ● 妥当性確認(Validation)

    ● 検証(Verification)

    ● 継続的インテグレーション

    ● バージョン管理

    ● モニタリング

    ● リファクタリング

    12

    View Slide

  13. 具体と抽象

    エンジニアにとって具体と抽象の扱いは日常

    ● Extract Method - メソッドの抽出

    ● Composed Method - メソッド内の各処理の抽象度を揃える

    13

    View Slide

  14. 具体と抽象。そして概念化

    具体的な対象を抽象化し、概念化できれば、広く転用できるようになる

    同じことを繰り返
    したくない

    繰り返しを減らし
    たい

    DRY原則
    抽象化
 転用

    Don’t Repeat Yourself Principle

    同じことを繰り返さないようにする

    14

    View Slide

  15. 優れた手法を概念化

    ● 情報共有

    ● タスク管理

    ● ペアプログラミング

    ● モブプログラミング

    ● ふりかえり

    ● 妥当性確認(Validation)

    ● 検証(Verification)

    ● 継続的インテグレーション

    ● バージョン管理

    ● モニタリング

    ● リファクタリング

    組織づくりの領域に転用

    概念化

    15

    View Slide

  16. 持ち帰ってもらいたいこと

    エンジニアの手法を組織づくりに転用する例を知ること。

    そして、皆さんの現場でエンジニアの手法を組織づくりに転用して
    もらうこと

    16

    View Slide

  17. 目次

    ● エンジニアの考え方 - 三大美徳💻

    ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻

    ● エンジニアの手法で組織課題を解決 - 短気🏢💻

    ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻

    ● 組織づくりにエンジニアの手法を転用する📡

    17

    View Slide

  18. 目次

    ● エンジニアの考え方 - 三大美徳💻

    ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻

    ● エンジニアの手法で組織課題を解決 - 短気🏢💻

    ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻

    ● 組織づくりにエンジニアの手法を転用する📡

    18

    View Slide

  19. エンジニアの考え方 - プログラマーの三大美徳💻

    ● 怠惰 - Laziness

    ● 短気 - Impatience

    ● 傲慢 - Hubris

    19

    View Slide

  20. 💻エンジニアの考え方 - 怠惰 - 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

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

    21

    View Slide

  22. エンジニアの考え方 - 短気 - 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
    短気とは、単に目の前のニーズを満たすだけではなく、

    先を見越してプログラミングするような姿勢


    View Slide

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

    23

    View Slide

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


    View Slide

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

    25

    View Slide

  26. 目次

    ● エンジニアの考え方 - 三大美徳💻

    ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻

    ● エンジニアの手法で組織課題を解決 - 短気🏢💻

    ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻

    ● 組織づくりにエンジニアの手法を転用する📡

    26

    View Slide

  27. 組織づくりの考え方 - 怠惰 = 効率化🏢

    27
    組織づくりにおける怠惰とは、組織全体として必要となる労力を減らすために、
    協力者を巻き込み、効率化を実現していく努力を惜しまないような姿勢

    怠惰とは、全体として必要となる労力を減らすためとなれば、努力を惜しまない
    ような姿勢

    エンジニアの考え方💻

    組織づくりの考え方🏢


    View Slide

  28. ● 良い施策のノウハウが部門内に閉じている

    ● 問題解決のノウハウが部門内に閉じている

    組織課題 - 効率化に関わる組織課題

    28

    View Slide

  29. 自由と責任。自律と主体性を大切にする社風。

    それゆえに、各部内で様々な工夫を独自に実施している。

    全社の意思決定を待たずに柔軟に部内の取り組みを実施できる。

    反面、良い取り組みが部門をまたいで横展開されにくい。

    組織課題 - 効率化に関わる組織課題 - 背景

    29

    View Slide

  30. ノウハウが広がっている部分もある。

    社員同士の交流範囲で偶発的に取り組みが広がる

    「お祭り」的な展開がある。

    組織課題 - 効率化に関わる組織課題 - 背景

    30

    View Slide

  31. 例 - 評価制度リファレンスもくもく会

    評価制度改定に合わせて制度理解のための「評価制度リファレンスもくもく会」
    が草の根的に1つの部門で実施された。

    たまたまそれをみかけた複数の部門が「私たちも」と「評価制度リファレンスもく
    もく会」を実施した。

    組織課題 - 効率化に関わる組織課題 - 背景

    31

    View Slide

  32. 解決策 - 情報共有

    32
    組織施策に関わるノウハウを全マネージャーに共有する

    ● 良い施策を把握し、転用できる

    ● 問題解決の方法を把握し、転用できる


    View Slide

  33. 具体例 - 組織施策一覧の作成

    33
    組織施策を共有する一覧を作成した。

    施策名
 概要

    部内課題共有カンバン
 部への問題提起、リクエストをかんばんで管理

    部門ダッシュボード
 部の目標と成果の可視化

    マネージャーズMTG
 隔週で部長・マネージャー間で部内施策およびメン
    バー状況等に関する相談・共有を行う

    RACI図
 RACI図によって部門内の責務を可視化

    Welcomeティータイム
 入社メンバーとの雑談コミュニケーション


    View Slide

  34. 具体例 - 組織施策一覧の作成 - 進め方

    34
    小さくはじめる

    ● 4部門のマネージャーに趣旨を説明

    ● 協力を得て、4部門の組織施策を記録


    View Slide

  35. 具体例 - 組織施策一覧の作成 - 進め方

    35
    大きく広げる

    ● 組織施策一覧への追加手順を整備

    ● 組織施策一覧を全マネージャーに共有


    View Slide

  36. 具体例 - 組織施策一覧の作成 - 今後の展開

    36
    こんなことができたらいいかも?

    ● 横展開可能な施策の確認と展開

    ● マネージャーが集まる雑談会での情報交換

    ● マネージャー同志の1対1での情報交換

    ● 社外へのノウハウ開示や未来の同僚に向けたブログ発信


    View Slide

  37. まとめ - エンジニアの手法で組織課題を解決 - 怠惰編

    37
    ● 課題 - 効率化に関わる組織課題

    ○ 良い施策のノウハウが部門内に閉じている

    ○ 問題解決のノウハウが部門内に閉じている

    ● 解決策 - 情報共有

    情報共有の実施


    View Slide

  38. 目次

    ● エンジニアの考え方 - 三大美徳💻

    ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻

    ● エンジニアの手法で組織課題を解決 - 短気🏢💻

    ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻

    ● 組織づくりにエンジニアの手法を転用する📡

    38

    View Slide

  39. 組織づくりの考え方 - 短気 = 先見性🏢

    39
    組織づくりにおける短気とは、単に目の前の状況に対するニーズを満たすだけ
    ではなく、先を見越して仕組み化するような姿勢

    短気とは、単に目の前のニーズを満たすだけではなく、先を見越してプログラミ
    ングするような姿勢

    エンジニアの考え方💻

    組織づくりの考え方🏢


    View Slide

  40. 組織課題 - 先見性に関わる組織課題

    40
    ● エンゲージメントセンサスサーベイを半年に1回実施している

    ○ 社員のエンゲージメントの確認が半年に1回しかできない

    💡エンゲージメントとは「 社員が会社に貢献したいという意欲を持って
    いる状態」です。単なる社員満足度とは異なります。 

    最近話題になっている Developer eXperience では、開発者の社員満足
    度が取り上げられがちですが、本来重要なのはエンゲージメントで
    す。


    View Slide

  41. 解決策 - モニタリング

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


    View Slide

  42. 月次でエンゲージメントパルスサーベイ(以降EPSと表記)を実施

    ● 10問~15問程度の少数の設問のアンケートによってエンゲージメントチェッ
    ク

    ● 設問ごとに5段階でスコアリング

    具体例 - エンゲージメントパルスサーベイ

    42

    View Slide

  43. EPS

    独自サーベイの作成

    ● 自社の文化を踏まえた設問が作成可能

    ● 設問の継続改善が可能

    設問の例

    ● Q2. 資源 - 仕事を進めるために必要となる資源(人、時間、予算、情報、権
    限、設備等)が提供されている

    ● Q11. 文化「情報発信」 - 社内外への情報発信(ブログ、登壇、ポッドキャス
    ト、動画配信など)を行うことの価値を実感している

    43

    View Slide

  44. 説明スライド - 目的をしっかりと伝える

    ● 組織の状態把握

    ● 組織の継続改善


    EPS - 目的説明


    View Slide

  45. 伝えないとどうなるか?

    EPS - 目的説明

    45

    View Slide

  46. サーベイ疲れ(Survey Fatigue)が発生する

    ● 目的がわからない

    ● 何に使われてるのかわからない

    ● 意味があるのかわからない

    EPS - 目的説明

    46
    1回目の

    サーベイ実施

    回答
 用途不明

    2回目の

    サーベイ実施

    回答意欲低下

    真剣に

    回答しない


    View Slide

  47. EPS - トライアル

    トライアル実施

    MVP(Minimum Viable Product)での実施

    ● 5ヶ月間の実施

    ● 2事業部4部門 約100名が対象(全社だと約500名)

    ● アンケート - Google Form

    ● レポート - Google Spreadsheet + Google Docs

    47

    View Slide

  48. トライアル実施

    ● サーベイフィードバックの実施

    ○ アンケートの実施

    ○ 結果レポートの作成 

    ○ 結果レポートの共有 

    ○ 参加部門のマネージャーと協力 

    ■ 問題選定

    ■ 原因特定

    ■ 解決策の実施

    ■ 改善確認


    ※2023年1月から全社への本番導入を開始しました

    EPS - トライアル

    48
    アンケートの実施

    問題選定

    解決策の実施

    改善確認

    サーベイフィードバック 


    View Slide

  49. EPS - プロセス

    49
    異常値の発見

    原因の特定

    解決策の実施

    正常化の確認

    ポストモーテム


    View Slide

  50. EPS - プロセス - 異常値の発見

    50
    異常値の発見

    原因の特定

    解決策の実施

    正常化の確認

    ポストモーテム


    View Slide

  51. EPSにおける異常値の発見

    明確な基準を置くかどうか検討中

    ● 単月スコア

    ● 推移スコア

    ● 分析軸 - 部門、職種、入社時期、etc

    51

    View Slide

  52. EPSにおける異常値の発見

    的を絞る

    ● 低スコアの項目のうち、どの項目に着目するかを決定する

    ○ 単月で比較的スコアが低い設問 

    ○ 推移で大きく低下している設問 

    52

    View Slide

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

    53
    異常値の発見

    原因の特定

    解決策の実施

    正常化の確認

    ポストモーテム


    View Slide

  54. EPSにおける原因の特定

    追加調査

    ● EPSの設問は抽象度が高い

    ○ Q2. 資源 - 仕事を進めるために必要となる資源(人、時間、予算、情報、権限、設備等)が提供され
    ている

    ● 低スコアの原因を特定するためには追加の情報が必要

    ○ どの資源が不足しているのか? 

    ○ なぜ不足しているのか? 

    54

    View Slide

  55. EPSにおける原因の特定

    追加調査の方法

    ● チームでの対話

    ● アンケート

    ● インタビュー

    55

    View Slide

  56. EPSにおける原因の特定

    追加調査の方法

    ● チームでの対話

    ● アンケート

    ● インタビュー

    56
    トライアルでは主にこち
    らで原因特定を実施

    View Slide

  57. EPSにおける原因の特定 - Tips 事実を引き出す

    質問のコツ

    解釈を確認する質問ではなく、事実を確認する質問をする

    ● 解釈質問 - Why

    ○ 「なぜ、リソースが足りないのですか?」 

    ■ 解釈の回答「みんな忙しいからだと思います」 

    ● 事実質問 - When、Where、Who、What、How

    ○ 「具体的に、どの程度リソースが足りないのですが?」 

    ■ 事実の回答「本来4名必要なプロジェクトを3名で実施しています」 

    57

    View Slide

  58. EPS - モニタリング - 解決策の実施

    58
    異常値の発見

    原因の特定

    解決策の実施

    正常化の確認

    ポストモーテム


    View Slide

  59. EPSにおける解決策の実施

    ● 解決策の立案

    ● 解決策の実施

    59

    View Slide

  60. EPSにおける解決策の実施

    解決策の実施に関する具体例

    ● 低スコアの設問 - 資源の不足

    ● 追加調査の実施 - 追加調査 個別インタビュー

    ● 原因の特定 - 人の工数の不足。コンテキストスイッチの時間

    ● 解決策の立案 - コンテキストスイッチを加味した見積もり

    ○ 20%余力を持てるように調整をする

    ● 解決策の実施 - 契約の切れ目で段階的に実施

    60

    View Slide

  61. EPS - モニタリング - 正常化の確認

    61
    異常値の発見

    原因の特定

    解決策の実施

    正常化の確認

    ポストモーテム


    View Slide

  62. EPSにおける正常化の確認

    解決基準の確認

    ● 施策の実施時に定めた解決基準を確認する

    ● 解決に至っていない場合は、追加調査で原因を把握する

    62

    View Slide

  63. EPSにおける正常化の確認

    EPSのスコアを確認

    ● 施策の効果が出る時期に対象の設問に関わるスコアを確認

    ● スコアの改善が見受けられない場合は、他の要因の影響が考えられる

    63

    View Slide

  64. EPSにおける正常化の確認

    正常化確認の具体例

    ● スコアの確認 - 資源の不足に関する設問のスコアを確認。微増

    ● 追加調査の実施 - 見積もり能力の個人差が影響

    ● 追加施策の検討 - ペアワーク等、見積もり力を高める取り組み

    ● 追加施策の実施

    64

    View Slide

  65. EPS - モニタリング - ポストモーテム

    65
    異常値の発見

    原因の特定

    解決策の実施

    正常化の確認

    ポストモーテム


    View Slide

  66. EPSにおけるポストモーテム

    ● 解決した対象についてふりかえる

    ○ なぜ発生したのか?

    ○ 今後、仕組みによって未然に防ぐことは可能か?

    ● ふりかえった内容を記録する

    ○ 記録した内容を他部門が参考にできる

    66
    💡トライアル時点でポストモーテムは実施していません


    View Slide

  67. EPSにおけるポストモーテム

    ありえそうなパターン

    ● ポストモーテム

    ○ サーベイ結果 - 最近入社したメンバーの貢献実感のスコアが低い 

    ○ 原因 - 入社直後に身につけるべきことが身についていないから活躍に至りにくい 

    ○ 解決策 - 部門特有の入社オンボーディングを整備する 

    ● 横展開

    ○ 問題が発生した部門以外においても、部門特有の入社オンボーディングが十分でない場合は整備
    する

    67

    View Slide

  68. まとめ - エンジニアの手法で組織課題を解決 - 短気編

    68
    ● 課題 - 先見性に関わる組織課題

    ○ 社員のエンゲージメントの確認が半年に1回しかできない

    ● 解決策 - モニタリング

    モニタリングの実施


    View Slide

  69. 目次

    ● エンジニアの考え方 - 三大美徳💻

    ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻

    ● エンジニアの手法で組織課題を解決 - 短気🏢💻

    ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻

    ● 組織づくりにエンジニアの手法を転用する📡

    69

    View Slide

  70. 組織づくりの考え方 - 傲慢 = 品質維持🏢

    70
    組織づくりにおける傲慢とは、関係者から最終的に満足の声を得られるような
    質の高い組織施策を行うような姿勢

    傲慢とは、他者に文句を言わせないような質の高い成果物を作るような姿勢

    エンジニアの考え方💻

    組織づくりの考え方🏢


    View Slide

  71. 組織課題 - 品質維持に関わる組織課題

    71
    ● 組織施策の業務の質と効率を高めたい

    ○ 組織施策は開発に比べて結果の確認が漏れたり、曖昧になりやすい

    ○ 組織施策の実施は少人数で行うことになりやすく、効率を高めたい


    View Slide

  72. 解決策 - ふりかえり

    72
    ふりかえりをすることで

    ● よかった点を横展開できる

    ● 問題点を解決できる


    View Slide

  73. 週次のふりかえりを実施

    ● KPTで組織開発業務をふりかえる

    ○ 施策の良し悪しをふりかえる 

    ○ 施策に至る業務の進め方をふりかえる 

    具体例 - 組織施策のふりかえり

    73

    View Slide

  74. ふりかえりの運用 - 事前の運用

    ● Keep、Problemに追加する内容があれば都度登録しておく

    具体例 - 組織施策のふりかえり

    74
    💡ふりかえりまで1週間の間に対象について忘れてしまうことを防ぐ


    View Slide

  75. ふりかえりの運用 - 当日の運用

    ● Keepを登録する - 5分

    ● Keepのカテゴライズ + 説明 - 5〜10分

    ● Problemを登録する - 5分

    ● Problemのカテゴライズ + 説明 - 5〜10分

    ● Keepから1件Tryを選ぶ

    ● Problemから1件Tryを選ぶ

    具体例 - 組織施策のふりかえり

    75

    View Slide

  76. ポイント

    ● 週次で追加する改善対象はMax2件

    ○ Keepから1件

    ○ Problemから1件

    ● むやみにTryを出して改善できないよりは重要なものに絞って着実に改善したほう
    がいい

    具体例 - 組織施策のふりかえり

    76

    View Slide

  77. 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. まとめ - エンジニアの手法で組織課題を解決 - 傲慢編

    78
    ● 課題 - 品質維持に関わる組織課題

    ○ 組織施策の業務の質と効率を高めたい

    ● 解決策 - ふりかえり

    ふりかえりで

    継続的な改善


    View Slide

  79. 目次

    ● エンジニアの考え方 - 三大美徳💻

    ● エンジニアの手法で組織課題を解決 - 怠惰🏢💻

    ● エンジニアの手法で組織課題を解決 - 短気🏢💻

    ● エンジニアの手法で組織課題を解決 - 傲慢🏢💻

    ● 組織づくりにエンジニアの手法を転用する📡

    79

    View Slide

  80. エンジニアの手法の転用 - 情報共有の事例

    ● エンジニアの手法 - 開発の情報共有

    ● 組織づくりに転用 - 組織施策の情報共有

    80
    開発の情報共有
 組織課題の情報共有


    View Slide

  81. エンジニアの手法の転用 - モニタリングの事例

    ● エンジニアの手法 - システムのモニタリング

    ● 組織づくりに転用 - エンゲージメントのモニタリング

    81
    システムのモニタリング
 エンゲージメントのモニタリング


    View Slide

  82. エンジニアの手法の転用 - ふりかえりの事例

    ● エンジニアの手法 - 開発業務のふりかえり

    ● 組織づくりに転用 - 組織施策のふりかえり

    82
    開発業務のふりかえり
 組織施策のふりかえり


    View Slide

  83. 組織づくりにエンジニアの手法を転用する - 対象

    ● 情報共有

    ● タスク管理

    ● ペアプログラミング

    ● モブプログラミング

    ● ふりかえり

    ● 妥当性確認(Validation)

    ● 検証(Verification)

    ● 継続的インテグレーション

    ● バージョン管理

    ● モニタリング

    ● リファクタリング

    83
    今回はこれらを紹介

    View Slide

  84. 組織づくりにエンジニアの手法を転用する - 対象

    ● 情報共有

    ● タスク管理

    ● ペアプログラミング

    ● モブプログラミング

    ● ふりかえり

    ● 妥当性確認(Validation)

    ● 検証(Verification)

    ● 継続的インテグレーション

    ● バージョン管理

    ● モニタリング

    ● リファクタリング

    ● +α

    84
    あなたが発見し、

    転用できるものもある


    View Slide

  85. 組織づくりにエンジニアの手法を転用する

    ぜひ、エンジニアの手法を

    組織づくりに転用してみてください!

    85
    あなたが選んだ手法
 組織づくりに転用


    View Slide

  86. 告知

    今回の登壇内容をより詳細に、「怠惰・短気・傲慢」ごとにそれぞれ5パターン・合計15パターンの事例を揃えた
    ZennBookをAsk the Speaker(Q&Aコーナー)の完了後に公開します。

    Twitterの @tbpgr でお知らせいたします。Twitterをしていない方は、 https://zenn.dev/tbpgr?tab=books をご確認くだ
    さい。

    86

    View Slide

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

    87

    View Slide

  88. 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