改善、成功と失敗: 中国でのスクラム導入

InfoQ China(リンク)は中国でスクラム（Scrum）がどのように導入されているかに関する調査を行いました。私たちはこの記事のために5つの事例をピックアップしました。これらの事例は、異なるさまざまな会社によるもので、異なるプロセスが利用され、異なる結果が生じたものです。

サンプルは少なく、どの会社も同じ方法をとったわけではありません。それでも、スクラムをどのように導入するか（成功でも失敗でも）を考えることで、そこからたくさん学ぶことができます。Mike Cohn氏は「Scrum and XP from the Trenches」(リンク)で次のように言っています。

「...私たちは、他の人、特に成功している人達の実施方法の話を聞くことで、スクラムをより良く実施する方法について学ぶことができます ... 最良実施ではなく、私たちが知るべきことは優れた実施とその成功の背景です。成功チームの話と彼らの実施方法を十分に読めば、ScrumとXPの使用時に直面するかもしれない障害に備えることができます。」

InfoQの質問は次のとおりです。

1. なぜプロジェクトでスクラムを利用したのですか?
2. どのようにプロジェクトにスクラムを導入しましたか、そしてそれはなぜですか?
3. 導入時のもっとも大きな問題は何でしたか、そして、それをどのように解決しましたか?
4. スクラムはプロジェクトや会社にどんな利益をもたらしましたか?
5. なぜスクラムの導入がうまくいかなかったのですか? その過程を説明してください。

インタビューの相手と彼らの会社について、次の表に示しています。個人と会社のプライバシーを保護するため、この記事では本名を使用していません。

Q1. なぜプロジェクトでスクラムを利用したのですか?

Julie:

要件はあまりに速く変化します。製品のロードマップは明確ではありません。私たちは、効率、コミュニケーションを改善し、できるだけ早く営業部門が結果を得ることができるようにする必要があります。

kaverjody:

ウォーターフォール型の開発モデルにおける欠陥、およびA&D部門でのその他の問題により、開発方法を変更せずに改善を行うことはできませんでした。上層部は、ソフトウェアメンテナンスのコストが非常に高い、新規バージョンの提供にいつも長い時間がかかるなどといった現在の問題を解決するために、スクラムを使用することを決定しました。

Alex:

私は2007年10月にNibiruTechに加わったときに初めてアジャイルの概念について聞きました。その当時、もっとも一般的なアジャイルのプラクティスは毎日のスタンドアップミーティングでした。私はそのようなミーティングの効果がまったく分かりませんでした。私は、それを理解しようと懸命に努力し、その後にスクラムを見つけました。

当社は新興企業のため、管理の経験があまりありませんでした。私たちは自身で管理システムを記述し、管理のためにTracと一緒にそれを使用していました。私はスクラムに非常に感動したため、社内でスクラムを広めることに決めました。

Q2. どのようにプロジェクトにスクラムを導入しましたか、そしてそれはなぜですか?

Julie:

私たちは純粋なスクラムを使用していません。代わりにXPでのプラクティスを含め、アジャイルの多くの概念とスクラムを混ぜ合わせ、スクラムレトロスペクティブ（回顧）を使用して現在の開発環境と要件から改善を行い、最終的に自分たちで方法を見つけました。たとえば、あるレトロスペクティブでコードレビューの改善が必要であると分かった場合は、次のスプリント（Sprint）で新しいコードレビューのメカニズムを取り入れます。

私たちはボトムアップ方法を使用しました。まず、小さな範囲で部分的実験を行ってから、それをどんどん広範囲に広めました。また、導入時にプロセスの改善を行いました。:

2006 / 03 to 2006 / 06 - 1チーム、約8人で使用
2006 / 06 to 2007 / 12 - 3チーム、約25人で使用
2007 / 12 to 2008 / 01 - 1部門、6チーム、約50人で使用
2008 / 01 to today - 分散したチームで使用中。現在もコラボレーションメソッド、ツール、プロセスなどを構築中

kaverjody:

組織内でスクラムを使用することは、上層部によって決められました。

Alex:

私は当時、スクラムの導入方法について考えずに、ただCEOやチームメートとすべての情報を共有するだけでした。

InfoQに、「実験中、どんな方法をとるかをどのように決めましたか? 既存の問題に専念し、それらを解決するために適切なアジャイルプラクティスに取り組みましたか? また他の方法は?」と質問されて、Julie氏は次のように答えました。:

実は、私たちは当初、「スクラム」という専門用語を使用しませんでした。私たちはリリース日についてビジネスガイと話し合い、毎月のリリースという結果になりました。その後、管理のために毎日のスタンドアップミーティングと、改善のためにプロジェクト結論ミーティングを行いました。私たちは生産レビューとチームレトロスペクティブの両方を結論ミーティングに入れました。製品マネージャーは現状を説明し、すべてのチームメンバーは実績、課題、および不足について議論していました。計画ミーティングに関しては、最初からスクラムの手法をとりました。MS Projectは小さいプロジェクトに適していないため、スクラムExcelスプレッドシートに、そしてその後Xplannerに変更しました。

