ソフトウェアハウスとの付き合い方

投稿者

投稿内容

taro: ぬし; 会議室デビュー日: 2003/10/20; 投稿数: 316

投稿日時: 2004-11-30 13:12

ないものを出せと言うとねぇ･･･後から作るだけなんですよねぇ･･･。
社内をハンコ集めて回ったりとか･･･。（ごにょごにょ）
正確な進捗報告とか、実情を知るためには結局「仲良くなる」しかないんですよね。
とてもそんな気持ちにはなれないと思いますが、、、。
相手も人間なんだ、うまくいく可能性はほとんどゼロだけどまだゼロではないんだ、
と念じながら「そうは言っても大変ですよねえ」「ぶっちゃけどうなんですか？」等々
口を割らせて、正確な状況を掴んだ上で、なんとか落とし所を見つけるしかないんですよね。
動く前のトラブルより動き出してからのトラブルの方が実害がありますから･･･。
一度相手のリーダーと赤提灯でも行くといいんじゃないですかね･･･？

Beatle: ぬし; 会議室デビュー日: 2003/06/09; 投稿数: 394

投稿日時: 2004-11-30 13:55

引用:

きくじろうさんの書き込み (2004-11-30 08:53) より:

結合テストが終わった段階で、基本設計書を作らせ（順序が逆ですが）、詳細設計書を見直させ、それを精査しました。
それでも仕様の不一致が山ほど出ており、修正の要求は出しているものの、相変わらず、目先の対応とテストスケジュール消化だけに没頭しており、テストの品質は果たして大丈夫なのか、問題が解消されているとは到底思えないのです。

設計書を精査したということは、現時点で完全な設計書になったと考えて良いわけですね。
もし、間違い等を指摘したままの状態なら修正を施したものをまず作成するほうが良いです。
そこで、設計上の食い違いというのが無くなった状態にしておいて、開発側には現状で
出ている不具合の改修と、設計書の機能が満足しているかを再度単体テストからやらせ
ましょう。
その間、きくじろうさんは受け入れテストの仕様書を作りましょう。
受入テストは、本来要件定義書等から起こすものですが、この際基本設計書でも詳細設計書
でも構いませんから、そこからこれだけの項目のテストに合格すれば受け入れOKという
指針を持って作成します。これが重要です。このテスト仕様書に漏れていて後で判明した
不具合については、両者に責任があるという意味で、改修費用が発生しても止む無しという
気合で書く必要があります。

で、もうひとつ付け加えると、テスト仕様書（チェックシートでも可）は、どうあるべきか
ということがきっちりと書かれているか、それは何を持ってそう判断するかまできっちり
と書きましょう。例えば、一覧リスト出力等なら既存システムで出したこのリストと同じで
あればOKというような形です。目で見てOKというのは色指定とかデザインのバランスとか
いうこと以外は極力避けましょう。
次に、そのテスト項目の処理内容等を説明している設計書の参照ページも記述しておけば
完璧です。

この仕様書を持ってテストを行い、NGとなった場合にはきちんと原因、解決方法等を
記述させ、レビューしてから改修作業に入らせるようにします。レビューは受け入れ
テスト全部が終わってからじゃなく、細かい単位のテストが終了する毎でも、毎日で
も良いです。それを繰り返すと何日目からか受入テストと改修チェックの両方を行う
ようになるのでテストする人間（きくじろうさん）側のメンバーも増やす必要が出る
かもしれませんので、日々のテスト数、不具合数、改修数等の進捗管理はきちんと記録
し、バグ改修曲線のような目で見える形で確認しても良いでしょうね。

まぁ、あれこれ角を立ててお互いに感情的になるよりも、きちんと手順を踏んでひとつ
ひとつ進めるしか方法は無いと思いますよ。

よっちゃん: 大ベテラン; 会議室デビュー日: 2004/02/15; 投稿数: 117; お住まい・勤務地: 千葉の片田舎

投稿日時: 2004-12-01 10:24

引用:
はゆるさんの書き込み (2004-11-29 20:54) より: ・・・・・・このあたりの記事は、参考になりますでしょうか。　・「動かないコンピュータ」からは脱出できない，陥らないことが重要（IT Pro さんより）

