PMプロの知恵コーナー
先号　　　次号

ゼネラルなプロ (134) (Nコム)

向後　忠明　[プロフィール]　：12月号
　今月号では多くのプロジェクトで失敗の原因となる仕様変更や問題発生時におけるシステム品質への影響、そしてそれを防止する課題・変更への対応について話をしたいと思います。

　統合マネジメントによるプロジェクト遂行過程において、各フェーズまたは領域で各種のプロジェクト実行上での課題や問題が発生してきます。
　これらはプロジェクト実行前や実行中の各ステージで発生するものであり、その内容により簡単なものからプロジェクトそのものに大きく影響するものがあります。簡単な課題はその都度の処理で処置可能であるが、下記に示される種類の課題や問題はそれなりの厳格な手順を踏んで対応をしていかないとプロジェクトの失敗につながることがあります。

  1. ①自社の原因で発生し、将来課題を含んだ仕様変更によりプロジェクトスケジュールおよびコストに影響を与える問題。
  2. ②顧客要求により、将来課題を含んだ仕様変更によりプロジェクトスケジュールおよびコストに影響を与える問題。

　①の場合は、その影響度により仕様変更の処理または計画の変更と同時に企業としてその是正処置(将来同じことの起きないような分析とその整理)を行い、改善策として登録することが通常の処理方法です。もし大きな影響を及ぼすような事象が生じた場合は、自社の責任としてその課題等を処置する必要があり、この結果のプロジェクトへの影響(スケジュールやコスト)は自社の責任で処理しなければならないことになります。
　特に、自社の営業活動、契約活動そしてその結果でのプロジェクト体制と人材配置などの不適切な対応により生ずる場合は最もプロジェクトリスクの高いフェーズとなります。
　そのため営業活動や契約交渉などの段階からプロマネの参加が必要であり、このフェーズでのリスクを最小にする努力が必要になります。
　上記以外にも、プロジェクト実行中に自らの不手際で発生するミスでの変更が応じることがあります。この場合は自社のコスト又はスケジュールの範囲内で処置できるかを検討し、自社の努力で対応していくことになります。

　②についても同様な影響度分析を行い顧客にその結果を報告し、この場合は追加・変更の処置(チェンジオーダ)を行う必要があります。しかし、②のケースの場合でも営業、契約段階及び計画段階においては①と同じく最も大変なフェーズであり、その不手際の結果は問題の発生ということになる。この結果で最も危惧される問題は契約内容の不備とコストやスケジュールがプロジェクト実行中に表面化し、大きな問題となりプロジェクトの失敗につながることになります。しかし、上流工程における作業がしっかりしていて顧客からの変更や追加に関することが契約書の条文や付帯文書に明確になっていることを証明することができていれば交渉により十分挽回することができます。
　このように変更や問題の発生による変更管理は①自社によるケースと②顧客によるケースがあるが、実際はこのようにきれいに分かれるわけではない。プロマネとしては①のケースでの失敗では自社内において責任論が噴出し、プロマネの寿命を短くすることになります。
　例えば、ある企業では、多国籍による事業運営において組織編成とプロマネの能力不足によるプロジェクト運営の失敗とプロジェクト組織内のメンバー間のコミュニケーションがうまくいかず、その結果大きなスケジュール遅延と予算超過となりました。その企業のトップも苦境に立たされ、結果的にCEO を始め関係役員が首になり、当然関係したプロマネも左遷されました。これは①のケースです。
　このような経験から前月号でのNコムの財務会計システムのプロジェクトは初めから終わりまで、仕様設定と組織と人材の適切な配置とプロジェクト実行手順の確立に多くの時間を費やし完璧なものとし、コミュニケーションクライメートの充実を図りました。
　この結果、プロジェクトは成功裏に終わることができました。

　しかし、問題は②のケースです。
　例えば筆者の経験での失敗事例では顧客要件不確定のプロジェクトで、前回同様なプロジェクトの成功事例の経験から甘い読みがあり、顧客折衝及び契約時点から、設計基本(要件定義)／設計思想(設計方針)の詰めを誤り、一括契約としました。
　しかし、後のシステム仕様設計の過程で思いもよらないオペレーションにかかわる業務側からの要求に応えられず、相手方との交渉も暗礁に乗り上げ多くの時間とコストの消費となり、プロマネ失格の烙印が押され降板することになりました。

