ソフトウェアピープルマネジメント

ソフトウェア開発のワークエンゲージメントを高める為の考え方。という内容でソフトウェア開発
のワークエンゲージメントを高めるために何を考えればよいのか？をまとめてみました

Transcript

1. ソフトウェア ピープルマネジメント ソフトウェア開発のワークエンゲージメントを高める為の考え方 VERSION 1.0 2024.4.24 @ryurock SRE アーキテクチャ USE TEMPLATE Click 1
2. Agenda 2 ➔ ピープルマネジメントに責任をもつマネージャーとは？ ➔ ピープルマネジメント ➔ 構造や場にアプローチする ➔ 我々の集まった目的を共有する ◆ 評価と指標 ➔ ヒトに行動変化のきっかけを与える ◆ 1 on 1 ◆ 暗黙知と形式知 ◆ 権限委譲
3. 自己紹介 Click 3 木村 竜介 (@ryurock) SRE アーキテクチャ 高校卒業後、クライミングにハマりフリー ターをしながら海外クライミングに明け暮 れる。その後、システムエンジニアとして 様々な業務に従事。ここ７年ほどは SRE 領 域を主戦場としている。 システムリアーキテクトや SRE チームの立 ち上げ等、ハード(技術)とソフト(組織)の両 軸から戦略を考える事を得意としている。
4. 4 ピープルマネジメントに責任をもつ マネージャーとは？
5. ピープルマネジメントに責任をもつマネージャーとは？ Click 5 個人の成果ではなく、 周りの成果がマネージャーの成果 プレーヤー 組織として 求めるもの あなた個人の成果 マネージャー 組織として 求めるもの マネジメント範囲及び 周辺の成果 全体のエンゲージメントを高める マネージャーには、マネジメント範囲が あるが、自身のマネジメント範囲の成果 を出すためには、その周りの成果も配慮 しないと成果が出てこない。 充実した人達を バスにどれだけ 乗せられるか？
6. ピープルマネジメントに責任をもつマネージャーとは？ Click 6 ヒトのワークエンゲージメントを高めて 組織に還元する メンバー 活力 ワークエンゲージメント 仕事に取り組むエネル ギーが高く、困難な課題 にも積極的に行うことが できる状態 熱意 仕事の目的を成し遂げよ うとする激しい意気込み をもつ状態 没頭 仕事に取り組む際に夢中 になり、のめり込んでい る状態 組織が 解決したい課題 組織の 目的と背景 目標 売上 利益 マッチング
7. ピープルマネジメントに責任をもつマネージャーとは？ Click 7 足りないピースの穴埋めや落ち葉拾いをする ピープルマネジメント テクノロジーマネジメント プロジェクトマネジメント プロダクトマネジメント Product Manager Project Manager Manager OR Manager OR Tech Lead Manager OR 人事 Manager OR マネージャーの宿命 各組織が求める水準のピースがいない間は、 そのピースの代打になることがマネージャー に求められる。 つまり、沢山の仕事があり、突発的な仕事が 割り込んできたり、発生したりする。
8. ピープルマネジメントに責任をもつマネージャーとは？ Click 8 マネージャーには様々なチームから情報が 集まり、説明責任と意思決定に責任を持つ マネージャー Product Team Product Dev Team Marketing Team Sales Team CS Team 要望 Feature Features & Issues 要望 Feature 要望 Features 要望 Feature 要望 Feature 課題 Issues 様々なグループの 意思決定に 影響を与える 情報を元に組織内の影響を与える ナイーブな事も難しい事も些細な事も 様々な情報が集まる。 マネージャーは情報のハブになることが 多い。
9. ピープルマネジメントに責任をもつマネージャーとは？ Click 9 あらゆるコトとヒトに関わるので、曖昧さと 抽象度が高い事象を進める事が多い マネージャー Product Team Product Dev Team Marketing Team Sales Team CS Team 要望 Feature 抽象度の高い Features & Issues 要望 Feature 要望 Features 要望 Feature 要望 Feature 課題 Issues 様々な抽象度が高い 事象と対峙する 曖昧 or よくわからない 曖昧 or よくわからない 答えがないコトに取り組む 外的要因でコントロールできないことや ヒトなので完全にコントロールができない 等、やってみてその変化が良い方向に動く事 もあるし、悪い方向に動くこともある。
10. ピープルマネジメントに責任をもつマネージャーとは？ Click 10 つまりあなたはボトルネックになりやすい マネージャー Product Team Product Dev Team Marketing Team Sales Team CS Team 要望 Feature Features & Issues 要望 Feature 要望 Features 要望 Feature 要望 Feature 課題 Issues 様々なグループの スピードに影響する 全知万能というバイアスがかかる マネージャーになった途端、全知万能 というバイアスが入る。 実態は情報をより多く、速く周りよりも取得 しているだけ。という事も多々ある 「知っている」のと「対処できる」 は、別の話。
11. ピープルマネジメントに責任をもつマネージャーとは？ Click 11 意思決定に考える時間がないと、 様々なグループのムダが発生する マネージャー Product Team Product Dev Team Marketing Team Sales Team CS Team 要望 Feature 本質的ではない Features & Issues 要望 Feature 要望 Features 要望 Feature 要望 Feature 課題 Issues 様々なグループの ムダを生み出す 情報整理と考える時間 考えるために情報整理をする。 情報が散らかっていると、 素早く意思決定ができない。 素早さと正しさの意思決定において 時間管理と情報整理はマネージャーに おいて重要な事。 「沢山の仕事で時間がなく、 じっくり考える時間を作れない。」 という矛盾した状況をまずどうにか 抜ける事が重要
12. 12 ピープルマネジメント
13. 01 ピープルマネジメント Click 13 ピープルマネジメントで必要な事 構造や場に アプローチする 我々の集まった目的を 共有する ヒトに行動変化の きっかけを与える
14. 01 ピープルマネジメント Click 14 私達は社会的な問題から 中長期的に慢性的な人手不足に陥る 参考: 経済産業省 IT 人材需給に関する調査報告書 経済産業省が平成 28 年 6 月に公表した「IT 人材の最新動向と将来推計に関する調査1」に よれば、IT 需要が今後拡大する一方で、我が国の労働人口（特に若年人口）は 減少が見込まれ、IT 人材の需要と供給の差（需給ギャップ）は、需要が供給を上回り、 2030 年には、最大で約 79 万人に拡大する可能性があると試算されている。 IT 人材が、2030 年で最大 79 万人の足りない 外的要因でコントロール できない事 大量雇用から人を資源とした 育てるマネジメントが必要
15. 01 ピープルマネジメント Click 15 ヒトは欲求を求める生き物である 自己超越欲求 生命を維持するための欲求 食欲、睡眠欲、呼吸等 安心や安全に関する欲求 生活環境や金銭的な不安等 集団や組織に所属したい欲求 家族や組織等に受け入れられたい等 他社から認められたい欲求 家族や組織等に認められたい等 自分の能力や才能を最大限に発揮したい欲求 自分らしく生きていきたい等 自分のエゴを超えて他者や社会の事を思う 欲求 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求 マズローの欲求段階 低次の欲求が満たされることによ り、高次の欲求が生じるようにな る。 承認欲求は悪い事ではない 何かを認められたい。という欲求 なのでモチベーションは 高く保ちやすい 自身の危険 や安全 自身の周り について あなた について 社会に ついて
16. 16 02 ピープルマネジメント 構造や場にアプローチする
17. 01 ピープルマネジメント Click 17 エンジニアのワークエンゲージメントは低い 参考: IT 業界における働き方改革 －ワーク・エンゲージメントと創造的協働を高める 10 の提言－
18. 01 ピープルマネジメント Click 18 なぜワークエンゲージメントが低いのか？ 過剰分析 過剰計画 過剰規制 過剰な分析によって、 数字で全てを結論つけてしまう 過剰な計画によって、 変更の余白がなくなってしまう 過剰な規制によって、 想像の余地がなくなってしまう 3つの過剰で 生まれたもの 局所最適化と 分断 Product Team Product Dev Team Marketing Team Sales Team CS Team 最適化 最適化 最適化 最適化 最適化 過剰な局所最適化で分断されてムダが発生 パターン A 過剰分析パターン
19. 01 ピープルマネジメント Click 19 なぜワークエンゲージメントが低いのか？ 曖昧分析 曖昧計画 曖昧規制 曖昧な分析によって、 指標が信用できない 納期は約束されているが 計画が曖昧 納期ドリブンでの契約 ベータ版なのに大きな宣伝 3つの曖昧で 生まれたもの 疲弊と 無関心化 お伺い リレー パターン B 曖昧さによる疲弊と無関心 部門 無関心 言ったことで変わらない
20. 01 ピープルマネジメント Click 20 末端工程になればなるほど、余地も余白もなく 想像も難しくなる 分析 計画 実行 3 つの過剰・曖昧さで末端に行けば行くほど、 覆すのが難しくなる Product Team Enginner Team ダブルパンチで 超絶難易度が高い Marketing Team Sales Team CS Team 最適化 最適化 最適化 最適化 最適化 サイロ化による弊害 利益優先 売上優先 ユーザー 優先 > >
21. 01 ピープルマネジメント Click 21 開発パフォーマンスパターン Product Team Marketing Team Sales Team CS Team 最適化 最適化 最適化 最適化 最適化 リレー(サイロ)型 Product Team Product Dev Team Marketing Team Sales Team CS Team 最適化 最適化 最適化 Enginner Team 各工程の担当がバトン を渡すように進む オーバーラップ型 担当領域を部分的に オーバーラップする ユーザー課題解決 Team 最適化 スクラム型 強い結びつきで 組み合わせる 開発パフォーマンス 低 高 参考:AIS　一般社団法人 行政情報システム研究所 2020年4月号特集　アジャイル／スクラムから考える開発と経営
22. 01 ピープルマネジメント Click 22 組織パフォーマンスパターン Product Team Marketing Team Sales Team CS Team Enginner Team リレー(サイロ)型 Product Dev Team Business Team Business Team Product Growth Team オーバーラップ型 ユーザー課題A 解決 Team ユーザー課題B 解決 Team スクラム型 部門で構成 近接する部門で構成 目的で構成 適応とイノベーション 低 高 一人当たりの目的の裁量 少 多
23. 01 ピープルマネジメント Click 23 バーンアウト(燃え尽き症候群)にならないよう に構造にもアプローチする 仕事に対して過度のエネルギーを費やした結果、疲弊的に抑うつ状態に至り、仕事への興味・関心や自信を低下させた状態。 バーンアウト(燃え尽き症候群) マネージャー Product Manager Marketing Manager Sales Manager CS Manager 構造にアプローチしやすい ユーザー課題B 解決 Team Product Dev Team Product Growth Team 徐々に変化させる それはマネージャーの仕事？ 誰も動かなければ、提案する。 構造が矛盾を作る。 構造も環境も色々考える。 ただし、構造変更は全体影響が大きい ので慎重に。
24. 24 02 ピープルマネジメント 我々の集まった目的を共有する
25. 01 ピープルマネジメント Click 25 組織のミッションビジョンバリューやパーパス 人々を屋外に誘い出します 冒険心を掻き立てます 社会的欲求のきっかけを 提供する 運動の推奨 つながりを作る 社会的欲求の場を 提供する 安全欲求のきっかけを 提供する 参考:Niantic ストーリー ゲーム内でヒトの 承認欲求を満たす 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求
26. 01 ピープルマネジメント Click 26 目的とメンバーの欲求をつなげる 組織が 解決したい課題 組織の 目的と背景 目標 売上 利益 得たいものと目的をマッチングする マネージャー メンバー 目的を達成することであなたに 何の経験が得られるか？ マッチング 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求
27. 01 ピープルマネジメント Click 27 No と言える勇気も必要 メンバー マネージャー 売上 利益 技術だけでお金 が欲しい!! サービスが成長するから 払える原資が増える 技術は手段であって 目的ではないことを伝える マネージャー 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求 メンバー 燃える 方向を 修正する アンマッチな欲求 事業会社
28. 01 ピープルマネジメント Click 28 技術は手段であって、目的ではない事伝える ユーザー志向への変化 ビジネス要求やニーズに 対してスピードが求められる IT サービス A IT サービス B IT サービス C モノが溢れる 時代 選択肢は 少ない 昔 モノの選択が 少ない 今 ユーザーが 選ぶ時代 IT サービスの 競争激化 急激な環境の変化への対応 ビジネスと IT サービスの距離が 短くなったので、エンジニアも 最低限のビジネススキルが 要求される時代に変化 アナログ デジタル
29. 01 ピープルマネジメント Click 29 マネージャーとして直接メンバーに与えられる のは知識と経験 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求 集団や組織に所属したい欲求 家族や組織等に受け入れられたい等 他社から認められたい欲求 家族や組織等に認められたい等 自分の能力や才能を最大限に発揮したい欲求 自分らしく生きていきたい等 自身の周り について あなた について マネージャー メンバーに対して知識と経験の場を 提供する努力をする メンバー バジェット お金が欲しい!! 分配されるもの 経験が金銭に変わる 売上(原資)がなければ、その メンバーがどんなに頑張っても 給与は上がっていかない。 知識と経験は中長期的に金銭に 交換される。 経歴書にかける内容を 積ませてあげるように努力すれば 中長期的にメンバーの給与は 上がっていく。 持続的な金銭価値をしっかり説明 する。
30. 01 ピープルマネジメント Click 30 トレードオフではなく、トレードオンで考える 質とスピード ソフトウェアを持続的に成長 させるためには、基盤となる ソフトウェアの品質を一定に 保たないとスピードで競争に 負ける。 技術負債やソフトウェア開発手法の 組織の浸透等は、開発組織だけの問 題ではない。 Volatility 変動性 Uncertainty 不確実性 Complexity 複雑性 Ambiguity 曖昧性 ソフトウェア サービス 技術 当たるサービスに 不確実性がある 技術負債も 貯まりやすい サービス スピードを求めるならば 技術品質の維持も重要になる 二項対立で考えない
31. 31 02 我々の集まった目的を共有する 評価と指標
32. 01 ピープルマネジメント Click 32 単純な指標をそのまま目標にしない グッドハートの法則 計測結果が目標になると、その計画自体が役に立たなくなる。 指標 売上 利益 マネージャー メンバーの 目標 組織が 解決したい課題 組織の目的 メンバー マネージャー の目標 評価 指標しか 見なくなる 課題をより多く 解決したいから 売上が欲しい 目的を見失う ２つの Issue 測定する情報の歪曲 測定基準の改ざん
33. 01 ピープルマネジメント Click 33 測定する情報の歪曲 ユーザーに届けられた 価値ではなく単純な金銭で 測定する 簡単に測定できるもの しか測定しない 金銭は結果であって、 目的ではない コストしか測定しない 利用した金額やリソースを 測定したほうが簡単 何の価値を 生み出したのか？に フォーカスされていない 標準化による情報の 質の劣化 コンテキストが失われる 測定の意味を見失う 参考: 測りすぎ：業績評価が組織をダメにする？ 変動性、不確実性、複雑性、曖昧性(VUCA) なソフトウェア開発は、測定の難しさがある。 難しいので、取りやすい情報から測定しだす。
34. 01 ピープルマネジメント Click 34 測定基準の改ざん - キャンベルの法則 - 小さい PR を沢山作ると 改ざんができる PR 数 = 開発生産性 ハードルを下げる 達成度自体をごまかす 都合の悪い数字を 無視・除外をする できそうな結果のみを 開示する 定量的な社会指標が社会的意思決定に使われれば使われるほど、汚職の圧力にさらされやすくなり、 本来監視するはずの社会プロセスを捻じ曲げ、腐敗させやすくなる 目標に対する圧力が強ければ 強い程、改ざんに動く。
35. 01 ピープルマネジメント Click 35 定量化にこだわり過ぎない 達成する為のストーリー。すなわち設定に着目する。 目的とずれた設定になっていないか？ 手段をそのまま記載していないか？ どうあるべきか？の ストーリーに着目する 言語化できていないものは定量化するのは、難しい。 一方で量をこなさないと言語化はできないので、 定性的 = ダメという考え方をやめる。 定性的なものも 混ぜる 難しい事を念頭において、ストーリーをしっかり考える。 時間をある程度かける。 定量化は慎重に 測定を目標 = 悪でもない 測定をしないほうが良い。も 改善の結果を証明できなくなる。 「測るべきもの」 「目的」 「試してみるもの」 を吟味することが重要。
36. 36 02 ピープルマネジメント ヒトに行動変化のきっかけを与える
37. 37 02 1 on 1 個別に聴く
38. 01 ピープルマネジメント Click 38 1 on 1 重要なのは共感 まずは、聞く。傾聴をすることで 新たな発見や知見を得られることはある。 雑談から生まれるアイデアも沢山ある。 悩み マネージャー 思っていること etc.. 雑談 メンバー 全員がオープンな場を好むわけではない 集団でも本音を話せる人とそうでない人が いることを認識すること。 オープンな場所だと話しづらい人も いるのでリモートや個室で 1 on 1 も検討す る。 重要なのは、本音が話しやすい環境作り
39. 01 ピープルマネジメント Click 39 下位の欲求で問題で発生している場合は まずその不安に集中できるように調整する メンバー 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求 寝不足気味。 家族が病気。 生命を維持するための欲求 食欲、睡眠欲、呼吸等 安心や安全に関する欲求 生活環境や金銭的な不安等 自身の危険 や安全 マネージャー 負荷をかけないように 調整する。 まずは調整 業務量の調整やタスクの調整等
40. 01 ピープルマネジメント Click 40 マネージャーが全てを解決しなくて良い。 接続して解決する方法も考える チームが立ち往生するリスク チームや部署では解決できない悩みは沢山ある。 わからない人達がわからない事をやった結果は わからない事が多い。 やみくもにやると、中長期的にメンバーも チームも袋小路にはいってしまう。 ヒントを貰えるならば、近道ができる。 悩み マネージャー メンバー マネージャーが解決方法を 知らない メンバー 知っていそうな 人に接続する 接続 Product Team Marketing Team CS Team 色々な接続先と普段 から会話をしておく Give & Take を忘れずに 何かをもらったならば、 何かを返すよう(最低でも感謝)に心がける。 その循環であなたの仕事は劇的に楽になる。
41. 01 ピープルマネジメント Click 41 ポジティブゴシッピング 他人に対して積極的な評価や称賛を伝える行為。 他人に対して積極的な評価を伝えることで、相手の自尊心や自己肯定感を高め、良好な人間関係の構築に寄与できる。 マネージャー メンバー コミュニケーションが少ない・褒めるのが恥ずかしい 他部門の人 仲介コストが発生しやすい マネージャー メンバー コミュニケーションが多い・褒めている 他部門の人 仲介コストが発生しにくい
42. 42 02 暗黙知と形式知 行動変化の場を提供する
43. 01 ピープルマネジメント Click 43 つなぐ為の暗黙知と形式知 共同化 (Socialization) 表出化 (Externalization) 連結化 (Combination) 内面化 (Internalization) 創発場 対話場 システム場 実践場 共通の体験を通じて 暗黙知を移転させるプロセス 個人の暗黙知を言語化し メンバーと共有するプロセス 異なる形式知を組み合わせて 新たな知を創出するプロセス 新たに得た形式知を 学習により体験するプロセス 暗黙知 形 式 知 形式知 暗 黙 知 SECIモデル 個人が持つ知識や経験などの 暗黙知を、形式知に変換した上で 組織全体で共有・管理し、 それらを組み合わせることで また新たな知識を生み出す フレームワーク。 スパイラルの ように絶えず 繰り返す 参考:AIS アジャイル／スクラムから考える 開発と経営
44. 01 ピープルマネジメント Click 44 共同化 表出化 (Externalization) 創発場 共通の体験を通じて 暗黙知を移転させるプロセス きっかけを作る 勘や感覚等、言語化できない。 またはできていないものを 交換して新たな発想やアイデアの きっかけをつなぐ。 何かしらの体験や 経験によって、 暗黙知を他人に 移転させる 他者と知識や経験の交換の場 モブプログ ラミング ワーク ショップ 立ち話
45. 01 ピープルマネジメント Click 45 表出化 共同化 (Socialization) 対話場 言語化は難しい 一言に言語化といっても 言語化作業は難易度が高い。 (言語化の慣れが必要) 不完全でも問題ないので、一旦 文章化することが重要 暗黙知を言語化して、 形式知に変換する 暗黙知を形式知に変換する場 ドキュメン ト作成 マニュアル 作成 会議 個人の暗黙知を言語化し メンバーと共有するプロセス
46. 01 ピープルマネジメント Click 46 連結化 連結化 (Combination) システム場 小さく始める 全体に適用、大規模なツールを 作ると、手戻りたくない心理が 出て、ムダが生まれる。 小さく始めて、改良・改善が しやすいのを意識する。 異なる形式知を 組み合わせて 新たな知を創出する 形式知と形式知が組み合わさる場 分析ツール の作成 ツールの 作成 プロセスの 作成 異なる形式知を組み合わせて 新たな知を創出するプロセス
47. 01 ピープルマネジメント Click 47 内面化 内面化 (Internalization) 実践場 質の前に一定の量を 一定の量を行わないと新たな 発想や気づきは出てこない。 量から質に転換されるので一定の 期間や時間が必要な事を 忘れない。 反復練習等を行い、自分 のものにして、形式知 から個人の暗黙知へと また変化する 実践をして新たに得たものを再び 暗黙知に変換する場 分析ツール の実践 ツールの 実践 プロセスの 実践 新たに得た形式知を 学習により体験するプロセス
48. 48 02 権限委譲 必要な権限を渡す
49. 01 ピープルマネジメント Click 49 知識と経験と欲求を満たせるためには 一定の権限が必要 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求 マネージャー 権限委譲を意識する 私に権限がないと思い込んでいるメンバーと渡していると思っているマネージャー。 よくある光景で、このすれ違いが知らない間に不満がたまるケースが多い。 一方で多大に権限を渡すと過多になってメンバーが潰れてしまうリスクもある メンバー 権限がないと 実現できない 渡していたと 思っている すれ違いが よく発生する
50. 01 ピープルマネジメント Click 50 権限移譲の 7 段階 指示する 意思決定者が 決定して伝える 説得する 意思決定について 納得させる 相談する 決定前に相談する 合意する チームと一緒に決定する 助言する 決定に助言する 尋ねる 決定後に確認する 任せる 影響を与えない 作業レベル マネージャー メンバー 指示する 指示され ている マネージャー チームレベル チーム 助言する 説得され ている 役割レベル マネージャー テックリード 任せる 任せら れている 権限足りてる？って聞く 権限の要求は、役割や評価者 に嫌われたくない。という 心理から要求側は言いづらい もの。 マネージャー側から聞いて あげる事が重要。
51. 02 マネージャーとは？ Click 51 権限移譲はめちゃくちゃ重要 いろいろな人や部署 忙しい マネージャー ボトルネック メンバー チーム テックリード マネージャー 任せる 相談しづらい 権限委譲ができる = スケールしやすい 組織はスケールを望む。 スケールができるマネージャーは、組織にとっても優秀なマネージャー。 負のループ
52. 52 まとめ
53. 01 ピープルマネジメント Click 53 つないでそのヒトや場の意思決定を サポートしてあげるのがピープルマネジメント 生理的欲求 安全欲求 社会的欲求 承認欲求 自己実現 欲求 ミッション ビジョン バリュー マネージャー 組織 構造や場に アプローチする 目的の共有 行動変化 ヒト 理論と欲求を合わせる 開発手法・経営・集団心理等の理論を 持ちつつ、個々の欲求を満たして、 行動変化に発展させて目的と win-win の関係を成立させる
54. 54 トーマス・エジソン 「失敗は積極的に行ってい きたい。なぜなら、成功と 同じくらい貴重だからだ。 失敗がなければ、何が 最適解なのかわからない だろう。」
55. 参考文献 Click 55 • 経済産業省 IT 人材需給に関する調査報告書 • AIS　一般社団法人 行政情報システム研究所 2020年4月号特集　アジャイル／スクラムから考え る開発と経営 • NRI 測りすぎ：業績評価が組織をダメにする？ • Niantic ストーリー • IT 業界における働き方改革 －ワーク・エンゲージメントと創造的協働を高める 10 の提言－