前回に続き、顧客との運命共同体をいかに築くかである。法的に契約を満たせばよいというものではなく、顧客とベンダーが運命共同体として同じ船に乗り、荒波を乗り切って行くことが、プロジェクト成功の必須条件になる。幹部層も含めて顧客とよく連携を取り、プロジェクトの成功に必要なことは積極的に提案するとともに、遠慮せずに意見交換できる関係を構築したい。
大規模プロジェクトや難航が予想される新規プロジェクトの場合、顧客側の幹部も、プロジェクト進捗報告のためにベンダー側の幹部が集まる幹部会に出席してもらうことが望ましい。最近の不幸なプロジェクトに関する記事を見ると、幹部間の意思疎通の悪さが感じられる。「もし定例幹部会を開催し、もっと実質的に議論していれば、これほどの事態には至らなかったのでは」と思われてならない。
幹部会設定の最大の目的は、発注者と受注者が同じ船に乗ることと、乗っている船が沈んでは困ることを関係者全員が共有すること、プロジェクト・メンバーでは解決し切れない課題や問題を両社幹部の支援で解決に向かうきっかけを与えることである。 また幹部には分かりやすく筋道を立てて話す必要があるため、受注側・発注側ともに、責任者がいやでもプロジェクトの実態を把握する立場に追い込まれることも、幹部会の大きな効果だ。
システムの開発過程において、顧客からの仕様追加・変更要求は、プロジェクト混乱の大きな要因になるだけに、できるだけ抑える必要がある。だからといって、顧客の仕様追加・変更要求を何とか断り、「早くまとめよう」「何とか説得しよう」とあがいても、なかなか思うようには理解してもらえず苦戦することが多い。
頑なに断るほど、かえって要求が厳しくなり、連帯感も減ってしまいがちだ。むしろ、まず要求を素直に受けるという“積極的受動性”を持って顧客の話を聞くように努めると、本当のニーズがよく見えるようになる。
真のニーズや目的が見えてくると、それまでに出していた提案の延長線上で、より経済的で有効な代案が出しやすい。そしていい提案ができれば、あまりコストをかけずに顧客の要望を取り入れられるため、相互の信頼感も深まってくる。
顧客は、自分のやりたいことをベンダーに話し、それをきちんと実現してくれることを期待している。そこに間違いはないが、何でもユーザーに言われるままに対応しても信頼が高まるとは限らない。「これをやってくれ」と言われたとき、「それを実現するとこんな問題があります。むしろ、こうしたほうがよいのではないですか」と代案を提示するほうが信頼されるだろう。
あるユーザー企業の代表は、ユーザーの言いなりになるSEのことを“言いなりマシーン”と批判されている。言いなりになるのではなく、しっかりした軸を持ち、システムとしてやるべきこと、顧客にとってなすべきことを、積極的に熱意を持って提案できるSEこそが期待されているのである。
顧客と共同でプロジェクトを推進する場合、問題点の早期解決のために両者が参加する各種会議が設定される。会議では、いろいろな報告が必要になるが、顧客側の参加者にも分かりやすいように、報告書は設計書と同様にシンプルで美しくありたいものである。
長々とした報告は聞くに飽きるし、読むにも疲れる。基本的に、個条書きにし、各項目が一貫した考え方で整理されている必要がある。思いついたまま勝手に並べては、何を言いたいのかが分からなくなってしまうからだ。
さらに各項目は階層的に整理されていなければならない。階層化によって、大事なことが少数の大項目に整理され、理解しやすくなる。幹部クラスに説明する際は最上位層だけを説明し、専門家には下位層の中で詳細を説明するようにして理解不足を補いたい。
