スクラムを利用したアジャイルプロジェクトマネジメント： 機会と挑戦

1.　序論

　近年では，アジャイルプロジェクトマネジメントの導入により顧客満足度の向上やチーム結束力の強化に繋がったという成功事例が多く出てきています．本記事では，アジャイル手法の一種であり，プロジェクトに対して反復的かつ段階的なアプローチを取る「スクラム」というフレームワークを紹介します[1]．
　1986年に竹内弘高氏と野中郁次郎氏がハーバード・ビジネス・レビューに「The New New Product Development Game」という論文を発表しました[2]．この論文で紹介された自己組織化チームの概念は現代のスクラムフレームワークの基盤となっています．　プロジェクトの制約条件として良く知られているものとして「コスト」「スケジュール」「スコープ」があります．従来のウォーターフォールモデルでは，プロジェクトの初期段階においてこれらの制約条件が全て定められており，変更は限られた範囲でしか発生しないように管理されます．プロジェクトの失敗事例として，最もよくある原因として実際のスコープが計画から乖離すること，つまり「スコープクリープ」によるものです．一方，アジャイルモデルではコストとスケジュールが定められていますが，スコープはプロジェクトの進行につれて変化することが前提となるため，そもそもスコープクリープの恐れがないとも言えます．
　スコープ面で柔軟性が不可欠なプロジェクトにはアジャイルモデルが適しています．
　それでは次にスクラムの要素と仕組みについて，説明します．

2.　スクラム

スクラムフレームワーク（図 6-1）には以下の要素が含まれています．
　　・役割：スクラムマスター，スクラムプロダクトオーナー，スクラムチーム
　　・スクラムプロダクトバックログ
　　・スプリント
　　・スクラムイベント：スプリント計画ミーティング（WHATミーティング，HOWミーティング），
　　　デイリースクラムミーティング等 [3]

「スプリント」（「イテレーション」とも呼ばれます）とはあるまとまった単位のタスクを実行する時間の単位（通常2～4週間）のことを指します．イテレーションや最終成果物の規模から，通常では一つのプロジェクトに複数のスプリントが設けられます [3]．
　各役割の説明は以下の通りです．

　・スクラムチーム：要件分析とタスクの設定，スプリントバックログの作成などを行います．補足としてスクラムチームの特徴や利点を表6-1にまとめました．
　・スクラムマスター：チームリーダーやチームが目標達成へ向けて活動に積極的に取り組んでいることや有効なコミュニケーションを取れるような環境の整備，チームが直面する問題の解決，メンバーへの指示などの役割を果たします．
　・スクラムプロダクトオーナー：プロジェクトのライフサイクルにわたってチームの活動をコーディネートし，チームが顧客要件を理解した上で正しくタスクを実行している状態を保ちます．スクラムプロダクトバックログの内容のマネジメント権限を持ちます．

　スクラムプロダクトバックログはエンドユーザーの要求を含む残作業のことです．各スプリント計画ミーティングにおいて，プロダクトオーナーが優先度の高い項目を説明し，チームが次のスプリントで実施する項目を決めます．実施項目が決まり次第，チームメンバーがタスクの進捗状況をトレースできるようにするためにスプリントバックログを作成します．スクラムプロダクトバックログの最も重要な特徴の一つは，どの項目においても顧客にとっての価値となることです．要件変更はチームが次のスプリントを計画する時のみに行われ，スプリントの途中でタスクの追加や変更は原則行わないことが特徴です．
　私が個人的に推奨したい活動が，スクラムのコンポーネントの一つであるデイリースタンドアップミーティングです．このミーティングは文字通り毎日，参加者全員が立ったまま会議を行い，プロジェクトチームのメンバーが昨日何をできたか，今日は何をするつもりか，そしてパフォーマンスを妨げる問題は何かなどについて15分ほど議論します．デイリースタンドアップミーティングはチームの透明性を促進し，問題の発生を抑えながらタスクを遂行するのに有効だと思います．
　チームのパフォーマンスはバーンダウンチャートの形式でトレースできます（図6-2） [4]．バーンダウンチャートにおいて，計画されたタスクと完成されたタスクが可視化されます．例えば，プロジェクトの初期段階にチームはプロジェクトを遂行するために50ポイント（ストーリーポイントとも呼ばれ，作業量を表す架空の単位）が必要と見積もっています．プロジェクトは10スプリントにより構成され，スプリントごとに5ポイントを完成する必要があります．スプリントが終わり次第，未完成分のポイントは図6-2のようにバーンダウンチャートに記録することができます．

3.　結論

　スクラムフレームワークは生産性・プロダクトの品質・チームの士気を向上させることに加え，最終的には顧客に価値を提供し，顧客満足度の向上に繋げることができると考えています．IoEビジネス部は構造計画研究所のコアバリューを徹底的に追求し，限られた期間において最大限の価値を生み出すためにスクラムでのプロジェクト運営を実施し始めています．
　このフレームワークのもう一つの利点として，プロジェクトごとに人数や実施方法を柔軟に変更できることがあります．例えばスクラムが５～９人のチームによるプロジェクトにしか適用できないわけでなく，より多くの人的リソースを必要とするプロジェクトにも適用できます．大規模なプロジェクトでは，プロジェクトのチームを複数のスクラムチームに分け，それぞれに一部の作業を担当させることができます．この場合はスクラムのガイドラインや原則は変えずに全てのチームに浸透することが重要です．また，必要に応じてウォーターフォールモデルと組み合わせてハイブリッドフレームワークも構築できます．私たちは，ウォーターフォール，アジャイル，ハイブリッドフレームワークが適用できる様々なプロジェクトの経験があります．プロジェクトのスコープやイテレーションに多くの変更を必要とする場合，スクラムのようなアジャイル型のプロジェクト管理を実施すべきだと思います． 例えば，システム開発プロジェクトにはウォーターフォールモデルを適用し，データ分析プロジェクトをアジャイルモデルで実施，分析コンサルティングとシステム開発両方含めたプロジェクトをハイブリッドモデルで実施するなど，プロジェクトの特性によって最適なマネジメント手法を選択することで，限られた時間と予算でより高い品質で顧客のニーズを実現することを目指しています．

〔参考文献〕

[1] Essential Scrum: A Practical Guide to the Most Popular Agile Process, Rubin, K.S., 2012

[2] Harvard Business Review, Vol. 64, No. 1. (January/February 1986), pp. 137-146 　

[3] Agile Project Management with Scrum, Ken Schwaber, 2004

[4] Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition,
Lyssa Adkins, 2010