PR

 城野は、スマホの画面に目をやった。定時を15分ほど過ぎたところだ。城野は、力なく言葉を返した。

「まあいいわ。明日朝一番に確認して、見通しは立てておいて。で、大木さんのほうは?会計領域は追加要望が多くて、何とかスコープを調整しないと動きが取れないでしょう?」

 大木は、大きくうなずいた。

「いつどこで調整するつもりなの?とりあえず次回のステコミ議題に上げる?」

 大木は、急に煮え切らなくなった。

「上げてもいいですけど、無駄かもしれないですね。横井さんは自分で何も決めようとしない方で、黒田部長が何かおっしゃると、事がすぐひっくり返るんです」

「黒田部長は、ステコミにも出ておられないの?」

「出てこられません。忙しいし、システム開発は部下に任せてるからって」

 城野はまた、顔をしかめた。

「でも、しっかりクレームはつけてこられると。確か、ステコミにプロジェクトオーナーがおられたはずよね」

 大木はうなずいた。

「滑川常務ですね。確かにステコミに出席されていますけど、ただ黙って報告を聞いているだけですよ。今年度から着任されたばかりですから、業務のことはあまり分かっておられません」

 城野は、ため息をつくしかなかった。いつまでもスケジュールやスコープが確定しないのも道理だ。いったい誰が、このプロジェクトを前に進める役割を担っているというのだろう?

トラブルの要因

 いわゆるルーティン業務とは異なり、プロジェクトチームはプロジェクト立ち上げの都度編成されます。従って、各メンバーが担うべき役割も様々で、個々人にとって、必ずしもそれまでに経験したことのある役割が割り当てられるとは限りません。

 にもかかわらず、体制図は作っても役割定義を明文化しないなど、役割分担をないがしろにするプロジェクトは案外多いものです。

 とりあえず関係者を体制図に組み込み、「何とかリーダー」「かんとか責任者」といったラベルだけ貼りつけて事足れりとするわけです。当然ながら、これではうまくいきません。果たすべき役割はプロジェクトによって異なりますし、その役割には、メンバーにとって未経験、未知の領域も含まれるからです。

 それぞれの関係者に自分の役割を飲み込んでもらい、役割に沿って機能してもらおうとするなら、ハコを並べただけの体制図では不足なのです。ルーティンワーク以上に役割の定義を明確にして共有しておかないと、プロジェクト炎上の火種が燃え出すものです。