アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (2)

みなさんこんにちは。@ryuzeeです。

先日、弊社がアジャイル開発やスクラムのトレーニングの際によく質問いただく項目とそれへの回答を一部紹介しました。参考になると言ってくださった方も多かったようなので、第二弾を公開します。

■請負契約でアジャイル開発を進めるコツを教えてください

悪いことは言わないので、請負契約は避けた方が良いです。最初にスコープを全て洗い出して固定し、そこから期日と費用を見積もって請負契約したのであれば、完成責任と納入責任を負わざるを得ません。一方でアジャイル開発は「スコープが変化する」「全てのことを事前に予測することはできない」という考えを中心においています。ですので完了する責任をもって契約するのではなく、「変化に最大限対応すること」「最善をつくすこと」を約束します。必ず完了させなければならない契約に対してアジャイル開発を適用してしまうと、「変化」の要求は受け手側にとってはコスト増大・期間延長のリスクにしかなりません（定額時間無制限食べ放題みたいなものです）。準委任型の契約にしましょう。それでも顧客が請負契約を求める場合があるかもしれませんが、その場合は顧客がそもそもアジャイル開発を理解していない可能性があるので、考え方を説明して理解してもらう活動が必要です。

■スクラムの開発チームメンバーはクロスファンクショナルでいろいろなことができると思いますが、そんな優秀な人たちがいるならウォーターフォールでもうまくいくのではないですか

誤解のないようにいっておくと、個人としてインフラやアプリを始めとするさまざまな領域の設計や実装を全部できないといけないわけではありません。開発チーム全体を見た時に必要なスキルを網羅していることがだいじです。外部のチームへの受渡しや依存が増えれば増えるほどリードタイムは長くなり、計画作りも難しくなります。また、いま複数のスキルがなくても開発チーム一体で開発を進めていけばいろいろなスキルが身に付きますし、開発チーム全体の能力もどんどんあがります（もちろん最初のうち特定のスキルが特定の人に依存する場合もあります。その場合はその人がボトルネックになるためクリティカルな領域であるほどなるべく早く単一障害点の解消が必要です）。

なお、「うまくいく」の基準はウォーターフォールとアジャイルでかなり違います。ウォーターフォールは事前にたてた計画を守れれば成功、アジャイル開発はプロダクトによってビジネスの成果が出せれば成功です。その点を抜きにして、開発チームの生産性や効率だけを議論することに意味はありません。

■スプリントの長さは固定ですが、祝祭日があって営業日が減る場合はどうしたらよいですか

スプリントプランニングやスプリントレビューは定期的に実施することにメリットがあるので、基本的に曜日を固定することをお勧めします。つまり祝祭日があった場合は、その分スプリントの稼働日数は減ります。開発チームが使える時間も減るので、計画ではそれを考慮して取り組むプロダクトバックログアイテムを減らすのが一般的です。また研修などでの不在や休暇も考慮に入れるとよいでしょう。スプリントの総稼働可能時間から不在の時間や各種イベントの時間を抜いたものが開発チームのキャパシティになります。キャパシティを超えたタスクに取り組もうとしても終わらないので、スプリントプランニングでタスク量とキャパシティを比較し、タスク量が多すぎる場合は末尾のプロダクトバックログから順番にスコープから外していきます。キャパシティについてはあらかじめ20〜30%程度のバッファを取っておくと安心です（間違っても1日8時間全部が開発に使えるとは決して思わないようにしてください）。

なお、日本は月曜日に休日が多いので、スプリント開始日を月曜日にしない方が運用しやすいと思います。

■プロダクトバックログの見積りについて、規模や工数を算出する時にどんな方法を使えばよいですか

プロダクトバックログアイテムの見積りは継続的に実施する活動なのでタイミングごとに説明します。

まずプロジェクト初期に全体で必要そうな工数や期間などを算出します。算出の仕方はスクラムでは規定はありませんので好きなやり方を使ってください。例えばファンクションポイントも使えますし、見積りのノウハウが蓄積されていればそれを使っても構いません。大事なのは初期のプロダクトバックログアイテムのすべての開発を「約束」するわけではないので、この見積りは開発チームのサイズや期間の算出に使うだけであるというのを意識することです。ここで開発チームのサイズと期間が決まれば、プロジェクトにかかる費用は算定が可能です。もちろん先に予算確保や投資可能額が決っているのであれば、それを前提にしても構いません。

次に個々のプロダクトバックログアイテムの見積り方法ですが、これ自体もスクラムでは細かい決まりはありません。決っているのは「プロダクトバックログアイテムを見積もっておけ」という点です。人日や人月で見積もっても構いませんが、細かく見積もることにあまり意味はないので、相対的なサイズを1,2,3,5,8,13,20…などのフィボナッチ数列を使って表したりTシャツサイズと呼ばれるS/M/L/XL/XXLなどで表したりします。最初の何回かのスプリントを実施すると開発チームがどれくらいの量を1スプリントで完了できるかが分かってプロジェクトの着地点の予測精度が向上していきます。

なお、個々のプロダクトバックログアイテムの見積りはスプリントが進んで色々なものができあがったり開発チームの能力が向上することによっても変わっていきますので、バックログリファインメントのイベントを活用して上位のプロダクトバックログアイテムは定期的に見積りしなおしてください。

■スプリントプランニングやレトロスペクティブで、スクラムチーム内の議論についていけないメンバーがいた場合、どうしたらいいでしょうか

基本的にはスクラムチーム内で解決方法を考えてください。例えば新人であれば話が分からなくてついてこれないのは当然ですが、ずっとそのままにしておくといつまでたってもチームの総合力が上がらないので、優先順位の高い課題として対処しないといけません（例えばペアで作業したり説明の時間をとるなど）。一方で本人の資質やマインドセットに問題があって、チームとしてできる限りはやってみたということであれば、スクラムマスターやラインマネージャーがその人をチームから除外するという判断をした方がよい場合もあります。ただしいずれにせよ、まずはチームで全力で解決しにいってください。

なお、似たようなケースでスクラムチーム内で決めた規律を守らない人がいる場合もあります。たとえばイベントごとに来ない、完成の定義を守らない、着手すべき順番に着手しないで好きなものばかりをやるといったものです。このような状況を放置すると、スクラムチーム全体の規律が失われていきます。技術的に優秀かどうかに関係なく対処をしなければいけません。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料）