事例研究：Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

作者 Marco Mulder and Martin van Vliet , 翻訳者 渡辺 裕之 投稿日 2008年12月2日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

Agile ,

ケーススタディ ,

Agileの採用

タグ

分散チーム ,

Scrum

スクラムはプロジェクトに実行に際して確実な土台を提供します。しかし、どんなプロジェクトにおいても特定のニーズや状況へスクラムのプロセスを対応させる必要があります。どのようにして対応させるかというのがプロジェクトの成否を左右する重要な要素となるのです。この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。このプロジェクトは過去に一度、伝統的なアプローチで頓挫していました。読者が大規模なスクラム・プロジェクトで成功することを願い、ここに私達がプロジェクトの立ち上げ、正しいプロダクト・オーナーの選択、見積もりの重要さ、効果的なコミュニケーション、テストとドキュメント作成について得た教訓を共有したいと思います。

背景

Dutch Railwaysは世界有数の乗降客の多い鉄道で、1日当たり120万人の乗降客が利用します。Dutch Railwaysは旅行客により少ない手間で、より正確な旅行情報を提供する新しい情報システムを構築しました。この計画の一部として私達は、中央制御によって各駅への画面情報と音声配信をする、PUB(publish:公表)システムを構築しました。

PUBシステムを構築する最初の企画は伝統的なウォーターフォール手法によって実行されました。詳細な要求仕様がITベンダーに渡され、それ以上顧客側が関与することなく完璧なシステムが実現されると期待されていました。そのベンダーが稼働するシステムを提供できなかったことにより、3年後にそのプロジェクトは中止されました。そうしてDutch Railwaysは私達の会社に一からPUBシステムを構築する発注をしたのです。私達はスクラムを利用したアジャイル手法を提案し、顧客の密な協力、オープン・コミュニケーションそして少しずつ開発していくことに集中しました。

準備

私達は最初のスプリントを始める前に、必要な物を全てそろえるためのキック・オフから始めました。この3週間のキック・オフはプロジェクト・マネージャ、アーキテクトそしてスクラム・マスタによって行われました。

プロダクト・オーナーの選択はとても挑戦的なものでした。十分な時間があり、業務知識があり、要求を優先順位付けする権限を持った個人を見つけることができませんでした。そこで私達はプロダクト・オーナーの役に二人のビジネス・アナリストを任命しました。彼らなら時間を割くことができ、また、以前のPUB構築プロジェクトへの参画経験から多くの業務知識を蓄えていたので顧客側のステーク・ホルダーにとって十分なプロダクト・オーナーの代理となったのです。優先順位付けやスコープに関する高度な判断は顧客から権限を委譲されたプロジェクト・マネージャが行いましたが、その人は十分な時間を割くことができず、要求については詳細な知識を持ち合わせていませんでした。ほとんどの場合はこのやり方でうまく行きましたが、何度か、終えたばかりの(プロジェクト・マネージャが欠席した)計画会議で決定した優先順位をプロジェクト・マネージャが変更したために会議を開きなおさなければならないことがありました。

前回のPUBシステム構築プロジェクトのおかげで、システムの一部については詳細な要求仕様書を手に入れることができました。それらはMIL規格に準拠していました。この形式だとスプリントで構築、テスト、デモするための小さいグループにまとめらていないのでアジャイル開発における計画と見積もりには不向きでした。そしてプロダクト・オーナーはユーザ・ストーリーの記述経験がありませんでした。これを解決するために初めのいくつかのイテレーションについてはスクラム・マスターがきめ細かいユーザ・ストーリーを含む初期の製品バックログの作成を手伝いました。

私達が構築したソフトウェアは多くのソフトウェア・システムと関連する大きなプログラムの一部で、それによって駅における画面表示を構築しています。これら多くとの調整のために納期の遵守が必須でした。従って、私達は計画の完全な全体像を提供する必要がありました。いくつかのイテレーションの後、これらの機能について'可能な限りの'見積もりを作成することでこの問題を解決しました。その頃には、自分達の開発速度について確信の持てる精度の情報を蓄えていました。従って、作成したバーンダウン・チャートを使うことでプロジェクトの状況の追や、進捗状況の共有がとてもよく出来ました。このことで学んだのはどんな見積もりでもないよりはマシということです。例えほとんど情報が入手できないとしてもです。

