DX（デジタルトランスフォーメーション）を実現する
大規模アジャイル開発

高橋規生株式会社日立コンサルティング　マネージャー

新井英史株式会社日立コンサルティング　シニアコンサルタント

2020年4月23日

１．ライン生産からセル生産へ

デジタルトランスフォーメーション（DX）時代における企業情報システムは、どのような開発方法を採用すればよいのであろうか。DX時代の情報システムは「SoE」「SoR」「SoI」といったシステム領域特性に分類されると考えられる^※1。「SoR」領域は基幹システムとされるので、伝統的なウォーターフォール型の開発方法が採用されることが多いと考えられる。しかし、「SoE」「SoI」領域のシステム開発には課題があるため、従来とは異なった、大規模アジャイル開発方法を採る必要がある。

※1: 第1回「DX時代のITアーキテクチャとグランドデザインによる展開」

（1）大規模アジャイル開発方法

「SoE」「SoI」領域のシステムの開発には、以下のような課題が存在する。

①: デバイスや技術の急激な進歩、変更、ユーザーニーズの急速な変化
SoEは消費者が利用するシステムなので、スマートフォン対応はもちろん、VR/ARや動画配信、位置情報活用、5G大量高速通信などの新しい技術への対応が求められる。また、消費者のニーズは移ろいやすく、SNSで爆発的に人気が出たかと思えば、新規性が薄れると急速に陳腐化して見向きもされなくなるケースが発生する。そのような急速な変化への対応が必要となる。
SoIはデータ分析が主な目的となるが、新たなAI技術や分析技術が次々と生み出されているので、それらへ追随することが開発の要件となる。
②: ニーズが潜在化し、把握が困難
DXによる新規ビジネス開拓を行う場合、ニーズが明確になっているとは言いにくい場合が多いと考えられる。ニーズが明確であれば誰でも市場への参入は容易で、資本力を発揮して薄利多売の消耗戦を勝ち抜き、寡占状態を築くことが重要となるが、それは価値創造性には欠けており、DXビジネスとしては適当でないと考えるからである。ニーズが明確でない場合には、消費者がまだ気付いていない潜在的な価値やニーズを新技術（シーズ）により掘り起こし、「見える化」する必要がある。
また、SoI領域におけるデータ分析システムにおいては、通常、成果を得るための分析手法（アルゴリズム）を発見すること自体が困難であり、手探りでシステム要件（ニーズ）を規定することになる。
③: 常に変化を追い続ける持続可能性を維持
上記①②のように要件が変化する領域であるため、常に軌道修正する必要があり、それを可能とする開発手法が求められる。ウォーターフォール型の開発方法では、開発が終了しないと修正ができないため、変更が必要でも一度完成させなければならないという矛盾が生じてしまう。

このような課題を解決するためにアジャイル開発方法は適している。また、以下のような特徴を持つ。

A）: リリース期間の短縮
アジャイル開発は、ウォーターフォール型開発方法における完成主義、ドキュメント主義、工程順守主義を避け、動作可能なプログラム（プロトタイプ）を2週間ほどの周期で開発し、ユーザーに仕様を確認しながらシステムを組み上げていく方法である。過剰なドキュメント作成やテストを排し、3カ月程度でシステムリリースが可能である。このことから上記①のような課題に対して、新技術を導入した新フロントシステムを短周期で迅速に提供することが可能となる。
B）: 反復開発による試行・修正周期の短縮
アジャイル開発では初回のシステムリリース後、変更や追加したい機能を順次開発していくことで、次々とシステムリリースが可能となる。これにより、試行錯誤しつつニーズを明確化して行くことができる。潜在的なニーズを掘り起こすためには、新技術などを利用したプロトタイプを作成し、利用者に改良箇所の評価をヒアリングすることが有効な手段として知られているが、アジャイル開発は、プロトタイプ開発とその改善を周期的に実施することができ、適した方法と考えられる。
データ分析システム開発においても、成果が上がる分析手法、およびデータを試行錯誤で探索する必要があるため、アジャイル開発の採用が必須と考えられる。
C）: 開発負荷の平準化
工程・工期に合わせて体制を組むウォーターフォール型開発とは異なり、アジャイル開発では通常５～8名程度のチームを組んで、開発要素を細かく分解し優先度を決め、2週間程度の単位でその要素を開発して組み上げるという方法を採っている。単位内でできる範囲の開発を行い、残作業分は次開発単位へ持ち越すため、負荷が平準化されるという特徴がある。頻繁に修正が入る「SoE」「SoI」領域のシステム開発は長期に及ぶ可能性があるため、体制の大幅な変更の必要がなく淡々と開発推進が可能なアジャイル開発は、発注者・受注者の双方にとって有意な方法と考えられる。

