スクラムマスターからエンジニア戻って1年くらいたった

Qiita で開催されている Qiita×Findy記事投稿キャンペーン 「自分のエンジニアとしてのキャリアを振り返ろう！」 - Qiita に合わせて書いた記事です。

ついでなので Zenn にも投稿します。

転職を機にスクラムマスターからエンジニアになり、1年くらいたったのでざっくりふりかえっていきます。

1年前の今ごろ

スクラムマスターとして働いており、それなりに楽しい日々を過ごしつつも、エンジニアとしてスキルを持て余す・生かしきれない状況が続いていました。
スクラムマスターとしてチームを見ていて大変だったのは次の点です。

• エンジニアとしてのスキルで解決できる問題があるが、チームメンバーの対応に追われがちでした
  • 調整ごとが多く、私自身、コミュニケーションが比較的取れるほうなので窓口に立つことが多かったです
  • 結果として受けなくてもいいような連絡のパスなどをする必要があり、時間がとられメンバーが自分に依存することが多かったです
  • 今思うともう少し手放しでメンバーに頑張ってもらったほうがよかったのではないかと思います
    • メンバー同士で会話したほうが早いケースもあるので、もっと早くそうできればよかったかと思います
    • 自分の退職が決まってからは、メンバー同士でのコミュニケーションが増えたように思います
• エンジニアとしての勉強会には参加しているものの、MTGに時間がとられ残業時間で試すことが多かった
  • チームをもっとよくできるという意識があったものの、そのための時間がなかなか取れませんでした
    • 今思うと自分の時間を大切にすべきであったし、チームメンバーの視座を上げるための活動をもっと積極的に行うべきであったと思います
  • 私から勉強会で情報を得てきて共有しても、ほかの人はそれを享受するだけ・実施するだけになっているケースがあった
    • 勉強会の設計がうまくなかったのかも、と思い返しています
    • レトロスペクティブや部署の活動でそういう時間を設けられるような仕組みが必要だったのかもしれません
    • 文化づくりなのか、意識改革なのか、チームメンバーの採用なのか、私自身の問題だったのか、原因ははっきりしていません
      • しっかり共有する人、アウトプットする人ももちろんいましたが同じメンバーに偏っているように感じていました
    • ただ自分自身としてはうまく向き合えずフラストレーションをためがちで向き合い切れていませんでした
• エンジニアとしてのスキルがチームメンバーから評価され、評価者レイヤーからはマネジメントの評価をされていたように感じた
  • これ自身はうれしいことでした
  • 一方で期待されていることに対してのギャップなどにかなり苦しんでおり、最終的に解決できませんでした
  • ここに対しての答えはまだわかりませんが、腹をくくってある程度方向性を決めるしかなかったのかなと思います

総じて手を動かすエンジニアとして解決できる問題が多くチームメンバーにはそれを期待されている一方で、期待感のずれや周りとの温度感の差が大きく、葛藤が大きかったように思います。
他方、思っていたよりもプロジェクトの管理や進行において、スクラムマスターとしてチームを支え進行できていたというのは自分では気づけない自分の長所だったと感じています。

現在

現在は転職してバックエンドのエンジニアとして働いており、バックエンド・インフラの設計や構築を含めた開発を行っています。
エンジニアに戻って思うところは次の点です。

• 技術的なキャッチアップに全力を注ぐようになりました
  • 今のプロダクトフェーズもありますが、本当に必要なスキル・情報をすぐに取り入れる必要が出てきました
  • 割と初心に帰った気持ちでスキルを身につけられているように思います
  • スクラムマスターだった頃も勉強会には参加していたものの、勉強会に参加する姿勢が変わったように思います
  • また自分がいま主としてやっていないジャンルの勉強会や技術書については読む時間が足りず、こちらもそのうち参加したい気持ちです
• 要求を満たすための方向性を決められると感じるようになりました
  • 単純に言われたことだけではなく、何を解決すればいいのか？ についてエンジニア視点で見て、議論できるようになりました
  • スクラムマスターを経験したことで少し外からチームが開発しているものを見た経験が活きているように思います
  • スクラムマスターを経験したことでその期間分開発経験がなくなってしまったわけですが、遠回りしたことによって得たものがあると思います
  • エンジニアとしての経験年数や信頼していただくための行動も伴ってきている、という面もあるかもしれません
• コミュニケーションの窓口としてやり取りするのはあまり変わっていません
  • チーム規模が小さいため、そういったまとめフォローする動きはあまり変わっていません
  • ただし変にアジャイル・スクラムの言葉を使わないように注意しています
    • 言葉に引っ張られないことと、自分たちで考えることを大事にしています
