エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

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

スクラム開発を導入するにあたり、必要になる手順は?メンバーはどんな意識を持つべき?実際にスクラムを新たに導入し、チーム力を向上させたRettyの実例を聞きました。

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

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

参考:スクラムガイド™(日本語版PDF)

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

後藤紗也佳さん(ごとう・さやか/@sayaka_goto)(写真右)
アプリ開発チームマネージャー。2015年、化粧品の口コミサービスを運営していた会社からRettyへデザイナーとして中途入社。クリエイティブな視点を活かした企画やチーム開発が得意分野となり、開発チームのマネージャーへジョブチェンジ。オフィスのデザインも担当。
李 泳浴さん(り・えいよく/)(写真左)
北京大学CS専門、2011年mixiに新卒入社。その後、en-japanに移り新規事業開発に従事。2013年からアプリ開発に携わり、2017年Rettyにアプリエンジニアとして入社。現在はエンジニアリングマネージャーとしてアプリ開発チームを率いる。
山本直也さん(やまもと・なおや/@PONTA_zip)(写真中央)
大学卒業後、Sansan株式会社でEightのアプリ開発に従事。2018年2月Rettyへ入社。入社後からアプリ開発チームに加わり、開発者兼スクラムマスターとしてチームを牽引する。Webアプリケーション開発、スマートフォンアプリ開発等幅広く経験を積んでいる。タンパク質をこよなく愛する筋肉エンジニア。

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

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

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

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

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:ガイド通りルールを遵守する

──奇をてらわず、ガイドや『SCRUM BOOT CAMP』を手本に愚直に導入しよう、と考えられたのはなぜでしたか?

山本 ここ数年スクラムを導入した他社の事例を聞きますが、自社の実状に合わせてスクラムイベントをいくつか省く例をよく聞きます。

よく耳にするのが、レトロスペクティブ(振り返り)を省くケース。チームの中で課題があっても、振り返らないと解決する機会がなくなってしまいます。スクラムの価値を最大限発揮できないのでは、もったいないと思うことがあります。 しかし、スクラムイベントは削りに削ったシンプルなものしか残っていません。私が思うに、スクラムはチーム開発の洗練された手法です。それぞれのイベントに意図があり、全部そろって1セットだと考えたのです。

そのため、導入時もガイドと参考図書に書かれたルールを守ることから始めようと考えました。

後藤 プロダクトオーナーからすると、イベントを省略したい思いはありました。正直、1週間のうち3時間をイベントに費やすほどの効果があるのか疑問でしたが、現状の課題を解決したい一心で導入を決意しました。

山本 後藤のように考えたメンバーも他にいたかもしれません。しかし先ほど挙げたレトロスペクティブの例のように、イベントをこなさなけば本来スクラムで得られるはずのメリットが享受できなくます。

イベントの必要性を一つ一つチームメンバーに理解してもらい、すべてのイベントを実施するようファシリテートすることも、当時の私の役目でした。メンバーにははじめにスクラムの意義・目的を話したうえで、イベントの方法ではなく「なぜそのイベントをやるか」を重点的に伝えています。

スクラム導入手順3:開発メンバーの満足度・幸福度を大事にする仕組み作り

──ガイドに従うとはいえ、チーム独自の事情もあったのではないでしょうか。

 スクラムガイドには大筋の記載はあるものの、細かいことは書かれていません。そのためガイドに従っている中でも試行錯誤しています。現在では、タスクや環境などチームの状況が変わるなかで起こる問題の解決策をチームの全員が提案しあい、プロダクトオーナーが決定するいう感じでスプリントを回しています。

例えばスプリントレビューの時間配分。

スプリントレビューとは、ざっくり言うと成果物をチーム全員で確認しあう場です。しかし、小さな機能の開発が中心になったスプリントでは、スプリントレビューの時間が短くなっていました。このようなスプリントが続くと、開発メンバーの熱量が下がり、チームの幸福感・満足感が段々下がっていることに気がついたんです。なぜなら、定量的に結果が測りにくい施策は、スプリントレビューがアウトプットに対してのフィードバックを得られる唯一の場所だったからです。

そこでプロダクトオーナーに課題を伝え、スプリントレビューの内容改善を提案しました。時間を必ず30分確保し、残りの時間は自分のこだわりポイントを話したり、他メンバーが質問をします。積極的に成果を評価し・ナレッジを共有する場にしました。

ポジティブなレビューの例

・コードの量を減らしたリファクタリング

・同じ画面に見えるけれども実は早くなった

・見た目には気づきにくいレベルでも、実は工夫してUX体験を上げた

後藤 プロダクトオーナーの私としては、フィードバックまで聞くことで「そういうところにこだわってくれたんだ」と認識でき、感謝を伝えやすい場にもなっています。

 自分の努力を褒めてもらえるとエンジニアのモチベーションにつながります。達成感を得ることで、満足度・幸福度の向上につながっていると感じます。エンジニアのモチベーション維持もEM(Engineering Manager)として大切にしたいです。

