チーム開発の進め方

こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。

今回はウチのチームの開発の進め方や見積もりの仕方を説明しようと思います。

実はコレ系の話は 5 年前にもデブサミで発表 したのですがこの時はリリースまで 1 年とかのレベルのプロジェクトの進め方の話でした。今回は 1,2 ヶ月でリリースまで持っていく開発の進め方を説明します。

動画サービス部分を microservices 化するときに実際に行った事を元に説明します。開発者は 3 人で 1.5 ヶ月位の開発です。

何故このようなことを行うのか

誰だって楽しく仕事がしたいし、なるべく不安などは無い方が良いはずです。 例えば自分がやっている作業がどうなったら終わりなのかわかっていなければ不安でしょうし、いつまでに作ればいいのかわかっていなければ不安でしょう。

そういった不安をなるべく無くすためにうちのチームでは 見える化 と コミュニケーション を重視し、メンバー全員で楽しく開発することを目標にしています。

まずは作らなきゃいけないものの洗い出し

いわゆるタスク出しってやつですね。正直この作業はあんまり面白いものではないです。特に開発初期などはエンジニアはまっさらな状態からコードをドンドン書いていけて凄く楽しいのでいきなり手を付けたくなります。ですがチーム開発でそれをやってしまうと比較的早く破綻しますし、その時にはメンバーそれぞれのモチベーションにも差が出てきたりして軌道修正をするのが難しくなります。なのでメンバーの意識も高い初期になるべく楽しく行うのが大事だと思います。

まずは全員で時間を作りやらなきゃいけないタスクの洗い出しをします。 1,2 ヶ月で完成させるようなものはアジャイル開発でよく使われているユーザーストーリーで分けると粒度が少し大きくなってしまうため機能単位でタスク出しをしています。

どの程度の粒度で出すかというと

• DB 設計
• Video テーブル移行スクリプト
• Video 取得内部 API

のような感じで出しています。 実際に全員で「もう出すもの無いよね」というところまで出し切ったらそれを一個づつ付箋に書いていきます。

出したタスクの重さを決める

次に出したタスクの重さを決めていきます。ユーザーストーリーで分けているときはストーリーポイントとか言われているものですね。コレはなるべく抽象化したポイントであらわし、かかる時間などの具体的な数値で出さないことが大事です。以下説明のためにこの数値を SP (ストーリーポイント) と書きます。

実際の数値の出し方ですがプランニングポーカーと呼ばれている手法を使って行います。簡単にうちのチームで行っているプランニングポーカーの説明をします。

1. 「1,2,3,5,8,13,∞,?」 どこかで見た数列 + 無限と ? のカードを人数分用意します。
2. すべてのタスクの中からちょうど真ん中くらいの難易度だろうと思うのもをみんなで選びその SP を 5 にします。
3. まだ SP を決めていないタスクを選びます。
4. 簡単にそのタスクの機能の説明をします。
5. それぞれがカードの中から SP を選び同時に出します。
   • 最初に出したタスクが 5 だというのを参考に考えます。
   • 専門分野など情報が不足しすぎていて自分には見積もりできない時は ? を出します
     • これはその後説明を求めます。
   • タスクが大きすぎて 13 を大幅に超えると思ったら ∞ カードを出します
     • タスクをさらに分割します
6. 数値が合わなかったら一番大きい数字と小さい数字を出した人間がそれぞれの根拠を説明します。
7. 6 で出た意見を参考にもう一度全員で SP を出します。
8. 全員の数字が揃うまで 6,7 を繰り返します。
9. すべてのタスクに SP が振られるまで 3 〜 8 を繰り返します。

これですべてのタスクに SP が振り分けられます。 プランニングポーカーは面倒臭い見積もりをゲーム感覚で楽しく行えるのでオススメです。

イテレーション期間

次にイテレーション期間を決めますが、もうコレは色々経験してきた結果

水曜日始まりの 1 週間を 1 イテレーションとする

が一番しっくり来るので僕の独断でそうしています。簡単に理由を説明すると

• 1 週間より短いと細かすぎて朝会などと区別があやふやになる
• 1,2ヶ月の開発に 2 週間だと 2 〜 4 イテレーションしか回せずうまくリズムにならない
• 月曜日で振り返りを行うと先週の問題点があんまり気にならなくなってる
• 金曜日に振り返りを行うと月曜日には改善しようと思ってたことを忘れる

という理由からそうしています。

スケジュールぎめ

