ObjectSquare [2011 年 7 月号]

[レポート]


スクラム体験記

株式会社オージス総研
エンタープライズソリューション第3部
伊藤 宏幸

■はじめに

日本国内のシステム開発では、まだまだウォーターフォールが主流を占めています。※1
ですが、ウォーターフォールでは、時間もお金もかかる割には品質が上がらず、ユーザーの不満も多くなりがちです。
せっかくシステム開発をするなら、良いものを効率的に作りたい。
そしてそのために「アジャイル開発手法」に挑戦してみたい。
そう考えておられる開発者の方も多いのではないでしょうか。

一方で、そうは言うものの、どういうところに気をつけて「アジャイル開発手法」を実践していけばよいのかが分からずに不安を感じて、
適用に二の足を踏まれている方も多いのではないでしょうか。
また、適用はしたものの勘所が分からず、あまりうまくいかなかったなという感想をお持ちの方もいらっしゃるのではないでしょうか。

私はこれまで、「アジャイル開発手法」の1つである「スクラム」を、3つのプロジェクトで経験してきました。
スクラムプロジェクトに実際に参加してみると、書籍だけでは分からない多くのことに気づかされました。
今回のレポートは、これらのプロジェクトで得たスクラムの実践に当たっての個人的知見を、失敗例と成功例の2つの体験談を通じて展開することが目的です。※2

なお今回のレポートは、「スクラム」について、本やネット上の記事を読んである程度ご存じの方を想定読者としております。
また、実体験から得た知見の展開が目的ですので、理論上そうではないのではないか?という点が多々あることはご了承下さい。

この知見が、アジャイル開発をやってみたいのだけれども不安でなかなか一歩を踏み出せない方、
またスクラムの適用・実践で悩んでいる方の一助になれば幸いです。

※1 情報サービス産業における技術動向調査2009調査報告 〜浮き彫りになったソフトウェア開発実態の変化と今後の動向〜
       JISA 社団法人情報サービス産業協会 技術委員会技術調査部会技術動向調査WG
       2010/07/22
       17ページ

※2 もう1つのプロジェクトは成功でしたが、成功例と内容が被るため、今回の体験談からは外しました。

TOP ページのトップへ戻る

■体験談1:失敗編

【プロジェクト・チームの説明】

●プロジェクトの目的
Web による受発注システムの構築
※現在勤務している会社の前の会社で経験したプロジェクトです。

●チーム構成

仕様担当チーム (2名)  :  ユーザ側との仕様調整を担当。
開発担当チーム (10名)  :  アーキテクチャを含めたシステム開発を担当。

●ロール

PM  :  仕様担当チームのうち1名が担当し、プロジェクト全体を管理。
リーダー  :  1名で、実質開発担当チームだけを取りまとめた。
スクラムマスター  :  仕様担当チームの2名が担当。
各メンバーを、プロジェクト開始前に教育。
※その会社でスクラムを適用するのは初めてだったので、マネージャ層の教育・勉強を兼ねて、敢えてスクラムマスターを2名置くことにした。
  うち1名が PM を兼務し、もう1名が PM を補佐する形を採った。
プロダクトオーナー  :  ユーザ側の責任者が担当。

●プロジェクトの進め方

1スプリントを1ヶ月とし、計6回のスプリントを行う。
スプリント終了後、構築した機能をユーザ側(特にプロダクトオーナー)にデモする。
開発メンバーに対して、スクラムマスター主導で、スクラムの教育を実施した。
具体的には、プロジェクト開始前に勉強会を数回実施し、また書籍『スクラム入門−アジャイルプロジェクトマネジメント』をメンバー全員に読ませた。
プロジェクト開始前に、2日間の全体計画のミーティングを実施。
プロダクトオーナーを交え、プロダクトバックログの定義を行った。
各スプリント開始前に、1日間のスプリント計画ミーティングを実施。
プロダクトバックログを元に、開発メンバー主導でスプリントバックログのリストアップとタスクの割当てを行った。

●私の立場
1回目のスプリントでは開発担当チームのメンバーとして、
2回目のスプリントでは開発担当チームのリーダーとして参加。


【体験談】

