ObjectSquare [2011 年 7 月号]

[レポート]


Scrum Gathering Seattle 2011 参加報告

前編

オージス総研 技術部アジャイル開発センター 藤井 拓

今年 5 月 16 日から 18 日までの 3 日間に渡り、米国ワシントン州シアトルで Scrum Gathering Seattle というアジャイル開発手法スクラムの実践者の集いが開催されました。本記事では、Scrum Gathering Seattle の初日のプログラムで面白かったことと、筆者が参加した 2 つのセッションの内容を紹介します。




Scrum Gatheringとは

シアトルの風景
シアトルの風景

Scrum Gathering は、アジャイル開発手法スクラムのコミュニティである Scrum Alliance が主催するスクラムの実践者の集いです。 Scrum Gathering は、北米を中心に全世界のあちこちで年に数回開催されています。それらの Scrum Gathering には、Scrum Alliance が直接主催するものとローカルコミュニティ主催のものがあるようです。今回開催された Scrum Gathering Seattle は Scrum Alliance 主催で参加者は 200 名程度でした。6 月には、上海のローカルコミュニティ主催の Scrum Gathering Shanghai が開催されたようです。

筆者は、アジャイル開発手法の中で現在最も普及しているといわれるスクラムが実際にどの程度根付いており、どんな人たちが実践しているかという点に興味を持って Scrum Gathering に参加しました。また、日本でいまアジャイル開発が普及する上での障害となっている契約や既存の手法からの移行についても何らかの情報を得たいという狙いもありました。

基調講演の講演者が…

初日は主催者のあいさつからスタートし、基調講演のはずだった。でも、主催者から「基調講演の講演者がこちらに到着していません」とのアナウンス…。どうなることかと思ったが、主催者は1人のファシリテータにバトンタッチし、臨時のセッションを開始。

ファシリテータはまず「海外からこのイベントに参加している人は起立してください」と参加している地域や参加回数別に参加者の起立を求めた。海外からの参加者は私を含めて 10 人強ぐらいでそれほど多くはなかったが、意外に東海岸からの参加者が多く、またScrum Gatheringに複数回参加している人が多いことも分かった。

ファシリテータが「せっかくだから参加者の皆さんがこのイベントを通じて解決したい課題をリストアップし、同じテーブルの人とお互いの課題を説明しあってください」と述べると、しばしの沈黙の後、いきなり見知らぬ者同士が名刺交換をしながらお互いの課題を話し合い。私のテーブルは、アジャイル開発のコンサルタントと社内コーチと、スクラムで開発行っている部署の管理職などがおり、お互いの課題を紹介しあった。「日本では契約などが障害となり、アジャイル開発がそれほど普及していない」と私が話をすると、他のメンバーは不思議そうな顔をした。

主催者が諸連絡を行っているところ
主催者が諸連絡を行っているところ

次に、ファシリテータが「会場の他の人に自分の課題を述べたい人は手を上げてください」と述べると、あちこちで手が挙がった。ファシリテータに指名された人が立ち上がって「私は QA 部門の人間ですが、アジャイル開発においてテストをどのように行うべきか学ぶために参加しました」などと自分の課題を説明すると、ファシリテータは「この課題に対する解決策を持っている人は立ち上がってください」と述べ、解決策を持っている人が立ち上がると「いま立っている人はお互いに顔を覚え、話し合う機会を設けて、この 3 日間で問題を解決しましょう」と進行をしていった。

この臨機応変なイベントの進行は、まさにスクラムの精神を表しているようで非常に興味深かったが、それだけではなかった!後で振り返ると、なんとこのセッションが強力なアイスブレークのような役割を果たしたのである。このセッションで他の参加者に知り合いができるとともに、他のどの参加者とも気軽に話し合える場の雰囲気が一気にできたのである。そこまで計算したのだろうか?

The Business Case for Agile: What Every Executive Needs to Know

講演者:John Rudd ( SolutionIQ )

経営者にアジャイル開発のメリットを説明するために「 Real Options 」という概念が有効であることを説明した。通常、ソフトウェアを開発する際には様々な仮定をしてソフトウェアに必要な機能を決めていく。この様々な仮定を各々オプションと呼ぶ。例えば、「こういう業務フロー(新しいサービス)により売り上げや顧客満足度が上がる」とか、「ソフトウェアにこのような新機能があった方がよいだろう」などが仮定になる。

ウォーターフォール開発の場合は、開発に先だって要求を確定しなければならないのでこのような仮定を複数置いて開発を進めることになる。それらの仮定が正しいかどうかはソフトウェアの開発が完了し、新しい業務(サービス)やシステムが稼働して初めて明らかになる。仮定が間違っていれば、その仮定に依存する他のもののも含めてビジネス上の期待は達成できないことになる。これは、大きな賭け金を積んで1発勝負をするようなものである。

それに対して、アジャイル開発では1つ1つの仮定あるいは少数の仮定が正しいかどうかを段階的に確かめ、仮定が正しくなければ軌道修正を行って開発を進めることができる。このように開発を進めると、ウォーターフォール開発のように目論見を外して役に立たないシステムや機能を作ってしまうということが防ぐことができる。

企業は複数のビジネスやそれを支援するシステムの開発を並行して進めており、それは企業の競争力を高めるためのポートフォリオを構成している。そのようなポートフォリオを構成するビジネスやそれを支援するシステムの開発においてアジャイル開発を適用することで、開発途上のビジネスやシステムの有効性を確かめることができ、最も有望なものへと投資を絞り込むことができる。つまり、複数のビジネスやそれを支援するシステムの中で最も有望なものを見つけることで、投資効果を高めることができるのである。

