札幌市が取り組んできた発注者主導での基幹システム再構築では、プロジェクト管理を受注者に任せきりにすることなく、発注者自身もしっかりとプロジェクト管理を行います。

この発注者のプロジェクト管理ですが、いくつものプロジェクトの経験を通じて「船長として大きな船を操るようなものだ・・・」というイメージを持つようになりました。

皆さんも遊覧船や連絡船に乗ったときに、大きな船がじわじわと方向を変えるのを見たことや経験したことがあると思います。
大きな船は、視野が狭いため、危険が迫ってもそのことに気づきにくく、また、危険に気づいて舵を切っても方向が変わるまでにとても時間がかかります。
これは、システム開発を委託して発注者側がプロジェクト管理をするときのプロジェクトが反応する感覚に似ています。

この大きな船を操るような感覚は、システム開発を委託することにより、プロジェクトの構造が「入れ子」になることに起因します。

かつての汎用機中心の頃のように、単一ベンダーに任せている時は、お互いを理解していることによる「あうんの呼吸」があり、問題が起きにくいものとなっていました。

しかし、近年のように、さまざまなベンダーが参加するマルチベンダーでのプロジェクトでは、入れ子よって生じるプロジェクト管理の難しさが強く現れるようになります。

さらに、プロジェクトの規模が大きなものであったり、そのプロジェクトが複数並行して走るものだったりすると、その難易度はさらに高いものとなります。

私たちはこれまでの経験から、委託したシステム開発のプロジェクトを発注者がうまくコントロールするためには、一般的に言う「プロジェクト管理」とは少し違った視点やコツがあると考えています。

ここで紹介する視点やコツは、第1回で紹介したAIST包括FWを用いてプロセスや成果物を標準化する「グラスボックス」の手法を採用していなくても有用なものですが、併用することでさらに効率的でコントロールがしやすいものとなります。

今回は、まずシステム開発を委託する場合の発注者側のプロジェクト管理の特徴をお話しします。
そして、それをうまく進めるためのコツとして「進め方を合わせる」こと、そしてそのポイントについて具体例を挙げて説明していきます。

最後に、その中でも特に難易度の高い、プロジェクト規模が大きな場合や複数プロジェクトが並列する場合のポイントについて紹介していきます。

1.「入れ子構造」プロジェクト管理は発想の転換が必要

「プロジェクト管理者が管理するプロジェクトを管理する。」禅問答みたいな話ですが、ここに発注者が行うプロジェクト管理の難しさの本質があります。

システム開発を委託する場合、発注者とベンダーは同じプロジェクトを管理していますが、発注者からみると、一旦ベンダーのプロジェクト管理者を介する、いわゆる「入れ子」の構造になります。

そのため、発注者プロジェクト管理は、作業者と直接やりとりすることの無い間接的な管理になります（図１）。

これは、自治体のシステム開発の委託契約が請負形態を採ることにより、業務の完成責任をベンダーが負うこと、そのため発注者はベンダーに指揮命令することができないという、「委託のメリットの裏返し」によって起こります。

そして、このような入れ子のプロジェクトの管理には、以下のような2つの特徴がみられます。

(1)問題に気づくのが遅れがち

一部の作業にトラブルが発生しているなど、プロジェクトに問題が生じているときに、そのことに気づきにくくなります。

発注者側はプロジェクトの状況変化を間接的にしか捉えられないために、タイミングが遅れてしまうのです。定例の状況報告や成果物の検収のタイミングではじめて気がついたということが起こります。

発注者側が状況を把握したときには、既に事態が大きく悪化していて、対応が後手になってしまうこともあります。

(2)　問題への対応が遅れがち

問題があることがわかっても、それを解決するための具体的な対応策の検討がしにくく、対応に着手するのも遅れがちになります。

これは、発注者側からベンダーの各担当者が成果物を作るまでにどのような作業をしているか見えにくいため、どこに手を打てばよいか、効果的な対応策を考えることができないことに起因します。

ベンダーに対応を依頼しようとしても、「ちゃんとやって欲しい」としか言うことができません。
かといって、問題が起きてから状況を把握し、そこから対応を依頼していては時間がかかり、事態をさらに悪化させてしまうことにもなります。

　では、これら2つの特徴に手を打つことで、入れ子のプロジェクトをうまく管理することができるようになるのでしょうか。

考えられる対策としては、事態を把握までの時間を極力短くし、かつ、対応の指示に対する応答までの時間も短くするといった方法があります。
しかし、プロジェクトが入れ子構造である限り、この方法には限界があります。

札幌市のシステム再構築プロジェクトでは、この問題に対してプロジェクトが始まってから状況変化の把握や対応を行うのではなく、それらが最小限で済むよう、プロジェクトで起きる状況変化や対応を予測してからプロジェクトを始めることにしました。

大げさに言えば、計画に従って進めてそこからの差を検出するという従来の発想から、当然起こるであろう変化を想定して、そこへの打ち手も予め考えてから進めるという発想の転換、パラダイムシフトを行ったのです。

これまで、複数の開発プロジェクトが進められてきましたが、それらの立ち上げ時には、プロジェクトで起きる状況変化や対応を予測する活動を行います。

この予測は「進め方」と呼んでいます。プロジェクト計画を策定するタイミングで「進め方」を関係者全員で考え、それをプロジェクト計画書に落とし込んで共有できるようにしています。

そのようなプロジェクト運営を行うことで、入れ子構造のプロジェクトにおいても発注者主導のプロジェクト管理を実現することができています。

　次章以降では、この「進め方」について、その重要性や内容についてお伝えしてきます。