プロジェクトマネージャ 2021年 午後1 問03

　A社は金融機関である。A社の融資業務の基幹システムは、ベンダのX社、Y社の両社が5年前に受託して構築し、その後両社で保守している。両社はIT業界では競合関係にあるが、ともにA社の大口取引先でもあるので、5年前の基幹システム構築プロジェクト（以下、構築プロジェクトという）では、A社社長の判断で構築範囲を分割して両社に委託し、システム開発をマルチベンダで行う方針とした。A社システム部は、構築プロジェクトの開始に当たり、X社、Y社それぞれが担当するシステム（以下、Xシステム、Yシステムという）の機能が基本的に独立するように分割し、それぞれのシステム内の接続機能を介して連携させることにした。構築プロジェクトの作業、役割分担及びベンダとの契約形態を表1に示す。

　A社は今年、新たなサービスを提供することになり、X社とY社に基幹システムの改修を委託することになった。この基幹システム改修プロジェクト（以下、改修プロジェクトという）のスポンサはA社のCIOであり、プロジェクトマネージャ（PM）はA社システム部のB課長である。B課長は新たなサービスの業務要件を両社に説明するとともに、両システムの機能分担を整理した。この整理の結果、それぞれのシステム内の接続機能を含めた仕様に変更が必要であり、構築プロジェクトと同様に両社の連携が必要なことが判明した。 　 〔構築プロジェクトのPMに確認した問題〕 　B課長は、改修プロジェクトの計画を作成するに当たり、構築プロジェクトのPMに、構築プロジェクトにおいて発生した問題について確認した。 (1) ステークホルダに関する問題 　・X社とY社がA社の大口取引先であることから、A社の経営陣にはX社派とY社派がいて、それぞれのベンダの開発の進め方に配慮したような要求や指示があり、プロジェクト推進上の阻害要因になった。 　・X社とY社の責任者は、自社の作業は管理していたが、両社に関わる共通の課題や調整事項への対応には積極的ではなかった。構築プロジェクトの振り返りで、両社の責任者から、他社の作業の内容は分からないので関与しづらいし、両社に関わることはA社が調整するものと考えていた、との意見があった。 (2) 作業の管理に関する問題 　・実装は請負契約なので各社が定めたスケジュールで実施した。接続機能に関して、X社が詳細設計工程で生じた疑問をY社に確認したくても、Y社はまだ詳細設計工程を開始しておらず疑問が直ちに解消しないことがあった。また、Y社の詳細設計工程で、基本設計を受けて詳細な仕様を定め、A社に確認して了承を得たが、その前に了承されていたX社の詳細設計に修正が必要となることがあった。X社が既に製造工程を終了していた場合は、この修正を行うために手戻りが発生した。A社としては、両社の作業が円滑に進むような配慮があった方が良かったと考える。 　・連動テストには、A社、X社及びY社の3社から多数のメンバが参加し、テストの項目、手順や実施日程の変更など、全メンバで多くの情報を共有する必要があった。これらの情報に関するコミュニケーションの方法としては、3社の責任者で整理して、各社の責任者から各社のメンバに伝達するルールであった。A社メンバへはA社メンバが利用しているWeb上の構築プロジェクト専用の掲示板機能を通じて速やかに伝達し、作業指示も行ったので認識を統一できたが、X社及びY社のメンバには情報の伝達遅れや認識相違によるミスが多発した。 　・連動テスト前半で、接続機能に関する不具合が発生して進捗が遅れた。A社は、連動テストを中断し、A社の同席の下、両社の技術者で不具合の原因を調査して、両社の詳細設計の不整合に起因する不具合であることを発見した。この不整合は、両社のそれぞれの作業及びA社の検収で発見することは難しかった。その後両社で必要な対応を実施して連動テストは再開され、予定どおり完了した。 (3) 変更管理に関する問題 　・Y社が、両システム間の結合テスト工程で、接続機能以外のある機能について、性能向上のために詳細設計を変更した。Y社では、この変更はXシステムとの接続機能の仕様には影響しないと考えて実施したが、実際はXシステムと連携する処理に影響していた。その結果、Xシステムとの連動テストで不具合が発生し、対応に時間を要した。 　・構築プロジェクトでは制度改正への対応が必要であった。制度の概略は実装着手前に公開されており、Yシステムで対応する計画だった。Y社はA社の了承の下、制度改正の仕様を想定して開発していた。その後、連動テスト中に制度改正の詳細が確定したが、確定した仕様は想定と異なる点があり、A社で検討した結果、Xシステムでも対応が必要なことが判明した。急きょX社に要件の変更を依頼することにしたが、コンティンジェンシ予備費は既に一部を使っていて、Yシステムの制度改正対応分しか残っていなかった。Xシステムの対応分の予算は、上司を通して経営陣に掛け合って捻出したが、調整に時間を要した。 　B課長はこれらと同様の問題の発生を回避するような改修プロジェクトの計画を作成する必要があると考えた。 　 〔ステークホルダに関する問題への対応〕 　B課長は、改修プロジェクトの成功には、3社で一体となったプロジェクト組織の構築と運営が必須であると考えた。 　そこでB課長は、社内については、①プロジェクトに対する経営陣からの要求や指示はCIOも出席する経営会議で決定し、CIOからB課長に指示することを、CIOを通じてA社経営会議に諮り、了承を取り付けてもらうことにした。一方、社外については、基幹システムの保守を行う中で、X社とY社の間に信頼関係が築かれてきたと考え、構築プロジェクトで実施した週次でのX社及びY社との個社別会議に加えて、改修プロジェクトでは、②3社に関わる課題や調整事項の対応を迅速に進めることを目的に、B課長と両社の責任者が出席する3社合同会議を隔週で開催することにした。 　 〔作業の管理に関する問題への対応〕 　B課長は、改修プロジェクトを進めるに当たり、作業、役割分担及びベンダとの契約形態、並びにWeb上のプロジェクト専用の掲示板機能を活用することは構築プロジェクトと同様とすることにした。その上でB課長は、X社及びY社から提示されたスケジュールを確認して、スケジュールに起因する問題を避けるために、③接続機能については実装の中でマイルストーンの設定を工夫することを考えた。また、B課長は、連動テストでは、3社の責任者で整理した3社で共有すべき周知事項については、X社及びY社のメンバもWeb上の掲示板機能で参照可能とすることにした。ただし、④契約形態を考慮して、各社のメンバへの作業指示に該当するような事項は掲示板には掲載しないことにした。さらに、詳細設計の完了時及び完了以降の変更時には⑤ある活動を実施することで、後工程への不具合の流出を防ぐことにした。 　 〔変更管理に関する問題への対応〕 　構築プロジェクトでは、連動テスト以降の設計の変更は、A社と、変更を実施するベンダが出席する変更管理委員会での承認後に実施していた。B課長は、改修プロジェクトでは、変更管理委員会には3社が出席し、⑥あることを確認する活動を追加することにした。さらに、B課長は、構築プロジェクトにおいて発生した問題から想定されるリスクとは別に、マルチベンダにおける相互連携には想定外に発生するリスクがあると考えた。そこで、後者のリスクへの対応が予算の制約で遅れることのないように、⑦CIOに相談して、プロジェクト開始前に対策を決めることにした。 　B課長は、CIOの承認を得て、検討した改修プロジェクトのプロジェクト計画を両社のプロジェクト責任者に説明し、この計画に沿った契約とすることで合意を得た。