 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| ギャップを埋める「リアリティ」の原則 | ||||||||||||
|
2人の会話にあったように、ユーザ企業と開発ベンダーの間にはどうしても対立の構図ができてしまう。ここで重要なのは両方の言い分はどちらも正しいということだ。では、どうすればよいのか。
表1：ユーザ企業と開発ベンダーの対立 なぜ対立が起きるのかというと、プロジェクトに対する両社の立場や前提の違いからくる「現状認識のずれ」があるからだ。このずれは、議論の対象であるプロジェクトが目にみえないものであるから発生しているのだ。 みえていないものについて、違う立場から自分のいいたいことと相手の気にしているところが異なるまま議論しても、意見が合わないのは当然である。議論の対象であるプロジェクトを同時にみることができれば、認識のずれは埋まり、双方が自分の気にしているところを理解できる。 例えば、画面仕様策定の際に「画面プロトタイプ」を作成すれば、意識違いを非常に効率よく回避できるといった経験を持っている人は多いだろう。言葉で画面仕様を意識あわせする困難を想像してほしい。だが、プロジェクトについての議論は、まさにそのようなことをしているのだ。 つまり、プロジェクトに発生するギャップを埋めるためには「プロジェクトのプロトタイプ」を作成し、意識の違うところをすりあわせていくという手法がとれる。そうすれば、同じ立場からプロジェクトを眺め、対立することなくプロジェクトを進行させていくことができるようになる。  図2：「ユーザ企業vs開発ベンダーの構図」から「プロジェクトvsチームの構図」へ （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
| 問題vs私たちの構図 | ||||||||||||
|
オブジェクト倶楽部で議論されている「プロジェクトファシリテーション」では、その行動原則の1つとして「問題vs私たちの構図」がうたわれており会議では向かい合って座るのではなく、プロジェクタで映した課題を並んで眺めるようにしようと提言している。実際に会議の場で並んで座る必要こそないのだが、今回の話はそれをより大きな観点から適用したと考えてもよいものだ。 |
||||||||||||
|
では、なぜこれまでのやり方の中で、提案書やプロジェクト計画書、WBSなどできちんと説明しているにもかかわらず、後に認識のずれや対立に繋がってしまうのだろうか。筆者はその原因としてリアリティの不足の存在が大きい考えている。特に、プロジェクトの初期段階で「今そこまで詳細を詰めなくても」という一見オトナの態度が、双方のギャップを埋めないまま放置してしまい、後になって大きな対立を生んでしまうのだ。 このような「リアリティのあるプロジェクト像」を描くための具体的な方法はどんなものになるのだろう。 結論からいうと、プロジェクトの工程や会議の種類ごとに異なるものになる。この連載では、その中でも特に重要な「プロジェクト立ち上げ」と、その後ずっと継続する「進捗定例」の2つについて説明していく。 今回は、そのような実際のシーンでの手法説明に入る前の予備知識として、プロジェクト像にリアリティを持たせるための基本的な5つの「コツ」を説明しておこう。 |
||||||||||||
|
|
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
