プロジェクトをしっかり立ち上げられるPMが足りない

　本連載では、ユーザー企業のシステム部門かそれに準ずる立場のプロジェクトマネージャー（PM）に求められる、プロジェクト立ち上げの勘所を7つ、事例を交えながら紹介する。このような勘所が重要な理由は単純で、プロジェクトの失敗が多いからだ。失敗の要因は複合的で多様であるが、代表的なものを見てみよう。


　要件定義の後半になると、画面や帳票の設計が具体化する。するとそれまであいまいな要望しか言わなかったエンドユーザーが、やたらと具体的な要件を次々と言い始める。実はエンドユーザーにはそれまで具体的なイメージを伝えてこず、あいまいな理解のまま放置してきたのだ。

　さらにシステムテストに入ると再び要件が膨らむ。システムを触って初めてイメージが明らかになり、こんなはずではないと言い始めるのだ。ひどいプロジェクトになると、業務改革の骨格すら説明せずに、業務オペレーションのベテランを集めて「とにかくいろいろ使って不具合がないか確認して」とやるので、現行システム通りに動かないところがすべて不具合として改善を要望される。それが操作レベルの過剰サービスを削減する目的であってもだ。

　このように提示されたすべての要件を集めると当然予算超過となり、要件の取捨選択には苦労する。予算超過だけならまだしも、根本的な他部門との合意事項やアーキテクチャを覆す必要のあるものすらある。こうなると事態の収拾は簡単ではない。


　「現行通りにして」はエンドユーザーの常套句である。これを仕方ないと思って受け入れてしまうと、何が正しいのか決め手がなくなってしまう。「現行通りにして」を使う典型的な利用部門は、決算などブラックボックス化した業務の多い経理や、同じ業務であるが人や拠点、チームによって微妙にやり方が違う営業や開発部門である。「現行通りにして」は、要件を決める役割を担ったエンドユーザーが、他者のやり方を含めて業務の全貌を知らない場合に使う責任を放棄するための言葉なのだ。

　一般的に母体のパッケージが変わったり、部門間の関係が変わったりするのは当り前なので、実は現行通りにはできない。「現行通りにして」を受け入れてしまうと、設計ではいつまでも仕様を決められない、テストで不具合が収束しない、現行システムで動いていたデータが新システムでエラーとなり、テストが進まない、などの状況はすべてプロジェクト側の責任となる。


　決めたつもりでも同じことを何度も言い始めるエンドユーザーがいる。プロジェクトが仕様の決定を求める圧力の前で、納得していないことや理解が不十分な決定に一旦うなずいても、現場に戻ると当然リードできないので蒸し返しとなる。

　このような板挟みに苦しむだけの人がアサインされることは多い。主だった利用部門長に、プロジェクトが取り組む業務改革の意義が正しく伝わっていないので、いい加減なアサインをされたり、アサインされた人に役割が説明されていなかったりするからだ。根本はアサイン誤りなのに、議事録を示して主張しても納得はさせられない。だから堂々巡りに陥る。

　このような失敗の芽は多様にある。失敗の芽はプロジェクト開始前に摘んでおかなければならない。「段取り八分、仕上げは二分」とはよく言ったもので、立ち上げに失敗したら致命傷である。それなのにプロジェクト開始前こそ真剣勝負であると本当に認識して行動するPMは少ない。すなわちプロジェクトをしっかり立ち上げられるPMが足りないのだ。

プロジェクト開始前にやるべきこと

　では、プロジェクト開始前にやるべきこととは何か。

　この工程は、システム化構想、システム化企画、システム化計画、マスタープランニングなどいろいろな呼び方をされている。しかし悲しむべきことに、工程名のバリエーション以上に、やるべきことの認識はもっとバラついている。工程名については本連載では“システム化計画”に統一する。冒頭に述べた我々が確立したシステム化計画の方法論では、システム化計画の目的を次のように定義している。


　システム化計画の目的は、システム化を通じて達成すべき業務改革とこれを支援するために作り上げるITの姿、今後の推進方法を明確化し、関係部門の合意を得て、業務改革と情報システム開発開始の承認を獲得することである。

　システム化計画の達成水準は、システム化計画承認後のプロジェクトが計画通りに遂行できること、また、開発した情報システムで、計画通りの業務改革を達成し、リターンが得られること、つまり後続するプロジェクトで、業務改革とそれを支援するITの開発が成功する条件がそろっていることである。

【次ページ】 システム化計画の残念な実態