数カ月後、私たちは全員を呼び集めてアジャイルメソッド共有ミーティングを開き、使用したすべてのプラクティスをまとめて、XP、アジャイル、およびスクラムの意味について説明しました。ほとんどの人が、まるで夢から覚めたかのようでした。「わぁ、私たちは過去数ヶ月、スクラムを使用していたのですね!!!」と。

私たちの実績は上層部にも承認され、その経験を他のチームと共有することが許可されているため、試験的にいくつかのチームを選びました。開発者はチーム間を行き来する可能性もあるため、1つのチームがMS Projectを使用して、もう1つのチームがXPlannerを使用すると、管理コストがかかってしまいます。そのため、最終的に会社全体でスクラムを使用するよう指示されました。

Q3. 導入時のもっとも大きな問題は何でしたか、そして、それをどのように解決しましたか?

Julie:

まず、上司に支持してもらうことが必要でした。それから、実を言うと、スクラムの導入はかなり容易で、CMMIよりもはるかに簡単でした。

もっとも困難なことは、プロセスで明らかになった問題を解決しなければならないことです。たとえば、次のような問題です。:

1. 「要件が明確でないため、後の段階でコミュニケーションに高いコストがかかります。何度も製品マネージャーと話し合いをし、あまりに多くの時間をかけ過ぎています。」
2. 「納入サイクルが長すぎます。スプリントは3、4週間の長さですが、製品マネージャーは私たちが週に2つのバージョンを納入できることを望んでいます。」
3. 「スクラムの特徴により、歴史的要件と製品アーキテクチャをマスターすることができません。」
4. 「納入日はビジネスガイによって定められているため、ユニットテストもコードレビューも実行する時間がありません。」
5. 「タスク間のボトルネックや、皆を協調させる方法がはっきりと分かりません。」
6. 「開発後にデータを分析するために少なくとも1週間は必要であり、現在のスプリントの直後に改善を行う方法を断定することは不可能です。」
7. 「開発のペースが早すぎるため、立ち止まって適切なレトロスペクティブを行う時間が十分にありません。歴史的要件を十分に生かすことができません。」

kaverjody:

私にとって、最大の困難は同僚たちの間でアジャイルに対する誤解があることです。彼らは具体的なツールと開発プラクティスを理解しているかもしれませんが、決定の背景にある意図を理解していません。なぜ私たちはこれらのツールを選ぶのでしょうか? なぜこれらのプラクティスをピックアップするのでしょうか? 基準を持ってプラクティスを選んでいるのでしょうか? 選択過程で、唯一理解できるのはアジャイルの価値だけです。

目標をワンステップで達成する方法はなく、継続的に同僚を教育するしかありません。また、私たちは、行く行くは問題を分析および解決し、ケーススタディを保持し、なぜこのように問題を解決したか、そして、今後同じような問題にどのように対処するかを説明する必要があります。

Alex:

スクラムを導入するにあたって、次の2つの大きな問題があると思います。:

1. 上層部からの指示。
   これは共通の問題であると思います。しかし、Jeff Xiong氏はInfoQ ChinaでAgile step by step: how to do agile bottom-up(source)という記事を公開し、「上層部がスクラムを支持しない場合は、上層部を阻止して、とにかくチーム内部でスクラムを実行してください」と言っています。ありがたいことに、私たちのCEOとCTOはどちらもスクラムを支持しています。
2. 従業員のためのスクラムトレーニング。
   同僚たちはスクラムをはっきりとは理解していないため、私はスクラムトレーニングを編成しました。私たちは問題について一緒に議論しました。そして導入時には、皆、スクラムについてますますよく理解するようになりました。もちろん、スクラムを広める人はスクラムに精通していなければなりません。

その後、InfoQがそれらの解決方法について詳細に紹介してくれるよう皆に頼むと、Julie氏は次のように言いました。:

最初の問題である「不明確な要件」については、すべての要件文書に対する汎用テンプレートを作成しました。そして、計画ミーティングの前に要件の議論ミーティングを追加します。製品マネージャー、試験者、開発者が議論に参加するでしょう。

2つめの問題である「長い納入サイクル」については、定期的な納入のほかに毎日の「継続する」製品保守要求に対する管理を追加しました。製品マネージャーは「ページの編集」、「データの追加/削除」などの保守要件を収集します。これらの要件は、毎週火曜日と木曜日の朝に行われるスタンドアップミーティングで、技術者に提出され、その日の午後に発表されます。

Alex氏は次のように言いました。:

