20代でマネジメントにチャレンジするということ / To challenge management in 20's

2019/11/30 Developers Boost 2019 #devboost
https://event.shoeisha.jp/devboost/20191130

Transcript

1. 20代でマネジメントに チャレンジする ということ 2019/11/30 #devboost Developers Boost 2019 Yoshiki Iida
2. whoami ◂ 飯田意己(@ysk_118) ◂ 株式会社クラウドワークス 執行役員 兼 エンジニアリングDiv GM ◂ マネジメントとかプロダクト戦略とか色々 ◂ 2018/4〜マネージャー ◂ 2019/5〜執行役員 ◂ 一般社団法人アジャイルチームを支える 会 理事 ◂ アジャイルチームを増やす支援 2
3. 3 一般社団法人 アジャイルチームを 支える会 https://agileteam.doorkeeper.jp/
4. クラウドワークス について
5. crowdworks.jpについて 5 オンラインで直接つながり マッチング 仕事依頼 業務実行・納品 発注者＝クライアント （企業・個人） 50万社 受注者＝クラウドワーカー （主に個人） 260万人
6. crowdworks.jpについて 6
7. 組織構造 7 職能横断組織
 ×
 スクラムチーム

8. エンジニアブログ 8
9. 今日話すこと ◂ キャリア戦略としてのマネジメントの位置付け ◂ マネジメントのリアル ◂ 困難の乗り越え方、そして得られるもの 一番伝えたいこと: 「マネジメントにチャレンジする人を増やしたい」 9
10. 注意 ◂ 私個人の経験の中で感じたものをベースに話します ので再現性があるかはわかりません ◂ 役割の話が多く出てきますが、会社によって定義は 様々だと思いますのでご意見・ご質問があったらぜ ひディスカッションさせて下さい 10
11. マネジメントに興味のある人？ 11
12. 1. キャリア戦略における マネジメントの位置付け
13. エンジニアのキャリア 13 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ...
14. エンジニアのキャリア 14 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー
15. 技術的な責任を負うとは ◂ 一番わかりやすいのはCTOという肩書き ◂ 最も技術に精通しているからなるわけではない ◂ 会社側面から見た時、期待されるのは 「経営メンバーの中で最も技術に責任を持てること」 ◂ すなわち、エンジニアでありながら経営者でもあるというこ と ◂ 責任を持つ=やりきること ◂ 技術、組織、事業観点全て必要になる ◂ ここに大きなギャップがある 15
16. エンジニアのキャリア 16 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー このパターンもあるが
17. エンジニアのキャリア 17 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー 結局全部必要になる
18. マネジメントの立ち位置 ◂ 組織の支援をし、意思決定をし、全体最適で成 果に導く ◂ 成果にコミットするには技術、組織、事業それぞ れの観点を理解する必要がある ◂ 同じ支援の役割としてスクラムマスターも存在す る ◂ スクラムマスターはマネージャーもステークホルダーと 捉えてさらに外側から俯瞰的にプロセスを最適化する 立ち位置 18
19. スクラムマスターのプロセス最適化対象 スクラムチーム マネジメントの立ち位置 19 スクラムマスター 開発者 プロダクトオーナー マネージャー 支援し、成果に導く
20. スクラムマスターのプロセス最適化対象 スクラムチーム マネジメントの立ち位置 20 スクラムマスター 開発者 プロダクトオーナー マネージャー 支援し、成果に導く 全体最適視点 チームにとっては不都合な 要求をする時もある 現場視点 チームのプロセスの 最適化 パワーバランスが 取れると良い
21. マネジメントの立ち位置 21 マネージャー チーム チーム チーム 成果 成果 成果 全体としてきちんと成果になっているか？
22. マネジメントの立ち位置 22 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー 全員とコミュニケーション するし責任も持つ
23. マネジメントの立ち位置 23 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー 逆に言えばフィードバックも集 まりやすい 若いうちにやれば みんな言いやすいので より集まりやすい
24. ぼくの経験プロセス 24 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー
25. ケース: 創業CTOの場合 25 • 他の人を支援できる • 自走してチームに貢献できる • 支援してもらいながらチームに貢献できる • ステークホルダーや影響範囲 を広げる • チーム・組織の開発をリードで きる • 会社全体の技術・開発・組織・プロダクトに責任を持つ • 組織のマネジメント • チームのマネジメント プロセス 改善 プロダクト マネジメント ... CTO, VPoE, VPoP テックリード マネージャー スクラムマスター プロダクトオーナー ↑経営に入ってから ここの後追いは結構大変
26. マネジメントについてまとめると ◂ 全体最適で物事を考え、全員とコミュニケーション を取り、意思決定する経験を積むことができる ◂ 技術的な責任を負う立場になったときにも絶対に 必要になるため若いうちに経験しておいて損はな い ◂ みんながフィードバックしやすい若いうちにやれる といっぱい失敗できる 26
27. 2. マネジメントのリアル
28. 28 リアルその1 批判
29. 批判を浴びることを割り切る必要がある ◂ 全体最適とは、言い方を変えれば会社都合 ◂ でも会社にいる以上は会社が持続的である必要があ り、それを実行・実現する人が絶対に必要 ◂ マネジメントをやる上で会社側の人間と呼ばれ、 批判を浴びることは覚悟する必要がある ◂ プロセス・環境・待遇、、イケてないというフィード バックも全て集まる ◂ 体は一つなので本当に自分が解決すべきものを 取捨選択する必要がある 29
30. 30 リアルその2 別れ
31. 課題を解決できなければ離れていく人が出る ◂ 解決すべき課題を解決できなければ辞める人は 必ず出る ◂ 課題解決していても辞める人はいる ◂ ポジティブ/ネガティブいずれもあるが、それを見越 して組織の持続性を考える必要がある ◂ 自分がマネージャーになった前後では強い人たち がごっそり抜けたので本当に厳しい状況だった 31
32. 32 リアルその3 ネガティブフィードバック
33. 自分の本来の性格とのギャップに苦しむ ◂ ネガティブフィードバックや、ネガティブな事実を説 明しなければいけない場面が来る ◂ 敢えて言う、言った結果嫌われる、といったことも 起こりうる ◂ でも、優しい性格のままでは組織を腐らせていっ てしまうこともある ◂ 仕事として演じる、という側面は少なからずある 33
34. 34 リアルその4 アンコントローラブル
35. 市場、事業、会社の不確実性 ◂ 会社を取り巻く状況は速いスピードで変化していく ◂ 法律が変わって急な対応を迫られる場合もある し、事業そのものの存続に関わることも発生する かもしれない ◂ 理不尽なものも飲み込んでアカウンタビリティを発 揮しなければいけない 35
36. 36 重たい空気になりましたね ここからはポジティブな話をします！
37. 3. 困難の乗り越え方、 そして得られるもの
38. マネジメントの面白さ ◂ 変化を起こせているときはめちゃくちゃ面白い ◂ 組織全体のファンクションの変化もあるし ◂ 一人一人の成長を間近で感じられる 38
39. 組織もエンジニアリングすべし ◂ 事業の課題を解決するために、どういうチームに どういうミッションを持たせるのか、コミュニケー ションの設計はどうするのか？ ◂ 責務の分割をきちんとしないとチームはパフォー マンスを最大化できないし、課題を誰がトリアージ して誰が対応するのかイベントのハンドリングを設 計しないと不整合が起きてバグる 39
40. 組織全体として誰が何を決めて どのように成果に向かうのかを構造化するイメージ 40 チーム 責務: hoge チーム 責務: fuga チーム 責務: piyo バックログ マネージャー PdM 成果 成果 成果 イレギュラー はマネージャーがトリアージ アウトカムの モニタリング 優先順位 付け アウトカムの モニタリング 相互連携
41. マネージャーのエンジニア的解釈 ◂ エンジニア視点では組織をエンジニアリングする 人だったり組織のアーキテクトのような言い方もで きる ◂ 人に関する問題に追われ続ける役割というのは 味気ない ◂ テンションあがるかっこいい価値づけをしていこ う！ 41
42. 課題の乗り越え方 ◂ 組織の課題は対話が基本 ◂ 様々な人と対話して、信頼関係を築き、本音を聞 き出して、課題を抽象化し、アクションを作っていく 42 建前 建前 建前 本音 本音 本音 真の課題 アクション 表面的な課題 表面的な アクション
43. そもそもどうやったら若いうちになれる？ ◂ 年功序列の大きな会社だと難易度が上がるかもしれません ◂ 小さくスピード感のある会社にいくと可能性は増えます ◂ 全体最適を追求していくと近づきやすい ◂ チーム最適化し過ぎていると、チームのミッションが大きな 意思決定によって変更になった場合に理解できない/時間 がかかる ◂ 全体最適の観点の情報提供を促してみましょう ◂ そしてそれを元にマネージャーの支援をしてみましょう ◂ 組織全体に影響のある変革を積み重ねることができたら そのうち任される 43
44. チャレンジする前の不安あるある ◂ 技術もまだまだなので難しそう ◂ やりたいけど耐えれるかわからない ◂ コード書けなくなるのがちょっと・・ 44
45. 不安への対処: 技術もまだまだなので難しそう ◂ 様々な人と対話するので、一定の技術力は必要 ◂ 少なくとも課題を理解できる、エンジニア以外 の人に説明できる能力は求められる ◂ ただし、最前線であり続ける必要はない（もちろん それを追求してもよい） ◂ 自分より優秀な人はたくさんいるのでその人たち がパフォームする環境を作りたいと僕は思ってい る 45
46. 不安への対処: やりたいけど耐えれるかわから ない/コード書けなくなるのがちょっと・・ ◂ 無理だと思ったらやめればいいし、コード書きたく なったら書けばいい ◂ マネージャーやってから現場に戻る例もある ◂ マネジメントに取り組んだ経験は絶対に無駄には ならない 46
47. 情報の入手方法 ◂ 書籍 ◂ エンジニアリング組織論への招待 ◂ エンジニアのためのマネジメントキャリアパス ◂ イベント ◂ Engineering Manager Meetup ◂ https://engineering-manager-meetup.connpass.com/ ◂ Podcast ◂ EMFM ◂ https://anchor.fm/em-fm/ 47
48. 48 結局、僕は何を得たか
49. 1年半で得られたもの ◂ 組織の変化の当事者になれたということ ◂ その経験を元に社外含めいろんな人と議論できる ようになったということ ◂ 微力ながらこれから変化を起こそうとしている人の 支援ができるようになったということ ◂ 謎の自信 49
50. 組織の問題解決に慣れる価値 ◂ どこに行っても人に関する問題は起きる ◂ マネジメントを当事者としてやった経験は 組織の審美眼となる ◂ マネジメントを続けるにせよ、エンジニアに戻るに せよ大きなレバレッジに 50
51. まとめ
52. まとめ ◂ エンジニアのキャリアの中で会社としてより大きな 責任を持ってチャレンジをしていくなら若いうちに マネジメントにチャレンジするのは悪くない選択肢 ◂ 苦労もあるけれど後々の大きなレバレッジになる ◂ マネジメント=組織をエンジニアリングする人が増 えるとうれしい！ 52
53. ご清聴ありがとう ございました。