Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

tbpgr
January 23, 2023
1.6k

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

2023/01/23 のDevLOVE イベントの発表

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

# DevLOVE イベントページ
あなたのノウハウ、開発の現場だけ?組織へ越境させよう!
https://devlove.doorkeeper.jp/events/149511?fbclid=IwAR0Ni5mQ_a2_yznrKvU1fPJ32V4NTnUL3CQrgC33fPTQjfBbvIgYm8d5Z40

tbpgr

January 23, 2023
Tweet

More Decks by tbpgr

Transcript

  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
  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. 3年間、人事業務をして感じていること
 5 エンジニア採用について実際に取り組んだ内容
 • 開発採用チームの立ち上げ
 • 組織が求める人材像の明確化
 • 求人票の明確化
 •

    ペルソナの作成
 • 訴求要素の明確化
 • 選考の質向上
 当時のブログ記事「Recruiting Operations のお仕事 Part 1 - 質向上編」

  4. 3年間、人事業務をして感じていること
 6 エンジニア採用
 ソフトウェア開発
 • 現状を整理した • 実装が必要な対象を整理した
 • 優先順に並べた

    • 優先順に並べた
 • 一つずつ順に対応した • 一つずつ順に対応した
 ◦ 完了の定義を定めた ◦ テストを実装した
 ◦ 解決方法を調べた ◦ 実装方法を調べた
 ◦ 解決策を実施した ◦ 実装した
 ◦ 完了の定義を満たした 
 ◦ テストを通した

  5. 3年間、人事業務をして感じていること
 11 エンジニア採用
 ソフトウェア開発
 求人要件定義 - 求人の分割
 責務の分割
 求人票 -

    求人票のレビュー 成果物のレビュー
 選考 - マッチング・インタビュー
 期待値の明確化

  6. エンジニアの世界は優れた手法の宝庫
 • タスク管理
 • イテレーション開発
 • ペアプログラミング
 • モブプログラミング
 •

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

    コードレビュー
 • 妥当性確認(Validation)
 • 検証(Verification)
 • 継続的インテグレーション
 • バージョン管理
 • モニタリング
 組織づくりの領域に転用
 概念化
 15
  8. エンジニアの手法の例💻 - モニタリング - 原因の特定
 • 異常値が発生している原因を調査する
 ◦ 関連情報の確認
 ◦

    問題の切り分け
 ◦ 仮説の検証
 • 正常だった場合は対応を完了する
 • 異常だった場合は原因を特定する
 23 異常値の発見
 原因の特定
 解決策の実施
 正常化の確認
 ポストモーテム

  9. エンジニアの手法の例💻 - モニタリング - ポストモーテム
 • 事象に対するふりかえりを実施し、文書として記録する
 ◦ ポストモーテムは「検死解剖」の意味 


    • ふりかえりから得た知見をもとに改善を実施する
 ◦ 閾値の変更
 ◦ その他の対策の実施 
 • 問題が再現しないか確認
 26 異常値の発見
 原因の特定
 解決策の実施
 正常化の確認
 ポストモーテム

  10. EEPSの導入🗳 - 設問設計
 独自サーベイの作成
 • 自社の文化を踏まえた設問が作成可能
 • 設問の継続改善が可能
 設問の例
 •

    Q2. 資源 - 仕事を進めるために必要となる資源(人、時間、予算、情報、権限、設 備等)が提供されている
 • Q11. 文化「情報発信」 - 社内外への情報発信(ブログ、登壇、ポッドキャスト、動画 配信など)を行うことの価値を実感している
 32
  11. サーベイ疲れ(Survey Fatigue)が発生する
 • 目的がわからない
 • 何に使われてるのかわからない
 • 意味があるのかわからない
 EEPSの導入🗳 -

    導入目的の説明
 35 1回目の
 サーベイ実施
 回答
 用途不明
 2回目の
 サーベイ実施
 回答意欲低下
 真剣に
 回答しない

  12. EEPSの導入🗳 - トライアル実施1
 MVP(Minimum Viable Product)での実施
 • 5ヶ月間の実施
 • 2事業部4部門

    約100名が対象(全社だと約500名)
 • アンケート - Google Form
 • レポート - Google Spreadsheet + Google Docs
 36
  13. EEPSの導入🗳 - トライアル実施2
 • サーベイフィードバックの実施
 ◦ アンケートの実施
 ◦ 結果レポートの作成 


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

  14. EEPSにおける原因の特定🗳
 追加調査
 • EEPSの設問は抽象度が高い
 ◦ Q2. 資源 - 仕事を進めるために必要となる資源(人、時間、予算、情報、権限、設備等)が提供され ている


    • 低スコアの原因を特定するためには追加の情報が必要
 ◦ どの資源が不足しているのか? 
 ◦ なぜ不足しているのか? 
 43
  15. EEPSにおける原因の特定🗳 - Tips 事実を引き出す
 質問のコツ
 解釈を確認する質問ではなく、事実を確認する質問をする
 • 解釈質問 - Why


    ◦ 「なぜ、リソースが足りないのですか?」 
 ▪ 解釈の回答「みんな忙しいからだと思います」 
 • 事実質問 - When、Where、Who、What、How
 ◦ 「具体的に、どの程度リソースが足りないのですが?」 
 ▪ 事実の回答「本来4名必要なプロジェクトを3名で実施しています」 
 46
  16. 🗳EEPSにおける解決策の実施
 解決策の実施に関する具体例
 • 低スコアの設問 - 資源の不足
 • 追加調査の実施 - 追加調査

    個別インタビュー
 • 原因の特定 - 人の工数の不足。コンテキストスイッチの時間
 • 解決策の立案 - コンテキストスイッチを加味した見積もり
 ◦ 20%余力を持てるように調整をする
 • 解決策の実施 - 契約の切れ目で段階的に実施
 49
  17. EEPSにおけるポストモーテム🗳
 ありえそうなパターン
 • ポストモーテム
 ◦ サーベイ結果 - 最近入社したメンバーの貢献実感のスコアが低い 
 ◦

    原因 - 入社直後に身につけるべきことが身についていないから活躍に至りにくい 
 ◦ 解決策 - 部門特有の入社オンボーディングを整備する 
 • 横展開
 ◦ 問題が発生した部門以外においても、部門特有の入社オンボーディングが十分でない場合は整備 する
 56
  18. エンジニアの手法の転用📡 - モニタリングの事例
 • エンジニアの手法 - システムのモニタリング
 • 組織づくりに転用 -

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

  19. エンジニアの手法の転用📡 - 対象
 • タスク管理
 • イテレーション開発
 • ペアプログラミング
 •

    モブプログラミング
 • コードレビュー
 • 妥当性確認(Validation)
 • 検証(Verification)
 • 継続的インテグレーション
 • バージョン管理
 • モニタリング
 59 今回はこれだけを紹介

  20. エンジニアの手法の転用📡 - 対象
 • タスク管理
 • イテレーション開発
 • ペアプログラミング
 •

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

  21. 告知
 Developers Summit2023(デブサミ)に登壇します
 • テーマ - 組織づくりをエンジニアリングする
 • セッションID -

    10-C-4
 • 日時 - 2023年2月10日(金)、13:15 ~ 13:55
 ◦ 登壇後に5分間 Ask the Speaker(Q&Aコーナー)あり 
 • 補足
 ◦ 参加登録が必要
 ◦ オンライン実施
 ◦ 登壇後に登壇内容の連動コンテンツを公開予定 
 64
  22. 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