スクラムでは「より生産的であろうとすることを妨げる何らかのもの」を障害として定義している。チームができるだけ継続的に、障害を取り除く手段を確立することを、スクラムでははっきりと重視している。Joe Little 氏は、障害のスコープ(source)について、「組織が価値を提供することを妨げる何らかのもの」とした方がよいのではないか、と提案している。
先日書かれた記事でLittle氏は、なぜアジャイルなチームの測定基準としてベロシティは重要であるのか(source)、自論を展開していた。端的に言うと、彼は以下の3点を指摘している。
- 防御面: ベロシティはマネージャと顧客に、「できません」（または「できます」）と言うための妥当な論拠をチームに与えてくれます
- 正当化: ベロシティという測定基準は、なぜアジャイルが重要なのかという説明を、より前向きにマネージャが受け入れるための助けになります
- 挑戦: ベロシティは、障害を取り除くための努力を評価できるような基準を与えてくれます
その後すぐに、 Little 氏は3つ目のサブテーマである「障害の排除」をさらに深く掘り下げていった。彼は「障害になりうるものを定義する場合、そのスコープとは？(source)」ということを問いかけ、さらに、一般的に受け入れられているアジャイルの見解は、的を外しているかもしれないという問題提起をしている。
スクラムの定義によると、障害とは「より生産的であろうとすることを妨げる何らかのもの」です。個人的に付け加えておきたいのは、全てのものは不完全なのですから、私に言わせれば、全てのもの多かれ少なかれ障害と言えます。こつがあるとすれば、その日のうちに1つか2つ大きな障害を特定しておくぐらいなのです。
スクラムにおいても、工学的な手順から個人的な悩みなど様々なことまで含め、スコープは広いものであるとしています。
私が見たことがないのは、最初から最後まで一貫した観点に立ったバリューストリームのスコープに関する議論です。ですから、チームが生産するビジネス的価値(または価値を産み出すスピード)を減らしてしまう何らかのものが障害なのだ、ということについて議論したいのです。
Little 氏は、まだパートナーの「実装/インストール」チームがインストールの準備ができていないのに、ソフトウェアを作っている開発チームを例に挙げている。このケースでは、チームはやり遂げることができた。しかし、本当の意味でのビジネス価値は何も産み出していない。Little 氏の主張は、実装における障害が最も重大な障害であり、開発チームはそれを発見し、取り除くことに注力した方がいいだろう言っている。
Little 氏が言っていることは、最近 Mary Poppendieck 氏、Tom Poppendieck 氏(参考記事・英語)、平鍋 健児氏(参考記事)などが普及させたリーンソフトウェア開発(source)のシステム思考が持つ特色の、根源的な前提に辿り着いたと言える。要するに、根本にある考え方は、包括的にバリューストリームを理解し、陥りがちな障害を取り除くことで、局所的な最適化を防ぐというものである。