スクラムギャザリング東京2011でYahoo! JAPANのスクラムへの取り組みをご紹介しました

こんにちは！R&D統括本部でアジャイル開発の推進を担当している高橋(@kappa4) です。

近ごろ、書籍「アジャイル・サムライ」のヒットなどで再度注目を集めているアジャイル開発ですが、そのひとつとしてスクラムがあります。そのスクラムのイベント、スクラムギャザリング東京2011が先日10/19(水)、22(土)の2日間に渡って行なわれました。Yahoo! JAPANでは今年10月にスクラムを組み入れた開発が公式に認められましたので、これまでの成果を事例発表という形で弊社R&D統括本部プラットフォーム開発本部本部長志立と、フロントエンド開発1本部の立木から紹介させていただきました。 ヤフーのセッションが行なわれた1日目は有料カンファレンスであったため、広く資料の公開は行なわれていませんが推進担当として伝えたかったことの要点をこの場でもお伝えしたいと思います。

イベントについて

今回発表しましたスクラムギャザリングは、スクラムの普及促進をしている米国の非営利団体Scrum Allianceの主催・協賛を受けて世界中で行なわれるイベントです。今回が日本で初開催でした。 参加者は両日あわせてのべ300名を越え、アジャイル開発がいよいよ本格的に日本で普及し始めることを予感させるイベントでした。
http://www.scrumgatheringtokyo.org/

Yahoo! JAPAN セッションの要点

推進担当として発表で伝えたかったことの要点をまとめると、以下の5点です。

1. 推進側は先にバリューを提供する
2. 小さく導入し、知見を貯めてから公式ルールにする
3. 推進側はしっかりサポートする
4. ウォーターフォールは今まで通り残しておく
5. 開発手法は文化であり、急激に変えることはできない

1. 推進側は先にバリューを提供する

新しいやり方を導入することは推進側が思うより不安が多くあるものです。その不安を少しでも柔らげ、最初の一歩を踏み出しやすくしていく必要があります。 そのための施策としてまずはアジャイル開発やスクラムについて知識を提供するため、社内セミナーを不定期で開催しています。 先に推進側からバリューを提供することで、さらに興味を抱いた方がコンタクトをとって来やすいですし、導入も最初から興味のある状態で始められます。この際個人的には、消費行動の心理モデルであるAIDMAを意識していました。

2. 小さく導入し、知見を貯めてから公式ルールにする

新しいやり方には、経験して明らかになる課題がつきものです。まずは小さなプロジェクトやチームでテスト的に導入し、経験を蓄積していくことが必要です。いきなり大々的に公式ルールを設定すると、課題に対応しきれず失敗するリスクが大きくなります。 ただし、ここで小さくと言っているのは「小さいプロジェクト、小さいチーム、会社の中の一部」を指しています。アジャイル開発のルールはお互いに影響しあっており、一部のルールだけを導入するやり方は私たちのチームではあまりお勧めしていません。一部ルールの導入しかできない、あるいはカスタマイズが必要だと思っても、その後の基盤となる標準的なやり方を経験してから変更していくことで、より良い変更をしていけるのです。

3. 推進側はしっかりサポートする

セミナーに参加いただき、導入用のドキュメントを渡して「あとはよろしく」では上手にできません。 アジャイル開発の経験者がチームとコンタクトをつづけることで、各チームの状況に応じた解決法を自分達で導いていけるようにします。(この経験者の役割を『コーチ』と呼んでいます) 特に導入当初はしっかりと関わりを持って考え方をガイドしていくことが必要です。もし、アジャイル開発のルールが守りづらい場合は、周りに理解を求めるお手伝いをすることもあります。

もちろん、コーチの助けを借りずに全て自力で導入していくことも可能です。コーチを依頼しない場合は、どこから手をつけていくのか？外せないポイントや考え方はどこか？あるいは外した場合に起る不都合は何か？といったことを時間をかけて経験・学習していくことになります。その試行錯誤の経験は大きな力になりますが、より学習を加速したい場合や第三者視点での指摘が必要な場合はコーチを依頼するのが良いでしょう。

4. ウォーターフォールは今まで通り残しておく

Yahoo! JAPANの10月以前の開発手法は公式にはウォーターフォール開発の一択でした。今回新しくスクラムを組み入れたアジャイル開発が公式に認められましたが、ウォーターフォール開発を止めるということではなく、プロジェクトの特性やチーム状況に応じて選べるようにしています。ウォーターフォール一択しかない場合では向き不向きを判断する余地がありませんでしたが、代替策を提示することで様々な状況を直視し、現実に沿った理性的な判断ができる機会をより増やせると考えています。

5. 開発手法は文化であり、急激に変えることはできない

開発手法には会社による運用の個性、それに適応した教育体制やマネジメント体制がありますので、会社文化のひとつであると考えて差し支えありません。幕末から明治維新にかけていろいろな摩擦が生じたように、新しいアイデアを取り入れる際は摩擦がつきものです。 特に初期段階ではまずはこちらから積極的に事情を理解し、少しずつ浸透させていくことが大切だと考えています。

経験を公表し、シェアするということ(個人的な学び)

今回の発表を社内の裏方として支えました。また、今回のスクラムギャザリング自体にも裏方として関わりました。こうして社外の方にも取り組みを知っていただき、反応を頂くことで、組織の学習サイクルが早まっていくと感じています。同じく、個人としても学んだことや取り組んだことを社外のコミュニティ等で発表することで、成長をより早めていけると確信しています。また、参加者としてコミュニティでもそこで得た技術や知識を業務に活かすことができ、自分の会社を客観的に見ることができ、学びを還元していくきっかけを得られます。参加している人達は特別な人達ではありません。同じ興味を持つ人達と思いを共有することは、それ自体が楽しいことです。

ヤフーのアジャイル開発はスクラムをベースにしていますが、代表的なコミュニティを2つご紹介します。(弊社の業務とは関係ありません。)

• すくすくスクラム - @Sukusuku_Scrum
• スクラム道 - @tao_of_scrum (私もスタッフをしています)

お礼

今回のスクラムギャザリングは前記のコミュニティで出会った人達がお互いの思いを共有して実現したイベントです。今回奇妙なご縁で実行委員長を務めましたが、それもこういった場で同じ思いを共有できる仲間たちと出会えたからでした。 いつもコミュニティという素晴らしい場を提供してくれる方々、今回このイベントに力を貸してくれた皆様方、素晴しい講演をしてくださった登壇者の皆様にこの場を借りて深く御礼申し上げます。

最後に

スクラムギャザリングについては、報告記事がいくつか出されていますので、是非そちらもご参照ください。

• PublicKeyさん
  • Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（前編）
  • Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（後編）
• Twitter まとめ
  • Scrum Gathering Tokyo 2011 : Day 1 #sgt2011
  • Scrum Gathering Tokyo 2011 : Day 2 #sgt2011

弊社でも公式ルール化が済んだばかりで、社内制度への対応も一部残しています。文化への適応や浸透もまだまだこれからですが、この取り組みが少しずつ適用範囲を広げていきながら、より良いYahoo! JAPANのサービスに繋がっていけばいいなと思っています。