1_システム≠魔法の箱_その1

当時、為替ディーラーだった私が、システム導入のデスマーチを経験したお話です。米国雇用統計に一喜一憂する職業の私が、ライトノベル『なれる！SE』7巻みたいな事態を現実世界で経験するとは、予想もしていませんでしたが。

何をしたか

為替ポジション管理用のシステム導入が決まってから、ユーザー受入テストでデスマーチを経験し、後始末をしました。ちなみにシステムは開発ではなく、パッケージをカスタマイズしたものでした。

私の所属した部署がシステム導入で手にしたかった成果は、為替ポジションのリアルタイム管理を実現することでした。自社の既存システムは為替管理に対応していなかったため、Excelでの手動管理を余儀なくされていたのです。

波風立たない相場なら、そんな管理手法でも良かったかもしれません。しかし当時は、黒田バズーカが放たれたり、地政学的リスクが顕在化したりと、ボラティリティが高くディーラーにとっては手応えのある相場でした。
その最中でリアルタイムに期待損益を出せないことは、ディーラーにとっても会社にとってもリスクでした。
そうした背景があって、システム導入が決定されたのです。

ベンダーはコンペで決まりました。コンペとは言っても、自社と付き合いの深いところになるんだろうなと予想していましたが、なんと参加ベンダー各社の半値で見積りを出してきたところが現れたのです。
パッケージシステムだけど改修を加えればリアルタイム管理が実現できる、大手金融機関で導入実績もある、という触れ込みでした。

安価に成果を得られるならと、ベンダーD社に発注することになりました。

導入の結果、どうなったか

• デスマーチが発生し、結果的にチームのメンバークラスは全員退職しました。

• システムエラー対応にリソースが割かれ、本来バリューを出すべき業務の質が悪化しました。

• 業務改善を実施して残業時間を1人あたり2時間削減したのに、エラー対応でその成果が帳消しになりました。

• 従来のExcel管理が残り、システムと二重管理の状態になりました。

私はユーザー受入テストから関与しましたが、エラーが頻発し、ベンダーD社も原因特定に数日を要する、という事態がリリース前日まで繰り返されました。

D社は下請け会社にシステム改修を丸投げしており、PM（プロジェクトマネージャー）はまだ駆け出し、PMも下請け会社も金融や為替の知見が不足している。システムは既にブラックボックス化していました。
私はこのとき人生で初めて要件定義書を読みましたが、内容は「後に定義する」のオンパレードでした。
システムトラブル時の対応も通常のサービス・レベル・アグリーメントであれば、〇時間以内に対応するといった記載があるところ、本件においては明確な定めがなく、顧客（私の所属企業）側で代替対応を実施する、データのバックアップも顧客側で実施するといった内容でした。

これが安価な見積りの理由だったんだ！と、そのとき理解しました。そして私たちの業務時間に占めるシステムエラー対応の割合が、急激に増えていきます。

システムが算出するポジション金額は、はたして正しいのだろうか？度重なるエラーでシステム自体が信用できなくなり、従来の管理用Excelで算出した金額と答え合わせをするため残業が増えていく日々。
嫌な予感は当たり、システムの計算ロジックが間違っていたことがリリース直前に判明しました。

計算ロジックの修正が継続中にも関わらず、システムは予定通りのスケジュールでリリースされました。
そしてリリースで事態はさらに悪化しました。ひとつの部署としては目立つ金額の予算を投じて鳴り物入りで導入したシステムです。そのシステムが算出する数値が間違っているなんて許されるわけがありません。

計算ロジックの修正が終わらないなか、私たちは従来の管理用Excelで算出した数値を正として、システムがそれと同じ結果を導き出せるようインプットデータに修正を加えてシステムへ取り込んでいました。
一度で成功することは稀で、システム算出結果を見ながら複数回にわたってインプットデータを修正する必要がありました。
まるでダムの水を柄杓ですくうような作業です。

ディーラーなのに、ディーリングよりも、マーケットの分析よりも、システムのお守りに時間と精神力と体力を優先的に投入せざるを得ない日々でした。
結局、手にしたかった成果「為替ポジションのリアルタイム管理」は実現せず、私たちに残ったのはシステムとExcelの二重管理でした。

ふつうの企業であれば、リリース時期の見直しやシステム導入中止の選択肢があったのだと思います。ところが私がいたのは、銀行系証券会社。それも銀行カルチャーの浸透が急速に進んでいた時期でした。

続きは、次回。