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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

李　自分の努力を褒めてもらえるとエンジニアのモチベーションにつながります。達成感を得ることで、満足度・幸福度の向上につながっていると感じます。エンジニアのモチベーション維持も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週間の作業量を制約しないため、余った工数を使って、ユーザー目線でより良いアプリになるように工夫する時間に使えるようになりました。

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

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

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

編集：薄井千春（ZINE）