DevLOVE199 越境CONにて発表した、1人のエンジニアの"今まで"と"これから"です。

1. 「自分でやる」という快感を追い続ける
- あるプログラマーの成長戦略 -
Vol.01 Jan/28/2017
Isao Takahashi
Travel Service Development Department, Rakuten Inc.
http://travel.rakuten.co.jp/

2. 自己紹介
3
Name
高橋 勲
(もうすぐ三十路)
Account
@IsaoTakahashi
Role
Application Engineer
ときどき
レビューおじさん
Favorite
コード書くこと全般
(機能実装、リファクタリング、
自動化 etc.)

3. 自己紹介
4
Name Account
@IsaoTakahashi
Role
Application Engineer
ときどき
レビューおじさん
Favorite
コード書くこと全般
(機能実装、リファクタリング、
自動化 etc.)
高橋 勲
(もうすぐ三十路)

4. つくってます
5

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

6. まずは、
7
“自分自身の
コーディング史”
を振り返ってみる

7. Commit数/PR数の変遷
8
0
50
100
150
200
250
300
Commit数
PR数

8. 傾向見ようと思ったけど、
9
“プロジェクト忙しいときに
メッチャCommitしてる”
というのが見えただけだった

9. でも、
10
“最近 > 新卒時 > 2,3年前”
という雰囲気は見えた

10. Commit数/PR数の変遷
11
0
50
100
150
200
250
300
Commit数
PR数
無邪気にコーディング
楽しんでいた期
マネージメントロールを
模索して苦しんでた期
自分を再発見した期

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

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

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

14. 無邪気にコーディング楽しんでいた期
15
0
50
100
150
200
250
300
Commit数
PR数

15. 入社時～2年目
• 無邪気にコーディングを楽しんでいた頃
– 「自分が一番へたくそ」
• 実装タスクがメイン
• 常に「打てば響く」状況
– 上司は「どんどん改善してけ」とアグレッシブ
• アイデアを出す
-> 実現のためのコーディングも自分でできる！
16

16. このころにやっていたこと
• キレイズキ委員会への参画
– コーディング規約の統一
– 運用改善の提案(フロー、ツールの導入)
• 10%ルールへの参画
– 好きなものを作って発表しあう場
• ペアプログラミングの提案、実施
• Jenkinsを使った自動ブラウザテスト環境構築
17

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

18. この頃の自分
19
「コード書いて
お金もらえるとかマジ天国」

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

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

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

22. マネージメントロールを模索して苦しんでいた期
23
0
50
100
150
200
250
300
Commit数
PR数

23. 3年目～4年目前半
• 「コーディングする時間が減ってきたぞ」な頃
– 「詳細設計」と「後輩の指導」をするように
• 両方初めてだったので、長い時間を費やす
• あんまりコード書けない･･･
– デキる先輩たちはどんどんマネージメントを
メインタスクとするように
• 自分もそうなっていくべきなのか･･･?
24

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

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

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

27. キャリアパスを真面目に考え始めた
• Coder → Manager?
– 「チームをマネージメントすることで、
自分1人ではできないことを実現できる」
• 確かにそれはそのとおり
– 皆がその道に進むのがいいのか?
• 規定路線になるのは何か違うのでは?
29

28. 自分のキャリアについて悩んでいたら、
30
“チーム異動”
イベントが発生

29. 31
自分を再発見した期

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

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

32. 自分を再発見した期
34
0
50
100
150
200
250
300
Commit数
PR数

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

34. キャリアパス?
36
“考える余裕”
ほとんどない

35. 時は経ち、
37
“人材不足解消”
イベントが発生

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

37. となると、
39
“キャリアパスに悩む”
イベントが再発生

38. 自分はどうしたいのか？
• 「コーディング楽しい (╹ᴗ╹)」
– うそ偽りのない、本音
• 設計や運用改善の提案もしたい
– そんでもって、それを自分で作りたい
40

39. つまり、
41
“アプリケーションエンジニア
のスペシャリスト”
になりたい

40. スペシャリストやれる土壌はあるか?
• チームの現状的にいけそう
– 自分が一番コーディングスキル高い
• チームの中で。
– 設計スキルもそこそこ
– マネージメント特化な人が、他にいる
– 後押しをしてくれる人”たち”がいる
42

41. スペシャリストやれる土壌はあるか?
• チームの現状的にいけそう
– 自分が一番コーディングスキル高い
• チームの中で。
– 設計スキルもそこそこ
– マネージメント特化な人が、他にいる
– 後押しをしてくれる人”たち”がいる
43

42. スペシャリストやれる土壌はあるか?
• 会社としての評価指標もある
– ManagerとIC(Individual Contributor)
• Manager ： 「人を上手く動かすことで成果を出す」
• IC ： 「自分自身が直接動くことで成果を出す」
– 昔から「スペシャリスト」を評価する流れはあったが、
今年から正式に評価制度として確立された
44

43. よし、
45
“やれそう”

44. よし、
46
“やるぞ”

45. 47
まだ見ぬ”アツイ”期

46. まだ見ぬ”アツイ”期
48
0
50
100
150
200
250
300
?

47. まだ見ぬ”アツイ”期
• “個”のエンジニアとして貢献
– 「何か困ったらコイツに任せれば何とかしてくれる」
存在になる
– “チームを支える”のではなく、”先頭を突っ走る”
• どっちがいいとかではなく、
「自分がどういうポリシーで動くか」
– “指導する”のではなく、”背中を見せる”
• 「憧れられる存在」になる
49

48. 50
まとめ

49. 割と有名なベン図
51
できること
やりたいこと 期待されること

50. これが、
52
プログラミング
できること
やりたいこと 期待されること

51. こうなって、
53
プログラミング
できること
やりたいこと 期待されること
マネージメント

52. こうなろうとしたけど、
54
プログラミング
できること
やりたいこと 期待されること
マネージメント

53. やっぱこうなりたい
55
プログラミング
できること
やりたいこと 期待されること

54. We are Hiring!
69
http://corp.rakuten.co.jp/careers/engineering/

55. 70
おまけ

56. 自分を再発見した期
71
0
50
100
150
200
250
300
Commit数
PR数

57. Commit数がピークに達したとき、
72
“何が起こっていたのか”

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

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

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

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

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

63. よし、
78
“やろう”

64. どうやって?
79
“根性 & 根性”

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

66. 結果、
81
めっちゃ頑張った！

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

68. 結果、
83
コードの行数：Down↓
静的解析の指摘： Down↓

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

70. 結果、
85
コードの複雑度：Down↓
テストカバレッジ：Up↑

71. 結果、
86
前より良くなった！