（2）アジャイル開発の進め方

アジャイル開発の進め方

プロジェクト立ち上げ準備、キックオフを経て開発が開始される。利用可能なシステムとして外部に提供するタイミングをサービスリリースと呼び、3カ月程度の周期で実施する。最初のサービスリリース周期に入ると、まず要件定義を開始する。次に要件定義がある程度進んだら、要件定義を継続しつつ優先度の高い要件に関して開発を開始する。開発は「スプリント」と呼ばれる２週間程度の周期で実施される。スプリント内では、設計、実装、テストを実施し、プログラムとして完成された状態まで仕上げる。完成されたプログラムは部分的ではあるが動作可能なので、プロダクトオーナー（システム仕様決定責任者）が開発成果物の仕様チェックを行う。そこで要件を充足していれば採用となり、していない場合は次スプリント以降で修正・再開発となる。このようにスプリントを繰り返すことにより、要件を充足したプログラムを蓄積していき、サービスリリース直前のスプリントでリリースするプログラムを選択し、システムとして組み上げる。こうすることで、3カ月周期で利用可能なシステムをリリースすることが可能となる。

上記の進め方を実現するためには、「要件・作業項目の決定方法」「開発体制と分担」について以下に述べる工夫が必要となる。

（3）要件・作業項目の決定方法

アジャイル開発を実施するためには、2週間程度の各スプリントで動作可能なプログラムを開発できなければならない。また、3カ月程度のリリースサイクルで、エンドユーザーの利用に堪えるレベルのシステムを提供する必要がある。細かい品質はスプリント、リリースごとに改善していくことが可能であるが、主要な機能は各リリース時に最低限稼働できていなくてはならない。
そのためには、要件定義とその細分化、優先順位付けの作業が重要になってくる。その方法を示した図が以下となる。

要件の細分化と作業項目の関係

システム開発における要件は４段階で細分化される。

①: Epic（エピック）
開発するシステムや製品に対するニーズと、それを解決するためのソリューション（方法）を示す。
最も広範囲な要件であり、システム全体の方向性を決める要件。
②: Feature（フィーチャー）
エピックから導出される最上位の要件を示す。システムの機能体系・モジュール構造を決定する。
③: User Story（ストーリー）
フィーチャーから細分化された、スプリント内で開発可能な単位の要件。各スプリントで開発するプログラムは、本レベルの要件を満たすことが完成条件となる。
④: Task（タスク）
ストーリーを細分化した、各担当メンバーが実施可能な具体的な作業項目。スプリント内で複数のタスクを実行し進捗（ちょく）を管理する。

ストーリーはユーザーが利用する機能の最小単位であり、スプリントで動作確認できる単位でもある。

（4）スクラムとは

アジャイル開発は、「アジャイルソフトウェア開発宣言」、「アジャイル宣言の背後にある原則」が根底にある。アジャイル開発にはいくつか流派があるが、特に「スクラム^※2」、「XP(eXtreme Programming)」が有名である。本記事では、スクラムに絞って紹介する。

※2: スクラムガイド

スクラムは、「変化を受け入れて、プロダクトの価値を素早く届けるフレームワーク」である。スクラムには、プロダクトオーナー、スクラムマスター、開発チームという三つの役割があり、これらがそろうことでスクラムチームとなる。

【スクラムチームの構成要素】

