PR
がめら4354
口の悪い管理人嫦娥のホームページです。ゲームや本のレビュー、超手抜き料理レシピなど煩悩のままに増殖しています。
Calendar
Freepage List
Comments
Keyword Search
▼キーワード検索
2009年12月13日
カテゴリ： 何故日本のオフショアは失敗するのか
問題です。
貴方は受け入れ検証を管理するtesting engineerです。
貴方が受け入れテストを担当するプロジェクトで、既に出荷している製品の「command」のbugを修正しました。
このbugの修正依頼は、オフショア発注側（つまり受け入れ検証側）の要求で発生し、
修正内容をuserにアナウンスする必要がありますが、bug自体はminor Changeとして処理されます。
貴方がとるべき行動は何でしょうか？
１．修正されたbugにあうように、既存batch fileを変更する。
受け入れ検証仕様書も修正にあわせ変更する。
実行したbatch fileが問題なく実行され、
２．minor Changeであるため、既存batch file、既存受け入れ資料はそのままとする。
既存の検証結果と比較し、該当commandの実行結果だけが異なることを確認する。
修正bugの仕様確認用のbatch fileや検証資料を別途作成する。
修正仕様が妥当であることを確認する。
さて、testing engineerとして、ここで問われるのは、
出荷済み製品の障害管理をどうするのか、どのように考えているのか、
というskillです。
本件は、bugと製品自体の扱いを理解していなければ、正しい答えは導き出せません。
大概のプロジェクトでは、Major Changeは根幹的な仕様変更、Minor Changeは仕様変更を伴わないbug修正など、といったように使い分けています。
その違いの扱いを理解できているか否かが問われます。
貴方ならどうしますか？
major Changeになって始めて、受け入れ検証用のbatch fileの変更を含めて「検討」します。
検討するんであって、必ずしも修正はしません。
何故か解りますか？
これが理解できない日本人のengineerは多く、
中国人にいたっては「何故こんな効率的ではないことを許すのか」と抗議するくらいでしょう。
を理解できるか否かが分かれ道です。
ちなみに理解できている
というのは、
日常的に応用して初めて理解である
とオイラは思うがね。
engineerの多くに、この考え方、「bug修正の正しさの証明」中、「影響がないことの証明」が盲点となっているのを観測できます。
「効率化」
を歌うengineerに限って、１．を選択することが多く、
１．の「危険性」を理解できない
↓
結果、品質を落とし、何が原因なのか発見しにくくなります。
正直にいいますが、２．の方が「効率」がいいし、「品質」も保証できるんだけどね。
これが理解できない。
「貴方がuserに対して保証しなければならない動作はなんですか？」
ということが理解できていれば、
「bug修正の結果が他に影響ないことを保証すること」
も検証の重要な要素であることに気が付く筈なんですがね。
この考え方は、なにもtesting engineerだけに限ったものではなく、
実装者である開発者にこそ必須の考え方なのですが、
検証のプロが理解できないものが理解できる訳がない。（笑）
特にAsia諸国では、まだ「検証」「テスト」というものに対する必要性が理解されておらず、
programmerよりもtesting engineerの身分低いというU.S.A．ではありえない状況です。
確かに、testing engineerのlevelも低いが、それ以上に開発engineerのskillが低い。
文化的に、何かの「証明」をする、という行為が、
何かを作った人に対する
背信行為にあたる
という考え方が根底にあるんじゃないのか？
と疑っていますが、証明しない信用、は「妄信」というんじゃないのかねぇ
くだらね。
貴方は受け入れ検証を管理するtesting engineerです。
貴方が受け入れテストを担当するプロジェクトで、既に出荷している製品の「command」のbugを修正しました。
このbugの修正依頼は、オフショア発注側（つまり受け入れ検証側）の要求で発生し、
修正内容をuserにアナウンスする必要がありますが、bug自体はminor Changeとして処理されます。
貴方がとるべき行動は何でしょうか？
１．修正されたbugにあうように、既存batch fileを変更する。
受け入れ検証仕様書も修正にあわせ変更する。
実行したbatch fileが問題なく実行され、
２．minor Changeであるため、既存batch file、既存受け入れ資料はそのままとする。
既存の検証結果と比較し、該当commandの実行結果だけが異なることを確認する。
修正bugの仕様確認用のbatch fileや検証資料を別途作成する。
修正仕様が妥当であることを確認する。
さて、testing engineerとして、ここで問われるのは、
出荷済み製品の障害管理をどうするのか、どのように考えているのか、
というskillです。
本件は、bugと製品自体の扱いを理解していなければ、正しい答えは導き出せません。
大概のプロジェクトでは、Major Changeは根幹的な仕様変更、Minor Changeは仕様変更を伴わないbug修正など、といったように使い分けています。
その違いの扱いを理解できているか否かが問われます。
貴方ならどうしますか？
major Changeになって始めて、受け入れ検証用のbatch fileの変更を含めて「検討」します。
検討するんであって、必ずしも修正はしません。
何故か解りますか？
これが理解できない日本人のengineerは多く、
中国人にいたっては「何故こんな効率的ではないことを許すのか」と抗議するくらいでしょう。
を理解できるか否かが分かれ道です。
ちなみに理解できている
というのは、
日常的に応用して初めて理解である
とオイラは思うがね。
engineerの多くに、この考え方、「bug修正の正しさの証明」中、「影響がないことの証明」が盲点となっているのを観測できます。
「効率化」
を歌うengineerに限って、１．を選択することが多く、
１．の「危険性」を理解できない
↓
結果、品質を落とし、何が原因なのか発見しにくくなります。
正直にいいますが、２．の方が「効率」がいいし、「品質」も保証できるんだけどね。
これが理解できない。
「貴方がuserに対して保証しなければならない動作はなんですか？」
ということが理解できていれば、
「bug修正の結果が他に影響ないことを保証すること」
も検証の重要な要素であることに気が付く筈なんですがね。
この考え方は、なにもtesting engineerだけに限ったものではなく、
実装者である開発者にこそ必須の考え方なのですが、
検証のプロが理解できないものが理解できる訳がない。（笑）
特にAsia諸国では、まだ「検証」「テスト」というものに対する必要性が理解されておらず、
programmerよりもtesting engineerの身分低いというU.S.A．ではありえない状況です。
確かに、testing engineerのlevelも低いが、それ以上に開発engineerのskillが低い。
文化的に、何かの「証明」をする、という行為が、
何かを作った人に対する
背信行為にあたる
という考え方が根底にあるんじゃないのか？
と疑っていますが、証明しない信用、は「妄信」というんじゃないのかねぇ
くだらね。
お気に入りの記事を「いいね！」で応援しよう
Last updated
2009年12月15日 08時48分36秒
[何故日本のオフショアは失敗するのか] カテゴリの最新記事
-
YAMAD○電気に見る日本人の問題 2010年01月04日
-
Asia人の独創性、もしくは、私がOriginali… 2009年12月17日
-
笑顔でゴキブリ出汁のお茶をご馳走したく… 2009年12月16日
【毎日開催】
15記事にいいね！で1ポイント
© Rakuten Group, Inc.
