よくある古典的な、終わりのない葛藤と同じように、開発チームをどのように組織し、自律的にするかという議論は依然として盛り上がっています。目下のところ、スクラムについては好意的な見方よりも批判の方が多いかのように思えます。もっともよくある３つの批判は次のようなものです。
１. 仕事そのものよりもプロセスが重視されがちである
２. 呼び名が違うマイクロマネジメントであると混同されやすい
３. デイリーのスタンドアップによって、自分の在り方を正さなければいけないように感じる
その他にもスクラムにおける役割が正しく表現されていないというケースがあります。プロダクトオーナーがスプリントの中にあまりにも多くのことを詰め込もうとしたり、スプリントの最中に優先順位を変えようとしたりすることもあります。また、スクラム開発におけるベロシティを維持することと、新しく学んだスクラムの儀式を何でも取り入れようとすることに執拗にこだわるスクラムマスターがいます。このフレームワークの中でしばらく働くうちに、「大事なのは私たちの仕事なのか、それともこの方法論なのか？」など、誰もが似たような疑問を抱くのです。
スクラムに対する間違った５つの期待
上に挙げたような数多くの機能不全があるとしても、スクラムが機能しない根本の原因は、スクラムはただプロセスに沿うだけで組織内の根本的な問題を解決できるようには設計されていないということです。このことを理解しないと、新たなチームで仕事を始めて間もなく危機に陥るでしょう。
１. スクラムはチームの作業を高速にする
スクラムで使用される用語は、あたかもスクラムを使えばリソースの追加無しでプロセスを加速させるかのように誤解させる響きがありました。スクラムに慣れていないチームは、その専門用語の泥沼にはまってしまうことが非常によくあります（たとえば、スクラムマスターって？ プロダクトオーナーとプロダクトマネージャーはどう違うの？ ストーリーポイントとは何でどのように見積もるといいの？ というように）。
さらに厄介なのは、「ベロシティ（velocity）」や「スプリント（sprints）」といった用語が「速さ」を連想させることです。しかしながら、スクラムを含むアジャイル開発手法の目的は、完成されたプロダクトをユーザーに提供することです。あなたのチームがスクラムを用いてより有能になるにつれて、結果として新たな機能をより素早くユーザーに提供できることになるでしょう。
しかし、速さは必ずしも本来の目的ではありません。開発のスピードではなく、完成されたプロダクトをより素早くユーザーに届けるという目的はスクラムチームの中で明確になるべきです。また、社内での理解を高め、スクラムの開発手法をサポートしてもらうためにもスクラムの目的を明確にする必要があります。
あなたが売っているものは速さではなく、完成されたプロダクトなのです。
２. スクラムを厳格に遵守すれば、会社の文化に関わる問題を解決できる
誰もが異なった仕事のスタイルを持っています。会議を好む人もいれば、よく働いてよく遊ぶということを好む人もいます。あなたの会社が価値を置いている仕事のスタイルがどのようなものであれ、その良い面と悪い面の両方を受け入れることが不可欠であり、重要なことです。会議を重視する会社は、デイリースクラムに悩みがちです。攻撃的でスピードに特化したチームはスプリントの中で今後やるべき作業の肥大化に直面するでしょう。
特に、できて間もないようなチームにとっては、全体像を見失いやすいことがあります。大事なことは、プロセスの細かな点全てにこだわることではなく、完成されたプロダクトをユーザーに届けることなのです。方法論についてどうこう言う以前に、目標を達成するために仕事のスタイルを改善する方法を常に探しましょう。
３. 決定的な働きをする人であれば、会議には代役を立てても良い
スクラムを始めたからには、代理としてではなく本来のチームが参加することが重要です。開発者の立場からほとんど普遍的な不満があるとしたら、それはスクラムマスターとプロダクトオーナーが大事なときに役に立たず、彼らの代理人に決定権が無いことです。誰だって、決定権のある人がいない会議に、ただ決定事項を聞くためだけに参加したくはありません。
会議に代役を立てることはおそらく一般的なことですが、スクラムにおいては、会議の参加者にも決定権を与えるべきです。
４. デイリースタンドアップさえすれば、皆がより自分の仕事に集中できるようになる
デイリースタンドアップにおいては、ただ単にそれまでの24時間に何をしたかについて注目しても仕方ありません。それよりも、タスクの障害を明るみに出し、問題を解決するための新たな提案に重きを置くほうがずっと重要です。
スクラムが断定的な力を持ちながらも行き過ぎないようにするためには、特にスクラムマスターのような役割を必要とします。スクラムマスターにとって重要なのは、プロダクトの完成につながるようなポジティブな雰囲気を作り上げることです。
５. 最初の試行で成功する
スクラムにはあてずっぽうも、演繹（えんえき）的思考も、そして何より失敗もすべてを内包されます。初めての挑戦でうまくやれる人はほとんどいません。スクラムはあらゆる面において反復的なものです。最終プロダクトに到達する方法だけでなく、プロセスを管理し運用する方法も重要です。スクラムは、チームが導入するための壁を低く設計してありますが、同時にまた、フレームワークへの参加を繰り返し、継続的に改善する責任も求められます。
壊れたスクラムのプロセスを修復する方法
スクラムはサンクコストの誤りに陥りづらい仕組みです。その繰り返す性質によって、スクラムには効果的でないプロセスを見直す機会があるのです。もしスクラムのプロセスが期待したような効果を上げていないのなら、次のような事項を考えてみてください。
期待値を見直す
市場投入までの時間を短縮することであれ、魅力的なプロダクトを作ることであれ、チーム内の協力関係を向上させることであれ、成功を掴むためには責任と時間が必要です。できて間もないチームにとっては、各スプリントの後に実稼働環境にテスト可能なコードを導入できるかが達成すべき合理的なマイルストーンになります。
高度な開発チームなら、要求に応じてビルド、テスト、デプロイする能力を持っていて成功を測ることができます。新しい機能に対するユーザーの反応を計測および定量化できますか？ より広範な組織ではチームがプロダクトに加えようとしている変更をサポートする用意ができていますか？
メンバーに権限を持たせる
チームにとっての価値をどのように高めることができるかという点で、チームメンバーと実際に顔を合わせて指導することが重要です。もし意思決定を求められている場合、いつどのように他のメンバーを巻き込めばよいかコーチングを行って、彼らの自信を強く持たせましょう。マネージャーは必要に応じて障害を取り除き、チームをサポートできるようにしておかなければなりません。
問題に前もって対処する
スクラムは、あなたの会社に変革をもたらすように作られたものではありません。もし問題を放置すれば、きっとそれらの問題はプロダクト開発のプロセスにおいて明るみに出てくるでしょう。スクラムマスターは、メンバーのフィードバックを組み込むためのポジティブな方法を導入して、衝突感や対立感を軽減することができます。
そのような例の一つが、「こうしたい、こうならないか、もしそうだとしたら」というフレームワークです。チーム内での議論や振り返りの中で、メンバーはこのいずれかのフレーズから意見を述べ始めることでフィードバックを提供できます。たとえば、「デイリースタンドアップでは、もっとその日に注意を払うべき障害に特化できるようなものにしたい」というような発言です。これとまったく同じでなくても、自分らしい言いかたで大丈夫です。
もう一つ、会議において役立つフィードバックの仕組みが、Brian Robertson氏によって作られ、Zapposなどの企業で使われているホラクラシーの一つ、トリアージという方法です。たとえば、メンバーは議論の対象となる「テンション（Tension）」のアジェンダを作ります。各メンバーは「こういうテンションを感じていて」と話し始め、それからそれを解決するための人員やその他のリソースを列挙します。メンバーが問題を「テンション」として直接的に扱うように仕向けることにより、ホラクラシーはメンバーがギスギスした雰囲気になることなく自由に意見を言い合うことを可能にしているのです。
問題を解決するために振り返りを行い、プロセスの中で繰り返す
多くの会社において、振り返りは正当な評価をされていません。これはまず何より、多くの人が振り返りの場を、もう済んだ議論や衝突、不満を吐き出すための場所にしているからです。チームにとって、チーム自身の価値観と会社の文化を反映した基本原則を作ることが何より重要です。
決まったプロセスに時間をかけないようにすることもまた重要です。一度上手く行ったものは、二度と上手く行かない場合があります。メンバーは別のチームにアサインされたり、昇進したり、こぞって会社を辞めたりしますが、これは多くの会社でごく普通に起こることです。チームの構成が進化するにつれて、スクラムではすべてが繰り返すということに囚われないことこそが重要になります。失敗は起こるものですが、繰り返しているうちにそれらは長続きしなくなるでしょう。
スクラムは、原則が存在してこそ力を発揮する
チームの一員であるために、あなたは自分の役割を示すこと、そして役割を全うできることに責任を持たなければなりません。プロダクト開発は、会社の長期的な発展のために引き受けなければならない、おそらくもっとも重要なプロセスでしょう。ですから、スクラムは新たなプロダクトの開発への最高の道として、相応の評価を受けるべきです。
多くの環境では、開発チームは会社の目標を左右するような意思決定や議論とは切り離されたところで働くことがあります。ですがスクラムは違います。一つのプロセスの中に意思決定も、方向付けも、開発も統合されているのがスクラムなのです。なので、スクラムの方法の中で行われる会議に代理の人を出席させたり、チームメンバーを除外したりすべきではありません。
まとめ
スクラムの繰り返しの性質によって、ビジネスがいつまでもうまく行かなかったり、後からまずいアイデアだと分かるようなものやお粗末に使われるプロセスに注力したりすることを、スクラムを使うことで防ぐことができます。この原則を守れば、過去の過ちから解放され、スクラムのプロセスを繰り返し改善することが可能です。
一人ひとりのメンバーと、チームにフォーカスすることが重要です。チームのメンバーは変わりますし、プロジェクトは一つひとつ違います。プロセスを厳格に守ることがいつでも最高の結果に結びつくわけではありません。プロセスの外でメンバーに対して働きかけることも、あなた自身がプロセスの中でどのように振る舞うかと同じくらい重要です。
スクラムは柔軟に使うことができます。もし何かが上手く行っていないのなら、アジャイルやアジャイル以外のフレームワークから別の要素を取り入れることを検討しましょう。対立的な議論に効き目のある、コミュニケーションの構造化されたスタイルを見つけ、それを取り入れてください。
スクラムのおかげでチームは、変化し続けるクライアントの要望に対応して完璧なプロダクトを作ることができ、その結果、長期的なROIにプラスに作用します。おそらくスクラムは、より良い開発をするためのすばらしいアイデアを出やすくしながら、間違ったアイデアに力を使いすぎないようにするための最高の方法論でしょう。
