特集2

●プロジェクト計画への反映

　では、次にコントロールをプロジェクト計画に反映する手順を考えてみよう。これには、(1)プロジェクト体制面(2)プロジェクト運営・ルール面(3)教育面のアプローチがある。このうち、(3)「教育面」はプロジェクトの中で実施するよりも、プロジェクトが置かれる組織内の共通教育として実施することが必要である。これについては、第3回目に詳しく説明することとし、本稿では個別プロジェクト計画で考慮しなければならないことについて説明したい。

■ステップ1:リスクの洗い出し

　まず、プロジェクトでコミュニケーションリスクがあるところをできるだけ洗い出す。

　たとえば、かつて筆者が経験したシステム統合プロジェクト（筆者が所属するA社と同業同規模のB社の基幹システムを片寄せで統合した）でプロジェクト管理を担当する筆者が想定したリスクは、(1)共同化相手であるB社とのコミュニケーションリスク、(2)共同化時にシステム改変を担当するITベンダC社とのコミュニケーションリスクを想定した。どちらが、よりリスクが高いかと言えばB社とのコミュニケーションリスクである。実はC社とは長い付き合いで気心も知れているが、B社とは初めての仕事で、会社も異なるため、コスト負担で揉める可能性が高かったからだ。それでなくても同業同規模である。機能の維持を双方譲らないことが想定された。これは、通常の社内で完結するシステム開発と比べ、大きなコミュニケーションリスクとなる。

■ステップ2：体制、運営・ルールの検討・実施

　そこで、筆者は一番優秀な部下D君をあえてPMにアサインせず、交渉担当に任命した。B社との交渉をすべてこのD君に集中し、直接管理することにしたのである。このプロジェクトは開発作業そのものよりも要件定義やコスト負担交渉の方がリスクが高い。多くのリーダに権限を委譲するよりは、一人の人間に交渉権限（決定権限）を下ろしたほうがよいと考えたからだ。当然、この内容はシステム協同化契約書に明記し、筆者とD君以外が発言した内容以外は、決定事項と見なさないことをB社と取り決めた。

　この内容は、プロジェクトメンバー全員に事前徹底し、B社に不適切な話をしないよう徹底した。

　会議にはSEやリーダとともにD君を必ず参加させ、問題発言はその場で訂正させるように動機つけた。当然、議事録はD君が書く。筆者はこれをチェックすれば管理ができる仕組みである。このプロジェクトは本当にうまくいった。最初は今までと異なる役割に戸惑っていたD君だったが、次第に自分の新しい役割を理解し、筆者に相談しなくても、問題になりそうな発言を潰したり、訂正したりできるようになった。体制・運営面の取り組みが重要であることがお分かりいただけたと思う。次回は教育について説明する。応酬話法とは何か、交渉の基本は何かについて説明していくことにしたい。

■芦屋広太（Asiya　Kouta）氏プロフィール

OFFICE　ARON　PLANNING代表。IT教育コンサルタント。SE、PM、システムアナリストとしてシステム開発を経験。優秀IT人材の思考・行動プロセスを心理学から説明した「ヒューマンスキル教育」をモデル化。日経コンピュータや書籍への発表、学生・社会人向けの講座・研修に活用している。著書に「SEのためのヒューマンスキル入門」（日経BP社）、「Dr芦屋のSE診断クリニック(翔泳社)」など。

サイト： http://www.a-ron.net
連絡先： clinic@a-ron.net