ObjectSquare [2010 年 3 月号]

[技術講座]


講演「ファシリテートされたワークショップ
:力を合わせてニーズを定義する」の日本語訳

前編

講演者:エレン・ゴッテスディーナー(EBG Consulting)

日本語訳の筆記:藤井 拓(オージス総研)

昨年 ( 2009年 )9 月 18 日に開催された UML モデリング推進協議会 ( UMTP ) 主催の Modeling Forum 2009 で EBG Consulting のエレン・ゴッテスディーナーさんが「ファシリテートされたワークショップ:力を合わせてニーズを定義する」という講演をされました。この講演では、「ファシリテートされたワークショップ」がどのようなものであり、その実施のための 6 つのポイントについてお話をされました。この講演の日本語訳を講演者の許可の下2回に分けてお届けします。なお、今回の日本語訳では講演内容の 8 割程度カバーしていますが、内容を一部を省略したり、再構成しています。それらの点について、ご容赦下さるようにお願いします。




イントロ

この講演では、ファシリテートされたワークショップを使って要求開発を成功させるために役立つ情報を皆さんにお話したいと思います。私は、2冊の本を書いています。1 冊目が「要求開発ワークショップ」[1]であり、この本にはファシリテートされたワークショップの使い方を書きました。2 冊目が昨年日本語訳が刊行された「実践ソフトウェア要求ハンドブック」[2]です。

図 1 講演のアウトライン
図 1 講演のアウトライン

今日は、次に述べる順序でお話をします。まず、ファシリテーションがどのようなものであり、従来の会議とどこが違うかについてお話をします。次に、ファシリテートされたワークショップを行うための土台となる「6つの P 」についてお話をします。これは、異なる種類のファシリテートされたワークショップで繰り返し使える枠組みです。最後にまとめを行い、質疑をお受けしたいと思います。

従来の打ち合わせ

まず、ジョークをお話しましょう。孤独ですか?決断をするのがいやですか? - それなら打ち合わせしましょう!他の人を目にしたり、フローチャートを描いたり、自分が大事だと感じたり、同僚に感心してもらったりできます。すべて会社の時間で行えるのです。打ち合わせは、働くことの現実的なもう1つの選択肢です。

図 2 打ち合わせをしましょう
図 2 打ち合わせをしましょう

まじめに考えてみましょう。毎週どれくらいの時間を打ち合わせに費やしているでしょう。膨大な時間ですよね。米国では、毎週最低 7 から 10 の打ち合わせに参加しているでしょうし、重役ともなれば業務時間の半分は打ち合わせに費やします。調査によれば、多くの場合、打ち合わせ前に準備が求められ、打ち合わせの2時間以上前には議題が通知されます。そして、打ち合わせに 1 から 1.5 時間費やされます。膨大な時間です。調査によれば、打ち合わせで参加者は打ち合わせの目的やゴールすら話をしないのです。とても費用がかさみ、全世界で効率が悪いことを行っているのです。

ファシリテーションとファシリテートされたワークショップ

そこでファシリテーションを活用して、打ち合わせをより豊かなものにしたり、要求について共通の理解を築いたり、開発対象のソフトウェアプロダクトに何を作らねばならないかを明らかにする方法についてお話したいと思います。

図 3 ファシリテーションの定義
図 3 ファシリテーションの定義

ファシリテーションとは何でしょうか。私の好きな定義の 1 つは図 3 に示すものです。従来の打ち合わせという概念には合わないかもしれません。従来の打ち合わせとの違いが分からない人は、従来の打ち合わせでこのようなことが行われていたか考えてみてください。従来の打ち合わせで「自分が打ち合わせに参加しているぞ」という実感を持つことは多いでしょうか。その対極にあるのが「座って受身でただ聞いているだけ」という状態です。打ち合わせの目的やゴールがなんなのかがはっきりと分かっている人は多いでしょうか。従来の打ち合わせと異なり、ファシリテーションでは参加者全員が積極的に参加します。

