SO Technologies株式会社
話を伺っているとスクラム開発は、メンバー同士がコミュニケーションを積極的に取っていけるチームビルディングを土台に、その力をもってして開発のスピードをあげていく手法なのかなと感じています。 そうですね。コミュニケーションを頻繁にするフレームワークなので。 -- どんな開発チームや会社とも相性がよさそうな手法のような気がします。 ...
https://recruit.so-tech.co.jp/talk/talk_07.html
近年、生産性を向上させる開発手法として注目されている「スクラム開発」というワードを耳にする機会が増えたエンジニアの方もいらっしゃるのではないでしょうか。
しかしそもそもこの開発手法が何なのか、どうやって導入していいか分からないという方も多いと思います。
そこで今回は、Google マイビジネスの登録代行や保守、運用サービスを提供している『ライクル GMB』チームのスクラムマスター府川翔大さんに、「スクラム開発とは何か」「どんな開発・チーム体制を整えているのか」「スクラムマスターとしてどんなことを意識しているのか」について伺いました。
『ライクル GMB』チーム スクラムマスター 府川 翔大
固定の短期間(スプリント)で、プロダクトの中でも優先度の高いものをこまめにリリースするための手法です。メンバー同士が協力しあって作るため、必然的にコミュニケーションが多くなるフレームワークになっています。
スプリントでの開発イメージ
開発のゴールの予測と大きな乖離が出ないところだと思います。
長期間で開発を進めていく手法の場合、完成形がなかなか見えなかったり、予測していたものとズレたものができて修正せざるを得なくなったりすることが起こりがちです。短期間で振り返りと改善をするスクラム開発なら、プランニングで最優先に取り組むことが明確化されるため、携わるメンバーがゴールを思い描きやすいと思います。
また、過去の実績を記録して活かせる点もスクラム開発の強みではないでしょうか。
例えばあるサービスの1画面を、エンジニア3人で約1カ月で作ったという実績があったとします。スクラム開発の場合、これと似た新サービスを作るとなった時に、開発の単位が細かいので見積もりも出しやすいんです。
10人のメンバーと一緒に1週間のスプリントで、開発チームが成果物をプロダクトオーナーに説明(レビュー)し、KPT方式で振り返り、翌週で改善することをプランニングで詰めていく流れで開発を進めています。
府川さんがスクラムマスターを担うサービス『ライクル GMB』のWEBサイト
むしろ効率は上がっていると思います。メンバーからも「生産性が上がった」という声もあがっていますよ。
何が最優先事項なのかをきちんと考えて、無駄なタスクが発生しにくい状況を作っていることが挙げられると思います。
また、メンバー全員が目的の共通認識を持てているため、いざという時に誰でも助けに入れる状態になっていることも、影響しているのではないでしょうか。
確かに、プランニングのゴールがぼんやりしてしまう時はあります。ただその時は正直に「まだゴールがはっきりしていない」とメンバーに伝えるようにしていて。
そんな時ライクルGMBのメンバーは、一緒に翌週の最優先事項を考えてくれるんです。改善点も毎週どんなに絞っても5個くらいは出てきますし。
作っているものをより良くするためにはどうすればいいかを考えてくれる積極的なメンバーばかりなので、本当に心強いです。
むしろフルリモートになって、出社にかかる物理的移動の時間や会議室の予約が必要なくなった分、定例のミーティングはもちろん、問題にぶつかった時の小さなミーティングを実施しやすくなりました。
会議でよくある「時間が足りないから、結論は次回に持ち越し」なんてこともありません。テキストコミュニケーションも活発で、分報に「ここがうまくいかない・わからない」とつぶやくと、アドバイスがすぐに飛んできます。
メンバーの中には入社してから実際に顔を合わせたことのない人もいますが、悩んだ時にすぐミーティングができる環境になったので、メンバー間の目的の共有はしやすくなり、結果改善スピード、生産性もあがっている感覚があります。
週次の振り返りの際の推奨ルールに「プライベートな話でも何でもいいから、良かったことを最低3つは挙げよう」を掲げています。
このルールを設けた理由は、僕が以前問題点にばかり思考が向かってしまう組織に属していて、開発を楽しめない経験をしたからです。
もちろん問題は問題としてきちんと考える必要はあります。ただ楽しく開発を進めてほしかったですし、日頃から良いところを見つける癖をつけてほしかった。なにより感謝し合えるようなチームを作りたかったので、この推奨ルールを設けたんです。
はい。お子さんが生まれたばかりのメンバーがいて、振り返りで「夜泣きがひどくて寝られない」という声が上がったんです。
そのメンバーは早く出社できたら家庭のスケジュールを前倒しできて寝る時間も確保できそうとのことだったので、会社が裁量労働制をとっているのを活用して出社時間を早くする改善をとりました。
また、新型コロナウイルスの影響で外出自粛になったばかりの時は、家に籠りっぱなしだったこともありメンバーから「精神的にしんどい」という声があがりました。
そこで換気できてる場所であることを条件に、終業時間を後ろ倒しして15時~16時は運動する時間にあてるという改善をとったんです。
振り返りとプランニングを1週間という短期のスプリントでしているからこそ、メンバーのプライベートな部分の改善にも、翌週からというスピード感を持って取り組めたと思っています。
あとはメンバーのチャレンジを賞賛する雰囲気も、楽しく開発に打ち込める1つの理由になっていると思います。
もちろんチャレンジの中には失敗もありますが、きちんと考えて取り組んだ上での失敗なら、それを責める人はこのチームにはいません。
そうですね。コミュニケーションを頻繁にするフレームワークなので。
現状の開発手法がマッチしていてうまく進められているのであれば、必ずしも導入すべきだとは思いません。
ただ、チームがまとまっていない、開発スピードがなかなかあがらないといった課題を今抱えているのであれば、試す価値のある手法だと思います。
コミュニケーションの重要度があがるフルリモートワークを取り入れているチームであれば、短期間で改善するスピード感を持ったこの手法は、なおさら向いているのではないでしょうか。
しかし、いきなりやり方を変えるとそこにリソースを割くことにもなるので、まずは今の開発手法とスクラム開発のハイブリットで試してみるといったように、段階的に取り入れていく形もありだと思います。
スクラム開発を取り入れないにしても、週次レベルくらいのこまめな開発の振り返りをするのは大切ではないでしょうか。
コミュニケーション力と行動力ではないでしょうか。
スクラムマスターには、チームメンバーの意見を聞くだけでなく、意見を出してもらえる環境をつくり、さらに作り上げたものを改善するために迅速に動くことが求められます。
そして、「楽しく働きたい」という想いは、常に持っています。
これがスクラムマスターに必要かと言われたら、たぶん本には載っていないと思います。ですがスクラムマスターの資格を持っている僕の師匠も、メンバーが楽しく開発できたらいいよねと言っていたので、この想いは大切にしたいですね。
スクラムマスターのミッションは、開発メンバーの生産性をあげること、エンジニアがエンジニアの仕事に集中できる環境をいかに作れるかだと思っています。
とはいえ、僕自身も最初からできていたわけではありません。
ライクル GMBチームも最初は、僕と若手エンジニアだけで「スクラムって何?」というところから説明するなど、試行錯誤の繰り返しでしたよ。
まずは『スクラムガイド』や『スクラム・ブート・キャンプ ザ・ブック』を読んで、スクラム開発の流れを学びながら、並行して1〜2週間ごとに振り返りをする場を設けるのがいいと思います。
こまめに改善をする習慣を身につけることとコミュニケーションを活発に取れるようになったら、学んだスクラム開発の内容を少しずつ取り入れていけばいいのではないでしょうか。
府川さんおすすめの書籍『スクラム・ブート・キャンプ ザ・ブック』
(転載元:SO Technologiesリクルートサイト)