スクラム的チーム構造と要求管理：『アジャイル開発とスクラム』を読んで

この本のあとに『アジャイルサムライ』を読んだので少し印象が薄まってしまったが、アジャイルとスクラムについてが平易にまとまっており、また各種プラクティスにも言及しているので次に興味を持って調べてみようとするとっかかりとしても良い本だった。

従来のビジネスとITの関係は目的が分断されてしまっており、「要求が劣化する」というのは非常に耳が痛い。

ビジネスはシステムを開発し、投資した以上の効果を上げることが目的である。ところが、ITは契約を満たすこと、すなわち、「使用どおりのシステムを納品すること」が目的になってしまう。

では要求を劣化させずにITをインプリするにはアジャイル開発が必須というわけではないし、逆にアジャイル開発の手法さえ取れば劣化させずに要求を満たせるというわけでもないのだろうが、現時点でそのProbabilityを上げる方策としてはアジャイルが最適解なのだろう。

スクラムのチーム構造

アジャイル、スクラム、そしてXPなどは現時点で明確な線引きはなく渾然一体とした概念となってしまっている（そしてそれは正しい姿なのだと思う）が、その中でスクラムとしての特色は以下の3つにチームの役割が分かれているところだと思う。

プロダクトオーナー
開発チーム
スクラムマスター

これまでの古典的なウォーターフォール型開発における官僚制的組織であれば、プロジェクトマネージャがプロダクトオーナーとスクラムマスターとしての役割、および開発チームのリーダを兼任している状態だ。これに対しスクラムでは三者の分断を推奨している。プロダクトオーナーが要求をまとめその優先度を明示し、開発チームはプロダクトオーナーは開発のやり方を決めて製品を完成まで持っていき、スクラムマスターは「サーヴァントリーダ」として開発チームが自律的に滞りなく作業を進められるための支援を行う。

一見するとこの主張には違和感がある。スクラムなどアジャイル系開発手法は比較的小さなチームに適合する手法と言われているが、上記のようにプロジェクトマネージャが有していた職掌を分解して別々の役割を置くというのは小さなチームに適合するのか？というところ。

ただこれはこれまでの組織がプロジェクトマネージャに権限を集約させすぎておりそれ故にプロジェクトマネージャ自身がボトルネックになったり、違う感性・コンピテンシーを求められる役割を全うできずに片手落ちになってしまうというケースが多いという反省点が考慮されていることと、逆に開発チームはこれまで機能単位などで分断されていたのを統合することで全体としてはスリム（リーン）な体制にできていることで説明出来るだろう。

ここで面白かったのは、僕の今いるチームがこの構造に非常に近い形に自然となっていたことだ。僕はチームのリードながら基本的に案件の内容やソリューションは概要レベルのみの把握に留めて管理やチームのサポートに回るスクラムマスター、もうひとりの同じクラスのメンバは要件をきっちりと抑えつつソリューションは基本チームに任せるプロダクトオーナー（チーム内から見れば彼こそチームリードに見えるだろう）、そしてそれ以外のメンバが開発チームとしてそれ以下のチーム割をほとんどなく対応してくれている。このような体制が「今までの感じとちょっと違うな」という違和感を覚えながら良い感じで回っていたのにも、このスクラムの構造を照らし合わせると納得がいく。

ただ、これって『人月の神話』で書かれている「外科手術チーム*1」でも「執刀医」と「管理者」、その他諸々の役割に分けるのと一緒なので、古くて新しい（だけど現実にはなかなか難しい）分担なのかも知れない。

要求の優先順位付け

もう1点、スクラムの特徴を挙げると、要求の管理の部分だろうか。要求を「ストーリ」の形、すなわち完璧な仕様として記述せずにユーザの言葉で簡潔に記述することとともに、全ての要求に順番をつけることが求められている。

順位付けされて並んでいることが重要で、例えば要求に高・中・低のような優先度を付けるわけではない。

これは非常にシンプルな指針であるのにこれまで気が付かなかった。まさに目からうろこ。

僕のチームでも「この要求とこの要求どっちが優先なんですか？」という会話が何度も飛び交っている。チケット管理システムに優先度の項目（まさに高中低）はあるけれども事実上使用されていないし、TATの長い大きめの開発作業と日に日に発生する問合せ・作業依頼対応も一緒くたに管理されているので、特にオフショア開発者にとってはどれを優先させて対応すべきか、この要求・タスクはいつまでに完了させなければいけないかが聞かなければ分からない状態なのだ。

これをプロダクトバックログの形でバックログになっている要求・タスクすべてに順番をつけてあげれば、上記のような無駄な確認は不要となるだろう。

とはいえこのすべての（未完了の）要求・タスクに対して順番をつけるというのは手作業だとなかなか難しい。完了したものは除かないといけないし、連番をつけていっても100番と101番の間に差し込みたいものが出てきたら100.5番なんてかっこ悪い番号を付けることになってしまうからだ。

ということでここらへんはシステムの力に頼りたいところ。Redmineでも標準では出来ないので、Redmine dashboardかRedmine backlogを入れて試してみたい。