分散チームへスケール・アップ

キック・オフの後、プロジェクトは7人のメンバから成る1つのチームが2週間単位のイテレーションを行う体制でスタートしました。プロジェクトの開始当初からインドにいる要員を使って体制を拡張することが決まっていました。このため2人のインド人開発者が最初のスプリントからプロジェクトに参画していました。彼らはアプリケーションの扱う領域、顧客側の代表者やその他の開発チーム・メンバに親しむために6週間を顧客の拠点でオン・サイトで働きました。

チームを作り上げる第一歩は仕事の仕方について合意を形成することです。これを促進するためにインドからの仲間を含む、チーム・メンバ全員による標準化と憲章を決める会議を開催しました。このセッションで私達はペア・プログラミングの方法、ツールの利用法、品質目標、コア・タイムなどの取り決めを行い、Wikiページに記録しました。チーム全体で共有された合意事項はとても役に立ちました。例えば振り返りの際に、これらの合意事項に変更があった場合はチームに新しいメンバが加わった時に最新の状態となるようにその取り決めについては更新しておく必要があります。

最初のイテレーションで、このシステムの中核を成すと思われるユーザ・ストーリーについて構築、テスト、デモンストレーション可能であることを示しました。このことは顧客をとても喜ばせました。というのも、とりわけ前回の企画と比較して、進捗状況がより早く示されることでプロジェクトの方向性についてよりコントロールすることが出来たからです。

2，3のイテレーションの後、プロジェクト体制を拡張しました。インド人開発者は国に帰り、それぞれ5人の開発者からなる1人のテスターを共有する2つのスクラム・チームを構成するためにインドとオランダに要員を追加しました。後には3人のテスターと3つの開発チームに拡張しました。私達のアプローチのカギはどちらのスクラム・チームにもそれぞれインドとオランダの要員がいたことです。この手法は高い開発速度と品質を維持するのに成功しました。

では、どのようにして複数の拠点からなる1つのチームで共同作業をしたのでしょうか？まず、私達はSkypeを徹底的に使いました。ウェブカム、ヘッドセット、優れたマイクそして大きな画面を確保しました。こうして私達は全体会議と同様に1対1の会議も行うことができました。全て手元にあったものとフリー・ソフトだけで実現できました。停電の場合でもSkypeのセッションが継続できることを保証するためにインド側のネットワークにUPSを設置した以外、特別な投資は一切不要でした。次に、ペア・プログラミングの相手は同一拠点に限定しました。これはつまりインドとオランダそれぞれにペアがいたということです。私達の経験では、ツールの有無によらずペア・プログラミングの相互作用を得るには尚も物理的に同じ場所にいる必要がるということが分かりました。

そして、私達は誰が何を担当していてスプリントの進行状況がどうなっているのかを確認するためにScrumWorksというツールを使いました。チームが分散していたのでホワイトボードを使うより向いていました。ScrumWorksはプロダクト・オーナー達とバックログについて話し合うときにも役立ちました。

 

この分散開発の手法を導入するためにいくつかの挑戦をしなくてはなりませんでした。例えば、プロダクト・オーナーは英語を話すことに抵抗がありました。スクラムでは、スプリント計画ミーティングは２つの部分から構成されます―まず最初の部分でプロダクト・オーナーがチームと一緒になってユーザ・ストーリーを明確化しスプリントに向けて優先順位付けを行います。言葉の壁があったので、この部分はインド人要員を除いてオランダ語でミーティングを行うことにしました。計画ミーティングの残りの部分はSkypeを使ってインドの開発者と一緒に、プロダクト・オーナー抜きで、英語で行いました。最初の部分の内容についてコミュニケーションをとるために余計に時間を費やしました。スプリント・デモはオランダだけで行いました。インドにいる要員に最新の情報を伝えるため、オランダのチーム・メンバがデモについて社内報のようなものを書きました。これは社内全体にも配信され、同僚全員に親しまれたことが分かりました。

アーキテクチャに焦点を当てたチームの分割

