スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。

シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。

1. 組織の賛同が得られていない

どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外ではありません。変更に対し、関係者が納得していなかったり、主要なステークホルダーの賛同が得られていなかったりする場合は、スクラムを導入しても失敗に終わることは明らかです。

スクラムのプロセスはソフトウェア開発を進める中のあらゆるプロセスに適用されます。ですから、チームの関係者それぞれがスクラムのプロセスを受け入れる必要があります。一部の人だけがそれを推進していても成功しません。スクラムを導入すると、多くの人にとってあまりなじみのないテクニックや用語が出てきたり、ソフトウェア開発における長年のルールとは相反するものが出てきたりします。そのため、少しやりにくさを感じる同僚やマネージャーもいるかもしれません。組織としての文化がアジャイルの価値観そのものと相容れない場合には、こうしたことがさらに問題になります。詳細については、 アジャイルの原則 を参照してください。

解決策： 自社にスクラムを導入することを検討する前に、 チームと組織にどんな価値をもたらすのかを明確にしましょう。 まず、 あなた 自身が、スクラムの導入がもたらす価値を明確に理解していなければ、他の関係者に何かを期待することはできません。「なぜやるか？」が明確になって初めて、チームとステークホルダーを説得する段階になります。チームの規模によっては、この段階をいくつかのセッションに分けて行うことをお勧めします。忘れないでほしいのは、この段階では心をつかむことが目的だということです。同僚たちが、ただやらされていると思っているようではいけません。彼ら自身がスクラムを導入したいと思えるぐらいまで説得するのです。これができれば、成功する可能性はずっと高くなります。

「自社へのスクラムの導入を検討する前に、それがチームにどんな価値をもたらすのか明確に理解しておくべき」

すぐに賛同を得たいという場合には、ちょっとしたコツがあります。チームや組織の中で既に認識されている弱点と、それに対してスクラムがもたらすメリットを結びつけて話すのです。例えば、開発チームの離職率が高いことが問題になっている場合、アジャイル原則を包含しているスクラムなら持続可能なペースで作業を進めていけると説明することができます。同僚はメリットが明確になれば、そのやり方に目を向け始めるでしょう。そうなれば、いつの間にかチーム全体がスクラムの導入を推進してくれるようになるのです。

賛同が得られれば、導入は半分完了したようなものです。極端だと思われるかもしれませんが、事実です。人に、長年続けてきたプロセスや習慣を変えることを納得してもらうのは、非常に難しいことだと言えます。だからこそ、そのプロセスを受け入れる人が増えれば増えるほど、スクラムが成功する可能性は高くなるのです。

同僚や顧客からの賛同を得ることは必須。

2. スクラムの導入を急ぎすぎる

よく聞く原因です。組織のどんな変更でもそうですが、特にソフトウェア開発プロセスの核心にまで影響するような変更の場合は、スクラムの導入は着実にひとつずつ段階を踏む必要があります。数週間の工程でウォーターフォール方式からスクラムに変更しようとして失敗する事業者を多く見てきました。チームとプロセスの根本的な変化は、一晩では起こらないものです。

解決策： 事業やチームにスクラム方式を導入するための時間を十分にとりましょう。3か月から6か月をお勧めしますが、この期間は関係者の人数に応じて異なります。スクラムの導入を全く初めてのプロジェクトとして取り扱い、タスクを小さく分解します。つまり、製品管理チームを訓練して、製品バックログの整え方を教え込むのです。その小さなタスクを短い繰り返し作業（スプリント）にスケジューリングし、各回の繰り返しの最後に何が達成できているか確認します（スプリントレビュー）。成功の鍵は、急がば回れです。

適切なペースでスクラムを導入すれば、同僚たちがスクラムの概念とさまざまな作業のやり方を把握する時間をとることができます。また、この方式をチームや組織にもっと適した形にするために微調整を加えられそうな場合には、それについて議論したり試したりする時間もとることができます。その場合は、この方式の根本的な部分、例えば機能横断型のチームやスプリントミーティングなどの特徴を失うことになるような、安直な道を選ばないように注意しましょう。

