Download to read offline
Uploaded byIsao Takahashi
「自分でやる」という快感を追い続ける - あるプログラマーの成長戦略 -
DevLOVE199 越境CONにて発表した、1人のエンジニアの"今まで"と"これから"です。
More Related Content
Similar to 「自分でやる」という快感を追い続ける - あるプログラマーの成長戦略 -
「自分でやる」という快感を追い続ける - あるプログラマーの成長戦略 -
- 1. 「自分でやる」という快感を追い続ける - あるプログラマーの成長戦略 - Vol.01Jan/28/2017 Isao Takahashi Travel Service Development Department, Rakuten Inc. http://travel.rakuten.co.jp/
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. でも、 10 “最近 > 新卒時> 2,3年前” という雰囲気は見えた
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. 入社時～2年目 • 無邪気にコーディングを楽しんでいた頃 – 「自分が一番へたくそ」 •実装タスクがメイン • 常に「打てば響く」状況 – 上司は「どんどん改善してけ」とアグレッシブ • アイデアを出す -> 実現のためのコーディングも自分でできる！ 16
- 16. このころにやっていたこと • キレイズキ委員会への参画 – コーディング規約の統一 –運用改善の提案(フロー、ツールの導入) • 10%ルールへの参画 – 好きなものを作って発表しあう場 • ペアプログラミングの提案、実施 • Jenkinsを使った自動ブラウザテスト環境構築 17
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23. 3年目～4年目前半 • 「コーディングする時間が減ってきたぞ」な頃 – 「詳細設計」と「後輩の指導」をするように •両方初めてだったので、長い時間を費やす • あんまりコード書けない･･･ – デキる先輩たちはどんどんマネージメントを メインタスクとするように • 自分もそうなっていくべきなのか･･･? 24
- 24. このころにやっていた(いる)こと • トラベル開発部署〆会の開催 – 部署全体の月次共有会 •5-60人を1つの会議室に集めて開催 • 現在は、100人over & 複数拠点(3カ国6箇所) 26
- 25.
- 26. このころにやっていた(いる)こと • トラベル開発部署〆会の開催 – 今 •この会場と同じくらいの広さで、満員？ 28
- 27. キャリアパスを真面目に考え始めた • Coder →Manager? – 「チームをマネージメントすることで、 自分1人ではできないことを実現できる」 • 確かにそれはそのとおり – 皆がその道に進むのがいいのか? • 規定路線になるのは何か違うのでは? 29
- 28.
- 29.
- 30.
- 31.
- 32.
- 33. 4年目後半～ • 設計もコーディングもやらないといけなかった – 人手不足なチームへ •設計もコーディングも自分でやらないと回らない • マネージメントの主担当の人が既にいた 35
- 34.
- 35.
- 36. 今 • 設計もコーディングもやっていい – チームが回るように •「マネージメント担当」「テクニカル担当(自分)」 の2本柱で回り始めてきた – コーディング楽しい (╹ᴗ╹) 38
- 37.
- 38. 自分はどうしたいのか？ • 「コーディング楽しい (╹ᴗ╹)」 –うそ偽りのない、本音 • 設計や運用改善の提案もしたい – そんでもって、それを自分で作りたい 40
- 39.
- 40. スペシャリストやれる土壌はあるか? • チームの現状的にいけそう – 自分が一番コーディングスキル高い •チームの中で。 – 設計スキルもそこそこ – マネージメント特化な人が、他にいる – 後押しをしてくれる人”たち”がいる 42
- 41. スペシャリストやれる土壌はあるか? • チームの現状的にいけそう – 自分が一番コーディングスキル高い •チームの中で。 – 設計スキルもそこそこ – マネージメント特化な人が、他にいる – 後押しをしてくれる人”たち”がいる 43
- 42. スペシャリストやれる土壌はあるか? • 会社としての評価指標もある – ManagerとIC(IndividualContributor) • Manager ： 「人を上手く動かすことで成果を出す」 • IC ： 「自分自身が直接動くことで成果を出す」 – 昔から「スペシャリスト」を評価する流れはあったが、 今年から正式に評価制度として確立された 44
- 43.
- 44.
- 45.
- 46.
- 47. まだ見ぬ”アツイ”期 • “個”のエンジニアとして貢献 – 「何か困ったらコイツに任せれば何とかしてくれる」 存在になる –“チームを支える”のではなく、”先頭を突っ走る” • どっちがいいとかではなく、 「自分がどういうポリシーで動くか」 – “指導する”のではなく、”背中を見せる” • 「憧れられる存在」になる 49
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 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.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.