このファシリテーションをワークショップに応用します。それでは、ワークショップとは何でしょうか。結局のところ、打ち合わせなのですが、従来のものとは異なります。構造が決まった打ち合わせであり、参加者を注意深く選びます。つまり、ステークホルダーです。どんなプロダクトをどのように作らねばならないか、集まって要求を作り、洗練し、最後に何を作るかについて合意を形成します。ワークショップは、プロジェクトにかかわるコミュニティを作るイベントであり、要求の意味についての理解を共有できるようになります。従来の打ち合わせとは大きく違います。このようなワークショップにこれまで参加された方はいらっしゃいますか?これから作るものについて、開発に入るかなり前に明確な考えを持てましたでしょうか?

図 4 ファシリテートされたワークショップ
図 4 ファシリテートされたワークショップ

それでは、ワークショップでは何を作るのでしょうか。まず、複数のモデルを作ります。ユースケースだったり、シナリオだったり、スコープ(開発範囲)を表現するモデルを作ります。ファシリテートされたワークショップを実施することで、時間とエネルギーを大きく節約することができます。

本アプローチを使って、要求を収集したり、意思決定を行った場合のビジネス上の効果についてはいくつかのデータがあります。たとえば、費用対効果が 10:1 というデータです。とても訴求力がありますよね。ファシリテートされたワークショップに費やされたお金の 10 倍の効果を生産性において得ることができます。ユーザの要求がなし崩し的に増えていく、スコープのなし崩し的な拡大(スコープクリーク)は開発コストを大きく上昇させます。これはプロジェクトで最大のリスク要因です。ファシリテートされたワークショップを使うことで、スコープクリープを 80% から 10% の範囲で削減することが可能になります。さらに、要求に関する結論に至るのに要する時間もファシリテートされたワークショップで 60% 削減されます。また、納品されたプロダクトの欠陥も 20% 少なくなります。世の中には、多くの失敗プロジェクトがあり、自分が望んだものが納品されないという不幸なお客様が多数いらっしゃいます。ファシリテートされたワークショップは、万能薬ではありません。しかし、プロジェクトの失敗やキャンセルのリスクを 50% 減らすのにとても有効です。

6 つの P

それでは、このようなワークショップをどのように企画することができるでしょうか。何年間にも渡り、数百ものワークショップを実践する経験を通じて、私は1つのパターンがあることに気づきました。プロジェクトの趣旨やリスクを定義したり、詳細な要求を作成したりする際に、この「 6 つの P 」という枠組みを繰り返し使って効果的なワークショップを開催することができます。

Purpose (目的)

図 5 Purpose (目的)
図 5 Purpose (目的)

1 番目の P は、Purpose (目的)です。ワークショップを開催する目的はなんでしょうか。そんなことは明らかだと思えるかもしれません。それでも注意すべき点がいくつかあります。まず、ワークショップに集まるすべての人の間で、ワークショップの目的がプロジェクトやプログラムの目的と整合していなければなりません。すべての参加者が自分らがなんで集まったのかを理解しなければいけないのです。

あるグループがある目的のために集まったはずなのに、本当の目的は違っていたなんてことも私は経験しました。あるグループは全世界の製造拠点で使うためのソフトウェアパッケージを実装しようとしていました。そのパッケージの拠点への展開については、いくつかの実装戦略がありました。そこでそのグループは最善の戦略を決めるためにファシリテートされたワークショップを開いてほしいと私に依頼したのです。そこで、拠点と戦略について分析を行おうとしました。でも、本当に求められたのはそれらではありませんでした。非常に優秀な人たちで様々な戦略の分析をいっぱい行い、各々の長所と短所を理解していました。私は、このプロジェクトのスポンサー役の役員が他のプロジェクトに移ってしまい、その時点ではスポンサー役の役員がいないことに気づきました。本当に求められていたのは、最終的な判断を下すスポンサー役の役員だったのです。そこですでにある分析をもう一度やり直すのではなく、適切なスポンサーシップをどうしたらよいかという課題に取り組みました。ファシリテーターとして、ある課題の解決策を求めるのを助けることを依頼されても、プロジェクトのコミュニティがまったく異なるものを必要とするという場合もあるのです。

