SESクソ体験（3） 事業報告書作成システム再構築

2004年04月のこと、僕が初めてVB6.0に触れたプロジェクトです。
某保険会社の社内システムで、案件の切れ間に「誰かやっといてよ」みたいな感じでめちゃくちゃ無計画に依頼された案件です。
「事業報告書作成システム」って言ったら聞こえはいいですけど、気の狂った計算式がゴテゴテ入ったExcelフォーマットでした。計算式が破壊されたり、印刷時に勝手にフォーマットを変更する社員がいたり、Excelでの運用がストレスになっていたため、Windowsアプリケーションで作り直すことが求められました。

嘘を吐いてでも案件に潜り込ませる

当時は「プログラムが書ける」というだけで仕事がありました（開発環境が育った昨今は、プログラムはかけて当たり前、それにより何を表現できるかが価値になっていると思います）。VBを使ってアプリケーションが作れるというだけで、仕事が発生しました。

僕はといえばCOBOLしか組めないので、「誰がやるんだろうなーあれ」って横目で見てました。その現場にはVBを扱える人間がいなかったので、みんなパスしました。
そうしたら、同じ会社から来ている上司が「こういう時に、『自分がやります』って手を挙げんだよ」と圧をかけてきました。でも、自分はVBなんて触ったことないです、と抵抗するも「当たり前だろ最初は誰だって初めてだ。選んでたら仕事ねーぞ」と脅され、無理矢理やらされることになりました。
なお、 誇張でなく、部下に対してこういう口の利き方するのが普通の会社でした。

案件に入る前に、PM（プロジェクトマネージャー）と面談をしました。当たり前ですが、案件を受注してから「やっぱりできませんでした」では、会社間の問題になるからです。
別案件でそれなりにうまくやっていたので、PMは僕のことを知っていました。「清瀬君はVBも組めるんだー、よろしくねー」といった感じ。僕が触ったこともないですと言う前に、上司が「案件を受注するのは初めてですが、社内OJTでシステムを作ってますので」と息をするように嘘を吐きました。

これがSES会社のクソなところです。
SES会社は、ハッタリを利かせてでも社員を現場に出します。
これを読んでいる人は「もうあきたよ」というであろう内容ですが、一応仕組みを説明すると、以下のようになっています。

①SES会社は、社員を雇う（月給制）
②SES会社は、社員の労働力を企業に提供する（案件ごとに月単価が異なる）
③企業は、SES会社に報酬を支払う
④SES会社は、③の報酬からいくらか差っ引いて、社員に月給を払う

社員が現場に出なかったら、会社は収益がないのに給料だけ払うことになります。社内で待機している限り赤字社員ですので、SES営業はなりふり構いません。金のためなら社員が苦しむことをわかっていながら、嘘を吐いてでも売り飛ばします。

お気付きの人はSES業界にどっぷりの人だと思いますが、このケースでは上司（現場に出ているSE）がSES営業を兼ねているんですよね。当時は上司が憎くて殺してやろうかと思ってましたが、上司も相当無理をしていたのではないでしょうか。そのことに僕が気付くのは、10年以上の後、自分が現場営業をさせられるようになってからです。

１分でわかるプロジェクト要求

「この…Excelシートがあるじゃないですか？これと同じものをVBで出せるようにしてもらえればいいから。期間は3ヶ月でできたらなって思うんだけど、いける？」

PMの説明はそれだけでした。
本音としては「わからねえよ」でしたが、となりで上司が無言でじっと見てきているのは「余計なこと言うんじゃねーぞ」という圧です。
当時、まともなプロジェクトなんかやったことがない新米でした。年がら年中クソコードを読んで、コピペして、縄張り争いをしていただけです。無茶苦茶なのはわかるけど、具体的にどう無茶苦茶なのかもわからないし、できるともできないとも全く判断がつかない。

無茶苦茶ポイント①
技術的な懸念として、VBを組んだことのある人間がいない。僕自身組んだこともなければ、上司もやったことがなく、なんなら客先にもいない。じゃあこれで良い、これでは良くない、という判断は誰が下すのか。
無茶苦茶ポイント②
メンバーが一人なんですよ。小規模プロジェクトとはいえ、3ヶ月も続くなら、ただプログラムを組めばいいってわけではありません。そりゃ1〜2個タスクやって終わるならいいですが、ざっと考えても計画、ツール選定、リソース管理、進捗管理、成果物管理、報告と、やることは多岐に渡ります。それをエンジニア1人に全部やれという時点で異常です。少なくともPL（プロジェクトリーダー）1人つけて、要所でレビューしないと、やってることが正しいのか間違ってるのか、コントロールを失います。

