アジャイル・マニフェスト：4つのコア価値と12の原則の説明

以下の画像はアジャイル・マニフェストのウェブサイトから来ており、アジャイルの4つの価値観を示しています。

Agile Manifesto and the 4 Agile Values answer what agility is

価値観の序文に示されているように、著者たちはソフトウェアを開発するより良い方法を模索し、他者を支援することを目的としていました。すべての価値は重要ですが、左側の価値が右側の価値よりも優先されます。

プロセスやツールよりも人間と対話

前述したように、アジャイル・マニフェストが発表された際、重い手法に挑戦しました。当時、能力成熟度モデル（CMM）やITILは、プロセス志向のアプローチへの人気の傾向でした。

したがって、これらの思想的リーダーが人間から始めることを選んだのは驚きです。彼らは、チーム内の適切な人材（個人）を見つけること、そして彼らが効果的に協働できるように支援すること（対話）は、特定のプロセスに従うことや特定のツールを使用することよりもはるかに重要だと信じていました。そのため、左側、すなわち「個人と対話」に重点を置いたのです。

包括的な文書よりも動作するソフトウェア

従来型またはウォーターフォール型のソフトウェア開発では、チームは要件の収集や設計・仕様の策定に多くの時間を費やし、ライフサイクルの後半になってやっと実体のあるものを構築していました。マニフェストの著者たちは、動作するソリューションを持っていることの方が、そのソリューションの仕組みを説明する大量の文書を持っていることよりも価値があると考えました。

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

3番目の価値は、契約交渉よりも顧客との協働です——ここで契約交渉とは、範囲に含まれる内容について議論することを意味します。たとえば、「それはあなたの要件文書に書いていなかった」といった発言を耳にすることがあります。これらの思想的リーダーは、顧客と共に本当に必要なソリューションを提供するために協働することが、はるかに重要だと考えました。

計画の遵守よりも変化への対応

4番目で最後のアジャイル価値は、計画の遵守よりも変化への対応です。著者たちは計画の重要性に同意しています——実際、アジャイルチームは多くの計画を立てます。しかし、これらの思想的リーダーは、情報がまだ限られているプロジェクト初期に作成された計画に固執するよりも、避けがたい変化に応じる能力の方がはるかに重要だと考えました。

マニフェスト内のこれらの価値すべてが重要ですが、左側の価値が右側の価値よりも高い優先順位を持ちます。

12のアジャイル原則

これらの4つのアジャイル価値に加えて、アジャイル・マニフェストの著者たちは12のアジャイル原則を合意し、アジャイルな働き方の基盤を形成しています。4つのアジャイル価値ほど広く知られてはいませんが、私は12のアジャイル原則の方が実用的で、アジャイル実践に対する明確な指針を提供すると考えます。

12 Agile Principles behind the Agile Manifesto

