2022年2月1日
Chatwork株式会社 エンジニアリングマネージャー
粕谷 大輔
2001年に大学卒業後、SI、ソーシャルゲーム開発を経て、SaaSサービスの開発エンジニアやディレクターを経験。2021年よりChatwork株式会社にてScrum@Scaleをベースにした開発組織づくりに携わっている。共著に『Mackerelサーバ監視[実践]入門』(技術評論社)、『開発現場に伝えたい10のこと』(達人出版会)。アドバンスド認定スクラムマスター/認定スクラムプロダクトオーナー。
チームメンバーがスクラムの理論を理解し正しく実践できるよう、障害物を取り除いたり、問題解決を促したりする「スクラムマスター」。アジャイル開発の推進に伴い、近年そのニーズが高まっている。
Chatworkでは根幹部分のアーキテクチャのマイクロサービス化に取り組んでおり、Scrum@Scaleを採用し、各マイクロサービスの開発に単一のスクラムチームを割り当てて進めている。Chatworkのエンジニアリングマネージャーを務める粕谷大輔さんは、スクラム開発についての悩み相談を受け付ける「だいくしーのスクラムBar」を主催し、自身の知見を積極的に発信してきた。
開発組織づくりに携わってきた粕谷さんが見ている、スクラムマスターとしての現在地と夢を聞いてみた。
Chatworkで実践されているScrum@Scaleについてはこちら
初回はChatworkでも実践中のフレームワークであるScrum@Scaleについて話しましたので、「どうやったらScrum@Scaleをうまくスケールできるか」についてリスナーと一緒に悩みました。
この前ちょっと回答に困ったのは、「フリーランスエンジニアとしてスクラムマスターへキャリアチェンジできますか」という質問です。
というのも、フリーランスでも通用するようなスクラムマスターのスキルを身につけるには、少なくとも1年以上実際のスクラムチームで仕事をした経験が必要だと考えているんです。でも、その経験をフリーランスのエンジニアとして得るのはなかなか難しいのかなと。
スクラムマスターはほぼフルでチームに張り付かないと、そもそも務まらないと思いますね。幅広く仕事していきたいフリーランスの方には好まれないこともあります。アジャイルコーチになると、週2日程度でコンサル的な立場からプロジェクトに関わるような働き方もできますが、そこまで行くにはもっと実践で経験を積んでいないと務まらないかと。
そうですね。結局のところ、フリーランスとしてスクラムマスターをやりたいのならまずは会社員として経験を積まないといけない。でもそれでは、フリーランスのワークスタイルではいられなくなります。ニワトリが先か卵が先かみたいな話ですね。
悩んだ結果、「会社員のほうがスクラムマスターの経験は積みやすいものの、その後、そのスキルを活かしてフリーランスで活動することはできるだろう」とお答えしました。
自分のためと会社のため、両方に理由があります。僕が考えるに、情報は発信した人のところにどんどん集まってくるんです。自分の出したアウトプットに対して皆さんがSNSでディスカッションしたり、もっと聞かせてよと声をかけてくださったりすることで、そこからまた新しい情報、別角度の意見を知ることができます。
さらに、積極的なアウトプットは個人のキャリアにとっても有利だと思います。僕は10年ぐらい前から、地域のエンジニアコミュニティなどに顔を出すようになったんです。その当時はSI勤務で、社内業務だけだと自分のスキルを人にアピールすることはかなり難しいと、実感していました。イベントで発表したり、メディアで記事を書いたりすることで、どういう取り組みをしてきたのかをより直感的に他人に伝えることができる。なので、今は外に知られて良い情報ならすべて出すくらいの気持ちでやっています。
一方でChatworkは今Scrum@Scaleを積極的に実践していて、スクラムマスターの人材確保に力を入れています。それこそアジャイルコミュニティに対して露出を増やしていかないと認知してもらえないので、アジャイルやスクラムに興味のあるエンジニアと接点を増やしていき、良い人材の採用につなげたいと思っています。
やはりスクラムをスケールさせること自体が難しいです。スクラムというのは、もともと小さな範囲内でやる開発方法なので、それを複数チームにスケールするには様々な課題がありますね。たとえば、複数のチームを同時に動かしながら1つのプロジェクトを進めるには、互いの情報共有をスムーズにできるようにまだ工夫が必要です。
また、スクラムマスターの人材不足もスケールするときのボトルネックになりがちです。特にスクラム開発の経験が浅い未熟なチームでは、スクラムマスターが果たす役割は大きいと思います。
ChatworkでScrum@Scaleの枠組みで動いているチームは3つあるので、本当はスクラムマスターも3人いるのが理想です。でも実際は、僕が2チームのスクラムマスターを掛け持ちしていて、あと1人は外部のアジャイルコーチの方にスクラムマスターとして入ってもらっている状態です。これが今後4チーム、5チームと増えれば、兼務では回らなくなってしまう。なので、社内でスクラムマスターをどう育てていくかが課題ですね。
スクラムマスターになるには、スクラムチームでの成功体験が必要だと思っています。チームづくりの結果が出るには少なくとも半年くらいかかるので、すぐに育成できるものではないんですよね。
ただ、スクラムマスターに興味がある人は多いので、社内でスクラムマスターについて情報交換するグループチャットをつくったり、週1回30分集まって情報交換する場を設けたりして、育成の促進に取り組んでいます。
僕が大切にしているのはチームを丁寧に観察することです。チームメンバーの仕事の様子や仕事の中における情報の流れ方を隣で見ながら、ときには図に落としてどこを改善していくか考えています。たとえば、週末になるとみんなつらそうだなと思ったら、「毎週末のリリース作業が非効率ではないか」と原因を想像して、掘り下げていきます。
やはりリモートワークとなると、みんなの仕事中の表情や動きを観察することは難しくなりました。その代わりに、1on1やデイリースクラムなどオンラインで顔合わせるときは神経を尖らせていますね。カメラオフでも声色が元気なさそうだったら仕事の進捗が良くないのかなとか、いつも丁寧に文章を打つ人が急に簡素な文章になったら忙しくて手が回らなくなっているのではないかとか、継続して観察しているからこそいつもとの差がわかります。
このように、チームが困っていることやボトルネックを見つけて、どう改善するかを考えます。仮説が正しく、改善策が効いたときはスクラムマスターをやっていて一番楽しい瞬間ですね。
スクラムマスターはマネージャーではありません。当然スクラムマスターの仕事にはマネジメントスキルが必要な側面はありますが、チームを管理するのではなく支援するサーバントリーダーシップこそスクラムマスターの本質だと思います。チーム自身が自主的にいろいろな判断をしていくために人材を育成したり、ワークフローを整理したり、障害物を取り除くのが仕事です。
スクラムマスターは成果物が見えにくい部分があるので、定量的に評価するのは難しいですね。ただ、スクラムマスターをもっと増やしていきたいし、スクラムマスターとしてキャリア形成できる道をつくっていきたいので、キャリアアップの指標として何かしら持っていなければならないと思います。
僕が考えるには、フロー効率がどれほど改善できたかは指標の1つになると思います。エンジニアとデザイナーの連携がボトルネックになっている場合は、間に入ってコミュニケーションがよりスムーズにできるように整えます。顧客のニーズが開発チームにうまく伝わっていないと感じたら、カスタマーサクセスチームと連携をとってよりうまく言語化します。設計からリリースまで1カ月かかっていたところ、スクラム採用でボトルネックを解消して毎週リリースできるようになったなどは、定量的に測れます。仕事の流れをいかにスムーズにして、チームのパフォーマンスを最大化できるのかがスクラムマスターの腕の見せ所であり、評価軸の1つになるのではないでしょうか。
また、スクラムマスターとしての経験を積んでいくと、より広い範囲の組織に対して影響を及ぼせるようになります。たとえば、最初は5人の1チームしか見られていなかったスクラムマスターがスクラムオブスクラムマスターになり、いつの間にか複数チームの相談先になっていることもあります。評価基準の中で影響範囲を明確にレベル化できれば、評価もしやすいと思います。
公式の力を借りて成果を評価することも考えられます。いまChatworkで実践中のScrum@Scaleは結構柔軟なフレームワークなので、プロジェクトの進捗に合わせて開発組織のリファクタリングをしています。自分が入社してから6カ月の間、毎月体制図が変わるくらい動いています。
そこで、自分がやってきたことが正しいかどうかを確かめるために、2カ月ほど前にScrum Inc.主催の「Scrum@Scaleの公式トレーニング」を受講しました。結果50%ぐらいはちゃんとできたので、やってきたことは間違っていないと答え合わせができたのと、できていない部分は今後改善していく方向性として捉えることができました。
そうですね。スクラムマスターは、コードも書かないので、以前は「生産的な仕事なの?」と思う人もいたはずです。ここ数年で、スクラムを採用する現場が多くなり、スクラムマスターの求人も急激に増えた印象です。裾野が広がり、スクラム開発をより良くしたいと思う人も増えたことで、スクラムマスターが大事だという認識が広まったのでしょう。
前の会社で入ったのがスクラムを始めたばかりのチームだったんです。その前の会社でアジャイル開発をしていたので、気になることをいろいろ提案していたら「スクラムは任せる」と言われ、開発エンジニア兼スクラムマスターのような形で働くことになりました。
やってみたらすごく楽しかったんですよ。かつては炎上プロジェクトも経験したし、エンジニアがもっと楽しく仕事ができたらいいなとずっと考えてきました。だから今、チームのみんなが生き生きとして働いていて、1人では成しえない大きな成果を上げているのを見ると嬉しいですね。
Chatworkに転職したのは、スクラムマスターとしてほかの場所でも通用するのか試したかったのと、スクラムマスターとしてキャリアアップしていける可能性を感じた会社だったから。
僕がやり遂げたいのは、Chatwork全体をスクラム組織にすることです。スクラムを開発チームにだけでなく、営業組織、マーケ組織を含めた企業全体に適応していきたいと思っています。もちろん全部が完璧なスクラム組織である必要はない。実際今スクラムを実践している3チームのうちの1つも割と自由に動いていて、少し形を崩したスクラムになっています。
僕は今はまだ2つのスクラムチームを見ているだけですが、いずれは事業部全体、最終的には会社全体まで良い影響を及ぼせるようになりたいです。
自分が見るチームのエンジニアリングスキルも必要だし、それこそ見積もりの仕方からプロジェクトマネジメントスキル、チーム観察には共感力のような人間的なスキルまで。必要なスキルを一般化するのは難しいですが、興味のあることを幅広く勉強しておくと、何かしら役立つことも多いと思います。
スクラムマスターに必要な技術やスキルは、エンジニアとは少し違う方向性ながら、掘り下げ甲斐があり、奥深い職業です。エンジニアは自分の専門性や技術を追求するのが好きな人が多い気がするので、やってみたら「面白い!」と感じる人はきっと多いんじゃないかと思いますよ。
取材・執筆:古屋美江子
関連記事
人気記事