私達のプロジェクトは一連のアプリケーションの一部でしたので顧客の既存のIT基盤に合致しなくてはなりませんでした。私達のプロジェクトのプロダクト・オーナーは中心となる機能面の要求についてはとても詳しかったのですが、セキュリティ、ロギング、可用性やパフォーマンスといったことについてはあまり詳しくありませんでした。異なる部署の多くの人との調整が必要なため、これらの要求を顧客から吸い上げるのは難しいことでした。このような調査を要する仕事はスクラムのイテレーションのリズムを乱します。この問題に対処するため、私達はアーキテクチャに焦点を当てた別のチームを作ることにしました。彼らの仕事はバッグログに向けて私達がそれらの要求をユーザ・ストーリーに取り込めるように非機能要求を明確化することでした。'スクラムのスクラム'ミーティングを開いて機能要求と同期をとるようにしました。機能開発チームが最高速で作業できるのでこのやり方で取り組んだのはとてもよかったと思います。そして、何人かにとっては'アーキテクチャ・チーム'で働くことは良い転機となったようです。

ドキュメント作成

顧客からはMIL規格に準拠した詳細なドキュメントの提出を求められました。さらに、それらはオランダ語で記述する必要がありました。ドキュメント作成はオランダの要員にしかできないことは明らかでした。しかし、開発者やテスターはMIL規格には精通しておらず、ユーザ・マニュアルのようなドキュメントを作成することは彼らのコア・コンピテンスではありませんでした。従って私達はMIL規格のドキュメント作成経験があるテクニカル・ライターを雇うことにしました。この方法は成功しましたが、テクニカル・ライターと他のメンバトの間に多くのコミュニケーションが必要になるということを発見しました。開発者は'自分達の仕事に専念'したがるのでこのことは留意する必要があります。

要求

私達のプロジェクトのプロダクト・オーナーはビジネス・アナリストで、通常はオランダ語で詳細な要求仕様書を作成しています。私達のプロセスではバックログにあるユーザ・ストーリーと計画ミーティングでプロダクト・オーナーから受ける説明だけで十分です。ところが、顧客からは詳細な要求仕様書の提出を求められました。スクラム・プロセスでこれを達成するため私達はプロダクト・オーナー協力の下、要求仕様をユーザ・ストーリーに変換することにしました。その結果、要求仕様が2か所で管理されることになりました。要求仕様書とバックログです。このことで要求が変更された際に何度か問題になったことがありました。プロダクト・オーナーが要求仕様書だけではなくバックログの内容にも責任を持つように幾度となく指導する必要がありました。

短いユーザ・ストーリーに加えてプロダクト・オーナーによる説明、私達のスクラム・チームでソフトウェアを構築しテストするにはこれだけで十分でした。私達にとってはこれ以上の要求仕様書は不要でした。しかし、外部のテスト・チームがテストするのにとっては要求仕様書は価値のあるものでした。それでも、いくつかのイテレーションで私達が実装したユーザ・ストーリーを要求仕様書の特定の部分にマッピングするのは難しいことでした。

振り返ると、私達は特定の要求管理プロセスを持っていませんでした。反復開発するのに必要なユーザ・ストーリーと顧客の要求する詳細な要求仕様書という競合する要望がある状況に対して、ただベストを尽くしただけでした。

テスト

私達はプロジェクトの期間中、各スプリントが終了する時点でデグレのないテスト済みのソフトウェアを配布するためにテストの自動化を行いました。システムが大きくなっても8名のスクラム・チーム当たり1名のテスターで高品質を維持するためにこの方法を継続しました。外部のテストでは1KLOC当たり1つの欠陥しかみつかりませんでした。

私達は単体テストと受け入れテストという2つのレベルでテストを自動化しました。前者に対してはJUnitを使い、カバレッジの測定にはCloverを使ってサーバ・サイドのコードに対して80%のカバレッジを目標にしました。受け入れテストはFitNesseを使って自動化しました。実装された全てのユーザ・ストーリーに対して受け入れテストがFitNesseで記述されました。詳細なテスト・スイーツがあることで、デグレは通常スプリントの最中に発見して潰すことができました。このアプローチのもう一つの優れた点はテスターがスプリント開始当初から有効に機能するということです。ユーザ・ストーリーの実装の前にテスト・ケースを作るのです。

