楽天株式会社(ラクマチーム)を退職しました
こんにちは。つよぽそです。
さて、掲題のとおりですが、1/31を最終出社日とし、2/28に楽天を正式に退職します。僕はラクマを開発するチームに所属していたんですが、そこでやってきたことや、これからを書いていこうかと。 ※最終出社日翌日からずっと体調を崩してるので遅れてしまった。。。
何故入社したのか?
実は僕は楽天に入社したわけではありません。ラクマに名前が変わる前のフリルを開発していたFablicに入社しました。なのであくまでFablicに入社した理由を書きます。
元々前職はソーシャルゲーム会社なのでゲームから離れてwebサービスをやっている会社を探していた。当時既に何社か内定をいただいていたので、最後にwantedlyをみてちょっと気になったので応募してみた。まずCTOとのカジュアル面談で何となく雰囲気の良さそうな会社だなと思ったり、技術面談でも、こちらの話しをしっかり聞いてくれて楽しく進めることができたり、構造化面接ではこれでもかと自分のやってきた仕事を深掘りしてくれた。面接を進める中でこの会社良いなと思っていたんだけど、決定打になったのは面接から帰る際、オフィスが暑いからと気温の低い廊下で作業をするエンジニアが二人いた事。当然人事の方は必死になって言い訳してくれるんだけど、その光景を見てたら、この会社好きだな、一緒に大きくしていきたいなと思った。※ちなみに最終面談で人事の方からサーキュレーター導入したんです!!との報告があったw
まあ、そんなアホな理由で入社??と思うかもしれないけど、事実だし会社が好きだなと思える事って結構重要だと思っています。
Fablic時代
Fablicに入社してからだけど、想像していた以上に最高だった。
- 情報の透明性の高さ
- 垣根に囚われず積極的に関わっていくメンバー達
- OKRもメンバー達が案を出す
- 活発なslack
- 権威勾配の低い社風
- 自由と責任を持って働くスキルの高いメンバー達
- コーヒーを淹れながらカジュアルに相談
- 社内で炊き込みご飯
- rubyKaigiに無料で行かせてもらう
他にも色々あるが、皆が課題と向き合ってしっかり行動する良いチームだった。 Fablic時代にやったことは主に下記
特に楽天キャッシュチャージ機能に関しては、取引・配送チームのマネジメントをする中、他部署のエンジニアとの調整(担当が誰なのか探すところから)、当時ラクマチームに知見のなかった楽天社内でのセキュリティー監査、QAとの調整ハンドリングを行いつつバックエンドの実装をほぼ一人でやり遂げた。 ラクマのエンジニアとしてユーザーに明確な価値を提供できたのがとにかく嬉しかった。
楽天時代
正式に楽天に吸収されたのは2018年7月。まあ、それ以前から既に楽天のメンバーとは一緒に働いてはいた。 この時一つ決意していた事なんだけど、ここから楽天を辞める時までコードを書かずにマネジメントに徹するようにした。環境が激変する中でメンバーの余裕がなくなっていく事は予想できたので、自分は徹底して現場の支援に周り、何か問題があれば出来る限り先頭にたって問題解決にあたろうと。 正直、自分のマネジメントはいかに自分が必要のない状態にチームを育てていく事か?だったりするので、普段の業務外の事にもすぐ対応できる自信があったっていうのもある。ただ、そのためにはコードを書いていると自分がボトルネックになってしまうだろう。っていう判断からだった。この期間中も色々あったんだけど、ネットで書いていいかどうか微妙なものも多い気がするので割愛する。
メインでみていた取引・配送チーム(2018年9月の評価期間終了をもって完全に後任に引き継ぎ)やCREチームは2つとも自主性溢れる良いチームになれたなーと、最後の方はニヤニヤしながら朝会や振り返りしている姿を眺めていたりした。この2チームの担当領域がラクマに来る問い合わせの調査依頼の8〜9割を〆ていたので、この2チームが安定して運用を回せるようになったのはラクマにとっても大きいと思う。
また、大阪出張に行かせてもらい楽天大阪支社の皆さんの前でラクマの開発スタイルを話したり、各チームのやり方を聞いたり情報交換を行う機会をいただけたことは良い経験だった。※楽天大阪支社は本当に良い雰囲気で楽しかった。
2018年12月、この時期はラクマに何か残したいと思っていたんだけど、ラクマの皆が外で発表してラクマの存在感を高めないといけないなと思っていた。そのためにはまず自分がやらないと駄目だなと思って、とりあえず発表してくるってスタンスを見せるよう頑張った。やってみて思ったのは、どんどん外で知見を広めていくのは重要だなと改めて気づけたのは大きい。今後もどこかで発表していきたい。
Devlove関西 speakerdeck.com
em_meetup speakerdeck.com
何故辞めたのか
いつ辞める決断をしたかというと、正直Fablicの吸収を発表された時には遅かれ早かれ辞める事は決めていた。自分がFablicに入った時はエンジニアとして会社の成長にコミットすることがテーマだったから楽天に吸収されてしまった時点で仕事をする理由が無くなってしまった。 なので、一旦目標を吸収合併の混乱の中でラクマをしっかり運用できるようにし、新規の施策を実装していける体制が整うまでっていうところにおいた。結果CREチームが自走出来るチームに成長したのと開発メンバーが吸収前より増えた事で自分の責任は果たしたなと思えたため、このタイミングで辞める事を決意した。
楽天がどうだったかというと、トップダウンな社風だったり他部署に渡ってコミュニケーションをとったりする時にかかる圧倒的な労力と遅さ(これは大企業にありがちなしょうがない部分な気がしてるけど、どうすればこの状態を組織として解消できるのか未だに正解はわからない)と嫌な部分はあったりはするけど、退職の理由になる程ではなかったと思う。自分が頑張ればなんとかなる部分も多かったので。大阪支社でも感じたけど良い人が多くて好感を持てた。
そんな中でもラクマは事業も開発もCSも近くにいて、雰囲気も良いチームだった。開発側もプロデューサー、デザイナー、エンジニアが別け隔てなく議論しあえるチームになれたと思っているので、とても居心地が良かった。辞めるのが本当に寂しいと思える良いチームだった。 ※本当にラクマは良いチームなので皆様興味あれば是非応募してください。こちら
これから
しばらくは、ゆっくりして一ヶ月くらいセブ島に英語留学をしようと思っていたりします。その前に転職先を決めれたらいいなと思っているので、2月中に転職先を決められるのが理想。 ラクマっていう組織を再び大きくすることには充分貢献できたと思っているので、Fablicで出来なかったエンジニアとして会社を大きくすることにコミットしたいと思っています。
- 会社を好きになれること※たぶんこれが一番重要
- プロダクトが魅力的であること
- 会社が大きすぎないこと
- 組織的課題を抱えていること※あると良いが必須ではない
- エンジニアとして実装する余裕があること※あると良いが必須ではない
ここらへんを軸に色々な会社を見て回れると嬉しいと思っているので、是非お声がけください。
つよぽそ (@cobasparxxx) | Twitter にDMくれると助かります。
最後に
アプリの統合や、会社の吸収等中々経験できない事をやってきた気がしますが、この一年半楽しかったです。至らない点も多々あったと思いますが関わってくださった皆様本当にありがとうございました!!
小さく失敗しませんか?
こんにちは!!つよぽそです。
※この記事はEngineering Manager vol.2 Advent Calendar 2018 21日目の記事です。
今日は僕の所属している開発チームで意識していることを紹介します。
小さく失敗する?
さて、いきなり失敗するって書いてあって驚きましたか?そもそも失敗なんてしたくないわって思う人がほとんどだと思います。実際僕もそうです。失敗なんてしたくない。失敗をゼロにすることこそが本質だろうと。
だが、人間は失敗する
そうなんです。いくら失敗したくないと思って注意したところで、僕らが人間である限りは必ず失敗します。悲しい事実として人間は決して完璧な生き物ではないのです。恥ずかしながら僕はありとあらゆる失敗を経験してきました。辛いですね。
当然ながら完璧な物を作りたい。失敗なんてゼロにしたい。バグゼロだ!!と思って日々開発を進めるわけですが、こう思って寝る間を惜しんで開発に着手してありとあらゆるテストをして不安に押し潰されそうになりながら日々を生きたところで、いざリリースをしてみると残念ながらバグは発生します。ちょっとしたバグからクリティカルで死にたくなるようなバグまで。
失敗の影響をコントロールする
バグを出さないように努力することは当然の義務ではあるんですが、少し視点を変えてみます。そもそもバグは必ず起こる。だったらそのバグで発生する影響を最小限にできるようコントロールすることで安心を得ることができるのではないかと。バグは不確実性だと思っているんですが、バグの影響を最小限に留めつつリリースを行う環境を整備し、チームに浸透させていくこと、つまり不確実性をコントロール出来るようにすることもエンジニアリングマネージャーとしての仕事なのではないかと思っています。以下、弊チームで推進している小さく失敗するための施策を紹介します。
小さく失敗するための工夫
小さくリリース
リリースするうえで、如何に必要最低限の機能をリリースするのかを意識して動きます。一つの機能を考える時、全てを同時に出すことに拘りがちですが、一度立ち止まってもっと小さく機能を分解してリリースしていけるのではないかと考えてみます。最小限の機能で小さくリリースすることで以下のメリットを享受することができます。
- 最小限の工数でリリースしていくためスピードが早い
- リリースしていく中で新たな課題が見つかり方向転換しやすい
プルリクを小さく
小さくリリースにも関連しますが、プルリクを出来る限り小さい単位に区切ります。例えばですが、modelの実装のみ先にプルリクを出す等です。プルリクを小さくすることで下記のメリットを享受できます。
- レビューしやすい
差分が少ないため当然レビューに対する労力は減ります。変更点に焦点を絞れるためレビューの見逃しも減ります。
- バグの影響範囲を絞りやすい
差分が少ないため、どこの変更が影響しているのか調査が容易になる
- バグが出た時にロールバックしやすい
コードに差分が少ないため、リリース後バグを検知したあとに一旦releaseのバージョンを下げてデプロイする際の影響範囲が少ない。
※リリースされる機能が絞られているため他の機能までロールバックしなければいけないみたいな状況が少なくなる。
※エラーの検知をしっかり整備しておくとより安心した開発が可能になります。
feature togglesとcanary release
特定の機能やrubyのバージョンアップ等の段階的なリリースを可能にしてくれます。例えばですが全体の1%にのみ機能をリリースしてエラーが発生するかどうかを確認しつつ、徐々に公開率をあげて確かめて行くことができます。特に複雑な作りになっている箇所だったり支払い周りといったクリティカルな箇所に修正を加えたりといった場合に圧倒的な安心感を与えてくれます。メリットは下記です。
- user単位であったり公開比率といった段階的リリースが可能
- ごく一部のユーザーにのみ公開し挙動をチェックすることが可能
- 仮にバグを発見した場合、一旦公開率を0%に戻す事で落ち着いてバグの修正に取り組める
- 公開比率を調整できるため、A/Bテストも気軽に行う事ができる
※feature togglesとcanary releaseの考え方はujihisa氏がfablic時代に持ち込んでくれました。感謝
まとめ
※当然の事ですが、バグ自体は起こさないように全力を尽くしましょうね!!
では、楽しんで開発していきましょう!!