DXプロジェクト成功へのチャレンジ(3)

Planning：計画フェーズにおけるポイント

アジャイルにおいても、基本的なPDCAサイクルは適用することが可能です。重要な点としては、プロジェクトGOALを満たすための計画は明確化し、その計画を迅速化するために、確実に価値を積み上げる柔軟な計画を分けて考える点です。

アジャイル計画における構造の理解

アジャイル計画では、多数の機能リリースの作成に重点を置きます。そのため、リリース計画が基礎となり、各機能リリースのタイムライン作成が必要になります。各リリース計画は、イテレーション（反復サイクル）で構成され、イテレーションでは、プロダクトの一部設計、開発、テストが含まれます。

また、イテレーション計画は、各リリース完了に必要なイテレーション（＝スプリント）の数、各イテレーションに含まれる機能（フィーチャー）を決定します。ここで重要なのはイテレーションの内容は対象のイテレーションを実施中は変えずに終わった後の改善活動にて見直しを図ることです。ここのリズムが狂うとチームモチベーションは著しく低下します。機能（フィーチャー）は、ユーザ・ストーリーと呼ばれる要件の塊と紐づいており、ユーザストーリーを１つ１つにタスクがある構造になっております。

(図:アジャイルプロジェクトの計画構造)

アジャイル計画の目標を決めるための手法

アジャイルではプロダクト・バックログと呼ばれる、顧客が所有する「顧客の実装したい機能のリスト」をメンテナンスしていくことが重要になります。これらはユーザ・ストーリーと呼ばれる顧客の要件を簡易に示したもので構成され、事業価値の観点から、優先順位付けされます。

アジャイルにおける管理上の測定単位

管理する上においては、極力、定量的に状況を把握することが望ましいです。アジャイルにおいても管理する上でのポイントとなる管理単位を以下に示します。ストーリーポイントの決め方はプロジェクト内での議論によるルール化が必要になります。

• フィーチャー


利用者の観点から見たときのプロダクトの機能・特徴


• ストーリーポイント


作業完了に必要な全体見積もりを表すための測定単位で、チーム内で議論した手法にて、相対的に作業量を決めるもの（プロジェクトによって内容は異なる）


• ベロシティ


チームが作業を進める速度を、定められた期間（スプリント等）の中で完了できる平均作業をストーリーポイントで表したもの

Do：実行時の管理ポイント

前述の管理測定単位をもって、プロジェクトのパフォーマンスを把握するには、プロジェクトの状況や目的に沿って、適切な管理手法を取ることが必要です。以下は手法の例と適したプロジェクト内容をご紹介します。

バーンダウン・チャート　

残作業量とその作業を行うための時間の比較を視覚的に表現したものです。アジャイルのスクラムにおいては、イテレーション毎の期間は変わらないため、バーンダウン・チャートでイテレーション期間中に予定していたタスク(図上ではストーリーポイント)が終わるのかどうかを把握するのに良く使用します。

（図：バーンダウン・チャート例*）

バーンアップ・チャート

残作業量と完了作業の累積量を表記し、タスク（図上ではストーリーポイント）の総量の推移を把握するためのものです。バーンダウン・チャートが明確なGOALが分かっているものに使用されることに対して、バーンアップ・チャートは、逆に明確なGOALがないものを積み上げるのに良く使用されます。そのため、中期的なリリース計画の状況把握や予測に使われることがあります。

（図：バーンアップ・チャート例*）

ベロシティ・チャート

チームの完了率を時間軸上にグラフ化し、チームの生産性を把握するためのものです。ベロシティが価値管理をする上での重要指標となっているため、イテレーション毎のベロシティを把握し、次回以降のイテレーションにおける将来予測に有用なチャートです。

Check：監査・評価をする上でのポイント

アジャイルにおいては、PDCAサイクルを迅速に回していくことになるため、評価にもスピードが求められます。時間と労力の掛かるウォータフォール的な品質監査等は困難になるため、イテレーション毎に評価改善を繰り返し行うことが基本となります。評価は大きく２つあり、プロダクトへのレビューを実施するデモ（＝スプリントレビュー）と、チーム自身がチームのプロセスや実務慣行をレビュー・改善していく取り組みのレトロスベクティブ（＝振り返り）があります。

デモ（スプリントレビュー）　

