アジャイル開発を導入して1年以上経ちました

みんなのウェディング、松久(@kamonegi1977)です。

みんなのウェディングでは、アジャイル開発を導入して1年以上が経ちました。現在、どんな組織・チームでサービス開発をすすめているのかを説明します。

なぜ?アジャイル開発を導入したのか

アジャイル開発を導入する前は、以下のような流れで開発が行われていました。

  1. マーケティングから企画がまとめられて、開発依頼が出される
  2. 開発担当がアサインされ、デザイナー、エンジニアが決まる
  3. Excel などで仕様書(画面構成)があり、リリース日が決まっている
  4. リリースすると開発終了。次の開発へ(1に戻る)

この流れは、エンジニアが1つの開発に集中できるメリットがあります。
一方でリリース日が重視されるため、機能や品質が犠牲となることがありました。リリースを終えると次の開発に入ることが多く、リリースした新機能や変更を改善することが難しい状態でした。チーム開発ではなかったので「あの人しか知らない」事が増えていく状態でした。

アジャイル開発の始まり

システムを、Ruby on Rails へ移行を決めた時に、アジャイル開発を行うことにしました。アジャイル開発を始めるにあたり、角谷さん(@kakutani)の指導をうけて進めていきました。

最初は、既存システムを Ruby on Rails へ移行をするチームだけでアジャイル開発を導入しました。システムの移行が進むにつれて、サービス開発を担当する部署と話し、エンジニリングを担当する部署全体でアジャイル開発を試してみてから、サービス開発を行う部署全体へ広げていきました。

現在の組織構成

部署は、ユーザー行動をふまえたビジネス目標をもちます。各部署は、職能を横断したチームが1つ以上あります。チームは、ディレクター、デザイナー、エンジニアで構成されています。デザイナーはUXデザイン部に属していますが、日々の業務は特定の部署の業務を行います。デザイナー、エンジニアの中には複数のチームに属している人もいます。

1週間(スプリント)の計画をたてる

毎週月曜日に1週間(スプリント)の計画をたてます。
意識していることは「1週間の終わりに、どんな状態になっているのか?(世の中をどう変えたか?)」です。

  1. 実現したい成果を実現するためのタスクを書き出す
  2. タスクに重みを書く
  3. 1週間後の状態を考えて1週間でできることをチームで約束する

月曜日に計画を立てているのは、1週間の「始まり感」を出してリズムを作りやすくするためです。

タスクを書き出す

タスクの完了状態を考えて書き出します。
エンジニアであれば、プルリクエストがマージできるとタスクが完了したといえます。デザイナーであれば、「デザインレビューに出す」「プロトタイプを作る」などでしょうか。
チーム内でタスクの「完了の定義」の意識合わせをしておくことを大切にしています。

タスクのサイズを決める

タスクには「サイズ」と呼んでいる完了までに必要な時間の予測を書いています。サイズは、XS、S、M、Lとしています。数字をそのまま書くと作業完了までの時間のように見えるので数字は使っていません。

サイズの目安は

  • XS:2 〜 3 時間(すぐできそう)
  • S:1日
  • M:2日ぐらい
  • L:Mよりも大きい

ぐらいに考えています。L が出てくると、M や Sに分解できないか?考えます。大きな1つのタスクを分解することで、コードレビューや、リリースをしやすくします。

デザイナー、エンジニアが複数人いるときに、サイズは全員で決めるべきです。しかし、ついつい経験者がサイズを言って決めてしまうことが多いです。何が要因でサイズを決めたのか話し合えると、経験が少ない人がタスクの内容を知ることが出来ますし、説明することで経験者も仕様を整理することができます。

1週間の終わりを意識する

「1週間の終わりに、どんな状態になっているのか?」を考えて、タスクの優先順位と選択をしていきます。上から下へ優先順位で並べ「1週間の終わりに、どんな状態になっているのか?」をチームで約束します。

朝会をカンバンの前で行う

朝会は、始業すぐにカンバンの前で行います。電車の遅延などで遅くなる人が多いようであれば、少し遅らせて始めることもあります。朝会の目的は、チームの情報同期なので、聞いていない人が多いのでは目的が達成できないからです。

仕事の状況管理は「カンバン」を使っています。カンバンには、チームの情報が集まります。チームの状態や、どんなサービスを作ろうとしているのかが可視化され、チームメンバー間での情報同期を行うツールになっています。