①: プロダクトオーナー
開発チームの作業とプロダクトの価値最大化と、プロダクトバックログの管理に責任を持つ。
②: スクラムマスター
スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうように支援する。
③: 開発チーム
各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届ける。

スクラムを理解するに当たり、スクラムはプロジェクトの「管理」を主眼にしたものではないことに注意すべきである。「PMBOK（Project Management Body Of Knowledge)」では10の知識エリア（コスト管理、スケジュール管理、調達管理など）に基づいたプロジェクト管理業務を、ノウハウとして規定している。
一方で、スクラムにはプロジェクトマネージャーという役割は規定されていない。スクラムマスターがプロジェクト管理業務を担うわけでもない。なぜなら、開発チームの行動規範として、自律的に判断して動く「自己組織化」が前提となるからである。短期間で成果をリリースするには、ただ作業指示に沿って動くのではなく、開発チームのメンバー一人一人が主体的に判断・行動する必要がある。スクラムマスターは、スクラムを成立させることに主眼を置き、スクラムのコーチングや開発チームが抱える課題の除去に取り組むことになる。

（5）開発体制と分担

アジャイル開発に参加する担当者は通常５～8名程度である。1名のプロダクトオーナーが、プロダクトバックログに開発項目と優先度を起票し、プロダクトオーナーと開発チームが相談のうえ、優先度に基づいて開発対象を決定する。1名のスクラムマスターがスクラムの理論・プラクティス・ルールを開発チームへレクチャーする。開発チームは、ストーリーの管理、タスクへの分割、担当者割り当てなどを率先して行う。1人が設計からテストまで一貫して一つのプログラムを担当し、画面からデータベース、プログラムロジックまでの設計・実装を行うので、責任持ってスプリント内で完成させる。ウォーターフォール開発における担当者は、画面設計、データ設計、ロジック設計などスキルごとに特化、分断されているのに対し、アジャイルではすべての設計を1人でこなす必要がある。アジャイル開発の実現は、要員の単能工から多能工への成長、ライン（流れ）生産からセル（集中）生産へのパラダイムシフトの実現ともいえよう。

フィーチャー・ストーリー・タスクの相関図

２．PMO７つ－１の道具

変化が速く、試行錯誤による手探りの仕様明確化が必要な「SoE」「SoI」領域のシステム開発方法として、アジャイル開発が適していることが前章で明確になった。しかしアジャイル開発は5～8名程度で実施する小規模な開発に適した手法であり、企業情報システムのような大規模なシステム開発へ採用できるものではないと考えられていた。そこで、当社は大規模システム開発へアジャイル開発を適用するために、以下の技法を開発した。

（1）課題と解決策

小規模システムに適したアジャイル開発を大規模化するためには、単純に考えると開発チーム数を増やして、規模を大きくすることが適していると考えられる。大人数の開発要員の一人一人についてタスク割り当て、進捗管理を行うことは事実上不可能だからである。ところが、開発チームを増やすと以下のような問題が発生する。

①: 各チームが開発したプログラム間で不整合が発生し、システムが動かない
各チームは割り当てられたストーリーを実現すべく、開発にリソースを集中させているため、他チームの開発内容把握を行う工数がなく、自チームと他チームが開発したプログラムが連動する際に、機能重複や機能不足を発生させてしまう。
②: チーム間にまたがる課題がボトルネックとなり、開発が進まない
複数チームに関わる課題（共通部品、環境構築など）に関して、お互いが他方の開発チームの担当と考え、誰も検討しておらず開発のボトルネックになってしまう。
③: 他開発チームのプログラムや開発環境の利用方法が分からず開発できない
他開発チームが開発していることが分かっている機能を、工数削減のために共用したくても、利用方法が分からないために別途開発してしまうことがある。

大規模アジャイルの課題と解決方針

上記の課題に対する解決策として、以下に述べる方法の実施が有効である。

（A）意思決定体制の強化
プロダクトオーナー、スクラムマスターを多重化、階層化し、権限委譲による意思決定迅速化が必要である。各チームにおける開発対象範囲・分担や、利用すべき基盤・共通機能・開発ツールを素早く決定し、各チームに徹底させるために、チーム間の調整を行うプロダクトオーナーの代理で、複数チームを取りまとめるスクラムマスターが務める役割を設定する。

