エビデンスなどの成果物の最適解は現場によって違うよね

SIerの闇・Excelにエビデンス貼付け - Togetterまとめ

こういうのは非常に興味深い話で、同じSIer、同じ元請けのPMだって成果物の定義がバラバラだったりするので、他所さん面白いことやっているなあって思える話題です。

昔、詳細設計でプロマネが成果物定義をろくにやってないと、実働メンバーが苦労するって話*1を書いてましたけど、それと似た話ですね。

まあ、こんなこと書いているとお前のところではどんなんだと言われそうなので、現在の現場で定義している成果物をカンタンに説明します。

なお、保守開発の現場となります。

個々のライブラリ、アプリケーション毎のテストで実行した結果のAPI出力結果や処理ログ、DBダンプのテキスト。

顧客納品物から除外するようにしているので、まあプロマネであるオッサンが確認できる形の証跡であれば良しとする方針です。

話題のEXCELに。ブラウザ出力画面をスクリーンショットをペタばり。

ただし、seleniumをカスタマイズしたものから自動で出力されたスクショを、これまたEXCELに自動で貼り付けるスクリプトでエビデンスを編集。これをJenkinsで自動実行。

リグレッションテストでは、検証自体はブラウザに出力されたhtmlソースを過去の正常結果とdiffを取り、差分を許容できる場所以外での差分有無だけを自動判定させるスクリプトで検証するようにしてます。

seleniumでどうしても自動化できなかった僅かな部分だけ、手作業＋目検を行う形。

結合テストとほとんど同じだけど、テストシナリオなどの都合上、システム運用が絡むのでJenkinsの動きがちょっと違う。

・・・

まあ、ざっとこんな感じです。

ちなみに、EXCELにエビデンスを貼り付けている理由は大したことがなく、

ぐらいの理由なので、ぶっちゃけユーザの会社のPCで見られるものなら、ファイルフォーマットはなんでも良いってのが本音ですね。

スクショエビデンスの目的としては、「顧客への納品物」「マニュアル作成のための資料」「過去バージョンの動作追跡」など、案外使い道は多いものです。

とまあ、こんな感じで成果物を定義しているわけですが、成果物の形をどう定義するか、どうやって作成するかについては大体以下の様な要因があると思ってます。

などなど。

これらの要因によって、適切な形のエビデンス、テスト実施方針が決まるかと思いますので、成果物を決めるプロマネは注意しておいたほうがいいかなと思います。

で、こういった背景を無視して「EXCELエビデンスなんてSIerの闇」なんて言ってもナニイッテンの、で終わってしまう場合もあるため、きちんと背景は抑えておいたほうが良いかなと思います。

ところで、「SIerは自動化ツールを使ってないからおかしい」なんてのをたまに見かけますけど、「受託開発売切、単発ソフト」の現場でテスト自動化なんて行ってたら、あっという間に過剰コストで大赤字です。

オッサンも、ぶっちゃけ保守開発の現場でなければ自動化なんてしなかったし。

状況に応じた最適解は様々なので、あまり自分の視界からだけで語ったりするのはよくないんじゃないかな、と元記事みて思いました。

まあ、オッサンも自分の視界から語っているのでどこまで俯瞰できているかは、微妙なんですけど。

ところで、元記事は「SIerの闇」なんて語っているわけですけど、個人的に感じる本当の闇は別のところにあって。

ぶっちゃけ、テスト自動化など推進していて常々考えさせられるのは「自動化して効率化した作業工数はどこに消えたのか」。

お客からもらうカネは変わらない。けど、テストは自動化した結果、必要となる作業量は減少している。。。

あんまり多くは語れないですが、「誰かの何か」は、きっとどこかの闇に消えたのでしょう。

ところで、この手の話で気になるのがあまりにも目的意識が共有されてない件。

元のまとめのツイートしている人の現場でも、多分、その現場のPMなりの事情と目的はありそうな気がしますが、その目的や事情が憶測で語られ、目の前の現象だけが問題と語られる点。

目的意識をメンバーで共有するのもプロマネの仕事だったりするので、そういった共有感を高められるようなチームマネジメントすることが、このSIerの闇をはらう一番の処方薬な気がします。

以上