次のプロジェクトでアジャイルワークフローを実装する方法

新しいプロジェクトを始めようとしている方は驚かれるかもしれませんが、従来の手法を使用して実施されるプロジェクトについて、6つに1つは200％のコスト超過に陥っているという統計があります。

なんと200%！ これは決して少額ではなく、予算の誤差の結果でもありません。 厳格な計画、長い変更管理プロセス、優先順位に対応できないワークフローの産物です。 変化の速い環境（特にソフトウェア開発チームや職能横断チーム）において、時代遅れのワークフローは単に非効率的であるだけでなくリスクも伴います。

そこでアジャイルワークフローの登場です。 アジャイルチームは、何もかも一度に構築してリリース時に機能することを期待するのではなく、反復的に作業を進めることで、テスト可能なインクリメントを少し生み出します。このインクリメントは、フィードバックに適応し、対象範囲の変化に合わせて進化し、無駄な労力が削減します。

このガイドでは、アジャイルワークフローの概要、従来のプロジェクト管理との比較、チームの現実的なペースに対応したワークフローの作成方法について説明します。 スクラムやかんばんのような人気のあるフレームワークに触れ、アジャイルワークフローライフサイクルを説明し、チームの高い集中力、即応力、準備状態を維持するためのヒントを共有します。

目次：

• アジャイルワークフローとは？

• アジャイルと従来のワークフローの比較

• アジャイルワークフローの作成方法

• アジャイルワークフローのメリット

• アジャイルワークフロープロセスライフサイクルのステップ

• アジャイルワークフローの種類

• アジャイルワークフロー構造の理解

• ソフトウェア開発とプロジェクト管理におけるアジャイル

• Wrikeでプロジェクトのカオスをアジャイルに変換

• よくある質問

アジャイルワークフローとは？

アジャイルワークフローは柔軟性の高い反復的なプロセスで、これを利用すれば、価値の高い少量のインクリメントで、作業の計画、実行、展開を行うことができます。 アジャイルチームワークでは、プロジェクトの終了時まで待ってから完成品を提供するのではなく、フィードバックを収集し、改善を加え、状況に適応しながら、小さな部分を継続的に提供します。

アジャイル環境でプロジェクトを管理してきた私の経験から申し上げますと、優れたワークフローは硬直的ではなく即応的です。 職能横断チームにとって十分な構造性が備わっているだけでなく、優先順位が変わった時や顧客からフィードバックが寄せられた時には方向を転換できる十分な柔軟性も備わっています。

アジャイルワークフローには通常、以下のステップが含まれています。

• 計画：チームは、多くの場合、優先順位が付けられたユーザーストーリーが豊富に含まれているプロダクトバックログを使用して、後の作業を定義します。

• 実行：スプリントチームが決められた期間（通常は1～4週間）に完了させる項目を選びます。

• レビュー：各スプリントの終了時に、担当チームが進捗を確認し、構築されたもののデモを行い、フィードバックを収集します

• 振り返り：チームは、次のスプリントで改善を行うために、うまくいったこと（うまく行かなかったこと）について反省します。

アジャイルワークフローは、協調性、適応性、現実的な顧客価値の提供などといったアジャイル原則に基づいて構築されています。 また、チームの主体性に大きく依存しています。 アジャイルにおいて、自己編成チームには、各自の作業の管理、協働での障害要因の解消、改善の継続的な反復を実施することが求められます。

適切なプロジェクト管理ツールがあれば、アジャイルワークフローはプロジェクトチームの認識を整合化し、利害関係者の関与を促し、製品開発チームが最重要事項（つまり、単に何でも迅速に構築するのではなく適切なものを構築すること）に集中できます。

アジャイルと従来のワークフローの比較

アジャイルワークフローと従来のウォーターフォールワークフローでは、プロジェクト完遂方法に大きな相違点が2つあります。

アジャイルワークフローでは柔軟性と反復が優先されますが、従来のウォーターフォールプロジェクト管理では柔軟性の低い段階的なシーケンスが実行されます。このシーケンスは、プロジェクトが一旦進行すると調整が難しくなります。

以下は上記の2つのアプローチの比較です。

アジャイルワークフローの作成方法

アジャイルワークフローの作成とは、チーム、目標、実務の進め方に適合したプロセスフローを構築することです。 アジャイルは硬直的ではありませんが、ワークフローには、全員の認識を整合化し、生産性を高め、価値提供に集中させるだけの十分な構造が必要です。

