アジャイル開発

アジャイル開発とは、短いイテレーションで作業を進め、フィードバックを継続的に取り入れ、理解が深まるにつれて計画を適応させていくソフトウェア開発手法です。2001年に発表されたアジャイルマニフェストでは、プロセスやツールよりも個人と対話、包括的なドキュメントよりも動作するソフトウェア、契約交渉よりも顧客との協働、計画に従うことよりも変化への対応という4つの価値観が掲げられました。

このマニフェストの表現は、しばしば重要な点で誤って引用される。それぞれの記述は、どちらも価値のある二つの事柄のうち、どちらか一方を優先するものであり、後者を否定するものではない。この文書は、右側の項目にも価値があるものの、左側の項目の方がより価値があると明言している。マニフェストを文書化、計画、契約を禁止するものと解釈する実施方法は、マニフェストの記述の半分を無視しており、批評家がアプローチそのものに起因すると考えるような混乱を招くのが常である。

その根底にあるのは不確実性に関する考え方です。逐次開発は、要件を事前に正確に定義できるという前提に基づいています。これは、問題が十分に理解されている場合には当てはまりますが、製品の価値が人々の反応に左右される場合には当てはまりません。反復的な開発は、意思決定からその証拠を得るまでの期間を短縮することで、誤りを犯した場合のコストを削減します。これは、問題の不確実性の高さに比例して価値が高まります。

実践において最もよくある失敗は、原則を伴わずに儀式だけを採用してしまうことです。組織は、固定されたスコープ、固定された期限、年間計画を維持し、フィードバックに基づいて行動する仕組みがないまま、毎日のミーティング、イテレーションの境界、見積もり手法を導入します。その結果、2週間単位で追加のミーティングを伴う逐次的な開発が行われ、どちらのアプローチも適切に行われた場合よりも時間がかかり、この方法論に対する広範な懐疑論を生み出します。

顧客との協働は、組織にとって最も難しく、最も頻繁に省略される要素です。フィードバックに対応するには、実際にフィードバックを得る必要があり、そのためには、実際のユーザーが定期的に動作するソフトウェアを利用することが不可欠です。社内関係者や文書化された仕様など、何らかの代理情報に基づいて作業するチームは、目的となるインプットがないまま反復作業を進め、誰も検証していない方向に自信を持って反復作業を進めてしまいます。

規模拡大は、当初の構想では対処されていなかった真の困難をもたらします。なぜなら、マニフェストは小規模な同一拠点チームを想定して書かれたものだからです。1つの製品で多数のチームを調整するには、連携、依存関係の管理、アーキテクチャの一貫性を確保するための仕組みが必要であり、これに対処する様々なスケーリングフレームワークは、本来削減しようとしていたプロセス負荷を再び高めてしまうとして、しばしば批判されています。この緊張関係は、理解不足ではなく、現実のものです。

評価は、遵守状況ではなく成果に焦点を当てるべきである。重要な問いは、アイデアから検証済みの学習までの時間が短縮されたか、証拠に基づいてチームが方向転換できるか、締め切りに追われる中で品質が犠牲にされることなく維持されているか、そして製品がユーザーにとって明らかに改善されているか、といった点である。定められた仕様に従って毎年出荷しながら、規定された手順をすべて実行しているチームは、用語は身につけたものの、その恩恵を全く受けていない。

このアプローチはチームの実践だけでなく組織的な状況にも大きく依存するため、導入には多くの場合、実施チームの管轄外にあるガバナンス、資金調達、計画の変更が必要となります。実際には、これは以下の方法で対処されます。 製品開発 配送プロセス自体と並行して、フィードバックループは以下によってサポートされます。 ユーザー調査そして、内部でその能力を構築する組織は通常、それを 製品部門 計画策定と実行に関する責任が一体となっている場所。