今なら「誰がレビューしますか」「有料のツールが必要となったら使えるのですか」「報告は誰にするんでしょうか」と色々質問すると思いますが、当時は今以上に未熟でした。しかも上司が「とにかくやれ」と睨んでいますので、やらないという選択肢もありません。
うすうす、この仕事なんかおかしくねーか？と思っていましたが、上司もおかしかったし、僕も実力不足だったし、要求元である某保険会社PMもまるでダメだと今ならハッキリわかります。登場人物全員がクソだったと言って過言ではありません。そしてこの案件が特別にクソだったわけではなく、SESではあるあるクソ現象です。

やり切った自分を褒めてやりたい

まずVB自体の勉強をしました。すべて独学です。ネットで調べて出てきたサンプルを切り貼りしてなんとかしました。COBOL出身なので、グローバル変数だらけのクソプログラムだったに違いありません。
SQL Server（関係データベース）も初めて触りました。上司に聞いても「俺はVSAMしか使ったことねえから知らねえ。それを調べるのがお前の仕事だろ」と突っ撥ねられました。基本的なCRUDだけならすぐ覚えましたが、インデックスも考慮してないクソ設計だったに違いありません。
レポートをどのように出力するのかわからず、その調査も僕がやりました。当時、Crystal ReportsとActiveReportsの二択でしたが、試用した結果ActiveReportsの方がいいと判断し、導入してもらいました。もうちょっと慎重に決めていいと思ったんですが、PMが「じゃあそっちにしたら？有料なの？あっそ」って言ってました。

計画もなにもあったもんじゃないので、残業を増やして前倒しで進めてました。テストは、Excelと自作プログラムとで同じ入力をし、印刷物を出力し、同じであることを確認しました。当時の実力でテストが網羅できていたとは到底思えませんが、PMもたぶんわかんなかったんでしょうね、なんとなくで受け入れテストOKになりました。
ActiveReportsの実力がすごかったのか、見た目は綺麗だったんですよ。こ、これが新しい事業報告書作成システムか〜！って感動してましたけど、出てる内容はExcelと一緒ですからね。違いと言えば、ページ送り機能と、ログイン機能が足されたくらい。よく考えたら費用対効果が酷いんですが、要求元が満足してるならそれでいいです。僕は。

これは要求定義の失敗ではないか

この記事書いてて思いましたが、これは要求定義に失敗している例だと思いました。

元はと言えば、計算式が破壊されたり、印刷時に勝手にフォーマットを変更する社員がいたり、それが問題だったわけです。Excelにはシートの保護機能がありますので、それを駆使して「想定外の使われ方」を防ぐだけでよかった。ログイン機能だって、Excelにはパスワード機能がありますので、それを使えば十分だったのではと思います。

まず、きっちり「何に困っている」か問題点をハッキリさせる。

・計算式が破壊される
・フォーマットを変更される
・閲覧権限がない人が閲覧できてしまう

これを裏返すと、要求になります。

・計算式を破壊できないようにしたい
・フォーマットを変更できないようにしたい
・閲覧権限がない人が閲覧できないようにしたい

もしここに、「VB6.0で作成したい。今後VB6.0での開発が活発になるため、社内システム移行をパイロットプロジェクトとして、技術的懸念を洗い出したい。」といった要求が加わるなら、VBで作成するのは正しかったと思います。
しかし、単に上記の問題を解決するだけであれば、以下で十分だと思います。

・Excelの「シートの保護」機能を利用し、計算式やフォーマットを変更できないようにする
・閲覧権限がある人だけが参照できるよう、運用フローを整備する

これであれば設計2日、実装0.5日、運用フローの整備はレビューを含めて5日程度。バッファを見込んでも10日程度で終結するプロジェクトだったと思います。

そんなことを言おうものならSES営業が「3ヶ月分の仕事を0.5ヶ月に縮めるようなことを自分で言い出してどうすんだ馬鹿野郎」と責めてくるので、SESってクソだなって思います。