NTTデータでは、様々なオファリングでお客様のデジタルトランスフォーメーション（以下、DX）を支援しています。Agileの方法論の適用・活用を推し進めるオファリング「Agile Transformation」で数々のお客様のDXをサポートしてきた中で気づいたことは、お客様自身のDXの進み具合（DX推進ステージ）によって直面する課題が異なり、必要な手立ても異なるということです。

我々はお客様のDX推進ステージを下記の図のように捉えています。

図1：企業におけるDX推進ステージ

Agile適用の流れは、（1）初適用として代表的なScrumの適用から始め、（2）Scrumチームのチーム数の拡大や適用案件数を増やし、（3）複数Scrumチームを統制するため大規模Agile方法論（SAFe、Scaled Scrum等）を導入し更に体制規模と適用範囲拡大させ、（4）最終的に組織的にAgileを適用していく、という4ステージに分類できると考えています。
その組織のAgile適用度はAgile適用開始から時間経過とともに向上しますが、伸び率はステージ毎に異なります。（1）のAgile初適用において、PoC案件をScrumで実施し高い成果を上げたとしても、その後（2）で停滞期に入ります。このステージは商用案件への適用を求められる段階であり、PoCよりも前提条件が厳しくなることで環境とプロセスの見直しが改めて必要となります。またチーム数増加に際し、チーム間のパフォーマンスばらつきが技術力やチーム成熟度の差により発生し、期待した規模拡大の効果が表れるまでに時間を要する場合があります。これはDX推進ステージが変わり新たな課題に直面していることに気づかず（1）で成功したやり方を疑わず同じ活動を継続しているようなケースに起こります。Agileは変化に適用する方法論です。外部環境・ビジネス市場の変化に合せるだけでなく、自組織の状況・DX推進状況に併せた変化も必要となります。当社では、お客様の置かれた様々な状況に対応するために、多岐にわたるオファリングをご用意しています。

前述DX推進ステージ（2）（数件実施）でみられる代表事例を3件ご紹介します。

• チームの問題
• プロジェクトの問題
• ステークホルダ（意思決定者）の問題

■ケース1：チームの問題

単一Scrumチームで高い生産性（ベロシティ）が見られたため、更にプロジェクト全体の規模を拡大させるため1チームを追加し要員を2倍にしたところ、生産性は2倍とならず、既存チームの生産性もダウンしてしまうようなケースがあります。
この原因のひとつとして、複数Scrumチームとなることで新たに発生する「チーム間の依存関係」に対する対処が考慮されていないことが考えられます。チームが複数になると、チーム間で依存関係のあるタスクを実施する際に待ち時間が発生する等、単独チームではなかった新たな問題が発生します。極力チーム間の依存関係を無くすようにタスクの切り方や環境設計に考慮が必要です。

図2：チーム間の依存関係について

また、チームを増やす際には、案件の状況・案件の特性を考慮してチーム拡大計画を立てる必要があります。案件のチーム拡大の目的が、既存機能と別に新規機能を開発するためのチーム追加であれば、既存チームは変更せず、新規メンバのみで新チームを構成することで、既存チームの生産性への影響をなくすことができます。一方で、長期継続案件で、膨大な過去のプロジェクト情報の継承が重要な場合には、既存チームメンバを分割し新規メンバとの混成チームとしたほうがチームの立ち上がりはスムーズになります。
Agile Transformationでは、このようなチーム拡張時の体制設計のご支援や、複数チームの立上げをサポートする「Agileコーチ」の派遣も実施しています。

■ケース2：プロジェクトの問題

プロジェクトにScrumを採用したものの、全体スコープがほぼ確定し納期遵守を求められているようなプロジェクトの場合、各スプリントのスコープ必達が義務付けられ、スプリントが超短期のウォータ―フォール開発の繰り返しになってしまうケースがあります。
この原因として、プロジェクトが案件特性的にAgileに適していない可能性があります。Agileは全案件に等しく効果が出るものではなく、特性によって向き不向きがあります。変化がほとんどなく開発量が大きい案件は、ウォータ―フォールで実施したほうがリソースを効率的に使うことができます。要件が頻繁に変化して先が読めない案件は、Agileで実施したほうが手戻りの量を押さえて、ゴール（目的の価値達成）までの到達期間を早めることができます。
Agile Transformationでは、お客様の組織文脈に併せてAgileの適用判断を行う「Agileガイドライン」を執筆するコンサルティングも実施しています。

■ケース3：ステークホルダ（意思決定者）の問題

Scrumチームの運用が適切に回っているプロジェクトにおいて、レポーティング対象となる意思決定者が変更になったことをきっかけに、Scrumチームの運用が停滞しウォータ―フォールでの管理に変更となったケースがあります。
これは、意思決定者がAgileの特性を理解せず、ウォーターフォール準拠の工程管理でのレポーティングを指示した場合や、不確実要素を全て明らかにしなければ着手承認を下さないといったマネジメントを行った場合に起こりえます。
Scrumを実施する現場には現場向けの教育（方法論とプラクティスを学ぶ研修）があるように、Agileを管理する管理者には管理者向けの教育が必要となります。デジタル領域におけるビジネスの投資判断は、ウォータ―フォールの時と同じく事業性判断を事前検討で下すことは非常に困難であり（将来の変化が激しいため）、事業性判断の検証に時間をかけてからの開発着手では市場のタイミングとしても遅すぎて勝機を逸することとなります。タイムリーにDX案件のGo/No Goの判断を実施するための勘所を理解するためのインプットがこれからの管理職には必要です。

Agile Transformationでは、このようなDX市場動向を理解し、自組織のDXを成し遂げるための必要な行動・マインドを学ぶ「管理職マインド変革研修」を提供しています。当社の研修提供については下記記事でもご紹介していますのでご参考にご覧ください。
https://www.nttdata.com/jp/ja/news/services_info/2020/111300/

新型コロナウイルスの影響が続く中で、ビジネスの推進のために多くの企業が転換点に立たされています。この変化に適用していくのにAgileは適した方法論であり、お客様がこれを正しく活用し効果を最大化できるようサポートして参ります。