３　幻のアーキテクチャ

　前回の内部ミーティングからさらに１ヵ
　かぞく銀行はシステム更改の類似事例を持つ銀行へのヒアリングを進めながら、パッケージベンダーに第１回目の情報提供依頼を求めて面談を進めていた。
　一方で姫宮は、ＧＣＳＣ社内の勘定系パッケージに関する動きを確認するように東山から言われていた。事実を確認したところ、確かにかぞく銀行からＧＣＳＣの担当部署に問い合わせは来ていたようだ。ただし蓋を開けてみると単に聞かれたことに対して情報提供だけするつもりであったらしい。ローンシステム専用のパッケージなのだが、勘定系パッケージによってはローンの機能がないものもあるため、銀行も気になっていたようである。
　結果的にＧＣＳＣのローンシステムというのは、かぞく銀行の業務に対してはフィットしていないことがわかり、ＧＣＳＣは情報提供依頼先からは外れた。このやり取りと共に、志賀・東山の二人は、再び選定作業に就くことになった。
　これらの状況を伝えるため、姫宮は常駐先であるかぞく銀行を訪れ、東山と面会した。
　「・・・という経緯で、当社の営業は特に勘定系で提案しようという考えは持ってないことが確認できました。」
　「了解。そもそもインターネットバンキングにはマッチしないだろう、と銀行も言っていたよ。今はあらゆる前提は置かずに情報を集めたいということらしいね。」
　取り敢えず大事にならずに済んだようだ。会社が統合するとコミュニケーションを取るのも難しくなる。
　「そういうことですか。いずれにしても、誤解が解けたみたいで良かったです。」
　「あと、そろそろパッケージの１次選定が行われるので、ベンダー向けの説明会から同席することになりそうだよ。それと同時に、システム全体をどのようなアーキテクチャ構成で作っていくかの検討を依頼されたよ。」
　「そうなのですね。いよいよフロントチャネルのアーキテクチャ検討開始ということですか。」
　「当然フロントも含めた話になるだろうね。でもね・・。」
　一呼吸おいて、悩ましげに東山が続けた。
　「そのシステムの要件が全くないんだ。パッケージについては必要な機能を定義してフィットアンドギャップしていけば自ずと決まるはずなんだが、アーキテクチャとなるとそもそものビジネス要件、通信要件やデータ要件、保守要件などがあるはず。でも要件ではなくて、あるのは現行システムの設計だけ。」
　「現行の設計書を総なめしていくということですか。かなり膨大な作業になりそうですね。」
　大変そうなのは、何となく伝わってくる。
　「まあそれは読んでいけば良いのだけど、結局それを実現しているのが今のシステムであって、積極的にアーキテクチャはこうあるべき、というポリシーがないことが問題だよ。」
　「でも現行システムはアーキテクチャのレベルで問題があるから、障害が多発したのではなかったでしょうか。」
　「現行の障害は認証サーバや流量設計をしておけば発生しない問題が多いし、今の時代、一般的なＡＰサーバ製品入れてしまえば改善出来ることは多いよ。ただ、今回の更改はそんなので良いのか、ということ。」
　「他に考えるべきことがあるということですか。どういうことでしょう。」
　東山が言わんとしていることは何となくわかるような気もするが、はっきりと確認しておきたい。
　「勘定系パッケージが乗る基盤アーキテクチャは、パッケージ要件が前提になると思うので、あまり議論の余地はない。そうするとフロントアーキテクチャ、つまりフレームワークを含めたチャネルレイヤーの検討が中心になる。」
　「そうですね。うちが求めてきた領域そのものかとは思います。」
　「だから、余計に決定打となる方向性が欲しいっていうこと。」
　確かにシステムを刷新するにしても、何を作るのか目的が定まってなければ難しいだろう。
　「志賀さんの話では、ＵＩＵＸやビッグデータ基盤など、経営戦略的な議論が並行していると聞いていましたが、その辺は要件にならないのでしょうか。」
　「ああ、調査レポートの山なら沢山あるけどね。どういう技術があるとか、どこでどんな実績があるかとか、そういうのばかり見せられるんだけど、結局銀行としては何がしたいのか？の話が全くなくて、例えば世界的に展開している某ＥＣショップのような商品構成が良いとか、本当に現実を見ているのか？という気がしてるよ。」
　キックオフで色々夢物語が出てきたと聞いていたが、逆に心配だった部分だ。
　「なるほど。まずは実現したい要件は具体的に何なのか、という議論が必要だと言うことですか。」
　「銀行として、対顧チャネルとしてはどんなことをしたいのか、顧客との関係をどう作るべきか。そういう部分がまだあればね・・。」
　「お気持ちは察します。誰かが決めなければとは思いますが、裏返せば、当社としてもグランドデザインから考えられるということですよね。」
　「そう簡単に言うなや。どんだけ大変やと思ってんねん！」
　関西出身の東山は感情がこもると関西弁になる。この時もよほど周りの丸投げ状態に腹を据えかねたのだろう。
　ただ、逆にそこは東山のプロ根性に火をつけているようにも見えた。事実として、検討を辞めたいという話ではなく、色々と教えてくれているではないか。
　「要件は必ず銀行から出してもらうべきだと思います。ただ、スマート化などと言っている今の時代において、流通大手の親会社でも今の時流でアーキテクチャのガイドラインがあるのではないでしょうか。」
　「確かにあそこは流通という社会基盤があるから、何かのガイドはあるだろうね。でも業界が違いすぎて使い物になるかはわからないよ。聞いてはみるけど。」
　「確かに業界が違うので、サービスレベルがどこで線引きされているのかはわかりませんね。あとは、帝国銀行のとかでしょうか。」
　「まだそっちの方が意味あるし、相談はしやすいと思う。」
　「では帝国銀行のアーキテクチャガイドの参照を銀行にお願いするということで、お願い致します。」
　ＧＣＳＣとして狙っていたフロントアーキテクチャの検討に関われるのは、願ってもないチャンスであり、東山も同じ思いであった。しかしながらこのあと東山は、それまでにやってきたどの仕事以上にも難易度が高く密度の濃い期間を過ごすことになる。
　現行システムの課題を次期アーキテクチャでどのように解決できるのか。未確定であるＵＩＵＸや分析基盤など、今後要件が定まってきた場合にもいかに柔軟に対応できるのか、さらには、銀行が直面しているであろうＦｉｎｔｅｃｈ時代でどう戦っていけるのか。オープンＡＰＩやＯｐｅｎＩＤなどにも対応が迫られるだろう。
　また、ブロックチェーンやＡＩといわれる破壊的イノベーションにはどう取り組むのか。これから変わる世の中に対しても、新たなチャネルデバイスの登場も予見しておかなければならないだろう。考えるだけでもめまいがする技術領域である。ＧＣＳＣ社内を見渡しても、このようなことが出来るのは東山以外にはいないと思う。しかし、東山なら必ず答えを導いてくれるはずだ、と信じるしかなかった。
　その日の午後。東山は朝比奈調査役に呼ばれた。アーキテクチャ検討を進める上での方向性のディスカッションということだった。
　「東山さん、パッケージはパッケージで固めておいて、フロント基盤を別に立てるようにしましょうよ。関連システムからのトランザクションも何とかそこに集約したいし。」
　「そこはマストなのだと思っていますが、ではどんなフロント基盤とするべきか、が明確になっていないと思っています。。」
　「そこは考え放題じゃないですか。ＧＣＳＣさんとしても、狙っているのはフロントチャネルですよね。自社フレームワークとか組み込んでおくチャンスだと思いますよ。その上でフルスクラッチにして、欲しい領域をうまく分割しておけば狙い通りじゃないですか。」
　自分たちがやろうとしていることが読まれている、と東山は苦笑いした。そう、出来れば自社のフレームワークを使う前提にでもして、そのまま不戦勝で進めたい。そうすれば自分たちの目的は半分以上達成だ。ただ自社にはフロントチャネルを前提とした、かつインターネットバンキングという大規模なトランザクションに耐えられるフレームワークは、その時点でも存在しないことを東山は知っていた。
　因みにフルスクラッチとは、パッケージなどの既製品に対する対義語で、一からプログラミングをしていくことを前提とするシステム開発方針のことである。システムに必要な構成要素を自分たちで一つ一つ選び、構築していく。パッケージでは必要なものが一式揃っているためシステム稼働までが早いが、思うような機能を組み込みにくいという特徴がある。これに対しフルスクラッチはその反対の特徴がある。
　「そうできると良いのですがね。自社にはそんなハイスペックなフレームワークはないので、一から考えなきゃならないと思っています。」
　「そうなんですね。天下のＧＣＳＣさんなのに、ないなんて不思議ですね。」
　「インターネットバンキングに使えるのって世の中的にもそんなにないんですよ。冗長化のための仕組みだったり、マルチチャネルの考えを適用しようとしたり、流量制御のためにＡＰサーバの処理を一部持たなければならなかったり。そうするとどうしても他の業界にとって過剰なものになるので。どんなシステムでも使えるような汎用的フレームワークにしようとすると、逆に物足りない感じになりますが、弊社にあるのはまさに後者のものですよ。」
　東山は既にそんなところまで調べ、考えていた。
　「なるほど。いろんな業界を担当されている御社なら、確かにそうなるのは理解できます。では改めてどんなフロントアーキテクチャとするかを考えましょうか。ブラウザのみではないので、今後のＵＩ前提で行くとＳＰＡですかね。」
　ＳＰＡとは、Ｓｉｎｇｌｅ Ｐａｇｅ Ａｐｐｌｉｃａｔｉｏｎの略である。一般的なＷｅｂアプリケーションは画面遷移を前提としたものが主流だが、ＳＰＡでは画面遷移を前提としない単一のページ構成を取りつつ、ページ内のある部分のみ情報を更新しながら、処理を進めていく方式である。画面遷移が発生しないため通信コストやレイアウト開発のコストが低減できるなどのメリットがあり、次の時代のＵＩ手法として注目されている。
　だが東山はそれらの特徴も既に調べていた。
　「ＳＰＡですか。それも考えましたが、やっぱりサービスの規約とかってお客様にきちんと読んでもらって、同意を取りながら進めたいじゃないですか。個人情報の取り扱いとか、情報が沢山あると間違いのもとになりますし。１つの画面で色んな情報出しながらそれをするのはどうしても無理があると思うんですよね。それと、取引認証することを共通的に括り出して、フレームワークの機能として提供しようとすると、どうしても画面遷移の方が都合良いんです。」
　「そうなんですか。」
　朝比奈調査役も知識の宝庫だが、ここは東山の方が深く調査していそうだ。
　「取り扱う情報は商品ごとに違うと思うんですけれど、ＳＰＡだと認証が確定してからのコミットがどうしても複雑になるんです。画面遷移だと、例えば認証画面だけでパターン化できるので、共通化しやすいんです。」
　東山の意見は理路整然としており的を射ていたはずだ。だが朝比奈調査役にも意見はある。
　「でも、画面遷移って画面と情報を制御するプログラムを、画面遷移ごとに作らないとダメなんですよね。ちょっと開発が効率的ではないかなー。」
　そういうと、東山はさらに解決策を示した。
　「そこで目を付けているのが、ＭＶＣ１．０というフレームワークです。」
　「ＭＶＣ１．０ですか。もうすでに実装されてるんでしたっけ？」
　ＭＶＣ１．０とは、Ｊａｖａのフレームワークの１つである。Ｊａｖａは１９９０年代に登場したプログラミング言語で、２０年以上が経過しているが、これまで多くの企業で採用されてきており、サポートするアプリケーションサーバ製品も多い。エンタープライズ向けには多くの実績を持つレガシー技術となっている。
　レガシーというと、「過去の遺産」というイメージもなくはないが、技術として成熟しているということであり、安定感があるという意味で各種のメリットがある。これが開発途上の技術だとすると、数カ月に一回はプログラミング言語の仕様が変わり、そのたびにシステムのプラットフォームを交換しなければならない。
　またセキュリティの脆弱性の発見も多発するだろう。その度にセキュリティパッチを適用しなければならず、大規模システムで採用する場合、運用コストが高くなる可能性がある。Ｊａｖａであればメジャーバージョンアップは１〜２年に１度のみであるため、大規模なシステムでも計画的な保守がしやすいのである。
　「ＭＶＣ１．０は、オープンソースで参照実装が存在するほか、間もなくＪａｖａＥＥの標準仕様としても採用される予定になっています。ターゲットとしては、Ｗｅｂｌｏｇｉｃ（ウェブロジック）の次期バージョンに乗るはずです。」
　「そうなんですね。そうすると、このプロジェクトの開発フェーズが始まる頃には、製品版が出ているということですか？」
　「最新の見通しでは、そうなっています。」
　Ｗｅｂｌｏｇｉｃというのは、Ｏｒａｃｌｅ社のアプリケーションサーバであり、Ｊａｖａを稼働させるうえで不可欠なサーバ製品の１つである。ＪａｖａＥＥとは、それらアプリケーションサーバが採用するＪａｖａの仕様のことであり、バージョン付きで表現する。ＪａｖａＥＥ８というのは、ＪａｖａＥＥのバージョン８ということになる。アプリケーションサーバ製品としてどのＪａｖａＥＥバージョンを採用するかということは、ガラケーを買うかスマホを買うかの違いくらい、基本機能が異なる関心ごとなのだ。
　話を二人の会話に戻そう。まだ東山の説明が続いていた。
　「ＭＶＣ１．０が利用できれば、画面遷移でも開発効率は遅くなりません。むしろＡＰＩバンキングを視野に入れると、ＳＰＡより効率的に開発を進められます。」
　「ＡＰＩバンキング・・・確かに、ＳＰＡはブラウザなど画面を持つという前提でのものでしたね。勘定系システムは関連システムとのインターフェースが沢山ありますし、それを考えるとＡＰＩごとに完結するステートレスな処理を担保する必要がある。逆に入力フォーマットに縛られないＭＶＣ１．０の仕組みを前提に出来れば、ＡＰＩバンキングを本格的に始めようとしても簡単に拡張出来るということ・・？」
　うまく話が誘導できていると、東山は満足げに答えた。
　「その通りです。Ｊａｖａのスペックリードを行うコミュニティで、ＭＶＣ１．０の仕様がこの夏に確定したところですが、ＪａｖａＥＥのリリースに乗るかどうかはまだわかりません。でも今の流れのまま決まればＪａｖａＥＥ８に載ることが確定となり、それを搭載するＷｅｂｌｏｇｉｃがちょうど２０１８年に登場し、我々はそれを前提に開発をすれば良いことになります。」
　頭の切れる朝比奈調査役も、少し理解が追い付かない。
　「えーと・・少し整理させてくださいね。２０１８年といえば、このプロジェクトの要件定義フェーズが始まる年だから、ちょうどその時点でリリースされている最新のＷｅｂｌｏｇｉｃを採用すれば、自ずとＭＶＣ１．０がついてくるということ？」
　ようやく目的の議論に到達したと、東山は満足げに答えた。
　「まさにその通りです。。」
　「そんな状況なのですね！次期システムにとってジャストインタイムではないですか。なんだ、東山さんめちゃめちゃ考えているじゃないですか。もうその方向で進めましょうよ。話を聞いていたら、絶対そうなりそう。というか、それしかないと思いましたよ。ははは。」
　この時の二人の会話についていける人はごく限られていただろう。東山も東山なら、朝比奈調査役も技術にはとても詳しい。
　ここで二人に代わってＭＶＣ１．０についてもう少し解説しておくと、Ｗｅｂアプリケーションを開発するためのＪａｖａフレームワークのことである。ＡＰＩエコノミーという言葉があるが、そのベースとなる通信上の電文形式で、ＪＳＯＮやＸＭＬなど、あらゆるインターフェースに対応した業務プログラムが簡単に開発できる仕組みが提供される。
　「簡単に」というのは、ＷＥＢアプリケーションであれば必ず必要となる、画面の開発、入力チェック、エラー制御、入力情報のプログラムへの自動格納などの機能が標準で提供されるため、システムの開発者にとって開発効率が良い。長らくシステム業界はブラック業界だと批判されてきたが、このようなアーキテクチャ改善の取り組みによって、エンジニアの生産性は劇的に改善していくものだ。
　かぞく銀行としても、今からＭＶＣ１．０を採用しておけば、ＡＰＩ連携が当たり前となる時代が来たときに、顧客向けサービスが効率的に拡張出来るはずだ、という事をふたりは喋っていた。
　要件が見えない中でどのようなアーキテクチャとするべきか。東山の中では、将来の銀行が抱える課題に基けば、自ずと答えは出ていたのであった。さらにそこに朝比奈調査役が同調してくれているとは、まさに鬼に金棒である。
　再び二人の話を聞こう。東山が続ける。
　「思った通りに行くと良いのですがね・・・ポイントとなるのはＪａｖａＥＥ８に関する、２０１７年３月のアーリードラフトレビュー（ＥＤＲ）３です。ＪａｖａＥＥの仕様は、スペックリードで示されたドラフトに対して主要メーカーなどが投票する形で決まっていきますが、ＥＤＲで通過した仕様はその後のパブリックレビューでもほとんどと言って良いほど通過しています。。」
　「つまり、このままＥＤＲ３を通過すれば、ＪａｖａＥＥ８に実装されることは間違いない、と言うことですね。」
　今は可能性でしかなかったのだが、東山としては一旦この場での結論は出しておきたい。
　「恐らく。ＥＤＲ２は先月問題なく通過しましたので、ＥＤＲ３もこのまま行くんじゃないかと思っています。結局のところ、フロントアーキテクチャはＷｅｂｌｏｇｉｃとＭＶＣ１．０を前提に設計を進めておきたいと思っていますが、宜しいでしょうか。」
　「わかりました。その方針で行きましょう。ではＪａｖａＥＥコミュニティの状況ウォッチは引き続きお願いします。ここまでのところは、ＧＣＳＣさんのシナリオ通りっていうことですね。笑。」
　東山は以前姫宮に対して、要件がないとこぼしていたが、どうやら頭の中では「アーキテクチャの構想」は既にあったらしい。問題はそれらを銀行経営陣に説明する際、どのように理解を得るかということだろう。
　どれになるかわからないが、既に勘定系システムはパッケージを使うことが決まっている。インターネットバンキングもその機能として標準的に備えているものは多い。それをわざわざ、フルスクラッチという、一から構築するグランドデザインを描こうとしているのだ。どうやってそれを理由づけるのか。朝比奈調査役の強力な後押しは得られるとして、銀行の経営陣にとっては明確な理由が必要である。さらに言えばそれは銀行の戦略を進めるために必要なのだと説明できれば、揺るがない大義になるはずだ。
　東山は改めて、今の時代の、そして将来の銀行業界の役割を考え直してみた。世の中インターネット経由で手続きが出来るのはもはや当たり前である。さらに、フィンテック事業者がＡＰＩという通信概念で自由に銀行システムにアクセスしてくる。ＡＰＩを境界として、事業者と銀行との責務が明確になる。その時の銀行の責務とは何なのか？
　そもそも勘定系とは、預金・為替・融資という銀行三大業務がベースになっている。対してフィンテックは、スマホやスピーカー、ＡＩオペレーターなどのチャネル系サービスと、ロボアドバイザーやＰＦＭ、ＡＩ融資などのクロスインダストリー系、さらに小規模決済のペイメント系などがある。他にも色々あるが、顧客が利用したいサービスは全て銀行の外側に存在している、ということだろう。ではこの時に銀行とは、一体どんな存在だと言えるのだろうか？
　そうこう考えながら年は変わり、日付は２０１７年の１月を迎えた。
　システムエンジニアにとって、その仕事のスタイルは様々である。
　・黙々とパソコンに向かい、何かを書いては消すことを繰り返して、結局何も出来てない人。
　・エクセルの書式ばかりを一生懸命設定している人。
　・情報を表などに整理して論理的に考え、ホワイトスペースを埋めながら答えを導く人。
　・散歩に出かけるなど気分転換を図り、何か閃いたと思ったら瞬発的に成果物を作り上げる人。
　この辺りが初級から上級エンジニアが行う仕事のスタイルだろう。志賀はこの中で三番目、東山は四番目のスタイルと言える。東山は散歩というより喫煙ルームで閃くことが多いようだが、このテーマのために何度喫煙ルームに通ったかはわからない。
　ただ、喫煙ルームというのは気分転換以外にも思わぬ収穫を得ることがある。役職者や役員などには未だに喫煙者は多く、銀行のキーマンからオフレコ情報を含む話が直接聞ける可能性があるのだ。
　年始も東山は朝から喫煙ルームにいたところ、かぞく銀行の赤魚本部長が入ってきた。
　「やあ東山さん。検討は順調ですか。」
　「どうも。何となく方向性は見えてきているんですが、決め手がなかなかですね。」
　「マーケ部も、ＵＩＵＸの件では色々な情報に翻弄されているようですが、今しばらく要件が確定しないと思います。なので柔軟に対応できるようなアーキテクチャにしておく、というところまでですかね。」
　「その柔軟性も、銀行としてどこまで持たせるべきなのかってとこですね。画面は変えたいニーズは最後まであるのでしょうが、プリミティブな銀行業務は変わらないでしょうし、何が変わって、何が変わらないかってことを整理しています。」
　「そうですか。あとＶｏＣを含む分析系は、ほぼＤＷＨで行いますので、フロントとしてはチャネルに特化して良いように思いますけどね。」
　「そうですね。その時に、チャネルに何が求められるか、というところを、もう少し色々見ながらアーキテクチャレベルで整理したいと思っています。」
　ＤＷＨとはデータウェアハウスのことで、システムに記録された膨大なデータを、意味のある単位で整理して分析などに利用する仕組みである。キックオフの時にＶｏＣ（Ｖｏｉｃｅ　ｏｆ　Ｃｕｓｔｏｍｅｒ）という部署がいたが、顧客の声をサービス改善に繋げるにあたり、ＤＷＨという分析基盤が重要になってくる。
　これらの話により、東山のすべきことは絞られつつあった。そして赤魚からある提案がなされた。
　「なるほど。了解しました。あと参考になるかわかりませんが、帝国銀行のフレームワークの情報もあったら見てみますか？」
　東山にとっては前向きな情報であった。
　「そうですね。ちょうど姫宮とも話していたんですが、閲覧可能なようであれば見ておきたいです。メガバンクとは違いがありますので、そのままというわけには行かないでしょうが、業務系の機能部品は早めに設計しておきたいと思っていますので。」
　「わかりました。問い合わせてみましょう。当行も帝国銀行から出向者を受け入れていますので、彼らの意見も聞かないわけにはいきません。朝比奈はフロントシステムはスクラッチで確定のつもりのようですが、越えないとならないハードルが沢山ありますので、今から固めに行くことも重要なんです。」
　銀行は銀行のしがらみの中で大変なのだと思いながら、東山は返答した。
　「はい、そこはかぞく銀行さんとして冷静にご判断頂ければ良いと思っています。」
　「まあ、それはそうですよね。我々も当然しっかり現場の意見を受け止めて検討しますので、宜しくお願いします。」
　赤魚本部長も帝国銀行からの出向者だ。かぞく銀行内の役職はかなり上だが、彼の上司は二人いるということになる。そしてこのような率直が意見が聞けるのも喫煙ルームならではであり、何か相談する上でとても都合が良かった。
　一方、この頃の志賀は、パッケージ選定に向けた論点表の作成に勤しんでいた。一つ一つの成果物に対し、朝比奈調査役からいちいち「何故こうなのか？」と質問され、そのための回答を考える毎日が続いた。
　このフェーズにおける仕事の特徴は、一人で正確な物を黙々と作るというより、ドラフトを作り、それに対して関係者からフィードバックを受け、修正しながら進めるというやり方が適している。形のないところから物事を作っていく際の進め方である。ドラフトを作成し、フィードバックを受け、それに対する修正を、最終的に相手が納得いくものになるまで繰り返していく必要がある。
　と同時に、このやり方は扱う相手が人間だけに人間関係のストレスも生じやすい。実際二人の作る成果物の完成基準は自分ではなく銀行が決めることになるため、会話をしながらその基準を引き出すことが必要であり、非常に高いコミュニケーション力を要した。
　時に銀行員の話に合わせながら思うままに喋らせ、関心を伺い、議論のたたき台となる物を作り、不十分なら聞き方を変えて質問する。それに対して小言のようなことも言われるということを繰り返した。
　そのため二人は銀行に指摘されると考え直すか、意見を通すかということを常に判断しなければならなかった。意見がぶつかったり、真逆の考えになっていたりする場合、こちらが意見を引っ込めればその場は穏便に進むだろうが、結果的に誤った判断になるかもしれない。押せば意見を通せるかもしれないが後味の悪さは残るだろう。
　遠くの一点にある光を目指しながら、一人で歩く綱渡りのような日々。少しでも気を緩めればそこからいつ落ちてもおかしくない精神状況であった。その中で二人は精神をすり減らさないようにと、自分の信念と事実のみを頼りに、バランスを取りながら一歩ずつ歩みを進めていた。
　銀行の期待との狭間の中でバランスを取り、かつスケジュールを守っていくということは、料理を味合う前に飲み込まなければならないような、何とも言えない消化不良の状態になる。そして、この時２人の中に存在したそのもどかしさは、志賀、東山の間だけの共通のコミュニケーションなのであった。
　自然と二人は、毎日のように飲みに行った。
　１２月の年末が差し迫る中、プチ忘年会と称してその日も近くの焼き鳥屋に行った。
　「東山さん、最近なんかやつれていませんか？」
　「志賀さん、分かりますか。なかなかしっくりくるような整理が出来ずにいて。」
　「銀行さんもやりたいことは多いはずですからね。うまく整理できると良いのですが。ただ我々がこのような場に立ち会えているのは、本当に幸せです。」
　「そのセリフ、キックオフのあとに私が言ったやつですね。笑」
　「そうでしたっけ。ははは。」
　この時ばかりは、二人で傷をなめ合うことが唯一の気休めとなった。
　「東山さん、それにしても、このお店、焼き鳥屋なのに色んなメニューがありますよ。特選バラエティー串盛りだなんて。面白そうだから、一つ頼んでみましょうか。」
　「良いですね。行きましょう。」
　それからしばらくして、店員が特選バラエティー串盛りを持ってきた。
　「ほー、なるほど。確かにこれはバラエティ豊かですね。」
　何気ないお店の料理だったが、このときの志賀に安らぎを感じさせるには十分だった。
　そこには、５本の串しかないのだが、鶏皮、もも、ささみ、レバーなどの鶏肉と、色々な食材とを組み合わせた串料理が並べられていた。それを嬉しそうに志賀が分析し始めた。
　「東山さん見てくださいよ。鶏皮と鶏皮の間に、ネギ、キュウリ、ワカメが入れ替わりで挟んであります。まるで鶏皮ポン酢が串になったみたいですね。」
　「確かに。こっちのは玉ねぎの薄切り、ニンニクスライス、ミョウガが挟んであります。焼き鳥というかポン酢に合う食材を串刺しにして、焼き鳥ではない新しい料理にしたみたいですね。」
　「こっちの串も面白いですよ。ささみをざく切りにしたつくねを大葉で巻いたチーズで挟んで、味噌を塗って焼いてある。これも味噌にあう食材の組み合わせですね。」
　このお店の特徴である特選バラエティー串盛りは、焼き鳥という固定概念にとらわれない発想により、ユニークなメニューを提供していた。
　「面白いですよね。一つ一つは焼き鳥屋であればどこにでもある食材なのに、組み合わせだけで普通の焼き鳥と全く異なる料理になったみたいで。」
　そう言われると、東山は少し考え込んだ。
　「・・・」
　東山はしばらくそれらの串を眺めながら、その料理の食材一つ一つが何なのかを確認していた。
　「・・なるほど。これは、大発見かもしれない。」
　「えっ？」
　志賀が驚いたように反応する。
　「いや、このメニュー、ただの串なんですよ。焼き鳥を少しひねった。でも、これこそが期待していたものかもしれない。」
　「どういうことですか？」
　志賀は不意打ちにでもあったように驚きながら質問した。それもそうだ。焼き鳥を見て大発見とは、なにやら新しいメニューでも閃いたのだろうか。この時の会話の流れと想定外の言葉に、むしろ不意を打たれずにはいられなかった。当の東山は自信気に説明する。
　「焼き鳥屋として用意しているのは、ただの焼き鳥の食材なんです。でも、それらの組み合わせ方をちょっと変えさえすれば、新しい料理が出来るということです。単なる焼き鳥と同じ食材だったのに、組み合わせを変えるだけで、お客さんにとっては新しい価値が提供出来ているわけです。」
　「確かに、焼き鳥界のイノベーションってとこですか！」
　何を言い出すのかと思えば、イノベーションの話かと、志賀はニヤけた。イノベーションであれば、志賀を置いて議論好きはいない。
　だがそんな単純なことでもなさそうだ。東山が続ける。
　「そのイノベーションは、結局人間が考えることであって、焼き鳥屋の機能としては、依然として皮、もも、レバー、野菜などを仕入れ、保管し、焼いているだけです。」
　再確認するように志賀も応じた。
　「普通に調理された食材を、どう組み合わせるかで新しい価値が作り出されるということですよね。確かに面白い発想です。何でもごちゃまぜにすると味もへったくれもなさそうですが、ポン酢や味噌など、味付けの方向性としても組み合わせが合理的だし、納得できる。何よりうまいことがその正しさを証明していますよね。」
　志賀は志賀で、目の前の料理を如何にイノベーションだと説明するか一生懸命考えていた。だが東山が指したのは、そこではなかったらしい。
　「焼き鳥屋に例えて言いましたけど、大発見といったのは、これからの銀行に求められるのは、まさにこういった、組み合わせる力ってことなんじゃないかと思うんです。」
　「銀行も組み合わせですか。イノベーションが必要という意味では、どの業界も不可欠ですからね。」
　志賀はまだ言われたことの本質に気づいていないようだ。
「それは銀行戦略やマーケティングの課題ですが、いずれにしてもその経営課題は時代が変わってもずっと無くならないと思うんです。その時に求められるアーキテクチャこそ、どのような組み合わせにも耐えられることではないのかって、これ見てて思いました。」
　「え？アーキテクチャの観点から、焼き鳥を見てたんですか！？なんて人だ・・・。」
　焼き鳥からアーキテクチャに飛躍するとは、志賀は今度こそ不意を打たれた。
　「本質的には同じです。焼き鳥の場合は鶏肉と焼くための機械、串など、基本的な機能はこの先もきっと変わらないでしょう。変わるのは人間の思考であって、その時に新しい組み合わせができるように保管されていることが重要なんです。組み合わせをするにはＡＰＩだけじゃなくて、銀行としての鶏肉、つまりデータを意味のある単位で整理し管理しておくことが、最低限銀行の役割として行き着くところなんじゃないかと、気づきました。」
　「確かに、ＡＰＩとは通信経路のようなものですからね。銀行としては何をどのような形で保管しておくのかが大切ですね。フロントと勘定系の責務の違いと同じなのだと理解しました。そうするとフロントチャネルというのは、組み合わせた結果を載せるところだから、その役割は串とお皿といったところでしょうか。」
　志賀もこの話の理屈をうまく説明しようとしたが、やはり焼き鳥に例えるのが精一杯であった。
　逆に東山が志賀の理解に解釈を添える。
　「恐らくそう表現するのであっていると思います。フロントチャネルは組み合わせた結果が如何に活用できるかに意味があって、そのため速やかに、間違いなく、見た目重視で必要な時に機能提供するのが役割になっていくということです。」
　「なるほど。フロントは料理としての表現にこだわる。勘定系は、材料であるデータをいつでも好きなように取り出せるようになっていることがそれぞれの役割、ということですか。」
　「組み合わせるのは人であり、場としてのフロントチャネルですから、勘定系にはデータが正しく保管出来ていれば良いです。もっというと、データの保管状態はパッケージでも何でも任せていれば良くて、取り出したときに加工しやすいかどうか。つまり、ＡＰＩがデータと補助機能を担保出来ているか、ということが重要です。」
　まだ半信半疑の志賀が自分に再確認させるように質問する。
　「ＡＰＩさえしっかり準備されていれば、データの保管形態はある意味お任せでも良いということですか？」
　「極論ですけどね。もちろん、検索時の性能とか、不整合が発生しないような安全性を担保する必要はありますが、そういうのは逆に勘定系パッケージは得意なはずですので。」
　志賀もここまで話して、何が大発見なのかがわかった気になった。フロントチャネルというのは、ブラウザに画面を出す以外になんの役割があるのだろうと自分でも腹落ちしない感じはあったが、言われたように考えると、自ずと必要な機能も定義できそうだ。
　志賀としてもこの考え方に希望をもてそうだった。
　「なんだか、面白くなってきましたね。フロントチャネルは何も持たない以上、土管のような空っぽの存在と思っていましたが、顧客マーケティングとしての位置づけを考えると、とても重要なのですね。」
　「そう。ただしばらくは土管が続きそうですが、絶対不可欠なものになっていくでしょう。」
　「それにしても東山さん、焼き鳥からアーキテクチャを考えるなんてさすがです。さながらヤキトリのアーキテクチャですね！」
　「へへへ。暫定１位になりうる名称ですね。」
　今日の焼き鳥屋での発見は、大きな収穫に繋がりそうだ。二人に安堵の表情が戻ってきた。
　「東山さん、そういえばもう一つ面白いことに気付きました。」
　「どうしたんですか？」
　「いや、私の役割って、コンサルではありますが、社内的にはこの現場の管理者も兼ねているじゃないですか。つまりゼネラリストであって、広く浅く漏れなく拾っていくっていうのが私の仕事のはずなんです。東山さんはその真逆で完全なスペシャリストなので、仕事も一本際立った成果を上げていくというスタイルのはずで。」
　「そうですね。」
　それがどうしたのだろうと、不思議に思いながら東山が確認する。
　「ところがどうですか。この焼き鳥の食べ方は。私は一本食べきるまで次の串に手を付けないのに、東山さんは少しずつ多くの串に手を出している。これって仕事と全く逆の進め方ですよね。」
　「・・・。」
　東山はそう言われしばらく考えた。
　「ふふふ。志賀さんは気持ちの中では、一つ一つを確り処理して次に進みたい、という心の表れなんでしょう。私もスペシャリストに見えますが、頭の中では結構色んな事を見ているのですよ。志賀さんの今日のネクタイ、４日目ですよね。」
　「えっ！？バレてましたか！というか４日間も身に付けているなんて、私自身全く気が付いてなかったですよ・・。」
　「そう。結構見てるんですよ。」
　「ははは。東山さんには、一生かないません。」
　いつものように慰め合うつもりが、焼き鳥屋のビジネスモデルから思わぬヒントをつかんだ。これはのちにＳｏＥ／ＳｏＲアーキテクチャとして、勘定系システムにおける重要な構成になる。
　技術のない大義は無意味だが、大義なき技術もまた無意味であろう。両者揃ってこその勘定系更改であり、大義は明確に描けそうだ。次はＭＶＣ１．０がＪａｖａＥＥ８に採用されるかどうかに委ねられた。