アジャイルへの道　第一章 チーム開発の苦悩と模索編

チーム開発の苦悩と模索

クレイでは、ずっと開発方法や情報共有をいろいろと模索してきました。
以前ブログで紹介した Basecamp や Backpack の紹介も、その一つです。

小さなチームを加速させる！ Basecampで簡単プロジェクト管理
Backpackでタスク管理から情報共有まで

最近、弊社ではチーム開発というものが、うまく機能するようになってきています。
@irohiroki を筆頭に全員でアジャイル開発を進めてきていることが確実に実になってきていると思います。

少しでも参考になればと思い、今までの苦悩と模索を「アジャイルへの道　第一章」として綴りたいと思います。ちなみに第十三章まではありませんし、第二章以降は @irohiroki に任せたいと思います。

1年前までの開発

基本的に受託での開発が多いため、次のようなフローになっていました。

1年前までの開発フロー

1. 打合せの内容は打合せ報告テンプレートを使って Backpack に記録する
2. 要件テンプレートを使って、Backpack に要件をまとめる
3. プロジェクトマネージャーと開発担当者で要件を確認しながら、BasecampのToDoに落とし込む
4. 朝会で前日のToDoの消化と、その日に担当するToDoを決めていく
5. クライアントと決めたマイルストーンに沿って報告、確認してもらう
6. コードレビューはやったり、やらなかったり

うまくいっていた点

• 打合せ報告テンプレートは2年以上前に作ったものですが、改良しつつ今でも活躍してます。
• 朝会で ToDo を決めていくので、周りの人のタスクの共有と進捗を把握しやすい。

問題点

• 要件ページがテンプレート化されておらず、各自バラバラの書き方をしていたため、抜けが多い。
• ToDo の完了条件が曖昧で各自が閉じるため、完成度にバラツキがあったり、出来ていないことも多い。
• 他の人の設計、実装を把握していないため、設計のまずさに気づいても後の祭り（肝となる設計は必ず数人で行うが、細かい設計は各自で行う）
• 関連する ToDo を一人の開発者が担当することが多いため、その人にしかわからない部分がある。
• ToDo をマイルストーン毎など順次作っていたため、ToDo が消化されると待ちが発生する。

2年近く前のブログで次のように書いていますが、何も改善できていなかったと思います。

小さなチームを加速させる！ Basecampで簡単プロジェクト管理

タスクの共有、進捗は全員で共有できていると思いますが、負荷状況の共有や協力がうまく機能していないと思っています。それはBasecampの問題ではなく、社内のチーム開発の仕組みがうまく機能していないためです。

最近の開発

1年ぐらい前から、簡単な日報を共有したり、要件テンプレートを改良して、要件をまとめやすくなったりしました。その後、本格的にチーム開発できるような体制や仕組みを作り始め、最近うまく機能するようになってきたことを感じています。

今は次のようなフローになっています。

最近の開発フロー

1. 打合せの内容は打合せ報告テンプレートを使って Backpack に記録する
2. 要件テンプレートを使って、Backpack に要件をまとめる
3. かんがえるシートを作成する
4. Pivotal Tracker に要件全てのストーリーをプロダクトオーナーが作成する
5. 開発者は優先順位に沿って、ストーリーを担当していく
6. 毎日、開発チームは朝会をする
7. 一週間に一度、開発チームとプロダクトオーナーで「ふりかえり」をする
8. 開発チームは各マイルストーンまでに完了できるストーリーを決める
9. 肝となるストーリーには review タグを付け、事前に設計を Basecamp に投げ、レビューしあう
10. 実装以外の ToDo や、ファイルの共有、設計の検討などは Basecamp を使う
11. 日報テンプレートを使って、簡単な日報を Backpack にまとめる
12. 月曜朝に日報の共有

うまくいっている点

• かんがえるシートでクライアントと開発チームの認識のズレが少なくなった。
• 要件テンプレートが改良されて、要件の確認に漏れがなくなってきた。
• 要件からストーリーを作成する時に完了条件を詳細に書くことで認識違いが減った。
• プロダクトオーナーが完了かどうか判断するため、実装漏れが減った。
• 朝会で開発チーム内での状況が把握しやすい。
• 「ふりかえり」で、チーム内の Keep, Problem が共有され、Try が行われている。（ふりかえりについては後述）
• レビューが自然と行われ、設計や実装が共有できる。
• 日報で知識と仕事、困っている点の共有ができる。

問題点

• 発注形態が従来と同じで、先に見積もりと納期が決まるため、変化していく要件に合わせて開発を進めても、納期が変わらないため、つらい場合がある。

かんがえるシート

仕組み化されてる部分と、朝会や「ふりかえり」など、チーム開発を円滑に進めるためのコミュニケーション部分が、うまく合わさってきている感じがします。

問題点については、クライアントにそのメリットを理解してもらって、アジャイル開発での契約を結ぶことができるかだと思います。

チーム開発への第一歩「ふりかえり」

弊社がこれまで採り入れてきた中で、一番有効だと感じたのが「ふりかえり」です。
次のように「ふりかえり」を行っています。

1. 巨大ポストイットに線を引いて、タイトル、K P T の文字を書く
2. ペンと普通のポストイットを開発チーム、プロダクトオーナーに渡す
3. 前回の「ふりかえり」があれば、Try（対応策）などを見直す
4. Keep（うまくいった行動や状況）を一つずつポストイットに書き出す
   • 思いつくだけいっぱい書きます。
   • 些細なことでも、よかったことやいい状況など何でも書きます。
5. Problem（問題）を一つずつポストイットに書き出す
   • 問題となっている状態や事象を書き出します。
   • 決して個人を攻撃しません。問題 vs 開発チーム全員という構図にします。
6. Try（対応策）を一つずつポストイットに書き出す
7. 全員で、Try に合意できるか確認する
8. Try を実行に移す

「ふりかえり」の様子

「ふりかえり」を続けてきたことで、“ふりかえり”でチーム全員の成長を図る でも書かれていますが、まさに成長していくことを実感しています。

参考記事

“ふりかえり”でチーム全員の成長を図る

これからの課題

問題点で挙げたように、クライアントと一緒にアジャイル開発を採用して効果を上げていくには、きちんと説明して特徴や進め方を理解してもらい、従来とは違った契約をしていく必要があると思っています。

現在は、まず信頼関係のあるお客様と一部採用しながら、進めていき、実績を増やしていますが、残念ながら契約に関しては従来のままとなっています。

SonicGardenの倉貫さんの記事、オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来は一つの解だと思います。弊社なりの解を見つけていけたらと思っています。

参考記事

オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来

目指すところ

弊社には「日本で一番知識や感情を共有して価値を生み出すことができる会社となる」という目指す姿があります。設立時から、知識共有、チーム開発に拘っており、それは今も変わっていません。

直近の目標として、2012年8月末までにアジャイルで開発していますと胸を張って言えるようにすることです。

最後に

弊社ではただ言われたものを開発するのでは無く、かんがえるといったお客様と一緒になって考えていくことを推進しています。（現在のかんがえるはGetting Realとアジャイル開発のインセプションデッキを組み合わせたシートを作成して、お客様と共有するようにしています）

アジャイルでの開発を検討している方がいらしたら、ぜひご連絡ください！

かんがえるシート

興味のある方がいましたら、こちらご利用ください。
かんがえるシートをダウンロード