エンジニアからエンジニアチームのリーダーになった話

エンジニアのマネージメントで悩んでいる人が集まる会 #1(https://em-meetup.connpass.com/event/118019/) 発表資料

Transcript

1. エンジニアから エンジニアチームの リーダーになった話 株式会社ヴァル研究所 ナビゲーション開発部 API Platform Team リーダー 山崎 恭史 〜マネージャ１年目奮闘中〜
2. 自己紹介 ▪ 山崎 恭史（やまざき たかし） ▪ 株式会社ヴァル研究所 ナビゲーション開発部 API Platform Team リーダー ▪ 趣味: ゲーム（スト5）、漫画 ▪ 好きな著書: あなたのチームは、機能してますか？ ▪ 好きなマネジメントフレームワーク: スクラム 2 @zaki_taka4
3. 会社紹介 ▪ 株式会社ヴァル研究所 ▪ 創業43年目の老舗ソフトウェア会社 ▪ 経路検索ソフト「駅すぱあと」で誕生30周年 3
4. 今日の話 ▪ 第一回のテーマ： みんなも心の底にあるようなエンジニアのマネージャーの悩み 共有会 ▪ 話のテーマ： マネージャー1年目の自分がエンジニアチームのリーダーをや ると決めてから、何を悩み、何をして、今どう思うか 4
5. アジェンダ ▪ 自分がリーダーになるまでの経緯 ▪ 自分がリーダーとして心がけていること ▪ リーダーの悩みと取り組み ▪ マネジメントについて思うこと 5
6. 自分がリーダーになるまでの経緯 6
7. マネージャまでの経緯 ▪ 2010年4月 株式会社ヴァル研究所に入社 ▪ 2010年7月 ~ 2012年6月 スマホアプリを開発 ◦ エンジニア時代 ▪ 2012年7月 ~ 2014年6月 ログを利用した研究 ◦ 研究者兼エンジニア時代 ▪ 2014年7月 ~ 2015年6月 広告とIDサービスの開発・運用・保守 ◦ プレイングマネージャー時代 ▪ 2015年7月 ~ 2018年6月 駅すぱあとWebサービスの開発・運用・保守 ◦ エンジニア兼マネージャー見習い時代 ▪ 2018年7月 ~ API商材の開発チームのリーダー 7
8. エンジニア時代 ▪ 2010年7月 ~ 2012年6月 ▪ エンジニアとしてスマホアプリを開発 ▪ 右も左も分からない、とにかく振られたタスクをこなす ▪ 1年間ほど、すげー楽しく働けるチームを体験 8
9. 研究者兼エンジニア時代 ▪ 2012年7月 ~ 2014年6月 ▪ ログの集約システムの開発がメイン ▪ アジャイルとの出会い ◦ インセプションデッキ、カンバン、朝会、スプリントなど様々なプラクティスに触 れる 9
10. プレイングマネージャー時代 ▪ 2014年7月 ~ 2015年6月 ▪ ログの集約基盤の開発とマネージャー的な役割の兼任 ▪ チーフという名の「役割」（「役職」ではなく） ▪ 開発にはアジャイル形式を採用していたが上手くまわらず、精 神崩壊の危機 ▪ 開発と合わせて、チームの計画、目標作成、メンバの進捗確 認、上司への報告、アジャイルの運用等、もはや何を考えて良 いのか分からない状態 10
11. エンジニア兼マネージャー見習い時代 ▪ 2015年7月 ~ 2018年6月 ▪ 上手くいっている（様に見える）チームのマネジメントは何が違うのか？を知りたくて 異動を希望。 ▪ 駅すぱあとWebサービスの開発・運用・保守をするチームに所属（今いるチームの 前身） ▪ エンジニアとして活動しつつもマネジメントの方向に進むことをほぼ決意 ▪ 認定スクラムマスターを獲得し、スクラムへの理解も深まる。 ▪ リーダーを尊敬しつつもマネはできないと気づく、と同時にマネジメントのやり方は 一つではないと思う。 11
12. そして今に至る 12
13. リーダーになるまでの8年間の学び 13 ▪ アジャイル、スクラムという開発は時代に合っている ▪ プレイングマネージャーは極力避ける ▪ マネジメントのやり方は人それぞれ、自分にあったやり方を見 つける ▪ 集団がチームになることの難しさ
14. 自分がリーダーとして心がけていること 14
15. ヴァル研究所におけるリーダー像（個人見解） ▪ いわゆるチームリーダーとチームマネージャーをあわせたもの ◦ チームの方針、目標を決め、チーム目標の達成に責任を持つ ◦ メンバーの勤怠管理や評価、リソース管理、メンバーの成長に責任を持つ ▪ 必ずしも役職名と職責が一致するわけではない 15
16. 自分のチーム環境 ▪ 駅すぱあとのWebAPI、駅すぱあとWebサービスを軸にヴァル 研究所のAPI商材を担当するチーム ▪ チームの職務としては、開発、運用、保守、だけでなく、営業同 行やサポート、認知活動、バックオフィス効率化となんでも ▪ メンバーは、リーダー１名、メンバー7名の合計8名 ▪ スクラムをベースとした働き方で、1週間スプリント 16
17. 自分がリーダーとして目指すもの ▪ チームとなり、チームとして成果を出す 17
18. チームとは ▪ 人が集まっただけではグループ ▪ 同じ目的・目標を共有し、その達成ために協力して行動するグ ループ ▪ チームになることは難しい 18
19. ピクサー本 “二流のアイデアを優秀なチームに与えたらそれを修正するか、捨ててもっといいものを 思いついてくれる” 19
20. タックマン・モデル 出典rd-c.com 20
21. チームになるには信頼関係の構築 ▪ “「チームワークは信頼を築くことから始まると言いましたね。そのための唯一の方 法は、完全無欠でありたいという気持ちを克服すること」” 引用元: あなたのチームは、機能してますか？ パトリック・レンシオーニ 著 21 チームが機能不全に 陥る五つの要因
22. リーダーをやらせてもらっている（意識） ▪ 目標とするリーダーに、どういう心構えだったかを質問 ▪ リーダーは、基本的には役割であり、上下ではない ▪ 自分にはしっくりきて、ひとつのリーダー像が描けた ▪ 自分の目標とする人がいたら、心構えを聞いてみるのはオス スメ ◦ マネジメントのやり方に正解はないが、自分に合うやり方はある 22
23. リーダーになって最初に考えたのは 如何にしてチームになるか 23
24. リーダーの悩みと取り組み 24
25. リーダーになってからの悩み 25 ▪ リーダーとは何をするのか？ ▪ チームの日々の業務をどうやって回すのか？ ▪ どうやってメンバが成長できる環境を作るか？
26. リーダーとは何をするのか？ 26
27. リーダーは何をするのか？ ▪ チームリーダーの責任（個人見解） ◦ チームの目標の達成とチームメンバの成長（自分を含む） ▪ エンジニア時代ではそこまで強く意識することはない ▪ 自分の職責を理解することで、自分が何に対して責任がある かが明確になる 27
28. チームの日々の業務を どうやって回すのか？ 28
29. スクラムによるマネジメント ▪ これまでのスクラムの経験と知識があり、チームに土台があっ た ▪ スクラムは変化が激しい複雑な状況に対応するための フレームワーク ▪ 「スクラムをやる」というやり方の失敗 ▪ 自分の中のマネジメント型の限界と、マネジメント型とは違う働 き方としてのスクラム ▪ 結果として、日々の業務はなんとか回せている 29
30. （補足）スクラムとは ▪ 複雑で変化の激しい問題に対応するためのフレームワーク ▪ 実際の経験と既知に基づく判断によって知識が獲得できる経験 主義を基本にしている ▪ 経験主義は、以下の３本柱に支えられている ◦ 透明性: いわゆる見える化 ◦ 検査: いわゆるレビュー、フィードバック ◦ 適応: いわゆるカイゼン ▪ スクラムを一言で言うと、「働き方」 ◦ 例えると、野球をやるか、サッカーをやるか 30
31. スクラムへの期待と不安 31
32. チームとしてのスクラムへの理解 ▪ 「スクラムをやる」ではなく、「自分たちのチームが成果を出す にはスクラムがあっている」 ▪ スクラムをやる理由を、リーダーだけでなくメンバーも理解する ▪ プラクティス先行の導入では、スクラムへの不信感が募るだけ だった ▪ チームのキックオフでメンバに対して説明 32
33. チームなりのスクラムの実施 ▪ スクラムではなく、スクラムベースであること ◦ スクラムマスターがいなければ難しい ▪ タイムボックスを守ることを重視 ◦ チームの特性にもよる（楽しく働きたい、効率性を重視したいか） ◦ 朝会の小話をやめて、プロダクトバックログのリファインメント を毎週実施 ◦ チームの人数が多いほど重要 ▪ スクラムガイドで定期的に目的と役割の責任を共有 ◦ スクラムは得てしてプラクティス先行になりやすい ▪ メンバーが見積もり、メンバーは全力を尽くすことに責任を持つ ◦ マネジメント型の限界に対するひとつの解 ◦ 長期的に成果を出し続けるためには必要な考え 33
34. どうやってメンバが 成長できる環境を作るか？ 34
35. チームのマネジメントを大別すると ▪ 日々の業務のマネジメント ▪ メンバの成長のマネジメント 35
36. メンバの成長のためにメンバの理解を深める ▪ 色々な取り組みを実施 ◦ 1on1 ◦ 180度評価 ◦ ジョブディスクリプション 36
37. 1on1 ▪ 毎月1回実施 ▪ 以下のルールを共有 ・困ってることや知っておいて欲しいことか、なんでも話す場 ・一人あたり15分~30分目処 ・進捗確認の場ではない ・（話すことがなければ即終了） ▪ 普段なんとなく思っているようなことでも共有してもらえる ▪ 自分がチームに発信したことについて（自分であれば、チームになりたい）、フィード バックがもらえる ▪ 個々のメンバを向き合う場としても非常に重要 37
38. 180度評価 ▪ 半年に１回実施（なので、まだ1回だけしかやってない） ▪ 全社に公開することをメンバーに承諾（チーム内の取り組みにしない） ▪ 匿名で以下の内容に回答してもらった ・リーダーを評価すると10点満点中何点？ ・良かった点（Good） ・良くなかった点（Bad、Problem） ・改善して欲しい点、アドバイス（Improvement、kaizen） ・その他なんでも言っておきたいこと ▪ メンバーからの本音のフィードバックが得られ、リーダー側へのメリットがとても大き い 38
39. ジョブディスクリプション ▪ 自分がどんな役職をやってみたいのかを上げてもらう ▪ やり始めた理由は、スクラムだけだと日々の業務をこなすだけになりがちになってし まうため ▪ チームが成長するためには、メンバの適性を知ることが大事。その上で、ジョブディ スクリプションという考えを利用してみた ▪ 年明けから始めたのでこれからだが、メンバの特性を知るには良かった 39
40. メンバの成長のマネジメント 絶賛悩み中！ 40
41. マネジメントについて思うこと 41
42. マネジメントの難しさ ▪ マネジメントは組織、業務、メンバー、そして自分によって変わ る ▪ 常に状態は変わり、上手くいっている時もあれば、上手くいか ない時もある ▪ 自分の成長、モチベも自分がマネジメントする、というのは実 は辛い 42
43. リーダーとマネージャーの区別 ▪ まずは自分の職責が何かを明確にすることは大事 ▪ リーダーとマネージャーが別だと良いと思うこと ◦ リーダーとマネージャーはやることがそもそも違い、日々取り入れる情報も違 う。 ◦ リーダーは、市場を追いかけ、ビジョンを見せる ◦ マネージャーは、チームの中をみて、メンバををみる ▪ リーダーとマネージャーが同じだと良いと思うこと ◦ メンバーの適正に合わせてチームのビジョンを考えることができる 43
44. プレイングマネージャはオススメしない ▪ リーダー、マネージャーの作業は創造的作業のため外からは 作業が見えづらい ▪ そのため、始める前はついつい現場の作業とできると思ってし まいがち ◦ （自分はそうでした・・・） ▪ マネジメントにリソースを割きたいのであれば手放すことを考 える ◦ 視点や視野が全く違う。特にメンバーの成長のマネジメントは。 44
45. 最後に ▪ チームとして成果を出す、ということを基準からぶらさない ▪ チームの成長に繋がると思うことを色々やってみる 45