PR

 プロジェクトでは、要件定義から基本設計フェーズまでを自社で担当し、詳細設計や実装といったフェーズの作業を協力会社に任せることは多い。詳細設計や実装の作業は基本的に、任された協力会社が主体となって進めることになる。協力会社のメンバーが自社のメンバーと同じオフィスで作業を進める場合でも、基本的にそれは変わらない。

 ときには、協力会社の担当者の間で意見が食い違い、現場に小さな緊張感が走ることがある。このとき、ついそのままにしてしまうPM(プロジェクトマネジャー)は少なくないのではないだろうか。

 自社のメンバー同士で意見が食い違って、小さな緊張感が走った状況であれば、割って入って調整するだろう。しかし、小さな緊張感が協力会社の担当者同士の間に生まれたものだと、「緊張感の解消は、協力会社の主担当者の仕事。自分がそこまで踏み込んでいたら面倒だ」と思いがちになる。プロジェクト全体の進捗や課題対応の状況など、PM自身がこなすべき仕事もあって忙しいので、なおさらそう思いがちになる。

 しかし、協力会社の中であっても小さな緊張感は、放置してはいけない。放置したためにプロジェクト全体に影響が及ぶことがあるからだ。

初めてのPMでUIの改修を任されたKさん

 KさんはSIベンダーの中堅エンジニアである。入社後、プログラマからSEへとキャリアを積み重ね、ついにPMを任された。Kさんが初めて担当することになったのは、ユーザーインタフェース(UI)の改修を含む、システム更新プロジェクトだった。それまでのシステムの画面は、Visual Basicで開発されたクライアントソフトで表示していた。新システムでは、利用部門からの強い要望があり、Java言語を使ってWeb化する。

 Kさんはプログラマ時代、Javaの専門部隊で働いていたこともあり、「初めて担当するプロジェクトだが、自分の得意分野だ」と思い少し安心していた。一方で要件定義や基本設計フェーズで、ステークホルダーとの仕様調整が難航したり、仕様追加が多発したりするのではないかという、不安もあった。

 実際、プロジェクトが始まってみると、要件定義・基本設計フェーズは順調に進んだ。基本設計フェーズも終わりに差し掛かったので、詳細設計フェーズ以降のために、Kさんはいよいよプログラマ部隊を投入する準備に取り掛かった。

 プログラマ部隊はUIの改修をサブシステム単位で行うため、複数チームで編成することにした。各チームのリーダーとメンバーはいずれも同じ協力会社の社員で構成する。

 ただし、改修に当たっては技術検証をした上で実装方式を決める必要がある。そこで、Kさんはプログラマ部隊のうち1チームを先行投入することにした。このチームは、Kさんがプログラマ時代に大変お世話になったA社に依頼することにした。

 A社もまたKさんに配慮して、Kさんと一緒に仕事をしていたプログラミング歴20年のベテラン社員Mさんを主担当者にした。「Mさんとは長年仕事を一緒にやってきて気心も知れている。しかも別会社の自分を、一人前のプログラマとして育ててくれた人。その人がリーダーを担当してくれる」。A社の決定に、Kさんは非常に心強く感じていた。