（B）緊密な調整会議体運営
PMO機能強化による、開発チーム間会議設定と方針伝達、フォローを実施する。スプリント期間の約2週間で開発を終了するためには、課題の放置は命取りである。スプリント内で開発終了しなくなってしまうからである。よって、スプリント開始早々に開発チームのリーダーとスクラムマスターを集めて課題を共有し、解決策の検討・対策を担当するチームを構成し、期限を設定する。毎スプリント終了時に進捗状況を会議で共有し、未解決の場合は対策を行う。

（C）情報共有機構構築
各チームで必要な情報を、労力をかけずに提供・入手・共有するため、情報共有システムを整備するとともに、スクラムマスター会議から開発チームが必要とする情報のニーズを抽出して、収集と展開を行う。アジャイル開発ではドキュメント作成を極力避け、プログラム開発へ注力することが大原則であるが、基盤や共通部品を開発・利用する場合は他チームの開発でも利用できることが必須なため、ドキュメントを提供・入手することが最優先となる。その際には文書管理システムやバージョン管理システムなどのドキュメント共有機能を利用して、迅速な情報共有を図る。

大規模アジャイル開発技法

（2）意思決定体制

大規模アジャイル開発における意思決定体制は以下の構造となる。

①: プロダクトオーナー
開発チームの作業と開発システムの価値最大化および、リリース機能の決定・管理に責任を持つ。プロジェクト全体で1人だけ存在する。
②: プロダクトオーナー代理兼スクラムマスター
スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。開発チーム間の調整を行い、リリースに関する最終判断以外をプロダクトオーナーに代わって意思決定する。スクラムマスター1名が複数の開発チームを担当する。
③: デザイナー
システムが実現すべき要件を明確化し、プロダクトオーナーが決定するリリース計画に基づいて、要件定義を実施する。プロジェクト全体に１チームを複数名で構成し、システムアーキテクトや開発チームと要件をすり合わせる。
④: システムアーキテクト
複数チームのスプリントと設計を俯瞰（ふかん）し、システム全体のアーキテクチャに責任を持つ。基盤・共通部品の開発・利用を促進して効率化し、開発ノウハウの蓄積・共有を図る。システム全体を統括する人を1人置くことを推奨する。
⑤: 開発チーム
各スプリント期間中にリリース判断可能なシステム・機能を完成させる。各チームには、チームリーダーを設ける。チームリーダーは、複数チーム間で調整が必要な事項を担当する。

①プロダクトオーナー、②プロダクトオーナー代理　兼　スクラムマスター、③デザイナー、④システムアーキテクトの各役割は、開発プロジェクト全体を見渡して調整・方向性を決定することにより、リリースされたシステムが有効な価値を持つことを保証する。

意思決定体制

（3）調整会議

大規模アジャイル開発を可能にするために、以下のような会議体を実施する。

会議体スケジュール(タイムボックス)

①: スプリント計画会議（Day1）
チーム内で今スプリントの計画を立案する。実装するストーリーを選択し、タスクへ細分化・担当割り当て、工数見積もりを行う。
②: デイリースクラム（毎朝10分程度）
前日までの進捗共有、当日予定作業の確認、課題（困っていること)を共有する。
③: 開発チーム合同のリーダーミーティング（Day3）
各チームのストーリーとタスクを確認・合意する。チーム横断の連絡事項を共有・調整し、各チームの進捗状況を確認・共有する。
④: 報告内容確認・調整ミーティング（Day7～Day8）
各チームの進捗状況確認、PMOチームへの依頼・相談を行う。プロダクトオーナーミーティングでの報告内容・順序・調整事項を事前確認する。
⑤: 開発サブチームミーティング（Day9～Day10）
各開発テーマ別のチームが主体となり、関連するメンバーを招集して、技術的な課題の方針検討・調整・分担決定する。必要に応じて他チームメンバーを招集し、要件取り込みチェックを実施する。
⑥: プロダクトオーナーミーティング（Day9～Day10）
各チームの進捗報告を行い、プロダクトオーナーの指示事項を伝達する。各チームからプロダクトオーナーへ重要事項を報告し、調整・決定を行う。各チームが成果・デモをプロダクトオーナーへ披露・確認し、リリース可否・修正・変更方針を決定する。エピック、フィーチャーの確認・合意・割り当てを実施する。
⑦: プロダクトバックログリファインメント（Day10）
各チームが内外の状況に基づき、実装予定のストーリーの追加・変更や、優先順位の見直しを行う。プロダクトオーナーミーティングの結果を反映する。
⑧: 振り返り（Day10）
今スプリントの活動状況をKPTA（Keep,　Problem,　Try,　Action）で整理し、次スプリントでのプロセスの改善・成長へつなげる。
⑨: チーム内スプリントレビュー（Day10）
チーム内で今スプリントの開発成果物をレビューする。

