Developers Summit 2012（アジャイル開発）
Developers Summit 2012のアジャイル開発に関する幾つかのセッションをサマリ。聞き違いや理解誤り、要約による主旨の取り違えなどあればご容赦ください。
slideshare、togetterによるまとめ、その他ブログでの秀逸なまとめが、より一次情報に近いです。
- 【16-B-4】アジャイル開発の10年と今後を語ろう。
チェンジビジョン平鍋氏によるアジャイル開発の説明。（⇒slideshare）
◆アジャイルの一つの源流は、リーン・ソフトウェア開発
リーン・ソフトウェア開発とは、トヨタ生産方式の考え方をソフトウェア開発に適用したもの
生産工程の7つのムダ ソフトウェア開発の7つのムダ 在庫のムダ 未完成作業のムダ 加工そのもののムダ 余分なプロセスのムダ 作りすぎのムダ 余分な機能のムダ 運搬のムダ タスク切り替えのムダ 手持ちのムダ 待ちのムダ 動作のムダ 移動のムダ 不良を作るムダ 欠陥(バグ)を作るムダ ◆アジャイルの具体例であるXPは、パタン・ランゲージが源流
パタン・ランゲージとは、街づくりや建築デザインにおいて、利用者参加型のプロセスで成果物を生み出すためのツールであり、「利用者と建築家の共通言語」となるもの。XP(エクストリーム・プログラミング)では「利用者参加型の開発」「漸進的な開発」「変化への対応」などの観点が重視されていて、考え方が共通する。
◆方法論よりも、プラクティス／文脈の時代へ
米国で2011年に実施した開発手法のシェア調査では、アジャイル開発がウォータフォール開発を初めて上回った。これからはアジャイル手法を如何に大規模プロジェクトに適用していくか、また組織改革につなげていくかが重要となる。トヨタ生産方式と同様に、アジャイル手法を現場参加型で実践していくことが必要。
実践の手法としての「プロジェクト・ファシリテーション」が、日本では広く受け入れられている。
永和システムマネジメント角谷氏によるアジャイル開発の説明。（⇒SpeakerDeck）
◆ソフトウェア本来のあり方
- 人とソフトウェアの間に価値がある
- ソフトウェアが"システム"全体を構成する
- 変更に対応できることが求められている
◆自然なソフトウェアと人工のソフトウェア
「誰かの頭の中にあるもの(ビジネス要求)」を「実際に使ってみて頭の中で認識する(ビジネス価値)」プロセスを経て、初めてソフトウェアの価値が発揮される。
ソフトウェア本来のあり方に上手に適合し、このようなサイクルが自然に機能していることが、オープンソース・ソフトウェアの特性である(自然なソフトウェア)。
一方で、ウォーターフォール開発によって受託開発されるエンタープライス・ソフトウェアでは、サイクルが上手く廻らなくなっている現状がある(人工のソフトウェア)。
人工のソフトウェアの開発を、自然なソフトウェアの開発に近づけるため、オープンソース・コミュニティに参加するなどして、理想の開発を求めることが大切。
◆手法や名前にとらわれてはいけない
アジャイル(俊敏な、すばやい)は形容詞であり、開発プロセスがどれだけ活き活きしているかを示す。たとえばスタンドアップ・ミーティング(朝会)を形式的にこなすだけでは不十分。
「アジャイル宣言の背後にある12の原則」に記されるとおり、「チームが効率を高められているかを定期的に振り返り、自分たちのやり方を最適に調整」しなければならない。
ヤフー長岡氏、高橋氏による導入事例。
◆アジャイルコーチ
開発者1,800人の組織に対して、標準化チームに着任して「アジャイルコーチ」を名乗った。2010年7月から2011年10月にかけてアジャイル開発をテスト導入し、2011年10月にアジャイル開発の公式ルールをリリースした。
企業合併によって着任した直後で、第三者視点から開発プロセスを良くしたいアジャイルコーチと、Yahooの社歴が長くて顔が利く社員との二人三脚で、標準化チームからテスト導入を推進した。
◆テスト導入
「Yahooニューストピックス」の運用チームがテスト導入の対象となった。5人のメンバーで小規模の機能追加／改善に取り組むチームだが、各個々人で黙々と開発をして、お互い何をやっているかが判らない状況であった。
開発の見える化や朝会を導入することによって、メンバーが全体感を持って仕事ができるようになったと好評を得た。スプリント(機能リリースの頻度)が短すぎることによってタスク漏れが生じた際には、アジャイルコーチから「スプリントの期間を長くする」旨、一歩引いた目線で助言を与えることによって対策がとられた。
楽天藤原氏による導入事例。（⇒slideshare）
◆楽天でのアジャイルの導入
楽天はカンパニー制の組織であるが、開発部は1部署。開発者1,000人以上、グループ70以上、プロジェクト1,000以上という規模。ウォーターフォール開発がベースである中で、2009年に3人、3ヶ月のプロジェクトでアジャイル手法を導入した。
◆導入の効果
ペアプログラミング、継続的インテグレーション、テスト駆動開発などの手法を導入した。導入当初は稼働時間に占める開発業務の時間が23%であったのが、2011年時点では70%に向上した。
開発業務に占めるテストの割合は、当初10%以下であったのが40%まで増加した。テスト駆動開発の導入当初はプログラミングの時間が圧迫されることによって一時的に生産性が低下したが、運用フェーズで取り戻すことができた。
◆組織改革
アジャイルの効果は開発部全体にはなかなか広がらなかった。開発現場は「エンジニア急増」「育成不足」「レガシーコード」という要因で繁忙感が高いと推測をして、コーチとして開発現場に入って改革を試みた。
「朝礼」「見える化」「コミュニティへの参加」などを推進した結果、関わった20人のメンバーから一体感やスピード感が向上した旨の好評を得た。しかし、コーチが抜けた後は状況は元に戻ってしまった。
1年掛けて20人の賛同者を得たため、20人一人一人に声を掛けて、組織改革を継続したい。
- 【17-A-4】Scrumで組織改革
ディー・エヌ・エー貝瀬氏による導入事例。
◆モバゲーでの課題
組織が急拡大する中で、以下の課題に対処するために自己成長型の組織にしたい。
- スケジュールが立たない←優先順位付けができない
- 責任範囲が不明確←組織が頻繁に変化する
- 問題を放置←目先の課題に取り組むことに忙しい
- 3つの役割(プロダクトオーナー、スクラムマスター、チーム)
- 3つのツール(プロダクトバックログ、スプリントバックログ、バーンダウンチャート)
- 4つの会議(スプリント計画、デイリースタンドアップ、スプリントレビュー、振り返り)
◆課題と対応
段階を経てスクラムを導入する中で、以下の課題に対処した。12チーム、100名の開発全組織でスクラムを導入、自発的な改善の風土が生まれた。