脱線です。　当事者様　済みません　ｍ（＿＿）ｍ
「動かないコンピュータ」の記事は
当事者ではありませんが、とても興味深く読まさせて頂きました。

[編集]
主語が沢山出来てしまい、修正しました。
[/編集]

[ メッセージ編集済み編集者: よっちゃん編集日時 2004-12-01 10:27 ]

[ メッセージ編集済み編集者: よっちゃん編集日時 2004-12-01 10:29 ]

きくじろう: 常連さん; 会議室デビュー日: 2004/09/06; 投稿数: 43

投稿日時: 2004-12-03 23:55

みなさんアドバイスどうも有難うございます。
来年の今頃は今の状況を懐かしんで居られることを願いつつ、とうとう師走を迎えました。

引用:

komeyさんの書き込み (2004-11-30 11:49) より:

試験で発生した不具合は全て報告してもらい、分析しましょう。(分析は非常に重要です)
ここでの分析というのは、上がってきた不具合に対し、
・プログラム上の問題点(どこがどういう理由で想定外の動作になったのか)は何か
・プロジェクト上の問題点(なぜそういうコードになってしまったのか)は何か
・類似不具合はないか
・類似不具合を探すためにどういうアクションを取ったか
・同じ不具合がないことを保証するためにどういう試験を追加したか
・今後、同じ原因で不具合が発生しないようにどうするか
を調べれば良い、と思います。
そして一番重要なのが、この分析を実際の成果物に生かす、ということです。実際、分析はしたけど対策が実施されていない、という報告書は山ほどあります。対策が夢物語になっている報告書はつき返しましょうね。

ここなんですね。私が一番不満なのは。
報告書は貰いましたが、うそばっかりで何も変わっていないように見える。
途中から体制の見直しをしているが、何も機能していないように思えるのです。
基本的にテストは受け入れ側の責任という主張なんですね。

確かに検収をするのは、発注者ですが、
単体テストの終わっていない状態で、未完成の仕様書とプログラムを納めて、はいどうぞ、時間内にチェックして下さいよ、こんな仕事の仕方を上場企業が行うなんて信じられますか？
責任者の出している指示も、その場その場の付け焼刃的な指示しか出していないようなので、何処まで言っても話が平行線上です。

引用:

ほろりんさんの書き込み (2004-11-30 12:17) より:
もうやっておられるかもしれませんが、手はじめにきくじろうさん自身の不具合管理票を作成されることをお勧めします。
EXECLとかに発生した不具合の日付、タイトル、不具合や指摘の内容、対処内容、対処日とか書いて表にしておく。
で、これを送りつける。

はい、これは当初からやってます。口うるさく言うようになってやっと出るようになりましたが、修正範囲や修正方法などの報告もまともにしてこないのには参りましたが。

引用:

Beatleさんの書き込み (2004-11-30 13:55) より:

この仕様書を持ってテストを行い、NGとなった場合にはきちんと原因、解決方法等を
記述させ、レビューしてから改修作業に入らせるようにします。レビューは受け入れ
テスト全部が終わってからじゃなく、細かい単位のテストが終了する毎でも、毎日で
も良いです。それを繰り返すと何日目からか受入テストと改修チェックの両方を行う
ようになるのでテストする人間（きくじろうさん）側のメンバーも増やす必要が出る
かもしれませんので、日々のテスト数、不具合数、改修数等の進捗管理はきちんと記録
し、バグ改修曲線のような目で見える形で確認しても良いでしょうね。

まぁ、あれこれ角を立ててお互いに感情的になるよりも、きちんと手順を踏んでひとつ
ひとつ進めるしか方法は無いと思いますよ。

そうですね。
地道にやるしか道は見えないことはわかってはいますが、何分にも弊社側の体制が手薄な状況に、中途半端なテストで納品し、あとは待機で待ちの体制、受入れテスト～時間切れカットオーバー～以降は別契約で精算に持ち込もうとしているのは見え見えなんですよね。
運用準備のためのタスクに加えて、そこまでの管理をする余裕が無い、社内に人も居ない、というのが悲しい現実です。

ついつい感情的になってしまうんですね。
上司も逃げ腰だし、社内の信用ゼロですね。
気長に来年の夏くらいのつもりでやるしかないと思ってます。
無制限一本勝負のデスマッチ試合開始です。

