エンジニアからエンジニアチームのリーダーになった話

Slide 1

Slide 1 text

エンジニアからエンジニアチームのリーダーになった話株式会社ヴァル研究所ナビゲーション開発部 API Platform Team リーダー山崎恭史〜マネージャ１年目奮闘中〜

Slide 2

Slide 2 text

自己紹介 ■ 山崎恭史（やまざきたかし） ■ 株式会社ヴァル研究所ナビゲーション開発部 API Platform Team リーダー ■ 趣味: ゲーム（スト5）、漫画 ■ 好きな著書: あなたのチームは、機能してますか？ ■ 好きなマネジメントフレームワーク: スクラム 2 @zaki_taka4

Slide 3

Slide 3 text

会社紹介 ■ 株式会社ヴァル研究所 ■ 創業43年目の老舗ソフトウェア会社 ■ 経路検索ソフト「駅すぱあと」で誕生30周年 3

Slide 4

Slide 4 text

今日の話 ■ 第一回のテーマ：みんなも心の底にあるようなエンジニアのマネージャーの悩み共有会 ■ 話のテーマ：マネージャー1年目の自分がエンジニアチームのリーダーをやると決めてから、何を悩み、何をして、今どう思うか 4

Slide 5

Slide 5 text

アジェンダ ■ 自分がリーダーになるまでの経緯 ■ 自分がリーダーとして心がけていること ■ リーダーの悩みと取り組み ■ マネジメントについて思うこと 5

Slide 6

Slide 6 text

自分がリーダーになるまでの経緯 6

Slide 7

Slide 7 text

マネージャまでの経緯 ■ 2010年4月株式会社ヴァル研究所に入社 ■ 2010年7月 ~ 2012年6月スマホアプリを開発 ○ エンジニア時代 ■ 2012年7月 ~ 2014年6月ログを利用した研究 ○ 研究者兼エンジニア時代 ■ 2014年7月 ~ 2015年6月広告とIDサービスの開発・運用・保守 ○ プレイングマネージャー時代 ■ 2015年7月 ~ 2018年6月駅すぱあとWebサービスの開発・運用・保守 ○ エンジニア兼マネージャー見習い時代 ■ 2018年7月 ~ API商材の開発チームのリーダー 7

Slide 8

Slide 8 text

エンジニア時代 ■ 2010年7月 ~ 2012年6月 ■ エンジニアとしてスマホアプリを開発 ■ 右も左も分からない、とにかく振られたタスクをこなす ■ 1年間ほど、すげー楽しく働けるチームを体験 8

Slide 9

Slide 9 text

研究者兼エンジニア時代 ■ 2012年7月 ~ 2014年6月 ■ ログの集約システムの開発がメイン ■ アジャイルとの出会い ○ インセプションデッキ、カンバン、朝会、スプリントなど様々なプラクティスに触れる 9

Slide 10

Slide 10 text

プレイングマネージャー時代 ■ 2014年7月 ~ 2015年6月 ■ ログの集約基盤の開発とマネージャー的な役割の兼任 ■ チーフという名の「役割」（「役職」ではなく） ■ 開発にはアジャイル形式を採用していたが上手くまわらず、精神崩壊の危機 ■ 開発と合わせて、チームの計画、目標作成、メンバの進捗確認、上司への報告、アジャイルの運用等、もはや何を考えて良いのか分からない状態 10

Slide 11

Slide 11 text

エンジニア兼マネージャー見習い時代 ■ 2015年7月 ~ 2018年6月 ■ 上手くいっている（様に見える）チームのマネジメントは何が違うのか？を知りたくて異動を希望。 ■ 駅すぱあとWebサービスの開発・運用・保守をするチームに所属（今いるチームの前身） ■ エンジニアとして活動しつつもマネジメントの方向に進むことをほぼ決意 ■ 認定スクラムマスターを獲得し、スクラムへの理解も深まる。 ■ リーダーを尊敬しつつもマネはできないと気づく、と同時にマネジメントのやり方は一つではないと思う。 11

Slide 12

Slide 12 text

そして今に至る 12

Slide 13

Slide 13 text

リーダーになるまでの8年間の学び 13 ■ アジャイル、スクラムという開発は時代に合っている ■ プレイングマネージャーは極力避ける ■ マネジメントのやり方は人それぞれ、自分にあったやり方を見つける ■ 集団がチームになることの難しさ

Slide 14

Slide 14 text

自分がリーダーとして心がけていること 14

