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

銀行カルチャー

銀行カルチャーの特徴は主に3つあります。
①統制（命令は絶対）
②失敗は許されない
③人事（左遷の恐怖、人事部門がもつ権限の強さは事業会社の比ではない）
その結果、一事不再理が暗黙のルールとして機能するのです。

今回のシステム導入に当てはめると、
・私のボスは役員にシステム導入を上申し、役員は導入の決定を下した
・その瞬間に、ボスのなかでシステム導入は何があっても成功させるべき命令に変化した
・エラーが頻発し、どうやらシステム自体は失敗のようだとボスは気付いた
・しかしシステム導入は必ず成功させなければならない

➡どうすればいい？成功条件を変えればいい！
➡成功条件を「為替ポジションのリアルタイム管理」から「〇月〇日リリース」へと再設定した

私がふつうの事業会社でしか働いたことがなかったら、そんなことある？！と頭を傾げると思います。
当時の同僚でさえ、銀行カルチャーの存在に気付いた人はごく僅かだったでしょう。

そのなかでベンダーD社は、長きにわたるメガバンクとの付き合いのなかで銀行カルチャーの存在に気付き、対処方法を持っていました。
金融業務や為替業務を理解するよりも、銀行カルチャーへの対処方法を学び実践することが自分たちのリスクヘッジになることを、彼らはよく解っていました。

得たもの

受入テスト以降、何度も夢でうなされたシステム導入ですが、学んだこともありました。この経験は今でも、原体験として私の仕事に影響を与えています。

システムは魔法の箱じゃない

要件定義していないものは実装できません。これはビジネスサイドの人が忘れがちな視点です。

「普段の業務はこの手順で進めていて、その時ついでにあのチェックもしている。元の業務フローは別々なんだけど、使うデータが一緒だから、現場の工夫で同一タイミングで実施している。」
「ベテランはプルダウンから選択する、ということはしていない。01米ドル、02豪ドルという選択項目の番号と内容の組み合わせを覚えていて、01と入力し米ドルを選択している。」

私たちビジネスサイドの人間は、普段おこなっている現場の工夫も当然システムに実装されるだろう、と無意識のうちに考えがちです。
システム導入プロジェクトのPMが対象業務に明るく、ビジネスとシステムの的確な橋渡しをしてくれるなら良いですが、都合の良いことを期待するよりも、自分たちでコントロールする努力をしたほうが成功に近づけます。

自分たちでコントロールする努力のひとつが要件定義だと、私は考えています。「あとで定義する」という言葉がならんでいた今回の要件定義書は、目的地に向かうための舵取りを放棄していることと同義です。

失敗を認めて、撤退する勇気を持つ

言うは易く行うは難し、とくに銀行カルチャーのなかにあっては、そうだと思います。
それでも、ロスカット・ルールに抵触したときは心理的抵抗を振り払って行動することが、後々の起死回生にとって必要であることを、私はこの経験と本業のディーリングから学びました。

システム導入から少し経って、オルビス炎上プロジェクトの記事を見つけたときは、オルビスの決断に感動を覚えました。

炎上した「20億円プロジェクト」、なぜオルビスは火を消せたのか