ここからは私が問題を見つけた背景、順序を書きたいと思います。
まず融資審査のシステムはこれまで書いてきた様に自動化されています。私が居た審査部、審査チームがシステム上の出力として確認できるのは融資申請をした企業・個人についての収支、資産規模等の属性データとそこから付与された格付けそしてその格付けの結果としての融資可否、融資金利です。
審査ではこの出力について審査内容との整合や行内での金利との乖離確認を行うほか、必要に応じてこの結果から最高いくら迄の融資が可能という額の答えを伝えたりします。
ただこれだけ見れば非常に仕事としてはまともに見えます。ですが少し疑ってみると、このシステムの内部処理を全力で信じているという前提があることに気づきます。
そのこと自体は問題ないはずです。むしろそうして全員が信じた前提は受け入れて進めていくのが仕事の当たり前だとも思います。
私もそうしてきました。昔はこれを手で全部やってた、エクセルを何個も作ってたよ。そんなことを引き継ぎの席で言われたこともあります。
異動から数月、部署としては新人ですが30近くの若手ということもあってそれなりに手間のかかる案件に取り掛かる機会がやってきました。
結果的にはこの大きめの案件については格付けが正しいものであったかどうかはわかりません。問題はその後です。
複数回の営業とのやり取りや諸々の確認、実際と同様のシミュレーション結果も行って案件を完結させた後私の業務ペースには少し余裕がありました。
半分くらいはご褒美的に少し割り当てを減らされつつ、自分でも慣れと達成の後の緩みで遅めに仕事をしていました。
そういう微妙な時間が生まれるとどうにも暇というものを感じるようになり、如何にして時間を潰そうかという思考が生まれました。
当時座っていた席が入り口から少し離れ、同時に上司の傍でもない、所謂島の真ん中程度でしたからあからさまにゲームや何かサイトなどを見るというわけにもいかずどうにか仕事ではない暇つぶしを欲していました。
そうして、今思えば狂気的でもあるのですが、せっかくなのだから面倒と言っていた手作業での格付け付与の処理をやってみようと思いました。
これならどうせ隣から見てもエクセルでの作業にしか見えず、真面目な仕事のふりができます。さらに幸いなことに右隣に居たのが新卒窓口配属から次の異動でここにやってきた子だったのです。当然旧システムたるエクセルでの処理など経験しているはずもなく、こちらの画面を見られたところで何か不審ともなりません。
暇つぶしで仕事らしきことをするのは少々もやもやとしましたが、暇つぶしには仕方のないとゆっくりと処理を追いました。
そういう時に、仕事の時間に仕事ではないことをするとどうにも捗ってしまい想像よりは楽に一通りの処理を追うことは出来ました。
そうすると次はそれで実際の審査過程はどうなのかと気になりだすものです。
手元にはいくつかの審査案件もありましたからとりあえずとばかりにシステムとエクセルの両方で処理をしていきます。
そこでふと画面の表示と手元の計算で違うものがありました。
格付け的にはかなり安全なところで、融資金額としてもそう大きくない低リスクと言える案件です。正直ずれたところで大した問題にはならない、システムはこういう面倒なところでちゃんと計算を行っているから今の姿として導入されたのだなと思いました。
そんな違和感にもならないただの記号として見過ごしながら、でも暇つぶしの為に両方の方式で処理を続けたのです。
サボりというには微妙なところですが、こういう時間の潰し方であれば最悪業務理解のためとも言い訳はできるなと考えていました。
こんなことを何日か続けた時でしょうか、また不一致がでました。
今度は先に見つけたものとはもう少し悪い方向のもので、格付けも悪い方向にずれていました。
私も一日に数百とまでの処理はしていないものでしたから、こうすぐに不一致が見つかると少し疑問というか、前のやり方は随分と不安定なのだなと思いました。多分前の時代ではこういうズレるような案件ではさらに別のロジックもしくは手修正も必要だったのではないかと。もう少しどういうやり方で以前はやっていたのですかと質問をしておけばよかったと。
ここでそういう納得で終わればよかったのです。
暇をどうにか何とかしてやろうというくだらない好奇心まがいの悪戯心で、もっと調べ始めました。
営業と審査部署には全社フォルダの中の一部フォルダの閲覧権限として、このシステムに関わるマニュアル、過去の導入関連資料へのアクセス権が付与されています。
普段はマニュアルを見る程度なのですがせっかくだからどういう処理がなされているか見てみたいと思ってしまいました。
ここで自分の背景に書かなかったことについて二点謝罪をさせてください。これまで書いた中では私の大学から銀行員としての情報を書きました。そこに私個人の交友関係はありません。ですが私とて人並み程度には他者と交流をしていました。その中に高校からの友人としてゲーム作りを趣味とする男がいます。
彼とは高校からの同期で、大学は学部こそ違いましたが同じ文系という括りでそれなりに大学生活の中で交流をしていました。
ありがたいことに卒業してからもそれは変わらず、彼の方は先に東京での勤務をしていたため私が異動してからそこそこの頻度で会っていました。
そんな彼の存在があってプログラムというものには、物凄い、何か一般人にとっては超常のものという認識はありませんでした。
本当はありえないことですが、何となく調べながらプログラムを見てどうしてもわからないところは記憶して彼にヒントをもらおうと考えていたくらいです。
そしてもう一つは経理部署でのシステム導入サポートという仕事について。
書き方の問題か、サポートというと納品業者とのやり取りや精算関連といった所謂雑事をイメージします。ただこれはサポートといっただけで実態としてはもう少し違うものです。
システムが導入でき、かつ使い物になるということには少しテストを行う必要があり、これはユーザーテストや受入検証などと言われ略称ではよくUATと呼ばれるとのことです。このUATに関わる部分をやっていました。
経理として実務経験が長いというわけではなかったので、ごく簡単な処理については自分で旧システムと新システムの齟齬が無いことを確認し、複雑な処理だったり近年の制度変更に基づいた面倒な処理などは歴の長い人の助言を得ながら新システムが変な動きを出さないという事実を重ねていく、そのような業務です。
そのような業務経験があったため、この後に出てくるフォルダ群の確認ができました。
ですが正直に書けば、当時そんなことは考えていません。ただそこにどんなフォルダがあるのかという、ただの、気になったというそれだけのことです。死ぬほど長いソースコードの山に一目で退散するようなイメージも持っていました。
とはいえ、フォルダにアクセスしいつも見かけるマニュアルのフォルダとは違う方の、導入時確認という文言だったり日付の入ったフォルダをいくつか開いていくと、議事録、要件定義書、詳細定義書、仕様書、詳細設計書といった文言の並ぶ階層がありました。ここはもっとあったかもしれません。その中に一つUATとアルファベットのフォルダがあって妙な存在感のようなものがありました。
そのフォルダを空けるとさらに単体テストや負荷テスト、結合テスト、最終テストなど、テストの文字がずらりと。
あとで調べたことでは負荷テストとは、当行での意味合いはともかく、一時的に処理が重なったときにちゃんと応答できるかを試すものだと知り、確かに支店規模でやるなら必要だなと納得した覚えがあります。
こんな感じで全てのテストがどういうものかはわからなかったのでとりあえず最終テストであれば情報は一番多いであろうと当たりをつけフォルダを開いたところ、そこにはさらに10程度のフォルダが格納されていました。
これは当行で行っていた格付けの付与が凡そ10ほどの区分であったことに由来します。
イメージは実際に格付会社が行っているAAA, AA, A, BBBなどの扱いが近いです。
そうして区分が10個もあり、さらにそこから幾つもフォルダを探っていくとどうにもこの区分は最終的に付与される格付によって作られたものであり、実際の融資案件を利用して同じ結果を得られるかを確認した結果の集積だとわかりました。
ただこれでわかったのはあくまでシステムの出力結果とエクセルでの結果が同一となった結果をまとめている、つまりは私の探していた不一致の処理がどうなっていたかということについて見つけるのは非常に困難という事実だけでした。
最終テストで行われていたのは全ての区分について、100件超の案件を同時に処理開始し結果を確認するという都合1000を超える確認結果の山だったのですから。
それを見て何となくその日はそれで終えました。
ただ次の日に何となく思いついた方法がありました。最悪の閃きです。
不一致のファイルを探すのが難しいなら、あるフォルダが格納するフォルダ名とファイル名を調べればいいのではと。
これまで見てきたフォルダではシステム証跡、エクセル証跡などといったように統一された名前のもとでそれぞれに画面キャプチャやエクセルなどが格納されていました。
ここでもし不一致を起こした事例があるならその時にはエクセルは追加で必要になる、あるいは追加フォルダを作成して何らか処理の追加分が残るのではないかと。
それでも全フォルダをチェックするのは面倒で、どうにかそういった情報をまとめて処理できないかと考えました。
当時は今のAIの走りという時代で、あまり精度こそよくありませんでしたがそれでも適当に質問すれば方向感くらいは当たりが付きました。
これを利用しコマンドプロンプトというもの、今でもあまりよくわかっていませんが、ここでフォルダ構造の取得と数え上げをやってみました。
多少苦戦したのは事実ですが、結果自体はちゃんと得られ、そこに何かファイルがあるだろうと思っていた私は大いに困惑しました。
コマンドプロンプト上で示されていたのは、フォルダの存在ではなくその逆。ところどころにエクセル証跡のフォルダの存在しないという事実だったのです。
もう何となくわかったかもしれません。
私の見つけた格付の不整合とは、そもそも検証などされていないのです。そういう仕様としてシステムが作られ、今も利用されているのです。
何か変だとその日はどうにか仕事をして帰りました。
ただこの後お酒を飲みに行ったのが悪かったのかもしれません。忘れようと飲んだはずのお酒で普段では考えないことを考えてしまったのかもしれません。
このシステムとはわざとこのような不整合を出すように作られていたのではないか。
このシステムでの検証はわざといくつかの証跡不足を作っておきながらあえて公開し、膨大な情報の山を見せつけることで誰もその中身を見ないようにしていたのではないか。
目覚めてからそんな疑念ばかりが頭に浮かびます。
よくよく思えば証跡の足りていないフォルダは番号の付いたフォルダの中でも先頭や終盤にはなかった気がします。ソートして探しても絶妙に一度や二度ではたどり着けない場所。たいていの人は2,3確認して問題なければそのまま、そしてそれは最初から始めることが大半。
ずっと疑いました。
これでいい、これでいいのだと思うにはただそのシステムが使われているという事実があるだけでした。
そしてまた会社に行った時には誰がこれを知っているのかと思います。
課長かそれとも部長か、システム導入のあれこれをやった人はとフロアの誰かに聞けば一発でしょう。
でも、聞いてそれでどうするのか。
格付も結果も間違っていると指摘するのか。指摘したとしてそれをどうするのか、直すにしてもどこから。
そんな渦巻の中で誰にも言えませんでした。
只仕事をして、疑いに苛まれて、また悪い考えだけが浮かぶ。
そんな中であの役員の関わりも思いついてしまいました。
これも誰にも聞けていません。議事録を見れば、承認者を見れば確認もできました。それも出来ていません。
これで私が問題に気づいた理由は以上です。
次は最後としてこの告発の理由を書いて終わりにしたいと思います。