アジャイル・プロジェクト管理とは

トラック上のフェラーリF1カーレース
Dan Nosowitz

Staff Writer, Automation & ITOps

IBM Think

アジャイル・プロジェクト管理とは

アジャイル・プロジェクト管理とは、主に製品やソフトウェア開発における個々の取り組みに対するアプローチであり、協働、反復型開発、柔軟性、適応性、継続的改善というアジャイルの原則に基づきます。プロジェクトの目標(スケジュール、リソース、目的、チーム)の管理はアジャイルの観点から行われ、スクラム、カンバン、リーンなど複数の異なるフレームワークのいずれかを含む場合があります。

アジャイル・プロジェクト管理は、グループ化した場合、アジャイルの原則に従って管理できるプログラムを形成できます。グループ化されたプログラムは、入れ子人形のようにポートフォリオを形成できます。

アジャイルというアプローチは、2001年にソフトウェア・エンジニアのグループがアジャイル・マニフェストを発表したことで誕生しました。アジャイル・マニフェストには、4つの重要な価値観と12の原則があります。重要な価値観は次のとおりです。

  • プロセスとツールよりも個人と対話を重視
  • 包括的なドキュメントよりも機能するソフトウェアを重視
  • 契約交渉よりも顧客との協働を重視
  • 計画に従うことよりも変化に対応することを重視

望ましい価値観は、望ましくないものの放棄を必要としません。たとえば、アジャイルの哲学では、計画の使用を禁止するのではなく、避けられない変化への対応と準備に重点が置かれています。

その名のとおり、アジャイル・プロジェクト管理は、頻繁に変化する要件が満載の世界で運用できるように設計されています。プロジェクトの開始前にプロジェクトの各ステップを綿密に計画するのではなく、プロジェクトを迅速に作成し、定期的にレビューし、チームや顧客の対応に応じて話し合いをして、変更を行います。

計画とアプローチは変更する必要があり、当初の計画に隷従する必要はないことが最初に想定されます。他のアプローチのように厳格な階層構造がなく、個々のチームメンバーに発言する権限が与えられます。

The DX Leaders

AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。

ご登録いただきありがとうございます。

ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。

アジャイルとウォーターフォール

アジャイルとウォーターフォールは、最も一般的なプロジェクト管理哲学の2つで、まったく異なるアプローチを表しています。

ウォーターフォールは、1970 年に初めて詳細に説明された(PDF)、連続的で高度に構造化された手法です。ウォーターフォールでは、プロジェクトの開始前にプロジェクトのステップが列挙され、各ステップが完了してから次のステップに移ります。興味深いことに、コンピューター科学者のウィンストン・ロイスが1970年に発表した論文には、ウォーターフォール方式に対する批判が含まれていました(さらに興味深いことがあります。ロイスの息子であるウォーカー・ロイスは、IBMのチーフ・ソフトウェア・エコノミストであり、プロジェクト・マネジメントについて何冊かの本を書いています)。

アジャイルでは別のアプローチを採用しており、反復的で変更可能、適応性のある進歩を重視します。プロジェクトのライフサイクル全体を最初から知ることは不可能であり、今後も知ることはないだろうということを理解し、受け入れて、その現実に合わせてレビューやスプリントなどのツールを実装します。

アジャイル・プロジェクト管理の主要な機能

アジャイル・プロジェクト管理は、特定の方法論というよりも、幅広い原則に基づいた哲学です。しかし、ほとんどのアジャイル・プロジェクトに共通する主要な機能がいくつかあります。

ノートPCで作業しているアナリストの手のクローズアップと、その上にあるビジネス分析チャート

エンタープライズ・アジャイル・プランニングで価値創造に注力する

戦略とデリバリーを整合させて、アジャイル運用を強化・拡張する上で役立つ、エンタープライズ・アジャイル・プランニングの変革力をご紹介します。

反復

アジャイルの最も重要な要素の1つは、反復を利用することです。これは、アジャイル・マニフェストの元々の 4 つの主要な価値観の1つである、実用的なソフトウェアの開発に結びついています。アジャイルでは、作業はより小さく、管理しやすい部分に分割され、迅速に完了し、頻繁にレビューされます。利害関係者とのレビュー・セッションに応じて、個々の部品が、場合によっては劇的に変化することが了解されています。

レビュー

レビューはアジャイルの重要な部分であり、反復による継続的な改善のための定期的なフィードバックになります。使用する特定のフレームワークによって異なりますが、アジャイルのすべてのバージョンで定期的かつ頻繁なレビュー・セッションが行われています。レビュー・セッションでは、意思決定が上から「流れ」るウォーターフォールのような、より階層的なモデルとは対照的に、すべての参加者が発言するよう奨励され、権限が与えられます。

コラボレーション

アジャイルは分野を超えた協働を優先し、組織全体の利害関係者と幅広く協働する複数のスキルを持つチーム・メンバーを高く評価します。アジャイルでは、開発者は製品開発中にチーム内の他のメンバーの存在を完全に無視して、自分たちだけで閉じこもったりはしません。その代わり、定期的なレビューにはあらゆる種類の利害関係者が関わります。

