最近一部で話題になっている「SEがテスト工程で画面のスクリーンショットをExcelに延々と貼り続ける作業」について、実際にスクショ貼り職人を経験した自分としては、何か残しておかねばと思い、この記事を書きます。
自分はSEでしたが、うつ病でもうすぐ2度目の休職に入ります。Excelスクショ職人を経験しています。そんな自分が、「Excelスクショに対して疑問を抱いている方」と「今現在Excelスクショ職人な方」へ、お願いと励ましの言葉を述べさせていただきたいと思います。
【参考】
そもそもExcelスクショとは何なのか
あるシステムを開発したら、必ずテスト工程があります。プロジェクトによっては、全くユーザーインタフェースがない場合もあるかもしれませんが、ここでは何かしら画面を操作する、例えば銀行のATMの画面を思い浮かべてください。
このような画面があったとき、例えば以下のようなテストケースが作られます。
- 1を押したら右の欄に「1」と表示される
- 2を押したら（ｒｙ
- ：
- 訂正を押したら1文字消える
- 確認を押した際に、
- 1桁しか入力されていなかったら「4桁で入力してください」として画面は遷移しない
- 2桁しか（ｒｙ
- 4桁入力されていて、内容が正しければ次の画面へ遷移する
- 〃内容が正しくなければ、「暗証番号が違います」と表示して画面は遷移しない
※これは笑い話なのですが、某FF11では初期の頃以下のようなバグ（設定ミス？）を出したことがあります
アタックモーションとか1回試せば分かるのに、なぜリリースされてしまったのか理解に苦しみます。売値より買値が高いなんてもってのほか。
所詮ゲームなので「ミスったので直しておくねてへぺろ(・ω<)」で済むのかもしれませんが、あまりにザルですね┐(´∀｀)┌
ここで強調したいのは、「問題発生時に社会的に大きな影響を与えてしまう」ようなシステムであるほど、古くからの慣習からExcelスクショ（最終的には印刷して紙で納品）が要求されるプロジェクトである事が多いのではないかということです。ここではそのようなプロジェクトを「Excelスクショプロジェクト」と呼ぶことにします。
さて、上のテストを「確かにやりました」と証明するために、画面のスクリーンショットを撮ります。それをExcelに貼り付けて体裁を整えた（お客さんの定形フォーマットや、テストケース番号、確認欄、スクショの該当箇所に赤線を引いたりなど）後、エビデンスとして残します。
最終的に、プログラムのソースコードや設計書と合わせて納品されます。Excelスクショプロジェクトだと大抵は「印刷して納品」します。印刷された各ページには、プロジェクトマネージャ、納品先のマネージャ、さらにその上の人・・・といった印鑑が押されたりします。
Excelスクショに対して疑問を抱いている方へ
問題を分解してみましょう- なぜExcelなのか
- なぜスクショなのか
- なぜ延々と作業することになるのか（何百枚と）
- なぜそんな無駄なことをするのか
- 元職人からのお願い
1．なぜExcelなのか
A.選ばれたのはExcelでした。Excelといえば「Excel方眼紙問題」というのもありますが、原因は近いと思っています。
上記の「スクリーンショットを貼って体裁を整えて印刷する」作業をするソフトウェアを以下のリストから選んでくださいと言われたら、どれを使いますか？
- Word
- Excel
- PowerPoint
- ワードパッド（Windows標準の）
なぜリストが4つなのかという問いに対しては、SEに割り当てられるPCにそれしか入っていないから、そして勝手にソフトを入れられないからです。
PCを大量導入する際、とりあえずMicrosoftのOfficeはライセンス購入すると思います。そうするとWord/Excel/PowerPointは入っています。これ以外にソフトを入れようとするとお金がかかります。
フリーソフトでもっといいのがあるよ！というご意見もあるかもしれませんが、特にExcelスクショプロジェクトでは「サポート」が問題になります。業務利用に耐えうるか、ファイル形式がずっとサポートされるかどうか、などです。（今だとLibreOfficeとかありますが・・・）
また、そもそも開発環境（開発用PC）がインターネットから隔離されていたり、PC監視ソフトが導入されていたりして勝手にソフトを入れることができません。
結論としては「使いたくてExcelを使っているわけではなく、限られた環境で最も適したソフトを探したら・・・選ばれたのはExcelでした。」ということです。（※個人の意見ですが、それほど外してないのではと思います。）
2．なぜスクショなのか
A.テストを確実に行ったという証明を残すためテスト仕様書の各テストケースの欄に「OK」と書くだけで済むのであれば必要ありません。しかし、運用に入ってから問題が発覚したときに、「本当にやったのか？」という話になります。
テストを行った証明としてスクリーンショットを撮るのです。そして、お客さんもそれを確認します。
画面入力を伴うシステムの場合、「こういう操作をしたらこうなる」という動作を仕様として設計します。仕様通り動くことを証明するには、実際に操作を行った時の画面が残っていないといけません。何か問題が起きたときには、ちゃんとテストが行われていたかどうか、設計時に想定されていた動作なのか等、説明が求められます。
「そんなのさっさと直せばいいじゃない」と思われるかもしれません。しかし、Excelスクショプロジェクトでは通用しません。お客さん側も、システム部門から運用部門、さらには実際にシステムを使うエンドユーザーに対して説明を付けなければいけないので、はっきり分かる形での説明ができないといけないのです。
3．なぜ延々と作業することになるのか（何百枚と）
A.入力項目、画面数の数だけパターンが増えていくため上のATMの例を取っても、ボタンが12個、桁数が4桁、確認ボタンを押した次の画面（この場合は別の金額入力画面に移るか、エラーで戻ってくるかの2パターン）あるので、やろうと思えば全部掛けた枚数は必要になります。
しかも、各テストケースで入力前と後で2枚ずつ必要になります。
項目数が多いほど、画面数が多いほど、その組み合わせは膨大になります。そのため、規模によっては恐ろしい数のスクショ枚数になります。
また、バグが見つかった場合、その画面のテストケースはやり直しになります。スクショも取り直しです。
設計や開発と違ってそれほどスキルを必要としないため、システム開発未経験の人や、入社したばかりの新人さんが担当したりします。
4．なぜそんな無駄なことをやるのか
「そんな作業は無駄だ！」と思われる方も多いでしょう。自分もスクショ職人をやっていたときはそう思ったこともあります。
スクショが重要になるのは運用フェーズ以降です。
運用後に致命的なバグが見つかった場合、大変な騒ぎになります。Excelスクショプロジェクトでは「申し訳ありません、直します」では済みません。
まず、即座に原因を突き止め、影響範囲を特定し、報告書を作成して報告します（その日中に）。
このとき、発生した直接的な原因、真の原因（？）、再発防止策も報告しなければなりません。（ちなみに真の原因の最終手段は「当時設計を担当したSEのスキル不足」でした・・・もう居ないので追求できませんという）
並行して、横断的調査も必要になります。バグが画面にあるなら発生した画面の他のテストケースに問題は無いか、特定のデータベースのテーブルを触っているロジックなら、同じテーブルを触っている他の部分に問題は無いか、等です。
このとき、スクショがあれば「他は問題ありません！」と断言できます。（ちなみに、データベースを更新するようなボタン操作だったら、画面と共にテーブルをSELECTした内容をスクショに取ったりもします・・・）
これは自分の経験ですが、参加していたプロジェクトは複数のサブシステムを別々の会社が担当していました。あるとき、特定のサブシステムで問題が発生したときに、1枚のスクショが自分たちのサブシステムに不具合がないことを証明したことがあります。不具合を起こした会社の方々はもちろん遅くまで残って対応していました・・・。
従って、結局のところ「SE自身を守るため」にスクショを残しているとも言え、決して無駄なことをしているわけではありません。
5．元職人からのお願い
Excelスクショは、より社会的に重要で巨大なシステムほど、古くからの慣習で残ってしまっている問題と思います。画面テストを効率よく行えるソリューションもあるかとは思いますが、お客さん（さらにその先のエンドユーザー）に理解してもらえるかは難しいところです。
しかし、無駄なことをしているわけではないので、「そんなの無駄だよ」とか「何の意味があるの？」とか言うのは止めてあげてください。嫌でもやらなきゃいけないからやっているわけなので、ごちゃごちゃ言っても本人が辛くなるだけです。
それよりは、このあと職人へのメッセージにも書きますが、体調を気遣ってあげてください。そして社会には逃げ道も用意されていることを教えてあげてください。
今現在Excelスクショ職人な方へ
同じように分解してお話ししていきます。- なぜExcelなのか
- なぜスクショが必要なのか
- スクショを撮りつつも成長するために
- 体調が悪くなったら（重要）
1．なぜExcelなのか
これは上で書いたことと同じなのですが、同じ作業を「割り当てられたPCに入っている別のをソフトを使ってやってもいいよ」と言われた場合、より良い選択肢はあるでしょうか。自分が前所属していたプロジェクトでは、開発用PCにはMicrosoftOffice以外は事前に申請して承認されたソフトウェアしか入っていませんでした。もちろん勝手にソフトを入れることは禁止されていました。
ちょっとした報告書、障害の説明資料などもExcelで作ってました。（ちなみに上のATMの画面はExcelで作りました(；´∀｀)
2．なぜスクショが必要なのか
撮っているときは意味も重要度も分からないと思いますが、フェーズが進んでいく毎に重要度が増していきます。テストフェーズも、規模が大きければ単体テスト、結合テスト、システムテスト、オペレーションテスト、ユーザー受け入れテストなど段階が増えます。後のフェーズで見つかったバグほど、対応が大変になります。特にバグが残っていた理由の説明、影響範囲の調査です。
スクショ1枚が、影響範囲を一気に狭めることもあります。
もしかしたらその時にはプロジェクトを外れてしまっているかも知れませんが、後に残った人達のためにも、しっかりテストを行ってください。スクショを撮っても、間違ったまま提出してしまっては意味がありません（お客さんもチェックしますが）。
3．スクショを撮りつつも成長するために
「こんなことばっかり毎日やってて意味あるのだろうか・・・」と思う方もいらっしゃるでしょう。もちろんただスクショ貼ってるだけではプログラミングスキルも付きません。
とはいえ、目の前の作業から逃げられるわけではない・・・という方へ、成長するための鍵を置いておきます。
- 小さな違いに気づく意識を養う
- バグが見つかった場合にチケット（問題管理表とか）を追ってどんな原因でそのバグが入ったのかを知る
- Excelの使い方を学ぶ
ぱっと見で明らかなバグはすぐ気づくでしょうが、中にはよーく気をつけて見ていないと気づかないバグもあったりします（たくさんある項目のうち1つだけフォントが小さいとか）。そういう小さな違いに気づく意識を養ってください。
これは後にレビューする側に回ったときに生きてきます。
また、上にも書きましたがバグは発見が遅れるほど対応が大変になります。同じ事の繰り返しはしんどいと思いますが、確認すべきところはしっかりチェックしてください。そして、30分に1度は一息入れる方が集中力が落ちにくくなります。（→ポモドーロテクニック）
■バグが見つかった場合にチケット（問題管理表とか）を追ってどんな原因でそのバグが入ったのかを知る
バグがなぜ生まれたかを追求するのは非常に勉強になります。どういうプログラムミスだったのかを知り、どのように対応したか、どうすべきだったのかを知る事は、エンジニアのスキルの蓄積として非常に重要です。参考書や資格試験では得ることのできない部分です。
スケジュールが厳しい場合はそこまで手が回らないかも知れませんが、自分の担当部分でバグが発生した場合は追いやすいのでは無いかと思います。できたらメモなどを残しておき、後で見返せるようにしておくと良いです。
■Excelの使い方を学ぶ
もうExcelを触るのも嫌かも知れませんが、細かな技を覚えておくと後々役に立ちます。ショートカットや数式はもちろん、VBAも使えるようになっておくと運用の時にツールとか作って楽になったりします。
とりあえずCtrl+1でプロパティが出ることだけでも覚えておくと便利です。また、スクショを貼るときに何かしらの加工（縮小や枠線入れなど）を行っている場合は、マクロを記録する機能を使うと楽になれるかも知れません。
集計や統計の関数を使ってログの解析をしたり、データベースのデータを分析したりすることもできます。
4．体調が悪くなったら
同じ事の繰り返しで精神的に辛くなったら注意してください。どうしても自分に合わない環境というのもあります。そして精神的に無理を重ねると人は壊れます。自分は壊れました。「スケジュールが厳しいからがんばらないと」
「みんながんばってるから自分もやらないと」
「新人だから甘えないでやらないと」
こういう気持ちで自分を追い詰めすぎてはいけません。
あまりに辛かったら、上司に相談しましょう。受け入れてくれなかったらその上の人、会社によってはメンタル面の相談を受け付ける窓口があったりするので、とにかく相談してください。
睡眠に影響が出たら（眠れなくなったり、夜中に何度も起きてしまったり、日中眠くなったり）要注意です。
吐き気や頭痛と言った、身体面での不調が出てきたらもう危ないです。すぐにその場を離れるべきです。
社内で相談できるところがなかったら、社外へ助けを求めて下さい。厚生労働省が色々な相談窓口をまとめたポータルサイトを用意しています。
1人で悩むのではなく、まずは相談してみてください。無理を重ねた期間が長いほど、復帰にも時間がかかります。
まとめ：いのちだいじに
でも体を壊してまで行う必要はありません。システム開発も色々な物があり、障害発生時に報告書を作るよりもちゃっちゃと修正してリリースするという現場もあります。そういうシステムではスクショは1枚も撮りません。
誰かがやらねばならないのですが、必ずしも自分である必要はありません。
2014/08/05追記
蛇足かもしれませんが、いただいたコメントに対しての返信エントリーを書きました。
2014/08/12追記
解決策を考えて記事にしてくださった方が現れました。
猫とガジェットが好きなJava屋さんです。うつ病で休職後退職し、1年半の休養後に社会復帰。・・・が、いろいろあって再び退職。さらに1年休職の後に復帰して、なんとかSE続けてます。茶トラのすずと一緒に生活していましたが、2014年9月4日に亡くなって1人に。