さらに、スクラムではソフトウェアの機能をビジネス上の優先度の順に開発する。このように開発することで、開発終盤には優先度の低い機能が残る。開発終盤に、これらの優先度が低い機能を本当に実装すべきかという点を再考することで必要のない機能を開発することを避けることができる。

講演会場の間の通路
講演会場の間の通路

Leading a Self-Organization Team

講演者:Mike Cohn ( Mountain Goat Software )

開発メンバー各々の自律性を尊重する、自己組織化されたチームにおいて、開発がうまく進まなかったり、継続的な改善が行われない場合にそれをどのようにリードするかという方法に関する講演。本講演の講演資料は、Mike Cohn 氏の会社である Mountain Goat Software の Web サイトよりダウンロード可能である。

自己組織化されていない従来のチームであればプロジェクト管理者が開発メンバーに直接的に指示を出すことで解決を図るだろうが、自己組織化されたチームではそのような解決は望ましくない。そのために、微妙なコントロールが必要になるのだ。

微妙なコントロールを行う方法としては、本講演では以下の 3 種類のものが紹介された。

Containers, Differences, Exchanges

Containers, Differences, Exchanges ( 略して "CDE" ) とは、微妙なコントロールを行うための 3 つの方法を意味する。

「入れ物」とは、自己組織が起きる集団の境界を意味する。つまり、会社、プロジェクト、役割、期待などである。「入れ物を変える」とは以下のようなことである。

「違い」とは、自己組織化されたチームのメンバー間の以下のような違いである。

自己組織化されたチームが真価を発揮するためには、チーム内の意見の違いを恐れず、安易に大勢に流されてしまわないようにするということである。そのためには、以下のようなことを行う必要がある。

また、異なる視点(意見)を持つメンバーを加えるという解決策もある。

「やり取り」とは、自己組織化したチームのメンバー間での相互作用やリソースのやり取りを意味する。やり取りされるリソースとしては、情報、お金、エネルギーなどがある。「やり取りを変える」ための方法としては、以下のようなものがある。

「やり取りを変える」具体例としては、異なるチームの開発者が集まり、お互いのテスティングに関する工夫を共有するような場 ( Community Of Practices ) を設けるというものが挙げられる。

講演では、これら CDE の演習問題が出題され、参加者がその解答を考えた。

チームの進化に影響を与える

次に、リーダーとして自己組織化したチームをどのように進化させるかということを説明した。自己組織化したチームは一時に生まれるものではなく、チームを取り巻く環境にチームが対応する過程で自然と現れてくる。そのため、チームを取り巻く環境をうまく作ることでチームが自己組織化するようにリードすることができるのである。

講演で、チームの進化に影響を与える方法として挙げられたものは以下のとおりである。

  1. パフォーマンスを定める
  2. 意味をきちんと伝える
  3. 代わりの淘汰システムを発展させる
  4. 勢いづける
  5. 複雑さを減らしたり、吸収したりする
  6. 真空状態を作る

1 は、進化の淘汰の中で生き残るものはこういう特性を備えるはずだというメッセージをリーダーが発信して進化を促すということである。例えば、「短期的に開発を成功させるだけではなく、将来のビジネスにつながるような新たな技術にも取り組むものだけが生き残れるのだ」というメッセージを発信するのである。

2 は、企業の原則、価値、姿勢の意味を具体的に示して進化を促すということである。そのために、企業の価値等を具体的に示すようなエピソード(伝説)などを繰り返し述べることで、価値等の意味を具体的に示すのである。

3 は、振り返り、20% ルール、処遇などにより人工的な淘汰システムを発展させて進化を促すということである。ビジネスにとって市場こそが淘汰が起こり、進化を促す場であるが、市場で結果が出るのには時間がかかる。そのために、振り返り等により淘汰する(進化を促す)場を人工的に作るべしということである。

4 は、大きな目標を掲げてチームのメンバーが奮起するようなメッセージを発信し、進化を促すということである。講演では、ビル・ゲイツが全社員に向けて発信したインターネットへの取り組みを行う決意を記したメッセージが例として示された。

5 は、定型化などにより作業の複雑度さを低減したり、組織間の垣根を下げて必要な情報をもらえるようにして進化を促すということである。

6 は、リーダー自身が直面している答えが無い課題をチームメンバーにも一緒に考えてもらうことで進化を促すということである。リーダーが、眠れないぐらいに孤独に悩んでいる自分の課題をメンバーに率直に話をし、議論してみるということである。

状況に応じたアジャイルリーダーシップ

リードする対象のチームの状態を以下の 2 つの観点で捉える。

そうすると、チームのアジャイル開発への準備段階(readiness)は表1に示す4段階に分類できる。

表1 アジャイル開発への4つの準備段階
実践できるか気持ち準備段階
できない後ろ向きR1
できない前向きR2
できる後ろ向きR3
できる前向きR4

チームがこれら4つの段階のどこに位置するかで、表2に示すようにリードの形態を変えた方がよい。

表2 準備段階とリードの形態
準備段階適したリードの形態リードの形態の説明
R1説明型のリード日々の作業をガイドする形で小さな成功を1つずつ積み重ね、基本的なスキルを育てる
R2売り込み型のリードR1よりもチーム自身で判断する度合いを増やすとともに、コード品質を高めることをよしとする
R3参加型のリードチームが短期的な(細かい)ことに囚われがちなので、長期(大局)的な視点でリードする
R4委譲型のリード判断は全面的にチームに委ね、開発のスループットを上げることに注力する

前編の終わりに

後編では、スクラムでのアーキテクチャ設計の進め方、Steve McConnell氏の基調講演の、Open Space Technology を紹介するとともに、Scrum Gathering Seattle で出会った人たちから得た情報を紹介する予定です。(あくまで予定なので、内容が変わる可能性もありますが、…)



© 2011 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP