RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

アジャイル開発のプラクティスを取り入れてチームを成長させよう

id:radiocat です。スクラムマスターをやっています。 先月、社内のTechイベントの全社MeetUpで発表してきました。今回はその内容についてあとがき的にまとめてみました。

f:id:radiocat:20180409202902p:plain

終わらないスクラム

私達のチームでは、以前このブログでも紹介されているスクラムトレーニングを受講してスクラム開発を実践しはじめました。

tech-blog.rakus.co.jp

その経験を踏まえて得た知見や気づきを元に発表したのがこのスライドです。

speakerdeck.com

事前にトレーニングを積んでいたものの、実際にスクラムを実践してみるとうまくいかない事がたくさん出てきてスクラムイベントが思った通りに終わらない事態に陥りました。そんな状況を改善するためにスクラムコーチの吉羽さんにアドバイスを頂いたり、スクラムガイドや様々な書籍・資料を参考にして、スクラムイベントをきちんと終わらせるように取り組んだのが次のような内容です。

タスクの細分化

スクラムガイドには 作業の単位は1日以下 と書かれています。タスクの粒度が大きいと着手中の状態が長くなり、どの程度進んでいるのか、どれくらいで終わるのかの見通しがわかりづらくなります。そもそも見積もった時点で1日以上かかるということは細かい作業内容が充分イメージできていない事が多いため予定通り進まないことも多くなります。私達のチームでは見積もりが大きい場合は半日以下になるまでタスクを分解するルールにしました。

リファインメントの徹底

開発チームとプロダクトオーナーがしっかり会話してプロダクトバックログの内容を相互に理解しておかないと、何をどうやって実現するかが明確にならず半日以下のタスクに分解することも難しくなります。スクラムガイドにもリファインメントは プロダクトオーナーと開発チームが協力して行う継続的なプロセス であると定義されています。私達のチームでは リファインメント会議を毎週1回定期開催 するルールにしました。

デイリースクラムの改善

私達のチームではスクラムで開発を始める前から朝会で全員の進捗を確認していましたが、改めてスクラムで定義されているデイリースクラムの目的は何かを考えて朝会のあり方を見直しました。スクラムガイドには 自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握 するためのイベントと定義されています。そのためチームのリーダーが進行して進捗を確認するスタイルから開発チームが交代制で進行するルールに変更しました。

カンバンを検査の拠り所に

カンバンもスクラムで開発を始める前から導入していましたが、チームで意見を出し合って少しずつマイナーチェンジを繰り返しています。デイリースクラムを毎朝カンバンの前で行うため、カンバンもデイリースクラムの目的に沿っていることが重要です。チームの状態を検査し今後の状態が予測できる場にするためにより良い使い方を模索してきました。現在、私達のチームが実践しているスタイルは左からToDo、実行中、レビュー中、完了の順にレーンをわけて、優先度の高いタスクを上から順に並べています。右上にいくほどチームとして最も優先度の高いタスクであり、全員で協力して早く終わらせるようにしています。

むきなおりでチームの方向性を再確認

はじめからチームの進むべき方向性がきっちり定まっていて全員の認識が一致しているようなチームは稀です。私達のチームもはじめは手探り状態でどこかで不安を抱えながらスプリントを進めていたため、3回目のスプリントが終わった時に改めてチームの進むべき方向性を議論して目指すべき設計の方針や品質目標を再確認しました。

インペディメントの除去

スクラムガイドにはスクラムマスターはサーバントリーダーであり 、 メンバーが成果を上げるために支援や奉仕をするリーダー であると書かれています。スクラムにかぎらずソフトウェア開発において開発チームには様々な妨害要素が待ち受けています。近年のソフトウェア開発では、今まで使ったことのない新しい技術や外部のサービスを使うことも当たり前となっています。スクラムマスターはそのような要素を妨害リストとして洗い出し、それらを少しだけ先回りしたり、問題が小さいうちに手を打つことでチームが成果を上げられるように支援に徹しました。

2つの気づき

これらの取り組みを実践することで得た気づきは大きく2つです。

アジャイル開発のプラクティスは従来型の開発でも役に立つ

スクラム開発で取り組んだことは従来型の開発にも活かせることが多いと気づきました。実際にこのような手法は、従来型の開発プロセスの中にアジャイル開発のプラクティスを取り入れるということでハイブリッドアジャイルと呼ばれて実践されているようです。つい最近、日経SYSTEMSの最新号でもハイブリッドアジャイルをテーマにした連載が始まっています。

tech.nikkeibp.co.jp

改善の機会はスクラム開発のほうが豊富

スクラム開発では決まったタイムボックスでイテレーティブに開発を進めることによってアジャイル開発のプラクティスを取り入れるための検査・適応の機会がたくさん訪れます。アジャイル開発のプラクティスを実践して改善する機会はスクラムのほうが豊富にあると感じました。

終わらない学びと実践

スクラム開発でもそれ以外の開発プロセスでも、アジャイル開発のプラクティスは活用できます。そして、スクラムで開発する機会が訪れた時にはアジャイル開発のプラクティスを活用する機会は増加します。つまり、いずれにしてもアジャイル開発のプラクティスを取り入れて学びと実践を繰り返していくことがチームが成長していくための道筋の1つだとスクラム開発を通して学びました。スライドではそのようなアジャイル開発のプラクティスを取り入れるための情報源を幾つか紹介しています。

スクラムガイドによるとスクラム開発は 理解は容易習得は困難 とあります。私達もまだまだ終わりは見えていませんが、習得に向けて学びと実践を繰り返すことでチームがさらに成長できると思っています。

f:id:radiocat:20180409203832p:plain

Copyright © RAKUS Co., Ltd. All rights reserved.