中華料理店の皿洗いとは異なり、ソフトウェアの品質は目に見えません。ソフトウェアに関する国際標準規約では、ソフトウェア製品の品質を6つの特性、機能性、信頼性、使用性、効率性、保守性、移植性に分類して定義しています。これらはすべて仕様書に明記すべき事項ですが、長年にわたり日本型開発アプローチの世界に甘んじてきた多くの企業には、仕様書の網羅性を保証する有効な手立てがありません。
一般には、こうした仕様書の不備を補うために、
などのさまざまな策を講じて品質向上に全力を尽くします。
数ある品質管理手法の中でも、明確な数値目標を好む中国企業に対しては、テスト工程でのテスト件数やバグの発生率に着目した品質基準が特に有効だと筆者は考えています。国内では、多くのソフトウェアハウスで採用されているソフトウェア工学の標準的な知識ですが、残念なことに筆者が取材した多くの中国オフショア開発プロジェクトでは、品質基準が十分に運用されていないのが実態です。
中国オフショア開発で一歩先を行く企業では、各種デザインレビューにおけるレビュー項目や指摘事項の発生率まで基準化しています。本連載第2回「不信感だらけのソースコードレビュー」では、日本と中国ではレビューに対する考え方が根本的に異なる事例を紹介しました。この背景には、一般的な中国人が持つ「間違い=悪」だとの気質が隠れています。多くの日本人が「恥をかくこと」を嫌うのと同じように、中国人技術者は「バグを出すこと」を反射的に嫌います。また、「レビューで指摘を受けること」は「他人から間違いを指摘されること」を意味するため、指摘する側もされる側も双方にとって多少なりとも緊張することがあるかもしれません。
その結果、オフショア開発に携わる日本人から
なんて声をよく耳にします。
デザインレビューに関する品質基準を設けることで、中国人が本能的に持つ「レビュー指摘」に対する嫌悪感を緩和して、デザインレビューの活性化を促しましょう。
Copyright © ITmedia, Inc. All Rights Reserved.