writing by MASA
*このコラムはiPM naviで配信しています
プロジェクトは、一般的に要件定義・基本設計の最終的な品質保証をITパートナーが主体となり総合テストで行います。
このテストを通じて、システム要件とシステム不具合（バグ）が解消していればシステム視点として品質が合格となります。
そして、最終工程のユーザーテストで、開発されたシステムを試運転し正確な業務運用ができていると判断されたときに、全ての品質条件がクリアーされたことになります。
この品質保証の判断には、ITパートナーとクライアントに大きなギャップが生じます。
それは、システム視点とクライアント視点という品質目線が違うからです。
そのためにも、ITパートナーは総合テストでも『クライアント視点』のテストを盛り込み実行することで、クライアントは安心できて、無用な誤解も避けられるのです。
監修：えのきのキャリア 2003年に大手コンサルファームにジョイン。 数年間のオープン系システムのインフラエンジニアを経験したのち、プロジェクトマネジメント関連業務へキャリアチェンジ。 以降中小から大規模までさまざまなプロジェクトにおいてPM/PMO業務に従事。 製造業、メディア、金融、官公庁など、業界を問わず経験しており、クライアントの様々な文化に柔軟に対応している。近年ではシステム関連の知識を生かし業務コンサルテイング領域でも活動中。 えのきのコラムを読む...
こんにちは、プロコンサルのMASAです。
iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。 その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。 今回のコラムは、SIerに勤務する38歳のPMの方からのご相談となります。
MASAのキャリア 2004年に大手コンサルファームBにジョイン。 大手事業会社をクライアントに持ち、クライアント社内で活用する品質マネジメント基準・開発プロセス基準の策定に従事。また、PMOとしてクライアントのプロジェクト推進及び品質維持に貢献しプロジェクトを成功に導いた。 2016年に大手コンサルファームMにジョイン。
大手エネルギーインフラ会社のガバナンス部門にて、大規模システム開発プロジェクトのマネジメント品質管理に従事。PMOとしてプロジェクト運営における問題点の可視化とプロジェクトマネージャおよび上位層への改善提案によりプロジェクトを成功に導いた。
目次
PMからのご相談
■相談者 SIerに勤務する38歳のPM ■相談内容 わたしはSIerに勤める38歳です。 この度、システムエンジニア職からPM職に転身しました。今回のプロジェクトで初めPMになった未経験者です。 ①現在、プロジェクトは総合テストの中盤です。 総合テストはシステム要件をもとにして作成された要件定義書・基本設計書の品質を実機で確認することが目的であるため、システム視点でテストを実施しています。 ②わたしは、クライアント主体で実施するユーザーテストへスムーズに引き継げるように、総合テストの中間報告をしました。 ③中間報告前にチームで進捗状況・品質状態を確認したところ、スケジュール通りに進行しており、不具合に対しても品質管理プロセスに従い修正していました。 ④しかし、クライアントは「わたしたちは技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい。」とご指摘を受けました。 ⑤わたしは、総合テストの位置付けと目的を説明しましたが、お客さまは納得してくれません。 ⑥クライアントに、納得してもらえる方法はないでしょうか？ ■相談のポイント ①相談者は、総合テストの中間報告でシステム視点での品質について説明した。 ②クライアントは、業務視点での品質を気にしている。 ③相談者は、業務視点（クライアント視点）での品質基準がわからない。 あなたが、PMであればどのように対処しますか？
こんな時は、こうしてみれば良いですよ！
このように前提条件を整理しました。 ・相談者は、クライアントへ総合テストの位置付け・目的について強引な説得をしない。 ・ITパートナーは、業務視点での品質基準を検討する工数を捻出できる。 ・クライアントは、業務視点の品質基準が納得できるものであれば受け入れる。 総合テストは、ITパートナーが主体となり実施するテストです。 そのため、どうしても『システム目線』になっています。 *特に、PMがエンジニアリング・キャリアが長いと、この傾向は強いです。 クライアントは、システム品質の保証と業務運用の保証を求めるものです。 しかし、クライアントは、システムありきの業務運用ではなく『業務運用ありきのシステム』と意識するものです。 そのためには、総合テストの中で『クリティカルな業務要件』に対して正確に業務運用ができるかのテストを実施しなければなりません。 まずは、このことを認識して、この問題をアプローチしていきましょう！ *このアプローチはDX時代に適応したリスキリングしているPMの方にも実用的に使えます。 アプローチ1 要件定義書・基本設計書からクリティカルな業務要件を洗い出す。
※下図のクリティカル条件を参考のこと。
アプローチ2 洗い出した業務要件をもとにクライアントと総合テストで実施する業務範囲を決める。 アプローチ3 テスト範囲を明確にするためにユースケースを作成する。 アプローチ4 ユースケースをもとに、テスト仕様書を作成する。 アプローチ5 クライアントへユースケースとテスト仕様書を説明し実施可否を判断してもらう。 【 注意 】 ユーザーテストで実施する予定のテストが含まれている場合は、総合テストもしくは、ユーザーテストのどちらで実施するかを調整する。 ※同じテストを2つのテスト工程で実施することは、プロジェクト工数を圧迫するため。
まとめ
プロジェクトでは、品質基準を作ります。 元々、エンジニアから仕事をスタートした人にとっては、技術的な知見を活かせるので、容易に品質基準を策定できるという誤解があります。 確かに、品質基準は技術的な観点が必要ですが、クライアントの観点での品質基準を考えるスキルを持っていなければなりません。 クライアントは、システムありきの業務運用ではなく『業務運用ありきのシステム』と意識しています。 そのため、エンジニアリング視点で、『品質は、大丈夫！大丈夫！』と伝えても、意味がないのです。 ポイントは、テスト開始前までに、このようなことを実施しておくことです❗️ ・クリティカルな業務要件を整理する。 ・総合テストで実施すべき業務範囲を確定する。 ・テスト範囲を明確にするために、ユースケースを作成する。 ・クライアントへユースケースとテスト仕様書を説明し理解を得る。 これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。 最後まで、読んでいただき有難う御座いました。
わたしのコラムで、あなたのお役に立てれば幸いです。
品質管理・スコープ管理、今回のようなリスク対策、これらをコラムとして配信していこうと思ってます。
ぜひ今後とも応援を宜しくお願いします。
*Back Numberはこちらです↓
