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

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

1. 1. 「自分でやる」という快感を追い続ける - あるプログラマーの成長戦略 - Vol.01 Jan/28/2017 Isao Takahashi Travel Service Development Department, Rakuten Inc. http://travel.rakuten.co.jp/
2. 2. 自己紹介 3 Name 高橋 勲 (もうすぐ三十路) Account @IsaoTakahashi Role Application Engineer ときどき レビューおじさん Favorite コード書くこと全般 (機能実装、リファクタリング、 自動化 etc.)
3. 3. 自己紹介 4 Name Account @IsaoTakahashi Role Application Engineer ときどき レビューおじさん Favorite コード書くこと全般 (機能実装、リファクタリング、 自動化 etc.) 高橋 勲 (もうすぐ三十路)
4. 4. つくってます 5
5. 5. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 6
6. 6. まずは、 7 “自分自身の コーディング史” を振り返ってみる
7. 7. Commit数/PR数の変遷 8 0 50 100 150 200 250 300 Commit数 PR数
8. 8. 傾向見ようと思ったけど、 9 “プロジェクト忙しいときに メッチャCommitしてる” というのが見えただけだった
9. 9. でも、 10 “最近 > 新卒時 > 2,3年前” という雰囲気は見えた
10. 10. Commit数/PR数の変遷 11 0 50 100 150 200 250 300 Commit数 PR数 無邪気にコーディング 楽しんでいた期 マネージメントロールを 模索して苦しんでた期 自分を再発見した期
11. 11. 12 無邪気にコーディング 楽しんでいた期
12. 12. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 13
13. 13. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 14
14. 14. 無邪気にコーディング楽しんでいた期 15 0 50 100 150 200 250 300 Commit数 PR数
15. 15. 入社時～2年目 • 無邪気にコーディングを楽しんでいた頃 – 「自分が一番へたくそ」 • 実装タスクがメイン • 常に「打てば響く」状況 – 上司は「どんどん改善してけ」とアグレッシブ • アイデアを出す -> 実現のためのコーディングも自分でできる！ 16
16. 16. このころにやっていたこと • キレイズキ委員会への参画 – コーディング規約の統一 – 運用改善の提案(フロー、ツールの導入) • 10%ルールへの参画 – 好きなものを作って発表しあう場 • ペアプログラミングの提案、実施 • Jenkinsを使った自動ブラウザテスト環境構築 17
17. 17. 10%ルールで作っていたプロダクトたち 18
18. 18. この頃の自分 19 「コード書いて お金もらえるとかマジ天国」
19. 19. 20 マネージメントロールを 模索して苦しんでいた期
20. 20. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 21
21. 21. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 22
22. 22. マネージメントロールを模索して苦しんでいた期 23 0 50 100 150 200 250 300 Commit数 PR数
23. 23. 3年目～4年目前半 • 「コーディングする時間が減ってきたぞ」な頃 – 「詳細設計」と「後輩の指導」をするように • 両方初めてだったので、長い時間を費やす • あんまりコード書けない･･･ – デキる先輩たちはどんどんマネージメントを メインタスクとするように • 自分もそうなっていくべきなのか･･･? 24
24. 24. このころにやっていた(いる)こと • トラベル開発部署〆会の開催 – 部署全体の月次共有会 • 5-60人を1つの会議室に集めて開催 • 現在は、100人over & 複数拠点(3カ国6箇所) 26
25. 25. このころにやっていた(いる)こと • トラベル開発部署〆会の開催 – 最初期の光景 27
26. 26. このころにやっていた(いる)こと • トラベル開発部署〆会の開催 – 今 • この会場と同じくらいの広さで、満員？ 28
27. 27. キャリアパスを真面目に考え始めた • Coder → Manager? – 「チームをマネージメントすることで、 自分1人ではできないことを実現できる」 • 確かにそれはそのとおり – 皆がその道に進むのがいいのか? • 規定路線になるのは何か違うのでは? 29
28. 28. 自分のキャリアについて悩んでいたら、 30 “チーム異動” イベントが発生
29. 29. 31 自分を再発見した期
30. 30. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 32
31. 31. どんなお話？ • 新卒で入った人間がコーディングによる改善 活動をしていたところ、だんだんコーディング する機会を失っていく中「人に指示する立場 であれば、その立場なりの立ち回りがある」と 改善活動を続けていたが、「やっぱ俺、自分 自身でコード書いて(手を動かして)改善する のが好きだ！」と気づいて『コードを書き続け る』ために奮戦するようになったお話 33
32. 32. 自分を再発見した期 34 0 50 100 150 200 250 300 Commit数 PR数
33. 33. 4年目後半～ • 設計もコーディングもやらないといけなかった – 人手不足なチームへ • 設計もコーディングも自分でやらないと回らない • マネージメントの主担当の人が既にいた 35
34. 34. キャリアパス? 36 “考える余裕” ほとんどない
35. 35. 時は経ち、 37 “人材不足解消” イベントが発生
36. 36. 今 • 設計もコーディングもやっていい – チームが回るように • 「マネージメント担当」「テクニカル担当(自分)」 の2本柱で回り始めてきた – コーディング楽しい (╹ᴗ╹) 38
37. 37. となると、 39 “キャリアパスに悩む” イベントが再発生
38. 38. 自分はどうしたいのか？ • 「コーディング楽しい (╹ᴗ╹)」 – うそ偽りのない、本音 • 設計や運用改善の提案もしたい – そんでもって、それを自分で作りたい 40
39. 39. つまり、 41 “アプリケーションエンジニア のスペシャリスト” になりたい
40. 40. スペシャリストやれる土壌はあるか? • チームの現状的にいけそう – 自分が一番コーディングスキル高い • チームの中で。 – 設計スキルもそこそこ – マネージメント特化な人が、他にいる – 後押しをしてくれる人”たち”がいる 42
41. 41. スペシャリストやれる土壌はあるか? • チームの現状的にいけそう – 自分が一番コーディングスキル高い • チームの中で。 – 設計スキルもそこそこ – マネージメント特化な人が、他にいる – 後押しをしてくれる人”たち”がいる 43
42. 42. スペシャリストやれる土壌はあるか? • 会社としての評価指標もある – ManagerとIC(Individual Contributor) • Manager ： 「人を上手く動かすことで成果を出す」 • IC ： 「自分自身が直接動くことで成果を出す」 – 昔から「スペシャリスト」を評価する流れはあったが、 今年から正式に評価制度として確立された 44
43. 43. よし、 45 “やれそう”
44. 44. よし、 46 “やるぞ”
45. 45. 47 まだ見ぬ”アツイ”期
46. 46. まだ見ぬ”アツイ”期 48 0 50 100 150 200 250 300 ?
47. 47. まだ見ぬ”アツイ”期 • “個”のエンジニアとして貢献 – 「何か困ったらコイツに任せれば何とかしてくれる」 存在になる – “チームを支える”のではなく、”先頭を突っ走る” • どっちがいいとかではなく、 「自分がどういうポリシーで動くか」 – “指導する”のではなく、”背中を見せる” • 「憧れられる存在」になる 49
48. 48. 50 まとめ
49. 49. 割と有名なベン図 51 できること やりたいこと 期待されること
50. 50. これが、 52 プログラミング できること やりたいこと 期待されること
51. 51. こうなって、 53 プログラミング できること やりたいこと 期待されること マネージメント
52. 52. こうなろうとしたけど、 54 プログラミング できること やりたいこと 期待されること マネージメント
53. 53. やっぱこうなりたい 55 プログラミング できること やりたいこと 期待されること
54. 54. We are Hiring! 69 http://corp.rakuten.co.jp/careers/engineering/
55. 55. 70 おまけ
56. 56. 自分を再発見した期 71 0 50 100 150 200 250 300 Commit数 PR数
57. 57. Commit数がピークに達したとき、 72 “何が起こっていたのか”
58. 58. サービスのリニューアルプロジェクト • 10年以上運用されてきたサービス – 設計思想も10年前 – 機能は継ぎ足し継ぎ足しで、if-elseの嵐 73
59. 59. サービスのリニューアルプロジェクト • 3年前にちょっとだけリニューアルした – リソース不足(人員・スキル・納期)のなか決行 – 結果、「新しいのに複雑怪奇な処理満載のコード」が大量 に生まれた 74
60. 60. サービスのリニューアルプロジェクト • 本格的なリニューアルが開始 – P「前に作った機能、そのまま使えますよね？」 – い「多分いけますけど、可能な範囲でリファクタリングした いですねー」 75
61. 61. サービスのリニューアルプロジェクト • 蓋を開けるとそこには… – 謎の動作フラグ – セグフォ上等なforループ – if-elseif-elseif-elseif-el(ry – “getHoge”メソッドの中でHogeをupdateしている 76
62. 62. サービスのリニューアルプロジェクト • リファクタリングを試みたが… – デッドコードいっぱいありそうなのに、そこもケアするの？ – そもそもまともなUTもない – 「作り直した方が速いのでは…」 – 幸い以前のQAテストケースは残っている 77
63. 63. よし、 78 “やろう”
64. 64. どうやって? 79 “根性 & 根性”
65. 65. サービスのリニューアルプロジェクト • 結果 80
66. 66. 結果、 81 めっちゃ頑張った！
67. 67. サービスのリニューアルプロジェクト • 結果 82
68. 68. 結果、 83 コードの行数：Down↓ 静的解析の指摘： Down↓
69. 69. サービスのリニューアルプロジェクト • 結果 84
70. 70. 結果、 85 コードの複雑度：Down↓ テストカバレッジ：Up↑
71. 71. 結果、 86 前より良くなった！