スクラムに活用しているツール

──スプリントレビュー以外に、自分たちに合わせたことはありますか?

山本 使うツールでしょうか。スクラム導入前の課題から、チーム状況とタスクの可視化のしやすさにこだわって選びました。現在は2つのツールを使っています。

KPT管理:GitHub_projects

GitHubで1週間単位のKPT内容を管理。

山本 レトロスペクティブは週の終わりに行い、GitHubでKPT(Keep/Problem/Try)を行います。前週のTryの進捗確認をした上で、チーム全員で1週間のKeepとProblemを記載し、共に振り返り・感想を述べTryを決めます。

タスク管理:ZenHub

山本 日々のタスク管理はZenHubを使っています。

かんばん管理におけるレーンはチームの開発プロセスによって最適化され、基本的にはオリジナルで設計される。QA工程が存在するので専用のレーンを用意。

山本 チーム内で一つのボードを共有し、タスクが終わったら担当者がレビューに移動したり、クローズしたりして各々で自分が担当するタスクを管理しています。デイリースクラムの場で各タスクの状況を共有します。

ZenHubの良いところは、タスク消費の予測と実行をグラフでチェックでき、チームの健康状態を確認できるところです。

1つのスプリントで消化するイテレーションの目標が決まったところで、1日あたりにこなさなければならないポイントの予定が決まります。それと実績を比べるグラフが自動で表示されるんです。この予実管理がとても便利で毎日確認して優先順位の見直し、タスクの入れ替えをしています。

ZenHubの健康状態のグラフ。

ノウハウを全社展開。他チームとの「交換留学」を検討中

──スクラムを導入してから、課題は解決されましたか?

後藤 課題としていたことは解決されました。

リファイメントで要件を詳細化し、スプリントプランニングで全員でタスクを細分化・見積もり。全員でこのプロセスを行う事で抜け漏れを防げて見積もりの精度も高まります。

 従来のウォーターフォール式でもチーム内の関係が悪かったわけではありません。でも、今の方が楽しいですね!周囲からもチームの雰囲気が明るいと言われることが増えました。

スクラムは開発パフォーマンスを改善する手法ですが、チーム内のコミュニケーションを活発化して楽しい雰囲気で開発を進めるための手法でもあります。

もちろん、定量成果も出せるようになりました。PDCAサイクルを回せるようになり、新しい機能開発をどんどん試せるようになったおかげで、チームの数値目標に対しては107%の高達成、iPhoneアプリのUUがV字回復するなど成果を出しています。

山本 私たちのチームの成功事例に、他のチームも関心を持っています。そこで、他のチームへの横展開に「スクラムマスターの交換留学」を考えています。

導入したいチームからスクラムマスター候補をスクラム導入済みチームに留学してもらい、1週間スクラム開発を体験します。その後、該当のチームへ1週間、スクラム導入済みチームのスクラムマスターとプロダクトオーナーがフォローします。

スクラム経験チームからナレッジを共有し、スムーズな移行を促進させていく事が狙いです。

スクラム導入で自己組織化チームに成長

——課題解決のほかに、導入後の変化があれば教えてください。

山本 若手が積極的に挑戦できる環境にもなりました。

例えばファシリテーション。導入してからしばらくはスクラムマスターの私がファシリテーターだったのですが、他の人にイベントのファシリテーションをお願いしたところ、問題なく回せました。それからは、若手を中心にファシリテーションを回しています。今年入社の新卒の二十歳のメンバーがファシリテーターになることもあります。

タスクの割り振り方も変わりました。ウォーターフォール時代は、タスクの割り振りは管理側が決めていました。ところが、スクラムだとカンバンのイテレーションに並ぶタスクに対し「自分がこれをやりたい」とメンバーがプル型で引き受けます。

タスクを与えられるのではなく、メンバー自身が手を挙げて担当するという風土があるとチャレンジの意欲が出て、周囲の助けを得ながら達成できるのがスクラムのよいところかなと思っています。

 私たちベテランもプラスアルファの仕事に手が出るようになりました。

スクラムでは1人あたりの1週間の作業量を制約しないため、余った工数を使って、ユーザー目線でより良いアプリになるように工夫する時間に使えるようになりました。

後藤 私は今までスケジュール調整に使っていた時間を、プロダクトの中長期戦略考案などにあてられるようになりました。良いサイクルに入り、目標の大幅達成やプロダクトの成長にも繋がったと実感しています。

スクラムは手法です。取り入れれば必ずよくなるわけではないですし、向かない環境もあると思います。

今回はチーム・開発環境とマッチし、メンバーがチームをより改善したいと思って、全員で取り入れた事が成功要因だったと思います。

Retty流スクラム導入の3つのポイント

プログラムは『スクラムガイド』を遵守した

チーム全員がスクラム(各イベントの意図)を理解し、認識をすり合わせる

『スクラムガイド』に書かれていない、詳細なルールは自分たちに合うよう考え、自分たちで作る

関連記事

編集:薄井千春(ZINE)