プロジェクト管理に携わる方なら、企業が変わり続ける環境に対応していく必要があり、従来のプロジェクト管理手法では対応しきれないこともあることをご存知でしょう。多くの企業は、よりリーンで迅速かつ実験的な方法で生産を推進することで優位性を保っています。

こうした状況で役立つのが、アジャイル手法です。

アジャイル手法に決まった定義はなく、どちらかといえばプロジェクトに取り組む際の考え方や方法を指す方法論です。アジャイル手法では、計画を立ててデリバリーや発売期日に向かって進むのではなく、開発プロセスを反復的なステップに分割し、プロジェクトのライフサイクルを通した柔軟性、テストと変更を実現します。

アジャイル手法とは何か？アジャイル方法論の概要と種類、チームでこれらの原則を適用する方法を詳しく確認しましょう。アジャイルフレームワークのテンプレートもご紹介します。

アジャイル手法とは？

アジャイル手法とは、連続するフェーズ形式での作業を排し、さまざまな部門で同時に、徐々に作業を進めていく手法です。チームは、通常2週間のスプリントで集中して作業を進めます。プロジェクト過程ではさまざまなチェックポイントが設けられ、チームは必要に応じて方向性を変えることができます。プロジェクトの状態を継続的に把握することで、よりよい最終製品を提供できるようになります。

では、伝統的なウォーターフォール方式などの管理スタイルでなく、アジャイルを選択する理由はどこにあるのでしょう。

製品管理・戦略コンサルタントの Scott Sehlhorst 氏は次のように説明しています。

「アジャイルであることが大きな価値を生む状況には3つあり、それぞれの状況において重要な利益が得られます。チームメンバーは、自分の仕事に対するフィードバックを得て、自分が作ったものが及ぼす影響を理解することで、個人として本質的な利益を得ることができます。エンジニアリング組織は、オペレーションの効率化に加え、価値の提供における効率を全体的に高められるようになります。会社全体としては、市場における変化に適応しやすくなり、効率の向上と新たに生まれた機敏な対応力を武器に、競争力を高めることができます。」

アジャイルの仕組み

アジャイル方法論を実践するのは非常に簡単です。意識せずにアジャイルの手法をすでに取り入れている場合も多く、ToDo リストの作成、優先順位付け、短期集中で作業に取り組むといった要素には多少なりとも馴染みがあることでしょう。アジャイル手法は、いわば、ToDo リストを詳細に作り込み、整理したバージョンに過ぎないのです。

ステップ1 : 機能や必須項目のリストを作ります。このステップでは、顧客や主要なステークホルダーと一緒にプロジェクトの特徴や優先順位を確認します。ソフトウェア開発の場合には、多くのチームが以下の MoSCoW ルールで開発の初期段階で盛り込む項目や機能を決めています。

• Must have (必須)
• Should have (推奨)
• Could have (可能)
• Won’t have time now, but later (先送り)

ステップ2 : 各機能や項目の完成までにかかる時間を見積もります。最も重要な項目が最初に完了するように優先順位を設定します。

ステップ3 : 最初に取り組む機能、テスト用の製品をリリースできる時期、フィードバックをイテレーションに反映させるスケジュールを決めます。作業の進行に合わせて計画を調整し、参加者全員にとってプロジェクトのペースやリズムが妥当なものか、調整が必要かを判定します。

アジャイル手法の主な価値

アジャイル手法のフレームワークは多種多様ですが、いくつかの主要な原則は共通しています。中でも重要なのが、以下のアジャイルソフトウェア開発宣言の12の原則です。

1. 早く継続的なソフトウェア提供を通じて顧客満足度を向上
2. 開発プロセスを通じて変化する要求へ対応
3. 機能するソフトウェアを頻繁に提供
4. ビジネス側の人と開発者がプロジェクトを通して協業
5. 関係者に対するサポートと信頼、モチベーションの向上
6. フェイス・トゥ・フェイスでの交流を実現
7. 機能するソフトウェアが進歩の最も重要な尺度
8. 一貫した開発ペースをアジャイルプロセスで支援
9. 技術的なディテールや設計へのこだわりでアジリティを向上
10. シンプルさ
11. 自己組織化されたチームが優れたアーキテクチャ、要件、設計を促進
12. 定期的な振り返りで効率を向上

この12の原則は、アジャイルの4つの主要な価値に基づいたものです。

プロセスやツールよりも個人との対話を

