巨大システムの裏側にある、小さな一歩の積み重ね うわっ、金融機関がJavaフレームワークに挑戦するのか!? そう思ったのが、そのプロジェクトの最初だった。 当時、私はある 大手金融機関のお客様 のプロジェクトに関わっていた。 その金融機関は、日本でも有数の巨大な企業体。社会への影響力も大きく、システムに障害が起きれば社会全体に影響が出る可能性すらある。 だからこそ、 基幹システムは依然としてCOBOLが中心 だった。 長年動き続けてきた、安定した仕組み。 金融の世界では、それは「守るべき資産」でもある。 しかし、同時にこういう声もあった。 「新しい技術にもチャレンジしていきたい」 そのプロジェクトは、 Javaのフレームワークを金融機関で適用する初めての試み だった。 とはいえ、金融機関である。 いきなり基幹システムに導入するわけにはいかない。 そこで出てきたのが、非常に興味深い考え方だった。 新しい技術は、まず影響の少ないところから使う。 それは、Webシステムなどの 周辺システム だった。 金融機関が考えた「安全なチャレンジ」 当時の金融システムでは、まだ 帳票文化が主流 だった。 帳票は公式記録。 そこに誤ったデータが出てしまうと、業務への影響は非常に大きい。 だからこそ、技術適用の順序にも工夫があった。 まずは 入力システムではなく表示システムから 。 理由は明確だった。 入力システムにバグがあり、誤ったデータが基幹データベースに登録されたら取り返しがつかない。 しかし、表示システムならどうか。 もし表示ロジックに問題があったとしても、データそのものが壊れるわけではない。 つまり 出力・表示 → 入力 → 基幹 という順序で、慎重に技術を適用していく。 さらに言えば、帳票に誤ったデータが出るより、 Web画面での表示の方が痛手は小さい 。 こうした議論を、金融機関の担当者と何度も重ねた。 その議論を聞きながら、私は思った。 「金融機関は新しいことに挑戦しない」 世の中では、そんなイメージがある。 しかし実際は、まったく違っていた。 「守る責任」があるからこその計画 金融機関の人たちは、決して挑戦を避けているわけではない。 むしろ逆だ。 社会を守る責任があるからこそ、計画的に挑戦...
うわっ、また夜中のローンチか！ 昔のプロジェクトルームでは、そんな声が当たり前のように聞こえていた。 私の経験上、 システムのローンチは夜に行われることが多い 。 それも、かなりの確率で。 なぜか。 理由はとてもシンプルだ。 次の日から使えるようにするため だ。 夜にローンチする理由 システムの変更は、できれば「区切りの良いタイミング」で行いたい。 たとえば、 ・夜中に切り替え ・翌日から新システム ・もしくは土日作業 ・月曜から新システム この形は、説明がとても楽だ。 「 月曜日からシステムが変わります 」 これだけで済む。 ユーザーにとっても分かりやすいし、 管理側も整理しやすい。 プロジェクトというのは、 技術よりも説明の方が難しいことが多い。 だからこそ、 区切りの良いローンチ が選ばれる。 金融システムはさらに特殊 特に顕著なのが 金融系システム だ。 金融の世界では、 平日の昼間はお金が動いている。 つまり、 平日昼間にシステムを止めるわけにはいかない。 その結果どうなるか。 作業は土日になる。 これが長年の常識だった。 さらに大きな変更になると、 GW（ゴールデンウィーク）作業 も珍しくない。 「GW中に変更作業を行い、 GW明けから新しいシステムになります」 金融プロジェクトでは、 この言葉を何度聞いたか分からない。 システム屋のGWは存在しない 私の若い頃、 システム屋にとってGWは特別な意味を持っていた。 休みではない。 むしろ 最大の作業タイミング だった。 システムローンチが控えている年は、 GWなんて存在しない。 プロジェクトルームに泊まり込み、 深夜の切り替えに備える。 そして夜中。 コマンドが打たれる。 ログが流れる。 沈黙。 「……よし、上がった」 その瞬間の空気は、 今でも忘れられない。 私は長い間、 システム屋ってそういうものだ と思っていた。 しかし時代は変わり始めた 最近、この常識は少しずつ変わってきている。 理由はいくつかある。 まず、 土日に人を集めるのが難しい。 働き方が変わったからだ。 さらに、 月曜日の高負荷タイミングで新システム というのは、 リスクが高いという考えも広が...