アジャイル開発の達成スコアは半分だが、改善点も見えた
この遅れが発生した要因は次のとおりである、と白石氏はいう。
- プランニングのジレンマ
- 見積もりの甘さ
プランニングでは、「早めに何かを出したい」というチームの方針と「出して駄目だった場合、作り直すのはもったいない」という思いの間にジレンマが生じてしまった。特に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 (大代表)
