４　難解なフレームワーク

　ちょうどこの頃、肝心の勘定系パッケージも第一弾の選定に向けて情報提供依頼が出されようとしていた。
　システム本体の開発も大変だが、どれにするかを選定するまでにも長いプロセスが横たわる。
　銀行の要望に沿った機能を有しているのか？という観点は当然にして、金額的に見合うのか、スケジュールに収まるのか、という事を細かく確認していく必要があるためだ。
　何より大規模な投資額である。後々問題が起きた時や、出資者である株主に対してなぜこのシステムにしたのかということを、明確な理由をもって示せなければ、逆に企業価値を棄損してしまいかねない。このため比較検討は組織的に、膨大な文書に記録しながら進められる。
　選定する方も大変なのだが、システムを提案するベンダー側も、提案依頼を受けた途端に途方もないプロセスが待ち受けるものだ。
　顧客に自社のシステムを理解してもらうために膨大な量のドキュメントを作成していくのだが、パッケージの仕様や見積もり、ライセンス条件など、多くの情報を銀行と共有するため沢山の人が何度も足を運び、説明しては質問を持ち帰り、それに答えていく、という事を繰り返すことになる。
　ここまでは営業活動として当たり前だが、最終的には選んでもらうという目的があっての活動であるため、勝ち目が無ければベンダーはやりたがらない。
　最初から自社製品が採用されないことが分かっていたら、全くもって無駄なボランティアでしかない。そのためこの期間、どこまで本気で顧客に付き合い、時間を掛けて取り組むのかはベンダーにとってジレンマとなる。
　一般的に選定までは無償で協力していくことになり、営業要員だけでなく、エンジニア、責任者など、普段は社内で籠もっているような人たちが総出となり、このプリセールス期間にフル稼働する。
　ベンダーにとってもシステムを買ってくれるなら誰でも良いというわけではない。契約条件は遵守されるのか、プロジェクトがしっかり遂行される体制か、問題が生じた時に顧客内を取りまとめるリーダーシップがあるのかなど、ベンダーから見たリスクとなる要素を、見積もりをしながら逆にチェックしていくのである。
　真面目にやろうとするとこのように大変な作業になるため、ベンダーに声がかかった途端に見積もりに全力投球するのではなく、採用される可能性を探りながら、スタンスを変えていくのである。
　このようなやりとりは、選定先が複数あれば、ジレンマもそれだけ存在するということになる。
　そんな事情は銀行も当然理解しているため、大規模なシステムになると選定は何段階かに分けて行われる。大会の予選と決勝のようなものだ。
　まず予選では、銀行から基本的な要求事項を提示し、それが満たせるのかを、いくつかの質問に回答していく形式で進められる。
　決勝戦では、具体的に機能ごとの要件を明確にし、見積の明細、工程ごとのスケジュール、プロジェクト体制、契約条件、ベンダーからの提案事項について求め、これにベンダーが答え、最も条件の良いベンダーを採用する、という流れとなる。
　銀行から見た場合、前者を情報提供依頼、後者を提案依頼といい、全体的にコンペとして進めていくのである。
　少し説明が長くなってしまったが、２０１７年１月時点でかぞく銀行が進めているのは、情報提供依頼の方であった。
　依頼と言いながら実態は依頼先から予選通過組を選定することに他ならないが、ベンダーも先に述べたような事情があるため、双方でこのプロセスを認識して進めていた。
　銀行からの情報提供依頼先は、国内の主要な勘定系パッケージメーカーである４社に加え、現行システムのグローバルバンク社を合わせた５社に対して行われた。５社とは次の通りである。
　まず家電メーカーでもありながらパソコンやサーバ関連に強みのある日の丸電気。彼らは都市銀行の勘定系システムを作ってきた実績をベースに、「ＷＥＢＢＡＮＫ」というパッケージを地銀中心に展開している。古くから採用されてきたパッケージで、業界では最もシェアが高い。
　次にシンクタンクの筑波総研である。彼らは共同センターとして「ＴＳＵＫＵＢＡＮＫ」というパッケージを開発してきた。共同センターとは複数の銀行が利用する前提で作られたパッケージシステムで、各行共通の仕様を満たし、運用も共同でアウトソーシングすることで、単独利用に比べコストが抑えられるという特徴がある。
　３社目はＢＮＩ社である。外資系ではあるが、国内最大級のメガバンクである、帝国銀行の勘定系を担当しているベンダーであり、帝国銀行とともに地方銀行向け勘定系パッケージ「ＣＨＡＬＬＥＮＧＥ」を展開している。システムだけでなく銀行業としてのノウハウもセットで提供され、帝国銀行系の地銀は大半がこのシステムを利用していた。かぞく銀行としては独自路線を行きたいところだが、帝国銀行とは出向関係があるため情報提供依頼先の１つに上げられている。
　４社目は総合電機メーカーの大手製作所である。ＢＡＮＫＣＥＮＴＥＲという、Ｌｉｎｕｘサーバで稼動する勘定系システムを扱っていた。
　それまでの時代では、銀行の大規模な勘定系パッケージはメインフレームという大型マシンで動かすものが多いが、ＢＡＮＫＣＥＮＴＥＲは早くからＬｉｎｕｘというオープン系マシンで稼動した。
　メインフレームとは大規模なコンピュータであり、高価だが高い信頼性がある。銀行勘定系を稼働させるうえでは必須とされていたが、近年オープン系システムの性能向上に伴い、ＷｉｎｄｏｗｓやＬｉｎｕｘなどのオペレーティング・システム（ＯＳ）で稼動する勘定系システムが登場してきた。
　ＢＡＮＫＣＥＮＴＥＲは日本で初めてＬｉｎｕｘで稼動させた国産勘定系システムであり、その意味でオープン化の先駆けとなっていた。
　これらに加えて現行勘定系システムであるグローバルバンク社にも依頼が行われる。
　パッケージも社名と同じ「グローバルバンク」という名称で、米国の大手銀行であるＷｏｒｌｄ　Ｂａｎｋのシステム部門が独立して展開しているシステムである。
　世界最先端と言われる米国銀行のビジネスモデルを採用し、早くからオープン化を進めていた。日本には１０年前に進出し、当時ネオバンクと言われる新興系銀行が軒並み採用してきた。しかしながら国内銀行の独自ビジネスモデルに当てはめるため、仕様を変更しようとすると、途端に開発スピードが鈍る。
　以前犬澤役員が言っていた通り、設計がブラックボックスとなっていることで、システム変更の影響がわからなかったり、海外の保守チームと日本のビジネスサイクルが違い過ぎたりすることが原因であった。
　ただ、グローバルバンク社も年々システムのバージョンアップを繰り返しており、現行ベンダーとしてかぞく銀行の業務仕様を最も理解している立場であったため、次期システム更改の選定対象から外すというわけには行かなかった。
　２０１７年１月の半ば、これら５社に対して、志賀たちが作成してきた情報提供依頼書が説明された。
　回答期日は２０１７年３月末。受け取ったベンダーは約１か月半の間、くだんのプロセスを経ることになる。
　ただこの回答期日は、かぞく銀行としてはベストタイミングであった。東山と朝比奈が検討していたフロントアーキテクチャの前提である、ＭＶＣ１．０の採否がほぼ確定する、ＥＤＲ３というイベントの結果が直ぐにわかるため、システム全体のアーキテクチャを検討するのにその後十分な時間を確保することが出来るためだ。
　東山は、これら勘定系選定活動の裏で粛々とフロントアーキテクチャ構想をドキュメントに起こしていた。
　そして２０１７年２月。
　フロントアーキテクチャ構想ドラフト版の銀行レビューの日を迎えた。レビューアは、朝比奈調査役、熊手部長、赤魚本部長と犬澤執行役員であった。
　「勘定系システムのアーキテクチャは、フロントチャネルとバックとを分離することで完成すると言えます。そして、フロントシステムはフルスクラッチにするのが現時点での最良の選択肢です。」
　落ち着いた表情でそう口火を切ると、東山は検討してきた過程を一つ一つ丁寧に説明した。
　「銀行としては次期システム更改で勘定系を刷新することが第一の目的だと思いますが、全体アーキテクチャを検討するにあたり、今後銀行に求められる役割を踏まえ、システムとしての要件を検討してみました。」
　行員たちは東山の口から発せられる落ち着きのある言葉にペースを任せながら、次は何が出てくるのかと待ち構えていた。
　当の東山は、いつものように淡々としたスタンスを保っている。
　「スマホは今や国民の５割を超える勢いで普及し、その技術を活用したＦｉｎｔｅｃｈと言われる事業者が金融業に進出しています。顧客としてはミレニアル世代という、デジタルネイティブな人たちが消費をリードすると予測されていますが、彼らの行動には、顧客体験価値が高いものを選ぶという特性があると言われています。そして顧客がどこに価値を求めているのかは、かぞく銀行にとっても非常に関心の高いものと認識しています。」
　戦略を説明する上では、何故その方法が有効なのか？という理由付けが重要である。その意味で銀行を取り巻く外部環境の変化から切り込むのは、大きな説得力に直結する。先ほどの説明は、外部環境のうち顧客と、業界のプレイヤーについてのこの先の変化を語っていた。
　「これらの変化に対して、世の中では技術や規制の緩和が生じようとしています。技術についていえば、事業者が銀行と情報連携を行うために、ＡＰＩというインターフェースの規格統一が行われようとしています。この仕組みは、銀行をはじめとする既存の金融事業者が、予め登録されたＦｉｎｔｅｃｈ企業と安全に通信する方法であり、認証方式のＯｐｅｎＩＤなどと補完する形で標準化が進められています。日本においても、銀行によるＡＰＩ公開が義務づけられるのは時間の問題です。そしてこれを後押しする形で、金融業界への参入障壁を下げるような規制緩和が行われる見通しとなっています。」
　つい２カ月前まではフロントシステムのアーキテクチャ上の位置づけがはっきりしていなかったが、今では世の中の動きを背景に、その位置付けは確信を持って説明できる。
　「ＡＰＩはＦｉｎｔｅｃｈ事業者のためかというと、それだけではありません。なぜなら銀行自身も、それを活用すべきだからです。」
　Ｆｉｎｔｅｃｈ事業者に公開するためにＡＰＩが登場したと言っておきながら、自分で活用するとはどういうことなのか。東山は明確に説明する。
　「Ｆｉｎｔｅｃｈといえば、家計簿や会計システムなどが代表例ですが、これらは言わば入出金明細照会と帳簿を組み合わせた機能です。その本質は、銀行で管理されている入出金の履歴と、家計簿の形をした帳簿があるだけで、それぞれが目新しいということではありません。つまり、Ｆｉｎｔｅｃｈと言えども大半は既存のサービスや情報の組み合わせで作られているといえます。そしてかぞく銀行としてこの点の特徴が出せるかどうかが、Ｆｉｎｔｅｃｈ事業者とのすみ分けに繋がっていくと考えられます。」
　ここまで説明したところで、おとなしく聞いていた赤魚の口から自然と同調する声が漏れた。
　「なるほど。だから、銀行もＡＰＩを使って特色あるサービスを作れということですね。」
　そう言ってもらえれば、もはやこちらのシナリオの内にある。と東山は心の中でほくそ笑んだ。
　「今すぐに作る必要があるということではありません。ＡＰＩと言ってもまだまだ照会系が中心で、資金異動などはもっと先になると思っています。我々が検討してきたアーキテクチャは、今後の拡張性を持たせるためにＡＰＩを自ら作れる状態にしておく必要がある、と言っているわけです。」
　どういうことか納得できた赤魚は、確認のために聞き返す。
　「その場合に、ＡＰＩを持っているのは勘定系であって、活用基盤としてフロントチャネルがある、と整理されたということですか。」
　「まさにそのように整理していました。」
　「なるほど。確かにそう言われるとスッキリしますね。」
　銀行が今後直面する時代の顧客、技術動向などを見ても、この先の展開、つまりフロントチャネルを独立した基盤と位置付けるべきであることは十分理にかなっていた。説明をすれば誰にでも理解してもらえるとは思っている。ただ、今はさらにこの必要性を訴え、理屈だけではなく心にも刻んでおきたかった。今後色々な局面で同じように説明しなければならないはずだ。そう考えると、このまま銀行員たちを勢いづける必要があったのだ。
　「銀行が備える本質的な役割は、安心・安全で信頼できる金庫番であり、これ自体がＦｉｎｔｅｃｈ事業者に置き換わることは出来ません。さらにこの金庫の中には、かぞく銀行が大切にしている日本の家族の姿があります。今は見えないかもしれませんが、今後の活用の仕方によって形になってきます。例えば、別々に管理されている口座も家族として関連づけることで、目的別の共同口座、定額仕送りや学資積立て、未成年の子ども口座なども簡単に開設することができます。家族のライフプランに応じた口座やサービスの展開も、基本的な勘定系のＡＰＩを組み合わせることで、いくらでも作ることが出来るはずです。」
　行員たちは、ここまでの東山の話を感心しながら聞いていた。事実、ノッているときの東山の話は、できないことでもできるように信じさせてしまう不思議な説得力を放っていた。
　「そして、このようにＡＰＩを呼び出す側と、提供する側で役割分担されている関係性は、そのままフロントチャネルと勘定系パッケージに置き換えることができ、前者はＳｏＥ、後者はＳｏＲアーキテクチャと呼ばれています。」
　ＳｏＥとはＳｙｓｔｅｍｓ ｏｆ Ｅｎｇａｇｅｍｅｎｔの略で、顧客と企業とを繋ぐシステムという意味がある。ＳｏＲはＳｙｓｔｅｍｓ ｏｆ Ｒｅｃｏｒｄの略で、取引情報などを記録することが目的のシステムという意味である。この概念は、ＡＰＩやスマホといった技術の進化により、「システムを操作すること」自体が体験としての価値を持つようになってから、特に注目されているアーキテクチャ概念だ。
　システムとは従来大量の情報を処理することが目的であったが、このような「顧客に体験を提供する」のが目的のシステムと、「従来の目的に則した」システムを使い分けることが、企業の新たなＩＴ戦略であると考えられていた。
　とはいえ今は言葉の定義はどうでも良い。フロントチャネルをスクラッチ開発にしてもらうという目的のために、この話を出したに過ぎない。
　東山が説明を続ける。
　「フロントチャネルシステムは、ただの通信経路ではありません。先程の通り、顧客ごとの取引状態に応じて提示するデータを変えたり、足跡を追ったり、あるいはセキュリティと利便性を同時に満たせるなど、顧客を離脱させないようにするための機能や拡張性を備えておく必要があります。つまりここはパッケージではなく、サービスの拡張開発に速やかに応えられるよう、独自フレームワークによるスクラッチ開発にすべきと考えています。そして独自フレームワークには、検討中のＪａｖａＥＥの最新フレームワークが最もイメージに近いといえます。」
　ここまで聞いて、赤魚は以前提案した話を切り出した。
　「Ｊａｖａのフレームワークなら、前も言った帝国銀行のものを参照できるよう交渉中です。作った時点で最新だったと思いますが、そういうことならその視点でも評価してもらうことは可能ですか？」
　「はい。帝国銀行はＪａｖａＥＥ６時点のフレームワークだと思いますが、採用したいのはＥＥ８です。実装されているＷｅｂｌｏｇｉｃはまだ出ていませんが、２０１８年にリリースされる次のバージョンで採用される予定となっています。つまり・・・。」
　東山はこのまま一気に結論まで持ち込もうとしていた。何かというと、まだ世の中にリリースされていない製品を前提に考えましょうと言おうとしたのである。ただし銀行としては、どんなものになるかまだ決まってもいないものが計画の前提となるのは相当のリスクを伴う。しかしながらそこは、どのようにリスクをヘッジするのか、既に東山は先回りして考えていた。
　「つまりこのプロジェクトでは、Ｗｅｂｌｏｇｉｃの次の最新バージョンを採用し、ＪａｖａＥＥ８を前提にするべきです。そこに実装されるＭＶＣ１．０というフレームワークを利用すれば、ＡＰＩのための拡張性に加え、ブラウザやスマホの画面をとても効率的に開発することが出来ます。Ｗｅｂｌｏｇｉｃ最新バージョンまでにはまだ１年以上の期間があり、それまでに仕様が変わるかもしれません。でもそれ以上にシステムの開発がかなり効率化出来るフレームワークになりますので、リスクをヘッジするのに十分な検証期間も設けられると考えます。」
　銀行の人たちは、納得する時は強く賛同してくれる。
　だがしかし、さすがに運任せのようなリスクは負うことが出来ない。様子を伺っていた熊手部長がここで口を挟んだ。
　「方向性としては理解しました。かぞく銀行としても、単なる勘定系システムを更改するという話ではなく、次の時代の銀行システム像を想起させる、深いコンセプトだと思います。スクラッチも良いと思います。ただ、メーカーがまだ公表もしていない予想のようなものを開発計画の前提に置くわけには行きませんので、チェックポイントを置いて、先に進めるのか方針を見直すのか、都度判断していきませんか？」
　考えてきたシナリオが、あと少しで完成を迎えようとしていたところに水をかけられた状態だった。だが、フロントシステムをスクラッチ開発にするべき、という主張が認められただけで大収穫だった。そればかりでなく、ＪａｖａＥＥ８やＷｅｂｌｏｇｉｃを開発前提として良いと認めてもらえたことで、この場の成果は想定以上だったと言って良い。
　これまで経験したＧＳＣＳ社のシステム構築の実績が、１００％信用された証拠だ。そこが認めてもらえるのであれば、都度判断などはむしろこちらからお願いしたい。
　「わかりました。確かに熊手部長のおっしゃる通り、まだ想定の域を出ていません。マイルストーンとしては、直近でＥＤＲ３というイベントがあるため、次のチェックポイントとして改めてご報告させて頂きます。」
　「そうですね。方向性はこのまま進めることで良いと思いますので、宜しくお願い致します。」
　こうして第一回目のアーキテクチャ構想レビューは無事に終わった。
　２０１７年の３月末。特にこの冬は厳冬という訳ではなかったが、東山と志賀にとっては、ようやく雪深い冬から抜けだしたような、待ち遠しい春の訪れとなった。
　ＪａｖａＥＥ８のアーリードラフトレビュー（ＥＤＲ）３の結果は、東山の思惑通りＭＶＣ１．０が無事に採用された。直ぐにこの結果をかぞく銀行に報告し、これを機にＭＶＣ１．０を前提としたフレームワークの検討を具体的に進めていった。
　一方、気になる勘定系パッケージに対する情報提供依頼の結果は、次の通りで様々なものであった。
　筑波総研からは、現在仕掛かっている別の銀行のプロジェクトに注力のため回答辞退、日の丸電気、大手製作所は約２００ページにわたり一つ一つ丁寧に回答が記載されている。
　ＢＮＩ社は、何と１０ページのみで、何故ＢＮＩ社が担うのがベストなのか？ということが淡々と綴られているだけで、質問に対する回答は見られなかった。
　あとはグローバルバンクで、かぞく銀行が利用している現行システムの次期バージョンに基づいた回答説明が中心であった。
　ベンダーの提案はありがたいが、聞いたことに答えてもらわなければ比較しようがない。世の中の天才と言われる人たちは、枠に囚われない発想で周りがついて行けなくなることはあるのかもしれないが、ＢＮＩ社の回答はそういった観点よりも、時間を引き伸ばそうとしか見えなかった。回答に当たって社内で色んな葛藤があったのだろう。
　しかしながらこの時点で辞退と同等と判断され、結果的に第一次選定は日の丸電気、大手製作所、グローバルバンクの３社に絞られることになった。
　日の丸電気はかぞく銀行の質問事項に対して一つ一つ丁寧に回答されており、老舗として流石と言える安定感と経験を感じさせた。
　ただ、彼らのパッケージシステムはメインフレームという大型コンピュータで稼働させることが前提となっていた。
　多くの地銀の中でスタンダードとなっている彼らのシステムは、何千万という顧客と取引データを扱った。特に稼働するシステムに対してこれといった注文がなければ、安定したシステム基盤で動かし続けたいというのは、当たり前のことだろう。その意味でかぞく銀行は普通の地銀とは異なる。インターネット経由でしかサービスを提供しないから、システムには拘りたい。そこが相容れるかどうかが比較検討の課題となるだろう。
　大手製作所は志賀も下調べしていたＢＡＮＫＣＥＮＴＥＲを推してきていた。
　オープン系のＬｉｎｕｘで稼動させており、その点では及第点だ。しかしながら勘定系機能とてしては基本的なものこそ揃っているが、全体的にこじんまりしており、かぞく銀行のサービスラインナップと比べると、いくつか独自に構築しなければならないものがある。そこが全てコストに跳ね返ってくることが課題と思われた。
　グローバルバンクはかぞく銀行が使っている現行システムのバージョンを最新にするという前提で回答してきた。
　現行システムにはシステム的な制約が多いが、最新バージョンでは多くの不具合は改善され、セキュリティ面の機能が向上していた。何よりシステム間のデータ構造は新バージョンでもほぼ変わらないため、選択肢の中ではシステム移行が最も楽になるのは間違いなかった。
　ただ、機能を追加する場合のコミュニケーションに大きく時間がかかるという体制上の課題は、グローバル体制である限り改善は望めないだろう。
　このように結果は三者三様の情報提供となった。