時間を十分にとれば、同僚には情報が十分に伝わり、スクラムを日常の業務に組み込むための正しい知識と職能が得られます。着実で持続可能なペースで導入を行えば、仕事のやり方を変えたくない人々からの抵抗はほとんど、または全くなくなり、概して人々はもっと自信を持って行動するようになります。

スクラムを導入するときは、急がないこと。

3. 計画の失敗

普通、計画なしでリリースを発表したりクライアントプロジェクトを提供したりしようとは夢にも思わないものです。なのに、なぜ全く新しい開発方式には計画が必要ないと考えるのでしょうか。馬鹿げたことに、スクラムの導入に失敗する主な理由の1つは、この計画性の欠如なのです。ベンジャミン・フランクリンの名言「計画の失敗は失敗の計画」のとおりです。

解決策： 良い製品やプロジェクトを提供するには構想や目標から始めるべきです。それはチームが目指す方向に集中するために役立ち、困難な状況を切り抜けるための指針ともなります。スクラムの導入も同じことです。早い時期に目標を設け、また、その目標が達成されたか測るために役立つ測定基準を必ず定めましょう。例えば、目標は「6か月以内に組織全体にスクラムを完全に導入する」でも良いでしょう。これで、目標と、その目標が達成されたかの測定基準がほぼ決まります。

「良い製品やプロジェクトを提供するには構想や目標から始めるべき。スクラムでも同じ」

スクラムを導入するとき、私は4段階の計画を使用します。まず、スクラムによってメリットが得られるだろうことを組織に納得させ、チームを自分の味方に付けます。これが、説得段階です。この段階では計画期を設けて、チームにスクラムのテストや読むべき本などの宿題を出します。各人に当事者意識を持たせるように、人やチームごとに異なるタスクを課し、さらに一連のミーティングを予定して進捗をレビューしてもらいます。第2段階ではさらに踏み込んで、タスク推定、スプリント速度、ストレッチ目標などについて話し合います。第3段階では、販売やマーケティングなどの、間接的に影響を受けるチームに話をします。スクラムの働きと、スクラムによって期待できること、例えば、もっと定期的なリリースやフィードバックの機会が増えることなどを伝えます。最後に、この変更と、これが顧客にとってどういう意味があるのかを、常にポジティブさを心がけながら顧客に話します。

スクラムへの移行の計画は非常に個別性の高いプロセスなので、入念に練り上げた計画が必要です。計画にはチームに確信と方向性を与えるための厳密さが必要ですが、途中でフィードバックがあれば変化するという柔軟性も必要です。前述したように私は4段階の計画を使用します。これは、組織の中にスクラムを徐々に導入するために役立ちます。

スクラムの導入ガイドはたくさん出されているので、いくつか読んでから、組織の人々の助けを借りて計画を調整することをお勧めします。優れた計画を立てれば、同僚の心をつかむために役立ち、彼らがプロセスの中で自分の役割に責任を持つ励みとなり、最終的には円滑で円満なスクラムの導入に繋がります。

この段階で苦戦している場合は、スクラムのコーチを外部から招いて支援してもらうことを強く勧めます。部外者の助けを借りるのは高くつくし不必要なコストだ、と感じるかもしれませんが、そんな人に対しては、開発期間を何週か無駄にした分の費用を計算し、外部のスクラムコーチに支払う費用と比較することをお勧めします。その結果に、きっと驚くことでしょう。スクラムの導入に関して言えば、外部のスクラムコーチを迎え入れたチームは、導入の成功率がぐっと高くなります。ひいては、スクラムの普及がなかなか進まないことや好ましくない習慣を引きずり続けることから生じる費用を節約できます。

4. アジャイル方式に関する知識や経験が足りない

スクラムの導入を開始した時点で、チームや組織のメンバー全員が適切なレベルの経験やスキルを持っていて、導入が円滑に進められる状況になっているなどということは、ほとんどありません。それ自体は大した問題ではないものの、こうした状況への対処をしくじると、チームや組織のメンバーがスクラムを受け入れず、かえって悪い習慣がはびこることにもつながります。さらにはチームや組織のメンバーが、より快適な（昔ながらの）作業方式に逆戻りする可能性も高まります。これこそが、導入計画の策定が非常に重要なことの理由です。

