スクラムに対する疑問を専門家に聞いてみた

最近社内でスクラムに関する勉強会があり、多くのスクラムチームの立ち上げに関わった方に質問できる機会があったので、スクラムに関して個人的に疑問に思っていたことを色々聞いてみました。書籍を読むだけではわからない実践的な学びを得たので、シェアします。なお、実際にスクラム開発をしている人というよりは、勉強中の人向けの内容かと思います。

手戻りという概念はあるか？

【回答】
手戻りという概念はスクラムには存在せず、学び/気づきを得たと考える。

「手戻り」は、現在行っている作業で何らかの問題が発覚したために、前の工程に戻ってやり直すことです。ウォーターフォールでは、設計や開発を行っているときに要件の漏れに気づいた場合、要件定義に戻る必要があります。一方スクラムでは、市場（ユーザ）に価値を提供するためには、こんな要件（ユーザーストーリー）が必要になる、という学び/気づきを得たにすぎず、それがバックログに追加されて終わりです。

障害対応はどのように扱うか？

【回答】
スプリントプランニングの際、スケジュールにバッファを持たせておき、障害対応などの想定外事象が発生した際は、そのバッファで対応する

スプリント期間中は、スプリントバックログにない作業は行わないと理解していたので、障害対応をどのように扱うか質問してみましたが、障害などのやむを得ない割り込みタスクに対してはバッファを持つ場合が多いようです。

バックログ消化を妨げる障害が人と判断され、スクラムマスターがその人を追い出すということはあるか

【回答】
ある。実際に、技術力が高いがこだわりが強くその人が納得しないとリリースさせない、という人がチームにいたことがあったが、その人は複数のチームの共通資産（アドバイザリー）という立場に異動させ、チームから抜けてもらったことがあった。

この話の流れで、スクラムマスターの重要な役割の一つに、人材配置があることを学びました。上述の例のように、チーム内の障害を取り去ることはもちろん、例えば、プロダクトにセキュリティの問題が発生し、セキュリティの専門家に相談をしたい、という場合は、スクラムマスターが人材の調達（またはプロダクトマネージャへその相談）を行う必要があるとのことです。

よいユーザーストーリーの条件の一つにNegotiableとあるが、開発チームがユーザと直接会話してもよいか

【回答】
よい。開発チームがユーザと直接会話してスムーズに仕事を進められるなら、むしろ好ましい。ただし、ユーザーストーリーに変更を加えられるタイミングは、バックログリファインメントなど限られたタイミングのみ。スプリント期間中に勝手にストーリーの完了条件を変更することなどは許されない。

スクラムチームとユーザとの接点は、プロダクトマネージャだけなのかなと考えていたのですが、開発チームとユーザとが直接会話できる場合（社内システムを開発するような場合は、珍しくないと思います）は、それは許されるようです。ただし、勝手にユーザーストーリーを変更すれば、プロダクトマネージャおよびスクラムマスターに詰められるようです。

ITベンダ（SIer、ITコンサル）が開発を行う場合、納期や実装できる要件を契約時点で約束できないが、ユーザ企業側は納得できるか。準委任契約だとしても、事実として、多くの現場で精緻なWBSを作り、ガントチャートを作り、成果物を定義しているので、納期や実装できる要件を契約時点で示せないと契約して頂けるイメージがわかない。

【回答】
プロジェクト開始段階においては、PoCをスクラムで行い、そのインプットをもとにスクラムを継続するか、ウォーターフォール的なアプローチで進めるかを決めましょうと言って始めることがある。また、本格的に開発することが決まった場合は、2～3スプリントごとなど期間を短く区切って契約することがある。

PoCでは「どこまで作る」を約束しなくてもよいケースが多いため、ITベンダが入る場合でも、スクラムを比較的導入しやすそうです。この段階でユーザ企業側にスクラムの進め方を理解してもらうことができれば、後続の契約もスムーズにできそうです。一方で、少なくとも本格的な開発開始の時点で、スクラムではウォーターフォール的な「事前に全ての計画を立ててそれ通り進めること」ができないということを理解してもらわないと、PoC期間である意味"下手に"チームの生産性などが可視化できてしまうからこそ、それをもとに計画を立てられるでしょ？と言われてしまいそうだなと思いました。

また、ITベンダとしても、案件規模を大きくしたがる傾向があるため、担当者レベルではスクラムで進めたいと思っていても、ウォーターフォールによる大規模案件の提案をせざるを得なくなる場合も多いと思われます。