各イテレーションの終了時にプロダクト・オーナー（≒PM）およびその他の顧客ステークホルダーと行うレビューです。プロダクトの進捗をレビューし、早期フィードバックを受け、プロダクト・オーナーはそのイテレーションで提供されたユーザ・ストーリーをレビューして受け入れます。　また、デモと名が付いている通り、実際にシステムの機能を動かして動的な確認をすることが重要視されます。そのためにも事前の計画で、動かして確認できる単位に機能（フィーチャー）を絞り込むのも必要になってきます。

レトロスペクティブ（振り返り）

アジャイルを中心的に動かすサーバントリーダー（≒スクラムマスター）が推進するチームメンバーのミーティングです。チームが独自の改善点を特定することを目的としており、チームのプロセス、実務慣行をレビューし、チームのパフォーマンスやコラボレーションを改善する方法を検討します。

Action：ありがちな問題への改善例

改善においては、プロジェクトによって千差万別であるため、ここでは良く起きる問題点（評価での指摘事項）に対する改善例を以下に示します。

PJの方向性が度々変わる

これは、アジャイルにおいて気づきにくい問題です。アジャイルでは変化に強く、顧客の要望を柔軟に取り込むことができます。ただ、単純にいつでも要件を変更して良いと捉えられ、無秩序に要望を聞いていると、PJの方向性を見失い、当初のリリース計画で予定していたPJ目標達成が困難になります。

現場においては、常に期限内に作業が終わらず、目に見える成果（機能としてのアウトプット）が減り、を作業量も見積もれず、最悪途中でPJが中止になります。この問題は経営層や顧客ステークホルダーのアジャイルに対する勘違いを是正した上で、プロダクト・バックログにおける優先順位の見直しをかけることが重要になってきます。優先順位が変われば結果的に、ストーリーポイントも変わり、ベロシティも改善されていきます。

チームメンバーの自律化がうまくいかない

アジャイルの中で最も解決が難しい問題の１つである、チームメンバーのスキル・体制・モチベーションコントロールの問題です。アジャイルにおいては、広範における各知識の保有と単一分野の深い専門性を持った”T字型人材”が求められます。一方でそのような人材は誰しもが欲しがる人材であり、なかなかに初めから潤沢に人材が揃っているプロジェクトというものも有りません。

そのため、プロジェクトの中で自らを育て上げること、あるいは周りが引き上げることが重要になっていきます。改善の一例をあげるとすれば、事業評価や人事評価の尺度を変えることがあります。モチベーションを高く維持するために、組織の目標を彼らの育成計画の先に置き、報奨も含めたインセンティブを準備することが効果的になってきます。

アジャイルそのものの手法が浸透せず、ミニWFの繰り返しになっている

アジャイルの中で最も陥りやすい問題である、ミニWF化の問題です。単なるWFを小さく、早く実行しているだけで、一見成功しているように見えるも、現場への疲弊は大きく、チームの生産性は後半に大きく下がります。この問題はおそらくシンプルで、イテレーションの期間を守らず、都度の要件変更をアジャイルの名の下に、実施中のイテレーション中に受け入れてしまうために起きる事象と考えます。

こちらの改善としては、サーバントリーダー（スクラムマスター）へのテコ入れが対策になるかと思います。アジャイルのマインドセットの理解向上の促進や、経営陣・顧客ステークホルダーの度重なる無茶な要望や計画を無視した言動等からのブロックが出来る人材を外部から召還することが最も早い対策になります。

まとめ

アジャイルプロジェクトの管理・運営におけるいくつかのポイントをPDCAサイクルをベースとして、ご紹介させていただきました。このサイクルを各メンバーが正しい理解の下、小さく速く回していくことがアジャイルの基本になるかと思います。

とはいえ、参加する各メンバーのアジャイルへの正しい理解が無いと、円滑に進むことが困難であるため、ある程度アジャイルプロジェクトの経験者で構成されていることが望ましいですが、このリソースを確保するのは中々に困難かと思っております。そのため、前提として多くの小さい失敗を受け入れる土壌、組織づくりができることが結果的には成功への近道であると日々感じております。

今まで3回にわたり、DXプロジェクトの成功における実践へのポイントのご紹介をさせていただきました。やはり実践に勝るものはないと思います。これらの記事が少しでもDXプロジェクトにチャレンジするための前向きな気持ちの一端となれれば幸いです。

ここまでのお付き合い、誠にありがとうございました。

[出典]
*Project Management Institute, Inc.『アジャイル実務ガイド』(ISBN 978-1-62825-423-5)