はじめに
組み込みソフトウェアエンジニアを10年以上続けてきた私が、スクラムに目覚め、エンタープライズ系のスクラムマスターにジョブチェンジしてみた振り返りをまとめてみました。
内容としては一般的でないものも多い気がしていますが、同じようなキャリアパスを描いている人もそうでない人も参考程度に見ていただければと思います。
転職前の状況
ソフトハウス、電機メーカーを転々とし、プログラマ5年程度、プロジェクトリーダ5年程度、何でも屋さんとして様々な炎上プロジェクトを飛び回る業務を5年程度を経験。
炎上プロジェクトを飛び回る中で、モチベーションの失われたエンジニアの生産性に限界を感じ、スクラム信奉者になる。
何でも屋さんの後半はモチベーションの高いチーム作りをモットーに、スクラムを勉強しつつ自分の権限範囲内でスクラム開発を導入するも、ウォーターフォールを基準に整理された社内プロセスの壁に跳ね返され、転職を決意する。
転職前時点での知識レベルは以下みたいな感じ。
- CSMの資格あり、スクラムマスター経験はそこそこ
- プロジェクトリーダーの経験はそこそこ
- プログラミングはここ数年殆どしていない（経験あるのもアセンブラとかCとかJavaとか💦）
- クラウドに関する知識は「何それ？」レベル
- ピエロ適正あり
といった感じで、このレベルでよくエンタープライズ開発を行う部門で採用してもらえたな、というレベルです。（ピエロ適正があると面接での受けが良いんですよね☺️）
転職後の所属チームの状況
転職後の所属部門は社内でスクラムを推進する部門で、スクラム開発に集中しやすいよう報告等も最小限に抑えられていました。感激😭
私が配属されたプロダクトは、以下みたいな感じです。
- サービスインから数年経っており運用と開発を並行して実施。
- 全てAWS上でサービスを提供。
- 体制はScrum of Scrumsを採用し３チームで運営。
- プロパとパートナーさんが3:7くらいの割合。
AWSはほぼ知識なし、Scrum of Scrumsは知識としてのみ知っている、といった状態でどうなることかと思っていました。
が、なんとかなるものですね😅。
最初3ヶ月はネイティブエンジニア兼SM補佐として入り、4ヶ月目からはスクラムマスターとして半年以上楽しくやらせてもらっています。
以降で、半年間の間に感じたことをまとめて行きたいと思います。
良かったこと
スクラムマスターに専念できた
自分も経験ありますが、エンジニアからスクラムマスターになると、なまじ知識がある分どうしても開発チームに混じって自分の開発タスクを持ちたくなるのですが、そうすると「スクラムマスターの仕事＜自分の開発タスク」となり失敗することが多いと思うんです。
最近読んだSCRUMMASTER THE BOOKにも書いてありました。
今回の私のケースでは、エンジニアとして役に立たない分、スクラムマスターの仕事に絞って取り組めたので、チームにとっても、自分にとっても良い方向に働いたように感じます。
（自慢出来ることではないですが、）開発チームの誰もが私にエンジニアとしての期待をしていない、ってのも大きかったです。
プログラミング言語の壁は気にならない
私のプロダクトでは、私自身が未経験のVueやPythonだったり使うことが多いのですが、スクラムマスターがコード見ることって殆ど無いんですよね。
ただ、コードから改善のタネを見つけられたりするので、読めるに越した事はないとは思います。
上にも書いたのですが、チームの誰もが私にエンジニアとしての期待をしていない状態なので、私に意見を求める時は要点を整理してくれているので、プログラミングの知識のなさは全く気にならなかったです。
組み込み開発もエンタープライズ開発も変わらない
こちらもスクラムマスターの仕事を行う上では、あまり関係なかったです。
私自身が入社前に困るかなと思っていたのは、チームの抱える課題を抽出し適切な改善策が打てるか、という点だったのですが、以下に書いた感じでなんとかなりました。
- 広い視点（設計時の観点不足や試験の自動化の必要性など）で見た時には、課題の抽出方法もそれに対するアプローチも、組み込み開発もエンタープライズ開発も全く同じ。
- 狭い視点（Pythonライブラリの知識不足やリファクタリングの必要性）は、組み込みとエンタープライズで異なる点も出てきますが、その粒度になると振り返りで開発チームから問題点として出てくる。
それをきちんと拾い対策をチームで決めていくことで解決できる。
プロジェクトリーダーの経験は役に立つ
全てのプロダクトに対して言えるわけではないと思っていて、私の担当するプロダクト固有のものだと思いますが、
Scrum of Scrumsを採用している私たちの場合、プロダクトオーナーが全てに対して目が届かず、スクラムマスターにある程度プロダクトオーナー的な視点も求められています（スクラムのアンチパターン😅）。
プロダクトオーナーならこう判断するだろうとか、このレベルならプロダクトオーナーの判断なしでチームで決めて良いはず、などの価値観を合わせることがスムーズに出来たのは、プロジェクトリーダーの経験が活きたなと思います。
苦労したこと
AWSの知識が足りない
フルクラウドで動くプロダクトを担当する以上、最低限の知識がないと話題に付いていけないですね。最初は打合せで議論に付いていけず、知らない単語をメモするだけで精一杯でした。
これは入社前に課題として考えていた点で、会社から研修を受けさせてもらうなどし入社当初に比べると徐々に解消してきています。
UXへの意識の違い
こちらは入社前には想像していなかった苦労した点です。
組み込み開発だと・・って一括りにしてしまうと怒られそうですが、組み込み開発の場合、製品を使う人が限られているので、作りやすさを優先しUXに対する意識が低くなってしまいがちでした。（ちょっと使いにくいけどマニュアルに書けば良いや的な）
エンタープライズ開発というかBtoCの場合は、使い勝手が悪いとお客さんが離れていってしまうので、その辺りの意識の違いに戸惑うことが多くありました。
UIの仕様だったり、不具合に対する重要度の認識差異だったり。
根本的な解決策は見当たらず、徐々に慣れていくしかないかなと思います。
こうしとけば良かったなと思ったこと
考えてみたんですけど、浮かびませんでした。
向上心が足りないのかも。。。
自分のこれまでの経験をチームに還元することも、苦労したことに対する取り組みも、自分なりに出来る事は出来たかなと。
終わりに
思いのほか長くなってしまいましたが、同じようなことを考えている方の参考になれば嬉しいです。
最初からスクラムマスター目指す人っていないと思っていて、そう考えるとスクラムマスターへのキャリアパスって色んなルートがあると思います。
ちょっとでも興味ある方いれば、スクラムマスター面白いので是非挑戦してほしいです！！