混成プロジェクトの課題と対策

　少し大きなシステム構築のITプロジェクト、つまり数十人以上のITプロジェクトは顧客、元請け企業、その下請け企業など、複数の企業の社員から構成される混成プロジェクトとなるケースが殆どです。このようなITプロジェクトでは元請け企業の管理力不足が露呈することがよく見受けられます。
　納期が守れなかった、費用がかかり過ぎた、品質が悪い、拡張性がない、性能不足などとなるケースは、失敗と言わざるを得ません。厳しいと言われるかもしれませんが、これらのいずれか１つでも顧客の満足が得られなければ“失敗”です。

　混成プロジェクトでは元請け企業の力量が問われます。生半可なプロジェクト管理はできません。プロジェクトの規模が大きくなるほど徹底した管理を行わなければなりません。混成プロジェクトを成功させる最低の条件として、プロジェクトメンバが共通のコミュニケーション基盤（技術知識および管理知識）の上で仕事をする必要があります。構成メンバが異なる企業文化を持ち込んでくるとちょっとしたコミュニケーションさえうまく行かなくなります。

　構成メンバが技術文書（要求仕様、機能仕様、構造仕様、詳細仕様、コード化標準、レビュー方式、テスト基準、品質評価基準、各種帳票、設計用語、etc.）やその作成手順、会議の種類・進め方などの知識を共有していなければ、コミュニケーションは躓きます。元請け企業は、こうしたコミュニケーション基盤を文書化し（これを「作業標準」と呼びます）、混成プロジェクトの構成メンバが作業標準に従うことを義務づけなければなりません。

　上記のような作業標準を持たず、保有していても混成プロジェクトで徹底されていないケースでどんなことが起きるのか、私の経験で述べましょう。

１）

　中規模の販売管理システム開発で、フレームワーク（Easy-Order型の開発ツール）を使用することになっていました。予め決めた作業標準ではビジネスロジック（モジュール）の開発は１人で行うことにしていました。一方このツールの使用経験がない下請企業が多かったため、使用経験を持つ下請け企業を採用することになりました。どうしたことかこの企業は１つのモジュールを詳細設計、コード化、単体テストの３工程に分け、３人の担当者にやらせていたのです。彼らはそのやり方が生産性が高いと信じていました。分業生産をイメージしたのだろうと思います。モジュールの開発に分業生産は適していません。案の定トラブルが続出しました。元請け企業が下請け企業に遠慮し、作業標準の順守を指導しなかったのです。障害が発見される度に、この企業ではビジネスロジック担当者の雁首を３つ並べて登場させることを延々とやることになりました。障害を起こし易く、解決も長引くやり方をしていたのです。

２）

　結構大きなプロジェクトでの経験ですが、元請け企業の幹部がどうもプロジェクトが怪しいので見てほしいと言います。プロジェクトの要員数約１５０人、元請け企業の担当者は課長以下１０人、下請け企業は５、６社で大きいところは約５０人。元請け企業はシステムを複数のサブシステムに分け、サブシステム毎に下請け企業に発注し、後の管理はすべて下請け企業に任せていました。ここまでは特に悪いことではありません。ところが、各社が提出してきた進捗状況報告は作業項目と出来高をパーセンテージで書いたものだけでした。基本的には、元請け企業は下請け企業の管理者の報告を信じる以外にないのです。XXサブシステム：現在詳細設計中・８０％完了というものです。何をもって８０％なのかという裏付けデータがないのです。詳細設計対象モジュールが何個あり、担当者は誰で、各モジュールの詳細仕様書の予定ページ数が何ページで現在何ページできたから、全体の８０％完了しているという報告になっていなければなりません。更には、今後の見通しや解決すべき問題点が報告されなければなりません。こんな具合でしたから、このプロジェクトは一体どうなるのやらさっぱり分らない状況に陥っていたのです。

　元請け企業と下請け企業のそれぞれに管理者がいます。管理の力量が下請け企業の方が上回っている場合もあります。それでも、元請け企業はまとめ役を担わなければなりません。彼らの仕事は、戦略立案と状況把握、判断・指示です。これを行うには、組織（企業）の壁を取り払う必要があります。プロジェクト推進チームを作り、このチームには下請け企業の管理者もエントリします。プロジェクト推進チームの役割については「ITプロジェクト戦略」を参照してください。

　プロジェクト推進チームは、当該プロジェクトで必要な作業標準を決めます。また、作業フェーズに合わせて、実行チームを編成します。各チームの状況適宜報告させます。他にも推進チームの役割は沢山あります。

　混成プロジェクトだからこそ、プロジェクト推進チームは大変重要な役割を持ってきます。元請け企業は、下請け企業に決して丸投げしてはいけません。

　上記の、私が経験した失敗プロジェクトにおいても、プロジェクト推進チームを立ち上げ、プロジェクトメンバ全員が組織的に活動することによって、当り前のITプロジェクトとして立ち直ることができたのです。

■