• 技術的なキャッチアップ速度が遅くなっている気がします
  • 年なのか、体の衰えなのかはわかりません
  • 具体的すぎる話が入ってきづらくなっているように感じます

スクラムマスターからエンジニアに戻るにあたってやっていてよかったこと

• 実際の開発技術について概要から可能なら手を動かして触っていました
• コードレビューに参加していました
  • リリース物に関してはダブルチェックも兼ねてなるべく依頼がなくても時間をとって読んでいました
• クラウド周りは試験を受けるなどして、知識を広げるようにしていました
  • 技術選定の知識としては役立っているように思います
• 小さめのツールなどは自作して、業務の効率化をしつつコードを書く感覚を維持していました
• ISUCONに参加、準備でいろいろな技術に触ったり、勉強も続けるようにしました
• 社内・社外問わずに勉強会に参加していました

こう書いてみるとエンジニアとしてのスキルを維持するために勉強は続けられていたというのがわかります。
前職でスクラムマスターになってからも技術的に相談されることや、自分自身で新しい方法を見つけることも多かったです。

一方でスクラムマスターとしてはエンジニアのこまごまとしたところや技術的な面に対して向き合いすぎていたのかなと思います。
本来チームをフォローアップし、一人一人が考えてアジャイルに開発できるようにするのがスクラムマスターの役目ではないかと今は考えています。
しかし私の活動範囲では、逆に私に依存している部分が多くなってしまい、理想と現実がかけ離れていて苦しい気持ちもありました。

そういった意味でその組織・チームで私がスクラムマスターを担当したのはあまり適任ではなかったのかもしれません。

スクラムマスターに戻りたいと思うこと

• アジャイル・スクラム・マネジメントに関する勉強会に参加しやすいと思っています
  • 昨年の夏から秋にかけては休暇を取って参加していました
  • アジャイル・スクラム・マネジメントにかかわる立場であれば業務扱いで行けるのかな？と思っており、会社の補助制度の状況もありますがうらやましく思っています
• 開発を高速にするにはどうするべきか、をみんなで考えてその先頭にいられるのは楽しいのでまた考えたいです
• 様々な分析手法やツールを使って、チームのいろいろなものを可視化していくのは楽しいのでまた考えたいです
• チームのメンバーが成長するのを見ることにやりがいを感じるのでまた考えたいです

開発と組織の状況というのは似通っているように思います。
そういった面で、ここは開発の力ではどうにもならない組織構造の問題なんだ、っていうのを感じた時に活動しやすかったのはスクラムマスターの強みなのではないかと思います。

まとめ

スクラムマスターもエンジニアもどちらも面白い仕事ですが、これもまたある程度自分自身がエンジニアとしての経験を積んできたから見えるものもあると思います。
スクラムマスターを経験したことにより、視座を変え、プロダクトに目を向けて考えることができたというのは自分自身のエンジニアリングスキルを伸ばすための促進剤になったように思います。

今後しばらくはエンジニアとしてのキャリアを歩んでいくことになりそうですが、その先に何をしていくか？はこれからまた考えていきたいです。

おまけ

スクラムマスターをしていた時に読んでいて面白かった本をいくつか紹介します。
エンジニアに戻ってからは公式ドキュメントばかり読んでいる気がしますね…。

• 読みやすいコードのガイドライン ―持続可能なソフトウェア開発のために：書籍案内｜技術評論社
  • 個人的にはチームレベルでコードを書くことを意識している本で、リーダブルコードよりも個人的にはおすすめだと思っています
• アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知 電子書籍｜翔泳社の本
  • タスクの分解や git を使った開発フローの整備など、リーダーレベルのエンジニアを目指す人にとって学びが多い本なんじゃないかなと思っています
• 『XPエクストリーム・プログラミング実行計画』｜感想・レビュー - 読書メーター
  • （本のページが見つからなかったので読書メーター） なぜ計画するか、それをメンバーとしてどう考えるかを学ぶことができる本だと思います
• ゾンビスクラムサバイバルガイド - 丸善出版 理工・医学・人文社会科学の専門書出版社
  • 自分たちのスクラムがおかしくなっていないかを点検できる良い本です。とても耳が痛い。
• 良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方：書籍案内｜技術評論社
  • あとで困らないためにコードを書いていくべきか？をよく考えさせられる本だと思います
• ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用：書籍案内｜技術評論社
  • この本も同様にどうコードを書いていくと良いのか？を考えさせれる良い本だと思います