 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| 議題について議論を重ねる | ||||||||||||||||||||
|
システム開発では議論を重ねるにあたり、様々な準備が必要です。顧客側のオフィスで会議を行う場合、顧客側にプロジェクタなどについての準備をお願いしておかなければなりません。 2セット目のノートPCとプロジェクタの用途も議論を進めるにあたって重要ですので、可能な限り用意してください。1セット目は議事録を常に表示します。2セット目は、業務分析などを通じて顧客の情報を可能な限り収集し、伝票や文書などの必要なものはすべてスキャンします。 立体物などは、デジタルカメラなどで記録するのもよいでしょうし、実物を会議の席に持ってくるのがベストです。ムービーを用いることも効果的でしょう。 これらは議論の対象に関して、繰り返しお話ししている開発側の「顧客業務の徹底理解」ができていることを伝えるための大切なツールです。議論の中で、すかさず議論の対象に関連する資料を画面上に表示できるよう、データの整理を充分に行っておきます。 資料として配付したものは基本的に参加者のメモという意味であって、議論の中では基本的にプロジェクタの中の伝票や文書などの情報を見て議論を行うようにします。進行役として、まず意識する必要があるのは、参加者全員が同じ情報を見ているということです。 配付資料では見るページを間違えていたり、勝手に違うところを見て聞いていなかったり様々な問題があります。会議の進行者は参加者全員を見渡して、全員がプロジェクタや議論の相手を見て話をしているかどうかに注意しながら議論を進めます。もちろん、手持ちの資料や自分で作ったメモなどを見ながら話すこともあるでしょうから、少しも手元を見ないということではありません。 開発側の代表として参加するプロジェクトマネジャーあるいは仕様策定者としては、個々の議題に関してプロジェクト全体の利益を考慮した上での建設的な案をあらかじめイメージしていなければなりません。そして、議論の結果として可能な限り自分たち開発側が最も能力を発揮しやすい形とする必要があります。 |
||||||||||||||||||||
| 開発側にとって、「最も能力を発揮しやすい」進め方 | ||||||||||||||||||||
|
開発側にとって、「最も能力を発揮しやすい」進め方というのは表4の進め方です。
表4：開発側にとって最も能力を発揮しやすい方法 顧客側との会議の前には必ず開発側内部での会議を行い、開発側実作業者らのプロフェッショナルとしてのアイデアや要望などを確認し、明確に説明できるようにしておく必要があります。 事前に開発側としての方向性を明確にした上で、それらについてを議論の場で顧客側へ根拠とともにしっかりと説明して同意を得ていくというのが、開発側代表の基本的な会議への臨み方です。 システム開発に関しての経験をベースとした明確な考えが顧客側にある中での議論であれば違ってきますが、そもそも顧客側はシステム開発のプロではありません。 顧客が納得のいくようなプロフェッショナルとしての案を提示し、顧客が納得して自分たちの決断として決定してもらえるようにしていくのが開発側の仕事です。このことを意識していれば、よほどのことがない限り「顧客が決めてくれない」という状態は発生しません。 顧客側としても、自分たちの会社の業務として開発に関わっている以上、積極的に協力し、議題に関して必要と考えられる情報はできる限り提示していく必要があります。そして、契約そのもの含めた様々な面で「Win-Win」の関係を実現することを考える必要があります。実際、成功するプロジェクトは「Win-Win」の考え方が大きく影響しています。 時として、自分たちの業務を開発側が分かっていないとバカにしていたりするようなことも見かけます。ちょっとした冗談程度であれば別ですが、その前に自分たちが数ヶ月や数年かけて理解した仕事をいかに短期間で開発側へ伝えるかを議論するべきでしょう。開発側も「業務分析」を行っていく中で、ガンガンと顧客の現場に入っていき、簡単にはバカにされないぐらいのモチベーションや能力を示す必要があります。遠慮していてもシステムはできあがりません。 |
||||||||||||||||||||
| プロジェクトを成功へ向ける力 | ||||||||||||||||||||
|
プロジェクトが失敗する要因には様々なものがあります。そういった例として、できるかどうかわからないにもかかわらず受注してしまう開発会社を見かけることがあります。逆に、ただ権威的に「どう考えているんですか？」と、焦点のわからない漠然とした質問で立場の弱い開発側を責めるような顧客側担当者も見たことがあります。 そのようなことをしても、どうにもならないどころか、結局は顧客側に不利益が生じてくることになります。たまたま関わりかけたプロジェクトで目にしたことがありますが、どっちもどっちといえるような状況で、顧客側も実はそれほど仕事を真剣に考えてはいないように筆者には見えました。能力ではなく、単なる立場の権力で面倒なことを立場の弱い者に押しつけているだけです。本当にプロジェクトを上手く運びたいのであれば、他に考えるべきことやできることは沢山あります。 とはいえ、その様な質問をさせてしまい、かつ質問のあいまいさとそこから見える真実を指摘できない（しない）開発側組織は確かに問題ありです。いずれにしても、顧客側担当者や承認者の人選ミスは、顧客側組織にとって極めて大きな損害を招く場合があり、慎重に行う必要があります。 プロジェクトが上手くいく要因には様々なものがあります。肝心のマネジャーが足を引っ張りこそすれ、役割を果たしておらず、開発側のプログラマが実質的に様々な面で影響力を発揮してプロジェクトを成功に向けて引っ張っている場合が現実あったり、顧客側担当者がうまく開発側のマネジャーを動かして成功へ向けている場合もあります。 周囲の人々はその状況をあまりわからないまま、多くの人は何となくうまく物事が進んでいるように思えていたりするようです。本来の役割の人が行うのと比べると間違いなく効率が悪くなってしまいますが、プロジェクトを成功へ向ける力は誰が発揮しても効力があります。 |
||||||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
