連載
» 2004年10月05日 12時00分 UPDATE

SCRUMワークショップ体験記:アジャイル開発手法「SCRUM」の真実 (2/3)

[関根信太郎, 黒坂輝彦,@IT]

ワークショップ1日目

 ワークショップ開始15分前に会場に到着したわれわれは、指定されたSDフォーラムの教室に入った。アメリカの建物の部屋にしてはずいぶん狭く、机がかなり近接して配置されている。日本の中学校の教室よりも狭い。すでに半分ぐらいの席が埋まっていて、受講者たちは用意された軽食を食べたりコーヒーを飲みながらワークショップ開始を待っている。徐々に席が埋まっていき、9時ころになると満席になるが、それでもまだ受講者が来る。どうやらオーバーブッキングしたらしい。この狭い部屋に45人詰め込もうというのだから当然だ。

 シュエイバー氏らしき人が出てきて、どうやって机といすを配置し直して45人詰め込めばいいかを受講生たちと相談。全員で、机といすを動かすところからセミナーがスタートした。また、週末開けでエアコンがまだ完全に機能していないということで、扇風機が持ち込まれた。混とんとした状態。スクラムのホームページのアドレスはhttp://www.controlchaos.comだが、「混とんを制御せよ」(Control Chaos)がキャッチフレーズのスクラムにふさわしいワークショップの幕開けに、これは演出ではないかと疑ってしまった。

 著者らは、スクラムについて最初から丁寧に2日かけて説明してくれることを期待していたが、その期待は最初から裏切られた。シュエイバー氏の最初の質問は、スクラムを実際に使っている人はどのくらいいますか、というものであり、半分以上の参加者がすでに何らかの形でスクラムを導入していることが分かったからだ。スクラムの基本を手取り足取り教えてくれるわけではなく、基本が大体分かっている人を相手に、現実に直面する問題を考えていくという形で授業は進められた(注1)。


(注1) ただ、ワークショップの実施要項に、事前にシュエイバー氏の著書(邦訳の書名は「アジャイルソフトウェア開発スクラム」:巻末資料参照)を読んでくることという項目があって週末に慌てて読んだおかげで、筆者らも何とか落ちこぼれることなくワークショップを受けることができた。


 このワークショップは、ワークショップという名前どおり、ただ先生の話を聞くだけではなく、参加が求められる。参加者同士が組になって話をしたり、問題を解いたりという時間が、講義の時間と交互に行われるようになっている。最初に行われたのは、近くの人とペアになって、スクラムの経験を話す、というものだった。このとき、黒坂の相手となったのは、ベテランのエンジニアという感じの男性であったが、後に米国連邦準備銀行(Federal Reserve Bank)のシステム部門に勤務していると聞いて、著者らは驚いた。金融関係といえば、正確さが何よりも求められ、仕様をはっきり決めるウォーターフォール型開発技法の最後のとりで、という認識があったからだ。話を聞くと、米国連邦準備銀行では、いくつかのプロジェクトですでにアジャイル型開発技法が採用されているそうだ。スクラムは、すでに思ったよりも広い分野で実際に使われているらしい。

 また、参加者をいくつかの班に分け、疑似プロジェクトを与えて、実際にどうスクラムを運用していくか、という演習がフェイズに分けて行われた。ここで使われた疑似プロジェクトは、プロ野球やプロ・バスケットボール・リーグに関するものであることから、恐らくシュエイバー氏はスポーツ観戦が趣味であると推定される。

 このワークショップのもう1つの特徴は、体を動かすゲームが随所で取り入れられていることだ。これは主にピーターソン氏が主導した。SDフォーラムの1つの部屋に全員移動して、さまざまな演習を行った。最初の演習は、「自分のプロジェクトが完ぺきにうまく運営されていると思う人はこっちの端、全く駄目だと思う人は反対の端、中間の人はうまくいっている度合いに応じた場所に立ってください」というものだった。

 結果は、70%ぐらいうまくいっている人と、10%のところに多くの人が集まり、中間は薄い、という分布になった。こういう質問をされると日本人なら皆真ん中に行きそうなものだ。さすがアメリカ人である。2回目の演習は、ペアになり、一方がもう一方にロボットを操縦するように命令して、あることを行わせる。次に、今度は同じことを自発的に命令なしで行って、どっちが簡単かを確認するものだった。このように体を動かす演習が最初の日だけで4回行われた。この時間は、スクラムを実感する、ということもあるが、睡魔よけとしてもよく機能した。大学生時代から講義の時間には眠ってしまう筆者にとっては、大変助かった。

 座学の方は、「スクラムの禅(The Zen of SCRUM)」という題名のスライドに沿って、シュエイバー氏が自分の経験に基づくコメントを入れ、随時質問に答えるという形で行われた(注2)。


