 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| 会議の目的とむずかしさ | ||||||||||||||||||||
|
前ページでご紹介した会議進行の方法について最初に明確にしておかなければならないことがあります。それは、進め方自体はとても簡単ですが、決定事項を導き出すための議論そのものの難しさには変わりはないということです。これについては、本来会議の手順ではなくて「顧客業務の徹底理解」によって改善が得られると考えており、後述します。 また、この会議進行を実現するには書記が会議をコントロールできなければなりません。そして、参加者全員に議事録の入力過程が見える以上、プロジェクトに対する理解が浅くては書記を行うことができません（入力が遅いのも好ましくありません）。ですから、書記自身、「顧客業務の徹底理解」ができている必要があります。 顧客側と開発側双方のステークホルダーが参加する公式の会議は、プロジェクトによっては唯一のコミュニケーションの場であることも多いでしょう。 そういったことから、開発側としてはその機会を逃さずに開発側の能力や成果を示さなければなりません。それによって、日頃から顧客側が安心できる状況を作ることを配慮しなければなりません。 また、顧客側が不安になる（怒る）可能性を恐れるがために、開発側のマネジャーなどの権力を持つ者が開発側内部に対してパニック状態になってしまうのでは、マネジャーがプロジェクトを破壊していることになります。このことについても配慮しなければなりません。つまり、バランスが大事です。 プロジェクト全体からすればピンポイントといえるような会議の機会に能力や成果を示すことができるようにするには、常にすべてのことが上手く運んでいる必要があります。 |
||||||||||||||||||||
| 上手く運んでいるプロジェクト | ||||||||||||||||||||
|
プロジェクトが上手く運んでいるというのは、「問題点がまったくない」ということとは違い、次のことだと思います。
表2：上手く運んでいるプロジェクト つまり、会議の度に顧客側や承認者などに、プロジェクトに関して指示や承認を得るべきことや要求することなどを明確に伝えることができるということです。会議自体が単なる報告会やマイナス要因の指摘会ではなく、双方にとって有益な「問題解決会」になるように「仕向ける」必要があります。 開発側にとって、顧客側ステークホルダーとの会議の目的は表3の2点です。
表3：顧客側ステークホルダーとの会議の目的 「動いてもらうこと」の1つとして、「会議の中で確実に決定してもらうこと」があげられます。決定してもらうことの中には顧客側の活動事項も含まれます。 これらを実現するために不可欠なのが、繰り返し書いています開発側の「顧客業務の徹底理解」であり、この理解はシステム開発プロジェクトのあらゆる局面で効果を発揮します。本連載で解説している「スペックパターン開発プロセス」では、開発側の「顧客業務の徹底理解」を行う「業務分析」を工程として最も重要視しています。前回お話しした「決定プロセス」の問題も、多くが解決できます。 |
||||||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
