実例に学ぶスクラム導入手順 - タスク属人化を避け、チーム開発力向上のためにRettyがやったこと

ウォーターフォールモデルから、アジャイルへの切り替えを試みる開発チームが多いなか、スクラムを導入したもののうまく浸透しなかったという声も少なくありません。公式の『スクラムガイド』のとっつきにくさが導入のハードルを上げているとの声も聞きます。

Rettyのスマホアプリ開発チームは、あえて現在の自チームに合わせたカスタマイズを一切せず、『スクラムガイド2017』に沿ってスクラムを導入。メンバーのモチベーション向上や開発メンバーの視座を高めるなど、わずか半年で効果を出しました。

参考：スクラムガイド™（日本語版PDF）

いかにハードルを乗り越え、チームの生産性向上とメンバーの満足度向上につなげたのでしょうか。スクラムの導入を提案し、実際に導入したチームのマネージャー、スクラムマスター、開発者メンバーの3名に話を聞きました。

• スクラム導入前夜～タスクの属人化に課題あり
  • 1人のプランナーが5人のエンジニアのタスクをすべて管理
  • 工数見積りの精度の課題が与える、「スケジュール」と「リリース後」への影響
• スクラムマスター経験者が入社。アジャイル開発の導入を決める
• スクラム導入手順1：『SCRUM BOOT CAMP THE BOOK』をチームで読み説く
• スクラム導入手順2：ガイド通りルールを遵守する
• スクラム導入手順3：開発メンバーの満足度・幸福度を大事にする仕組み作り
• スクラムに活用しているツール
  • KPT管理：GitHub_projects
  • タスク管理：ZenHub
• ノウハウを全社展開。他チームとの「交換留学」を検討中
• スクラム導入で自己組織化チームに成長

スクラム導入前夜～タスクの属人化に課題あり

──スクラムを導入してとても幸せになったと聞きましたが、実際のところいかがですか？

李　どんな仕事でもコミュニケーションから逃れることはできないものですが、スクラム以前・以降でコミュニケーションストレスが少なくなりました。仕事へのモチベーションを高く維持できています。私だけでなくチーム全体の変化です。チームに活気があり、仕事が楽しいんです。

加えて、進捗が滞っていることが少ないため、プラスアルファの開発タスクをエンジニア自身が見つけ解決するようになりました。万一、スケジュールに影響が出ても、チームの誰かがフォローしてくれる安心感があります。

1人のプランナーが5人のエンジニアのタスクをすべて管理

──さて、以前はウォーターフォールで開発されていたと聞きましたが、当時はどんな問題が起こっていたのですか？

後藤　山本が入社する前から「かんばん」などは取り入れていたものの、マネージャーが主導のチームで、今思うとウォーターフォール開発でした。

開発の全体感を把握し、タスクの優先順位をつけるのは8人のチームメンバーのなかでプランナーの私だけ。毎朝、タスクの分解の時間を設けて私とエンジニアの1対1で話し合いを行い、5名のエンジニアのタスク管理と指示出しを一手に引き受けていました。

誰かに想定外の問題が発生したとき、余裕があるメンバーを探してフォローを仲介するのもディレクションを担当していた私の役割でした。

李　そのためタスクの属人化が進み、誰かが突発的に休みを取るとスケジュールに影響が出るのが確実、という状況でした。

自分自身の休みが取りづらかっただけでなく、誰かが休んだときの負担も大きくなってしまっていました。特に旗振り役の後藤が休んでしまうと、進行中のタスクを終えたあとに何をすべきかが個人で判断できず、開発メンバーの手が止まってしまうこともありました。加えて、メンバー同士で他人のタスクや進捗を把握しておらず、自分から手伝おうと声をかけたり、フォローを依頼することもスムーズにはいきませんでした。今思うと受け身なところが多かったなと思いますね。

工数見積りの精度の課題が与える、「スケジュール」と「リリース後」への影響

──チーム内での業務調整が難しいと、スケジューリングにも影響が出てきますよね。

李　実際、開発工数の見積り精度は低かったように思います。

