アジャイルの基本原則と価値 (Jeff Sutherland 著)

アジャイル開発とは、スクラム、エクストリーム プログラミング (XP)、ダイナミック システム開発メソッド (DSDM)、および Crystal の開発者と、フィーチャ駆動型開発の代表的な提唱者、さらにソフトウェア業界のその他数人のソート リーダーで構成されるグループによって 2001 年に策定されたアジャイル宣言から派生した用語です。 アジャイル宣言は、当時の個々のアジャイル方式すべてに共通する、包括的な価値と原則を確立しました。 アジャイル宣言には、チームで高い成果を挙げるための、4 つの中核的な価値が詳述されています。

• 個人とその相互作用

• 正しく機能するソフトウェアの提供

• 顧客とのコラボレーション

• 変化への対応

これらの中核的な価値は 12 の原則によって支えられています。これらの原則については、Web サイト「Manifesto for Agile Software Development (アジャイル ソフトウェア開発のための宣言)」を参照してください。

これらの価値は、アジャイル宣言の策定者が口先だけで提唱し、すぐに忘れるようなものではありません。 これらは実用的な価値です。 これらの価値にどのように取り組むかは個々のアジャイル方式によって若干異なりますが、どの方式にも、価値を 1 つ以上高めるための固有のプロセスと手順が定められています。

個人と相互作用

個人と相互作用は、チームで高い成果を挙げるためには欠かせません。 あるプロジェクトで "コミュニケーションの飽和" について調べたところ、コミュニケーションに問題がなければ、チームは業界平均の 50 倍の実績を達成できることがわかりました。 円滑なコミュニケーションを図るため、アジャイル方式では、調査と順応のサイクルを頻繁に実施します。 このサイクルは、ペア プログラミングでは数分ごと、継続的な統合では数時間ごと、毎日のスタンドアップ ミーティングでは毎日、そして検閲と振り返りではイテレーションごとと、さまざまです。

ただし、単にフィードバックとコミュニケーションの頻度を増やすだけで、コミュニケーションの問題を解消できるわけではありません。 調査と順応のサイクルは、チーム メンバーが、次に示すような重要な姿勢を示した場合にのみ効果を発揮します。

• すべての人に対する尊敬の気持ち

• すべてのコミュニケーションにおける正直さ

• すべてのデータ、アクション、および決定の透明性

• 全員でチームを支えるという信頼感

• チームと、チームのゴールに対する貢献

このような姿勢を促すために、アジャイル管理では協力的な環境が必要になります。また、チーム コーチはこれらの姿勢を積極的に取り入れ、チーム メンバーはその姿勢を示す必要があります。 そうして初めて、チームは完全な能力を発揮できるのです。

このような姿勢を保つことは、見た目よりもはるかに難しいことです。 文化的な規範や、率直に意見を述べたために対立が起こり嫌な思いをしたという過去の経験などから、ほとんどのチームは正直さ、透明性、および信頼感を示すことを避けています。 こうした傾向を打破するために、リーダーとチーム メンバーは、建設的な対立を促進する必要があります。 そうすることで、生産性の高い行動をとれるだけでなく、他にも次のような利点が生まれます。

• プロセスの改善は、チームが組織内の障害や問題点のリストを作成し、それらに対して正面から取り組み、重要度に応じて体系的に解決していけるかどうかに左右されます。

• スクラムの名付け親である竹内氏と野中氏の調査報告にあるように、対立する考えを自由にやり取りして初めて革新が生み出されます。

• 共通のゴールに向かってチームの足並みを揃えるには、チームは対立する課題を表面化して、解決する必要があります。

• 協力して作業を行うという取り組みは、メンバーが共通のゴールに合意し、個人として、そしてチームとして向上に努めることよって初めて可能になります。

特に重要なのは、最後の取り組みについての点です。 高い価値を実現するための責任感を持ってこそ、個人もチームも熱心に取り組むようになります。これは、ソフトウェア開発チームにおいて重要な点です。 アジャイル方式では、優先度付けされた作業リストからピックアップして、自分の作業を管理し、作業方法の改善に注力するようチームに働きかけることによって、取り組みを促進します。 この方法は、アジャイル チームで成果を挙げるための原動力となる、自己組織化の基盤です。

