プロジェクトミューズ　バイリンガルプロジェクトは辛いよ　～その7～　船頭多くして船陸に上がる？

プロジェクトミューズには、実はプロジェクトマネージャーが事実上3人いることが判明しました。PMの肩書きを持っている人、顧客要件を機能要件に咀嚼する要件担当アーキテクト、機能要件を設計・実装方法にさらに咀嚼する開発担当アーキテクトの3人です。日本的（常識的？）感覚から行くと、PMがトップにいて最高権限を持っており、アーキテクトがその下で現場を管理するという体制になるはずです。ところがこのプロジェクトミューズではこの3人が横並びのチーム体制を取っていると請負業者の責任者は言うのです。

さてこの3人おもしろい力関係にあります。
要件担当アーキテクトは、実はこの会社の実質上のオーナーで、配偶者を社長兼COOに据え付け自分は技術の現場に専念しています。しかもこの配偶者は昔の部下。
開発担当アーキテクトは、見るからに学者肌。自分の信念を持って設計してくれるのは利点だけれど、頑固、融通が利かない、顧客の言い分を無視して自分の意見を押し通すというビジネスにとってはマイナスの要素有り。
PMは、実質上はアーキテクトやデベロッパーのお世話係。文書作成などの事務的な負担を軽減するのがその主な役割らしいということが、やっと最近私にも見えてきました。ランクとしてはデベロッパーよりも下。一番、権限がない立場です。

PMの役割が我々が想定していたものとまったく異なるため、PMとして機能しておらず、更迭になることは先日解説した通りですが、昨日、また1件問題が発生してしまいました。

2名のアーキテクトの間で認識の相違があるのです。

要件担当アーキテクトが開発要件として認識していた内容が、開発担当アーキテクトは認識していなかったという事実が発覚したのです。ベータ版で実装済みと要件担当アーキテクトが報告したにも関わらず、開発担当は認識していなかったのでベータ版には実装されておらず、従って追加要件であると言うのです。

両者の意見の食い違いは、発注側の関知するところではない（none of his business)はずですが、追加要件になる・ならないのツケは最終的には発注者に跳ね返ってきます。しかも要件担当と合意した処理にしていた案件が開発担当によって反古にされるということが続出したのではプロジェクトは進みません。

さて、このような場合、どうしたらよいでしょうか。

私が薦める（そして欧米でもよく使われる）アプローチは自分にとって都合の良いところだけを拾い上げ、都合が悪い点は請負業者社内の問題として投げ返すことです。要件担当がスコープ（業務請負範囲）だと言っているにも関わらず開発担当が異論を述べている点についてはスコープとみなし実装されていない事実をクレームする、一方で要件担当が意識していなくても開発担当が既に実装されているといえばそれを断る理由はなにも無いわけです。（要件担当がスコープに入れていなければ開発担当が実装することはまずありえないのですが。）

対価を払わなければならない立場の発注者としては、しかも顧客要件を請負にちゃんと伝えてきたという確信がある場合には、実装漏れに対しては断固としてクレームを主張しなければいけません。それは実装漏れは請負業者内部のプロジェクト管理のミスだからです。

それはさておいて、このアーキテクト間の意識のズレ、コミュニケーションギャップはどのように対処すればよいでしょうか？あくまても請負業者内部の問題なので、「内政干渉」にならないようにする配慮が必要です。その上でPM間で意識合わせができていないことによる弊害を具体的に指摘しなければなりません。そしてこの問題は、彼らの上の立場にある人物（この請負業者のCOO）にエスカレートしなければならないということです。

もう一つ忘れてはならないのは、エスカレートして何をして欲しいのかを発注側は明確にしておかなければなりません。クレームを出したり、問題をエスカレートさせても、それどうして欲しいのかという合意・受け入れ可能な措置や対策を心の中に準備しておかないと、クレームをつけただけで終わってしまいます。

例えば今回のケースの場合、

（1）要件担当と開発担当のアーキテクト間で発言の優先順位を決めてもらう、

（2）発注者にとって納得のいく解釈を請負側に受け入れさせる。

プロジェクト管理のチーム体制を主張する業者ですから、上下関係をつけるように期待するのは現実的ではないかも知れませんし、開発現場により近い立場にいる開発担当アーキテクトの言い分を支援したい場合もあるでしょう。ですから（2）のオプションを選択したほうがよいのではないかと思います。