当時は、エンジニア一人ひとりが曖昧な予測で見積もりを出すこともありました。後藤から「どれくらいかかるか」と聞かれ、仕様を理解できていない状態でも「2日間でできます」と答えてしまう。実際に取りかかると想定より要件が多く、締切直前に延長を申し出ることが多くありました。

見積の精度が低いとコミュニケーションコストも高くなります。

一度決まったスケジュールに対して、メンバーや他のチームとの調整をしていくのは、本来必要のないことですし、あんまり楽しい会話でもありません。

開発がうまく進んでいないと、毎朝の進捗報告も気が重くなります。予定通り進捗を出せない不安と、当日「できていません」と答えなければいけない心理的負担も大きかったですね。

後藤　チーム内外で調整しようもないケースでは、なんとか帳尻合わせをしてリリースまでこぎ着けました。

──リリース後の課題もあったのですか？

後藤　リリース後は改善作業に追われました。要因は、タスク分解に時間をかけていなかったことにあります。タスクがうまく分解できていないので見積もり精度は低く、適切な割り振りがされないまま1人でタスクを抱え込んでしまう、つまり属人化が進んでしまう構造でした。

もし精度の高い見積りができていれば、スケジュール調整の手間は圧倒的に減少しますし、属人化という課題はタスクの可視化によって改善されるでしょう。

当時は「とりあえず実装しよう！」という考えになりがちでしたが、タスク分解と見積もりに時間をかけた方がトータルの時間は短くなったと思います。今思うとみんなに上手く裁量権を渡せずマネージャ主導型チームにしてしまっていたんですね。

スクラムマスター経験者が入社。アジャイル開発の導入を決める

李　この状況を打開するには、スクラムが解決策になりそうだと思っていました。前職ではスクラムの経験があったのです。後藤とも話しましたが、当時は導入に向けた時間的なコストを考慮すると余裕がないと考えました。私自身もスクラムの経験が全くないチームへの導入に向けた踏み込みができませんでした。

リニューアル後の改善対応に追われている中、山本がRettyへ中途入社してきたんです。

山本　私も前職でアジャイル開発の経験があり、スクラムマスターを担当したこともあります。

チームに続いている悪循環を変えるためにはスクラムしかないと考えたんです。後藤にスクラムの導入を提案して、同時にスクラムマスターに立候補しました。スクラム未経験者がスクラムマスターをいきなり担当するのはきついと思い、経験があった自分がやろうと考えたんです。

後藤　山本の提案と立候補を受け、マネージャーとしてスクラムの導入を決めました。2018年3月はチーム内でスクラムについて勉強し、4月からスクラム体制を開始しました。

スクラム導入手順1：『SCRUM BOOT CAMP THE BOOK』をチームで読み説く

──スクラム未経験のメンバーは、どのように理解を深めていったのでしょうか？

山本　まず『SCRUM BOOT CAMP THE BOOK』を参考図書としてチームメンバーで回し読みしました。

スクラムのルールブックでもある『スクラムガイド』にはプログラムは書いてあるものの、そのプログラムに至る背景や、ありがちな問題への対策は書かれていません。

一方『SCRUM BOOT CAMP THE BOOK』は、現場で起こりそうなこととその対策が書かれている上に、漫画で分かりやすく読み進められるのでとっつきやすいと考えたからです。

あわせて、スクラムフローのアクションを全て言語化しチーム全員ですり合わせを行いました。このフローは課題があれば常に改善して更新しています。

スクラムフローを改善するたびにドキュメントも更新する。

スクラムフローの具体的なアクションを言語化し、チームメンバーと認識を合わせる。

──『SCRUM BOOT CAMP THE BOOK』は具体的にどの場面が参考になりましたか？

後藤　私はプロダクトオーナーの立場でしたので、スクラムイベントに参加できない場面を自分に重ねて読みました。忙しいからといってレビューに出ないわけにはいかないよねと。

漫画ではレビューを複数回に分けることで、プロダクトオーナーが参加して解決していました。紹介された事例と同じ状況に遭遇すると、まずは本の通りにやってみようと思えます。自分の中で問題解決へのハードルが下がりました。

スクラム導入手順2：ガイド通りルールを遵守する