タイプ別プロジェクトチームの問題点：ユーザーサイド・プロジェクト推進ガイド（5）（1/2 ページ）

プロジェクトの概要が決まってきたら、プロジェクトチームの編成となる。しかし、システム開発の経験がない企業では、名ばかりのプロジェクトチームになってしまいがちだ。

社内でプロジェクトチームを編成する

　規模の大きなシステムの開発は、想像以上の作業ボリュームがあります。おおよそのスケジュールを立ててみると、一刻も無駄にしたくないと思うはずです。そこで、速やかにプロジェクトチームの編成を行い、本格的な作業に取り掛からなければなりません。

　たいていの場合、プロジェクトチームはシステム担当部署の内部に組織され、業務部門や設備部門など複数の関係部署と連携を取りながらプロジェクトを進めていくことになります。

　システム化の範囲となる業務が、2〜3の部署程度である小規模システムの開発では、基本的にプロジェクトチームというほどの組織は必要ありません。システムの規模も複雑さもそれほどのものでなければ、開発に携わる人も少なく、プロジェクトチームを作る方が不経済です。

　他方、組織横断的な大規模システムの開発プロジェクトでは、チームを作ることになります。これは､多くの部署をカバーするためですが、大規模なシステムとは、活用する業務部門にとってはある程度包括的なシステムであって、管理職／ライン／スタッフ／事務など多くの役割から使われるため、いっそうの調査、検討が必要になるからです。機能が限定されている小規模システムに比較すれば、必要とされる機能の数はかなり大きく、しかも役割間で矛盾する機能の要求もあります。さらに部署間の利害関係の対立が発生することもあり、その調整も行わなければなりません。

　このような状況では、どのようなプロジェクトチームが組織されるかによって、プロジェクトの成否は大きく左右されることになるでしょう。

プロジェクトチームのタイプ

　ユーザーサイドのプロジェクトチームを分類してみます。この分類の狙いは、プロジェクトチームにありがちなタイプを取り上げ、その中から危険なタイプを指摘し、そのタイプにならないように警告することです。

（1）丸投げタイプ

　調査や仕様の検討、調整など実務はすべてベンダが行います。プロジェクトチームが行うのは、ベンダと業務部門の打ち合わせ日程を調整したり（これもベンダと業務部門任せの場合もあります）、ベンダの作業報告を聞いたりするぐらいです。

（2）メッセンジャータイプ

　プロジェクトチームは、ベンダと業務部門のやりとりを中継します。前もって決めておいたフォーマットで記述されたベンダからの質問をメールや電話で業務部門に問い合わせ、その回答をやはりベンダと決めたフォーマットに書き直してベンダへ送付します。

（3）独断専行タイプ

　プロジェクトチームは業務部門に意見を諮ることなく、仕様を決めます。プロジェクトチームは、現状業務のプロセスや問題点などを把握しており、独自の改善策などの案を考えています。

（4）実習生タイプ

　プロジェクトチームは機能要求仕様書の作成や管理を、ベンダに任せっ放しにせずに、自らが主体となって行います。システム開発の経験や業務知識が乏しいため、ときには何をどのようにすればいいのか戸惑ったり、当てが外れて失敗したりします。それでも、業務部門やベンダの協力を得て学習し、工夫と実践、反省を繰り返しながら成長していきます。

（5）エキスパートタイプ

　磨き上げられた開発プロセスやIT技術を組織的に保有しながらも、常に勉強し、試行錯誤を怠りません。その活動の中で、若手に組織の記憶を伝達し、経験を積ませ、発展させます。ベンダとの役割関係においては主導権を持ち、プロジェクトを管理監督します。トップマネジメントや業務部門から厚く信頼されており、ベンダとの適切な関係にも注意しています。

　実際には、1つのプロジェクトチームがプロジェクト全フェイズを通して同じタイプであるわけではありません。ある局面では丸投げタイプであったり、別の局面ではメッセンジャータイプであったりします。プロジェクトチームごとに得手不得手もあるでしょうし、チーム外の各種条件によっても、いろいろなパターンが出てきます。

プロジェクト成功は“運任せ”の「丸投げタイプ」

　まず、（1）の丸投げタイプは、プロジェクトチームを名乗っていたとしても、実際には存在していないのと同じです。人がいないから丸投げしているのであり、チームとして機能しているはずがありません。なお、プロジェクトマネジメントに不備があり、スケジュールが押せ押せとなった結果、途中から丸投げになる場合があります。

　コンピュータ・システムの開発は苦労の多いものであり、ユーザーとベンダの協力が不可欠です。また、時間もかかるものです。客としての立場からは、「カネを払って人も出す、そのうえ時間もかかるとはどうなっているのか、まともなベンダならサッサとシステムを作れ」となるかもしれません。いいたいことは分かるのですが、コンピュータ・システムの開発がそれでうまくいくことはまずありません。丸投げは失敗のもとであり、また自社内で業務プロセスの可視化や改善、プロジェクト推進のノウハウなども蓄積できません。

　理屈でいえば、まともなベンダ──というよりも、優秀なベンダ──に依頼することができれば、システム開発プロジェクトは成功します。こうしたベンダは豊富なノウハウを背景に、業務部門などの関係者に対してさまざまな観点から質問や提案をして、相手の持つ隠れたノウハウや問題点を明らかにし、モレや不整合など不備のない仕様を作成することができます。関係者の間で対立が発生し、調整が必要となった場合も、実績や経験のある第三者としての立場から、当事者の理解や納得を得ます。

　このようなベンダをパートナーにできれば、ユーザー側にITやプロジェクトマネジメントのスキルがなくても、課題解決や目的達成に有効なシステムを手にすることが可能でしょう。ただし、この場合であっても、調査などにはかなりの工数が必要で、業務部門などの関係者にはそれなりの負担や協力が必要です。

　ユーザーは、このようなベンダを望んでいます。しかし、こうしたベンダ（厳密にいえばベンダのプロジェクトチーム、プロジェクトマネージャ）と巡り合うのは、“僥倖（ぎょうこう）”といわざるを得ません。IT系の雑誌・書籍・Webサイトで、優秀なベンダの記事や宣伝を見ることがありますが、そのようなケースが少ないから取り上げられているのです。