①②、⑦⑧⑨は各チーム単独で実施し、③④はプロダクトオーナー代理兼スクラムマスターと全チームのスクラムマスターが参加する。⑥は③メンバーに加え、最終決定者としてのプロダクトオーナーおよび、デザイナーとシステムアーキテクトも参加する。⑤はプロダクトオーナー代理兼スクラムマスターと各チームスクラムマスターがチーム毎に会議を実施する。

（4）情報共有機構

大規模アジャイル開発は、各チームが密に連携して推進するため、設計ドキュメントや各種資料にはプロジェクトメンバー全員がいつでもアクセスできるようにする必要がある。以下のようなツールを利用可能で、どのツールを利用するかは、用途やメンバーの役割、習熟度によって選択する。

①: 文書管理システム
オンラインストレージや、企業内のファイルサーバーなどのファイル共有システムを用いて、必要なドキュメントを共有することが可能。プロジェクト計画書や管理手順説明書など、ドキュメント単体でメンバーへ共有する必要がある場合に適している。
②: 進捗管理ツール
会議での報告に関連付いたドキュメントや、各チームの開発成果物・デモアプリケーションを共有する場合に適している。
③: ソースコード管理ツール
共通部品や基盤機能のソースコードを共有し、「利用ガイド」「開発ガイド」など、ソースコードを使うドキュメントを提供する用途に適している。
④: コラボレーションツール
チーム間での問い合わせ対応やアドバイス提供、課題調整などのコミュニティ活動で情報を共有する場合の利用に適している。

（5）進捗管理

プロジェクト管理の重要な項目の一つに進捗管理がある。大規模アジャイル開発は超小規模ウォーターフォール開発を多数並行実施することに等しく、管理対象となる開発項目が多いので、効率的に進捗を管理しないと成功が困難になる。そのため、ツール利用を前提とした以下の管理方法を適用する。

①: 「かんばん」管理
タスクをステータスにより分類する「かんばん」により視覚的な進捗管理が可能となり、作業効率が向上する。タスクを１件ごとにチケット状に表示し、「新規」「進行中」「終了」のステータスごとに分類し、ドラッグ＆ドロップでチケットを領域移動させることで、簡単に状態管理が可能となり、一目で進捗を把握できる。また、複数チームにまたがる課題事項をタスクとして登録して進捗を管理することにより、チーム間の作業の抜け漏れを防ぐことが可能となる。

「かんばん」管理

②: ストーリーポイントを用いたバーンダウンチャート
各タスクに配分された作業量を示す指標（ストーリーポイントや残タスク時間）を用いて、スプリント内の作業量指標の消化状況（タスク終了状況）をグラフで可視化する。バーンダウンチャートにより理想的な進捗と実績の差異が可視化されるため、定量的な完了予測と対策実施が可能となる。

バーンダウンチャート（ストーリーポイントで表示の場合）

