第3回 費用、技術のマネージメント
(4) 費用を把握し、コントロールする
PMは、担当範囲のプロジェクトの費用を明確にしなければなりません。成果物を造り出すために必要な社内の体制と作業コスト、他社の製品や成果物、必要な資材や開発環境なども考慮する必要があります。費用見積りでは、ファンクションポイント法などによる実現機能の観点と、スケジュールに絡めたマンパワーの観点の両方から、見積る必要があります。
PMがアサインされる前に、ビジネス上の判断で金額が先に決まっている場合、あるいは概算金額が既に提示されている場合があります。それでもPMは自分の目で見てどのくらいの費用がかかるかを見積り、結果を自社内の関係者（上位マネジメント、営業、あるいはユーザの代表者など）に報告しなければなりません。
プロジェクトが進行するにつれて見積り費用が変わることもあり、PMは費用の増減を把握し、関係者と情報共有しておく必要があります。予算（顧客企業からの支払金額、あるいはスポンサーのプロジェクト予算）とプロジェクトの費用は別のものです。ただし、PMは両方を意識する必要があります。「予算＜見積り費用」の場合には、何とか予算内に収める努力をしなければなりません。それでも予算に収まらない場合には、上位マネジメント、スポンサー、営業などの関係者に説明し、成果物を変更したりやり方を変えたりして協力を得る必要があります。
途中で交代PMとして入ったプロジェクトの場合にも、費用の見積りはしなければなりません。この場合、プロジェクトの進捗状況、問題点を把握し、これまでの費用を洗い出し、これからの費用を見積るには数週間、あるいは数ヶ月を要することもあります。しかしプロジェクトの状況を正確に把握し、関係者に報告し、協力を得るためには必須の作業で、出来る限り早くやらねばなりません。
私もあるトラブルプロジェクトに交代PMとして入ったことがあります。プロジェクトの状況を早く把握するために顧客やチームリーダ、メンバーと擦り合わせし、進捗状況把握、問題点把握、問題点の回避方法の立案とネゴ、体制とスケジュールの建て直しを実施し、約３億円の予算超過とその理由を上位マネージャに報告するまでに１ヶ月半を要しました。実際には３億３千万円の予算超過になってしまいましたが、もし３億円の費用超過を報告しておかなかったら、プロジェクトの赤字の責任は私一人だけが被ることになっていたでしょう。
一方、費用だけを制限すればプロジェクトがうまく行く、とは限りません。以前、予算を超過しないことだけが重要視され、期限内に成果物ができるかどうかが二の次になってしまったプロジェクトに出会ったことがありました。メンバー（一部は業務知識豊富）は本当に毎日懸命にやっているのですが、資源、技術スキル、マンパワーが足りず、顧客からの仕様提示、変更要求提示についても受ける一方で調整しなかったために、期限をまるで守れなかったというものでした。さらに開発環境が貧弱で、コンパイルやテストの待ち時間がひどく、士気低下も引き起こしました。このようにして、上位マネジメント、PMと各サブリーダ、メンバーの間に見えない溝ができてしまいました。
結局、損害賠償までは免れたものの、関係各社に多大の迷惑を掛け、かなりの工数が持ち出しとなりました。「(7) プロジェクト進捗の阻害要因を排除する」にも記載しましたが、費用を考えるあまりに資源不足、スキル不足、環境不足では、プロジェクトメンバーの活動を妨げてしまい、逆に費用がかかってしまいます。PMは勿論のこと、上位マネージャやユーザも、プロジェクトチームのこのような状況を見逃してはなりません。見逃せば、後で必ず、取り返しのつかない遅延、士気の低下、混乱を招きます。
(5) 技術的なことをマネージする
プロジェクトチーム内に優秀なリーダやメンバーが居れば、PMが技術的なことを一切把握しなくともプロジェクトはうまく行くかもしれません。しかし、最近はそれほど甘くありません。優秀なスタッフが簡単に集められるわけではないし、技術は日々進歩しており、経験者が身近にいないソフトウェアパッケージやハードウェアを使用することも十分ありえます。
技術標準を策定し、アプリケーションアーキテクチャを定義し、品質を管理する
開発者によってバラツキが出て問題となるような事には、標準化、ガイドラインといったようなものを定義する必要があります。例えば、JAVAやCのコーディング規約、クラスライブラリのガイドラインを決めたり、共通ライブラリを定義したり、エラー処理方式、ログメッセージ形式を統一することで、アプリケーションプログラムを標準化し、品質のばらつきを無くすこと等があります。
さらにアプリケーションパターン（オンラインリアルタイム系、オンラインディレード系、帳票出力・ファイル抽出系、バッチプログラム系、運用スクリプト系など）ごとに、各アプリケーションがインフラにどう絡むか、すなわち、一つの機能を実現するのに、どのサーバでどんなアプリケーションプログラムやソフトウェアパッケージが連携して動作するかを定義する必要があります。アプリケーションアーキテクチャ定義をメンバー全員が理解すると、各メンバーがお互いのやっていることを明確に理解できるようになります。これは計り知れないメリットを生み出します。各メンバーが、アプリケーションを詳しく知らなくとも、アーキテクチャが同じようなアプリケーションであれば、他人のプログラムのソースレビューをすることも、開発の相談に乗ることもできるようになります。結果としてメンバー間のコミュニケーションに多大な貢献をすることになります。
基盤構成を検討把握する
以前は、ITシステムといえば、大きなホストコンピュータが1〜2台あって、プログラムは必ずホストコンピュータの上で動作し、端末が数十台から数百台くらいあり、プリンタが数台あるといった構成で、ホストコンピュータで動くプログラムを作ることがシステム開発でした。
しかし、現在では、ハードウェアもソフトウェアも急激に進化し複雑化しており、ITシステムを開発するということは、単にアプリケーションを開発することだけではなくなりました。すなわち、ネットワーク、ハードウェア、ソフトウェア、アプリケーションソフトウェア、データベース、Webサーバソフトなど、様々のアーキテクチャの設計、インプリメントをも並行してやらなければなりません。
システム構成も複雑となり、Webサーバが数台で負荷分散装置を導入し、APサーバが数台をクラスタ化し、さらにDBサーバ数台をクラスタ化する、という構成が一般的です。イントラネットやインターネットに接続されることが多く、同時使用ユーザ数が予め特定できないこともあります。ネットワーク構成は複雑で、開発時のネットワークと本番稼動時のネットワークを使い分ける必要もあります。また、多くの種類のOSやソフトウェアパッケージが使用され、一つ一つの製品の特性が分からないと、アーキテクチャ設計はできません。
従って、近年、プロジェクトチーム内に基盤専門のサブチームが必要となってきました。PMは基盤チームリーダとミーティングを持ち、全体のアーキテクチャを把握し、アプリケーションとインフラをどう絡ませるか、問題点やリスクがどこにあるのかなどを、検討、把握しておく必要があります。
IT技術教育を受けてもすぐには実践で使えないことが多い
IT技術教育は非常に盛んですが、かなり断片的で「あれも出来ます。これも出来ます」という機能説明に終わる場合がほとんどです。「あれとこれを同時にやることはできない。そういう場合にはこういうガイドラインに基づいてこう判断すればよいでしょう」なんてことを明確に教えてくれることは、ほとんどありません。
例えば、WEBアプリケーションサーバの講習会などでも、システムを実現する観点から、それぞれの機能のメリット、デメリット（機能の取捨選択のガイドライン）や、構成上のメリット、デメリット、もっと細かくアプリケーション構造の標準、エラー処理の標準、コーディング規約などに言及してくれることはほとんどありません。
IT教育の質は、実施の観点からもっと高められなければなりません。一方で、技術者の地位が相変わらず低いわが国では、技術教育は若い人が受講するものという先入観があり、設計に責任をもつベテランは受講しない場合が多く、実施の観点から機能の取捨選択の判断ができなくなることがよくあります。さらに問題を複雑化しているのは、パッケージベンダは一般的に、できる機能を宣伝し、できないことや問題のあることは言いたがらないことです。
以上のような事情により、IT教育を受講したということが、プロジェクトで使える技術、ノウハウを身に付けているということにはならないことに注意しなければなりません。
ソフトパッケージを甘く見てはいけない
ERP、CRM、SCM、HRMなどの業務パッケージを導入するようなプロジェクトの場合には、当然のことながら、そのソフトウェアパッケージをよく理解する必要があります。スキル、ノウハウが不足であれば、スキル、ノウハウを持っている人材を集めたり他社に発注したりして武装しなければなりません。
このような業務パッケージは、必ず標準のデータモデルと、想定しているビジネスモデル（どのような画面や帳票が標準として提供されていて、それを使って、誰がどう業務を進めて行くのかという業務フロー）を持っています。このデータモデルとビジネスモデルがユーザの企業のデータモデル、ビジネスモデルに合ってなければ、パッケージの方をカスタマイズするか、または、企業のデータモデル、ビジネスモデルを変えるか、のどちらかになります。なかには、標準のデータモデルのER図をなかなか提示してくれないパッケージベンダもあります。ER図が無いということは、ユーザ側で必要な業務上のデータ構造とパッケージのデータモデルが合っているのかが判断できないということ、結局は、そのパッケージを導入していいのか悪いのを判断できないということです。
パッケージベンダは、通常、パッケージが業務に合っているかどうかの判断（Fit＆Gapなどと呼ばれる）を、数ヶ月間の有料のコンサルティングを経て提供し、それ以降のカスタマイズ費用を別に見積ります。ところが一方で、PMがアサインされたときには既にプロジェクトの予算が決まっていて、パッケージを導入することだけが決まっているという曖昧な状態になっていて、結局、顧客企業のデータモデルやビジネスモデルに合わせるために数億掛けてカスタマイズし、それがすべてSI会社の損失になったという話が、以前はよくありました。
このように多くの人たちがソフトパッケージを導入すればすぐに望む成果物が得られると勘違いしていた時代もありましたが、最近は、簡単ではないことが一般的に理解されて来ています。業務をパッケージのモデルに合わせて変更し、パッケージは一切カスタマイズしない、という例もあるようです。ただし、カスタマイズしないとは言っても、初期データの移行、定期的なデータの導入・導出機能などを付加しなければなりません。