日立製作所が実践したスクラム開発では、約3年にわたって総勢150人のメンバーが関わり、「開発基盤プロジェクト」などを推進した。エンタープライズ向けスクラムの実践は、当初からビッグバン的に導入したわけではなく、徐々に浸透させながら、運営を効率化していった。
エンタープライズ向けスクラムをどうやってプロジェクトメンバーに定着させ、どのように効率化したかを振り返り、その勘所を説明する。
3カ月でスクラムの流儀に慣れてもらう
開発基盤プロジェクトでは当初、スクラムの初体験者が大半を占めていたので、開始から3カ月間は、開発期間を2週間の「スプリント」単位で細切れにして開発していくという、スクラムの流儀に慣れてもらうことを最優先とした。具体的には、2週間のスプリントごとに成果物を完成させてプロジェクト内に披露し、フィードバックを受けて、次回のスプリントで改善していくというサイクルに慣れることが必須だった。なぜなら、ウオーターフォール型の開発に慣れた担当者は、ついつい成果物の完成度を100％にしないと、共有しない風潮があったからである。
また、スプリントごとに実施する合同リーダーミーティングや全体ミーティングでは、特別な会議資料を作成することなく、Redmineのかんばんを投映して説明することにした。そのため、他チームが投映したかんばんを一目で理解できる必要があり、ユーザーストーリーの記載フォーマットを統一した。
しかも、ユーザーストーリーは開発者目線の「機能ありき」で表現せず、利用者視点での最適な解決策を記述する必要がある。そこで、書籍『User Stories Applied: For Agile Software Development』などで紹介されているユーザーストーリーの記載フォーマットを参考に、以下の通り統一した。
エンタープライズ向けスクラムを成長させた6つの改善点
開発基盤プロジェクトでは、最初からスクラムの各種プラクティスを愚直に全て実行したわけではなく、試行と改善を繰り返して成長させてきた。この成長過程の中から代表的な6つを紹介する。
（1）各チームの成熟度に応じた会議体の増減
プロジェクト開始当初は、PMOチームと、アーキテクチャーチーム／開発チーム／運用チームとの個別の進捗確認ミーティングを、各スプリントの後半週に1時間、計3回実施していた。主にPMOチームの会議負荷が高かったが、各チームのスクラム開発手法の習熟度に応じて、各施策を適用する必要があったためである。
各チームがある程度スクラム開発手法に慣れてきてからは、「全体事前ミーティング」という1つの会議体にまとめた。これにより、ミーティングをチーム間の調整事項を議論する場という役割に集中させることができ、会議負荷の軽減につながった。
（2）チームの生産性を可視化
スプリント計画策定時は通常のスクラムと同様に、ユーザーストーリーはストーリーポイントを使用し、タスクは作業時間を使用して、作業量を見積もることにした。スプリント期間中は、スクラムの作業進捗状況が計画からどれくらい離れているかを一目で表す「バーンダウンチャート」を活用した。ストーリーポイントやタスク時間を予定通り消化できているかどうかを可視化し、合同リーダーミーティングで各チームリーダーが互いに定量的に進捗をチェックできるようにした。
スクラムでは、スプリントを重ねるごとにチームやメンバーが成長していくことが期待される。合同リーダーミーティングでは、各スプリントの予定と実績のストーリーポイントをチームごとにプロットし、以下の2つの観点でスクラムが順調に運営できているかを相互に確認した。
・見積もり精度の向上：予定と実績の差は、スプリントが経過するごとに小さくなっているか
・成長の確認：ストーリーポイントは右肩上がりになっているか