たとえば、アジャイルの原則を新しい演習アプリに適用してみましょう。アプリを作成する開発者は、設計者、フィットネスの専門家、マーケティング担当者、営業担当者、プログラム・マネージャーと頻繁に共同作業する必要もあります。必要な利害関係者をすべて受け入れることで、開発者は高品質の成果を得るために重要なフィードバックを取り入れることができます。

チーム構成

ウォーターフォールなど、古いプロジェクトや従来のプロジェクト管理システムでは、全員がタスクを継続するために、厳格な階層が続いています。プロジェクト・マネージャーがタスクを割り当て、専門の作業者が個々のタスクを完了し、全員が自分の役割に留まります。

このような方法は、サイロを生み出し、権限が縮小され、発言する立場にないと感じるチーム・メンバーの潜在的に生産的なフィードバックが封印される可能性があります。

アジャイル・モデルでは、チームは通常、小規模で自己組織化されており、複数の部門に頼ります。各チーム・メンバーはプロジェクトに対するオーナーシップをより強く感じ、必要なところで協力できるようになります。

人気のあるアジャイル・プロジェクト管理フレームワーク

アジャイル・プロジェクト管理フレームワークは、アジャイルの原則に従った構造を提供します。すべてのフレームワークがすべてのプロジェクトに適しているわけではないため、最も適切なものを選択することが重要です。

スクラム

おそらく、アジャイル・コンセプトの中で最も人気のあるスクラムは、チーム・メンバー全員が同時に力を合わせて1つのプレーに集中するラグビーというスポーツから生まれたものです。アジャイルの文脈では、スクラムは通常1~4週間の固定長の反復スプリントに依存していますが、チームワークの概念は残っています。

これらのスプリントは、次のスプリントで取り組む製品バックログのタスクと成果物を決定するための共同計画から始まります。このスプリント計画は、スクラム・チームがアジャイル手法を遵守し続ける責任を負う、リーダーというよりも教師であるスクラム・マスターまたはプロダクト・オーナーによって主導される場合があります。その後、チームは毎日短時間集まり、15 分以内の毎日のスクラムを行い、障害や問題点を特定します。これらの毎日の立ちミーティングは、潜在的な問題を発見するために不可欠ですが、できるだけ簡潔にする必要があります。

各スプリントの最後の、いわゆるスプリントの振り返りでは、チームは開発チーム外の利害関係者と完了した作業を確認し、潜在的な問題や変更の要素を特定します。

かんばん

カンバンはワークフローを視覚的に表現したもので、従来はボード上に分類されたポストイットの形式でした(紙媒体を避けたい人のために、デジタル版もたくさんあります)。

カンバンボードには、ほとんどの場合、次の3つの列が含まれます。

やるべきこと:まだ開始されていないタスク

進行中:個人またはサブチームが現在取り組んでいる内容

完了: 個々のタスクが完了

しかし、これは決まったわけではありません。プロジェクトによっては、「テスト」、「コンプライアンス」、「アイデア」などの他の列が必要になる場合があります。

各列には、紙またはデジタル付箋に書かれた個別のタスクがあります。演習アプリの例では、「”お気に入りの演習リスト”の作成」、「説明動画の追加」、「機能の実装」などのメモが含まれることがあります。各タスクが完了すると、その付箋は物理的に(またはデジタル的に)列から列へと移動し、すべてのタスクが完了するまで続きます。

Lean

正確にはアジャイル・フレームワークではありませんが、リーンはアジャイル・プロジェクトに適用できる関連手法です。製造業で生まれたリーンは、無駄、文書化、過剰生産、断片化を削減することに重点を置いています。この組み合わせは、リーン・アジャイルと呼ばれることもあります。リーン・アジャイルでは、価値の特定を優先します。価値のストリームマッピングと呼ばれる視覚的な表現を使用する場合もあり、これはボトルネックや非効率性の特定に役立ちます。

Scaled Agile Framework(SAFe)

大規模アジャイル・フレームワーク(SAFe:Scaled Agile Framework)とは、組織がエンタープライズ規模でアジャイル・モデルを実装できるように設計された、組織およびワークフローの原則、プラクティス、およびコンピテンシーに関する知識ベースです。SAFeの場合、アジャイル・チームはスクラムやその他の方法を使用して通常作業を行います。複数のチームが連携してアジャイル・リリース・トレーニング(ART)を構成し、部門横断的に連携して定期的に増分ソリューションを提供します。ARTは2週間ごとにデモのためにミーティングを開き、次のスプリントで実装するコメントと提案を作成します。SAFe には、多くのアジャイル手法とプラクティスが組み込まれており、大規模な組織を軌道に乗せるためのいくつかの機能も追加されています。

アジャイル・プロジェクト管理のメリット