●1週間目
毎朝15分のデイリースクラムでは、これまでとは違う開発手法を採用するのだという士気がメンバーから感じられる。
そのためか、問題らしい問題は特に上がってこない。
スクラムマスターもその士気の高さに応え、開発メンバーのやり方に任せることとした。
滑り出しは順調なようだ。

●2週間目
毎朝のデイリースクラムで、メンバー間の進捗にはっきりとした差が見え始めた。
進捗が遅れ始めたメンバーに理由を聞くと、「画面の仕様を全てきちんと提示してもらえないので、全く開発を進められない」との不満が出てきた。
画面の仕様が今回のスプリントでは一部だけしか決まらないこと、また今回はその一部を構築すればいいのだということは、事前に説明があった。
どうも、今までのウォーターフォールの手法に固執して、新しい開発手法に積極的になれないようだ。
そのことをリーダーが再度説明したが、「今までのウォーターフォールでは、前工程が全て済んでから次に進むようにしてきたので、
そんなことはできない」の一点張りで、首を縦に振らない。
他にも同様の理由で、作業を渋るメンバーが出始めてきた。
作業が徐々に滞り始めてきた。

●3週間目

開発を進めていくうちに仕様の不明点が見つかったため、スクラムマスター(仕様担当チーム兼任)へ確認を行った。
するとスクラムマスターは、それを今すぐ対応すべき要求と判断し、それを当スプリントのスコープとして急遽追加した。
開発後半で急遽作業スコープが増えたことにより、メンバーおよびスケジュールは大いに混乱した。
ウォーターフォールの手法に固執しているメンバーの進捗がいよいよ上がらなくなり、スクラムの手法を受け入れたメンバーが、その肩代わりをするようになる。
一方で、旧来の手法に固執しているメンバーが新しい手法を受け入れようという動きはない。
そのため、チームとしての作業バランスがさらに崩れ、混乱に拍車がかかった。
スプリントバックログの定義・各タスクの工数見積もりおよび割り当てはメンバーが主導で実施したが、スクラムに慣れるまでの工数を考慮に入れていなかったので、どうも生産性を高く見積もり過ぎたようだ。
自分たちで首を絞めてしまっていたことに気づき、メンバーがやり場のない怒りを抱くようになってきた。
上記のような状況にも関わらず、スクラムマスターは開発メンバーの間に入って調整するようなことはせず、開発のことは開発メンバーに任せるの一点張りだった。
役割の尊重といえば聞こえは良いが、要は調整作業の放棄だった。
プロジェクトの状況は、日に日に悪化していった。

●4週間目
スコープの増加と一部メンバーの大幅な進捗遅れとのダブルパンチで、毎日深夜まで残業しなければならなくなる。
特に最後の3日は、デモが控えているため、徹夜して状況の改善にあたった。
1月で1年分働いたような気分だ。

●デモを終えて
構築したシステムは、結局プロダクトオーナーの要望した基準に届かなかった。
スクラムマスターが複数名いることによる指示系統の競合などの問題は特に発生しなかったものの、経験不足などもあり、プロジェクト運営に当たって適切な指示・行動をとれたとは言い難かった。
また、メンバーの疲弊が非常に大きかったこともあり、プロジェクトは一旦中止となった。
結局2ヶ月後に体制を入れ替えて再開したものの、納期を半年以上遅らせることになった。
残念ながら、プロジェクトは失敗だったと言わざるを得なかった。

TOP ページのトップへ戻る

■体験談2:成功編

【プロジェクト・チームの説明】

●プロジェクトの目的
Web による顧客情報管理システムの構築
※私が現在勤務している会社で経験したプロジェクトです。

●チーム構成

アーキテクチャチーム (3名)  :  アーキテクチャの構築を担当。
画面チーム (5名)  :  フロントエンド(画面まわり)の開発を担当。
サービスチーム (5名)  :  バックエンド(サービス・バッチ)の開発を担当。

●ロール

PM  :  3チームを束ねる位置にいて、プロジェクト全体を管理。
リーダー  :  チーム毎に1名おき、各チームの取りまとめを実施。
スクラムマスター  :  PM が担当。
各チームリーダーおよびチームメンバーを、必要に応じて教育・ファシリテート。
プロダクトオーナー  :  ユーザ側の責任者が担当。

