ベンダが要求を分析した結果、不明事項があればユーザーに問い合わせるためのQ&Aを作成し、理解した内容に対してはそれが本当に正しいかユーザーに確認を求めるためのさまざまな資料を作成します。
この作業はベンダにとって大変なだけではなく、膨大な量の問い合わせはユーザー側のプロジェクトチームを苦しめます。そして、ユーザーの回答は再びベンダの分析・確認作業になるのですが、その回答は新たな不明点や疑問を生みます。この繰り返しは、ユーザー側のプロジェクトチームを機能不全に追い込み、プロジェクト作業が停滞することになります。
ユーザーは、ベンダから要請のあった資料をそろえたり、メモやポンチ絵程度の資料を作ったり、またベンダから送付されたQ&Aシートに、業務部門からの回答を書き込んで送り返したりしています。しかし、要求を管理するためのドキュメントがなければ、前にとり決めた根拠を忘れて、同じ調査をし直したり、矛盾する回答をしたり、他工程の業務プロセスと整合性のとれないことを考えたりすることになります。
また、ユーザーはベンダの作成したドキュメントをチェックし、承認しなければなりません。ベンダはユーザーの要求不備を常識や想像力で補って要求定義にまとめることがあり、ユーザーはこれによってできた誤りを発見するためにもベンダのドキュメントを精査する必要があります。しかし、機能要求仕様を管理しているキュメントがなければ、これも担当者の記憶に任せた危険な作業となります。
関連記事
連載:ユーザーサイド・プロジェクト推進ガイド(5) − タイプ別プロジェクトチームの問題点(@IT情報マネジメント)
このような状況をユーザーは「ベンダの理解力不足、常識知らず」が原因と考え、ベンダは「ユーザーはやりたことが分かっていない、一貫性がない」というように受け止めます。そして、結局は面倒くさくなったユーザーのベンダへの押し付け、あるいはベンダの勝手な解釈で見切り発車──すなわち、問題先送りでシステムが作られていくことになるのです。
ドキュメントを作ったことがないユーザーでも「自分たちでドキュメントを作ることができるならば、作った方がよい」ということは分かっているはずです。時間がない、どのようなものを作ればよいのか分からない──だから作らない(作れない)のです。別の言い方をすれば、ドキュメントの意味や効果を知らないのです。
一方、経験豊富なユーザー企業では、独自に工夫されたドキュメント標準を準備しています。企業によっては、UML・DFD・ERDなど一般的な標準技法を勉強して活用しているところもあるでしょう。これらのユーザーはドキュメントを自ら作成する効果を知っているのです。
プロジェクトには人的・時間的制約があります。その制約が深刻な場合、筆者はユーザーサイドで作成する最も優先度が高く、かつ最低限必要なドキュメントとして「業務プロセスフロー図」を挙げます。ドキュメントを「自分たちで作った方がよい」と感じているならば、作成には確かに時間がかかりますが、実際に業務プロセスフロー図を作って、その効果を実感していただきたいと思います。
これを活用すれば、ベンダに要求仕様を高い精度で伝えることができるだけでありません。今回はユーザーとベンダのコミュニケーションのみに注目しましたが、業務プロセスフロー図にはコンピュータ・システムの開発作業におけるさまざまな問題を克服する潜在能力があり、貴重な時間を投入する価値があります。
次回からこの業務プロセスフロー図を作成する前準備である用語辞書作成について触れ、その後、業務プロセスフロー図について説明していきましょう。
山村 秀樹(やまむら ひでき)
某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。
Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。
Copyright © ITmedia, Inc. All Rights Reserved.