アジャイル・プロジェクト管理は、特にソフトウェアとテクノロジーの分野で人気が高まっています。今日では、賢明な選択をすることの価値を多くの人が認識しています。2025年の調査(PDF)では、単純で複雑でない予測可能なプロジェクトにはウォーターフォール式が依然として最適であることがわかりました。この調査では、複雑なプロジェクトや頻繁に変更するプロジェクトには、アジャイル・プロジェクト管理が優れていることも判明しました。中には、ハイブリッド・アプローチを好むアナリストもいます。「混合アプローチにより、組織は最適なバランスを実現し、最終目標を見失うことなく予期せぬ課題に機敏に対応できるようになります」とアントニオ・ニエト・ロドリゲスはHarvard Business Reviewに書いています。

速度の向上

アジャイル・プロジェクト管理には、最小実行可能製品(MVP)に重点が置かれています。リーン、SAFe、またはその他の手法のいずれを使用しているかにかかわらず、アジャイル・プロセスでは、スプリントの終わりに機能デモを実施することが重視されています。ソフトウェアでは、これによって消費者へのリリースを迅速化し、プロジェクトの進行に応じて段階的な更新を行うことができる。

適応性

アジャイルな考え方では、プロジェクトは変更される可能性があるだけでなく、変更されることが最初から想定されています。適応性は、個別のタスクとプロジェクト、および定期的なレビューセッションを含むアジャイル手法に組み込まれています。各レビューでは、チームと利害関係者は、社内または顧客からのフィードバックがあれば報告することが奨励され、チームはそのフィードバックを次のスプリントに取り入れることができます。目標は顧客満足であり、計画の遵守ではありません。

効率性

お客様事例では、アジャイルの実践により効率性と生産性が向上することが示されています。アリゾナ州立大学では、IT部門がテンプレートと協働を通じてプロジェクト計画を標準化するアジャイル手法を導入しました。ASUは特に、無駄と重複を削減するリーン原則を組み込むツールを使用しました。彼らのアプローチは、スケーラブルで再現性のある新しいシステムの作成に成功し、大学全体の他のチームも新しい手法を採用し始めています。

コラボレーションとコミュニケーション

アジャイルは、通常より多くの利害関係者を含むオープンで効率的かつ強力なコミュニケーションを実現します。この部門横断的な性質により、組織内のさまざまな部門の代表者がスクラム後の議論に参加します。このように、アジャイルは大規模な組織で問題になる可能性のあるサイロの解体に役立ちます。

アジャイル・グループの分散化された性質は、多様なスキルと柔軟性を重視し、チーム・メンバーがそれぞれのスキルを最適な方法で発揮できるようにします。チームも自己組織化されており、上から指示された計画ではなく、独自の専門知識に従ってスプリントを実施する自主性を持っています。

アジャイル・プロジェクト管理の課題

アジャイル・プロジェクト管理には多くのメリットがありますが、潜在的な欠点や状況においては、アジャイルが理想的ではない場合や、組織のニーズに最適な状態に調整する必要があるかもしれません。

予測不可能性

プロジェクトのライフサイクル全体を通じて反復的なアプローチ、継続的な改善、頻繁なリリースを行っているため、プロジェクトがいつ「完了」するか、またはどのくらいのコストがかかるかを予測することが困難になる場合があります。ウォーターフォール型システムのような厳格なロードマップには、単純な合否の測定基準があります。製品が期限までに完成するか、そうでないかのどちらかです。アジャイルでは、プロジェクトは継続的な作業と改善の過程にあります。

予測できないことは課題になるかもしれませんが、アジャイルは、本質的に混沌としたプロジェクト・サイクルを形成しようとする方法ではなく、現実に対処する方法になる場合があります。ある意味、アジャイル手法は混乱に対処するための最も効果的な方法であるため、単に混乱と関連付けられるのかもしれません。

スコープ・クリープ

組織全体からのインプットが増え、アジャイルのスプリントの適応性が高まると、スコープ・クリープ(要件の追加変更の発生)の状態に陥りやすくなります。プロジェクトがゆっくりと、しかし確実に、意図したものとは異なる、より大きなものへと成長するにつれて、チームは機能を継続的に追加し、二次的、三次的な問題に取り組んでいく可能性があります。

この問題に対処するには、スコープ・クリープに定期的に対処する必要があります。新しい機能は、必須または過剰であるものとして評価されなければなりません。

文化適合

アジャイル・プロジェクト管理手法は、部門横断的、自律的、自発的なチーム・メンバーに最適です。個々のチームは自己組織化されており、チーム・メンバーはさまざまな職務を遂行するよう求められる場合があります。この機敏性には、特定の柔軟な考え方が必要であり、すべてのチーム・メンバーがそのような条件下で最もよく機能するわけではありません。有能なチーム・リーダーは、アジャイル環境の中で調整し、前進するための方法をチームに教えることができます。

ノートPCで作業しているアナリストの手のクローズアップと、その上にあるビジネス分析チャート

エンタープライズ・アジャイル・プランニングで価値創造に注力する

戦略とデリバリーを整合させて、アジャイル運用を強化・拡張する上で役立つ、エンタープライズ・アジャイル・プランニングの変革力をご紹介します。

電子書籍を読む