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

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

弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。今日はよくある質問とその答えについていくつかご紹介したいと思います。

なお、過去2回のものは以下になります。

好評そうだったら続編も書く予定です。

■以前のスプリントで作成したインクリメントにバグを発見した場合には、修正はどのように扱えばよいでしょうか？

スプリント内で開発しているプロダクトバックログアイテムに関するバグがそのスプリント中に見つかったのであれば、そのスプリントの開発作業の一環として修正します。そのバグの内容が完成の定義を満たしていない場合は、成果とはならず、そもそもスプリントレビューにも出せません。

次に以前のスプリントで開発した部分にバグが見つかった場合ですが、まずはバグの内容を分類します。重大なバグなのか、普通のバグなのか、時間があるときに直せばよいバグなのか、もしくは放置して問題ないバグなのかといった具合です。例えば、既に運用中のシステムにおいて重大なバグが見つかった場合、すぐに対応が必要で、その規模が大きいようなら、計画済のプロダクトバックログアイテムを入れ替えたり、スプリントをキャンセルしたりするといった判断をすることもあります。それ以外のバグについては、プロダクトオーナーが優先順位を付けて対応時期をコントロールします。課題管理システム等にバグを入れても構いませんが、プロダクトバックログと課題管理システムが併存して別々の優先順位を持つと混乱するので、順番についてはプロダクトオーナーが判断していきます。

■要件定義や設計だけを行うスプリント、テストだけを行うスプリントというのはダメでしょうか？書籍ではどれもスプリントで設計からテストまで全部やっているように見えますができる気がしません

新規プロダクトの場合は、最初のスプリントの開始前に、スプリント0と呼ばれる助走期間をとってビジョンを明確化したり、初期の要件を収集したり、アーキテクチャを検討したりすることがあります。これについては時間を限定して実施する分には構いません。準備不足で決まっていないままに進めると、スプリントが空回りするためです。

一方で、通常のスプリントに入った場合には、「動作するソフトウェア」が完成しないスプリント、特に設計だけのスプリントは絶対に避けなければいけません。このようにしてしまうと、後続のスプリントの計画が自動的に決まってしまうのと、動作するソフトウェアの製造量の予測ができなくなるからです（設計のベロシティとは何？ということです）。

もちろん何も要件が決まっていないと開発できないのも事実なので、次のスプリントで作るものの要件については前のスプリント完了までに決っている必要がありますが、このとき大事なのは「開発チームが作る予定のものが具体的かどうか」です。次にやらない箇所を含めて全部設計しないといけないわけでもありません。通常、次のスプリントに向けての準備はバックログリファインメントの活動で行いますが、使う時間はスプリントのキャパシティの10%程度の時間になります。

なお、テストについては事情が違うこともあります。スプリント単位で「出荷できるレベルの品質」を確保しようとすると品質関連の作業が多くなりすぎて開発の時間が減ってしまいます。リリース時期が固定なのであれば最後の数スプリントを総合的なテストに使うという選択肢もあります。ただしスプリント単位でも「ある程度大丈夫と思える」品質を確保するのが前提になります。さもないと最後のテスト期間に大量の問題がでてしまい、当初確保した期間では対応できないといった結果になってしまいます。

■IT業界のトップ：Google、Microsoft、Amazonなどでも、大規模システムはウォーターフォールで進めているのではないですか？

この3社とも、それぞれのプロジェクトでどのような手法を利用するかは、実際にそのプロジェクトを推進するチームに任されているようです。

例えばGoogleの場合は、この記事のコメント欄に以下のような記述があります。

Overall, Google generally fits the spirit of agile methods, and in fact some groups use XP, or Scrum, or whatever, but it's up to each team, and the methodology a team choses to use is definitely secondary to the results it produces, so nobody cares about buzzword compliance. The corporate philosophy seems to be ""we'd rather underconstrain people than overconstrain them"". Some projects are time critical--and they use schedules, milestones, etc. (though not, that I have seen, MS Project) as a way to keep themselves on track. Some people do pair programming as a way to be more productive, but that's up to them. That's what's most different from other large development organizations: process is intentionally not centralized except where absolutely necessary. It's the polar opposite of, say, CMMI.

要約すると、主にアジャイルなやり方をするが、具体的にどんなやり方をするかはチームに任されていて、中央集権的なコントロールは避けているということです。これは社員を大人扱いし自由に取り組むことで生産性や創造性を向上させるアプローチです。またAmazonでも同じ状況だと思われます（Scrum Incの支援先企業の一覧にAmazonも含まれています）。もちろん本番にリリースするためには品質を確保する必要はあり、デプロイ用のプラットフォームやCI/CD環境などが共通基盤として提供されており、一定のルールには従う必要があるそうです。

