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

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 無邪気にコーディング楽しんでいた期

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 マネージメントロールを模索して苦しんでいた期

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 自分を再発見した期

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 めっちゃ頑張った！

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

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

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

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

Esté a ler uma amostra.

Confira estes a seguir

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

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

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

Mais recentes (20)