客先、ってもエンドユーザーとの間に入っている企業から、弊社のバグ修正結果検証を行うので説明せよとの指示が前からずーっと出ている。検証をするなら「開発サイドとは違う視点で」彼らに再検証してもらうのがベストなのだが、この人達はそれはやりたくないらしい。結果のレビューだけをやりたいそうな。というわけで説明資料を出して説明するわけだが、その資料が狂ってる。
- 該当案件のデータをDBから引っこ抜いて出せ。
- 出すには(開発を担当する、ウチが作成した)UNIX上で動くダンプツールを使え。
- その他のダンプ結果、たとえばエクセルに吐き出したものとかは「容易に修正できるから」ダメ。テキストファイルにしろ。
- ダンプ結果は、必要なところだけ提示すればいい。
- ダンプは紙に出せ。
- ダンプのカラム名は日本語で出せ。
- ダンプの検証対象に該当するところは蛍光ペンと付箋ですぐ判るようにしろ。
え?「エクセルは容易に修正できるから」という理由で弊社が作った「ダンプツール」が出した「テキストデータ」を出せと?……は?
実はこの議論は9月末にも行っている。それもコレを言ってきた本人に。と、そのときの反応「じゃ、今までの検証は全部ダメってことになるでしょう」。いや、そうじゃなくってさ。どのみち人間の手が入った証跡資料なんてのは信頼性という面では限りなく低くて、そこを保証するための努力を今からやるのであれば、ほかにやることがあるだろう、と。システムの目的はダンプを出す事じゃ無いわけだから。「問題なく動いている」ことは別の面からの観測で十分実証されていて、ダンプなんてエンドユーザーは必要としてないわけですよ。
というかなによりね、テキストファイルってのは、それこそ「エクセルみたいにソフトが無いと開けない」ファイルよりも容易にいじれるわけ。加えて、ダンプツールを作ったのはウチの関係者で、改竄するなら「ダンプツールレベル」で改竄が可能なわけですよ(都合が悪いデータは出さないとか ^^;)。だから、最初に言われた時に、Oracleのエクスポートデータを用意して「検証用データはこれに退避してあります」と言ったら「読めないでしょそれじゃ」と言われて却下。
もうね、素人か?とかそういう以前に「まともなことしゃべろうよ」って感じ。これが会社としての要望として出てくる...あり得ないねぇ。
これが稼働開始後の不具合ごとに実施される。エンドユーザーさんからは「可及的速やかな修正とリリースを」と要望が出ているのに、間に入っている会社への「説明」で、修正作業の3倍くらいの時間を割く。もうね...