メディア

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

» 2005年09月21日 12時00分公開

[山村秀樹，＠IT]

業務部門が機能要求仕様の検討をしない／できない理由

　以上のことから、業務部門の目的達成は業務部門の責任であり、その責任を果たすためには、システムに対する機能要求の検討を、プロジェクトチームではなく、業務部門において実施することが、プロジェクト成功への近道となることが分かります。せりふにすれば「どのような業務のやり方、システムとすればいいのか、現場で十分考えていただきたい。プロジェクトチームはそのお手伝いをさせていただく。力を合わせていいシステムを作ろう」となります。

　しかし、その一方で、立場的・技術的に業務部門で自らの機能要求を検討することが難しいとされる理由もあります。

プロジェクトチームの調整により決定事項が変わる

　大規模なシステムでは、その業務範囲に関係する部署は多数となります。機能要求を検討する主役は業務部門といっても、その部門が多数であれば相互に矛盾する要求が出てきたり、優先順位を整理する必要があります。このようなプロジェクトのバランスを取ったり、コントロールしたりする作業は、業務部門の中の特定部門が行うよりは、中立的なプロジェクトチームが担当するのが適当です。ところが、プロジェクトチームが業務部門間のバランスや相反する機能要求を調整するために、業務部門がせっかく出した要求事項を変更したり棄却したりするうちに、いつの間にか機能要求の検討自体もプロジェクトチームが主体となって行うようになってしまうという現象が見られます。

　確かに、プロジェクトチームが部門間の調整を行うことは適切なことです。これはプロジェクトチームの役割の1つであり、プロジェクトチームにはその能力があります（なければなりません）。しかし、だからといってプロジェクトチームが業務部門の機能要求を検討すればよいかといえば、それは話が別です。プロジェクトチームには、業務部門の目的達成の責任を取れません。

　この問題に対しては、プロジェクトチームは業務部門と密な関係を保って、調整による影響が大きなものにならないように、内容やタイミングを配慮することが必要となります。

業務部門にIT知識がないので決めようがない

　業務部門では、コンピュータ・システムで何ができるのか、どの程度のことができるのかが分からないために適切な要求が決められないという場合もあります。業務部門が時間とエネルギーを掛けて要求をまとめても、いざ要望してみるとコンピュータ・システムに実装するのに困難だったり、費用が掛かり過ぎるなどの理由で拒否されることがあります。すると、業務部門は無駄骨を折ったと感じたり、落肝したりします。そこで、「最初からITに詳しいプロジェクトチームが中心となって機能要求仕様を検討する方が効率的だ」という考えになってしまうのです。

　しかしITを知っているからといって、業務を知らずに機能要求を検討することはできません。業務に精通しているとはいえないプロジェクトチームが中心となって作成した機能要求仕様では、例えば業務部門の立会い検査や本稼動で不備が発覚し、仕様の作成からやり直さなければならなくなるなど、作業の後戻りが発生する恐れがあります。効率的どころか、むしろ、無駄な作業が内在しているとさえいえます。極端な話、現場を知らずに理屈だけで作ったシステムは使い物になりません。使えないものを効率的に作っても、意味はありません。

　といっても、IT知識やITを使った事例などの情報があれば、プロジェクトの参考になることは確かです。システムを開発するベンダが決まっていれば、プロジェクトチームはそのベンダの知識を利用することができます。プロジェクトチームとしては、ベンダや業務部門と密な関係を保ち、両者を橋渡しして素早く有用な情報を業務部門に提供することが大切です。

プロジェクトチームの現実解

　システム開発の際に、業務部門が自身の目的を達成するために、自ら主役となって機能要求をまとめることが本来のプロセスであり、これは十分に実施可能なことです。ところが、現実にはよほど高度なレベルでの取り決めや意識改革がないことには、プロジェクトチームが各業務部門の機能要求の取りまとめをしなければなりません。これは、プロジェクトチーム単独では解決し難い問題です。

このような場合、プロジェクトリーダーは、上級職や業務部門に対して「業務部門のことは業務部門で検討することが本来の姿だ」と具申、あるいは要請するのはもちろんですが、一方では現実的な対策としてプロジェクトチーム側が中心になって機能要求をまとめる覚悟とスキルを準備することが必要です（この作業をベンダに投げてはいけません）。

　殊に、現状の仕様が不明になっている既存システムの機能変更を伴わない単純更新の際に、ベンダを変更しようとする場合は、最初からプロジェクトチームが中心となって機能要求をまとめることになります。業務部門に対するヒアリングなど一からの調査が必要であり、大変な作業になります。

　もちろん、業務部門が主役となって機能要求仕様を検討する場合においても、プロジェクトチームは、部門間の相反する要求を調整しなければならず、機能要求をまとめる作業はあります。

ITガバナンスが存在する場合

　ITガバナンスという言葉があります。この言葉にもいろいろな定義があるようですが、その中には、「企業のトップマネジメントによって定められたシステムを開発する部署、ならびにそれを使用する部署の役割や責任の規定」も含まれています。このガバナンスに、システムを使用する部署の責任と義務として、「そのシステムを開発する原始の目的を達成すること、そのために、機能要求仕様の策定を行うこと」との定めがあれば、本来のシステム開発のプロセスを取れます。

　つまり、業務部門は、課題の解決、目的の達成のために必要な機能を自ら検討し、プロジェクトチームに伝えなければなりません。

　一方、プロジェクトチームは、業務部門に対して支援を行います。その際に注意しなければいけないのは、業務部門自ら要求を出した場合でも機能にモレや誤解が混入している恐れがあるということです。従って、それを防ぐような工夫──例えば、ツールとその利用方法などを業務部門に教える必要があります。また、何でもかんでも要求事項にせず、システムは小さく始めて育てていくものであることも教えます。そのほかにもプロジェクトチームを通さずに、直接ベンダに要求事項を伝えないようにルールを決めたり、ITでできることのアドバイスを行うなど、さまざまな支援を行います。

　なお、ここでの支援とは、相手が困ったときだけ手助けすることとは違います。各業務部門の作業管理が前提として存在し、進ちょくや作業の質を維持することも含みます。

　また、プロジェクトチームは、ITガバナンスによって定められた各部門間の境界付近の業務など、部門によって食い違いが発生している要求事項の調整作業を行います。

　こうしたITガバナンスがどれだけ普及しているのか不明ですが、あまり広まっていないのではないでしょうか。ITガバナンスが定着すれば、システム開発の成功率はもっと上がるはずです。

　次回以降、現実を踏まえ、プロジェクトチームが各業務部門の要求事項を取りまとめることを前提に各段階での作業を考えていきます。

profile

山村秀樹（やまむらひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、なかでもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

前のページへ 1|2|3 　　　　　　