アジャイル手法の実装は、いずれも、小規模なチームが独立して、または協働してプロジェクトを完遂させることが基盤となっています。こうした環境では、チームメンバーは受動的なコミュニケーションよりも対面でのやり取りを重視し、トップダウンの指示や指導に頼らず、一人ひとりの参加者がプロセスを通じて決定権を持てるようになります。

包括的なドキュメントよりも機能するソフトウェアを

どんな研究、事実調査や実世界調査であっても、実際に機能する製品には勝てません。製品の複数のイテレーションの開発、リリースと継続的なテストに注力することで、チームはリアルタイムで問題に対応し、修正を加えて、最終的により洗練された最終バージョンに仕上げることができます。

計画に従うよりも変化への対応を

プロジェクトは通常、一連の成果物について合意した作業範囲の決定から始まります。この作業範囲はプロジェクト全体のコンテキストや基準点となるものですが、ステークホルダー間の対話ではこれに縛られず、開発プロセスを通じてオープンに話し合い、必要に応じて調整を加えることで、アジャイル手法の真髄を実践し、よりよい最終製品を完成させられるようになります。

契約交渉よりも顧客との協調を

アジャイル手法では、フィードバックや課題の出現に合わせて軌道修正ができます。発売日以降になって始めてバグに対応するのではなく、継続的に製品のバージョンをリリースし、ユーザーによる実際のテストを経て、特定した問題を修正していけるようになります。

アジャイル手法の種類

開発やプロジェクト管理に使えるアジャイルのフレームワークは多数ありますが、ここでは、アジャイル手法に基づくさまざまな種類のフレームワークを概説します。

スクラム手法

スクラム方法論 は、継続的なフィードバック、自己管理、少人数のチーム、スプリント (2週間の集中期間) に分かれた作業を基盤としたものです。

スプリントは計画ミーティングから始まります。このミーティングでは、2週間の間にチームがどのようなタスクを達成するかを決めます。また、通常、目標に対する進捗状況を確認する短時間のチームミーティングを毎日行います。スプリントの終了後には振り返りミーティングを行い、達成できた内容と次回以降改善できる内容を議論します。

カンバン手法

カンバン手法は、元々日本の製造業でプロジェクトの指示伝達の手段として考案されたもので、チームが優先すべき項目を確認でき、同時にタスクを抱えすぎることを避けられるよう、作業項目を関連付けて提示する戦略です。

エクストリーム・プログラミング (XP) 手法

XP 法と呼ばれる顧客満足度を重視したフレームワークで、遠い将来に完全なアップデートを提供するのではなく、顧客が必要としている機能を提供することを目指すものです。このため、XP 手法では以下の点も重視しています。

• 顧客やチームメンバーとの絶え間ないコミュニケーション
• 短いサイクルでの頻繁なリリース
• 顧客によるテストとフィードバックのためのチェックポイント
• シンプルなソフトウェア設計

クリスタル手法

クリスタルは、チームの規模やプロジェクトの優先順位に応じて拡張できるアジャイル手法で、基本的な流れは以下の3つのフェーズで構成されており、それぞれに小さなタスクがあります。

• 憲章の制定 : 開発チームを結成し、プロジェクトの実現可能性を判断して開発方法を固めます。
• 周期的デリバリー : アップデートとリリースの計画を構築し、テストのイテレーションを統合してユーザーに製品を提供します。
• まとめ : デプロイを行い、開発後のレビューと振り返りを行います。

動的システム開発手法 (DSDM)

DSDM はユーザー主導型で、製品の提供を頻繁に行い、チームに意思決定権を与えるなど、積極的な参加が終始求められる手法であり、以下のフェーズで構成されています。

• プレプロジェクト
• フィージビリティスタディ
• ビジネススタディ
• 機能モデルのイテレーション
• 設計とビルドのイテレーション
• 実装
• ポストプロジェクト

機能駆動開発手法 (FDD)

FDD 手法は、短く具体的な作業フェーズを特定し、機能の構築と設計に焦点を当てるもので、以下のステップに分かれています。

• ドメインオブジェクトモデリング
• 機能別開発
• コンポーネント/クラスのオーナーシップ
• 機能チーム
• 検査
• 構成管理
• 通常の構築
• 進捗状況と成果の可視化

アジャイルのフレームワークを運用やその他のプロジェクト計画に応用することで、チームの効率や柔軟性に大きな変化が生まれる可能性があります。チャンスを積極的に受け入れ、プロジェクトのライフサイクルを通じて顧客からのフィードバックを取り込み、一人ひとりの参加者が主体的に行動できるよう支援することで、イノベーションを促進する軽快なプロセスを生み出すことができます。