プロジェクトチーム結成──業務部門との関係を考える：ユーザーサイド・プロジェクト推進ガイド（7）（3/3 ページ）

[山村秀樹，＠IT]

ユーザー企業のプロジェクト体制の在り方

業務部門を巻き込み続ける

　プロジェクトリーダーが業務部門に人を出すように要請する際に、特に注意しなければならないことがあります。

　あなたがプロジェクトリーダーであり、後々、うそつきといわれたくないならば「業務部門にこれ以上迷惑を掛けることはしないから、メンバーを出してほしい」とはいわないことです。業務部門から「プロジェクトチームに人を出したうえ、まだ打ち合わせに人を出さなければいけないのか」と苦情をいわれることがありますが、業務部門からプロジェクトチームに参加した人が、その部署のシステム開発における役割をすべてカバーできるわけではありません。

　先にプロジェクトチームが業務部門出身者に望むことを3つ挙げました。しかし、現実にはそのメンバーが保有する出身職場に対する影響力や知識に満足できることはマレです。たとえチームに参加した当初において影響力や知識を保有していても、プロジェクトの期間中それを維持することは期待できません。

　ユーザーサイドのプロジェクト体制には、プロジェクトチームだけでなく、各部門代表者のワークグループを組織しておくべきです。業務部門には、プロジェクトチームに人を出してもらっていますが、それ以外に、打ち合わせには、業務に詳しいエース級の人を出してもらう必要があります。その人たちを組織化し戦力になってもらいます。

　プロジェクトチームに人を出したからといって、その時点で業務部門とプロジェクトの縁を切らせるわけにはいきません。常に、業務部門をプロジェクトに巻き込んでおく必要があります。問題や要望などの意見や提案をいってもらい、業務プロセスなどに動きがあればプロジェクトチームに速やかに連絡してもらいます。プロジェクトチームの成果物をチェックすることによりチームが暴走することを予防することも重要な使命です。テストや本番へ移行する際には、現場の協力体制を作り上げてもらいます。

チーム参加時にはオリエンテーションが必要

　もし、チームに「その業務部門のことはその業務部門出身のメンバーにすべて任せておけばよい」という考えがあれば、それは独断専行のチームとなる危険な芽と思ってください。チームメンバーの教育と作業管理は必要です。

　一般的に、業務部門の人は設備を使うことや機能を要求することには慣れていますが、設備の設計や実際に施工することの経験は乏しいものです。業務部門が要求すれば周り（設備担当部門）が面倒なこともちゃんと考えてやってくれるので、自分はいうだけでよい、と思い込んでいる人がいます。

　そのような人の中には、プロジェクトチームに来て、自分の考える要求のみをいい続ける人がいます。業務部門からプロジェクトチームに来た人はその時点で役割が変わります。要求を受け止め、妥当な予算で実施できるかなどを検討する立場になるのです。ところがそこを認識しないと、「プロジェクトチームに選ばれたということは要求を出す特権を与えられたのだ」と勘違いして、ベンダに要求を出し続けることになってしまいます。この状態を放置したままプロジェクトが進んでしまうと、後で取り返しのつかないことになります。

　プロジェクトチームを率いるリーダーには正しいチーム運営の知識が必要であり、チーム結成の際には適切なオリエンテーションが必要なのです。

業務部門にプロジェクトメンバーを要請する際のチェックポイント

• システム開発とはどのような作業か、出してもらったメンバーの役割はどのようなものかを書面で提出する
• 「これ以上迷惑を掛けることはしないから、メンバーを出してほしい」とはいわず、業務部門をプロジェクトに巻き込み続ける
• 参加メンバーには、チームとしての教育と管理を行う

　次回は、システム担当部署からのメンバーについて考えていきます。その後、強いチームであるための方策を取り上げ、今回言及したオリエンテーションについて考えていきます。

筆者プロフィール

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

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

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

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

• 業務の可視化で、多くの関係者を巻き込め！
• 工夫と規律で「システム用語辞書」を実現せよ
• 社内用語を統一する「用語辞典」作成のポイント
• 言葉の不統一がもたらす業務とシステムへの悪影響
• ドキュメントを作成しないユーザーは、失敗する
• プロジェクトメンバーがそろう前に行っておく事前準備
• システム開発プロジェクトの魅力を伝えよう
• プロジェクトチームのマインドとルールを方向づけるには
• プロジェクトキックオフ！ オリエンテーションで話すこと
• プロジェクトリーダーは十二分な準備で自信を生み出せ
• プロジェクトチームのリーダーに向く人、向かない人
• プロジェクトチームにおける“システム担当者”の役割
• プロジェクトチーム結成──業務部門との関係を考える
• プロジェクトチームに付きまとう制約を打破するために
• タイプ別プロジェクトチームの問題点
• 不良システムを作らないプロジェクトの枠組み
• スケジュールとコストは、ユーザー側が始めからつかめ
• 最初が大切──構築システムの“概要”を作る
• ユーザー企業側プロジェクトチームの使命と役割