「自分でやる」という快感を追い続ける - あるプログラマーの成長戦略 -

「自分でやる」という快感を追い続ける- あるプログラマーの成長戦略 -

Vol.01 　 Jan/28/2017Isao TakahashiTravel Service Development Department, Rakuten Inc.http://travel.rakuten.co.jp/

3

自己紹介Name

高橋 勲( もうすぐ三十路 )

Account

@IsaoTakahashi

Role

Application Engineerときどきレビューおじさん

Favorite

コード書くこと全般( 機能実装、リファクタリング、自動化 etc.)

4

自己紹介Name Account

@IsaoTakahashi

Role

Application Engineerときどきレビューおじさん

Favorite

コード書くこと全般( 機能実装、リファクタリング、自動化 etc.)

高橋 勲( もうすぐ三十路 )

5

つくってます

6

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

7

まずは、

“ 自分自身のコーディング史”を振り返ってみる

8

Commit 数 /PR 数の変遷

0

50

100

150

200

250

300

Commit 数PR 数

9

傾向見ようと思ったけど、

“ プロジェクト忙しいときに メッチャ Commit してる”というのが見えただけだった

10

でも、

“ 最近 > 新卒時 > 2,3 年前”という雰囲気は見えた

11

Commit 数 /PR 数の変遷

0

50

100

150

200

250

300

Commit 数PR 数

無邪気にコーディング　楽しんでいた期

マネージメントロールを　　模索して苦しんでた期

自分を再発見した期

12

無邪気にコーディング楽しんでいた期

13

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

14

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

15

無邪気にコーディング楽しんでいた期

0

50

100

150

200

250

300

Commit 数PR 数

16

入社時～ 2 年目• 無邪気にコーディングを楽しんでいた頃– 「自分が一番へたくそ」

• 実装タスクがメイン• 常に「打てば響く」状況

– 上司は「どんどん改善してけ」とアグレッシブ• アイデアを出す

-> 実現のためのコーディングも自分でできる！

17

このころにやっていたこと• キレイズキ委員会への参画

– コーディング規約の統一– 運用改善の提案 ( フロー、ツールの導入 )

• 10% ルールへの参画– 好きなものを作って発表しあう場

• ペアプログラミングの提案、実施• Jenkins を使った自動ブラウザテスト環境構築　

18

10% ルールで作っていたプロダクトたち

19

この頃の自分

「コード書いてお金もらえるとかマジ天国」

20

マネージメントロールを模索して苦しんでいた期

21

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

22

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

23

マネージメントロールを模索して苦しんでいた期

0

50

100

150

200

250

300

Commit 数PR 数

24

3 年目～ 4 年目前半• 「コーディングする時間が減ってきたぞ」な頃– 「詳細設計」と「後輩の指導」をするように

• 両方初めてだったので、長い時間を費やす• あんまりコード書けない･･･

– デキる先輩たちはどんどんマネージメントをメインタスクとするように• 自分もそうなっていくべきなのか･･･ ?

26

このころにやっていた ( いる ) こと• トラベル開発部署〆会の開催– 部署全体の月次共有会 • 5-60 人を 1 つの会議室に集めて開催• 現在は、 100 人 over & 複数拠点 (3 カ国 6 箇所 )

27

このころにやっていた ( いる ) こと• トラベル開発部署〆会の開催– 最初期の光景

28

このころにやっていた ( いる ) こと• トラベル開発部署〆会の開催– 今• この会場と同じくらいの広さで、満員？

29

キャリアパスを真面目に考え始めた• Coder → Manager?– 「チームをマネージメントすることで、 自分 1 人ではできないことを実現できる」

• 確かにそれはそのとおり– 皆がその道に進むのがいいのか ?

• 規定路線になるのは何か違うのでは ?

30

自分のキャリアについて悩んでいたら、

“ チーム異動”イベントが発生

31

自分を再発見した期

32

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

33

どんなお話？• 新卒で入った人間がコーディングによる改善活動をしていたところ、だんだんコーディングする機会を失っていく中「人に指示する立場であれば、その立場なりの立ち回りがある」と改善活動を続けていたが、「やっぱ俺、自分自身でコード書いて ( 手を動かして ) 改善するのが好きだ！」と気づいて『コードを書き続ける』ために奮戦するようになったお話

34

自分を再発見した期

0

50

100

150

200

250

300

Commit 数PR 数

35

4 年目後半～• 設計もコーディングもやらないといけなかった– 人手不足なチームへ• 設計もコーディングも自分でやらないと回らない• マネージメントの主担当の人が既にいた

36

キャリアパス ?

“ 考える余裕”ほとんどない

37

時は経ち、

“ 人材不足解消”イベントが発生

38

