タグ: , ,

プロジェクトの「管理の管理」(後編)

<<前回>>からの続きです。

スクリーンショット 2016-06-10 19.57.39 「Q(品質:Quality)」の管理は、人が行う全ての作業において行われなければなりません。ベンダーがこのQの管理をどのように行っているのかを知り、その管理が十分に行われていることを監視(管理)していなければなりません。

 ベンダーのPMの方がどんなに優秀なPMでも人間ですし、優秀と言えるPMは非常に残念ながら稀にしか存在しません。
   



a0008_001807 のコピー  発注者側の皆さんは例えばテスト項目の詳細な内容まで知る必要はありません。

 どのようにテスト項目を決めているのか、それは何故そのように決めるのか、テスト項目が10,000ということだが、何故それで十分と言えるのか、その根拠は何か、漏れをなくすためどのような確認を誰が行ったのか、それを誰がチェックしたのか等々、管理の内容をチェックしたり、テスト内容記述書を作成者ごとに数件ずつ記述方法に問題がないかを抜き取り検査をすることが求められます。  


 優秀と言えるPMは本当に少ないですし、そのPMも人間ですから。
 


a1020_000086 勘の良い方は気づかれたでしょうが、そうなのです。テスト仕様書だけではなく要件定義書や仕様書についても同じなのです。しかし、要件定義の段階でQの管理を行っているベンダーは非常に少ないでしょう。

 でも、米国での調査によると、プロジェクトのQCDの失敗の原因の48%が要件定義に関連しています(Tracy Hall, Sara Beecham, and Austen Rainer, 2002)。  


a1380_000231  一度ベンダー企業のSE等が書いたドキュメントを抜き取って読んで見ることをお勧めします。書かれていることの意味は分からなくても大丈夫です。きっと「何?この日本語」「誰がチェックしているの」と驚かれることになると思います。そうなんです。皆さんにもITプロジェクトのQの「管理の管理」は簡単に出来るのです。    


 「D(開発期間:Delivery)」についてはベンダーのPMが進捗会議の都度、進捗状況表という(稲妻)グラフを提示して、「遅れはありません」「順調です」「多少遅れはありますが、○○月の第○週までに回復します」と前向きな説明をするでしょう。  



 しかし、Qの場合と同じで、PMがどのようにチェックしているのか、なぜそれで十分(大丈夫)と言えるのか、自分で直接確認したのか、他に誰が確認しているのかといった質問をいれるだけで良いのです。   a0960_003608  

 ここでも「5Whys」を実践してみましょう。

 また、ベンダー側の複数の作業担当者に「最近調子はどう?」と労いながら声をかけて、生の現場の話を聞くことも有効ですので心がけてはどうでしょうか。

 但し、決して担当者に直接仕事に関する指示をしてはいけませんので、要注意です。「偽装請負」になりかねません。      


(株)プラッサムの「プロジェクト管理支援サービス」のご案内はこちらです。