日本通運はなぜアクセンチュアを訴えたのか？　IT部門が「124億円の訴訟」から学ぶべきこと：日本独特の商習慣が招いた「124億円の訴訟」【前編】（1/2 ページ）

　SIer側でプロジェクトを統括するのがPMだ。「PM」と一言で言っても、対象となるプロジェクトの規模によって求められるスキルは異なる。プロジェクトの工程や体制も大きく異なる。

　プロジェクトの規模別にPMに求められるスキルを整理すると、以下のようになる。

１、中小規模プロジェクト

　一般的なプロジェクト。約2〜3億円までの規模で、最大で約20人体制。サブシステム単位で構築されることが多い。PMは、要件定義からテストを自ら実施して内容を把握し、チームを率いる。著者の著書『PMの哲学』（日経BP）で扱っているのがこの規模のプロジェクトだ。

2、大規模プロジェクト

　中小規模プロジェクトよりも一桁大きい20〜30億円規模で、最大で100人超体制となる。著者の著書『失敗しないITマネジャーが語る　プロフェッショナルPMの神髄』（日経BP）で扱っているのがこの規模のプロジェクトだ。大規模プロジェクトは、PMをチームリーダーとする複数チームから構成される。各チームリーダーには、中小規模プロジェクトを統括するスキルが求められる。5〜10以上のサブシステムから構成される、ユーザー企業の部門全体で利用するITシステムが対象となる。この規模のITシステムを筆者は「機能システム」と定義している。

　大規模プロジェクトでは、サブシステム間で共通のデータベース制御、あるいは障害対応なども含めたITシステムの運用の共通化など、ITシステムを動かすために必要な機能の設計・開発が必要となる。端末応答を3秒以内に、データを1日当たり100万件処理するといった「非機能要件」を整理して、実現可能な設計をし、開発することも必要となる。そのために方式設計（注2）とシステム基盤開発を実施することも求められる。

　つまり、プロジェクトの規模によって工程も大きく異なるため、プロジェクトの特性を理解して工程を定義する高いスキルがPMに求められる。

　中小規模プロジェクトでは、「IT（連結《結合》テスト）（注3）終了レベル」が納品に相当し、検収を経てリリースとなる。一方、大規模プロジェクトでは、IT終了後に「ST（総合テスト）」（注5）の実施が必須となる。

　STを一定の品質に達したと判断した上で、顧客を中心に「ユーザー受け入れテスト（UAT）」（注4）を実施した時に検収するのが一般的だ。

3、超大規模プロジェクト

　機能システムを複数束ねて開発するプロジェクト。100億円以上、最大で1000人超の体制となる。プロジェクトマネジメントの難易度は大規模プロジェクトよりもさらに増し、「P2M（プロジェクト＆プログラムマネージメント）」（注6）と呼ばれる。

　超大規模プロジェクトを一括してリリースするのは難しいため、機能システム単位で順次リリースすることになる。このため、新旧の機能システムを併存させながら徐々に移行するシナリオの策定が必要になる。さらに、機能システム間の整合性確認のため、STの次に機能システム間テストを実施する。システムが部門間をまたがるため、部門間で調整した上で全社レベルのルールを制定する。各部門を調整する権限が必要となるため、CEOの参加が必須となる。ほとんどの企業では実質的な責任者となるCIO（最高情報責任者）の権限と立場を抜本的に見直す必要がある。

　このように、規模が拡大するごとに難易度も格段に上がっていく。筆者は、1〜3の全ての規模のプロジェクトにおけるPMを経験した。PMの第一歩は規模の違いを意識することだ。

　大手SIer各社には大規模プロジェクトを担当できるレベルのPMが20〜40人在籍している。超大規模プロジェクトを担当できるPMは、業界全体でも10人程度だと筆者はみている。

プロジェクトの難易度を上げる「現行機能保証」とは？

　ここまでプロジェクトの規模を中心に見てきた。規模が大きくなるほど難易度も挙がることがお分かりいただけたと思う。もう一つ、プロジェクトの難易度を格段に上げる要素となるのが「現行機能保証」だ。

　現行機能保証とは、新しいシステムを導入する際や、既存システムの一部を変更、あるいはアップグレードする際に、既存の機能がそれらの変更の影響を受けずに正常に動作することを保証するものだ。

　この説明からはそれほど難しい印象を受けないかもしれない。しかし、多くのユーザー企業は自社の業務内容を正確に把握しておらず、業務要件を定義できないために、現行機能を保証する難易度は高い。

　システム化とは業務の一部を自動化することであると同時に、業務をITシステムに「隠ぺい」することでもある。エンドユーザーは、入力と出力の操作が分かっていればシステムを利用できる。システムが何をどのように処理しているかを知らなくても使えるのだ。

　システム化の範囲が広がるにつれて、業務はシステムに順次隠ぺいされていく。つまり、ユーザー企業の従業員は自社で実施している業務を「知らない」状況が生まれる。

　こうしてITシステムの開発をSIerに丸投げすることによって、ユーザー企業は自社の業務内容を把握できなくなった。一方で、ITシステム開発を担うSIerは、ユーザー企業の複数部門の従業員と調整しながら業務要件を取りまとめた結果、ユーザー企業の従業員よりも業務に詳しくなっていく。

　特に、業務要件の重要情報である業務フローは、本来はユーザー企業が維持、管理すべきだが、放置されがちだ。システム構築後、時間の経過とともに業務フローは変更されることがある。その場合も、必要最低限の修正ドキュメントが断片的に残されるだけというケースは多い。何重にも上書きされた修正ドキュメントから現在の業務要件は読み取れず、業務要件が不明になりがちだ。

　筆者の経験から言うと、現行機能について正確に理解しているユーザー企業はほぼ存在しない。現在の業務要件が整理されていない中で、SIerが要件を再定義する難易度は極めて高い。プログラムを分析すると、「何をしているか」の情報は見付けられるが、「何のために動いているのか」に関する情報はない。プログラムは機能を実現するための手段であり、何のためにプログラムが書かれたのかという目的はインプットされていないからだ。つまり、プログラムの分析によって判明する業務仕様は一部にすぎない。

　実際に筆者が前職で経験した、問題のあるプロジェクトの8割は、ユーザー企業から「現行機能保証」を求められたケースだった。現行機能保証はSIer共通の課題で、トラブルの主要な原因になっている。プロジェクトの規模が大きくなればなるほど、難易度はうなぎのぼりになる。