以下は一から構築する際の私のアプローチ方法です。

ステップ1：目標とワークフローの範囲を定義する

計画を立てる前に、プロジェクトの範囲、関係者、どのような状態を「完了」とみなすかを明確にしておきます。 ’がソフトウェア開発ワークフローを構築する場合でも、マーケティングスプリントを実行する場合でも、アジャイルワークフローを単なるタスクのバックログにするのではなく、実際のビジネス目標に結び付けるべきです。

また、この段階の基礎として、顧客とのコラボレーション、反復作業、変更への対応などのアジャイル原則を据えることも重要です。 ワークフローはこれらの価値観に基づいて機能すべきです。

ステップ2：プロダクトバックログを作成する

プロダクトバックログは、どのアジャイルワークフローでも中心部にあります。 チームが取り組む可能性のある事柄（ユーザーストーリー、機能、バグ、技術タスク、調査項目など）の一覧をこのログに保存できます。 アジャイルアプローチでは、早い段階ですべてを確定する従来のプロジェクト計画とは異なり、バックログはいつでも変更できます。

プロジェクトが進むにつれて、バックログも変わります。 利害関係者のフィードバック、新しい発見、顧客のフィードバックに基づいて、優先順位を変更できます。 この柔軟性こそが、アジャイルプロジェクト管理にバックログが非常に適している理由で、チームは作業の流れ全体を中断することなく迅速に調整できます。

通常、プロダクトオーナーがバックログの管理と整理を行います。 具体的な作業としては、リストの整理、承認基準の明確化、最も価値のある作業が確実に上位に上がるようにするタスクの優先順位付けなどがあります。 アジャイルでは、バックログが、チームが取り組むべき作業とその理由を示す唯一の情報源になります。 バックログを適切に管理することで、スプリントの有意義性を維持し、常に実際のビジネス目標に沿ってプロジェクトを進めることができます。

ステップ3：アジャイルフレームワークを選ぶ

チームのスタイルに合ったアジャイル手法を選択します。 スクラムは、構造化されたスプリントや定義された役割に適しています。 カンバンワークフローは、手続きの少ない継続的デリバリーに最適です。 両方を融合させることもできます。 重要なのは、チームをプロセスに合わせるのではなく、プロセスをチームに合わせることです。

ステップ4：ワークフローステージをマッピングする

計画から成果物の提供までの作業の流れを整理します。 一般的なステージには、「未着手」、「進行中」、「レビュー/QA」、「完了」などがあります。 弊社のチームでは、障害要因を可視化するために「レビュー準備完了」と「利害関係者待ち」を追加しています。 このステップにより、アジャイルプロセスフローが明確になり、タスクが行き詰まっている箇所を特定できます。

ステップ5：WIP制限とスプリントケイデンスを設定する

スクラムを使用している場合は、スプリントの長さを決定します（通常は1〜4週間程度）。 かんばんの場合は、過負荷にならないように進行中の作業（WIP）に制限を設定します。 これにより、チーム集中力が保たれ、一度に処理する作業が多すぎる混乱状態を回避できます。

ステップ6：役割と責任を割り振る

担当者（プロダクトオーナー、区スラムマスター、チームメンバーなど）と担当内容を明確に定義します。 アジャイルは、自己編成チームを奨励しますが、構造がないというわけではありません。 プロジェクトの進捗を軌道に乗せるための鍵はオーナーシップです。

ステップ7：適切なプロジェクト管理ツールを使う

バックログの管理、スプリントの追跡、タスクの割り振り、ベロシティ（速度）の監視を行うのためのスペースが必要です。 Wrikeのようなプロジェクト管理ツールを使えば、チームのコラボレーション、更新の自動化、認識の整合性の維持が可能になります。特に複数のスプリントある場合や複数のチームが参加している場合に有用です。

ステップ8：点検、適応、改善を行う

アジャイルは継続的な改善を基盤としています。 振り返り、フィードバックループ、メトリクス（累積フロー図など）を使用して、機能しているものと機能していないものを特定します。 次に、ワークフローを微調整します。 アジャイルとは理念であり、固定されたシステムではありません。

アジャイルワークフローのメリット

