【第8回】大規模システムにも適用可

アジャイル（俊敏）開発は少人数のチームによる取り組みが基本形だが、大規模システムの開発にも適用できる。ただ、従来手法のように、システムの規模の大きさに合わせて高度なＩＴ（情報技術）人材を新たに加えたり、開発メンバーを数十〜数百人まで増やしても失敗する恐れがある。

大規模システムをアジャイル型で開発するには、全体を統制する役割や各チームが円滑に情報交換できる会議体を設ける必要がある。アジャイル開発の一手法であるチームが一丸となって開発する「スクラム」での勘所を説明する。

まず、全体構造の説明からだ。大規模システムでのスクラムは複数の小規模なスクラムチームで構成し、それぞれ「事業企画」「開発」「運用」など役割を分担する。

その上で、その小規模スクラムチームを統括する３つの役割（人）を置く。市場動向などを踏まえシステム全体の方針を決める総責任者「チーフプロダクトオーナー」、各チームの進行役であるスクラムマスターに指導・運営・改善の助言をする総進行役「統括スクラムマスター」、会議の運営や大切な情報の伝達などを通じてチーム連携を後押しする事務局「ＰＭＯ（プロジェクト・マネジメント・オフィス）」の３つである。

次に会議体の説明だ。複数チーム間で生じる課題や調整事項を議論するため、３つの会議体「チームリーダー合同会議」「報告内容確認・調整会議」「全体会議」を新設する。

「チームリーダー合同会議」は２週間の開発周期の場合、３日目に行い、各チームのリーダー、サブリーダーが参加する。各チームの計画や進捗状況を確認する。また、チーム横断の連絡事項を共有・相談・調整する。

「報告内容確認・調整会議」は７日目に行い、出席者はチームリーダー合同会議と同じだ。チーム間で調整すべき事項の依頼・相談や、全体会議での報告内容・順序・調整事項を事前に確認する。

「全体会議」は９日目に行い、チーフプロダクトオーナーと全チームのリーダー層が参加する。各チームがチーフプロダクトオーナーへ実際に動くことを披露し、公開可否・修正・変更方針を決定する。また、各チームの進捗状況を報告し、チーフプロダクトオーナーの指示事項の伝達や重要事項の調整・決定を行う。

ただし、各チームの担当者には十分な作業時間を確保して作業に集中させ、不要な会議には参加させないよう配慮する必要がある。リーダー層が自チームを代表して３つの新設会議に参加することが大規模スクラムならではのチーム運営、会議体運営の工夫である。

まとめると、少人数チームによる自律的かつ迅速・柔軟な開発体制を最大限生かしつつ、各チームが勝手な方向に向かわないように、定期的にきめ細かく調整していくということである。

当社グループでも大規模プロジェクトでアジャイル開発に取り組んだことがある。日立製作所が開発した「ＩｏＴデータ分析基盤システム」である。アプリケーションを動かす基盤に加え、分析ツールや検索サイトなどを同時並行で開発するもので、当社も参加し、スクラムは全体で１５チーム、総勢１５０人程度の規模となった。

３カ月後に試用版、６カ月で仮公開版、９カ月で正式版を公開し、その後も改良を続けた。大規模スクラムでありながら、開始から３年の間に１１回システムを更新・公開することができた。

大規模プロジェクトを統括する３つの役割
「チーフプロダクトオーナー」＝ビジネスや市場の動向などを踏まえ、開発するシステム全体の方針を決める総責任者
「統括スクラムマスター」＝各チームの進行役であるスクラムマスターに指導・運営・改善のアドバイスをする総進行役
「PMO（プロジェクト・マネジメント・オフィス）」＝会議の運営や重要な情報の伝達などを通じてチーム連携を後押しする事務局

※

本稿は2021年8月3日に日経産業新聞に掲載された「戦略フォーサイト：アジャイル開発への道（８）大規模システムにも適用可」を転載しております。

※記載内容（所属部署・役職を含む）は制作当時のものです。