　会社が異なればシステムの思想も異なる。それぞれが個別最適で考えられ、彼らベンダーが比較検討する土俵のうえでは、各社すべてが最も優れているのだろう。
　ただ、かぞく銀行はベンダーではなく銀行である。最も相性の良いシステムは、会社は、いったいどこなのか。この先、長い時間を掛けて一つ一つが比較評価されていった。
　その年も既に７月となった。
　かぞく銀行は第一次選定先である日の丸電気、大手製作所、そしてグローバルバンクの担当者と面会を重ねながら、詳細な情報を整理していた。
　そもそもかぞく銀行の定めた評価基準に対して、各パッケージのメリットやデメリットが異なるため、同じ評価軸で比較することが困難であった。
　そのため、それぞれを選択する場合に課題となる部分を解消するための具体的な施策を洗い出し、それを埋めるためのコストを引き直し、金額換算することで比較できるようにしていった。
　かぞく銀行が目標とするシステムは、東山の提言によるＳｏＥ／ＳｏＲアーキテクチャが実現出来ること。その場合の勘定系システムは、ＡＰＩでフロントチャネルと分離できることが前提であった。
　この点で、日の丸電気のＷＥＢＢＡＮＫは勘定系パッケージと専用の画面パッケージが一体となっていたため、両者を切り離したうえで、勘定系部分に対して新たにインターフェースを開発する必要があった。
　そのうえＷｅｂサーバを介した通信の中継も必要となった。さらにメインフレームというシステムは開発を行うにも専用のマシンを必要とする。この点も将来的な技術者の確保が不安材料となった。結果的にかぞく銀行の求めるシステム要件に対しては、コストが最も高くかかる評価結果となってしまった。
　そして今回の検討経緯である、グローバルバンクを切り替えることが目的で発足したプロジェクトである。ここまでの検討を経て、実質的に大手製作所のＢＡＮＫＣＥＮＴＥＲが残された選択肢と考えられた。
　次の二次選定で、もしも大手製作所が辞退でもして来ようものなら、このプロジェクトは大きな軌道修正が必要になる。この時かぞく銀行内では、現実の状況を踏まえ、二次選定の方針が話し合われていた。
　熊手「ここまでのところ、大手製作所のＢＡＮＫＣＥＮＴＥＲを採用するという選択肢が最有力となっています。」
　赤魚「我々として実現したい要求事項が明確になっている以上、それを変えてまでやる意味はないので、まずはお見合い相手が見つかりそうだということは良いと思います。ただ、コンペではなくなってしまうため、競争原理が働かなくなり、今後コスト面でリスクになる可能性がありますね。」
　犬澤「ＢＮＩさんは、ある意味きちんと回答をもらえていないと思うけど、もう一度時間を取って提案してもらうという選択肢はあるんじゃないの？」
　熊手「一次回答があった際に面会して話を聞きましたが、彼らの中でクラウドバンクという構想があって、勘定系を丸ごとクラウドに持たせて共同運営することを考えているようなのです。話すたびにそのプロジェクトに乗らないか、ということを仰るため、１つの銀行のための要件をお願いしても難しいかと思います。」
　海鳥「ベンダーさんからしたら、沢山の銀行を相手にする方が良い商売になるでしょうからね。かぞく銀行とサシでお付き合い頂けそうな、大手製作所を前提にするのが良いでしょう。」
　熊手「そうですね。二次選定もコンペを行う予定でしたが、大手製作所以外は見積に時間を割いて頂くのも申し訳ないため、コンペにはせずに大手製作所から正式見積を頂くように進めます。」
　犬澤「宜しくお願いします。その場合、各社へはきちんと理由を説明することと、先ほど赤魚さんが言われていたコストに対するリスクはヘッジしていくことも合わせて検討をお願いします。」
　熊手「わかりました。勘定系が大手製作所だとすると、フロントは別のベンダーさんにするなどがリスクヘッジになると思います。そこはもう少し考えて、対応方針を確定したいと思います。」
　当初の思惑では、一次選定である予選で数社に候補を絞り、二次選定となる決勝戦で金額勝負してもらうつもりだった。
　だが、かぞく銀行は決して大きな銀行ではない。投資額が決まっている以上、ベンダーからは選ばれる立場でもあり、常に現実を見ていく必要がある。
　逆に言うと、１つの銀行のためにこれから数年間、いや、一生の付き合いになるかもしれない立場に名乗りを上げてくれるベンダーがいるというのは、ある意味幸運と思った方が良いのかもしれない。
　銀行として事実上の勘定系パッケージが選定されてから、一ヶ月が経った２０１７年９月。
　かぞく銀行は、大手製作所を呼出し、フロントチャネルの考え方や二次選定の取組み方針などについて話し合いを行っていた。
　ＢＡＮＫＣＥＮＴＥＲを採用するのは、フロントチャネルをフルスクラッチとするため。その条件だけは譲れない。その根幹となるフレームワークは、ＪａｖａＥＥ８で採用されるＭＶＣ１．０である。ここまでは大手製作所にとって特に不利になる条件でもなく、問題なく合意しながら進んでいた。
　そして９月２２日。順調に検討を進めていたかぞく銀行内に、この日激震が走る。
　日本時間で前日の９月２１日、米国サンフランシスコで行われた、Ｏｒａｃｌｅが主催する世界最大のＪａｖａカンファレンス「ＪａｖａＯｎｅ２０１７。」において、ＭＶＣ１．０がＪａｖａＥＥ８からドロップ（脱落）した、ということを大手製作所が指摘してきたのだ。当日のプレゼンでＪａｖａＥＥ８に含まれる機能の説明があったそうだが、そこにＭＶＣ１．０が含まれていない、ということが指摘の根拠であった。
　この知らせは東山たちにとって晴天の霹靂であった。
　ＥＤＲ３でも問題なく採用され、後はパブリックレビューの通過待ちでしかなかったのである。
　まずは事実関係の確認が必要だが、想定が外れてしまったこと、さらにＪａｖａの世界的な祭典がノーマークとなっていたことで、ＧＣＳＣ社の情報力に対する信頼も著しく低下してしまうことを恐れた。
　何より、これまで様々な事実関係を元に作り上げた、東山のシナリオが大きく崩れることになる。すぐさま朝比奈調査役から、事実関係について確認を受けた。
　「東山さん、ＧＣＳＣさんの情報だと、ＭＶＣ１．０はこのまま採用されるということでしたよね。」
　「申し訳ありません。社内でもＯｒａｃｌｅを主管する部署がありますので、至急事実関係を確認致します。」
　「大手製作所さんが指摘してくれたから早く分かって良かったようなものですが、ＧＣＳＣさんはＪａｖａについて最新の情報をお持ちではないのでしょうか？」
　「そのイベントはマークしてなかった私のミスであって、会社としては最新情報を抑えているはずです。」
　「そうなんですか。大手製作所さんにも、ＪａｖａＯｎｅでの発表が本当にドロップすることを意味しているのか確認してもらっていますので、ＧＣＳＣさんでも確認お願いしますね。」
　「わかりました。社内でＯｒａｃｌｅを専門で扱っている窓口がありますので、事実関係を確認します。」
　話が終わるなり、東山・志賀からすぐさま事の次第が姫宮に報告された。そして姫宮からＧＣＳＣ社内の担当窓口へ確認し、先日のＪａｖａＯｎｅでの発表の背景となった、ＪａｖａＥＥの最新ロードマップを正式に入手し、東山に連携した。
　「ありがとう。この情報があっただけでも救われたよ。」
　そういって、東山たちは一瞬だけ安堵した。
　この時の速やかな連係プレーにより、ＭＶＣ１．０がＪａｖａＥＥ８からドロップされたという正式な情報はＧＣＳＣ社が最も早く入手し、かぞく銀行に報告することが出来た。だがしかし、事態がわかるまでは誰もが疑いもせずＭＶＣ１．０を前提にアーキテクチャ設計のシナリオを作ってきており、方針の見直しは不可避の状況となった。
　さらにこのレポートによると、ＪａｖａＥＥ８がリリースされるのも２０１８年末と、従来の想定の中で最も遅いスケジュールであることが分かった。
　幸いだったのは、プロジェクトの基本計画を策定するまでにはまだ三ヶ月あり、軌道修正を行うには十分時間が残されていたことくらいだ。もっとも、東山にとっては予想が外れたことは大きなショックである。この日から、東山はひたすら関連する情報を漁り、何故ＭＶＣ１．０がドロップされたのか、復活する可能性はないのか、代替手段をどうするのかについて徹底的に調査を行った。
　その結果、苦肉の策として代替手段を提案することが出来そうだった。
　「今回のドロップの原因は、時代の潮流が変化し、一年前と比べ世界中の多くの技術者にとってＭＶＣはもはや重要な要素ではなくなったと思われたことが影響しているようです。」
　「というと？」
　これまでは疑いもせずＭＶＣ１．０を推していたのだ。世界的な潮流が読めなかったのは事実であるが、朝比奈調査役も簡単に納得できるわけではない。
　「ＭＶＣはアクションベースで画面開発していくうえで効率的ですが、これから重要だと思われているのは、マイクロサービスというアーキテクチャです。ＡＰＩによるシステム間を連携する仕組みであることには全く変わりありませんので、我々の方針が誤っているということではありません。」
　「ＭＶＣにより画面を前提とするというより、システムのインターフェースはマイクロサービスとして整備できるようにしていくのが最新の流れである、というということですか。」
　「システムのユーザーインターフェースは画面だけでなく色々なものを前提としていきますよ、ということを積極的に推進する姿勢の表れだと捉えています。ただ、両者はどちらか、という背反の関係ではなく、両立するものです。」
　「まあそこは世界的なアーキテクチャの流れとしても理解できますが、とはいえ画面開発のフレームワーク前提が狂ってしまいましたよね。まさか今からマイクロサービスで行きましょうという軌道修正はないだろうし。」
　ここまでは事実の共有である。だが、東山の中では代替手段が既に用意されていた。
　「ＭＶＣについては、参照実装としてオープンソースのフレームワークが存在するため、それをそのまま取り込んでしまえば、どうってことはありません。本当はＪａｖａ標準となっているのがベストだったので、取り込むための開発は発生しますが。」
　「そうなのですね。でもＭＶＣで入力チェックなどと統合が図られる予定だったのに、機能が分断されてしまった感じになりますね。アプリの開発者にとって、複雑なフレームワークにならないか気になります。」
　「そこはフロントシステムを担うのであれば、担当されるベンダーには逆にどんな技術が使われるのか理解しておいてもらわないと困る部分かと思います。」
　「それはそうですね。ＧＣＳＣさんが担当することが決まっていれば問題ありませんけどね。ではＭＶＣについては少し方針を転換する、という事で行きましょう。」
　東山が機転を利かせたことで、何とかフロントアーキテクチャとしての体面は保つことが出来た。
　ただ、今回の一件で、想定していたフレームワークが構造上分断されることになった。ＪａｖａＥＥという製品上のプログラムではない、他のライブラリを使うことになる。
　もともと構想していたフレームワークによって、開発工程の生産性向上を大いに期待していたが、若干の効率低下は免れないだろう。その程度の違いは、使いこなすエンジニアのスキルでカバーしていけば良いと、この時は考えられていた。
　事件から一ヶ月後の２０１７年１０月。
　勘定系パッケージをＢＡＮＫＣＥＮＴＥＲとする前提で、この先どのように選定プロセスを進めるか、銀行内で話し合いが行われていた。
　その結果、勘定系についてはもはやコンペはせず、大手製作所に正式に見積依頼をすること、フロントシステムはＧＣＳＣを含む検討チームに参画中のベンダーに依頼することが決まった。この先は正式なＲＦＰ（提案依頼書）を作成することになるが、ＧＣＳＣは要求を出す側・答える側のどちらの立場にもなった。
　この方針が決まってすぐ、志賀は朝比奈調査役に呼び出された。
　「志賀さん、このまま行けばＧＣＳＣさんにも正式に提案依頼が行くと思いますよ。今のうちから体制構築しておくよう、営業さんに強く言っておいた方が良いですよ。」
　「それはありがとうございます。早速本社に連携しておきます。」
　志賀は直ぐに姫宮に状況を報告した。
　「そうですか。いよいよかぞく銀行も提案に向けて意思を固めてきているのですね。ここまでの志賀さんと東山さんの働きのお陰です。最後の選定に向けて、引き続き頑張って下さい。」
　紆余曲折がありながらも、ここまでシナリオを進めてくれた二人には感謝しかない。
　「ええ。何とかこのような状況を作り出せました。我々はこれからＲＦＰを作成することがメインとなっていきますので、あとは本社で体制を確り準備して頂きたいと思っています。」
　姫宮たちの当初の思いは、あと少しで実を結ぶところにいた。
　ただこの時、姫宮はかぞく銀行も含む銀行事業領域の責任者となっていたのだが、今年度の事業状況を踏まえると、体制が十分作れる状況ではないことを認識していた。
　そのため、本部長である田中執行役員に相談することにした。
　「田中本部長、かぞく銀行の件ですが、いよいよフロントもスクラッチでの提案依頼方針を固めたようで、当社にも正式に声がかかると報告がありました。」
　引き合いは喜ばしいはずだが、田中本部長の反応は厳しかった。
　「もうそんなことになっているの？だけど、今の本部の状況では新たに体制を作るのは難しいぞ。日の丸銀行からも大型のグローバルシステム構築の引き合いがあったのだが、うちの経営計画上も外すことは出来ない案件だ。社長にエスカレーションしてそちらの体制を作るのもままならない状況になっている。」
　「そういうことなら、本プロジェクトについても同じレベルで調達に動いて頂けないでしょうか。」
　「何を言っているんだ。単なるＳＩ案件と、経営計画になっているグローバル案件だぞ。同じレベルで調整なんて出来るわけがないだろう。経営計画上の数字のコミットも求められているんだ。以前から話していたサービス化検討はどうなったんだ？そちらの方向性が描けるのなら、考えられなくもない。」
　あの話か、と姫宮は思ったが、今からサービス化など現場に切り出すことなど出来るわけがない。
　「サービス化は、正直難しいです。ただ、これまでにないフロントチャネル構想を描いており、Ｆｉｎｔｅｃｈなどへの取組みにも寄与すると考えています。」
　「そんなことが言えるのであれば、サービス化前提で考えてくれよ。何年後に、うちが、どんなサービスでいくらのサービス収益を上げるって言えるんだ。その計画を以て判断だ。」
　「承知しました。直ぐにサービス化ということは難しいですが、ＧＣＳＣ社ならではのロードマップを考えてみます。」
　「それと、依頼を受けると言ってもまだ受け取ってもないんだろう？正式にもらってから考えるのが筋なんじゃないのか。先行着手して結局提案機会をもらわなければ、それこそ無駄になるぞ。」
　「はい、そこは営業から銀行にスケジュールを確認してもらいます。」
　姫宮がこの会話で受けた印象として、提案に回答できる可能性は５０％もなさそうだと感じた。ただ、今動かなければ、この１年半の取組みは無になってしまう。
　これまでインターネットバンキングという銀行チャネルシステムの一角を担ってきたＧＣＳＣ。
　過去からの歩みを考えると、チャネル領域で大きな実績につながるこの案件は絶対に進めるべきだ。姫宮も次の実績を作ることが、頑張ってきた社員のためになると信じていた。
　会社の経営計画も重要だろうが、ＳＩｅｒの世界で重要と思われていることは、主として現場からのボトムアップでしかない。
　必ず経営層に理解してもらえるようなロードマップを作り、そして何とか提案体制を整えたいと、姫宮は誓った。