便宜上、12の原則に番号を付けましたが、公式ウェブサイトでは番号がついていません。公式ウェブサイト.

  1. 1番目の原則は最も高い優先順位顧客の満足を、価値のあるソフトウェアの早期かつ継続的な提供を通じて達成することです。『価値のあるソフトウェア』という表現に混乱する人もいますが、2001年にこれらの思想的リーダーがアジャイルの価値と原則を導入した際、彼らの焦点はソフトウェア開発に限定されていました。それ以来、アジャイルは建築、自動車製造、さらには戦闘機の生産など、ほぼすべての業界で採用されています。もし意味が明確になるなら、「価値のあるソフトウェア」の代わりに「価値のあるソリューション」を使用してください。
  2. 2番目の原則は変化する要件を受け入れる開発の後期でも。今日の多くの人々が変化を制御したり、「スコープクリープ」を管理することに注目しているが、現実には変化は避けられない。アジャイルプロセスは意思決定を先送りし、開発サイクルを短縮し、要請の迅速な分析を支援する。これによりアジャイルチームは迅速かつ低コストで対応できる。これは競争上の優位性をもたらし、アジャイル作業の主要な柱の一つである。
  3. 第3の原則は頻繁に動作するソフトウェアを提供すること数週間から数か月の間隔で、できるだけ短い期間を優先する。頻繁な提供の主な利点の一つは、顧客が本当に必要としているものを開発しているかを確認するためにフィードバックを得られることである。
  4. 第4のアジャイル原則はビジネス担当者と開発者が毎日協力することプロジェクト全体を通して。今日では、ビジネス関係者はしばしば要件書を作成し、開発者に「壁の向こうに投げて」しまう。数か月、あるいは数年後、開発者は最終テストのために解決策を依頼者に提供するが、その解決策が誤解され、正しく構築されておらず、あるいはすでに不要になっていることが判明する。この原則の重点は、解決策を構築する人々とそれを使用する人々との協働であり、このような結果を回避することにある。
  5. 第5のアジャイル原則は意欲ある個人を中心にプロジェクトを構築すること彼らが必要な環境と支援を提供し、仕事を遂行できると信頼すること。これは本質的に3つのアプローチからなる：人を empowered にし、自律性を与え、信頼すること。
  6. 第6のアジャイル原則は持続可能な開発。スポンサー、開発者、ユーザーは無限に一定のペースを維持できるべきである。私が技術プロジェクトに初めて携わった頃、プロジェクトはしばしば6か月、12か月、あるいはそれ以上に及んでいた。最初の1〜2か月でほとんど成果が出ないことが普通だった。当然のことながら、これはプロジェクト終盤にかけて膨大な負荷が集中する「クランチ期」を招いた。チームメンバーは固定された納期や範囲を満たすために、夜間や週末も働かされることが求められた。このようなプロジェクトは「デスマーチ」と呼ばれる。アジャイルは夜間や週末に働かないという意味ではないが、すべての人が持続可能なペースで作業することを強調している。
  7. 第7の原則は動作するソフトウェアが進捗の主な指標である。伝統的に、進捗は完了率で追跡されてきた。完了率は非常に信頼性が低く、特に80%や90%に達したときには判断が難しい。90%の完了状態は、実際には残りの作業や時間は10%程度であることが多い。アジャイルチームは、作業を機能や仕様に分割し、小さな単位に分け、その単位が完了したかどうかを追跡することで、完了率を避ける。このアプローチにより、誤解を招く進捗指標を回避できる。
  8. 第8の原則は、開発チームへの情報伝達およびチーム内での情報伝達において最も効果的かつ効率的な方法は対面での会話である。今日では最も一般的なコミュニケーションツールはメールかもしれない。送信者にとっては効率的である。何百、何千人にも一度にメッセージを送信できるからだ。しかし、それは本物のコミュニケーションではない。研究によると、他人の文章を読むことは大きな誤解の余地を残す。アジャイルの提唱者たちは、真の共有理解を得るには人々を一緒に集める必要があると学んだ。対面が不可能な場合は、利用可能な最高帯域幅のコミュニケーション手段を使うべきである。それはビデオ会議や電話である。SharePointにドキュメントをアップロードするよりもはるかに良い。ここでの教訓は、利用可能な最高帯域幅のコミュニケーションチャネルを使うことである。対面コミュニケーションを好むことの副次的な効果として、同じアジャイルチームのメンバーを同じ場所に集めることが理にかなっている。今日では、多くの組織がこの明らかに明らかな点を無視している。
  9. 第9の原則は継続的な注目を技術的優秀性と良い設計アジャイル性を高めるために。焦点は、手抜きや技術的負債を避けることにある。短期的には速くできるが、長期的にはコストが増えるようなことはしないこと。技術的負債を積み重ね続けると、アジャイル性を失ってしまう。これは固定スケジュールのウォーターフォール型プロジェクトでよく見られる。約束された納期を守るために、妥協が生じる。時間を節約するためにテストサイクルを短縮または削除するが、これによりリリース後の本番環境で多くの問題が発生する。その結果、緊急対応に追われる状態となり、保守が困難なコードが生まれる。
  10. 第10の原則は、シンプルさを保ち、不要な作業を排除することにある。シンプルさ——「行わない作業の量を最大化する芸術」——は不可欠である。つまり、プロセスを検討し、顧客に価値をもたらさないものをすべて排除することで、必要なものを提供しつつ、未完了の作業の量を最大化すべきである。
  11. 第10の原則は、自己組織化チームについても述べている。最高のアーキテクチャ、要件、設計は自己組織化チームから生まれる。作業に最も近い人々に、どのようにして最善の成果を出すかを決定させること——これがこの原則の本質である。
  12. 最後の原則、第12条はリトロスペクティブについてである。チームは定期的に、より効果的になる方法を振り返り、その後調整し、適応するそのように行動を調整する。

アジャイルの価値観と原則は今日ではあまり革新的には見えないかもしれませんが、2001年に発表された当時は非常に革命的でした。そのため「マニフェスト」という言葉が使われました。それらは、前世紀に組織が行ってきた方法とはまったく異なる働き方を示していました。それ以前は、ソフトウェア開発は工業時代の作業手法をほとんど模倣していました。以下で述べるように、この歴史的文脈を理解することは極めて重要です。

 

 

コメントを残す