きくじろう: 常連さん; 会議室デビュー日: 2004/09/06; 投稿数: 43

投稿日時: 2005-02-22 18:48

動かないコンピュータに成りかかっているシステムのその後です。

先が薄ぼんやりと見えかかってきたものの予断を許さない状況です。
こつこつと駄目だしをし続けてはや１年弱。

バグの再発や修正による別のバグ発生など、忍耐の要る作業が続いています。
この時点でも単体レベルの不具合も頻発しています。

何度クレームを出しても改善の傾向はありませんので、
最後は、お金で縛るしかもう手は無いと思ってます。

テストの結果を持って来いと言ったこともありましたが、
持ってきてもいいけど、トンでもない枚数ですよ、と言って誤魔化していたものの、
あれで持って来いといったら本当に持ってきたのかどうか？
チェックも出来ないゴミの山を貰っても困るのですが、
再請求してみようかなとも思っています。

「とり合えず出すだけは出して判子もらわんと、テストは相手にやらせたれや」
「うまいこと言ってやらすんや。それもＳＥのテクニックやで」
そんな指示が出ているのかもしれません。

発注する会社を間違えたことは分かりきっていることですが、
こんな会社が上場してＳＥと名売った仕事はして欲しくないです。

前にも何方かが仰られたように、
赤字を出した会社は保守で回収しようとする、これは定石でしょう。
今だから言えますが、私も反対側の立場にいましたから経験があります。

しかし、本体部分をまともに作っていないで、期間オーバーで赤字が出たから、
保守で要員を確保して誤魔化そうとする魂胆は大甘です。
既にメンバーの一部は別プロジェクトに投入されているようです。

こんなことを書いているうちに仕事しろやと言われそうですね。

ちょっと感情的になってしまいましたのでこの辺にします。
悪質な会社を糾弾するために、また後日報告をしたいと思います。

未記入: ぬし; 会議室デビュー日: 2004/09/17; 投稿数: 667

投稿日時: 2005-02-22 20:18

引用:
悪質な会社を糾弾するために、また後日報告をしたいと思います。

そろそろ、実名を晒して欲しいんだが…。被害者を増やさないためにも。

因数分解: ベテラン; 会議室デビュー日: 2004/10/13; 投稿数: 53; お住まい・勤務地: 稲の原

投稿日時: 2005-02-23 10:31

引用:
きくじろうさんの書き込み (2005-02-22 18:48) より: 何度クレームを出しても改善の傾向はありませんので、最後は、お金で縛るしかもう手は無いと思ってます。・・・ちょっと感情的になってしまいましたのでこの辺にします。悪質な会社を糾弾するために、また後日報告をしたいと思います。

以前にプログラムの検収テストをした経験があるんですが、
読んでいてその時の事を思い出して、もらい泣きしそうなくらいです

コンパイルは通るが実行ボタンをクリックすると落ちるという、そりゃもう惨憺たる状況でした。
挙句の果てには本稼動の日は社員旅行で誰も居ないという無責任ぶり。
案の定トラブル対応でその日から１ヶ月以上は休み無しの状況でした。
そこは汎用機（ＣＯＢＯＬ）の仕事をメインとしていて、
メンバーはＰＣ（ＶＢ）の仕事を始めて間もない者ばかりのようで、
この『悪質な会社』も同じようなメンバなんだと思います。
汎用機からＰＣに変わってきたメンバはどうもＰＣを軽く見る傾向があるようなので、
それがもろに品質に現れてきます。
改善される兆しもないようなので、早めにお金で縛った方がいいと思います。
それと、テスト仕様書と結果のリストも提出してもらってどんなテストを行ってるのか
検証した方がいいと思います。
くれぐれも、自分に責任が降りかからないように注意してください。

未記入: ぬし; 会議室デビュー日: 2004/09/17; 投稿数: 667

投稿日時: 2005-02-23 12:15

「お金で縛る」ってどういう意味ですか。もしかして、ちゃんと仕事してないのに、さらにお金を上積みしてあげるということですか。

«前のページへ 1|2|3|4|5|6|7|8|9 次のページへ»

ソフトウェアハウスとの付き合い方

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