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

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

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

結果、

前より良くなった！

Engineering

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