アジャイルワークフローは、面倒な手続きにとらわれることなく迅速に行動できる構造をチームにもたらします。

アジャイルは、小さく漸進的な進行と絶え間ないフィードバックに重点を置くことで、数ヶ月前に定義された範囲ではなく、実際の顧客のニーズに合った成果物をより容易に提供できるようにします。

ここで最大のメリットをいくつかご紹介します。

アジャイルワークフロープロセスライフサイクルのステップ

アジャイルワークフローは柔軟で反復的な構造になっているため、チームは継続的に学習と適応を行いながら、アイデアからデリバリーまで、そしてその後へと進むことができます。

以下は、製品ベースに焦点を当てた主要ステージの内訳です。

1. アイディエーション

ここからプロジェクトが始まります。 チームは機会を特定し、問題を定義し、高次のビジョンの概要をまとめます。 この本番段階では、構築する必要があるものとその理由を理解することに重点が置かれます。

2. インセプション（開始）

アイデアが固まった時点で、チームはプロジェクトの範囲を定義し、目的を整合し、成功の測定方法を決定します。 役割の割り振り、タイムラインの協議、主要リソースの特定 — これらの作業はすべて、明確な開発開始点の設定と、作業開始時の不確実性の軽減を目的としています。

3. イテレーション（反復）

作業は時間が制限されている短いサイクル（スプリントと言う）に分割されます。 各スプリント期間中、チームはバックログから項目を選び、開発、テスト、改良を行います。

目標は、各サイクルの終わりまでに作業する製品のインクリメントを生成し、フィードバックに基づいてレビューと適応を行うことで、プロジェクトが進化するにつれて継続的かつ重要な改善を行うことです。

4. リリース

数回のイテレーション（反復）後、ユーザーに対して、機能的な製品バージョンがリリースされます。 この段階では、価値提供と、未来の開発に役立つユーザーフィードバックの収集に重点を置いています。

5. 生産

この時点で製品は実際のシナリオで使用されます。 チームはパフォーマンスを監視し、問題に対処し、製品がスムーズに動作することを確認します。

6. 終了

最終的に、製品はライフサイクルの終わりを迎えます。 この段階では、製品を段階的に廃止し、必要に応じてユーザーを移行し、サポートを終了します。

アジャイルワークフローの種類

ここまでで、アジャイルワークフローによる製品ライフサイクルのサポートについて説明してきましたが、アジャイルは製品チームやソフトウェアチームに限定されません。 今ではマーケティング部門、運用部門、人事部門、さらには法務部門でも広く使用されています。 サイクルで作業を行うチームや、優先順位の変更に対処するチーム、フィードバックを重視するチームは、アジャイルアプローチのメリットを享受できます。

アジャイルワークフローにはいくつかの種類があり、それぞれが、異なるチーム構造、プロジェクトタイプ、複雑さのレベルに対応するように設計されています。 チームの作業方法、提供する製品やサービス、プロジェクトの各フェーズで必要となる構造に基づいて、適切なものを選ぶことが重要です。

スクラムワークフロー

スクラムは、最も広く使用されているアジャイルフレームワークの一つです。 作業は、スプリントという、短い固定期間のイテレーション（通常は1〜4週間）で完了します。 各スプリントには、計画、実行、レビュー、振り返りが含まれます。 スクラムチームには、プロダクトオーナー、スクラムマスター、開発チームなどの定義された役割があり、速度や継続的改善に重点が置かれています。

かんばんワークフロー

かんばんは、より視覚的でフローベースのアプローチです。 固定スプリントの代わりに、チームはバックログからタスクを引き出し、かんばんボード上で「未着手」、「進行中」、「完了」などのステージを経てタスクを移動させます。作業の流れの安定を優先し、進行中の作業を制限して集中力と成果を向上させたいチームに最適です。

例えばマーケティングチームは、コンテンツ制作やキャンペーンワークフローを管理するために、下書きからレビュー、公開までアセットを追跡するのにかんばんをよく使用します。

スクラムばん

スクラムばんはスクラムワークフローの構造とかんばんの柔軟性を融合させたものです。 チームはスプリントで作業を計画する場合もありますが、リアルタイムでのタスクの引き出しとキャパシティ管理には連続フローモデルを使用します。 このハイブリッドは、チームが従来のプロジェクト管理から移行する場合やアジャイルプラクティスを拡大する場合に役立ちます。