　このように初期の契約、組織編成と人材配置の不首尾そして設計基本(要件定義)／設計思想(設計方針)の確認不備がプロジェクト失敗の大きな問題となります。それ以外に、システム仕様や基本仕様の設定がオペレーションサイドとのすり合わせなどが不十分なことが原因で問題が生じることもあります。
　このように、一般的にはプロジェクト発足当初の綿密な処置がプロジェクトの成功につながります。
　一方、プロジェクト進行中にも顧客の考えが初期の設定から変わったり、新たな情報を入手したりした時に最初に決めた仕様から変更することもあります。
　どちらにしても、契約書や関連図書で決められた内容の変更であれば当然交渉によりコストやスケジュールについて話し合いが可能であるが、プロジェクト当初における詰めが甘ければかなりきつい交渉になると思います。

　読者諸氏の変更の対象となるケースは②のケースがほとんどであり、少しでもプロジェクトに影響が発生すると懸念される場合は顧客との交渉により、追加変更処理としてコストやスケジュールの回復に当たることになります。
　この任に当たる人は、対象となるプロジェクトの契約内容、手順、技術内容及び仕事の所掌範囲全般にわたっての多様なプロジェクト経験・知識でもって対処する必要があり、顧客との交渉能力に長けている必要があります。変更管理はプロマネ主導の変更管理委員会などがこの変更・追加にかかわるものとなるが、その所掌や関係者などもプロジェクト遂行手順の中で明確にしておく必要があります。
　しかし、この追加・変更の内容も千差万別であり、プロジェクトの全様をすべて知ることは不可能に近いです。
　よって、追加変更の対象となる項目については、契約の時点でその対象を決めておく必要があります。
　その対象となるものの一例を以下に示します。
  • 設計基本(要件定義)／設計思想(設計の方針)
  • スコープ(仕事の範囲)
  • 仕様の変更(基本機能、インターフェース条件、その他プロジェクト特有の術的事項)
  • プロジェクトスケジュール
  • 検収条件
  • 性能保証
  • プロジェクト手順
  • 提出書類
  • 契約本文

　上記に示す項目はどのようなプロジェクトでも発生する変更管理の対象となります。
　しかし、昨今のプロジェクトを取り巻く環境変化や社会環境そして技術の変化に伴い、設計基本(要件定義)を示すことのできないプロジェクトも出てきています。
　このような不確実性の高いテーマを具体的プロジェクト要件定義として落とし込むことができないプロジェクトも多くなっています。

　このケースはこれまでの課題管理の対象となっているものとは異なったものであり、上記の設計基本(要件定義)の創生ができず、プロジェクトを前に進めることができないでいることも多いようです。特に昨今のIT関連プロジェクトにこのケースが多いようです。昨今のIT技術はDX、AI等などの最新技術との組み合わせによって製造業や一般業務にも関連する技術であり、あらゆる分野に適応させていくことが必然的になってきています。
　そのため、プロジェクト・市場・技術を取り巻く外部環境を考え、曖昧で観念的要求に含まれる問題・課題の解決を顧客と共に共創により、プロジェクトの具体的目的(あるべき姿)を示していくことも請負側の立場となるでしょう。
　このようにプロジェクト初期段階(P2Mにおけるスキームフェーズ段階)での思考を駆使して、むしろ顧客側にプロジェクトの具体的提案ができることが必要となってきています。
　今回のNコムにおける財務会計システムプロジェクトもテーマは「既存の財務会計システムをグローバル対応にする」というだけで、具体的な要件や仕様そして条件もなく、最新のパッケージソフト(例：ERP)にするか、既存システムの更改から始めるかといった社内での議論もありました。
　そのためのプロジェクト要件検討からこのプロジェクトは始まり、情報収集、自社の能力、予算、スケジュール、対象範囲等々の見地からの検証を行い、結局はシステムの更改で進めることになりました。
　その後、関係各部からのヒアリング調査を行い、かつ各部の既存会計システムとのインターフェース等の条件を明確にし、プロジェクト要件を確定していきました。
　そして前月号にて示した組織体制、コーディネーション手順書、プロジェクトスケジュール、予算そしてプロジェクト要件なども含めたプロジェクト計画表を作り、プロジェクトを進めることにしました。

　今月号は筆者の経験からの事例を挙げて変更管理について説明してきましたが、来月号からは経済・社会の複雑で変化の激しい環境下でプロジェクトを主導する「ゼネラルなプロ」について話をしてみたいと思います。
ページトップに戻る