「以上」と「イコール」、似たようにも思えるが、その裏側には想像以上に大きな違いがあることを知っていただきたい。実体験をもとに解説しよう。
今回は、筆者が過去に経験したセキュリティにおけるカルチャーショックについて紹介してみたい。幾つかあるショッキングな内容の1つが、金融プログラムに対する考え方の違いである。
当時、都市銀行(都銀)と呼ばれていたほとんどの銀行は、あるシステムを競い合って開発していた。いわゆる「第三次オンライン」である。今の主要行で使われているプログラムの根幹は、この頃に作成されたものが多い。当時としてはビックプロジェクトであり、都銀で総開発工数が「万人月」を超えた最初のプロジェクトだったと記憶している(今では珍しくないが)。
そうした中、筆者は「知的野人を求む!」というキャッチフレーズに魅かれて、某都銀の中途採用の門を叩いた。25年前の出来事だ。完成するまでは馬車馬のごとく働き、走りながら考え、設計書の作成、プログラミング、そして、テストの繰り返しだった。テストとはいっても、今のWeb開発や数十人くらいで行うテストとは全く別次元のものであった。
カットオーバーして、自分がシステム監査人として作業をして、初めてその膨大な事実にびっくりしたものである。何せソースコードを1行修正しただけで、テスト計画書はバインダーにして10冊にもなってしまう規模である。テストケースは1行修正しても、最低数万件のテストデータが準備される。しかも、全て目的別に作成され、無意味なデータは皆無なのだ。
ある意味、今では昔懐かしい話かもしれない。現在なら、通常の企業で行っているWeb開発はそうした状況にないだろう。できれば専任の思慮深いテスターを配置すべきと思うが、コストと時間の関係で優秀なテスター専門員をWeb開発で配置することはほとんどない。設計者やプログラマーがテスターも兼ねるが、品質のことを考えると不安が残る。こうした実態をみるに、現場の方々の苦労が心に突き刺さる。
話が昔を懐かしむ老人のようになってしまったが、筆者は当時、内部にいて全体の整合性を検証する側ではなかった。その時には気が付かなかったが、後になって気付いた問題が幾つも残ってしまったのである。その1つを紹介しよう。
単純に「振込処理」をする場面を想像していただきたい。顧客が自ら操作するATMでの処理ではなく、窓口で行員が処理をする場合である。
仮に振込処理をする場合に、大きく分けて「A+B+C」という3つの処理で振込処理が成立するとしよう。多くの金融機関ではそれぞれの処理を実施する権限が違うように設計されている。銀行により、「権限区分」や「グレード区分」「処理区分」といった名称に違いはある。
例えば、権限の比重が支店長は「90」、副支店長は「80」、以下、次長が「70」、課長が「60」、課長代理が「55」、係長が「50」、一般行員が「40」、嘱託行員が「30」、端末の操作権限を持つパート(元銀行員が結婚後にパートになるケースが多い)が「20」としよう。そして、A処理を行う権限が「50」以上、B処理が「20」以上、C処理が一番に重要な処理として「60」以上とする。それぞれにチェックが働く三重のチェック機能を持ったソフトウェアと思ってほしい。
ある時期、米国の某預為システムのソースを見る機会があった。事細かになぜそういう機会になったのかは覚えていないのだが、その時に受けたショックだけは忘れられない。
単純にいうと、そのシステムでは振込処理「A+B+C」における実行権限が日本と全く違うのであった。前述のようにするものだという考えだっただけに、最初は筆者の間違いかと思った。そして、その理由を聞いた瞬間、ハンマーで頭を殴られたほどの衝撃を受けた。
こうした実行権限は、もちろんセキュリティを考えてのものだが、セキュリティ以前の問題に実は「文化(カルチャー)」の違いがあることを知ったのである。
この違いは数式にすると分かりやすい。端末操作者の実行権限を仮に「Z」とする。
処理 | 日本なら | 米国なら |
---|---|---|
A処理 | 50≦Z ならOK | 50=Z ならOK |
B処理 | 20≦Z ならOK | 20=Z ならOK |
C処理 | 60≦Z ならOK | 60=Z ならOK |
つまり、「≦」か「=」という違いだ。それではセキュリティの側面で考えた場合にどう実際に違ってくるのか。正直に言って、日本方式は「ざる」であり、セキュリティの根本的精神すら理解していないということになる。
Copyright © ITmedia, Inc. All Rights Reserved.