新卒から2年7ヶ月お世話になった会社を退職しました

はじめに

2年7ヶ月お世話になった楽天株式会社を退職しました。 退職エントリを自分のために書きたかったので書きました。短く書こうと努めましたがかなり長くなりました。 楽天という会社について良い事も悪い事も色々書きたかったのですが「御社にとって不利益なことは発信しません」の内容が盛り込まれた退職時の誓約書にサインをしたので、私の会社への所感も含めここには書かないことにしました。 結果、私のための私の成果をアピールするだけのつまらない記事になっています。 楽天について知ろうと偶然にもこの記事を読んでいる方の期待には応えられないです。すみませんm( )m そういうこともあり、ここでは私が所属していた部署の事業内容、業務内容についても具体的には触れません。

なぜ転職を選んだ?

技術力を向上させたいと思い転職を決意しました。 私のエンジニアとしての1つの理想像が「技術コミュニティに対し有用なものを生産し配信し続けるエンジニア」だと自分の中で落ち着いたのでそれにより近づける環境に移ろうと思いました。

やってきたこと

はじめに

私は新卒入社からの2年7ヶ月、一度も異動はなく同じ部署のグループに所属しており、退社するときにはある程度の古参メンバーでした。 私が入社したときはグループのメンバーは少なかったのですが、徐々に採用が盛んになり3年目になる頃にはグローバル企業らしく国際色が非常に豊かになっていました。東西アジア圏、東西ヨーロッパ圏、南北アメリカ圏と様々な国出身の人たちが在籍するようになりました。日本にいながらそういった環境で仕事ができたのはとても貴重な経験でした。

1人での開発プロジェクト

入社してから10ヶ月くらいの間は業務機能追加のためのプロジェクトを単独で実施していました。初めのOJTでのプロジェクトを含めると3つのプロジェクトを単独プロジェクトとして取り組みました。1人といってもレビューは上司やチームメンバーにしてもらいます。 この頃はチームとしては完全にウォーターフォールの開発スタイルでした。プロダクトマネージャから要件定義を聞いてすり合わせ、DBスキーマ等を決める基本設計、プログラムの制御を記述する詳細設計、コーディング&単体テスト結合テスト、QAを順にしていくという具合です。 とにかく一番はじめのOJTでのプロジェクトが大変でした。というのも業務としての開発は全くやったことがないのにいきなりDBスキーマの設計などをしないといけなかったからです。(もちろんメンターの方がしっかりサポートしてくれました。)実装フェーズにおいても学生のころには触れなかったプログラミング言語フレームワークミドルウェアに慣れる必要がありました。仕事の進め方、開発のやり方の2つのダブルパンチを受けながら必死に食らいつきました。このOJTが終わるころには確かに当初と比べるとレベルアップした実感が得られました。

運用 (システムトラブル対応と問い合わせ対応)

自身のためにも一番残しておきたいのが運用タスクです。前述のOJTプロジェクトが終わるころに運用タスクも他グループメンバーに混ざり行うようになりました。 運用というのはシステムのトラブル対応と問い合わせの調査タスクです。私が所属していたチームが持つプロダクトは業務機能が複雑であるということもあり(ここではこれが主な原因であるということにしておきます)発見することが難しい内在的な不具合が存在するかつトラブルがあると業務的なインパクトも大きいということで運用タスクが重要でした。 この運用へ時間を多くかけてしまうこと自体は問題であり私を含めチームメンバーで常に改善をしてきましたが、この運用タスクを行うことで、サービス提供者としてどのようにユーザにとってベストな対応ができるか、プロダクトを保守していくとはどういうことなのか、どのように開発すればヘルシーな運用をすることができるのか、といったことを学ぶことができました。 またカスタマーからの問い合わせ内容を調査する場合には、プロダクトのユーザは実際にどのような使い方をしているのか、どのような部分を不満に思っているのかを知ることができる場となっておりプロダクトというのはユーザのために作っているということを実際に考えることができるようになりました。(これは当たり前のようですが開発者は開発すること自体に没頭すると頭から離れがちになります。)

チームで開発プロジェクト

2年目になるとグループ全体として大きな変化がありました。既存のプロダクトと同じ業務機能を持つプロダクトをフルスクラッチで開発するという大きなプロジェクトが始まったことです。結果このプロジェクトは1年2ヶ月をかけてリリースがされました。 グループの中で各業務ごとに6つほどの小チームを編成しました。私は1つの小チームのリーダーを務めました。2年目のペーペーがリーダーをやった理由としてはグループには上記で述べた運用も行う正社員の雇用形態のメンバーと主に開発を行うパートナースタッフの雇用形態のメンバーが混ざっていたことにあります。私個人としては最後までこの雇用形態の違いによるロールの違いに違和感を感じていましたが、正社員がプロダクトオーナーとコミュニケーションを取りながら業務機能を理解し開発をリードする立場になるのはグループ全体として自然なことでした。 この大きなプロジェクトから実施されたのがアジャイル開発です。フレームワークとしては一般的なスクラムで実施しました。これによりアジャイル開発というものに曲がりなりにも触れることができいくつかの書籍を読むことでアジャイル開発の思想のファンになりました。 しかしどの現場でも似たようなことになっていると思いますが、スクラムマスターとプロダクトオーナーの経験がありリードしてくれる人材が少ないために実際にはあまりうまく回りませんでした。私は結局ロールとしてはスクラムマスターとプロダクトオーナーの兼任をしていました。各タスクの具体的な完了条件を記載しプライオリティを管理、デイリースクラムやレトロスペクティブといったスクラムイベント内では未経験ながらもチームが良い方向となるように建設的な対話ができるように努めました。 私個人の問題としてはまだ2年目のエンジニアでありながらコーディングをすることから離れてしまいがちになったことです。立場上コードレビューをすることはあってもコーディングをしなくなってしまったことに危機感を覚えました。そしてその危機感は最後まで続き転職に至ったという感じです。