別の例を挙げると、ソフトウェアアプリケーションのユースケースとビジネスルールを開発しようとしていたチームがありました。そのチームのビジネス分析者が、顧客にユースケースを承認してもらうために私にファシリテートされたワークショップの開催を依頼してきたのです。しかし、顧客や対象分野の専門家にインタビューをしたところ、その人たちはユースケースに不満でした。なぜでしょう。IT担当者は、この文書を読んで承認してくださいと言ったのです。でも、顧客はユースケースを開発する過程に関与していなかったのです。そこで、文書を承認するためのワークショップを開催するのではなく、様々なシナリオやカードを使い、紙を壁に貼り付けてユースケースのステップを確認するワークショップを開催したのです。顧客は、自らの要求を定義するためにワークショップに積極的に参加してくれました。これはとても強力です。

ということで、ファシリテートされたワークショップで本当に検討すべきことを明らかにすることは非常に大事です。

Participants (参加者)

2 番目の P は、Participants(参加者)です。誰がファシリテートされたワークショップに参加すべきかということです。ワークショップでは様々な役割が必要になります。まずは、ワークショップのスポンサーです。スポンサーは、予算を提供するとともに、ワークショップの開催に必要なリソースを確保する政治的な力をもっていなければなりません。ファシリテーターと記録係はスポンサーが確保しなければなりませんが、これらの役割については後で説明します。ワークショップの重要性を示すために、スポンサーがワークショップの開始時(キックオフ)に参加したり、終了時に戻ってきて検討結果の説明を受けることがよくあります。

図 6 Participants (参加者)
図 6 Participants (参加者)

スポンサーはとても大事ですが、本当の主役は要求の中身に関わる参加者たち(content participant)です。特定分野の専門家、業務側の人たち、問題領域を理解しなければならない技術側の人たちであり、本当に必要な要求を定義するために必要な人たちです。適切な参加者を集めることは大事です。しかし、ワークショップを大きくしないように、注意したほうがよいでしょう。12 名以上も参加者がいると、ファシリテーターが取り仕切るのは困難になります。そのためには、なるべく問題領域の周辺の複数の部分に通じているような参加者を選んだ方がよいでしょう。

次に、ファシリテーターです。ファシリテーターは、中立的な立場でファシリテーションの過程を導く人です。ファシリテーターは、リーダのようになすべきことを指示する人ではありません。どんな作業をどのような順番で行うというプロセスの設計を行い、要求の様々な表現形式のどれがもっとも適しているかを知り、参加者がゴールを達成することを支援します。ファシリテーターの役割では、中立的であることが非常に大事です。プロセスをうまく進行させることに最大限注力し、要求の中身にはそれほど力を注ぎません。そのため、ファシリテーターの役割を果たそうという場合には、中立的であることに注意に払わねばなりません。要求分析者やビジネス分析者に「私もファシリテートされたワークショップを開催し、要求を責任もって定義できるでしょうか」とよく質問されますが、そのような場合に私は次の 2 つの質問をします。まず、「極めて中立的になれると自分を信じられますか」という質問です。その答えが「はい」の場合、次に「参加者もあなたが極めて中立的だと見るでしょうか?」と質問します。ということで、「中立的になれるか」と問いかけることが大事です。ファシリテーターは、グループでファシリテーションするためのテクニック、作るかもしれないモデル、意見の衝突にどのように対処するかを知らなければなりません。意見の衝突への対処の方法は後でお話をします。

ファシリテーターを支援する役割として、記録係があります。ファシリテーターも記録係もプロセスに関する役割です。記録係は、ノート PC を持ち込んで議論の内容を記録し、壁に貼っている紙に描かれているモデルの写真を取り、グループの記憶を保存します。というのは、われわれはいろんなことを忘れるからです。ワークショップで検討されたことを、後で参照すると役立ちます。記録係を設定させずに、壁に貼り付けた紙をはがして、後でモデルを PC に打ち込んだり、写真にとって記録するということもあります。でも記録係がいたほうが、ワークショップのプロセスは加速するでしょう。