●プロジェクトの進め方

1スプリントを1ヶ月とし、計3回のスプリントを行う。
スプリント終了後、構築した機能をユーザ側(特にプロダクトオーナー)にデモする。
開発メンバーに対して、スクラムマスターとリーダーが主導して、スクラムの教育を実施した。
具体的には、プロジェクト開始前に勉強会を数回実施し、またプロジェクト実施中も必要に応じてスクラムマスターとリーダーがメンバーに適宜 OJT 形式で教育を行った。
プロジェクト開始前に、2日間の全体計画のミーティングを実施。
プロダクトオーナーを交え、プロダクトバックログの定義を行った。
各スプリント開始前に、1日間のスプリント計画ミーティングを実施。
プロダクトバックログを元に、開発メンバー主導でスプリントバックログのリストアップとタスクの割当てを行った。

●私の立場
サービスチームのメンバー兼リーダー補佐として参加。
スクラムを経験していることから、必要に応じてアドバイスを実施。


【体験談】

●1週間目
毎朝15分のデイリースクラムでは、進んでいる点よりも困っている点を、メンバーに優先的にあげてもらうようにした。
すると、スクラムのやり方がしっくりこない人がおり、ヘルプが欲しいとのことだった。
そのため、スクラムマスター・リーダー・他メンバー共同でその人を早期・優先的にフォローするようにした。
滑り出しから問題が起きたが、みんなで解決していこうという雰囲気になった。

●2週間目

毎朝のデイリースクラムで、進捗の遅れるメンバーが出てきた。
進捗が遅れ始めたメンバーに理由を聞くと、「画面の仕様を全てきちんと提示されていないが、この場合どう開発すれば良いだろうか」というものだった。
そこで、リーダーを中心にチーム全体で話し合い、(進捗の進んでいる)スクラムのやり方になじんだメンバーが開発方法を教える形でフォローするようにした。
それにより、困っていたメンバーもすぐに解決方法を理解し、進捗の遅れを早期に回復できた。
開発を進めていくうちに仕様の不明点が見つかったため、スクラムマスター(PM 兼任)へ確認を行った。
スクラムマスターはすぐにプロダクトオーナーに確認を行い、必要な機能であれば次回以降のスプリントに含めるよう、また不要な機能であればスコープから落とすよう説得した。
プロダクトオーナーもこの状況をすぐに理解してくれ、無理なスケジュールにならないよう調整ができた。
スクラムマスターは、リーダーを介して早期から各チームのやり方に積極的に関与し、リーダーを中心にチームとして早急に改善策を出すようにした。

問題は確かにおきているが、一つずつきちんと解決することができている。

●3週間目
毎朝のデイリースクラムで、当初スクラムのやり方がしっくりこなかった人が徐々に慣れてきて、進捗があがるようになってきたことが分かる。
このことは、日に日に減っていくバーンダウンチャートからも明らかだ。
また、ボトルネックは相変わらず発生するものの、デイリースクラム及び日々のインフォーマルなヒアリングですぐにそれらを発見・対処しているので、チーム全体の進捗に悪影響を及ぼすには至っていない。
また、スプリントバックログの定義・各タスクの工数見積もりおよび割り当てはメンバーが主導で実施したが、スクラムマスターのアドバイスもあり、スクラムに慣れるまでの工数を考慮に入れて、初期のスプリントでは生産性をやや低めに見積もったことも功を奏したようだ。
日に日に、メンバーの士気が上がっていくことが実感できる。

●4週間目
終盤の詰めで多少の残業はあったものの、深夜残業や徹夜は1日もせずに済んだ。
また、メンバーがボトルネックの発見・解決に慣れ、進捗を妨げる問題は事前に回避できるようになってきた。

●デモを終えて
メンバーの疲弊もなく、プロダクトオーナーの要望した基準を満たしたシステムを構築することができた。
その後追加要望などがあったものの、最終的にほぼ予定通りの時期にシステムをリリースすることが出来た。
プロジェクトも予算・納期内に完了し、ベンダー・ユーザともに Win-Win の関係を築くことができた。

TOP ページのトップへ戻る

■実践で得たスクラムの知見

上記の体験談は、意図的に問題個所を際立たせるような書き方をしていますが、いずれも実際に私が体験したものです。

私はこうした体験から、スクラムの実践に当たって、次の6つの点に注意する必要があると考えています。

  1. チームのベクトルをスクラムに合わせること
  2. ボトルネックを管理し、チーム全体で解決を図っていくこと
  3. スプリント中に作業量を増やさないこと
  4. 試行錯誤を考慮したスプリントの計画を立てること
  5. メンバーも変化を受容すること
  6. 見える化でチームの士気を上げること

【1.チームのベクトルをスクラムに合わせること】

スクラムでは、動作するシステムを短期間で徐々に構築していくため、TDD(Test Driven Development)やイテレーティブ・インクリメンタル開発など、ウォーターフォールの手法とは異なる手順・テクニックを適用する必要があります。
ですが、メンバーが今までのウォーターフォールの手法に固執してしまい、新しい開発手法になじめないままプロジェクトを進めてしまうと、そのメンバーがチームのボトルネックとなってしまい、チーム全体の進捗を下げることになってしまいます。

チームのベクトルをまず最初にスクラムに向けないと、チーム環境は破壊的なものになります。
ですので、スクラムの実施に当たっては、チームメンバー全員がスクラムの手法で作業する/スクラムのルールに準拠して行動するよう、特に意識してチームビルディングすることが必要です。

アメリカの心理学者 Bruce Tuckman の Tuckman's stages(Tuckman's FSNPA(Forming, Storming, Norming, Performing, Adjourning))モデルにおいて、チームの発展段階の1つとして「動乱期」というものがありますが※3※4
スクラムの場合は特にこれまでと異なる手順・テクニックを用いることが多くなりやすいので、慣れないチームメンバーが非協力的になる恐れが大きいです。

具体的な対策としては、以下のものが効果的だったと思います。

  1. スクラムマスターを中心に、継続的にメンバーの教育を行うこと。
  2. 初期スプリントでは、慣れていないメンバーのフォローをチームとして推奨すること。
  3. 慣れていないメンバーがスクラムの手法で成果を出したら、チームメンバー全員で褒めること。

※3: Tuckman's FSNPA については、下記の記事でも紹介しております。
        講演「ファシリテートされたワークショップ:力を合わせてニーズを定義する」の日本語訳(後編)

※4: 『PMBOK ガイド第4版』 「プロジェクト人的資源マネジメント」 「プロジェクト・チーム育成」プロセス 「チーム形成活動」 232ページ〜


【2.ボトルネックを管理し、チーム全体で解決を図っていくこと】

毎日のデイリースクラムでは、前日の実績と今日の予定、そして今抱えている問題点を各自説明することになります。
ですが、ここで特に意識をしないと、メンバーは良かった点だけを報告して終わりになってしまいがちです。
それでは、問題を早期に発見して対処することが難しくなってしまいます。
なので、チーム全体として、悪い情報およびチームのボトルネックになり得る情報を、積極的に報告し共有するようにした方がよいです。

スクラムでは、短期間で動くシステムを構築することになるため、各メンバーの作業成果が全体の進捗により直結するようになります。
そのため、特定のメンバーの遅れが、スプリント全体のボトルネックとなる可能性が高くなります。
なので、チーム全体でボトルネックを発見し、チーム全体でそれらを解決していく態度が重要です。

そういった意味では、スクラムマスターは早期から開発メンバーのやり方に積極的に関与し、メンバーと共に早急に改善策を出すようにしていった方が良いでしょう。


【3.スプリント中に作業量を増やさないこと】

これは、特にスクラムマスターが気をつける必要のあることです。

例えば、1ヶ月間で1回のスプリントを行うとしましょう。
スプリントを開始するにあたっては、その1ヶ月間で行うスケジュール(段取り)および成果物を事前に決めてから作業に取り掛かります。
そしてメンバーは、その1ヶ月間に決めたタスクの実現に全力を注ぎます。

