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週：コーディング／バグフィックス
するとどうなったか。プランニングを完全に終えるまで待っていると工数、時間がなくなってしまうので、何となく分かっているところは、見切り発車でコーディングを始める。急いで強引に作業を詰め込むため、バグが多くなり、バグフィックスが間に合わない。バグフィックスが、次のスプリントに持ち越される。
次のスプリントでは、皆がバグフィックスに忙しい中、次のプランニングをしなければならない。これでは計画通りに進むわけもなく、プロジェクトは「地獄のような悪循環」（白石氏）に陥ってしまった。