Slide 15

Slide 15 text

ヴァル研究所におけるリーダー像（個人見解） ■ いわゆるチームリーダーとチームマネージャーをあわせたもの ○ チームの方針、目標を決め、チーム目標の達成に責任を持つ ○ メンバーの勤怠管理や評価、リソース管理、メンバーの成長に責任を持つ ■ 必ずしも役職名と職責が一致するわけではない 15

Slide 16

Slide 16 text

自分のチーム環境 ■ 駅すぱあとのWebAPI、駅すぱあとWebサービスを軸にヴァル研究所のAPI商材を担当するチーム ■ チームの職務としては、開発、運用、保守、だけでなく、営業同行やサポート、認知活動、バックオフィス効率化となんでも ■ メンバーは、リーダー１名、メンバー7名の合計8名 ■ スクラムをベースとした働き方で、1週間スプリント 16

Slide 17

Slide 17 text

自分がリーダーとして目指すもの ■ チームとなり、チームとして成果を出す 17

Slide 18

Slide 18 text

チームとは ■ 人が集まっただけではグループ ■ 同じ目的・目標を共有し、その達成ために協力して行動するグループ ■ チームになることは難しい 18

Slide 19

Slide 19 text

ピクサー本 “二流のアイデアを優秀なチームに与えたらそれを修正するか、捨ててもっといいものを思いついてくれる” 19

Slide 20

Slide 20 text

タックマン・モデル出典rd-c.com 20

Slide 21

Slide 21 text

チームになるには信頼関係の構築 ■ “「チームワークは信頼を築くことから始まると言いましたね。そのための唯一の方法は、完全無欠でありたいという気持ちを克服すること」” 引用元: あなたのチームは、機能してますか？パトリック・レンシオーニ著 21 チームが機能不全に陥る五つの要因

Slide 22

Slide 22 text

リーダーをやらせてもらっている（意識） ■ 目標とするリーダーに、どういう心構えだったかを質問 ■ リーダーは、基本的には役割であり、上下ではない ■ 自分にはしっくりきて、ひとつのリーダー像が描けた ■ 自分の目標とする人がいたら、心構えを聞いてみるのはオススメ ○ マネジメントのやり方に正解はないが、自分に合うやり方はある 22

Slide 23

Slide 23 text

リーダーになって最初に考えたのは如何にしてチームになるか 23

Slide 24

Slide 24 text

リーダーの悩みと取り組み 24

Slide 25

Slide 25 text

リーダーになってからの悩み 25 ■ リーダーとは何をするのか？ ■ チームの日々の業務をどうやって回すのか？ ■ どうやってメンバが成長できる環境を作るか？

Slide 26

Slide 26 text

リーダーとは何をするのか？ 26

Slide 27

Slide 27 text

リーダーは何をするのか？ ■ チームリーダーの責任（個人見解） ○ チームの目標の達成とチームメンバの成長（自分を含む） ■ エンジニア時代ではそこまで強く意識することはない ■ 自分の職責を理解することで、自分が何に対して責任があるかが明確になる 27

Slide 28

Slide 28 text

チームの日々の業務をどうやって回すのか？ 28

Slide 29

Slide 29 text

スクラムによるマネジメント ■ これまでのスクラムの経験と知識があり、チームに土台があった ■ スクラムは変化が激しい複雑な状況に対応するためのフレームワーク ■ 「スクラムをやる」というやり方の失敗 ■ 自分の中のマネジメント型の限界と、マネジメント型とは違う働き方としてのスクラム ■ 結果として、日々の業務はなんとか回せている 29

Slide 30

Slide 30 text

（補足）スクラムとは ■ 複雑で変化の激しい問題に対応するためのフレームワーク ■ 実際の経験と既知に基づく判断によって知識が獲得できる経験主義を基本にしている ■ 経験主義は、以下の３本柱に支えられている ○ 透明性: いわゆる見える化 ○ 検査: いわゆるレビュー、フィードバック ○ 適応: いわゆるカイゼン ■ スクラムを一言で言うと、「働き方」 ○ 例えると、野球をやるか、サッカーをやるか 30

Slide 31

Slide 31 text

スクラムへの期待と不安 31

Slide 32

Slide 32 text

チームとしてのスクラムへの理解 ■ 「スクラムをやる」ではなく、「自分たちのチームが成果を出すにはスクラムがあっている」 ■ スクラムをやる理由を、リーダーだけでなくメンバーも理解する ■ プラクティス先行の導入では、スクラムへの不信感が募るだけだった ■ チームのキックオフでメンバに対して説明 32