アジャイル方式では、高い成果を挙げるチームを形成するために、プロセスやツールよりも個人と相互作用に重きを置いています。 実際、どのアジャイル方式も、調査と順応のサイクルを頻繁に繰り返すことによって、コミュニケーションと協力の活性化を目指しています。 ただし、これらのサイクルは、アジャイル チームに対する正直さ、透明性、信頼感、尊敬、責任などで成り立つ強固な基盤を構築するために、アジャイル リーダーが建設的な対立を促して初めて効果を発揮します。

包括的なドキュメントより、正しく機能するソフトウェア

正しく機能するソフトウェアは、アジャイル開発がもたらす大きな変化の 1 つです。 アジャイル宣言で表されるすべてのアジャイル方式は、正しく機能するソフトウェアを少しずつ、一定の間隔で顧客に提供することを重要視しています。

すべてのアジャイル チームは "正しく機能するソフトウェア" が何を指すかを定める必要があります。多くの場合、これは、完了の定義と呼ばれます。 高いレベルでは、1 つの機能は、その中の機能がすべてのテストに成功し、エンド ユーザーが操作できる段階になって初めて完成したことになります。 少なくとも、チームは単体テスト レベルにとどまらず、システム レベルでのテストを行う必要があります。 良いチームの場合は、1 つの機能の完了の定義の中に、統合テスト、パフォーマンス テスト、および顧客による承認テストも含めます。

CMMI レベル 5 のある企業で、数々のプロジェクトの膨大なデータを検証した結果、機能と共に承認テストを定義し、機能を連続的に優先度に従って実装し、各機能に対して承認テストを即時実行し、最優先と認識されたバグを修正することで、生産速度が一貫して倍増し、欠陥が 40% も削減されたそうです。 この企業は、既に世界で最も低い欠陥率を誇っている企業のうちの 1 つです。

アジャイル宣言では、正しく機能するソフトウェアを、チームが一定の間隔で提供できるよう推奨しています。 完了の定義について意見をまとめることは、このゴールを達成するためにアジャイル チームが行う実践的な方法の 1 つであり、これによって高い実績と高品質が実現します。

契約上の交渉より、顧客とのコラボレーション

過去 20 年間にわたり、世界中のプロジェクト成功率は 2 倍以上になりました。 プロジェクトがより小規模になり、納品がより頻繁に行われていることがその要因です。これにより、顧客は、正しく機能するソフトウェアに関するフィードバックを定期的に提供できるようになりました。 アジャイル宣言の提唱者たちは、明確な考えがあって、ソフトウェア開発プロセスに顧客を参画させることが成功に不可欠であることを主張していたのです。

アジャイル方式では、作業を支持する顧客が、開発チームと手を携えて連携することによって、この価値を高めています。 たとえば、最初のスクラム チームは、数千もの顧客を抱えていました。 その全員を製品開発に参画させることは不可能だったため、現場のすべての顧客だけではなく、管理職、営業職、サポート、クライアント サービス、およびその他の関係者を代表する製品所有者と呼ばれる顧客プロキシを選定しました。 製品所有者は、チームが正しく機能するソフトウェアをリリースする 4 週間ごとに、要件のリストを更新する責務を担っています。その際、現状と、顧客および関係者からの実際のフィードバックを考慮に入れます。 そうすることにより、顧客は、作成中のソフトウェアを具体化できるようになります。

最初の XP チームは、社内 IT プロジェクトから始まりました。 チームでの作業に、企業のエンド ユーザーにも日常的に参加してもらいました。 コンサルタントや社内チームは、およそ 1 割の確率で、日常的にチームと連携できるエンド ユーザーを見つけられます。 残り 9 割については、プロキシを立てる必要があります。 この顧客プロキシは、XP チームでは顧客と呼ばれており、エンド ユーザーと連携して、開発者が実装する必要がある機能について明記され、かつ優先度付けされたリストを提示します。

業界のデータによると、従来型のプロジェクトよりもアジャイル プロジェクトの方が世界中で平均 2 倍以上の成功率を達成している主な理由の 1 つとして、顧客 (または顧客プロキシ) との日常的な連携が挙げられます。 アジャイル方式ではこれを評価したうえで、開発チームに顧客の代理人専門の職務を設けました。