1 週間というタイムボックスが決まったので、それぞれのイテレーション期間でどのタスクを行うかを決めていきます。 最初はだいたいザックリ「今週はこのくらい出来るんじゃね？」という量を割り当てていき、次の週などもそれを元に割り振っていきます。この時に大事なのはタスクの順番を意識することです。例えば最初に例に上げた「DB 設計」を終わらせないと「Video テーブル移行スクリプト」は実装できません。こういった順番を考慮しつつ各イテレーションに作業を割り振って行きます。（後で説明しますがココで上げたスケジュールは大体破綻しますｗ）

実際に開発を回していく

スケジュールも決まったので実際に開発にかかります。うちのチームでは基本的に個々の作業管理はツールとしてのかんばん で行っていますが少しアレンジしています。

1. タスク自体はイテレーションを表した大きめの紙に貼られている
2. 自分が実際に作業しているものには自分の名前の書かれたマグネットを置く
3. 終わったものには猫のシールを貼る
4. 予定になかったタスクが発生したら赤い付箋に書き、そこにも SP をふる
   • 突然降ってきた仕事
   • 仕様考慮漏れ
   • バグ修正

タスクが終わったものはシールを貼って表していますがコレはその作業が完全に完了するまで行わないことを徹底しています。（アジャイルで「完全 Done 」と呼ばれているものですね）

振り返りを行う

水曜日には振り返りを行います。まず計画で上げたタスクで完全に完了したものの SP をすべて合計して算出します。 コレがチームの 1 週間で行える作業量という指針になります。ついつい「この 8SP の作業、あとちょっとで終わるから」と言って合計数に含めたくなりますがやめましょう。

さて、だいたい最初のイテレーションが終わるとすでに最初の計画が破綻していると思います。 今回うちのチームも 1 イテレーションで 30SP 位の作業は出来るだろうと見込んでいたのですが、 20SP しか完了出来ませんでした。つまり 10SP の作業はあぶれ、今後のイテレーションに割り振られている 30SP をすべて 20SP に修正すると一気に 1.5 倍ほどのスケジュールになってしまいます。

ここで大事なのが振り返りです。

まずは我々は1イテレーションに 20SP しか消化できないという認識をします。 そこで何故 20SP しか消化出来なかったのかなどを話し合います。今回は 3 人なので KPT のような比較的きっちりした振り返りではなくスタンディングでお互いの意見を言い合う形で行いました。 最初のイテレーションはデータ移行などのタスクに引きづられ、大きめなタスク( 13SP )が実際にデータを入れてみたら修正する箇所が出てきたりして完全 Done にならなかった事がわかりました。 幸いにもその修正はすぐに終わるだろうという事で今回はスケジュールの見直しはしないで行けそうだということになりました。

ここで厳密に今後のスケジュールを見直すことも可能ですが、いきなりここで厳密にやってもテンションが下がるだけなので行いませんでした。実際、本当に持ち直せなかったら次のイテレーションでスケジュールの切り直しをするつもりでしたが、うまく持ち直したのでそのまま進みました。

イテレーションを回していく

上記のようにイテレーションを回しながら

• 抜けているタスクはないか
• タスクに割り振られている SP は妥当か
• イテレーションに割り振られているタスク量は適切か
• スケジュールを切り直す必要はないか

は話し合っていき、スケジュールをドンドン正確にしていきます。

チームのパフォーマンスチューニング

このようにイテレーションを回していくとベロシティ（チームの平均消化 SP）がわかってきます。あくまで指針としてですがこのような数値を毎週出しておくとチームの健康状態を図れます。ベロシティが落ちていればなにか問題があるのでしょう、逆に上がっていれば何か改善する事があったのでしょう。

振り返りの時に「なんか今週仕事があんまり進まなかった気がするよね！なんでだろ？」と感覚的にいうよりも「何故今回はベロシティ下がったんだろう？」というほうが数字にも出てるのでチームメンバーも共感でき、一緒に改善案を考えれます。

パフォーマンスチューニングの基本「推測するな、計測せよ」です。

まとめ

チーム開発の進め方として主にタスク出しやスケジュールの切り方を説明してみました。僕はもともと「スケジュール立てるのとか苦手だし、誰か得意な人がやればいいんじゃね？」とか思っていましたが今では

タスク出しやスケジュール立てるのは才能ではなく技能なのでやり方覚えれば誰でも出来る

と感じています。実際にやっていることはプログラムを書くときと同じで大きい問題を小さく切り分けて順番に対処していっているだけです。そして計測してそこから逆算しているだけです。

やり方を覚えて身に付ければ誰にでも出来る事なので、まだ習得していない人や昔の僕の考えと同じようなことを考えている人は早めに習得しちゃうことをオススメします。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~