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

» 2006年02月14日 12時00分 公開
[山村秀樹，＠IT]
前のページへ 1|2 　　　　　　

実は、管理していない「メッセンジャータイプ」

プロジェクトチームが業務知識に自信が持てないと、（2）のメッセンジャータイプになります。

　このタイプは、ベンダに作業を丸投げしているわけではないので、仕事をしていると考えています。そのため、プロジェクトが失敗した場合、ベンダ側に責任があると思い込みがちです。ところが、実はこのタイプのチームが行っている作業は、ユーザーサイドの仕事としては不十分であり、失敗の芽をもともと含んでいるのです。

　プロジェクトチームは、情報の仲介作業を通して仕様に関する知識を得ます。ベンダとやりとりした資料や書類も整理しています。ただしその実態は、決められたフォーマットで清書したものをフォルダへため込んでいるだけで、記述されている内容そのものが管理されているわけではありません。

　プロジェクトチームは、やりとりした資料や書類を取り扱いやすいように整理するのはベンダ側の仕事で、かつそれがきちんと仕様書に反映されるものと思っています。チームはベンダとのやりとりと書類の作成で十分仕事をしている気になり、それ以上には自分たちが提出している仕様のバランスや整合性に気を留めません。

　さてプロジェクトでは、機能要求仕様を詰める段階になって、同じ業務部門であっても人が違ったり、同じ人であっても状況が違ったりすれば、意見が前回と違うことがあります。またほかの部門と調整した結果、前に決めたことを変更しなければならないこともあります。そして検討のやり直しになるのですが、これが何回も繰り返されることも珍しくありません。

　プロジェクトチームは、業務部門からの要求事項などを管理しているのはベンダだと思っていますが、ベンダは業務の詳細にまで精通しているわけではなく、時間や人数にも制約があり、速やかな対応ができません。日々変わっていくユーザーからの要求を精査し、不整合や調整の必要性をすぐにプロジェクトチームに連絡してくれるということは淡い期待に終わります。

　結局、ベンダにおいて機能要求仕様を管理し切れません。ベンダによる管理を当てにしていたユーザーサイドのプロジェクトチームは、途中の段階では仕様を把握していても、最終的な仕様が分かりません。システムの立ち会いテストや本運用に至って業務部門からクレームが続出しても、ユーザー側がベンダに要求した仕様がユーザー自身にとって不明で、果たしてこのシステムは要求した仕様どおりに作られているのかどうかさえも分からなくなることになります。

　ベンダとの、質疑回答のやりとりだけではなく、打ち合わせにおいても同様のことがいえます。プロジェクトチームはそこにいるだけで、業務部門がいいたいことをしゃべる、ベンダがそれを議事録にする、時にそれは前回の打ち合わせと矛盾している、そしていつの間にか仕様が不明になります。

　そのほかにもこのタイプのプロジェクトチームの欠陥として、業務部門の「必要だ」の一言に適切な対応ができずに、仕様の肥大化を招くことがあります。また、業務部門が協力的でなかったり、忙しくてプロジェクトどころでなかったりした場合、スケジュールが遅れることも挙げられます。

“衆知”に背を向ける「独断専行タイプ」

　（3）の独断専行タイプは、業務に関して自信満々のメンバーで構成されていたり、業務を改革するには多くの人との話し合いは時間の無駄と考えていたりするチームです。

　開発の段階では、チーム内でメンバー同士の衝突があるとしても、業務部門との衝突がありません。このタイプであれば、確かに速やかに機能要求仕様を作れます。

　しかし、出来上がったシステムは“使えないシステム”になる可能性が大いにあります。現場を知らずに作られたシステムが理屈倒れになるのは、当然のことです。独り善がりなシステムでは話になりません。いかに業務を知っている人がプロジェクトチーム内にいたとしてもすべてを知り尽くしているとは考えられず、重要な見落としがある場合も多いといえるでしょう。

　エンドユーザーが「使えない」と思っても、莫大なコストを費やしたためにシステムを使わざるを得ず、結果として業務に支障を来すことも考えられます。

学ぶ姿勢を貫く「実習生タイプ」

　（4）の実習生タイプ──これは、「仕事には手を抜かないという信条のため」「自分のキャリアに傷を付けないため」「失敗が大嫌いだから」、あるいは「もともとユーザー側の作業がプロジェクト全体に大きく影響することを承知しているから」など理由はさまざまですが、とにかくプロジェクトを成功させるために努力しようとするメンバーが活躍するプロジェクトチームです。

　しかし、このプロジェクトチームにはシステム開発の経験がない、もしくは失われています。故に彼らはシステム開発に必要な作業には、何が必要でそれはどのように実践すべきかといったことに関して、自ら積極的に勉強する必要があります。もし、社内のどこかにシステム開発の記憶が残っているのであれば、それは良い学習材料になるでしょう。それがなければ雑誌・書籍・Webサイトの記事、各種団体などの勉強会などでいろいろな事例やノウハウを学ぶとよいでしょう。

　何の準備もないままプロジェクトに臨むことは危険です。いくらやる気があったとしても、プロジェクトをまったくの試行錯誤の場とすることはあまりにリスキーです。それこそ時間がいくらあっても足りません。やるべきこととそのやり方を計画し、作業の中でより良いやり方、あるいは逆に不都合がはっきりすれば修正を加え、手応えや効果があれば、そのやり方を定着させます。

　このプロジェクトチームは、プロジェクト完遂までにより多くの時間を費やすことになるでしょう。しかし、努力の結果、スケジュールどおりの期間でユーザーとして責任の持てる機能要求仕様書を完成させることができたならば、そのシステムはライフサイクル全体で考えると、費用的にも時間的にもローコストなものとなります。トラブルが発生した際の復旧も速やかであり、改造の際の費用も低く抑えることができます。

　それは、ユーザーの頑張りによって、ベンダが設計やテストを十分に行うことができ、きちんとしたドキュメントの作成も可能だからです。また、ユーザーが業務プロセスを管理しているから、余分な調べ事が不要となるからです。分かりやすいドキュメントをキチンと維持管理すれば、担当者が変わっても将来にわたって運用コストを抑えることができます。

　最後に、（5）のエキスパートタイプは理想です。こうしたレベルに到達するのは、簡単なことではないでしょう。そこへ至る道の第一歩は、（4）のタイプのチームです。まずは、（4）のタイプのチームとなることです。

　さて、次回はなぜこうしたチームになってしまうのか、プロジェクトチーム編成にまつわる制約を考えていきます。

筆者プロフィール

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

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

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



「ユーザーサイド・プロジェクト推進ガイド」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