(注2) ここで禅という言葉が出てくるのは、スクラムが日本と関係しているからではない。アメリカでは、禅という言葉が、日本とは少し違う意味で普及している。


<プリマベーラ社の事例>

 今回の講義でよく引き合いに出されたのが、プリマベーラ(Primavera)社の例である。この企業は、特定業界向きのプロジェクト管理ソフトウェアパッケージを販売している。従来は、典型的なウォーターフォール型の開発技法を採用していた。そのためかどうか、通常、エンジニアは製品のリリース前3カ月間は残業/休日出勤が当然だった。にもかかわらず、苦労して開発した製品はリリース時にはすでに時代遅れとなってしまっていた。そのため、製品開発部門と他部門の間で深刻な確執があった。そこへシュエイバー氏自らがコンサルタントとして乗り込み、スクラム手法を使って開発体制を再編した。この事例については、http://www.controlchaos.com/download/Primavera%20White%20Paper.pdfに詳しい。



 ところで、すでにスクラムを実践している人たちがこのワークショップを受講しても退屈なだけではないかと思われるかもしれないが、そうではない。このワークショップでは、教科書に書いていない実践的なことが語られるからだ。例えば、スクラム手法のプロジェクトと伝統的手法のプロジェクトの混在環境では、どうすればいいか? ということが、シュエイバー氏の経験と参加者の経験を基に語られた。スクラムを採用した場合のソフトウェア開発請負契約は、どういうところを注意しなければいけないか、という現実的な話もあった。

 さて、開発手法というのはそもそも形のないモノを売るだけあって、ちょっと宗教に似ている面がある。このワークショップでも、1日目からいきなり以下のような精神訓話的な話があった。

  • 他人を変えるのではなく自分が変われ
  • 向上する余裕を与えよ
  • 何をすべきかを教えるのをやめよ
  • 見積もりとは予想することではない

 しかし、精神的な訓話やソフトウェア開発者の幸せをいくら強調したとしても、企業がスクラムを採用してくれるとは限らない。そのため、(スクラムの導入が)ビジネスにどの程度の影響力を持つか、という実際的な話も当然語られた。

  • スクラムは、会社や政府機関がソフトウェア採用基準として使用するCMMレベル3に該当する
  • スクラムを使うと生産性が2倍から10倍に上がる。
  • スクラムを使うとROI(Return on Investment:投資効果)が上がる

 この日の講義で筆者らが理解できなかったのが見積もりの話である。スクラムでは、見積もりを、人月ではなく、チーム日で行う。つまり、チーム全体が1日に生産できるソフトウェアの量だ。だが、チームといっても2人のチームから20人のチームまでさまざまなのに、1スプリントでは大体18チーム日を基準に考えろ、という話であった。このことに関して、シュエイバー氏へ質問する機会を逃してしまったのが、心残りであった。

 ほかの講義内容を個条書きにする。

  • 面と向かっての対人コミュニケーションの大切さ
  • 自立的組織
  • ガントチャートは使えない
  • 計画の仕方
  • 製品バックログから、→機能→スプリント・バックログ→仕様への落とし込み
  • ブタとニワトリ(注3)

(注3) ブタとニワトリについては、読者がワークショップを受けるときまでの楽しみとして取っておくために、あえて触れない(筆者)


 ワークショップ初日は、終了予定時刻17時を20分ほど過ぎて終了した。大変内容の濃いものだったことは確かだった。

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

ピックアップコンテンツ

- PR -

注目のテーマ