Engineering Manager Meetup #8 LT資料

1. /18
徹底的にアウトプットを伴う育成をやってみた話
1
2020/6/3
Engineering Manager Meetup #8
小島優介

2. /18
自己紹介
2
名前：小島 優介
業務：
2005年から15年間ツール開発業務を担当。
プロジェクト管理ツール開発のプロジェクトマネージャーなどを経て、
現在はレビュー支援ツール開発のエンジニアリングマネージャー。
プレイングマネージャーとして毎日メンバーと一緒に開発している。

3. /18
話したいこと
3
新人ばかりで15万行のツールの変更開発という窮地を
徹底的にアウトプットを伴う育成で乗り切った話

4. /18
当初(1年前)のプロジェクトのメンバー
4
メンバーは中堅1人(私)、ほぼ新人(開発経験半年)が2人
技術力と開発生産性は、社内の中でも最低レベルのチーム
新人 新人中堅 新人
(半年後にもう1人
新人が配属予定)
デザインパターン？
なんですか？
SOLID原則？
なんですか？
中堅社員です

5. /18
当初のプロジェクト概要
5
C#のツールの変更開発業務
既存のソースコードは15万行
数ヶ月ごとに継続的なバージョンアップが必要
開発チームを新しいメンバーで一新したばかり
＜問題点＞
新人では開発するためのスキルが足りない
カリキュラム通りに学習するだけの従来の育成方法では
とても今後の継続的なリリースができるほどの成長は見込めない
→新しい育成方法でのスキルアップが必要

6. /18
新しい育成方法の検討
6
＜方針＞
スキルアップのためにアウトプットを強制する
ガチで学習しないといけなくなることで急成長を期待
↓
＜不安＞
開発も進めなければならないため、アウトプットする余裕あるか？
全員がアウトプット経験に乏しい
↓
＜結論＞
勉強会や開発プロセスなど
日々のタスクにアウトプットをセットで組み込む
(セットにしないと余裕がある時しかアウトプットされない)

7. /18
アウトプットの種類を頻度で分ける
7
• 毎日のアウトプット
• 毎朝15分の勉強会
• 学んだことをSlackに投稿
• etc
• 毎月のアウトプット
• 技術記事投稿

8. /18
毎日のアウトプットの施策
8
開発と並行しながら、5つの施策で毎日アウトプット
• 設計や実装中の思考を話す
• ペアプログラミング/モブプログラミングで思考の指導
• 設計や実装中の思考を書く
• 分報で思考の指導
• 学んだことを話す
• 毎朝15分の書籍勉強会
• 学んだことを書く
• 学んだことをSlackに投稿
• 学んだ設計技術を使って実装する
• 毎朝15分のデザインパターン勉強会

9. /18
設計や実装中の思考を話す
9
ペアプログラミング/モブプログラミングにて
書いたコード(＝結果)の指導より、
どのように考えてそのコードにするか(＝思考)を重点的に指導。
なぜそのメソッド名にするか、クラスの分割は妥当か、など
質問を投げかけ、理由を話してもらい、その思考に対して指導
「なんとなく」決めることがないように
すべてロジカルに意思決定する思考を徹底
＜詳細は以下＞
ペアプロ・モブプロでメンバーが驚くほど成長した話
https://qiita.com/kojimadev/items/5d0e03f3367eddc4fa67
物語風で分かる、早くて楽しいモブプログラミング
https://qiita.com/kojimadev/items/e96e89ec80f9b789169c

10. /18
設計や実装中の思考を書く
10
分報でどう考えてタスクを進めるか書いてもらい、その思考を指導
(例)不具合調査は、原因特定の思考過程を書く
→その思考に対して考慮漏れなどを指導
＜詳細は以下＞
分報で各自の作業を可視化したら、メンバー間の協力が加速された話
https://qiita.com/kojimadev/items/ea8825dec1b0d0d2874c
原因特定の思考過程での
考慮漏れを指導

11. /18
学んだことを話す
11
学んだことは人に説明した方が身につくため(＝アウトプット)
毎朝15分の書籍勉強会を実施
事前に全員が書籍を30ページ程度 読んできた上で、
その重要ポイントを各自が自分の言葉で説明
＜詳細は以下＞
毎朝15分の勉強会で若手の行動が驚くほど改善した話
https://qiita.com/kojimadev/items/cd5dd5332e33b3ef46a6