朝会をすれば情報が同期されるわけではありません。
私は以下のことについて注意しています。

  • 自分からタスクの進捗を伝える
  • 1週間後の約束が守れそうか推測する。チームメンバーに聞いてみる
    • 進みが悪いようであれば、阻害している要因は何か?要因を除外できないか?など少しでも進められるようにする
  • 仕様や実装でわからない事があれば話してみる
    • すぐに解決できない時は、別な時間をとって相談する
  • 調子がわるそう、元気がなそうな人などがいないか見てみる
    • 声に出せないけれど、悩んでたり納得していないことがあるのでは?と思って話しかけてみる

スプリントをふりかえる

1週間で行ったことの「ふりかえり」を行います。以前は、全チームが同じ時刻からふりかりを行い、ふりかえりの内容を共有していました。今は、チームごとにメンバー数が大きく異なるため、終了時間を合わせる必要がでてきたので、各チームでスケジュールを決めて実施しています。ふりかえりの内容は、スプリントレビューで共有することにしました。

「ふりかえり」は「よかったこと」「もやもやしたこと」を付箋に書き出すことにしました。

「ふりかえり」の目的は、

  • 初めての人の組み合わせのチームもあるので、チーム初期(1ヶ月〜3ヶ月)は特に、チームビルディングのきっかけ
    • 「よかったこと」を先に話すと盛り上がる
    • 「よかったこと」を後で話すと「ふりかえり」が気持ちよく終われる
  • チームでのやり方の改善を促す
  • チームでのやり方が改善できているか?を確認する

チーム視点でも、個人視点でも、今まで出来なかったことが出来るようになったことや、きになっていること、もやもやしたことを書き出して、チームのやり方の改善をしています。チームによっては、「KPT(ケプト: Keep・Problem・Try)」を実施しているところもあります。

チームメンバーの入れ替えがあったり、サービスの課題に合わせたチームが作られたりすることがあるので、「ふりかえり」のやり方をチームで工夫しています。

ふりかえりは、週後半に行うことが多いようです。これは、スプリントで起きた「よかったこと」「もやもやしたこと」をふりかえる機会としても捉えているためです。

全チームが集まってスプリントレビューを行う

スプリントレビューは、全チームのディレクター、エンジニア、デザイナーが参加して行います。さらにインフラ担当や開発基盤をつくる部署も参加しています。最近では、部長、担当役員も参加することが増えてきました。

スプリントレビューでは

  • チームが何をしているのか集まっている人に伝える(自慢する)
  • 今後のチームの見通しを伝える
  • 隣のチームは何をしているのか?を知る

スプリントレビュー実施前に、上記の内容をドキュメント( esaを利用しています) にしておきます。

チームがやっていることをチームメンバー以外に説明する時は下記のことが必要になってきます。

  • チームが何をしているのか把握する必要がある
  • どうやったらチームがやっていることを伝えられるか考える必要がある
    • 動いている画面を見せる
    • 変化した数値を見せる

スプリント計画で約束した「1週間の終わりに、どんな状態になっているのか?」を、朝会などで同期していないと伝えることが大変です。

スプリントレビューを継続してみて、他のチームが何をしているのか?知っていることが増えました。また、気になることがあれば質問できる機会が毎週ある状態(聞くチャンスが勝手にやってくる状態)になりました。

アジャイル開発を導入して起きた変化

みんなのウェディングのサービス開発の1週間の流れを説明しました。
1週間(1スプリント)の間に、スプリントの計画、朝会、ふりかえり、スプリントレビューを行なっています。

アジャイル開発を導入して、以下の変化が起きました。

  • チームで「1週間単位で何を達成するか」を意識して開発を出来るようになった
  • 他のチームが何をしているのかを知ることが増えた
  • 繰り返し開発していくので、サービスの改善も行われるようになった

今後も開発の流れは変化します。理由は、サービスを開発するチームにとって今のやり方に価値がなければ、やり方を変更するか、辞めることが必要です。実際、チームメンバー数が少ないチームでは、朝会をしていないところもあります。カンバンもチームによって様々です。

どうやったら、もっとうまくやれる?ユーザーに価値を届けられている?という問いを持ってサービス開発の流れを改善していきたいと考えています。


みんなのウェディングでは、一緒に毎週サービスを改善していきたいデザイナー、エンジニアを募集中です。こんなこと本当にやれているのか見てみたい、と思ったら @kamonegi1977 に直接連絡いただくか、Wantedly からご連絡ください!

参考書籍