私たちはスクラムを導入する良い状況にあります。多分それは私がスクラムについてあまりよく理解しないで、一部の機能しか使用していなかったからですが、私は次のような信念を持っています。成功と失敗を繰り返してスクラムの独自のバージョンを見つけるべきです。私たちはたまたま、不明確な要件を伴うプロジェクトを抱えていました。スプリント計画ミーティング時に、既知の要件に基づいて技術上のステップをボードに書き出し、実行の順序を優先付けしました ... スケジュール全体を管理できるように、イテレーション（反復）は10日間だけでした。スタンドアップミーティングでは、皆、本日実行する予定の項目を挙げます。それにより、チームの自己組織化能力を改善できます。

Q4. スクラムはプロジェクトや会社にどんな利益をもたらしましたか?

Julie:

スクラムによってもたらされた利益を測定するのは難しいと思います。私たちは、チーム内部で調査を行い、一般情報をいくらか得ました。:

kaverjody:

ここでそれを断定するのは難しいです。私が分かっている利益には、次のようなことがあります。より頻繁に機能に関するフィードバックを得ることができること、そして、たとえばマルチサイト開発・協力や、レトロスペクティブや、改善など、初期の段階で問題を発見できることなどです。

Alex:

私たちは開発部門、販売部門、および人事部門を含め会社全体でスクラムを使用しています。新入社員にスクラムについて解説しなくても、彼らは毎日の仕事を通してスクラムを理解できるようになります。私は、収益がどれほど大きいかは答えられませんが、スクラムのおかげで幸せに張り切って仕事をすることができます。そして、期日までにイテレーション（反復）を完了しました。私たちは次のプロジェクトの準備をしています。要するに、まだスクラムを導入中です。

Q5. なぜスクラムの導入がうまくいかなかったのですか? その過程を説明してください。

David:

私たちの問題は、上層部の一部の人間がアジャイルとスクラムを誤解し、アジャイルを形式的なものにしたことです。たとえば、スクラムマスター（Scrum Master）を1つの大型プロジェクトに置き、それは順調に進みました。あるプロジェクトマネージャーがその素晴らしさを発見し、いくつかのプロジェクトでデイリースクラム（Daily Scrum）を推し進め始めました。しかし彼はアジャイルが何でスクラムが何かを知らないため、彼のせいでデイリースクラムはデイリーレポート（Daily Report b）になりました。そのため、スクラムのコア原則には従っていません。

全員が定刻にデイリースクラムに参加して、その日の作業についてマネージャーに報告する必要があります。その後マネージャーは、彼らがさらなる作業を行うべきかどうかを決定します。ひどいです。皆がそれを退屈過ぎると感じたため、「デイリースクラム」は結局中止されました。そしてその後、社内でアジャイルについて話す人はいなくなりました。

Fiona:

私は分散チームにいて、中国チームは当初アジャイルについて少しだけ知っていました。ある日、海外のPMはいくつかのリンクを私たちに送信してきました。それは、奇妙な単語「スクラム」に関する内容でした。スクラムに関する紹介文書を読む期間は1、2日しか与えられず、その後スタンドアップミーティングを開始しました。実際、誰もがコミュニケーションの重要性を知っていますが、6～7時間の時差があるため、彼らが朝出勤する頃、私たちは机を片付けて帰宅します。コミュニケーションは改善されず、1、2週間後に断念されました。中国チーム内でスタンドアップを実行しようとしましたが、最大の問題はチームとプロジェクト計画の間の文化の違いでした。スタンドアップミーティングは多くの価値をもたらすことなく、すぐに形式的なものになり、最終的に断念されました。

私たちには、計画ミーティングがありませんでした。いわゆるプロダクトオーナー（Product Owner）はいましたが、彼は各ストーリーの詳細を説明することも、Doneステータスを定義することもありませんでした。自分たちでレトロスペクティブを試みましたが、フィードバックで海外チームからの応答がなかったため、その後断念しました。

ScrumWorksを初めて使用したとき、プロダクトオーナーはすべてのストーリーの優先付けを行い、私たちは推定を行いました。しかし今では誰でもストーリーをScrumWorksに投じることができるため、どれが他よりも重要であるかを言う人はいません - 私たち開発者はそれを決定する必要があります。数百ものストーリーをこのスプリントに残したら、それらは次のスプリントに投じられるでしょう。

あまりに多くのことがこのプロジェクトで起こり、それがどんな困難であれ依然として継続しますが、社内でアジャイルについて話す人は私の気持ちを少しむかつかせるでしょう。

まとめ

この記事の中国語版(source)を終えた直後にAgile China Google Group(source)でスクラムに関する白熱した議論が起こりました。それについては後で報告するかもしれません。しかし私はシェークスピアの有名な言葉「ハムレットを読む千人の人の目に千人のハムレットが存在する」を思い出しました。では、あなたはスクラムをどう思いますか? そして、あなたの会社ではどのようにスクラムを導入しましたか? あなたの経験を私たちと共有してくれますか?

著者について

Jacky Liは、JavaおよびAgileソフトウェア開発を専門としている、InfoQ China/Agile Communityのリードエディターであり、中国でアジャイルを普及させることに貢献しています。彼は、InfoQミニブック: Starting Struts2の翻訳者でもあります。