さらに、オブザーバーが参加することもあります。ワークショップにオブザーバーとして参加する人がなぜ必要なのでしょうか。それは 2 つの理由があります。第 1 の理由は、要求の中身を学ぶためです。要求やドメインを理解するということです。たとえば、業務に新たに携わった人、プロジェクトに新たに加わったテスター、アーキテクト、開発者がワークショップに参加して、アーキテクチャや設計を考案したり、エンドユーザとなるビジネス側の人のために役立つ豊かな情報を得ることができます。ということで、オブザーバーとして参加することで要求の中身を学ぶことができます。また、ワークショップのプロセスを学ぶためにオブザーバーとして参加するということもあります。他のファシリテーターがセッションをファシリテートするのを見ることで、自分でも使ってみようというような様々なテクニックを学んだり、うまくいかないだろうことも学べます。ということで、オブザーバーとして参加することで多くのことを学ぶことができます。私は、他のファシリテーターのセッションにオブザーバーとして参加するのが好きです。ファシリテーター毎にスタイルやテクニックが異なるので、他のファシリテーターのセッションに参加することで、それらのスタイルやテクニックを学ぶことができます。

オブザーバーには、自分たちがオブザーバーであり、参加者ではないということを認識してもらう必要があります。オブザーバーは、ワークショップのやり取りを聞き、学ぶ役割です。

また、サポート役を設定するのも有効です。特定分野の専門家や業務知識を持っている人で、ワークショップにずっと参加せず、電話で手短に質問をしたりする相手です。アメリカのインディアナで開催された、あるワークショップに様々な地域の人たちが参加したことがありました。アジア、イギリス、イタリアから60名の人が集まり、クロスファンクショナルなチームを作りました。その際に、要求に関する質問が持ち上がりました。このような場合、情報をたくさん持っている人に、ワークショップを開催する前に電話で質問し、すぐに回答をもらうことになるかもしれないということを伝えておくことが大事です。この時もそのような状況がありました。質問をインデックスカードに書き込み、壁にパーキングロットと書いた模造紙に貼り付けました。後で検討する課題を貼り付けておくための場所です。昼食の際に、イギリスから参加者が電話をかけて、パーキングロットに貼り付けた質問に対する回答を得て、要求に関する質問の結論を得ることができました。ということで、サポート役が必要かどうか考えてみることが大事です。

私は、要求の中身に関わる参加者の中から計画立案チームと呼ばれる人たちを選びます。この人たちは、ファシリテーターである私の相談相手です。人数として最低 2 人は必要ですが、なるべく 3 人以上にならない方がよいでしょう。この人たちは、ワークショップの計画と設計を手伝ってくれます。ワークショップを目的を設定し、議題案をレビューします。既存の要求ドキュメントに関する情報や、ワークショップをどのように進めたらよいかという情報を得ることができます。ワークショップで必要なものの準備を計画します。このような計画立案チームでは、ビジネス側と技術側とのバランスをとる必要があります。特定分野の専門家、プロダクトオーナー、顧客のようなビジネス側の人と、要求技術者やビジネス分析者のような技術者の両者が参加した方がよいでしょう。ビジネス側の人と技術側の人の両方が参加することで、この 2 つの観点を取り入れることができます。ファシリテーターの役割は、グループにとって中立的に仕えることです。そのために、両方の観点を取り入れて、バランスをとることが大事です。


前編の終わりに

後編では、「 6 つの P 」の残りの 4 つの P と、まとめ、質疑をお届けする予定です。

今回紹介した講演(英語)は、2010年3月31日までModeling Forum 2009のオンデマンドウェブセミナーのサイトでストリーミング配信されています。ゴッテスディーナーさんの肉声をお聞きになりたい方はぜひお試しください。


参考文献



© 2010 OGIS-RI Co., Ltd.
Index Next
Index Next