今• 設計もコーディングもやっていい– チームが回るように• 「マネージメント担当」「テクニカル担当 ( 自分 ) 」の 2 本柱で回り始めてきた

– コーディング楽しい ( ᴗ )╹ ╹

39

となると、

“ キャリアパスに悩む”イベントが再発生

40

自分はどうしたいのか？• 「コーディング楽しい ( ᴗ )╹ ╹ 」– うそ偽りのない、本音

• 設計や運用改善の提案もしたい– そんでもって、それを自分で作りたい

41

つまり、

“ アプリケーションエンジニアのスペシャリスト”になりたい

42

スペシャリストやれる土壌はあるか ?

• チームの現状的にいけそう– 自分が一番コーディングスキル高い

• チームの中で。– 設計スキルもそこそこ– マネージメント特化な人が、他にいる– 後押しをしてくれる人”たち”がいる

43

スペシャリストやれる土壌はあるか ?

• チームの現状的にいけそう– 自分が一番コーディングスキル高い

• チームの中で。– 設計スキルもそこそこ– マネージメント特化な人が、他にいる– 後押しをしてくれる人”たち”がいる

44

スペシャリストやれる土壌はあるか ?

• 会社としての評価指標もある– Manager と IC(Individual Contributor)

• Manager ： 「人を上手く動かすことで成果を出す」• IC ： 「自分自身が直接動くことで成果を出す」

– 昔から「スペシャリスト」を評価する流れはあったが、今年から正式に評価制度として確立された

45

よし、

“ やれそう”

46

よし、

“ やるぞ”

47

まだ見ぬ”アツイ”期

48

まだ見ぬ”アツイ”期

4/1/2013

6/1/2013

8/1/2013

10/1/2013

12/1/2013

2/1/2014

4/1/2014

6/1/2014

8/1/2014

10/1/2014

12/1/2014

2/1/2015

4/1/2015

6/1/2015

8/1/2015

10/1/2015

12/1/2015

2/1/2016

4/1/2016

6/1/2016

8/1/2016

10/1/2016

12/1/2016

2/1/2017

4/1/2017

6/1/2017

0

50

100

150

200

250

300

?

49

まだ見ぬ”アツイ”期• “個”のエンジニアとして貢献– 「何か困ったらコイツに任せれば何とかしてくれる」存在になる– “ チームを支える”のではなく、”先頭を突っ走る”

• どっちがいいとかではなく、「自分がどういうポリシーで動くか」– “ 指導する”のではなく、”背中を見せる”

• 「憧れられる存在」になる

50

まとめ

51

割と有名なベン図できること

やりたいこと 期待されること

52

これが、

プログラミング

できること

やりたいこと 期待されること

53

こうなって、

プログラミング

できること

やりたいこと 期待されること

マネージメント

54

こうなろうとしたけど、

プログラミング

できること

やりたいこと 期待されること

マネージメント

55

やっぱこうなりたい

プログラミング

できること

やりたいこと 期待されること

69

We are Hiring!

http://corp.rakuten.co.jp/careers/engineering/

70

おまけ

71

自分を再発見した期

0

50

100

150

200

250

300

Commit 数PR 数

72

Commit 数がピークに達したとき、

“ 何が起こっていたのか”

73

サービスのリニューアルプロジェクト• 10年以上運用されてきたサービス– 設計思想も 10年前– 機能は継ぎ足し継ぎ足しで、 if-else の嵐

74

サービスのリニューアルプロジェクト• 3年前にちょっとだけリニューアルした– リソース不足 ( 人員・スキル・納期 ) のなか決行– 結果、「新しいのに複雑怪奇な処理満載のコード」が大量に生まれた

75

サービスのリニューアルプロジェクト• 本格的なリニューアルが開始– P 「前に作った機能、そのまま使えますよね？」– い「多分いけますけど、可能な範囲でリファクタリングしたいですねー」

76

サービスのリニューアルプロジェクト• 蓋を開けるとそこには…– 謎の動作フラグ– セグフォ上等な for ループ– if-elseif-elseif-elseif-el(ry– “getHoge” メソッドの中で Hoge を update している

77

サービスのリニューアルプロジェクト• リファクタリングを試みたが…– デッドコードいっぱいありそうなのに、そこもケアするの？– そもそもまともな UT もない– 「作り直した方が速いのでは…」– 幸い以前の QA テストケースは残っている

78

よし、

“ やろう”

79

どうやって ?

“ 根性 & 根性”

80

サービスのリニューアルプロジェクト• 結果

81

結果、

めっちゃ頑張った！

82

サービスのリニューアルプロジェクト• 結果

83

結果、

コードの行数： Down↓静的解析の指摘： Down↓

84

サービスのリニューアルプロジェクト• 結果

85

結果、

コードの複雑度：Down↓テストカバレッジ：

Up↑

86

結果、

前より良くなった！