プロジェクトを始める前にチームの協力体制を築くことは、効率的、効果的であるために最も重要なことです。プロジェクトがスポンサーにとってなぜ重要か、企業全体の動きにどのように合わせるか、そして、何が最も重要なアイテムであり、プロジェクトのスポンサーはどのようなトレードオフを受け入れるかについて、チームメンバが共通の認識を持っていなければ、プロジェクトは脱線してしまうか、スポンサーの期待に応えられなくなります。同様に、チームに協力できないプロジェクトスポンサーは、チームの能力やプロジェクトの納品に関する品質やタイムラインに対して、非現実的な期待を持つ傾向があります。あなたは、大きくなったチームにおいてどのように協力体制を作り上げられるでしょうか?
一般的に、チームメンバ１人１人は、毎日の仕事の中でそれほどプロジェクトスポンサーとやり取りをする訳ではありません。チーム全体で強い忠誠心を持ちながら意思の疎通を図ることは、たくさんのEメールやドキュメント、会議電話よりも、チームで協力体制を保つためにずっと効果的です。通常、地理的な理由やステークホルダの都合、スケジュールなどにより、毎日チーム全体で、強い忠誠心を持ちながら意思の疎通を図ることはできません。しかし、チームメンバ全員が、一日、一緒に集まることはできます。
Pivotalの、具体的に言えば、Cloud Foundryチームにおいて、私たちがチームの協力体制を作り上げるための使った効果的なアプローチは、インセプション(始まり : Inception) と呼ばれる1日ミーティングです。このアプローチの「なぜ」、「何」、「どのように」に対する答えについて学び、このアプローチから利益を得たCloud Foundryプロジェクトとチームから、いくつか具体的な例を見てみましょう。
インセプションとは何か?
インセプションとは、一般的に、新しいプロジェクトを始めるチームの準備をするために、営業日をほとんど丸1日使って実施するミーティングのことです。インセプションは、数か月続いている既存のプロジェクトの体制を立て直すために使われることもあります。理想は、インセプションミーティングの後、優先順位付けされた、具体的で実行可能なストーリーに開発チームが取りかかれることです。時には、プロジェクトのステークホルダとゴールが明確に決まっていないため、チームが取りかかる前に、詳細を決めて共有できるゴールに合意するのに、さらに作業が必要なこともあります。インセプションを実施すれば、そのことを健全に早い段階で発見できます。チームがプロジェクトを始める前に、問題を明らかにして調整することは、後で捨ててしまうことになる作業を何週間もやった後で知るよりも、ずっとよいでしょう。
インセプションは他のプロセスや方法論に関係するか?
エクストリームプログラミングには計画ゲームと呼ばれるコンセプトがあります。インセプションの様々な要素は、このアプローチから影響を受けています。しかし、計画ゲームで使われる計画はゆるく決められていて、1日ずつではなくプロジェクトを通して使われますが、Pivotalでは、通常は、プロジェクトを始める時に効果的なミーティングのための正式なアジェンダを使います。
「インセプション」という言葉から、ラショナル統一プロセス(RUP)の方向づけフェーズを連想する人もいることでしょう。言葉や目的は、インセプションミーティングとRUPの方向づけフェーズは似ていますが、インセプションミーティングは、1日で同じような目的を達成するもっとライトウェイトなアプローチです。
なぜこのような1日がかりのミーティングを実施するのか?
主な目的は、チームの協力体制を確立し、プロジェクトをうまく始めることです。Graham Siener氏によると、協力体制を作るミーティングは、チームが何を作り、どこから始めるかを知ることに注目するようにします。私の経験から、このミーティングによってチームは協力体制を作り、プロジェクトをうまく始められるようになります。そして、素早く価値を提供し、間違ったことに取り組むムダをなくします。
インセプションに誰が参加すべきか?
インセプションの参加者には、作業をするチーム、スポンサーとなるステークホルダや指名された人たちが含まれるべきです。一般的に、ビジネス、製品、開発、そして、おそらく運用/サポートのような他のチームも含まれます。また、このチーム作業の製作責任者や消費者といった上流から下流のチームの代表者も含まれるでしょう。実際には、人数が10人以上になると、ミーティングの効果が減り始めます。多くのグループが参加し、20人いたとして全員が効果的に貢献することは難しいからです。招待する人のリストが長くなってきたら、チームの中でもっとも関わりの薄い人はミーティングで他の参加者に自分の見解を述べてもらうようにするよう、インセプションのファシリテータかプロジェクトのスポンサーが頼むかもしれません。大人数のインセプションが避けられない場合もありますが、そのトレードオフとして出席者たちがそれほど積極的に参加せず、あまり協力体制を作れないことが挙げられます。
プロジェクトのスポンサーやステークホルダは、ミーティングに参加するか、自分たちの見解を示す権限を与えた人を送るべきです。スポンサーがたった1回の重要なミーティングに参加する時間が持てないけれども、プロジェクトの決定に対して、大きな影響を与えたり、コントロールしたりしたいこともあります。そのような状況において、チームは今だけでなく将来も必要なサポートを受けたり、注目を集めたりすることはあまり期待できません。
ミーティングを公平にリードできる経験のあるグループファシリテータを参加させることは重要です。この儀式の有能な支配者であるその人の能力は、非常に重要なのです。ファシリテータは、アジェンダを効率よく進め、チームが効果的にコミュニケーションしていることを確認し、時間を取って深追いするべきところを見つけ、だらだらと続いている会話を止めて、後で小さなグループで話し合えるようにする責任があります。
インセプションミーティングはいつすべきか?
理想を言えば、新しいプロジェクトが始まる直前、または、既存の長期プロジェクトの作業の新しい主な流れが始まる直前に、インセプションを実施します。チームに沢山の人が参加したり、いなくなったりする場合、または、方向性に大きな変更がある場合、もう一度インセプションを実施すれば、チームの協力体制作りに役立ちます。
インセプションはどのように実施すべきか?
ファシリテータは、出席者たちが完全にミーティングに注目するようにしましょう。ノートパソコンを開いていたり、休憩時間以外は携帯電話を使ったりすることは許されません。「あなたがここにいるのだから、すべての時間、あなたはここにいるべきです」というルールを決めれば、インセプションの効果を大幅に向上させられます。
インセプションは、理想を言えば、ホワイトボードと大きな紙のある大会議室で実施します。いろんな色のマーカーとインデックスカード、テープ、投票で使える小分けのお菓子や飴玉を準備するとよいでしょう。休憩時間は、1時間毎に5-10分程とりましょう。
直接会うか、それともリモートで参加するか
リモートで参加する場合に対して、直接参加する場合の利益は誇張ではありません。リモートで参加する場合、気が散りがちで、コミュニケーションへの忠誠心が低下します。私は、以前、数名のリモート参加者がいるインセプションが実施されるのを見てきましたが、自分がリモートでインセプションに参加した時、私の発言は少なくなりました。そのため、チームは私が直接参加したときよりもずっと少ない発言しか私から得られませんでした。時には、リモートの参加者は現実世界の制約のために避けられません。そのような状況では、高品質マイクや独立型ビデオカメラのような、リモート参加のために最高のテクノロジを使いましょう。低品質のビルトインラップトップマイクとカメラを使えば、参加者はメールをチェックしたり、ウェブサイトを見たりし始めるでしょう。
典型的なインセプションのアジェンダ
導入 - 導入は短く済ませましょう。その日はチームとして一緒に過ごし、1日中お互いを知る機会があります。ファシリテータが参加者たちについて、どのような人か、なぜここにいるのかといった、2、3の重要な情報を与えると役に立ちます。
ビジョンとゴール - プロジェクトのスポンサーとプロダクトオーナーは、プロジェクトに関する簡潔な長期的ビジョンを与え、これから2、3カ月間ですぐに到達すべきゴールを示すべきです。グループからの質問や議論のための時間を作ります。
ゴールではないこと - ゴールが重要であるのと同様に、直近のゴールではないことを明確に述べるのは重要です。多くの場合、ゴールではないことをはっきりと述べることは、現在の仕事の流れを制限し、最終的にはほしいけれども、今作る必要がないことを除外することによって、チームがより早く価値を提供できるようになる方法です。ゴールではないことについてグループディスカッションの時間を作るようにしましょう。
リスク - その部屋にいるみんなで、インデックスカードを使って、プロジェクトの主なリスクを明らかにしましょう。1人1人が好きなだけカードを使って、インデックスカード1枚に1つリスクを書き出していきます。ファシリテータは、インデックスカードを関係するリスクにまとめて分類し、カードを読み上げて、そのカードを書いた人に自分の書きだしたリスクに関する簡単な定義を説明する機会を与えます。これは、各リスクに対するグループディスカッションではなく、リスクがどのようなものかをただ理解するだけのものです。それから、ファシリテータは、投票用の飴玉や棒を使って、プロジェクトのゴールを達成する時にチームが遭遇するもっとも高いリスクのカテゴリに3票投票するように、みんなに指示を与えます。3票は1つのカテゴリに投票してもよいですし、3つまで別々のカテゴリに分けて投票してもかまいません。投票の後、もっとも投票数の多かったリスクを最初に議論しましょう。そして、ホワイトボードか写真で、分類されたリスクのランキングを記録します。チームは、その日の終わりにリスクを投票するエクササイズをもう一度やり、何か変更がないか確認します。大抵いつも変更があります。
役割 / ペルソナ -プロジェクトで必要な役割やペルソナを明らかにするために、 ファシリテータはグループエクササイズを実施します。単にプロダクトオーナーが権威を持つ人を宣言するのと、グループ全体でブレインストーミングのエクササイズをするのとでは、役割やペルソナが異なることがこのアプローチでは明らかになります。このエクササイズの主な目的は、チームのみんなでユーザがだれかを理解することです。
アクティビティ / ワークフロー - ファシリテータは、プロジェクトの直近のゴールに入るユーザの役割やペルソナのアクティビティやワークフローを明らかにするようにグループで取り組みます。ファシリテータは、グループの力にぴったりのアプローチを選ばなければなりません。それは、プロダクトオーナーに主なアクティビティを明らかにするように頼んで、グループでディスカッションするような簡単なものかもしれませんし、ゲームのようにもっと何か創造的なことかもしれません。何かを達成するためのシステムのユーザインタフェースがどのようなものであるかというこれらのハイレベルな説明は、プロジェクト全体の基礎を形作り、通常は後でストーリーに分けられます。ハイレベルなワークフローの例は、「ボビーという生徒が1冊の本を探して、店のカタログを検索し、ショッピングカートにアイテムを追加し、購入を完了する」というものです。
ストーリー - もし時間があるならば、アクティビティとワークフローをより小さく、具体的で実行可能なストーリーにしましょう。言葉遣いをそれほど正確にしようと心配しなくてもかまいません。プロダクトオーナーが後で言葉遣いを見直し、詳細を書きます。インセプション中にこのアクティビティをする時間がない場合もあり、よりハイレベルなアクティビティやワークフローは、見積もりや優先順位付けで使える粒度にします。これは問題ありません。インセプションの後、できるだけ早くストーリーが作成されるように、開発チームと取り組むのは、プロダクトオーナーの仕事ですから。
見積もり - もっとも重要なストーリーに関しては、その部屋にいる開発者に素早く大体の見積もりしてもらいましょう。ストーリーレベルで見積もった場合、開発中にチームで使うポイント制と大きさを使うようにします。大きなアクティビティやワークフローでは、開発者の1週間単位でよりおおざっぱな見積もりを使うようにしましょう。Martin Fowler氏の見積もりじゃんけんの技術は、素早くおおざっぱな見積もりをするのにとても効果的です。 見積もりをする数多くのアイテムがある場合、私の同僚のEvan Willey氏はTシャツサイズによる見積もり(Affinity Estimating)を推奨します。ここで重要な結果は、クライアントのスポンサーとプロダクトオーナーが、実装に関して責任のあるチームから直接見積もりを受けとることです。
優先順位付け - プロダクトオーナーがストーリーに優先順位を付けて、グループでディスカッションして検証しましょう。プロダクトオーナーは、ビジネスの価値に基づいて、優先順位が正しいことをチームに納得させなければなりません。これらの機能は、プロジェクトのこのフェーズで「必ずなければならない」ものか、それとも、ただ「あったらよい」ものなのでしょうか? ポイントに基づく見積もりが、チームサイズに基づいたプロジェクトの1週間単位で見積もれるものかどうか見てください。私が参加したほとんどどのインセプションでも、見積もりと優先順位によって、チームが数か月で納品するために、範囲を区切らなければならないことを示します。プロジェクトのスポンサーとプロダクトオーナーとトレードオフについて議論するには、今が一番よい時です。最初のプロジェクト納品に対して説明責任のあるチームから、ほぼ正確な見積もりを聞けるのですから。
リスク - 先ほどのリスクエクササイズを繰り返し、リスクが変わったかどうか確認します。
次のステップ - これから2、3日、また2、3週間で実行することについてグループディスカッションをします。これは、チームが開発とチェックインに向けて使われるプロセスについて、最終的に調整し、みんなに知らせるために使われるかもしれません。通常、ファシリテータとプロダクトオーナーは、ホワイトボードの写真を撮り、エクササイズで使ったインデックスカードを集め、アクションアイテムをはっきりさせて、誰がインセプションの内容をまとめてメールするかを決めます。時には、チームが白い大きな紙やインデックスカード、ホワイトボードの写真等、インセプションで作ったものを仕事場に貼り出しているのを見かけます。時間が経つに連れて、これらは古くなり、価値が減っていきます。
ふりかえり - インセプションミーティングについて話し合うために、アジャイルふりかえりを使いましょう。何がうまくいったか、みんながどんなことに疑問を持ち、混乱したか、また、何がうまくいかなかったか、今度インセプションをする時のアイデアはあるか。
楽しみ - 今の段階で、ほとんど1日部屋にいるので、みんなぐったりしているはずです。1日の終わりに向い、どこかで参加したい人だけ集まって、会社の外で楽しむのがチームにはよいでしょう。多くの場合、インセプションミーティングに参加できなかった人たちは、その結果を知りたがり、チームと交流したいと思っています。そのため、参加できなかった人を誘ってもよいでしょう。参加したい人だけにするのは、リラックスする時間が必要な人たちにとって大切なことです。
続けて協力体制を作る
インセプションは、ある時点で協力体制を作るのには優れていますが、協力体制を維持するために、フィードバックを繰り返し実施できるような別のタイプのミーティングが使われるべきです。効果的なフィードバックループの例として、毎日のスタンドアップミーティング、毎週実施するイテレーション計画ミーティング、プロジェクトスポンサーによる毎週のチェック、毎週、または、隔週のチームによるふりかえり、プロジェクト機能の継続的納品があります。数か月後か、重要なマイルストーン毎に、別のインセプションを実施することを推奨します。協力体制のあるチームは、効果的なチームです。
Cloud Foundryのインセプション
私は、PivotalのCloud Foundryで、2年以上働いてきました。そして、私たちの働き方が、高い生産性を誇り、うまく機能しているおもしろいチームであると、私は信じています。Cloud Foundryのサブプロジェクトはどれも、Loggregatorのように私たちのもっとも革新的な機能のいくつかが含まれるインセプションから始まっています。 Loggregatorは、直ちにすべてのアプリケーションから集められて流れるログをユーザに提供し、リモートのシステムログのエンドポイントへ流し込みます。とりわけチームからほぼ正確な見積もりを得られるインセプションミーティングによって、私たちは、開発範囲に関してログを流すことにとどめ、ログの永続性や検索は拡張しないようにしました。Cloud Foundryのコマンドラインインターフェースをgolangで書き直すことは、インセプションから得られた別のプロジェクトでした。インセプションの間、CLIのRubyバージョンから、ユーザエクスペリエンスを大きく離れることをチームとして合意しました。そのため、書き直しの範囲を減らし、ずっとよいユーザエクスペリエンスが得られました。
今までの私のソフトウェア開発の経験のほとんどが、事前設計やドキュメント、大きく分けられたチーム、また、1年以上の長期プロジェクトである、もっと伝統的なウォーターフォールプロセスを使っていました。私は、二度とそのような働き方に戻りたくありません。Pivotalで私たちが使うアプローチは、エクストリームプログラミングとアジャイルの原則のコンセプトに基づいています。これは、Pivotal Labsが実用的な現実世界のプロジェクトや継続的改善を使って設立されてから、25年以上磨き上げられてきました。このプロセスにより、外部のスポンサーやステークホルダと同様に中心的チームにおいて、確実に協力体制を作り、理解を共有します。次にあなたが新しいプロジェクトや新しいことを提唱する時は、インセプションやインセプションに似ているものを試してください。
1 このアプローチに関してより総合的な議論をするには、私の同僚であるAndrew Clay Shafer氏が、Diana Larsen氏とAinsley Nies氏による「発進: アジャイルチームとプロジェクトを作る」(Liftoff: Launching Agile Teams & Projects)を推奨しています
著者について
James Bayer氏は Pivotalのプロダクトマネジメント部門のシニアディレクタであり、Cloud Foundryオープンソースプロジェクトのプロダクトマネジメントチームのリーダーです。Cloud Foundryの前は、Oracle のWebLogic Serverプロダクトマネジメントチームのメンバとして、Java EE技術に広範囲に渡り取り組んできました。また、VMware、BEA Systems、Cordys、IBMでエンタープライズミドルウェアのポジションについていました。James氏は、ネブラスカ大学で数学とコンピュータサイエンスの学位を取得しています。