Versatility「テスト計画が失敗する原因、その回避策」

投稿者

投稿内容

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2005-01-18 16:54

記事の流れは
アカデミックｖｓ現場　→　喧嘩　→　崩壊　→　理想論の解説　→　唐突なまとめ
となっているようです。

とりあえず、次の投稿から著者へメッセージを送ってみませんか？

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-18 17:16 ]

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2005-01-18 17:07

まずは、他の記事を参考にしてみました。

続・いいかげんにして！日本企業　─理不尽な態度
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/05/01.html

ここで挙げられている日本企業における受託ソフト開発プロジェクト
（以下ソフト開発）での問題点
「仕様変更の段取りの悪さ」「仕様変更という名の仕様不備が多い」
「仕様変更が発生しても、謝罪の言葉がない」

これらがプロジェクトのテスト計画に大きく影響を与えているのは
説明がいらないでしょう。
仕様変更＝モノの変更＝テストの追加発生もしくは変更

という非常に簡単な計算を承認してもらえないことが
この問題の大半をしめるのではないでしょうか？

二つの記事は非常に対称的で、ソフト開発における
雇われる側と雇う側がお互いに困っていることをあらわしていると思いました。

また、Versatilityという言葉が「テスト計画の失敗」の予防にならないと思いました。
なぜなら、結局のところ次のレーンは違うボーリング場かもしれないし、
ピンが１１本かもしれないというのがソフト開発の現場で起きていることだと思います。
かといって、経験者のみを集めようとしてもコストや時期・時間の兼ね合いが
取れないことが多いわけです。場合によっては世界に経験者が１０人未満とか
世界で４例目の導入とかありますから。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-18 17:08 ]
[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-18 17:12 ]
[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-18 17:14 ]

もちつけ・・・て。事件は会議室でおきてるんだ！って台詞に反応しすぎですね。

[ メッセージ編集済み編集者: zaxx_MD 編集日時 2005-01-18 17:21 ]

masuda: 会議室デビュー日: 2005/01/21; 投稿数: 12

投稿日時: 2005-01-26 18:43

引用:
zaxx_MDさんの書き込み (2005-01-18 16:54) より: 記事の流れはアカデミックｖｓ現場　→　喧嘩　→　崩壊　→　理想論の解説　→　唐突なまとめとなっているようです。

「唐突なまとめ」ってのは同感です。もうちょっと補足（と展開かな）が欲しいところです。
計画と実施に対するフィードバックの話は、ワインバーグの「ソフトウェア文化を創る」シリーズにあって、『ワインバーグのシステム思考法』から順々に解説されています。CMMやISO9001のように形式化された「慣習」に従うレベルと、成果物（製品やバグ票など）をフィードバックしながら計画を変更していく形の舵取りのレベルの話が書いてあります。
記事にある「機敏にフィードバックすること」以下の文章ですが、ずばり「アジャイル」という単語を出して欲しかったです。続きのために残しておいたのか、フィードバックを受けながら作業を進めるというやり方は、アジャイルの「ハンドルを左右に調節しながら曲がった道を進む」に等しい訳で、このあたり触れたほうがわかり易いかな、と思いました。

Versatility「テスト計画が失敗する原因、その回避策」

スキルアップ／キャリアアップ（JOB@IT）