一つだけテストの自動化で苦労した領域がありました。システムの一部に複雑でリッチなインタフェースがありました。この部分のテストの自動化がサーバ・サイドのテストより難しいことが分かりました。そこでユーザ・インタフェースの機能については大きく手動によるテストに依存することになりました。システムが大きくなるに連れ、リグレッション・テストにどんどん時間がかかるようになりました。さらに悪いことに、外部のテスターはシステムのこの部分にだけデグレを発見したのです。テストが自動化されていればこれは防げたかもしれません。このことで学んだことは、時にテストの自動化は難しいこともありますが、プロジェクトが進めば必ずや元は取れるだろうということでした。

成果

顧客は私達の納品物にとても満足していました。後から思えば多くプロジェクト同様、プロジェクトが進むに連れ機能要件、納期と予算は変わって行ったので、"納期達成、予算達成"は成果に対する尺度としては曖昧な物になってしまいました。もっと重要なことはプロジェクト中に顧客とよく議論を交わし、彼らがその結果に対して満足を表していたことが成功要因だということです。残念なのは全国的な展開は同じく新しいシステムの一部であった別のシステムの問題によって遅れてしまったことです。

顧客はこのソフトウェアについて外部の監査法人に依頼したところ、以下のような結論が得られました。:

• システムの保守性はとても良好です。
• ソース・コードの品質はとても高いです。

彼らのプレゼンテーションで監査人はこれほど多くのプラス要因が指摘されたプロジェクトはかつてなかったとコメントしました。

まとめ

以下は私達がこのプロジェクトから学んだ重要な教訓になります。:

• 要求に詳しくかつ優先順位の決定権を持ったプロダクト・オーナーを見つけるのは難しいかも知れません。複数の人間でプロジェクト・オーナーの役割を担うことは、とりわけ大きなプロジェクトでは、避けられないことも多くあります。
• 納期の遵守が重要である場合、確実にバックログが完全で見積もりがされていることが重要です。要求については、例えほとんど情報が得られていないとしても、どんな見積もりであってもないよりはマシです。チームの開発速度と合わせることで、リリース計画にとって重要な情報となります。
• スクラムは複数の分散チームで実施するのに適しています。それぞれのスクラム・チームにオランダ、インド両方の要員がいたことでチーム・スピリットによい影響があり、効果的なコミュニケーションに努めることになりました。既存のハードウェアとフリー・ソフトによってこのようなコミュニケーションを低コストで実現することができます。
• 分散プロジェクトの開始当初にチームの習慣について合意するため一つの拠点から始めることはとても有意義です。
• スクラムのスプリントで取り組むには相応しくない仕事(例えば、人を追って調整したり、顧客の他部署と接触することなど)については別のチームを分けることで効率的にこなすことができます。これによって機能開発チームはソフトウェアの開発に専念できます。専任のテクニカル・ライターを用意することも、コミュニケーションのオーバーヘッドを増やすことになりますが、同様に役に立ちます。
• ソフトウェア開発のプロセスには不要であっても、顧客にとっては尚も詳細な要求仕様書は必要なものかも知れません。しかし、スクラム・プロジェクトではこれはユーザ・ストーリーに置き換えられるものではありません。もし両方が必要なら、二ヶ所に記述された要求内容を一致させるためのオーバーヘッドを計画段階で組み込んでおく必要があります。
• ソフトウェアを少しずつ納品していくには自動テストは不可欠であり、デグレを防ぐことができます。プロジェクトが終了するより前にコストを超える見返りが得られます。

出典

[1] MIL-STD-498 , The Standard (リンク)

[2] Agile Estimating and Planning, Mike Cohn, 2005

[3] Team norming and chartering (リンク), Martin van Vliet,

[4] Fully Distributed Scrum: The Secret Sauce for Hyperproductive Outsourced Development Teams (リンク), Jeff Sutherland, Guido Schoonheim, Eelco Rustenburg, Maurits Rijk,

著者について

Martin van Vliet氏とMarco Mulder氏はいずれも10年以上のエンタープライズ・システム開発の経験があります。オランダにあるXebia社で働いています。Xebia社は国際的なアジャイル・ソフトウェア開発企業で、オランダ、フランス、インドに事務所があります。Xebia社はJava技術、アジャイルによるオフショア、アジャイル・プロジェクト、アジャイルのコンサルタント、そしてトレーニング、ITアーキテクチャとIT監査に特化しています。http://www.xebia.com/をご覧ください。

 

原文はこちらです：http://www.infoq.com/articles/dutch-railway-scrum
（このArticleは2008年8月12日に原文が掲載されました）

• 次へ >