Slide 33

Slide 33 text

チームなりのスクラムの実施 ■ スクラムではなく、スクラムベースであること ○ スクラムマスターがいなければ難しい ■ タイムボックスを守ることを重視 ○ チームの特性にもよる（楽しく働きたい、効率性を重視したいか） ○ 朝会の小話をやめて、プロダクトバックログのリファインメントを毎週実施 ○ チームの人数が多いほど重要 ■ スクラムガイドで定期的に目的と役割の責任を共有 ○ スクラムは得てしてプラクティス先行になりやすい ■ メンバーが見積もり、メンバーは全力を尽くすことに責任を持つ ○ マネジメント型の限界に対するひとつの解 ○ 長期的に成果を出し続けるためには必要な考え 33

Slide 34

Slide 34 text

どうやってメンバが成長できる環境を作るか？ 34

Slide 35

Slide 35 text

チームのマネジメントを大別すると ■ 日々の業務のマネジメント ■ メンバの成長のマネジメント 35

Slide 36

Slide 36 text

メンバの成長のためにメンバの理解を深める ■ 色々な取り組みを実施 ○ 1on1 ○ 180度評価 ○ ジョブディスクリプション 36

Slide 37

Slide 37 text

1on1 ■ 毎月1回実施 ■ 以下のルールを共有・困ってることや知っておいて欲しいことか、なんでも話す場・一人あたり15分~30分目処・進捗確認の場ではない・（話すことがなければ即終了） ■ 普段なんとなく思っているようなことでも共有してもらえる ■ 自分がチームに発信したことについて（自分であれば、チームになりたい）、フィードバックがもらえる ■ 個々のメンバを向き合う場としても非常に重要 37

Slide 38

Slide 38 text

180度評価 ■ 半年に１回実施（なので、まだ1回だけしかやってない） ■ 全社に公開することをメンバーに承諾（チーム内の取り組みにしない） ■ 匿名で以下の内容に回答してもらった・リーダーを評価すると10点満点中何点？・良かった点（Good）・良くなかった点（Bad、Problem）・改善して欲しい点、アドバイス（Improvement、kaizen）・その他なんでも言っておきたいこと ■ メンバーからの本音のフィードバックが得られ、リーダー側へのメリットがとても大きい 38

Slide 39

Slide 39 text

ジョブディスクリプション ■ 自分がどんな役職をやってみたいのかを上げてもらう ■ やり始めた理由は、スクラムだけだと日々の業務をこなすだけになりがちになってしまうため ■ チームが成長するためには、メンバの適性を知ることが大事。その上で、ジョブディスクリプションという考えを利用してみた ■ 年明けから始めたのでこれからだが、メンバの特性を知るには良かった 39

Slide 40

Slide 40 text

メンバの成長のマネジメント絶賛悩み中！ 40

Slide 41

Slide 41 text

マネジメントについて思うこと 41

Slide 42

Slide 42 text

マネジメントの難しさ ■ マネジメントは組織、業務、メンバー、そして自分によって変わる ■ 常に状態は変わり、上手くいっている時もあれば、上手くいかない時もある ■ 自分の成長、モチベも自分がマネジメントする、というのは実は辛い 42

Slide 43

Slide 43 text

リーダーとマネージャーの区別 ■ まずは自分の職責が何かを明確にすることは大事 ■ リーダーとマネージャーが別だと良いと思うこと ○ リーダーとマネージャーはやることがそもそも違い、日々取り入れる情報も違う。 ○ リーダーは、市場を追いかけ、ビジョンを見せる ○ マネージャーは、チームの中をみて、メンバををみる ■ リーダーとマネージャーが同じだと良いと思うこと ○ メンバーの適正に合わせてチームのビジョンを考えることができる 43

Slide 44

Slide 44 text

プレイングマネージャはオススメしない ■ リーダー、マネージャーの作業は創造的作業のため外からは作業が見えづらい ■ そのため、始める前はついつい現場の作業とできると思ってしまいがち ○ （自分はそうでした・・・） ■ マネジメントにリソースを割きたいのであれば手放すことを考える ○ 視点や視野が全く違う。特にメンバーの成長のマネジメントは。 44

Slide 45

Slide 45 text

最後に ■ チームとして成果を出す、ということを基準からぶらさない ■ チームの成長に繋がると思うことを色々やってみる 45