プロジェクトチームにおける“システム担当者”の役割：ユーザーサイド・プロジェクト推進ガイド（8）（3/4 ページ）

[山村秀樹，＠IT]

システム担当部署メンバーの活用ポイント

　とはいえ、システム担当部署が保有している知識・経験を生かさない手はありません。システム担当部署のメンバーがトラブル対応や既存システムのメンテナンスに忙しくても、最大限プロジェクトに参加できるように配慮することは、プロジェクトの成功率を高めることでしょう。システム担当部署の各メンバーのモチベーションを維持すること、彼らの知識や経験を引き出すこと、そしてそれをプロジェクトメンバー全員で共有することはプロジェクト成功への鍵なのです。

業務知識や気付きを活用する

　前に述べたように、プロジェクトチームに参加する業務部門出身者といっても、すべての業務部門から人を出してもらうわけではなく、プロジェクトチームに人を出さない業務部門もあります。システム更新に伴うプロジェクトである場合、その部門に対しては、ほかの業務部門出身のメンバーよりは、既存システムの保守などを通じて接点のあるシステム担当部署のメンバーの方が業務知識を持っています。

　この知識は、業務プロセスを理解するうえだけではなく、機能要求仕様のモレを防ぐのに役立ちます。プロジェクトの中で業務部門など関係者から問題点や要望をヒアリングすることは重要な作業です。しかし、業務部門が口にすることだけがすべてではありません。少なからずモレがあります。

　業務部門はシステムなどの設備を使用する立場ですが作る立場ではありません。そのため、要求した機能にモレがあるかどうかを事前に綿密にチェックする習慣も意識もありません。システム担当部署のメンバーはメンテナンスを通じて、その職場のエース級に限らず（真の）エンドユーザーからいわれたこと、あるいは何がしか感じることがあるはずです。過去に要望されていて実現できず見送った機能も知っています。それを挙げるべきなのです。打ち合わせの場では、それが示唆となり思いがけないアイデアが出ることもありますし、別の仕様モレに気付くこともあります。

知識・経験を活用する

　また、機能要求の検討において、従来のIT技術の知識・経験が不要であるとは考えられません。システムの開発の経験が仮になかったとしても、保守をしていれば現場の評価の高いシステムやそうでないシステムの特徴、異常事態発生時の処理方法、変更のしやすい仕組みやトラブルの発生しやすい仕組み、メンテナンスしやすい仕組み、使いやすいメニュー構成や入力のしやすい画面構成などが分かっています。これはベンダよりもユーザーが分かっていることで、有効なシステムとするにはこれを生かすことです。

　業務部門のシステムに対する要求が多い場合、そのすべてを機能要求事項にすることはできず、その中から重要なものを選択しなければなりません。その際、実現性や費用対効果が判断材料の1つになりますが、実現性や費用に関してはIT知識や経験がなければ見当すらつきません。これらの判断をベンダのみに頼ることは、ベンダの都合に左右されることになり、合理的なことではありません。また、業務部門に対して技術的な理由で要求事項を断る場合、経験（信頼）のあるシステム担当部署の人間の方がうまく納得してもらえます。

ライフサイクルを通じて活用する

　さらには、システム担当部署がスキルを身に付けないとはどういうことかを考えてみてください。見積もり競争中は各ベンダの案や費用を比較することで、ある程度それらの評価ができます。しかし、例えばその後にベンダが「システム構成を変更しなければならない事態になった」といいだしたらどう対応しますか？ システム稼働後の改造などを1社だけに作業依頼する際の理不尽な見積もりを見破れるでしょうか？ システムのライフサイクルを考えると、かえって高コスト体質になります。

　もし、システム担当部署に知識や経験がないとすれば、なおのこと、プロジェクトを通して実力を付けるよう努力するべきです。実習生タイプのチームとなり、ベンダのやり方を観察し技術を盗んでください。ベンダの不手際、頼りないと感じたところ、不満なところは反面教師としてください。

強いチームであるための構成要素として活用する

　チームとはメンバー同士が刺激し合ったり補完し合ったりして相乗的な効果を出す組織です。この観点からは、システム担当部署、業務部門出身のメンバーがそれぞれの考えを持ち合って検討し合い、より適切な考えを導くことが重要といえます。

　やる気満々の業務部門出身のプロジェクトメンバーは、システムに対して要求が大きくなりがちです。また、現場の人の中には、自分たちはアイデアを出す、後の作業は業者に丸投げすることが効率的な仕事のやり方だと信じているところがあります。そのような部署からプロジェクトチームに異動したメンバーはこのやり方を踏襲します。これらを放置しておくと、プロジェクトチームによる仕様の肥大化やプロジェクトマネジメントの不在となります。この防止には知見のあるシステム担当部署のメンバーのかかわりが必要です。

　もちろん、システム担当部署のメンバーだけで仕様を決定することにも問題があります。業務部門出身のメンバーとは逆にシステム担当部署のメンバーはコストや保守性の観点からシステムをなるべく小さくしようと考慮するあまり、業務部門の要望を切実なもの、重要なものと見なそうとしない傾向があり、現場のニーズに応えていない不親切な仕様となることがあります。

　相反する意見がぶつかって、より優れたアイデアが生まれることはよくあります。ある意見に別の観点からの意見を上乗せすることでより優れたアイデアになることもよくあります。別の意見がある意見の触媒となって優れたアイデアに発展することもよくあります。同じプロジェクトチームとはいえ各メンバーのバックボーンは違います。これを資源として有効活用します。ただし、ぶつかり合いをコントロールできずにチームを分裂させてはいけません。