ドキュメントを作成しないユーザーは、失敗するユーザーサイド・プロジェクト推進ガイド(15)(1/2 ページ)

システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか?

» 2006年09月16日 12時00分 公開
[山村秀樹,@IT]

 コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか?

 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか? あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか?

 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に合うかもしれません。しかし、複数の業務部門がかかわる部門横断的な大規模なシステムの開発であれば、特に情報の質として満足できるものではありません。

 もし、ベンダに提示する情報がこの程度で良いと考えているのであれば、そもそも発注側でありながら、「いいシステムを作ろう」という気がなく“やっつけ仕事をしている”、あるいはシステム開発に関して“素人だ”と思われても仕方がありません。

 ありあわせの資料でことを済ませようとして、プロジェクトに積極的にかかわる姿勢を見せなければ、ベンダからは「リスクの高い発注主だ」と評価されることになるでしょう。良いシステムを作ろうと思うならば、それなりのプロセスがあり、その時々の結果を示す資料が存在するはずで、これらを整理したものがベンダへ提示されるべきです。

 “素人”と評するのは、自社内の自分たちですら業務の詳細を知らないのに、ベンダがそれを簡単に理解し、期待どおりの提案をしてくれると思い込んでいるところです。自ら骨を折ることをせず、値切りに値切った費用にもかかわらず、ベンダが最高の努力をしてくれると思っているならば、“ビジネスの素人”であるともいえます。

ベンダを過信してはいけない

 ユーザー側のメイン作業の1つは、ベンダに機能要求仕様を正しく“理解させる”ことです。いいたいことだけをいって大仕事をしたつもりになって、「あとはあなたたちでまとめておいてください、以上!」といい放つことではありません。コンピュータ・システム開発プロジェクトは、機械設備の導入プロジェクトと比較しても、より複雑な事情をいろいろと含んでいます。しゃべるだけですべてが正確に伝わるようなシンプルな事情を扱う案件ではないのです。

 複雑なプロジェクトなのにもかかわらず、ユーザー側が一方的に要望事項を伝えるだけで、ベンダの要求定義書をレビューさえしないケースがあります。ときどき、ユーザーがベンダのシステム化範囲の業務を理解する能力やその業務について改善提案する能力を、どの程度に評価しているのか不思議に思うことがあります。どうも、「ベンダは何でもかんでもできるもの」と思い込んでいるユーザーが多いのかもしれません。

 プロというのは要点だけ指示すれば具体的な作業をすべてこなすものと思い込んでいるのか、あるいは(“プロ”の定義に「要点だけ指示すれば具体的な作業をすべてこなすもの」があるとすれば)ベンダの大多数がプロとして信頼できるものと思っているのか、とにかくユーザーが言及しないことまでベンダは見通せると思っているのです。コミュニケーションにはリスクが存在するものですが、ユーザーからベンダへの伝達ルートに限ってはこのリスクは意識されていないようです。

 また、「ユーザーの要求を引き出すことがベンダの仕事」とされていることも、ユーザーに「ベンダは優秀な人間の集まりで、ユーザー側として何か特別な準備をしなくてもよい」と思い込ませる一因になっているようです。本当にユーザーの要求を引き出すことがベンダの仕事であるならば、ユーザーは問われたことに答えるだけでよいことになります。ベンダのセールス担当者が巧みな営業トークの中で「わたしどもが何でもやります」ということがありますが(※)、ユーザーはこれを真に受けてはいけません。ベンダがユーザーの要求を引き出す前提には、ユーザーがベンダに要求を伝えるという要素があるのです。

 「要求定義もします」というようなベンダでも、実際には要求の確認や表面的な不備を指摘するにすぎず、要求の管理すらできていないケースも少なくありません。ベンダの能力を過信することは危険です。本当に必要なのは、ユーザーの主体的な努力です。ベンダに理解してもらうのではなく、ベンダに理解させるのです。“理解させる説明”のためには、ユーザー側でのドキュメント作成が必要不可欠です。

 ※ベンダは「わたしどもを業者としてではなくパートナーとして見ていただきたい」ともいいます。「信頼してほしい」という意味の発言かもしれませんが、パートナーシップとは対等な協力関係をいい、「何でもやります」とはまったく違います。パートナーうんぬんというセリフには「分担した役割をお互いに責任を持ってやりしょう」という意図があります。


ドキュメント作成の省略は合理的ではない

 ベンダは、ユーザーの要求を分析・チェックします。これは単純な聴き間違いや意味のとらえ違い、不明な事柄、矛盾、不整合などに気付かずにプロジェクト作業を進めれば、手戻り作業が発生することになるので、これを避けるためです。チェックを怠ると、場合によっては作業を初めからやり直すことになったり、運用に入って致命的なトラブルが発生したりすることがあります。

 ベンダはこの作業のために、ドキュメントを大量に作成します。そのため「どうせベンダはユーザーの要求を理解したりチェックしたりするためにドキュメントを作るのだから、ユーザー側がドキュメントを作る必要はない」と誤解することになるのです。

 しかしベンダが仕様に矛盾や不整合がないようにチェックする作業は、本来ユーザーがしっかりと行っておくべきで、その前提でユーザーはベンダに機能要求仕様を説明すべきなのです。ユーザーがベンダへの説明をあらかじめ整理することと、ベンダがユーザーの業務や要求仕様を理解するための作業とは意味合いが違います。

 ところがユーザー側でもベンダ側でも、この作業を混同していることがあります。ベンダは受注競争の中で、できもしないのにユーザーに代わってユーザーの要求をとりまとめて整理することを約束さえします。

 ユーザーがドキュメントを作成しない場合、ベンダ側の理解は精度と効率が低いものとなります。またユーザーがドキュメントを作成していれば、自分たちで発見できたかもしれない不備が、ベンダで分析するまで、あるいは分析したドキュメントを見るまで気付かないことにもなります。それどころか、運用するまで不備に気付かない可能性も大いにあります。

 ベンダ作業に便乗するやり方は、一見、無駄なく合理的と見えるかもしれません。しかし、現実にはよいやり方と評価できません。結局、このやり方はユーザー側の作業時間を少なくすますことができたとしても、ベンダから驚くほどの追加費用を請求されるプロジェクトとなるのがオチです。それにこのようなシステムは取り返しのつかないほど複雑怪奇でたくさんの無駄を抱えており、そのライフサイクルにわたり業務改善を阻害するものとなるでしょう。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