アジャイル開発（スクラム）の本質を考えてみた

アジャイルソフトウェア開発宣言の執筆者が著者である、「スクラム　仕事が４倍速くなる“世界標準”のチーム戦術」を参考にしています。

本書から重要だと思うことをピックアップし、ウォーターフォールではどうなのかという対比をしてみました。

なお、本質的にはアジャイル開発⊃スクラムですが、ここではアジャイル開発とスクラムを同義で扱っています

1.生産性を極限まで高めたチーム

スクラムには、実施したほうが良いイベント（デイリースクラムなど）があります。

これらは全てチームの生産性を高めるためといって間違いはないと思います。

生産性が高いチームとは何なのか。

本書では、機能横断的で主体的、みずから動く力を持ち、枠を超えた大きな目標を掲げているチームとなっています。

一人ひとりが、自分の仕事に集中するだけではなく、チームのため動けるようになる、そしてチームが成長することが重要です。

計画はこれを邪魔します。

計画があるから、自分の役割に固執します。枠を超えません。

計画があるから、生産性を上げすぎず、スケジュールに間に合うように仕事します。

2.無駄を作らない

２つの重大な無駄があります。

①間違ったプロセスで続けた無駄な時間
②誰も使わない無駄な機能

　①間違ったプロセスで続けた無駄な時間

無駄な時間を作らないために、行動する必要があります。

行動をするからこそ、改善点を発見できたり、フィードバックをもらえます。

自分たちが正しいやり方で、正しい方向に勧めているかを確認出来るのです。

ウォーターフォールの場合、計画は完璧という前提で進めます。

前工程は完璧で、前工程通りに進められているか確認するためにテストを行いますが、最終的に要件や計画が正しいかを確認することは行いません。（行えません）

考え方として、計画の振り返りをする必要が無い、どこかを正としないといけないのです。

だから、気づけない、仮に気づいたとして遅くなるのです。

　②誰も使わない無駄な機能

ソフトウェアの価値の80%は、20%の機能に含まれています。
（45%の機能は全く使われていないという結果もあります。『Chaos Report、Standish Group、2000』）

まずこの20%に集中すれば良いのです。

アジャイル開発なら必要な機能から開発するため、この20%に集中することが出来ます。
さらにフィードバックを通して（①の活動を通して）、高い確度で20%を選定することが出来ます。

計画を事前に立てる場合、必要かどうか不明な機能をスコープに含めがちです。
機能を新規に追加するには再度プロジェクト化する必要があり、念の為スコープに入れておこうという心理が働くためです。

結果、無駄が生じるのです。

3.まとめ

アジャイル開発は柔軟性があって、ビジネス面でメリットがあることばかり取り上げられがちです。

しかし、それは副産物だと思っています。

最高のチームは何なのか、そして、チーム・個人をどのようにして最高の状態に持っていくか、に焦点が当てられているように思えました。

価値のある製品を作るために良いプロセスと良いチームを必要とするのではなく、良いプロセスが良いチームを作り、良いチームが価値のある製品を作るのです。

前回の投稿と比較すると、大企業が抱えているアジャイル開発の課題は、アジャイル開発を行うための本質にぶつかっており、抜本的な改革なしでは成功は無いことが予想されます。

本書では次の言葉で表しています。

「企業には２つの選択肢しかない。変わるかつぶれるかだ」