先日、クライアントに迷惑をお掛けした事件が発生しました。弊社自身が同じ轍を踏まないようここに記録を残します。本質的な部分に目を向けていますので、恣意的に事実とずれを作っています。
【表面的問題】
本来、アップすべきではないファイルをアップロードした。
【本質的問題】
日本語で渡された資料に対し、資料の意図を理解出来ず、そのまま処理してしまった。
通常、日本語が分かる人の場合、「ここはサンプルです」と書かれてあった場合、それはサンプルなので、置き換える必要があると認識します。しかし、言葉が分からない場合、それは一つの記号でしかなく、そのまま利用しようとします。
この問題は、オフショア開発を実践しているあらゆる局面で発生します。例えば、入力チェックのロジックがあり、ロジック毎にエラー文言を変えて出さなくてはいけないとします。
例1)メールアドレスが不正な場合は「メールアドレスが不正です」
例2)必須項目の場合、「Aは必須です」
などです。日本後が分からない場合、例1)と例2)の違いが分かりません。従って、テストの際、ロジックチェックを正常にテストしたとしても、文言チェックに漏れが発生する場合があります。日本側から見た場合、「何をチェックしているんだ!」となりがちですが、現場としてはロジックチェック以上に難しい問題です。特に、仕様書が間違っていた場合は最悪です。日本の感覚では、そのぐらいは分かるだろうと思われるかも知れませんが、現場では日本語を記号として捉えている以上、仕様書にミスがあるかどうかまでは分からないケースがあります。
この問題に対する対応策は、二つ。
1)日本語の分かるテスト要員を配置すること
2)仕様書を正確に記述すること
大切なのは2)です。特に日本語の分かる、もしくは、日本人のSEが正確な仕様書を作成することで回避は出来ます。1)があれば万端ですが、幸い、中国の場合、日本語を欧米人程、記号化せず、ある程度言葉として見れますので、違っているようであれば気づきます。
ただ、このようなチェック上の問題であれば、まだましですが、詰め作業が必要なコミュニケーションを要する作業の場合、さらに複雑です。弊社としては、この問題に対処する為、日本人スタッフ、またはネイティブに近いレベルの人材配置を通常の企業よりも大目に行っております。
それでもなぜ、ミスが発生したか?
通常ルート以外での仕事処理ルートが発生してしまっていた為です。弊社の管理体制に不備があったという事です。実際、その通りでした。弊社として、管理出来ないルート(担当者間で直接)での仕事依頼があった為です。
弊社としては、プロジェクト管理をより一層強化すると共に、クライアントに対しても通常のルートと異なるルートでの依頼は極力さけて頂くようご理解を頂きました。
クライアント様にご迷惑をお掛けしないように今後も改善に努めていきたいと思います。