解決策： スクラムの導入における（ビジョンの設定後の）最初の段階は、この方法論に関する一般的なレベルの経験と知識を感覚でつかんでもらうことです。同僚同士で何が足りないかを話し合い、ギャップの分析を開始するためのミーティングを開催しましょう。私が実践する場合は、各自の懸念や、知識が不十分な部分のギャップをまず付箋に書いて、壁に貼り出してもらっています。この作業が終わったら、貼られた付箋を「スプリントのルール」や「『完成』という用語の定義」などのトピックに分類し、各トピックを見出しやレーン（カンバン方式でしばしば使われる用語で「列」を指す）としてホワイトボードに書き込みます。続いて、全員に対して、自分の名前を付箋に記入し、もっと詳しく知りたいレーンや列に貼り付けるよう指示します。この技法の長所は、あなたのチームが「未知数ある、分かっていないこと」に気付くかもしれないという点にあります。つまり、彼らにはまだ分からないことが存在することすら、その時点では気付いていないということです。このようにオープンなワークショップを開催することで知識の共有が促され、大抵は良い結果が得られます。参加者の書きそうな回答を完全に予測できる場合は、その場の判断で、ミーティングの前にあらかじめ見出しを書き出しておいてもかまいません。

このセッションの結果分析が終わったら、知識のギャップを1つずつ解決していく必要があります。幸運にも、知識を持つ人が社内に既にいる場合は、その人たちにはコーチングのセッションでリーダーになってもらい、その旨をチーム全員に公表します。社内のリソースだけでは、特定されたギャップへの対処が十分にできない場合は、専門家を招くか、またはスクラムのオンラインコースを探して受講してください。予算が厳しい場合でも、無料で利用できるリソースはたくさんあります。

5. スクラムがその組織に適したフレームワークではない

とうとうこれを言ってしまいました。スクラムはソフトウェア開発の素晴らしいフレームワークですが、万人向けとは言えません。スクラムを採用したことで知られる企業の中には、同業他社がどこもやっているから追随しただけだったり、「アジャイル」を採用していると言えばビジネスで勝つ確率が上がるからというだけの理由だったりする会社もあります。そんなことはもうやめましょう。自社の製品、自社内のチーム、自社の事業を見直して、スクラムは自社に適しているかどうかを判断してください。

「スクラムはソフトウェア開発の素晴らしいフレームワークだが、万人向けとは言えない」

スクラムは、流れが速く短いサイクルで反復を繰り返す開発手法で、全くの新製品、または比較的歴史の浅い製品にはうってつけです。MVP（Minimum Viable Product最低限の機能を実現した製品）や市場性の高さなどのコンセプトに焦点を当て、そうした価値を迅速に実現するのを支援するフレームワークです。ただし、あなたの会社の製品がPMF（Product-Market Fit：新製品が「当たって」爆発的に売り上げを伸ばす状況）を達成したら、スクラムが自社にとって適切なフレームワークであるかどうかを本当に検討する必要があります。

解決策： ライフサイクルとして後半に差し掛かっている製品では、カンバン方式やウォーターフォール方式など、スクラム以外のアプローチが好まれる傾向があります。また、それらの方式は、PCやサーバにインストールされる、より大規模で複雑なアプリケーションに対しての効果が高い傾向にあります。そうしたアプリケーションでは、1スプリントの期間、つまり2～3週間という短期間で、出荷できそうなレベルの製品を仕上げるというコンセプトが実用的ではないためです。対照的に、大規模で複雑な作業には、リグレッション（回帰）テストや安定性テストを非常に重視する、より規則正しいアプローチが必要です。

スクラムのチュートリアルの中ではあまり言及されていないのですが、スクラムの成功はテストの自動化に大きく左右されます。必須であるとは言いませんが、毎回のスプリントで、ソフトウェアプラットフォーム全体に対してリグレッションテストを実行するのはほぼ不可能です。一方、テストの自動化を行わなければ、ソフトウェアが不安定になったり、製品のリリース前に毎回、長期間のリグレッションテストが必要になったりする可能性があります。

スクラムの世界にむやみに飛び込む前に、まずは一歩引いて目の前にある製品やプロジェクトを見直し、「スクラムは本当に、これを進めるための最善の方法なのか」と自問することを強くお勧めします。