オルタナティブ・ブログ > IT業界のマーケティングを問う >

戦略、プロモ、広報など実務から見たマーケティングをお話します

品質レビューは機能しているか?

»

多くのプロジェクトが品質面で問題を抱え、そのフィックスのために工数とコストを費やしていることは周知の事実だと思います。品質上の問題が露呈するタイミングが遅れることで、傷口が大きくなってしまっているプロジェクトも散見されます。

品質を確保するために、プロジェクト管理を強化することと共に、多くの会社では社内での品質レビューなるものを行い、要件定義や設計の成果物のみならず、プロジェクト運営での課題を事前に潰していくことで、コストへの影響を最小化しようと努力されています。

多くの大手SI企業で、プロジェクトの品質レビューの現場や、レビューのコメント等のレビュー結果、そしてレビュー前後でのプロジェクト状態の変化を見てきました。その結果感じていることは、品質レビューが本来の目的を果たしていないケースが多くなってきてる事実です。

原因の一つとしては、プロジェクトも大型化して、単なるシステムから業務まで、さらにはアプリケーションも複合型のものが増えてきたことなど、プロジェクトの性質の変化が挙げられると思います。その一方で、レビューを行う側、レビューを受ける側の準備、レビューの内容、レビュー可能な範囲など、変化する環境に対して旧態のままでのレビューを実施していることが、レビューが本来の目的を果たさない大きな原因であると思います。具体的には、以下にあげることが問題の原因だと思います。

  • まず、レビューが単なる社内手続きと化していて、レビューを受けること自体が目的化してしまっている。特に案件の状況報告等で、品質レビューを受けたこと自体が、ある意味でプロジェクトの健全性を現すチェック項目になっていて、とりえあえずレビューを受けることで、プロジェクト管理上の義務を果たそうとしている。
  • レビューに対して、レビューを受ける側の事前の準備が不足している。現状の課題や問題点のたな卸しをしない状態でいきなりレビューを受けている。
  • レビューをする側が、レビュー前にプロジェクトのドキュメント等を精読していないため、レビュー内容が通りいっぺんのものになっている。酷い場合には、現状を聞くだけのレビューになっている。
  • レビューする側が、本来必要なレビューポイントを網羅できない。社内ではある程度職位の高い人が担当するものの、その人の経験では、現在のプロジェクトの複雑さや多様性に対応できない。
  • コメントやアクションが一般的であり、具体的な作業や、アクションを取った結果まできちんとフォローされていない。特にアクションの結果は、本来レビュー担当者が再度確認することで、初めてレビュー完了なのだが、レビューミーティング後は、さほどプロジェクトの状況を監視しようとしない。

多くの会社で思い当たることがあるのではと思います。

これらの状況を引き起こしている原因としては、プロジェクト品質レビューが属人的な体制で行われていて、本来レビューで何を確認すべきであるかも属人的になり、レビューのレベルもレビュー担当者の個人スキルとカバー範囲に依存してしまうことにあります。さらには、このことが結局は時間をかけてレビューの準備とレビュー実施、さらにはフォローまで行うことができない状況を生んでいます。

本来レビューは多角的に行うべきであることも考えると、専属のレビュー組織や担当者も必要ですが、多くの会社でのプロジェクト・マネジャーは他のプロジェクトのレビューに参加すべきだと思います。

専属の人の下に、プロジェクトを抱えている複数の他のプロジェクトマネジャーがレビューにアサインし、品質責任をレビュー担当者として負う形を構築すべきだと思います。これが現状の人材払底状況で社内で唯一できる策だと考えます。それでも工数を確保できなければ、外部に頼るという手もありますが、本質的にはプロジェクトマネジャーが他のプロジェクトの現状から学ぶこと、すなわち情報のシェアという観点からも、レビューは無理しても社内で行うべきでしょう。

是非、大手SI企業さんはご一考ください。品質問題のつけはコストだけでなく、下請けの作業にも影響しますので…

Comment(3)

コメント

鶴田さんのご意見に同意です(^^
レビューという言葉だけが独り歩きをしてしまい、「やった」「やらない」だけが問われてしまうと本来のレビューの意味がなくなってしまい、余計なプロセス・ステップが増えた・・・となりかねないですね。

プロジェクト・マネージャによる相互レビューは実際にお客様に提案させていただき、実践いただいたことがありますが、お互いの経験やスキルから漏れを補い、非常に効果を発揮いただきました(何をどのような基準でレビューするかについての準備がやはりポイントでした)。

ベテランPMが若手PMをレビューすることでベテランのノウハウを伝授することもできますし、ベテランPMも自分の経験の棚卸しや再認識ができ、非常に効果的ですね。

品質については、開発の過程(プロセス)そのものが品質を作りこむという考え方がありますが、その点からもレビューは非常に重要な品質の作りこみ作業となりますね。

kondo

レビュー担当者というか本来であればQAエンジニアの仕事なのではないのかなぁと思いますね。
PMの仕事の範疇なのかどうかは微妙なところでしょうか。QA担当とのレビュー結果を承認するくらいでいいような。
とはいえ実際にはQAエンジニアが単なるテスターではなくきちんと機能しているところは少なそうです。
本来であればちゃんと人材を育成すべきなんでしょうけれど。
って理想論ばかりですね、すいません。

長沢さん>
コメントありがとうございます。レビューに費やす時間や資源をもっと効果的に使えば、もっともっと良いものが確実にできるのではと思う今日この頃です。

Kondoさん>
QAが出来る人が少ないことも課題の一つですよね。このままでは、システム監査ではなく、PMでもなく、レビューの公的資格までできてしまったりして…

コメントを投稿する