「あなたのノウハウ、開発の現場だけ？組織へ越境させよう！」参加メモ
イベント概要
てぃーびー(@tbpgr) / 田部井 勝彦さん「開発の手法を組織へ～Extract Method from Dev to Org～」
■はじめに
自己紹介
「開発の手法を組織へ」人事に転職して3年目
3年間、人事業務をして感じていること
意外とキャッチアップできた
詳細はブログ参照
ふわっと抽象度上げて捉えると、エンジニアのときと変わらないことをやっていることに気づいた
ITエンジニア採用入門のZenn
エンジニア採用とソフトウェア開発
「エンジニア採用：求人の分割をしよう」「ソフトウェア開発：責務の分割」
「エンジニア採用：求人票のレビュー」「ソフトウェア開発：成果物のレビュー」
「エンジニア採用：マッチング・インタビュー」「ソフトウェア開発：期待値の明確化」
エンジニアの世界は優れた手法がたくさんある
具体と抽象の扱いがうまい
そして概念化することで広く物事を広げる
■本編
エンジニアの手法の例
組織づくりの手法の例
エンジニアの手法の転用
エンジニアの手法の例：モニタリング
設定
異常値の発見
原因の特定
解決策の実施
正常化の確認
ポストモーテム
組織づくりの手法の例：モニタリング
監視対象：メンバーのモチベーションチェック
エンゲージメントパルスサーベイ（EEPS）
設定
10〜15問程度の少数の設問
サービスとして決まっている設問か、独自に作成するか（独自サーベイ）を選べる
独自サーベイなら
自社の文化を踏まえた設問が作成可能
設問の継続改善が可能
決まっている設問なら
他社との比較ができる
メリデメ考慮して選ぶのがだいじ
設問の例
資源：仕事を進めるために必要となる資源が提供されている
文化「情報発信」
導入目的の説明
目的をしっかりと伝える
組織の状況把握
組織の現状改善
伝えないとどうなるか
サーベイ疲れが発生する
目的がわからない
何に使われているかわからない
意味があるのかわからない
トライアル実施
プロダクト開発におけるMVP
5ヶ月100名（全社の1/5）でトライアル
サーベイフィードバックをトライアルでも実施
問題選定
原因特定
解決策の実施
改善確認
実施プロセス
異常値の発見
明確な基準を置くかは検討中（単月スコア、推移スコア、分析軸-部門・職種・入社時期etc）
EEPSにおける異常値の発見
的を絞る：低スコアの項目のうち、どの項目に着目するか決定する
原因の特定
追加調査
EEPSの設問は抽象度が高い
低スコアの原因を特定するためには追加の情報が必要
追加調査の方法3つ
チームでの対話
アンケート
インタビュー
トライアルではアンケートとインタビューを実施
最終的には現場のチームの対話で回るのが理想かも
原因の特定Tips：事実を引き出す
解釈を確認する質問ではなく、事実を確認する質問をする
解決策の実施
解決策の立案
解決策の実施
具体例
資源の不足、ある部門で低く出た。追加調査として個別のインタビューを実施。結果、工数の不足。コンテキストスイッチを加味した見積もり。受託兼任だと普通に100％に積むとコンテキストスイッチで120％とかになっていた
解決策の立案：20％余力を持てるように調整をする
解決策の実施：案件の切れ目
正常化の確認
解決基準の確認
EEPSのスコアを確認
思ったよりスコア上がっていない。追加調査をした
見積もり能力の個人差が影響していたことが追加調査で分かった
ペアワーク等、見積もり力を高める取り組みにトライ（経過確認中）
ポストモーテム
実施していない
解決した対象についてふりかえる
ふりかえった内容を記録
エンジニアの手法の転用
今回はモニタリングを例にしたが、他にも転用できるものがあるはず
ぜひエンジニアの手法を組織づくりに転用してみてください！
■告知：デブサミに登壇します
今回は例が1つ（モニタリング）だったが、デブサミでは、例を3つ紹介する
15個の例を紹介したZenn Bookを公開予定
（Q＆Aはメモとっていない）
感想
ちょうど所属している会社でも「エンジニアの手法を他の部門に横展開していこう」という趣旨の話を先日聞いたため、とてもタイムリーだった
「抽象度を上げて横展開していく」は「エンジニア→他の部署」以外にもなんか色々ありそうで面白いと感じたので、他にどんなものあるか考えながら日々過ごしてみよう
この記事が気に入ったらサポートをしてみませんか？