SEは「システムを安定的に稼動させる」ために働くのか

SEのミッションが「システムを安定的に稼動させる」と思うようになった理由を忘れないように書いておこう。

「システムを安定的に稼動させる」以外にもSIの仕事をする上で意識することはたくさんある。「業務上の要件を満たす」とか「メンテしやすいシステムを作る」とか「コストを抑える」とか。だけどそれらは数値化しがたかったり、すでに所与のものだったりするからミッションとなりにくい。「コスト」は数値化できるけど、大体のプロジェクトの場合、コストを巡る攻防はシステムを作る前哨戦ですでにあらかた決着がついているし、コストを下げる(自分の取り分が減る)ことにSEとしては特別インセンティブは働かないので、目標にはなりにくい。さらに、今のシステム業界では、コストは「システムの働き」や「品質」に対して払われるのではなく、「期間」や「人数」に対して支払われるのでSEとしてのミッションにはなりにくい。(これはどちらかというとSIのビジネスモデルの話なので今は関係ないけど）。

サービス開始したシステムが「当初の要件を満たしているか？」とか「メンテしやすいか？」という基準は重要なんだけど、例え評価が悪くてもなかなか表に出にくい。数値化が難しいというのもあるし、例えば「要件を満たしているか」という点については、評価する「ユーザー」自体が設計やテストの段階から参画しているわけで、サービス開始してから今更「これじゃ使えねー」とか「金のムダだった」とか言っちゃうと、「私は管理能力がありません」と言ってるようなことになる。並みの銀行マンにはこの台詞はいえない。システム屋から言えば「ユーザーへのリスク転嫁は済んでます。僕らは責められる覚えはありません」ということ。メンテにいたっては保守や追加開発の生産性を客観的に数値化するのは、ほぼ無理。

それに比べて、「トラブルの件数」というのはわかりやすい。「誰に？」というと「経営陣に」わかりやすい。特にこの数年はこの傾向が非常に強まっているように思う。金融庁を頂点として下請けベンダーを最下層とするピラミッド構造が確立された金融業界全体では、ここ数年の統合がらみのトラブルだとか世間の風当たりを受けて「内部のリスク管理しっかりやれ」「特にシステムでボロを出すな」という空気が緊迫感を持って広がっている。経営陣から見るとお上(金融庁)対策は死活問題なので「管理指標としてわかりやすい『トラブルの件数』をもって評価しよう」と。で、システム部門の人々の評価のうち「トラブル件数」という項目の重みがぐんと増してる感じ。
で、底辺をはいつくばるSIerに対しては「トラブル出したらただじゃ済まんぞ、コラァ」みたいな締め付けが強化されていて、半期ごとに新しい「なんとかチェックリスト」とか「システムが必ずクリアすべきなんとか基準」とかが追加されて、現場は踏み絵ばかり踏まされてもう地獄絵図みたいになってる。

その上で、オンラインダウンとかのトラブルでも出そうものなら、間違いなく2,3日徹夜で八つ裂きの上市中引き回しの刑みたいな状況になる。それまで仕掛かり中だったほかの案件も誰かとのMTGも、飲み会の約束もすべてキャンセルして、目の前のトラブルシュートに励む。まあ、それはそれで潔い心地よさがあるんだけど、その後会社の上司をたくさん連れて頭を下げる行脚が続く。そういう経験を体に刷り込むうちに、「やっぱ安定稼動最高！」、生きとし生けるSEよ、我らのミッションは「システムを安定的に稼動させる」ことよ、ということになってしまうのだろう、と思う。うーん、何かうまくかけない。