皆さまこんにちは。前回は“プロジェクトマネジメント”について、問題解決者として押さえるべきPMBOKと、これまで書いてきた一般的な問題解決（as-is ～ to-be）とリーンシックスシグマの進め方とマッピングして、“プロジェクトマネジメント”として追加する必要があるタスクを抽出しました。
今回は、プロジェクトマネジメントの中で、比較的新しい（といっても登場から20年以上経っていますが）“アジャイル”手法について書いてみたいと思います。
1. “アジャイル”とは？
さて“アジャイル”ですが、最近よく耳にする機会が増えているのではないかと思います。元々はシステム開発のプロジェクトマネジメント手法だったのが、最近はノンシステムのプロジェクトでも使える！という触れ込みで、認知度が上がっているのだと思われます。
“アジャイル”という言葉そのものの意味は“敏捷な、機敏な（出所：プログレッシブ英和中辞典）”といった感じなので、何となく“プロジェクトを早く進めることができる”手法と勘違いされている場合が多いように思います。
この後、説明していきますが、アジャイルというのは、要件定義おける“手戻り”を減らすことで、結果としてトータルのプロジェクト期間が短縮できる（場合もある）というもので、アジャイルを導入したから、プロジェクトのスピードが劇的に上がるのかというと、残念ながら（笑）“そんなことはない”と理解した方がよいです。
アジャイルには、様々な流派があります（笑）。
この中でも“Scrum（スクラム）”が最も一般的なので、以下スクラムを例にとって書いていきます。
アジャイルと対比される概念で、従来から存在するのが“ウォーターフォール”です。システム開発で言うと、“要件定義”⇒“設計”⇒“開発”⇒“テスト”⇒“導入”と進んでいく、お馴染みの流れです。それではここで、ウォーターフォールとアジャイル（スクラム）を比較してみます。
2. “アジャイル”の進め方
それではアジャイルの実際の進め方を、これまたウォーターフォールと対比しながら見てみます。
特徴は“Iteration (イタレーション。反復・繰り返し、程度の意味)”が複数回繰り返されることで、Iterationは“スプリント”と呼ばれます。各スプリント内で“計画”⇒“分析”⇒“設計”⇒“開発・テスト”のサイクルが回され、そのスプリントで開発した分がリリースされていきます。各スプリントの長さは1~4週間程度、2週間くらいが多いのではないかと思われます。
図3上は、スプリントは3回になっていますが、これはあくまで例で、実際の回数はプロジェクトによって決められます。もう少し言うと、“プロダクトオーナー”によって決められます。
アジャイルには“3つの役割”、“3つの成果物”、“5つのイベント”が必要になります。以下、順を追って説明していきます。
アジャイルの“3つの役割”
アジャイルの進めるに当たっては、3つの主要な役割を担うメンバーが必要です。
上図を見ていただくと分かる通り、プロダクトオーナーがキーパーソンになります。プロダクトオーナーがすべての意思決定権を持つため、それなりの職位の方がアサインされるべきですが、意思決定をするために、各スプリント間のレビューミーティング（2週間のスプリントであれば、隔週）は元より、できるだけデイリースクラム（後述）にも参加する必要があります。そのため、あまりお偉いさん過ぎても無理があります。解決策としては、お偉いさんからプロダクトオーナーにしっかり権限移譲をする、ということが大事になります。
“スクラムマスター”は、いわゆるプロジェクトマネージャー的な役割であり、チームのファシリテーターでもあります。
アジャイルの”3つの成果物“
アジャイルには、3つの主要な成果物があります。
“プロダクトバックログ”がウォーターフォールで言う“要件定義書”になります。ですので、スプリント開始前に、プロダクトバックログの内容（=スコープ）について、社内の適切なオーソリティで（ステアリングコミッティ等があればそこで）承認してもらうことが大事になります。
“スプリントバックログ”は、各スプリント開始時に、“プロダクトバックログ”の中から当該スプリント中に達成する要件を抽出したものです。抽出は“スプリント計画（後述）”時に、プロダクトオーナーと開発チームの合意のもとで行います。
“インクリメント”はいわゆる“モノ（システム開発であれば、プログラムそのもの）”ですね。
アジャイルの“5つのイベント”
先述の通り、アジャイルは“スプリント”を廻していきますが、各スプリントごとに5つのイベントがあります。
各スプリント開始時に“スプリント計画”を行い、終了時に“スプリントレビュー”と“スプリント振り返り（レトロスペクティブとも呼ばれる）”を行います。
そしてスプリント期間中は毎日15分の“デイリースクラム”を実施します。これは以前の投稿で書いた“デイリースタンドアップ”と同じものです。
3. “アジャイル”のポイント
ここまで見ていただいて、勘のいい方は気づかれたと思いますが、“プロダクトバックログ（=要件）”がどこまで達成できるか、そして全体にかかる期間は“プロダクトオーナー次第”、なのがアジャイルの特徴です。
ですので、実際にアジャイルを自社で実施するに当たっては、先述の通り、プロダクトオーナーに適切な人材をアサインし、その人材にしっかり権限移譲することが大事です。
また多くのプロジェクトの場合、そうは言ってもスコープと期間は決められている場合も多いと思います。そのため、下記の3点が、アジャイルを実際に導入するに当たって大事なポイントになると考えます。
これらのポイントを抑えておけば、アジャイルはウォーターフォールと比較しても柔軟性は高く、有効なアプローチだと思います。あとは適用するプロジェクトですね。モバイルアプリ等の“小出し”にできるものには最適だと思います。半面、基幹系のミッションクリティカルなシステム等は、やはりウォーターフォールで進めた方が堅いと思います。
・“プロダクトバックログ（=要件）“は、社内の適切なオーソリティ（ステアリングコミッティ等）で承認し、プロダクトオーナーはこれを守るものとする
・プロジェクト全体スケジュール（完了予定日）も、社内の適切なオーソリティで承認し、プロダクトオーナーはこれを守るものとする
・スプリント期間中であっても、“プロダクトバックログ”に大きな変更（コストにはねるような変更）があった場合には、社内の適切なオーソリティの承認を得る
今回はこのくらいにさせていただき、また次回以降、続けていきたいと思います。 最後まで読んでいただき、ありがとうございました。