その他

以下のことは上記以外で自分から積極的に取り組み貢献できたなと感じているタスクです。

CIツールの再構築

私が入社したときからグループのプロダクトが持っていたクリティカルな課題の1つにCI上で単体テストが走っていないという課題がありました (ちなみにCIツールはTeamCityと呼ばれるJenkinsと同様のオンプレミスCIツールです)。 開発現場を踏んでいる方ならばわかるようにこれは品質に直結する課題でありあってはならない状況でした。他の開発メンバーも良くない状況であると把握しながらもCIツール環境を構築したエンジニアがグループから離れているかつその設定が複雑であることから誰も手を出せていませんでした。 プロジェクト完了直後のちょうど時間に余裕ができていた時期だったこともあり上司にこの問題の対応のリソースを与えてもらうよう相談し経験が無いながらも取り組んでみました。確かにCIツールが複雑であり設定や自動化スクリプトも複雑であるため始めは面食らいましたが、公式ドキュメントやスクリプトを根気よく読み進め結果的に単体テストをCIツールで動かすことにコミットできました。 また、ビルド結果をBitbucketへプルリクエスト前に表示するようにしたり特定のブランチを定期的にビルドしデプロイツールへ繋げる仕組みの構築などにも貢献しました。

システムアラート通知の改善

上記にて言及した運用タスクでは業務後と休日中のトラブル対応は週代わりの当番制でグループ内で行っていました。 課題としてアラート当番の人とそれ以外の人がプライベートのスマホからでもアラート通知を気づくことができる仕組みが無いことでした。 そこでその当時自分が触ってみたいと思っていたパブリッククラウドでのサーバレスアーキテクチャの機能を利用した安上がりで作れるアラート通知システムを構築しました。 その詳細は以下のリンクにスライドとして公開しています。

https://speakerdeck.com/momotaro98/alertforviber-20171207

これは今でもちゃんと動いておりグループメンバーに利用してもらっているので作ってよかったです。

学んだこと

円滑な仕事の進め方

入社当初がある意味一番苦労しました。これは新卒ならば多くの人がそうだと思いますがそもそも社会人として仕事をするということに慣れるまでが一苦労でした。 以下は、入社直後のOJT期間中に上司やメンター、先輩からのアドバイスをもとに自分用のメモとして取った内容の一部です。

  • 自身での判断に迷ったときはすぐに相談をすること
  • 報告は事実を述べることに集中しネガティブな内容でも自信を持って堂々と伝えること
  • 相談するときはなるべく漠然としたオープンクエスチョンになることを避け、自分の考え(選択肢の1つ)を持ってそれでは問題ないかといった形で相談すること
  • 判断を上司に仰ぐとき、選択肢が複数あれば、それぞれの特徴を説明できるように準備しておくこと
  • 提案をする際はメリットとデメリットを洗い出し、メリットが大きいこととデメリットの影響が小さいこと、デメリットの対策方法を説明できるように準備すること
  • 新しいことを提案をするときは、その影響範囲を把握しておくこと
  • レビュー依頼時にはレビュアーに対してレビュー対象のスコープを明確に示すこと
  • 憶測で話すクセがあり相手を混乱させてしまうシーンがあるので、事実と推測を明確にして相手に伝えること
  • 指示を受けて自分が具体的に何をするかイメージがつかなかったらその場ですぐに聞いて確認すること
  • タスクを依頼されたら「いつまでに行えばよいか」のデッドラインの要望を確認し「自分がいつまでにできるか」を伝えること
  • 人にタスクを依頼するときは、いつまでにやって欲しいかのデッドラインの要望を伝え相手からいつまでできるかの確認を取ること

報連相、提案のやり方、コミュニケーションに関する内容のメモを多く取っていました。まともなビジネスマンにとっては当たり前なことの羅列だと思いますが、上記の内容は今後もサラリーマンをやっていく上で常に守っていくべきことだと思いここにもメモとして残します。

技術力

この2年7ヶ月で職場で学ぶことができた技術スタック、技術的トピックを箇条書きすると以下の感じになります。

仕事にて技術的に得た知識と経験はたまにQiitaの記事にしていました。 以下がそんな記事たちです。

https://qiita.com/momotaro98/items/460c6cac14473765ec14 https://qiita.com/momotaro98/items/3044a1a792eb58d3b6b2 https://qiita.com/momotaro98/items/c4fe0fff0c173e879f2d https://qiita.com/momotaro98/items/6c4d4a061a1d95d4c551 https://qiita.com/momotaro98/items/84fb1ba832f0d4f9f80b https://qiita.com/momotaro98/items/35fb835ce92e5d5bacb2 https://qiita.com/momotaro98/items/62f866433da1a8bcd8a9 https://qiita.com/momotaro98/items/5e37eefc62d726a30aee https://qiita.com/momotaro98/items/99d5ccdce0166ad4d73b https://qiita.com/momotaro98/items/ad859ec2934ee98540fb https://qiita.com/momotaro98/items/7be27447f5f4a5c8bac9

次はなにする?

次の職場では晴れてGo言語でのサーバサイドエンジニアのポジションを与えていただいています。チームへどんどん積極的に貢献していきたいです。 また、遅くともこれからの2年間の内に、Go言語関連のコミュニティの場で発表すること、メジャーOSSへのコントリビュートをしていきたいです。