本園 明史
ウルシステムズ シニアコンサルタント

 

 プロジェクトの現場で発生している「すれ違い」の芽を摘み取るのは、プロマネだけでは難しい。本連載では「マネジメントサポート」と「コーディネータネットワーク」という新たな2つの役割を提案する。今回は実プロジェクトの例を挙げつつ、現場に入り込むその姿と仕事内容を解説していく。(ITpro)


 前回はプロジェクトが抱える根本的な問題として、「プロセスをうまく回せない」という問題と、「プロセスでは扱いきれない人間系の問題を挙げました。そしてそれぞれの問題の解決策として、マネジメントサポートとコーディネータという新しい2つの役割をプロジェクトに導入することを提案しました。

 これら2つの役割は現場でどのように動き、プロジェクトにどのようなメリットをもたらすのでしょうか。今回は筆者が経験した実例をベースに解説します。

マネジメントサポートが必要な現場

 システム開発のプロジェクトでは、ユーザー側とベンダー側それぞれにチームを編成し、役割分担を明確にした上で進めていくのが一般的です。もう少し細かくその編成内容を挙げると、プロジェクトの総責任者はユーザー側のプロジェクト・マネジャです。その配下には事業ごと、あるいはサブシステムごとにIT部門と業務部門(ユーザー部門)の代表者によるチームが編成されます。ベンダー側にもユーザー側と対になるようなチームを編成します。同じようにプロジェクト・マネジャがいて、事業あるいはサブシステムごとにチームを構成します。

 前回も触れたように、プロジェクトは通例、方法論で定義されているプロセスやルールにしたがって作業を進めます。例えば、総責任者であるユーザー側のプロジェクト・マネジャが必要とする情報――プロジェクトの進捗や見えてきた問題点など――は、ルールに則って、まずベンダー側のプロジェクト・マネジャが集約します。進捗状況、品質状況、懸念事項、その他非公式な情報などが、チームごとにチームリーダーによってまとめられ、ベンダ側のマネジャに報告されます。一般的にこれらの情報はベンダ側で整理され、定例報告という形でユーザー側に届くことになります。

 ところが往々にして見られるのが、結果として信頼性の低い報告がなされ、混乱を招く状況です。通常、プロジェクトでは報告内容の信頼性を担保するために、記述方法や報告ルートはプロジェクトのコミュニケーション・ルールとして詳細に規定しておきます。一方で規定しきれない個別・具体的な詳細については、多少経験のあるマネジャであれば、指針や考え方を口頭や具体例を使ってメンバーに指し示します。これによってコミュニケーションの品質を保とうとします。

 しかし、無駄骨に終わるケースがあまりにも多いのが現実です。プロセスを着実に遂行していたつもりでも、忙しくなるにつれてプロセスの遵守は曖昧になりがちです。結局、「いつものプロジェクト」と変わらない状況に陥ってしまいます。

マネジャがマネージできない「負のループ」

 マネジメントサポートの現場を説明するにあたって、私が最近コンサルティングを受け持った、ある大規模自治体のシステム開発プロジェクトの例をご紹介しましょう。

 このユーザーは過去、大規模システム開発プロジェクトをいくつもこなしてきていますが、どのプロジェクトにも同じような失敗パターンが見られることが悩みの種でした。

 その失敗パターンとは、報告の品質に起因するものです。プロジェクトの最初のうちは開発を担当していたベンダー側から毎週「順調」という報告が挙がってきます。ところがプロジェクトの半ばを過ぎるようになると、遅延が目立つようになってきます。そしてスケジュール末期になると予期せぬ大幅な遅延が突然発覚します。やがてベンダー側からは(あからさまではないにしても)機能の削減や追加開発の必要性が聞こえてくるようになります。最終的には、ベンダーに言われるままの機能削減、追加開発プロジェクトの立ち上げ、予算の要求を受け容れざるを得ない形で、問題を収束させていたのです。

 実際、私がコンサルティングで入った段階で推進中のプロジェクトでも、その失敗パターンが再現されようとしていました。このユーザーがプロジェクトのパートナーとして契約していたのは、ある大手ベンダーでした。「美しい」マネジメント・プロセスを掲げ、それを適用していました。

 しかし現場を見ると、その美しさが表現されているとは言い難い状況でした。各種の管理基準は規定されているのですが、現場への適用の仕方はあいまいでした。そのため、同じ作業であっても、その作業内容を報告するメンバーが異なれば、報告される内容も粒度もまったく違ってしまっていました。つまり、何を報告すべきかの報告基準は担当者やリーダーによってバラバラだったわけです。これではルールや基準を立てた意味がありません。

 プロジェクトのリスクを減らすためには、現場で見つかった未確認情報がきちんと要確認項目としてマネジャに報告として挙げられるようにすることが大切です。ですがこのような状態では望むべくもありません。担当者の主観的な判断でいかようにも情報の中身が変わってしまいます。忙しい現場であればなおさら、挙がってくる情報は不正確になりがちです。

 今回のプロジェクトでも、そうした状況があちこちに見え始めていました。ユーザーの現場からは「ベンダーが悪い」という声、そしてベンダーの現場からは「ユーザーが悪い」という声が挙がっていました。互いが責任回避に終始した報告ばかりを応酬し、モラルが下がる一方でした。

 言わずもがなのことですが、プロセスやルールが存在していても、きちんと遵守されなければ意味がありません。この自治体のプロジェクトでは、その言葉通りの状況が繰り広げられていました。

 このプロジェクトだけに限った話ではありませんが、ユーザー側から報告される内容とベンダー側から報告される内容は、一致しないのが“悲しい現実”です。つまり、どの情報がプロジェクトの正しい姿を反映しているのかはわかりにくく、だからこそ優秀なプロジェクト・マネジャは現場に足を運ぶわけです。

 ですが多くのマネジャ、そしてこの自治体プロジェクトのマネジャも、忙しさの中、手元にある情報だけで問題の対処に当たらざるを得なくなっていました。手元にある情報は不正確ゆえ、打つ対処はいずれも的外れなものに――。プロジェクトはこんな「負のループ」に陥っていました。「突然の2週間遅延」、「90パーセントから動かない進捗」、「完了したはずのタスクが復活」といった問題が次々と発生し、それへの対応に追われる日々が続いてました(図1)。

図1●負のループに陥る中、プロジェクト・マネジャに報告される情報は不正確になりがち
図1●負のループに陥る中、プロジェクト・マネジャに報告される情報は不正確になりがち