もしそこに、突然新たな作業が増えたらどうでしょう。
それまで予定していたスケジュールを全て変更しなければならなくなるので、メンバーは混乱します。
また、普通1ヶ月でギリギリできる量を事前にアサインするので、新たな作業が増えると工数はオーバーし、無理な残業などで対処しなければならなくなります。

なので、原則スプリント中に作業量は増やさない方が良いです。

スクラムマスターは、勇気を持って、スプリント中に作業量を増やさないようにする必要があります。
ユーザにとって必要な機能なのであれば次回以降のスプリントに含めるよう、また不要な機能なのであればスコープから落とすよう、ユーザ(またはプロダクトオーナー)を説得する必要があります。
この点は、ユーザ側の合意も必要なので難しいところもありますが、チームとして成果を出し続けるためには、スプリントの開始時点で決めた作業スコープを守ることが必要です。


【4.試行錯誤を考慮したスプリントの計画を立てること】

アジャイル開発の初心者が多い場合、試行錯誤が色々と発生します。
そのため、初期のスプリントでは、解決できるバックログの量は少なくなりがちです。
このことを考慮せず、どのスプリントでも同じ生産性で計画を立ててしまうと、目標を達成できずにプロジェクトのリスケを繰り返すという悪循環に陥りがちになります。

なので、初期のスプリントでは、開発生産性の低さを考慮して計画を立てることが重要です。
一方で後続のスプリントでは、学習効果による開発生産性の向上を計画に織り込むと良いでしょう。
要は、一律同じ生産性で見積らないようにすべし、ということです。

スプリントバックログの定義・各タスクの工数見積もりおよび割り当てに際しては、スクラムマスターがメンバーに対して、この点を適切にアドバイスする必要があります。


【5.メンバーも変化を受容すること】

これは、特にメンバーが気をつける必要のあることです。

上記の「1.チームのベクトルをスクラムに合わせること」にも関連しますが、メンバー自身がこれまでのやり方を変えていくことを受容しなければ、スクラムのやり方でよいパフォーマンスは出せません。
よく XP(eXtreme Programming)で「変化を受容せよ」(embrace change)という言葉が使われますが、システムだけではなくメンバーも、変化を受容していく必要があります。

また上記「2.ボトルネックを管理し、チーム全体で解決を図っていくこと」にも関連しますが、チームの状況・ボトルネックは刻一刻と変化していきます。
メンバーはこうしたプロジェクトの変化も受容し、フレキシブルに対応していく必要があります。

変化を受容できる、自立的で責任あるメンバーが、スクラムでは求められます。


【6.見える化でチームの士気を上げること】

スクラムでは、スプリント内でのバックログの消化量を目に見える形で表現できる「バーンダウンチャート」を活用します。
これは、スプリントが後半になるにつれて、バックログが目に見えて減っていく様を実感できるため、状況把握だけではなく、メンバーの士気を高めることにもつながっていきます。
私も実際に体感しましたが、士気が上がり迷いの少なくなったメンバーは、より高い成果を上げられるようになります。

「バーンダウンチャート」を活用して、メンバーのやる気を引き出していきましょう。


TOP ページのトップへ戻る

■最後に

弊社では2011年4月より、「ソフトウェア工学センター」を「アジャイル開発センター」に改組し、大規模プロジェクトでアジャイル開発を適用していくためのご提案をさせていただいております。
同センターでは、「スクラム」と「アジャイル UP」とを組み合わせた「OGIS Scalable Agile Method(OSAM)」という手法を提案しております。
詳しくは、こちらのページをご確認下さい。

TOP ページのトップへ戻る

■参考とした書籍

●スクラム入門−アジャイルプロジェクトマネジメント
Ken Schwaber 著
(株)テクノロジックアート訳、長瀬 嘉秀 監修
日経BPソフトプレス
2004/09/02出版
ISBN:978-4891004408

●アジャイルと規律−ソフトウエア開発を成功させる2つの鍵のバランス
Barry Boehm, Richard Turner 著
ウルシステムズ 河野 正幸/原 幹 監訳、越智 典子 訳
日経BP社
2004/08/05出版
ISBN:978-4822281922

TOP ページのトップへ戻る


© 2011 OGIS-RI Co., Ltd.
HOME TOP
HOME TOP