KATOエンジニヤリング開発日誌

「アウトプット無きエンジニアにインプットもチャンスも無い」の精神で書いています

受注プロジェクトの管理を学ぶ - プロジェクトの集結 -

前回に引き続き、履修証明プログラムの「受注プロジェクトの管理」の内容をまとめます。

www.kato-eng.info

前回はプロジェクト実行中の流れでしたが、今回はプロジェクトを集結させる流れです。

プロジェクトの終結

社内プロジェクトと比較すると受注プロジェクトは企業間の契約を完了させるための作業がいくつか必要となるため、作業が膨らむ傾向にある。その中で重要なことはプロジェクトの完了基準に顧客と合意し、その基準を達成することである。

成果物の完成確認と本番移行

受注プロジェクトの契約は完成したシステムが本番で正常に稼働することがプロジェクトの引き渡し条件(完了条件)になっている場合がほとんどで、システムの完成を最終的に確認するのはシステムテストや運用テストだが、通常は受注プロジェクトチームがこの工程も作業範囲に含めて契約しているので、完成品の検収作業を受注業者が手伝っているということになる。

完成品の検収だけで終わるのではなく、本番かどうできて初めてプロジェクトの完了という見方もある。また、ほとんどのプロジェクトが本番移行作業もプロジェクトの範囲に含まれている。

プロジェクト終了時の顧客との役割分担

f:id:masayuki_kato:20171013102010j:plain

前述の通り、受注プロジェクトでは成果物を本稼働に移してプロジェクトが完了するものがほとんどである。その完了方法について提案時やプロジェクト計画作成時に明確にしておくことが重要である。
例えば、統合テストまでの成果物作成で請負契約を終了し、あとは顧客側が移行作業まで対応する契約や、請負部分の成果物の受け入れテストであるシステムテストや移行支援までを工数支援の別契約にすることもある。

受注プロジェクトのプロジェクトマネージャはプロジェクトの終了時の作業の定義について顧客に合意を得ておくことが大切である。システムの完了基準、本番移行手順、移行支援や本番支援の契約方式などについても明確にしておく。

プロジェクト完了確認会議

プロジェクトの完了を確認する会議体は次のようなものが挙げられる。

  • システムテスト完了判定会議
    • システムを構築することだけがスコープに入っているプロジェクトはここで終了。
  • 移行判定会議
    • 本番データの作成作業の直前にマネジメントを集めて行う。
    • システムテストだけでなく運用テスト、ユーザ教育なども含む最終会議。
    • 本番移行作業に入ってもよいという承認会。
  • 本番移行完了確認会議
    • 本番移行作業が問題なく終了し、本番移行が可能であるかを確認する会議。

本番移行作業

本番移行作業は、そのシステムの稼働環境にあわせて行う。朝からオンライン稼働が必須のシステムでは夜の時間で本番移行を済ませる必要がある。移行作業に時間が掛かることが分かっているシステムは、システムを止めることができる長期連休等を利用することになる。

本番移行作業はタイムスケジュールを厳密に作成し取り組むべきで、そのスケジュールで問題ないかリハーサルすることも重要。その中で考慮すべき事としては、本番移行時に何らかの障害が発生した場合に、データを旧システムに合わせて元に戻したりする等の時間である。

移行作業に何らかの障害が発生した場合はデータを元に戻し旧システムで稼働させるか、そのまま移行作業を続けるかを判断する必要も出てくる。

本番移行後のフォローと支援

本番移行後は初期トラブルが発生することが予想されるので緊急対応体制を取りながらシステムのスムーズな稼働を支援する。対応には操作方法の説明やバグ修正、データ不整合の修正、ユーザのオペレーションミスの対応などがあるが、受注企業に責任があるバグの修正や受注企業には責任のないユーザ業務のQ&A対応は明確に区別することは難しいので、この時期は工数支援契約を締結して対応するところが多い。

本番移行後にはこれまで保留していた課題や解決できていない問題が残っていることがある。これらの対応はプロジェクト予算の中で瑕疵責任として行うべきである。
また、この時点でプロジェクトチームは解散しているので瑕疵責任対応ができるよう、受注企業内で体制を準備しておかなければならない。

プロジェクトの終了処理

システムの成果物が完成して本番稼働もうまくできたらプロジェクトは完了する。本番稼働後に落ち着いてきたタイミングで顧客を交えたプロジェクト完了報告会議を行う。この会議で承認を得てプロジェクトが正式に終了することになる。

契約終了処理

受注プロジェクトの正式な終了は契約の終了処理である。通常は営業担当が行うものだが場合によってはプロジェクトマネージャが代行する。

企業の所定の様式で納品書を作成し受領印をもらうことで納品終了となり、プロジェクトが正式に終了する。
プロジェクトが完了しても本番開始後にトラブルが頻発していると顧客に受領印をもらえないことがある。本番開始後の対応を迅速に行うとともに顧客オーナーとの密なコミュニケーションが大切である。

自社内のプロジェクト終了処理

受注プロジェクトでは成果物が完成し顧客との間の契約も終了した後に、次のような自社内のプロジェクト終了処理が残っている。

  • プロジェクトメンバーの解放
  • プロジェクトの評価
  • 顧客満足度調査
  • プロジェクトコードのクローズ

プロジェクトメンバーの解放

プロジェクトメンバーの解放は事前に立てた解放計画に従って行う。プロジェクトの終了時には様々な問題が発覚することもあり、心情的にはできるだけ多くの要員を残しておきたいところだが、コストの面から見てもできるだけ速やかに要員を解放する必要がある。

解放にあたって、プロジェクト内の責任分担の条件もあるが他のプロジェクトの状況が影響する場合もある。次のプロジェクトが決まっている要員については考慮する必要がある。
また、長いプロジェクトの後には休暇や研修を予定している要員もいるので、モチベーションの面からも考慮しなければならない。

プロジェクト完了報告

受注プロジェクトのプロジェクトマネージャは顧客とのプロジェクト契約の終了後、自社内のプロジェクト終了報告を行う。ここではプロジェクトの実績値(コスト・利益・開発期間の予定と実績等)を中心に報告する。
報告書から得られる指標は集計されて企業全体の業務改善や次のビジネス戦略策定の基礎データとなる。

評価指標として最も重要なのは「顧客満足度」である。顧客満足度調査はプロジェクト終了後に顧客に対してプロジェクトマネージャやプロジェクトメンバーのサービスの質や提供価格、成果物の品質や満足度、トラブル発生時の対応方法などについて評価を受けるものである。プロジェクトマネージャ自身がプロジェクト終了後に直接アンケートを取ることもあるが、厳正さを求めるために会社として調査を行うこともある。

顧客満足度調査の結果はプロジェクトメンバーとしては結果を真摯に受け止め次のプロジェクトに活かすことを考え、会社としては次の企業戦略を策定する材料にする。

プロジェクトアカウントのクローズ

プロジェクトが完全に終了したら、自社内のプロジェクトのアカウントコードをクローズする。この作業によって、以降はこのプロジェクトの原価を発生させることはできなくなる。プロジェクトメンバーとしてはクローズしたプロジェクトコードに対して、これ以降は作業時間の報告が出来なくなる。

瑕疵責任と障害対応計画

プロジェクトが完全に終了したら、プロジェクトマネージャもプロジェクトメンバーもいなくなる。しかし、受注プロジェクトでは成果物を納めて1年間の間に発生した障害に対しては無償で修正をしなければならない。関係者がいなくなったあとでの対応をしやすいようにするためにプロジェクトの関連書類・資料は整理して参照しやすいようにしておく。