20年間続けたウォーターフォール型開発との決別
マイクロソフトの開発部門である日本法人マイクロソフトディベロップメントは、日本独自の視点を持ち、日本発で世界に向けた製品開発を行っている。その中で、白石康文氏が所属するOffice Japanチームのメンバーはデベロッパー、テスト、PMなど35人で、世界全体のOffice開発関係者6000人の中では小規模だが、独立したチームとして活動している。
Microsoft Officeは長年、ウォーターフォール型のプロセスで開発されてきた。プランニングが始まり、End-to-Endで実際に動くものが見られるのに約1年。そこから外にリリースされるまでにもう1年という流れだ。20年の経験があることから、工数の見積もりなどは極めて正確で、スケジュール管理やツールも安定。基本的にデベロッパーにとって無理のない開発が実現されていた。
しかし、いくら効率よく開発できたとしても、プランニングの段階で間違っていたり、開発中に環境が変わってしまったりした場合、開発したものが無駄になることがある。特に近年、次々と新しいプラットフォームやデバイスが出現しており、そのリスクが高くなっている。
そうした環境の変化は当然、Officeチームのリーダーの間でも認識されていた。そこで、次世代Officeプランニングの時期から新方針を検討。次のような方針を打ち出した。
この新方針のうち、Officeチーム開発チームでDev Leadの立場にある白石氏が、もっとも衝撃を受けたのが、「エンドユーザーへのフォーカス」であった。従来のOfficeはエンタープライズ向けの機能が多く、開発も「IT管理者が導入したくなるもの」を優先する傾向が強かった。それを「エンドユーザーが使いたくなるもの」にシフトする。そこでは当然、モバイル、クラウドとの連携が重要になってくる。
さらに、アジリティのある開発として、プランを立ててから2年後に新製品をリリースするのではなく、3か月おきに何らかの成果物を出す。これは、ウォーターフォール型との決別を意味する。
この新方針を受け、Office Japanチームが最初に開発した製品の1つが、ノート作成ソフトウェアOneNoteのWindows Store版である「OneNote App for Windows Store」だ。この開発では、次のことの実現を目指した。
- 2000年代前半からデスクトップ版を提供してきたOneNoteチームとのパートナーシップ。
- マイクロソフトリサーチ（MSR）開発の技術をブラッシュアップして製品化。
- カメラでホワイトボード。ドキュメント、レシート等々の写真を撮ってOneNoteに取り込み、より使いやすくする。
開発は、2013年の前半から3か月間を予定してスタート。ただ、20年間続けてきたウォーターフォール型から、急にアジャイルに切り替えるのは無理がある。そこで、細かい判断は各チームに委ねることとし、Office Japanとしては、次のような基本的な方針を立てた。
- 早い段階でEnd-to-Endでシナリオを通す
-
アジャイル開発の手法であるスクラムにおける基本概念を実装する
- 1か月単位のスプリント（ソフトウェア開発の工程）
- デイリースクラム：毎朝チームの状況を共有する
- プリントレビュー：開発したソフトウェアを関係者にレビュー
- バックログ管理：製品に必要な要素、仕様を管理
- スプリントごとに製品を“完成”させる
白石氏たちは当初、1ヶ月単位のスプリントは、次のような感じで進むのではないかと考えていた。
- 第1週：コーディング
- 第2週：コーディング
- 第3週：コーディング／バグフィックス
- 第4週：次スプリントのプランニング
ところが、最初のスプリントは結構上手く行ったのだが、第4週の次スプリントのプランニングが遅れたため、2回目以降のスプリントは次のような状態になった。
- 第1週：前スプリントのバグフィックス／今スプリントのプランニング
- 第2週：今スプリントのプランニング／コーディング
- 第3週：コーディング
- 第4週：コーディング／バグフィックス
するとどうなったか。プランニングを完全に終えるまで待っていると工数、時間がなくなってしまうので、何となく分かっているところは、見切り発車でコーディングを始める。急いで強引に作業を詰め込むため、バグが多くなり、バグフィックスが間に合わない。バグフィックスが、次のスプリントに持ち越される。
次のスプリントでは、皆がバグフィックスに忙しい中、次のプランニングをしなければならない。これでは計画通りに進むわけもなく、プロジェクトは「地獄のような悪循環」（白石氏）に陥ってしまった。
アジャイル開発の達成スコアは半分だが、改善点も見えた
この遅れが発生した要因は次のとおりである、と白石氏はいう。
- プランニングのジレンマ
- 見積もりの甘さ
プランニングでは、「早めに何かを出したい」というチームの方針と「出して駄目だった場合、作り直すのはもったいない」という思いの間にジレンマが生じてしまった。特にUX（ユーザーエクスペリエンス）の設計は時間がかかり、プランニングがどんどん遅れる原因になった。
また、見積もりでは、ウォーターフォール型での経験により、コードを書くコストは正確に出せたものの、そこから製品レベルまでのバグフィックス、プライベートレビュー、セキュリティレビューまでの見通しに甘さがあった。
加えて、そもそもアジャイル開発ということでスクラムを選んだつもりなのだが、その基本概念にある手順の中で、次のものが抜け落ちてしまった。
- スプリント計画ミーティング
- スプリントRetrospective（“振り返り”）
- スプリントごとに製品を完成させる
なぜ、抜けてしまったのか。スプリント計画ミーティングについては、2回目のスプリントが始まるころからバグフィックスに追われて、皆が同じ部屋に集まって1日ミーティングするなんて、とても無理だった。
そうなると、Leadが独断で、次のスプリントで何を行うかを決める。マネージャーと合意は取るが、チームの意志を反映する余裕はない。Retrospective（“振り返り”）も同様で、次のスプリントで忙しく、どんどん後回しになっていく。
この状況では、スプリントごとに製品を完成させることはできない。その結果、動くものが一応できてから、出荷可能になるまで1～2か月が必要という状態が常態化した。それでも、以前のウォーターフォール型では、形になるまで1年、出荷できるまでもう1年かかっていたから、現場には「あと1～2か月で出せるのなら、このままでいいのでは」という考えも出てきた。
しかし、これでは状況が変化したときに、迅速な対応ができない。実際、開発中にWindows 8.1やSurface 2がリリースされるなど、自分たちではコントロールできない要因が出てきた。その結果、スケジュールが2回ほど変更され、プロジェクトは3か月の予定が、最終的に半年かかってしまった。
「アジャイルソフトウェア開発宣言」という、アジャイル開発の原点ともいえるマニフェストでは、「アジャイル宣言の背後にある原則」として、アジャイル開発における12個のコアプリンシプル（原則）が掲げられている。その原則に対し、OneNote App for Windows Store開発がどれほど達成していたかをまとめると、次の表のとおりになる。
白石氏は「○が半分、△が3個、×が3個。まあまあな感じ」と振り返るが、Retrospectiveができなかったことと、スケジュールに追われて作業が厳しくなったことが課題として浮き彫りになった。「ビジネス側の人と開発者が常に日々一緒に働く」に×がついているのは、グローバルで開発しているマイクロソフトだからといえるだろう。
△も未達と考えれば、12個のコアプリンシプルのうち、達成できたのは半分である。そのため、白石氏は「スクラムもどき」と評価している。それでも、次のメリットがあったという。
- 最速でEnd-to-endのシナリオが通せる
- バグはあっても社内dogfoodには十分なものが非常に早く作れる
- 社内ユーザーのフィードバックをもとに仕様を見直せる
- 作りなおす可能性の高い部分は不安定でもOK？
以上の経験を踏まえ、白石氏は3つの改善点を挙げた。第1の改善点は「プランニングの遅れへの対策」。たとえば、UXで「この作り方で大丈夫だろう」と自信を持てるところはきちんと作り込み、自信が持てないところは、あまり安定を考えず、スクラムもどきのような作り方で作成し、評価することを検討する。
第2の改善点は「見積もり」。ただし、今回の経験から、デベロッパーの見積もりと現実にどれだけ乖離があったかを検証できるため、今後の改善が期待できる。
第3の改善点は、たとえ面倒でも「スプリントRetrospectiveをきちんと行う」こと。そうすることで、早期に改善点が見えてくるからだ。
そして、最後に白石氏は、「アジャイル開発のエキスパートではない集団が、試行錯誤しながら取り組んでみるとこうなるという一例として、参考にしていただければ幸い」と語り、セッションを終了した。
日本マイクロソフト株式会社
〒108-0075 東京都港区港南 2-16-3 品川グランドセントラルタワー
TEL: 03-4332-5300 (大代表)
