書評リレーやるよ。とりあえず言い出しっぺということで第1回。
「ウチの会社の業務システムはなぜこんなに使えないの？」と嘆いている人のために、そのシステムがいったいどのような行程を経て作られるか、あるいはシステム開発に関わる「SE」とはいったいどんな仕事をしているかに視点をあて、システム開発で陥りがちな失敗を解説した本。ただし、全ページにわたってたっぷりと皮肉と風刺が含まれているのでSEで洒落の通じない人は読まないように。「SE」と呼ばれて心当たりのある私が読んだ分には終始苦笑の連続だった。なかなかに笑いのセンスが光った希有な本だ。
内容は第1章から第3章まで分かれており、第1章ではそもそも「SE」とはどのような人なのか、どんな風に仕事をしているかについて説明している。まずSEを開発系と運用系に分け、開発系のポジションを上位のシステムコンサルタント、プロジェクトマネージャから下位に位置するプログラマまで順に紹介。SEとは顧客の要求をかみ砕くポジション、プログラマはかみ砕いたものを動くようにするポジションというふうに大ざっぱに説明している。
そして特筆すべきは、システムに関わるポジション同士の力関係にまで言及していることだ。業務オペレータは運用系SEにとって神だ。彼らは朝の4時だってシステム問い合わせと称して人をたたき起こせる存在だ。営業にとって顧客は神だ。顧客が望むなら自社にない技術だって実現させることを約束する…たとえSEが何と言おうとも。SEにとってプログラマは油断のならない存在だ。設計通りに作らない。プログラマにとってSEは油断のならない存在だ。自分のクリエイティブ性を発揮させてくれない。運用系SEにとって開発系SEは油断のならない存在だ。バグを仕込むだけ仕込んでおいてカットオーバーしたらトンズラする。もはや苦笑するしかない。まったくその通りだ。
さらに、運用系SEは開発系SEより評価されにくいという構造的問題（何事も起きないことが成果になるのだから当然だ）や、人材不足のプログラマを甘い言葉で釣っていく業界構造が招いた悲劇まで解説している。そして最後にこう締めている。
本書で想定している主読者である顧客の方々は、IT企業の構成員たちはこんなに壊れているのか、と不安に思われたかもしれない。実際にはこれ以上に壊れているので、本書は準備運動のお手伝いをしている程度である。
だが、彼らは壊れてはいるものの基本的には善良であり、付き合い方さえ間違えなければ得難いビジネスパートナーになってくれるだろう。
第2章ではシステム開発時の方法論と、実際に発注する際の手順、開発会社の選定方法や要件の伝え方、見積もりの評価や検収時の注意点などについて解説している。顧客の立場として最低限知っておくべきことはだいたい書かれてある。そして注目すべきは賢そうな横文字単語が出てきた場合についても少し説明していることだ。たとえば「オブジェクト指向で作っているので、高機能です」としたり顔でアピールする営業へのツッコミポイントは、オブジェクト指向は開発時のソース利用効率を上げるための方法であり、機能とは関係ないということ。そして、あくまで開発側の効率を上げるためのものなのでユーザには関係がないということだ。ということで、次のように切り返すことを提案している。「使い回し指向で作っていただいているわけですから、構築費用はお安くなりますよね？」。こう言ったところでおそらく効果はないだろうが、少なくともだまされないためにある程度の知識は持っておくことを説いている。
そして第3章は傑作だ。ケーススタディとして『web5.0』（！）的技術を駆使したシステムを開発して崩壊するまでの過程を物語風に書いている。「Web5.0！ いったいどの前頭葉を強打すればそのような言葉がまろび出てくるのか」という暴走営業に対するSEのツッコミや、「今回の案件などどうでもよいのだ」と部下に言い放つ顧客企業のCIOなど、もはやケーススタディというよりただの喜劇台本にしか見えない。しかしここまでいかなくてもシステム開発を遠くから冷静に眺めてみると、全員が協力してコントを演じているようにしか見えないから不思議だ。
システム開発での失敗事例や注意点について解説した本は数あるが、この本は初めてシステム発注する顧客に向けて最初の一歩を簡単に解説したよい本だ。しかし繰り返すが、SEの立場として読むならばひたすら皮肉られているだけで目新しい発見もないので苦笑するしかない。ギャグだと割り切って読むぶんには良いかも知れない。
最後に、よく知られたシステム開発のジョークを一つ紹介する。
自分の関わるシステムがこうならないよう祈るばかりだ。…いや、十中八九はこうなるんだが。