海外の企業の場合、個々のチームが明確なビジネスゴールを持っており、それを達成する上では多くの判断がチームに委譲されていると理解しておくと良いと思います。

■スプリントプランニングでのタスク分割について、「熟練チームではタスクを時間見積りしないこともある」と聞いたことがありますが、その場合どのようにしてスプリント中に自分たちの進捗を確認するのでしょうか。

熟練度の高いスクラムチームでは、あらかじめプロダクトバックログのうち直近着手するものについては具体化、詳細化をすすめて（Readyにする）、しかも扱いやすいサイズまで分割が終わった状態にしています。つまりスプリントに投入したプロダクトバックログアイテムが何個完了したかを追跡すれば、スプリントゴールの達成の可否は開発チームがおおよそ判断できるということになります。また、デイリースクラムの大きな目的はこのままいくとスプリントゴールが達成できるかどうかのチェックをすることですが、熟練度が高ければ見通しの判断も正確になっていきます。

一方で熟練度の低いチームの場合、なかなかそうはいかないこともありますので、スクラムマスターが開発チームに対してタスクの明確化や進捗追跡方法の検討を促すことも必要です。ただしスクラムマスターが言わないと開発チームがそういった活動をしないのであれば、開発チームに自律性が不足しているので、彼ら自身でできるように仕向けていく必要があります（なお、スクラムマスターは管理者ではないので、タスクのアサインや作業順序の指定などはしないでください）。また、もし開発チームがスプリントをうまく過ごせていないのであれば、レトロスペクティブを活用して、スクラムチーム全体でどうすべきか考えるように仕向けてください。

■スクラムチームを持つマネージャーの役割として、従来のマネジメントと大きく異なる点はありますか？

実行責任や説明責任、結果責任については、従来どおりマネージャーが一端を担うはずです。つまり実行そのものについてはスクラムチームに委ねたとしても、マネージャー自身はプロダクトオーナーやスクラムマスターと協働する必要はありますし（この場合マネージャーはステークホルダーになります）、マネージャーの責任が担保できないような場合はマネージャー自身がステークホルダーの1人としてプロダクトオーナーに意向を示して頂いて構いません。

スクラムを始めると、その後はスクラムチームが単独で全ての物事を判断して勝手に進めるわけではなく、実際には現実の制約や組織上のルールに従って外部と協働しながら勧めていくと理解すると良いでしょう。

ホラクラシー経営などに見られるようなフラット組織でもない限り、プロダクト開発を行う以外の組織でのマネジメント（ラインマネジメント）は従来のマネージャーの役割が必要です。組織間の調整であるとか、中長期経営計画、ポートフォリオマネジメントなど、スクラムチームだけで解決できない問題は残ります。

つまり、チーム内のことはチームに任せて、彼らがうまく仕事ができるようにチームの外から支援してあげてください。

■スクラムチームのマネジメントに有効な評価指標は何でしょうか。生産性指標はどうすればいいのでしょう？

まずは、チームが作成しているプロダクトの売り上げ、利益、キャッシュフローの計測が基本です。言い換えれば生み出した価値を基準にします。これらは短期的に達成すれば良いわけではなく、継続的に達成していく必要があります。

その上で、これらの指標に結びつく、内部の指標に何があるのかを考えてみてください。一般的なメトリクスを、成果との関連を確認せずに導入するのは、良くない結果につながります（そのメトリクスを取る活動自体もムダな可能性があります）。つまり、従来型手法を評価するために最適化していた評価手法（生産性指標など）を、そのまま他の手法の評価に使うのは適切ではありません。

■スクラムチームメンバの評価はどのようにすべきでしょうか？よくある個人の目標管理制度とどう組み合わせるのでしょうか

評価の目的は何でしょうか？チームメンバーとして、チームの業績に貢献するための能力、やり方の改善のための評価でしょうか？それとも給与を決めるための評価でしょうか？それらは、全く違うものですので、まずはそこを分けて考えると良いと思います。つまり仕事がうまくなるようにするためのフィードバックは頻繁に行う必要がありますし、期待に沿っているのかどうかのギャップが最後に発覚しないようにしてくだい。なお、よくある個人の目標管理制度とプロダクトの成功のために必要な活動がコンフリクトすると辛い状況になります。つまり限られた時間を個人の目標達成のためだけに部分最適として使うことになってしまうので、結果的にはプロダクトに悪影響を及ぼします。個人の目標をたてる場合は定期的に中身の見直し（不要になった項目の削除や新たな目標の設定など）をお勧めします。

それでは。