クリエイティブチームやデザインチームは、事前にキャンペーン業務の計画を立てる必要があるが、緊急リクエストにも対応する必要がある場合にスクラムばんをよく使用します。柔軟性を損なうことなく、計画にに十分な構造を持たせることができるためです。

エクストリームプログラミング（XP）

XPは、技術的卓越性と緊密なコラボレーションを重視するソフトウェア開発チームに向けて構築されています。 ペアプログラミング、テスト駆動開発（TDD）、頻繁なリリースなどの実践的要素が含まれています。 XPワークフローは、短い開発サイクルと絶え間ないコミュニケーションによって、高品質のコードを提供することに重点を置いています。

機能駆動開発（FDD）

FDDは、特定の機能の構築と提供を中心に開発を構造化します。 これは、敏捷性の利点を望む一方で、より多くの前提デザインとアーキテクチャを必要とする、構造化された大規模なチームに最適です。 FDDのワークフローは、スクラムやかんばんに比べると長く順序的ではありますが、適応性があります。

これらのワークフローは、反復デリバリー、チームコラボレーション、顧客フィードバックループなどのアジャイル原則に従っていますが、作業を構造化する方法がそれぞれ異なります。 重要なのは、チームのプロセスフローに合ったものを見つけることであり、フレームワークをチームの実際の運営方法に強制的に合致させることではありません。

アジャイルワークフロー構造の理解

アジャイルワークフローは、終わりのない製品バックログに蓄積されたタスクの単なるリストではありません。むしろ、アイデアから納品まで作業を進めるための構造化されたシステムです。

詳細はフレームワーク（スクラム、かんばんなど）によって異なりますが、ほとんどのアジャイルワークフローは、優先順位付けされた作業のバックログ、明確な一連のワークフローステージ（「未着手」、「進行中」、「完了」など）、意思決定の指針となる定期的なフィードバックループなど、いくつかの共通要素に従っています。

この構造が強力である理由は、可視性と柔軟性のバランスが取れているためです。 チーム全員が、進行中のもの、ブロックされているもの、次に来るものを確認できます。長いステータス会議に頼ることはなく、不要な遅延も発生しません。 プロジェクト管理ツールにおいて自動化とリアルタイム更新を組み合わせることで、チームは最も重要な作業に関して認識を整合化しながら前進できます。

ソフトウェア開発とプロジェクト管理におけるアジャイル

アジャイルがソフトウェアから始まったのには、それなりの理由があります。 アジャイルにより、開発者は、迅速に行動し、コア機能を開発し、静的な要件の代わりに実際のユーザーフィードバックに基づいた変更を行う手段を獲得しました。 新機能の開発であろうと、完全品の発売の成功であろうと、複雑で進化し続けるものを構築する際には、このような柔軟性が極めて重要になります。

しかし、アジャイルはもはやエンジニアだけのものではありません。 どの部門や機能にも適用できるプロジェクト管理原則では、アジャイルは、優先順位が変わってもチームが最重要事項に集中できるようにします。 マーケティング計画、合併や買収、製品の市場投入、採用イニシアティブなど、どのような状況においても、アジャイルは、チームの迅速な行動、より良いコラボレーション、勢いを失わない適応を実現できる柔軟な構造を提供します。

動的に計画し、一から始めることなく対象範囲を調整し、終了時だけでなくプロセス全体を通じて利害関係者を関与させ続けることができるのです。 アジャイルにより、チームは、スプリントの管理や毎日のスタンドアップミーティングの処理において、適応するための構造と改善の余地を得られます。

Wrikeを使ってプロジェクトの混乱をアジャイルに変換

従来のプロジェクトの6件に1件が予算の200%超過に陥っている場合のリスクはスケジュール遅延だけではありません。無駄な支出、勢いの喪失、チームの不満が生じるリスクもあります。 さらに、予算が以前にも増して緊縮される中で、そのエラーマージンはますます小さくなっています。

アジャイルワークフローは、速度を落とすことなく制御できる手法です。 Wrikeを使えば、プロセスをマッピングし、チームの作業をリアルタイムで追跡し、何一つ進行を妨げることなく優先順位を調整できます。 それが、理論上だけでなく、プロジェクト内、チーム間、そして現実の世界の変化の真っ只中で、アジャイルが実際に機能している時の状態です。

よくある質問