プロセスを正しく理解していますか?
チームを作る - ガイドライン、ルール、ロール
ここまで、進む方向と速度を決め、予定した通りに進んでいることを確認するためのチェックポイントを設定しました。ついに、チームの冒険が始まります。が、その前に、可能であればガイドラインとルールを決めることが役に立ちます。ゴールやマイルストンにたどり着く道筋は様々です。失敗する恐れの大きい危険な道、安全だけど遠回りな道など、様々です。そこで、大まかな道筋としてのガイドラインと大きく道を外れないためのルールを設定します。
図6: ガイドラインとルール(クリックで拡大) |
ガイドラインは推奨を意味します。義務ではありません。チームの行動を制約するものではなく、導くものです。一方、ルールは義務です。チームへの制約となります。ルールはもろ刃の剣であることを認識する必要があります。ルールは行動の幅を狭めチームの持つ創造性を奪う恐れがあります。いまだ発見されていない最短ルートに進むことをルールが阻んでいるかもしれません。
ガイドラインとルールは既に経験がある場合には設定できますが、経験がない場合に設定することは不適切です。効果的ではない道筋を示してしまう危険性が高いためです。実際に試して効果性を確かめたものをガイドラインやルールとして定めます。経験がないプロジェクトを行う場合には、チームを2つに分けることが役に立つかもしれません。チームメンバをロールで分割します。道なき道を行くことを好む冒険好きなメンバが先遣隊のロールを担います(図7)。そして、そこで得た経験に基づきガイドラインやルールを設定します。これはロールの一例に過ぎません。チームには様々なロールが生まれ、個性を活かしながら一丸となってゴールを目指します。ロールはマネージャやリーダが決めるものではありません。チームで行動をしながら、互いの個性を発見し、認め合い、得意なことを活かして助け合うなかでロールは生まれます。
図7: ロール(クリックで拡大) |
チーム作りでよくある誤り
チームを作る時には、ビジョン、ゴール、マイルストン、ガイドライン、ルール、ロールといった要素を駆使します。しかし、実際のチームを見ているといくつかの傾向を見ることができます。
一つはビジョンがないケースです(図8)ビジョンは、夢や志など人を動かす原動力になるものです。人は誰でも意欲を持っています。しかし、その意欲の向ける先が明確でないと鬱々とし、複数の向け先があると混乱してきます。目指すべき方向が定まらないと細かな指示を与えて都度方向を示す必要がでてきます。「私たちは何のためにソフトウエアを開発するのか?」この問いを忘れずにいたいところです。
図8: ビジョンがない(クリックで拡大) |
また、もう一つの傾向としては、人を方向づけるためにビジョンではなくルールを使おうとする傾向が見られます(図9)。ルールによる方向づけはフラストレーションを生みます。窮屈さ、不自由さなどが増し、最終的にはどの方向に意欲を向ければいいのか分からず、無気力状態になります。
図9: ルールで方向づける(クリックで拡大) |
ビジョンは他の要素に比べて実体がつかみづらいものであるため、ビジョンが大事だと理解できたとしても扱いが難しいものです。ビジョンを与えよう、創ろうとすると難しいものになります。しかし、ビジョンは誰しもが心のうちに持っているものです。人を喜ばせたい、よい関係を築きたい、よいものを作りたい。そういった思いこそがビジョンにつながります。それらの価値観をチームメンバ全員で共有することがビジョンを見い出すということです。
プロセスとは何か?
ここまでの話を含めてプロセスとは何かを再定義します。プロセスは「誰が」「いつ」「何をして」「何を作るのか」という過程(仕事の流れ)そのものと言いました。すなわち、「いつ」「何を作るのか」を示すゴールとマイルストン、「誰が」を示すロール、「何をして」を示すガイドライン、これらを補足するためのルール、これら全てをまとめてプロセスと呼びます。チームを作るために、チームで共有する必要のある要素こそがプロセスです。
図10: チームを作るための要素とプロセス(クリックで拡大) |
プロジェクトのプロセス
プロジェクトには個性があります。プロダクトの性質と関わる人々の性格がプロジェクトの個性を決めます。プロジェクトの個性に合わせてプロセスを考えなければ、生産性は高いものとなりません。プロダクトの性質は、そのプロダクトを作ることがプロジェクトの目的であり、変わりません。関わる人々の性格は、人員を選択することである程度までは変えることができますが、理想的な人員を得ることは難しいでしょう。そうなると、最も柔軟に変化させられる部分はプロセスです。
しかし、実際の開発でプロセスはどれほど意識されているでしょうか?プロセスはマネージャやリーダだけが意識するものではなく、チームメンバ全員が意識するものです。なぜなら、プロセスはチームを作るための要素であり、チームで共有されるべきものだからです。プロセスはチームワークを円滑にするためのものであり、チームメンバが頭を寄せ合って考えるものです。
おわりに
今回は、チームを作るための要素について説明しました。チームを作るには、ビジョンが最重要です。ビジョンはチームの目指す方向を統一し、動機づけます。そして、効率的にチームが動けるようにするためにプロセスを考えます。プロセスは、ゴール、マイルストン、ガイドライン、ルール、ロールから構成されます。これら、チームを作るための要素についてチームで考える必要があります。
第2回では、一般的に認知度の高いプロセスを例に取り上げ、プロセスの具体例を見ていくことにします。第3回以降はプロセスのパターンについてみていき、プロセスを自ら考えていくことができるようになることを目指します。
◆◇◆◇ コラム:プロジェクトマニフェストのすすめ ◆◇◆◇
ビジョンは、目指すべき方向を示すものです。航海における北極星のようなものと言えるでしょう。プロジェクトチームにビジョンがないと、チームは目指す方向を見失い、モチベーションが下がる、品質が落ちる、といった様々な問題が起こる可能性があります。
オブジェクト指向開発プロセスの代表格であるRUP(ラショナル統一プロセス)では、Visionというドキュメントが必須成果物の一つに挙げられています。文字通りプロジェクトのビジョンをまとめたもので、日本語では「開発構想書」と呼ばれています。
記述する主な内容は、次の通りです。
- プロジェクトの位置づけ
- 利害関係者の説明
- 開発する製品の概要
- 製品の機能
- 制約(設計上の制約、外部の制約、その他の依存関係など)
- 品質の範囲(性能、信頼性、使いやすさなど)
- システム機能の優先順位
- その他の製品要求(適用する標準、ハードウエア/プラットフォーム要求、環境要求など)
- 文書要件(ユーザーマニュアル、オンラインヘルプ、インストールガイドなど、作成する必要のある文書について)
アジャイルプロジェクトでは、記述するものを次の3つに絞った「プロジェクトマニフェスト」を作成することが多いです。
- ・ビジョン
- プロジェクトが目指すものは何か。それはなぜか。
- ・利害関係者
- プロジェクトは、誰にどのような影響をもたらすか。
- ・目標
- プロジェクトは、いつまでに、何を、どのくらい行うのか。
これらについて、関係者が集まって合意します。プロジェクトの公約になるわけです。これらは1枚の紙に収まるように簡潔に表記し、チームが迷いそうな時には、いつでも原点に立ち返れるよう、見る場所に張り出します。ポイントは、関係者全員で作ること。自分たちで作ったものであれば、従う意欲がわきます。ぜひ、作ってみることをお勧めします。
(株式会社SRA:土屋 正人)
【参考文献】
- トム・デマルコ/ティモシー・リスター『ピープルウェア 第2版』日経BP社(2001)
- 堀公俊『問題解決ファシリテーター』東洋経済新報社(2003)