Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（前編）

2011年10月24日

先週の水曜日（10月19日）に、アジャイル開発手法「スクラム」を学ぶイベント「Scrum Gathering Tokyo 2011」が都内で開催されました。

スクラムを実際に導入した事例として紹介されたのが「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み～組織と現場から～」のセッションで紹介されたヤフー株式会社の例。

同社は2名の担当者が中心となり、社内セミナーなどでスクラムに興味を持ってもらうことで社内の自主的な変化を促す一方、評価制度や内部統制などの制度を調整する担当役も置くことで制度面での変化も後押しするなど、スクラム導入の具体的な手法が紹介されました。

そのセッションの内容を紹介しましょう。

2名で分担してアジャイル開発の推進を開始

ヤフー株式会社 R&D統括本部プラットフォーム開発本部本部長志立正嗣氏。

組織の立場から見て、どういう風にスクラムを導入してきたのか、という話をします。導入のきっかけはCTOからのオーダーでした。

昨年、ヤフーはローカル広告関連のシリウステクノロジーズという会社を買収しまして、この会社ではアジャイル開発をやってうまくまわっていた、というのが背景にありました。

これまでの開発フローはウォーターフォール型でした。途中何度か承認や判断のポイントがあり、リリース前に承認を受けて、という方法です。

このガチガチのウォーターフォールの中にアジャイルを入れるのに、3つのステップを考えました。

まず実情を調査して、アジャイル開発を弊社に当てはめるとどんないいところ、悪いところがあるのか。これをだいたい2カ月くらいやって、昨年の9月にスクラムを推進するプロジェクトを開始。

昨年10月には推進体制を、社内調整役とコーチ役の2名で分担して開始しました。

社内調整役は、管理本部とか内部統制とか、いままでのルールを変えるとうるさそうな人たちとの調整。コーチ役は実際にプロダクトを作ってガリガリ行こう、という役割。こっちはガーッといく一方で、他方はフリクション（摩擦）が起きるところで交渉したり謝ったりしながら進めていくと。

進めるに当たっては、何を大事にするかというとこの3つ。スキル、制度、そして環境。この3つが揃ってはじめてアジャイル開発が会社に浸透するのではないかと思いました。

それぞれを紹介します。

習熟に関しては3つのステップで進めました。まずアジャイル開発に興味を持ってもらう、そしてヒアリングをし、手厚くサポートします。

トップダウンでアジャイル開発を導入する会社もありますが、弊社は現場が自主的に思えるところからきちっとやっていく手法をとりました。

社内セミナーとかをけっこう頻繁に開催して、そこで興味ありそうな人をピックアップして重点的に訪問して、「怖がらなくていいんだよ」「導入してみようよ」とささやいて、その上長にもサポートして説得してと、そういう風に進めました。

自主的にアジャイル開発をやろうとしていたチームには調査協力してもらって、会社で進めていくにはどうすればいいんだっけ、と聞いたりもしています。

アジャイルを推進するときには開発案件を詳細にヒアリングして、スクラムに向いているかどうかを判断したり、チームの理解度なども含めて適合性を判断しました。

実際にアジャイル開発が始まってからは、先ほどのコーチ役が助けます。スクラムマスターになってやることもありました。

また、テスト期間にスクラムで実際にやってみたら、ちょっと違う、まずい、となったらいつでも撤回して従来のフローに戻すのもオッケーにしました。できるだけソフトにというか優しく環境を整えて、最初の道はいばらだったりしますが、アジャイル開発に取り組めるような環境を作りました。

実際にやってみて、どう習熟に向かわせるか。

まず、いままでのやり方と違うと最初は思っていても、だんだんあいまいになってきます。だからコーチ役を中心に業務中やミーティングにもちょこちょこ顔を出して、アジャイルスタイルでやっているのかチェックして、修正したりサポートしたりしました。

手取り足取りの次には、自分で考えてもらおうと。いまのプロジェクトでこんなところが課題だよと指摘する。その答えはそのプロジェクトの中で悩んでもらう。そうやって自分で判断してもらうようになってもらう。

そして最後に、自分たちでやってもらう。

「振り返り」のみスペシャリストに出てもらって、それ以外はプロジェクトメンバーだけでやってもらいます。ここまできて、スクラムができるようになったと判断します。

スクラムにあった評価制度とは？

次が制度の話。

制度に関して言えば、社内はウォーターフォールに合わせて制度ができているので、アジャイル開発には合っていませんでした。でも今年10月、つまり今月の頭からアジャイル開発に合わせて整備をして、アジャイル開発のガイドラインも正式に発行して、標準の開発プロセスにしました。

例えば「目標評価」。スクラムのプロジェクトメンバーってどうやって評価されるんだっけ？という評価手法が難しくて。

従来の評価法だと、3カ月に1回、何をするのかが期初にある程度決まっています。「このシステムを何日までに作ります」と書きやすい。そうすると期末に、できたね、よかったね、と評価しやすい。けれどスクラムでは「これを作る」というのが決まっていません。期初でコミットメントができないんですね。

では、何をもってがんばったんだっけ、成果として出したんだっけ、というのをどうやって判断するのかと。

これをスクラムの中でどうやればいいのか試行錯誤中です。1つはプロジェクトが成功したかどうかで判断しますが、そこへの貢献度を計る。全体の工数の中で、果たした貢献度と量をどう評価するか、試行錯誤しています。

JSOXや内部統制、ここも対応しなければならないプロダクトが多くて、ここはルールをアジャイル開発に合わせて内部統制のルールを変更しようと試行錯誤しながらやっています。近日中に整備して、アジャイル開発でも対応できるようにしていきたいと思っています。

付箋とかホワイトボードとか、スクラムやるには環境も必要です。例えば、壁に貼る付箋やホワイトボードはセキュリティルール上公開情報だから、みんなが見ていい情報しか書いてないよね、といったことも変えて行かなくてはいけないですし、スクラムでは物理的に人を一カ所に集めることも重要なので、そういったスペース作りなどもしました。