計画に従うより、変化に対応する

変化に対応することは、顧客を満足させ、ビジネス価値をもたらす製品を作成するうえで重要です。 業界のデータによると、製品やプロジェクトの要件の 60% 以上は、ソフトウェアの開発中に変わります。 本来のプロジェクトが、期限内、予算内で、かつ計画されていたすべての機能を組み込んで完了したとしても、自分が求めていたものとは違うということから、顧客が満足しないことが多々あります。 " ハンフリーの法則" によると、顧客は、正しく機能するソフトウェアを目にするまでは、自分が何を求めているかわからないそうです。 プロジェクトが終わるまで、顧客が正しく機能するソフトウェアを目にすることがなければ、顧客からのフィードバックを反映できなくなります。 アジャイル方式では、プロジェクトを通じて顧客からのフィードバックを求めるので、製品の開発を進めながら、フィードバックや新しい情報を反映できます。

すべてのアジャイル方式には、顧客や顧客プロキシからのフィードバックに基づき、定期的に計画を変更するプロセスが組み込まれています。 この計画は、最も高いビジネス価値を常に最初に提供できるよう策定されています。 価値の 80% は機能の 20% に含まれるため、従来のプロジェクトの大半では終了が遅れますが、効率の良いアジャイル プロジェクトは早期に終了する傾向があります。 その結果、顧客の満足度は高くなり、開発者も仕事を楽しめるのです。 アジャイル方式は、成功するには変化に備える必要がある、という認識に基づいています。 こうした理由から、顧客フィードバックやビジネス価値に基づいて、定期的に優先度を変えるよう策定された、検閲や振り返りのプロセスを確立したのです。

アジャイルは包括的 - 方式は実装

アジャイル開発そのものは、方式ではありません。 いくつかのアジャイル方式を説明する、包括的な用語なのです。 2001 年のアジャイル宣言の署名時には、スクラム、XP、Crystal、FDD、DSDM などの方式が含まれていました。 それ以来、有益なアジャイル方式としてリーン手法も生まれ、このトピックの下の図に示すように、アジャイル開発の傘下に入れられました。

多くのコンピューター言語が、オブジェクト指向プログラミングの中核的な機能を異なる方法で示しているのと同様に、アジャイル宣言の中核的な価値を実装するアプローチは、それぞれのアジャイル方式によって少しずつ異なります。 最近の調査によると、約 50% のアジャイル実践者がスクラムを取り入れているそうです。 残りのうち 20% は、XP コンポーネントでスクラムを実践しており、 さらに 12% は XP だけを取り入れているとのことです。 世界中のアジャイル実装の 80% 以上がスクラムか XP であるため、MSF for Agile Software Development v5.0 では、スクラムと XP の中核的なプロセスと慣例に重点を置いています。

スクラムとは、アジャイル開発プロセスのフレームワークです。 特定のエンジニアリング手法は含まれていません。 反対に、XP はエンジニアリング手法に重点を置いていますが、開発プロセスの包括的なフレームワークは含みません。 しかし、これはスクラムが特定のエンジニアリング手法を推奨していない、または XP にはプロセスがないということではありません。 たとえば、最初のスクラムは、現在 XP として知られているすべてのエンジニアリング手法を実装していました。 しかし、ソフトウェア開発向けのスクラム フレームワークは 2 ～ 3 日でチームを立ち上げるよう策定されていますが、エンジニアリング手法は多くの場合数か月かかって実装されます。 したがって、特定の手法をいつ実装するか (および実装するかどうか) は、各チームに任されているのです。 スクラムの共同提唱者である Jeff Sutherland と Ken Schwaber は、障害とプロセス改善計画のリストをすぐに作成することを、スクラム チームに推奨しています。 エンジニアリング手法が障害として識別される場合は、改善策として、XP 手法に注目します。 良いチームは、XP 手法で補完したスクラムを実践します。 スクラムは XP の規模を拡大縮小でき、XP はスクラムが効果を発揮できるようにします。

次の表に、スクラムと XP の主要用語の相互対応を示します。

参照

概念

プロジェクトの計画および追跡

その他の技術情報

MSF for Agile Software Development v5.0