③: バックログ管理
未着手のストーリーをバックログと呼ぶ。バックログの優先順位を定期的に見直し、各スプリント開始時に開発対象に設定することで、バックログ管理を行う。スプリントが開始されるとタスクレベルの作業実施・管理が行われるため、システム全体としての完成度、進捗をチェックすることができない。そのため、システム完成までに必要な作業の総量と項目をバックログとして把握・管理することで、優先度の高い作業を優先し、リリースまでに利用可能な機能の完成を保証する。

(6）ストーリーの記述とストーリーポイントの設定

アジャイル開発に特徴的な要素である、作業項目の記述方法と、生産性の評価方法について以下に説明する。

①: ストーリー記述方法
ウォーターフォール型の開発における機能要件や、作業項目の記述方法では、機能の動作や作業の内容を記述することが多い。つまり成果物を実現する手段を規定する記述となる。しかし、アジャイル開発では手段ではなく目的を記述することで実現方法の柔軟性を確保し、素早く目的を達成することを優先している。そのため、「Connextraフォーマット」というストーリーの記述方法を用いて以下のように規定することを推奨する。
[ストーリー記述方法]
＜どのような役割のユーザー＞として、＜どのような機能や性能＞ができる。
それは＜どのようなことが達成したい＞ためだ。
②: ストーリーポイント設定方法
ウォーターフォール型の開発における規模見積もりや生産性評価では、ソースコードの行数:KStep、仕様書のページ数など、規模を用いて人月工数を割り出し、生産性指標としていた（X.XXKstep/人月など）。しかしアジャイル開発では、修正が多く発生するため、規模が増加しなくても要件充足に向けて進捗することや、初心者からベテラン開発者まで一律に工数管理すると、パフォーマンスの差を考慮できないことから、規模ベースではなく、成果量をベースとした仮想的な数値であるストーリーポイントを進捗管理で利用する。例えば、1人の開発メンバーが1日でできる作業成果物量を数ポイントとし、チームメンバー人数分の総ポイント数を集計することで、スプリント内の作業工数の見積もりや実績管理が可能となる。ストーリーポイントは、開発チームにとって共通認識を持てる、ブレの少ない基準を設けることを推奨する。

３．成功に向けた道しるべ

（1）事例と今後の展開

日立製作所では社内向けIoTシステム基盤を約150人規模でアジャイル開発している。16のチームを5つのグループに分類し、システム基盤、管理ツール、IoT分析サービス、サンプルアプリケーションを同時進行で開発し、3カ月ごとに10回以上のリリースを実施している。一部機能をサービスとして事業化、外部販売を実現している^※3。

※3: Lumada Solution Hub

一方で、政府情報システムにアジャイル開発を積極的に取り入れる機運が高まっており、システムの調達仕様書にも対応を求める記述を見かけるようになっている。認定プロダクトオーナー（CSPO）、認定スクラムマスター（CSM）のようなスクラム関連の資格は今後注目されるだろう^※4。

※4: 筆者も、2019年5月に認定スクラムマスターを取得済み。Eiji Arai - Scrum Alliance

（2）課題

アジャイル開発は多くの利点をもたらすが、適用には工夫が必要となる。
アジャイル開発では要件が明確でないため迷走しやすく、強力な仕様決定者が不可欠となる。また、いくらでも修正ができるのでプロジェクトの明確な終了が存在せず、スプリントが永遠に続いていくことにもなりかねない。ウォーターフォール型開発でも開発終了後からシステム廃棄まで保守・運用作業を継続するが、アジャイル開発では開発状態が継続的に続くため終了タイミングが判定しにくい。プロジェクト・システムの評価を一定周期で評価する必要があると考えられる。
開発要員育成も重要な課題である。前述のように開発要員は多能工となるので、高度なスキルが要求される。アジャイル開発チーム体制にスクラムマスターによる開発者指導や開発者同士の相談・アドバイスの実施、振り返りによるチーム成長といった育成要素が組み込まれてはいるが、育成はOJTであるため、開発プロジェクトが増えないと開発者を増やすことができない状況である。

このような課題はあるが、DX時代の情報システム開発方法の本命にアジャイル開発があることは間違いなく、十分な準備と対応が肝要と考えられる。

以上

本コラム執筆コンサルタント

本コラムへの感想などはこちらから