エンジニアとしてのキャリアを泥臭く試行錯誤したらスクラムマスターに辿り着いたが、さらに泥にまみれた話

こんにちは! Viibar でWebエンジニアをしている ijawaman です。
最近3月のライオンを読んだら将棋熱が再燃しました。
居飛車よりも振り飛車が好きです。
スーって飛車を動かす感じが気持ち良いですよね。

さて、Viibarにjoinしてから1年が経ちました。
Viibarではスクラムで開発をしています。
今回は、昨年末から始めたスクラムマスターというスクラムにおける役割について、始めたきっかけと現在までに感じたことを書きます。

ここでは書かないこと

スクラムについては非常に多くの情報がありますので詳細は書きません。
興味のある方はぜひ調べてみてください!

同じスクラムチームで開発をしているデザイナー 品川の記事はデザイナー目線でのViibarのスクラム開発についてわかりやすく書かれているので、「小難しい記事はイヤだ!」という方におすすめです!
スクラムのおかげで理解したUX/UIという言葉の意味

この記事で書いているスクラムマスターは、「スクラムチームの作る価値を最大化する」という役割を背負った人くらいに理解していただければと思います!

それは1年間の振り返りから始まった

スクラムマスターをやろうと思ったきっかけは、昨年11月に上長が調整してくれた「1年間の振り返り会」でした。

この会は、会社のこととは切り離して自分自身の成長のために、振り返りのレポートをまとめてエンジニアチーム全員でワイワイとツッコミしあう会でした。
上長もレポートをまとめてメンバーがツッコミしている光景はViibarのフラットな組織文化を現していると感じます。

レポートは概ね以下のお題でまとめています。

  • この1年やったこと・学んだこと
  • 心残り
  • 来年1年後どうなっていたいか・何をやりたいか

エンジニアとしてどう成長していこうかと試行錯誤していた1年を過ごしていた私にとって、この会は自分の大事にしたいことを再確認する良いきっかけとなりました。

スクラムマスターならやりたいことができそうだった

振り返りの結果、私が最もモチベーションが上がる瞬間は、チーム・自分自身が作ったプロダクトがユーザーに価値を提供できた時だと整理されました。

ユーザーに価値を提供したいならスクラムマスターでなくても良いのでは?とも思えますが、私は開発という行為自体が大好きですし、個人が生み出すアウトプットには限界があるため、チームで協力して作ったものでユーザーに素早く価値を届けたかったのです。

このモチベーションがスクラムマスターの役割と一致する点が多かったのと、Viibarのスクラムチームは当時、スクラムマスターを明確な役割として設けていなかったためスクラムマスターをやることを宣言しました。

Viibarでのスクラムマスターは壁打ちの壁

Viibarのスクラムチーム(プロダクトオーナー、デザイナー、エンジニア)はスクラムの基礎知識があり、日々課題感を持ちながら開発しているため、スクラムマスターがやるべきことはその課題感を一旦ぶつける壁となることでした。
これまではぶつける壁が明確でなかったため、自分のことながら人柱が現れたのはよかった点です。
(ちなみに課題感はGitHub issueに自由に書いてもらっているだけです。個別に詰められているわけではありませんw)

《チーム開発の課題感を募集しているGitHub issue》

それらの課題感は不定期に「チーム開発について話す会」と称して、チームビルディングのMTGを調整しています。
この会は「スクラムの各役割(プロダクトオーナー、開発メンバー、スクラムマスター)に期待することや課題感」「自律したチームとは」といった明確な正解がないことをテーマに話すことが多いです。

そのため、MTGは全員が付箋で考えを記載し、ホワイトボードに貼って発表する進行方法をとっています。

《こんな感じで全員が考えを共有してます》


この方法は全員の考えを確実に集めることができるのでチームビルディングにはぴったりの方法だと思います。

「プロダクトオーナーに求めること」一つをとってもメンバーそれぞれ異なっており、同じキーワードを使っていて、認識を共有しているつもりでも少しずつズレているんだなぁと発見できて面白いです。

なお、この会の名称に「スクラム開発」ではなく、「チーム開発」を使用しているのは、スクラム開発はあくまでも開発手法であるため、場合によってはスクラム開発を捨てる可能性があるからというちょっとしたこだわりです。

結局悩みは尽きない

スクラムマスターとしてチームに貢献していくという目標は定まったものの、悩みは尽きません。

例えば、前述のチームビルディングMTGは、それ自体がユーザーに価値を提供することはないため、進行中の開発タスクとのバランスが難しいです。

また、悩みの最たるものは「スクラムチームの価値」です。
冒頭にも書いた通り、スクラムガイドによると、スクラムマスターの役割には「スクラムチームの作る価値を最大化する」というものがあります。

この「価値」とは何か最近よく考えます。
わかりやすい価値(っぽいもの)としては、プロダクトの売上や開発のベロシティがあります。

しかし、売上というものは市場やプロダクトの性質次第だったりするため、スクラムチームの価値としては、コントロールできない点が多過ぎて適切ではないと考えています。
また、ベロシティはあくまでもそのチームがある期間で応えることができる要求の量であって、生産性を表すものではないため、この数字を追うことに意味はあまりありません。

だからこそ大事にしていきたいこと

ですので、売上や生産性は非常に大事なのですが、それらを直接追うことはしていません。

現在は焦る気持ちをグッと抑え、チームメンバーがそれぞれ考える良いチーム、良い開発を尊重・共有することを第一にしていきたいと考えています。
その中で生まれた課題を解決した先に悩みを晴らす何かが見つかる気がしています。

でわでわ。

株式会社Viibar's job postings
7 Likes
7 Likes

Weekly ranking

Show other rankings