Zenn
✨

転職して半年が経過したので振り返ってみる ~全体像編~

2022/10/02に公開
スクラム
転職
開発
idea

2022年4月に転職してから約半年が経過した。転職してから激動の日々を送っており、転職前と転職後では見えている世界が大きく変わるほどいろんなことを経験してきたのでここで一度振り返ってみようと思う。この記事では何をしたのかの概要と何を学んだのかを振り返る。具体的なエピソードについては別記事にて書いていく。

私は何者か

都内のSaaS開発企業のエンジニアをしている。役割としてはフルスタックエンジニアとして勤務していてフロントエンドとバックエンド、時々CIの開発をしている。また、スクラムマスターとしての役割も持っており、チームを自律型組織にするために奮闘している。

今まで何をしてきたのか

4〜6月

入社後すぐに環境構築をしたり、バグ改修や新規機能開発を通して技術理解を進めていった。前職と今の職場で使っている技術が全く異なっていた[1]ため、初めは新たな技術のキャッチアップをしながらバグ改修や機能開発をしていった。この時期は自分が書いているコードがどういうものなのかを理解するのに精一杯で、開発に時間がかかることが多かった。また、現職のフロントエンドではライブラリを至る所で利用しているため、それぞれのライブラリの使い方や仕組みを理解しながら開発を進めていた。
また、6月の終わり頃にスクラムを採用したチーム開発が始まった。その時、「7月から本格的にスクラムを運用するけど、スクラムマスターやってみない？」とお誘いを受けたので、挑戦することにした。7月までにスクラムについての書籍を読んでスクラムについて理解し、スクラムを自分のチームでどう運用するかを考え、Notionにまとめてチームに共有するなどのことをしていた。また、スクラムを運用するためのツールとしてZenHubを利用しているため、ZenHubの基本的な使い方やレポートの見方などのキャッチアップも行っていた。

7〜9月

開発者として

機能開発やバグ対応を引き続き行いながら、プロダクトの品質を向上するための活動をするようになった。たとえば、現職ではFlywayを使ってDBマイグレーションのバージョン管理をしているが、このバージョンがmainと開発ブランチで矛盾が生じていないかを確認するためのCIを新規で作成したり、フロントエンドのHooksの単体テストを新たに実装するためのライブラリを導入したりしていた。また、Storybookを使ってコンポーネント開発をした。GraphqlのクエリをStorybook上でどうやって表現したらいいかわからず苦戦したが、先輩たちに助けられながらなんとか実装できるようになった。これらによって、プロダクトの品質を向上するための基盤を構築することに貢献した。

スクラムマスターとして

チームのメンバーがそれぞれ納得しながらスクラムを運用できるようにするための活動をしていた。スクラムとは何か、なぜスクラムを採用するのかをまず説明し、リファインメントとスプリントレビュー以外のセレモニーでファシリテーターとして議論をまとめたりしていた。しかし、なかなかベロシティが安定しなかったり、セレモニーの時間が伸びたり、議論が発散してしまうことが多くみられるようになった。これらは9月に大きな課題として直面したため、チームリーダーと協力してスクラムを再構築することにした。スクラムを採用する目的や、各セレモニーはなんのためにあって、参加者にどんなことを期待しているのかなどを明確にしてチームメンバーに共有した。その結果、現在はメンバー全員が当事者意識を持ってセレモニーに参加するようになっている。まだまだ課題はあるが、チームが自律型組織になるための階段を一歩ずつ着実に登ってきていることを実感している。

何を学んだのか

本当にたくさんあるが、ここでは私が考える一番大きな学びを紹介する。そのほかの学びについては後続の記事を見ていただければと思う。（近日中に公開予定）

より良いチームを構築するにはどうすればいいのか

ファシリテーターを始めたばかりの頃、相手の発言を表面的な理解にとどまった状態で議論を収束させたために全員が納得できない状態の結論を出してしまったり、表面的は解決策しか出てこなかったりしていた。また、議題と関係のない発言をメンバーがすることで議論が発散し、十分に問題の深掘りができなかったため、表面的な解決方法を結論としてしまうこともあった。その結果、チームのベロシティが安定せず、予定通りに開発を進めることができなかった。また、チームのメンバーのモチベーションも高くなく、チームというよりは個の集まりのような状態になっていた。なぜこのような状態になっているのかを考えた結果、「発言の背景と意図まで聞いて、理解した上で議論を進めること」「会議の意図とゴール、メンバーへの期待値を明確にしてから議論を始めること」「今何の議論をしていてどんな発言を期待しているのか、メンバー全員が理解していること」という3つの課題があるのではないかと結論づけた。これらを解決するために会議体を見直し、さまざまな対策を講じた結果、現在はそれぞれの課題をほぼ解消できており、議論が発散することも、表面的で具体性のない結論を出すこともなく、全員が納得できてかつ具体的な結論をチームのメンバー全員で作り上げることができるようになってきた。また、チームのメンバーのモチベーションも向上し、ベロシティについても安定してきている。開発業務をしながらより良いチームを構築するために自分は何ができるか、メンバーに何を期待しているのかを考え続けていたのでまとまった時間を取ることが難しく、しんどい時期もあったが妥協せずに「スクラムを導入する理由はなんだろうか」とか「チームの理想の状態はどんなものだろうか」などといったことを考え抜き、自分なりn答えを出した経験ができたことはとても大きな学びであり、今後の成長につながると信じている。

まとめ

開発者、スクラムマスターそれぞれの具体的なエピソードについては後続の記事で話すが、半年を振り返ると本当にいろんなことを経験できたのではないかと思う。また、スクラムマスターとしてチームの課題に向き合うことで、課題を解消してチームがより強固に結束する姿をリアルタイムでみることにやりがいを感じるようになった。現職に転職することで得た成果だと感じているため、転職して本当に良かったと思っているし、これからも頑張っていきたい。また、スクラムマスターとしての挑戦記については別の記事にて詳しく説明しようと思う。

脚注

  1. 超ざっくりとした技術スタックの違い
    前職
    ・フロントエンド : JavaScrpt + jQuery
    ・バックエンド : Java, Struts
    ・API : REST
    ・インフラ : オンプレ + AWS
    ・CI / CD : Jenkins
    現職
    ・フロントエンド : TypeScrpt + React
    ・バックエンド : Golang
    ・API : Graphql
    ・インフラ : GCP
    ・CI /CD : GitHub Actions ↩︎

Discussion