12. /18
学んだことを書く
12
読んだ技術記事で学んだことをSlackに投稿し、チーム内で共有
自分で技術情報をキャッチアップする習慣を付ける

13. /18
学んだ設計技術を使って実装する
13
新人は設計を学んでもすぐに業務で使う機会がないため
毎朝15分のデザインパターン勉強会を実施
事前に、デザインパターンを用いた自分なりのサンプルプログラムの
クラス図とコードを書いてきてもらい、15分でレビューする
Gofの23パターンすべて実施で完了
その後は業務で実践
＜詳細は以下＞
毎朝15分の勉強会で若手の設計力がメキメキアップした話
https://qiita.com/kojimadev/items/99d2aa1c9bc67a835480
手書きでも電子でも
個人の好きな方法で書く

14. /18
毎月のアウトプットの施策
14
毎月のアウトプットは、技術記事投稿
↓
メンバーから挙がった声
• 書こうと思った記事は、すでに世の中にあるからネタがない
• 批判されたらどうしよう
• 1件書くだけでも時間がかかりそう
↓
以下のことに取り組む
• 技術記事のネタがない人でも書ける理論を考える
• メンバーに先んじて技術記事をいくらか投稿する
• 技術記事を書くことのメリットを調べる

15. /18
技術記事投稿への不安を軽減
15
• 書こうと思った記事は、すでに世の中にあるからネタがない
• 1つのコンセプトに色んな視点の記事があれば、
より多くの人がそのコンセプトを理解できる
→だから自分なりの視点で自分の理解を書けばよい
• 批判されたらどうしよう
• 批判は0件
→むしろフィードバッグで関連技術の知見が広がる
• 1件書くだけでも時間がかかりそう
• その技術を理解するために必要な時間のため、それを含めて計画
• 記事を書くことで、自分の理解の曖昧な点に気付く
理解が浅いと、結局業務で間違った実装をしてしまう
→遠回りのようでいて、必要なプロセス

16. /18
投稿できるようになるまでサポート
16
• 記事のネタを一緒に考える
• 下書きの記事を見せてもらって助言
• はじめのうちは記事の質は求めない
• 投稿したらポジティブフィードバックする
↓
全員が毎月2件、技術記事を投稿できるようになる

17. /18
活動の効果(1年後)
17
継続的なバージョンアップ可能なスキルを習得
＜技術力＞
コアドメインのアーキテクチャを刷新する変更開発に対しても
設計・実装を担当できた
＜開発生産性＞
全員が半年間でC#1万LOC以上の製品コードを実装
新人の開発行数の歴代最高記録を達成

18. /18
社内外からの評価
18
Qiitaに投稿した技術記事
→半年間で20万PV、4000いいね、月間ユーザーランキング1位
本発表の育成方法と
その他にも実施した「楽しく開発するプラクティス」を合わせて
「ハピネスチームビルディング」と名付けて社内外に発信
→社内で活動が評価され、金一封と表彰状をもらう

19. /18
おまけ
楽しく開発するプラクティス
19

20. /18
アウトプットを促進するために
20
アウトプットを促進するために
心理的安全性を高めて、楽しく開発できるような施策を実施
(以下は一例)
• アウトプットにリアクション
• ポジティブフィードバッグ
• 楽しくなるような用語を使う

21. /18
アウトプットにリアクション
21
アウトプットのメリットを感じなければ、継続できない
メンバーのアウトプットに対して積極的な助言と称賛が必要
(例)分報に対して助言することでタスクが効率化されれば
メンバーに分報でつぶやくメリットを感じてもらいやすい
つぶやきに対して
助言して効率化

22. /18
ポジティブフィードバック
22
「日々の行動」に対して積極的にポジティブフィードバック。
行動を褒める → 行動と喜びの感情が結びつき定着
自分は毎日10回くらいメンバーを褒める。
(例) 「そこに気付くなんて凄い！」「さすが！その通り！」
「その想定は素晴らしい」「その判断Good！」、etc
嬉しい！
開発が楽しい！

23. /18
楽しくなるような用語を使う
23
不具合をドラゴンと呼び、
不具合修正者をドラゴンスレイヤーと呼ぶ
仕事に遊び心は大切！