ユーザー企業側プロジェクトチームの使命と役割：ユーザーサイド・プロジェクト推進ガイド（1）（2/3 ページ）

[山村秀樹，＠IT]

誰が機能要求仕様を決めるのか？

業務部門こそが機能要求仕様検討の主役

　システム開発に関しては、基本的なところで誤解されていると思われることがあります。それは、業務に使用されるコンピュータ・システムとは、「売り上げを上げる」「コストを下げる」「業務効率を上げる」といった企業全体もしくは業務部門が持つさまざまな課題を解決するために構築・運用されるものだということであり、どのような機能が必要かを検討するのは、プロジェクトチームではなく、実際にシステムを使って課題を解決し、目的を達成しなければならない業務部門であるということです。このとき、プロジェクトチームの仕事はそれを支援したり、補ったりすることです。ところが、実際にはこのようにはなっていない場合があります。

　ある部門からの要請により、小規模なシステムを開発したり、既存のシステムを改造する場合においては、その部門がいろいろ考えてシステム担当部署に注文を出します。これは、まさに業務部門が自分たちの問題を解決するために、システムの機能要求仕様にかかわるという正当な姿です。

プロジェクトチームが業務部門の要求を検討することの問題

　しかし、その業務部門の外で企画されたシステム開発や、老朽システムの更新の場合では、暗黙のうちに「プロジェクトチームでよいシステムを用意するので、ぜひ現場で使ってほしい。そのためにいろいろ聞いたり、協力していただくこともあると思うが、そのときはよろしくお願いしたい」となっていることが多いのです。これでは、プロジェクトの進ちょくが遅れたり、機能要求仕様にモレや誤解が紛れ込んで、余計なコストが掛かったり、使えないシステムができたりすることになります。これは、業務部門がプロジェクトに対して無責任であることや、ときとしてプロジェクトチームが力み過ぎることに原因があります。

業務部門の無責任による仕様の不備

　プロジェクトでは、いろいろなことを決めなければなりません。通常、関係者を集めた会議をいくつも開いてそれらの1つ1つを決定しコンセンサスを得ていきますが、そのとき、各業務部門があらかじめ部門内で取りまとめた案を提出してくれれば、その分会議を減らすことができ、プロジェクトはずっと早く進ちょくします。各業務部門が同時並行で作業すれば、なお効果的です。要求の精度も最初から高いので後戻りが少なく、プロジェクトの成功率も高くなります。

　しかし、そのように業務部門に案を用意しておくよう“協力”を求めても、実行されることは、まずありません。業務部門の案を聞くつもりであった会議で、プロジェクトチームが中心となり、参加者から意見を聞き出して、案をまとめることになります。部門横断型プロジェクトでは、これをすべての業務部門に対して行わねばならず、かなりの時間とエネルギーが必要になります。

　それでも、間違いや過不足のない機能要求仕様を作成できればいいのですが、システムが稼働してから、業務部門から不備を指摘されます。一方、プロジェクトメンバーからは、「現場が意見をいってくれない」「現場に案件の確認を依頼したが、何の応答もなかった」など業務部門のプロジェクトに対する姿勢に不満の声が出ます。

　業務部門に機能要求案の作成を要請しても、結果として何もしてもらえないのは、業務部門がその作業に責任を負っていないからです。トップマネジメントが、業務部門における課題の解決、目的の達成を求めていても、その成否の責任が業務部門自身ではなくプロジェクトチームにあるならば、業務部門はわざわざ面倒な作業をする必要がありません。業務部門にしてみれば、責任部署が作業をすればいいのであり、普段の業務だけでも忙しくほかにもすることがあるのに、プロジェクトチームのお手伝いのようなことを積極的にする気にはなれません。業務部門はできあがったシステムに不備があれば、プロジェクトチームに修正を要求すればよいだけと考えています。

プロジェクトチームの力み過ぎによる仕様の不備

まれに、プロジェクトリーダー自身が「現場からはプロジェクトのために優秀な人を出してもらっている。これ以上、現場に迷惑をかけることなく（機能要求の検討に時間をかけさせることなく）、システムを作ることがプロジェクトチームの仕事だ」という認識を持っていることもあります。背景にいろいろな事情があるとは思われますが、迷惑という言葉からは、このプロジェクトリーダーには、システム開発は全面的にプロジェクトチームの仕事であり、プロジェクトチームが業務のすべてを把握し、業務部門が関与するまでもなく行うことが理想である、との考えが基本にあることががうかがえます。

　ところが､実際には、プロジェクトメンバーの業務知識は、不十分だったり、思い込みでしかなかったりします。また､業務を咀嚼（そしゃく）しきれなかったりします。このような場合、かえって業務部門の意見を十分に吸い上げることのないまま、見当違いのシステムが出来上がる可能性が高くなります。

　業務部門にとって、プロジェクトへの関与が仮に迷惑だとしても、業務部門の考えが反映されていなかったり、プロジェクトチームの憶測や誤解が紛れ込んだシステムを押し付けられることの方がもっと迷惑なはずです。

　業務部門による要求事項の検討は、目的達成のためです。容易な作業であるわけがなく、プロジェクトチームの要求部門に対する作業要請は、少なくとも「迷惑を掛ける」というよりは「投資してもらう」という方が妥当です。