６　かぞく銀行次期システムプロジェクト

　２０１８年７月３日。
　会社のある新橋駅から浅草線で終着駅。かっぱ橋本通りで毎年行われる七夕祭りの準備が、この年の夏の本格到来を感じさせた。
　そしてこの日、姫宮とプロジェクトメンバー１０名は、その浅草駅にあるかぞく銀行のオフィスに立った。
　「これから４年間、お世話になります。全員で一致団結して良いものを作って参りますので、宜しくお願い致します。」
　軽い挨拶を交わし、自分のために用意された執務席に着く。
　この日姫宮とともに着任したのは、この先の物語を作っていくレインフォースのメンバーたち。提案、受注を経てプロジェクト開始日が今日に決まり、無事にこの日を迎えることが出来た。着任したメンバーは、以下のチーム編成からなる１０数名である。今後の主役たちを紹介しておこう。

・基盤フレームワーク
　神城をリーダーとする、Ｊａｖａの少数精鋭な技術者からなるチームである。開発を担うのは、中堅ベンダーであるイージー技術者集団のメンバーたちだ。
　彼らは中国系企業であり帝国銀行子会社のＳＩｅｒで、これまでフレームワークなどコアな機能の開発実績を持っていた。このプロジェクトでも主要な基盤フレームワークを担当するのだが、南町専務の指摘にあったように、帝国銀行のフレームワークを出来るだけ流用しながら開発を進めてもらうことになった。
　インターネットバンキングは一般的に大規模でミッションクリティカルなシステムであり、その仕組みを作るのはなかなか経験出来るものでは無い。さらにこのプロジェクトにおいては帝国銀行のフレームワークにも精通している必要があるため、彼らはまさにうってつけの存在だった。
　そのイージー技術者集団のリーダーは李といった。李は、１５年前に大学卒業とともにイージーに就職して以来、ひたすらＪａｖａの機能開発に従事してきた。その中には帝国銀行のインターネットバンキングシステムの開発実績もあり、とにかくＪａｖａが好きな技術オタクであった。
　このプロジェクトにおいて帝国銀行のフレームワークを使う必要が発生した際に、かぞく銀行の赤魚本部長から紹介してもらったのが最初の縁だった。その李には提案の時から協力してもらったが、他のチームが見積りに苦労する中、彼らの見積は終始ブレることはなかった。
　着任にあたり、李が姫宮に挨拶をしにやって来た。
　「姫宮さん、今日から宜しくお願いします。暫くはＲＦＰに従って進めて行きますね。チームとしては神城さんがリーダーということですが、出来るだけお手を煩わせることがないようにします。」
　「こちらこそ、頼り切ってしまうかと思いますが、ＧＣＳＣ社員になったつもりで宜しくお願いします。」
　中堅ベンダーといっても、基盤フレームワークを担えるのは彼らしかいない。その意味では契約は異なるが、この先ほぼ一括請負のような分担で進めてもらうことになりそうだ。
・業務アプリケーションチーム
　セキュリティ機能、および円定期預金を担う業務アプリは、中井がリーダーとなり、設計・開発は中堅ベンダーのサクセス社が担当することとなった。
　中井はこれまで銀行の行内システムに関する開発プロジェクトの経験があるが、インターネットバンキングについては初めてだ。それに対しサクセス社はいくつかの銀行でその領域の開発経験があり、このプロジェクトには会社の主要取引先ということで購買部より紹介されたのが始まりであった。
　中井のキャリアは入社以来の銀行システム担当で、大手銀行のシステム開発プロジェクトリーダーを経験してきた。インターネットバンキングこそ経験はなかったが、銀行システムに求められる基本的な要求事項や、銀行とのプロジェクトの進め方など、お作法から行内業務まで幅広く経験してきた。
　また、仕事の正確さがズバ抜けており、彼が面倒を見てきたシステムでは抜け漏れなく設計管理され、高い品質を保っていた。リーダーとしてチームの作業も段取りよくまとめ、無駄なく安定的に運営出来るのが特徴的な人物だ。
　このプロジェクトでは仕様の定まっていないセキュリティ要件にリスクがあったため、仕様を段取りよく決めることと、サクセス社を含めた包括的なチーム運営を行うことが期待された。
　そのサクセス社のリーダー川平は転職組で、３０歳にしてこれまで４社を渡り歩いてきたという。いずれも中堅ベンダーのＳＩｅｒであり、大手ＳＩｅｒの下請けの立場として主に開発を担当してきた。逆に顧客と直接の接点を持ったことはなかった。
　このチームはインターネットバンキングの開発に得意なサクセス社と、安定的なマネジメントを行う中井とが相互に補完関係となることで、全体として必要な役割が揃っていた。
・業務共通チーム
　そしてこのプロジェクト最大の関門である、業務共通チーム。
　何が関門かというと、システムの共通機能を開発するということは、色々な業務アプリケーションに使ってもらう前提となる機能群を作るという意味で、どのような業務仕様があるのかを横断的に把握しておく必要がある。その上で、開発者が開発するＪａｖａクラスとはどのような構造になっているのかを理解し、どこを共通機能とするべきかを検討する。
　そのため基盤フレームワークチームが設計するアーキテクチャを誰より早く理解しておき、開発者が作業を進めやすいよう、Ｊａｖａクラスのモデルを意識したり、共通機能の不具合が業務アプリケーションに波及したりしないように非機能面や耐障害性などを考慮して設計していくことが求められる。
　さらに彼らのアウトプットは必然的に業務アプリ開発者が設計を開始する時点で存在していなければならないため、スケジュールも全体に対して先行し、要所要所で提供していく必要があるのだ。
　このような動きが期待されることから、業務共通チームに求められるスキルとは、Ｊａｖａなどの技術要素だけでなく、業務全体を横断的に把握する力、汎用化や概念化する力、非機能要求を設計する力、様々なドキュメントを読み解く読解力、ステークホルダーに対するヒアリング能力、文書として起こし、伝える能力、開発者としての経験、スケジュールなどのプロジェクト管理能力、などなど、数え上げればキリがない。
　他のチームもそれぞれ難しさはあるが、どちらかというと特定の領域に集中していれば良いのに対し、共通というのはそもそも言葉の定義が曖昧で、境目がない概念程度のものだ。そのため自分たちで境界を作っていくことから始めなければならない。これはもはや知識というより、熟練度がモノをいう職人の世界なのだ。
　そんな関門だらけの業務共通チームに着任したのは、提案から関わる大島のほか、業務アプリケーション開発経験者の小岳、派遣エンジニアの高橋であった。唯一この領域の経験があったのは大島のみ、高橋は経験中、小岳は見習い、といったところである。頼みの大島についても、前のプロジェクトの引き継ぎが終わらず、暫くは月に半分ほどの割合での参画となっていた。
　このような状況から、業務共通チームの体制を作っていくことは最大の関門であった。
　さすがにこれでは進めるべきものが進まない。姫宮は事前に体制を強化しておくため、社内で他に適任者がいないか隈なく探してきた。だが結局インターネットバンキング、業務共通機能経験者という括りではほぼ存在しないか、いたとしても異動が難しいかのどちらかであった。
　どうしようかと思案しながら、あらゆる人脈を頼った結果、着任１ヶ月前となった時、元社員でインターネットバンキング開発の経験があり、今は転職活動中だという神津氏に、コンタクトが取れた。彼は１０年前に退職したのだが、当時のスキルであれば経験も豊富でありプロジェクトにとって十分な補強になる。
　他に当ても無く藁にも縋りたい思いしかなかった中で、お互いの近況を聞くという体裁にし、魚見で久しぶりに落ち合うことにした。

　１ヶ月前―
　「神津さん、お久しぶりです！最近調子はいかがですか？」
　「ああ、ぼちぼちですよ。それより何か大変なことに取り組んでいるそうですね。」
　神津は以前と変わらぬ落ち着きで答えた。姫宮よりも２つ年上であるが、少しふっくらとした容貌は年を取ったことを感じさせず、まだ働き盛りという印象を受ける。
　「お耳が早いですね。実はそのことでご相談があるんです。」
　「ふふっ。噂は御社の南町専務から聞きましたよ。一体どうしたんでしょう？」
　そう、１５年前に南町専務が現場で奮闘していた時期に、神津・姫宮も同じプロジェクトで過ごしていた。南町専務は神津との関係を維持しながら、プロジェクトの人集めに困っている状況を見て、頭出ししてくれていたようだ。
　「単刀直入のお願いになるのですが、会社に戻ってきては頂けないでしょうか。次のプロジェクトがそれなりに大規模であり、業務共通領域でエンジニアを求めています。条件について現状より悪くなることはありませんし、会社も再チャレンジを推進しており、他のＳＩｅｒに行かれるよりは悪い話ではないと思います。」
　神津は目の前のコップに入ったビールを一気に飲みほし、しばらく考え込んだ。そして深く呼吸をした後に、思い詰めた表情で口を開いた。
　「うーん・・実は、ここに来る前に妻と話していたんです。わざわざ１０年ぶりに呼び出されるって何事だろうって。妻は１年前に大病を患ったんですけど、それ以来『縁を大事にしなさい』ってことを言うんですよね。で、今回の話も、ひょっとしたら何かのご縁に繋がるものがあるんじゃないかって、言われて来たんです。」
　「奥様は大変な状況だったのですね。。」
　「後遺症が残ったものの、病は治ったんですけどね。私も日々を淡々と働いて過ごしてきたというより、やはり人とのご縁や繋がりで今の自分があると思っているんです。姫宮さんの話を聞いていたら、今日、こうして呼ばれたというのは自分の将来にとって必要な縁なのかもしれないなと感じながら聞いていました。」
　予想外の展開に、姫宮の方が内心動揺せずにいられなかった。会社を辞めた人にこのような話をしても、気持ちはこちらを向いていないことがほとんどだ。それをまさかご縁と受け止めてくれるだなんて。今日の話の暗示を与えてくれた奥様には大感謝しかない。
　「そうだったのですか。ご縁を頼りに生きているのは、むしろ私の方なのです。こうしてお会いしようと考えたのも、もう一度過去の人脈に当たってみたいと考えた結論でしたし、まさか南町専務が頭出ししていたなんて思ってもいませんでしたけど。つまり、ということは・・？」
　奥様のことも正直に話してくれたことに、姫宮は神津の話を純粋な気持ちと受け止めた。その上で、改めて意思を確認してみた。
　「ただし、少しだけ考えさせてください。確かにインターネットバンキングはやっていましたが、業務共通となると私も触ったくらいの経験です。条件等は現職を保証して頂けるのであればそれ以上は望みませんが、やはり大変そうなプロジェクトということと、妻も後遺症をかかえながらであるため、夫婦としての覚悟が必要になると思っています。」
　「もちろんです。会社に戻って頂くことは神津さんのキャリアや、将来のためになるという前提ですので、確りお考えいただいて、またご感想を伺いたいと思います。」
　他にいくつかプロジェクトに関する情報を共有したが、仔細を説明せずとも、どんなプロジェクトになりそうなのか、何が課題になっているのかわかってもらえたようだ。
　神津がインターネットバンキングの開発プロジェクトを経験していた時は、預金為替を担当していた。もし仮に業務共通チームの体制が大島を筆頭に成功裏に立ち上がれば、神津は手持ち無沙汰となるかもしれないが、そのまま業務チームに転用だってできる。今日の交渉が成功すれば、かなり成功確率は上がると言えるだろう。
業務共通チームはこのように、プロジェクトがスタートする直前まで綱渡りな状態のまま過ごしていた。
　主要チームとしては以上なのだが、プロジェクト体制は他にもある。忘れぬうちに続けよう。
・ガイドチーム
　フレームワークとは、業務アプリケーション開発者が効率的にシステムを構築するための機能であるということは何度も書いた。ガイドチームはその一部を担い、フレームワークの使い方や設計情報などを開発者に適切に伝えるため、体系立てたドキュメントを書き起こすことが主要なミッションである。その範囲は、単にフレームワーク機能の説明にとどまらず、利用に必要な開発環境の構築手順、利用者のためのユーザーズガイド、実際の開発ガイド、業務アプリケーションのテスト手順、テスト支援ツール説明書、コーディング規約、などの作成が含まれる。このチームも専門性という意味では、基盤フレームワークに次いでＪａｖａの高いスキルが求められた。
　リーダーは長澤。彼は過去に開発推進という立場で複数プロジェクトの立ち上げを経験しており、技術力は高い。コミュニケーションはやや苦手だが、ガイドチームは少数精鋭で進めるため、彼自身がプレイヤーとしてアウトプットを作ってもらえれば問題はなさそうであった。
・ＰＭＯチーム
　ＧＣＳＣ社体制の最後はＰＭＯチームである。ＰＭＯとはプロジェクト・マネジメント・オフィスの略で、プロジェクトが円滑に運営できるよう、進捗管理や品質管理、要員管理などを組織的に行う役割のことである。プロジェクトマネージャ（ＰＭ）は姫宮が担っているが、ＰＭは事あるごとに判断を行うポジションであり、日々の運営管理はＰＭＯが主体となって行うことになる。ただ、管理状況は逐一ＰＭと共有されるため、基本的にＰＭとＰＭＯは一心同体の関係だ。そのＰＭＯには、池田と事務スタッフの２人が担当することになった。
　池田はシステム開発のプロジェクト管理経験があまりないが、保守サービスにおけるカスタマーサービスの責任者を多く経験していた。このプロジェクトは、彼の今後のキャリアを考えて、少しでも開発管理の実績が詰めるようにとＰＭＯにアサインしたのだった。
　以上がＧＣＳＣ社のプロジェクト初期体制である。これに対し、銀行側の体制は次のようになっている。
・プロジェクト全体統括
　総責任者はかぞく銀行の海鳥取締役、その直下にプロジェクト責任者の赤魚システム本部長、熊手システム開発部長と続く。このラインでプロジェクトに関する一切の舵取りと意思決定を行うことになる。海鳥取締役は流通親会社の出身であり、マーケティングに詳しい。赤魚本部長と熊手部長は帝国銀行出身であり、銀行業務には詳しい。
　企画段階で舵取りしてきた犬澤執行役員は、役職定年が決まっており、関連会社へ出向となっていた。そのため既にプロジェクトからは退いていた。
・フレームワークチーム
　かぞく銀行システム部に所属するチームである。銀行でフレームワークとは多少違和感があるが、フレームワークは他チームと沢山コミュニケーションを取りながら進める必要がある。そのため他チームとの窓口となり、調整機能を担うのが銀行フレームワークチームの役割だ。ＧＣＳＣの基盤フレームワークと業務共通チームのカウンターとなっていた。
　このチームのリーダーは朝比奈調査役であった。以前も触れたが、彼は外資系ＩＴ企業出身で、理論家である。頭脳明晰で若くしてとても優秀だが、自分が納得するまでとことん理詰めをするタイプで、これまで幾度となくベンダーを泣かせてきた。この物語の企画段階で、志賀や東山が何度か詰められてきたが、相手をする側も論理思考が備わっていないと、苦労しそうなチームであった。
　その配下には、若手行員である牛元主任が着いた。銀行という役割も時代と共に変わるものだ。銀行員として就職したかぞく銀行で、まさかフレームワークという、Ｊａｖａ技術の、しかもコアなシステムの面倒を見ることになろうとは。この時置かれた立場についてどのように受け止めていたのか、いつか聞いてみたい。
・業務チーム
　同じく銀行システム部である業務チームは、預金為替や円定期預金、セキュリティ、外貨預金、決済システムなどの業務要件、及びシステム仕様を統括する。銀行の事務は業務ごとに手順が明確に定められ、コンプライアンス違反がないように役割分担、権限が明確になっている。それらを踏まえつつ、各業務機能の仕様、勘定系とフロントシステムの役割分担、関連システムとのインターフェース調整などを行っていく必要がある。このチームは言わば銀行の要となるチームであり、コンプライアンス関連の部門、事務部門、マーケティング部門などから次期システムに対する要求を合意し、ベンダーに伝え、システムに確実に組み込まれるところまでを担保する責任がある。
　逆にベンダーからの意見や提案があれば、それを逆方向に調整していく必要もあり、高度なコミュニケーション力、業務知識に加え、意見がまとまらない場合などは時として行内の政治力なども活用する調整能力が求められた。
　そのチームリーダーは大猫次長が担った。彼も帝国銀行出身で、柳のような柔軟さと思いもよらぬ解決策を思いつくことがあり、ネゴシエーターとしては最適と思われた。またその直下で預金共通業務を鮒田調査役が担当した。
　預金共通という中には、ＧＣＳＣの業務アプリチームが担う円定期業務、セキュリティ業務が含まれることから、主な折衝先となる予定だ。鮒田はＳＩｅｒ出身でベンダーの役割などは熟知していたため、調整役としては最適の配置と思われた。
・ユーザー部門
　かぞく銀行におけるユーザー部門とは、システム部以外の部署を指している。システム部とは行内から上がってくる要求をシステムに落とし込んでいく部分を担うため、要求を出す側は全てユーザー部門といえる。これにはマーケティング部、事務部、スマホアプリ、ホームページ、コールセンターなど多くの部署が含まれた。そして彼らとの窓口は、前述の業務チームが担うこととなっていた。

　以上が銀行内の代表的な体制だ。
　最後にもう一つ、大事なプロジェクト組織がある。ＢＡＮＫＣＥＮＴＥＲを担当する大手製作所だ。彼らを抜きにして勘定系システム更改は語れない。
・大手製作所
　「ＢＡＮＫＣＥＴＮＥＲ」という、世界で初めてＬｉｎｕｘで稼動する銀行勘定系パッケージを世に出し、国内導入行としてはかぞく銀行次期システムで３例目となる。担当する範囲は、勘定系システムはもちろんのこと、フロントシステムも大半は彼らの担当であり、他に基盤、関連システムとの中継システムなども担当する。そのためＧＣＳＣの１０倍以上もあるプロジェクト体制となっていた。
　ＧＣＳＣが開発しようとしているフレームワークは、大手製作所のフロントシステムチームが主な利用者であると同時に、要求元にもなるため、多くのコミュニケーションを交わすことになる。
　その体制は際立ってベテラン揃いというわけではないが、それぞれの領域に長けた３０～４０代の要員で構成されていた。また海外オフショア拠点として中国に多くのエンジニアを抱えているのも特徴的だった。
　ＢＡＮＫＣＥＮＴＥＲはパッケージであり、全ての保守、開発業務を中国で実施していた。何ともグローバルで壮大な組織である。巨大なプロジェクトチームを率いるのは南田ＰＭ、ＧＣＳＣともコンタクトをよく持つフロントシステムリーダーは、森下といった。
　説明が長くなってしまったが、以上がかぞく銀行次期システムプロジェクトを支える体制である。続いてマスタープランについても少し触れておきたい。２０２２年５月まで、以下の順で進められることになっていた。
・プロジェクト計画工程
　２０１８年７月～２０１９年５月。この期間で、基本設計以降の成果物の定義、見積、テスト計画など主要な計画を固めることになる。そのため、システムの要件定義を一通り行い、全ての仕様を定義する活動である。
・基本設計工程
　２０１９年６月～２０１９年１２月。システムの基本設計工程として、画面設計書や機能設計書、インターフェース仕様書など、開発対象の機能全てについて一通りの設計書を作成していくことになる。設計書体系は、銀行内に設置される標準化チームが担うことになっていた。
・詳細設計・実装工程
　２０２０年１月～２０２０年６月。基本設計で定義された各機能について、画面などのユーザーインターフェース（ＵＩ）、データベースや勘定系システムとのＡＰＩ機能などを全てコーディングして開発する工程である。実装が完了すると、理屈の上ではシステムに必要なものが揃うことになるのだが、さすがにコードだけでは完成したとは言えないため、プログラム一つ一つを動かしてみる、単体テストもこの中で同時に行われる。
・ＩＴ１工程
　２０２０年７月～１１月。ＩＴとはインテグレーションテストの略で、システムのある部分を組み合わせたテストという意味である、ＩＴ１はそのうち前半となるテストという意味である。一般的にこれは結合テストと呼ばれており、開発工程で確立したＪａｖａクラスを、画面やバッチ入出力が行える纏まった単位で統合し、その単位ごとにテストを行う作業となる。
　これはフロントシステムならその範囲内で統合する必要があり、勘定系システムであるＢＡＮＫＣＥＮＴＥＲとのインターフェースを、スタブというダミー機能を通した状態でテストを進める必要があった。
・ＩＴ２工程
　２０２０年１２月～２０２１年２月。ＩＴ１に続く２番目のＩＴフェーズである。フロントシステムとして確立した一連の画面の流れを、勘定系と接続させ、銀行システムとして一連の接続確認を行う。勘定系システムであるＢＡＮＫＣＥＮＴＥＲとのインターフェース確認が中心である。ここまで終わると、開発すべきものが一通り完成することになる。
・ＳＴ１工程
　２０２１年３月～２０２１年１０月。ＳＴはシステムテストの略である。ＩＴ２までに構築・テストしてきたフロントシステム、勘定系システムに対して、銀行業務として利用可能であることを担保する工程となっている。ＩＴ２で勘定系システムと繋げても、道路工事で例えるとトンネルがつながった状態に過ぎない。実際に物流網として利用した際に機能するか、渋滞が生じるとどの程度で解消するか、有事の際に逃げ場はあるかなどを、実際の業務手順に即してテストしてみるのである。
・ＳＴ２工程
　２０２１年１１月～２０２２年４月。最終的なテストはこのＳＴ２工程となる。システム部門が完成させたシステムを、銀行全体で利用し、業務へ組み込んだ際の業務手順などを総合的に検証する。その検証の中には、災害が生じた場合の手続きの確認や、障害が生じた場合のフェールオーバー（待機系での継続）機能の確認、運用チームでのシステム運用手順の確認など、新システムを使った場合の業務手順の確認などが主なテスト対象となる。
・システム本番移行
　システムの移行は２０２２年５月の連休に計画されていた。最終的に本番システムとしてリリースを行い、現行システムに完全にとって替わることになる。そのため全てのデータやファイルなどを、限られたある期間のうちに一斉に移行し、新システムで使える状態にする必要がある。
　システム移行は、何度も実施できるわけではなく、顧客サービスを止めて行う必要がある。そのため一発で上手くいくように、入念に移行手順の確認やリハーサルが行われる予定となっていた。これは主にＳＴ２のテストと並行して行われる計画となっている。

　以上が、かぞく銀行次期システムプロジェクトの主要な計画である。
　総じて、チーム「レインフォース」は人の集まりでしかない。大手製作所のように持ち込んだプロダクトがあるわけではなく、職人のようにノウハウを持った人が何人かいるだけの集団だ。むしろ約半分はそれぞれのキャリアで初めて経験する仕事であった。体制に大きく懸念のある業務共通チームは、神津の採否にかかっているといえる。半分は努力で何とかなるかもしれないが、半分は運のような他人任せの状態であった。何れにしても、この状態でプロジェクトはスタートしてしまった。
　この時のＧＣＳＣのプロジェクトとしての成功確率は５０％あるかないかといったところだろう。将棋のようにＡＩで勝率がすぐにわかれば、冷静にリスクも見極められたのかもしれないが、予算上もアサインされた人がまずは努力していくのは、世の常である。
　まずはやってみて、問題点があれば修正していこう。姫宮の心の中でそのように何度も言い聞かせてみたものの、この先は眠れない日々が続いていくことになった。
　着任翌日の７月４日。姫宮はプロジェクトメンバー全員を召集しキックオフミーティングを開催した。その中で、プロジェクトの初期計画や体制を全員へ説明した。最後に、チームリーダーから一言ずつコメントをもらい締めくくったのだが、大島の挨拶が印象的だった。
　「業務共通チームということで、数年前の実績が役に立てられればと考えています。ご覧の通り今はまだ体制として十分とは言えません。でも、期間が長いですし、自分自身が成長していくことで、足りない部分を補いたいと考えています。他のチームも同じ状況はあるのだと思いますが、全員が１つ２つ成長しなければ、プロジェクトは成功しないということでしょう。姫宮さんや会社のアサインには、正直厳しいと感じる部分もありますが、親心と考え、応えていきたいと思います。」
　現時点でレインフォースの勝率をＡＩが判定すれば、確かに５０％に満たないだろう。ただしＡＩは、人間は成長し、その能力を増やし、知識も広げることが出来るという部分は計算外のはずだ。予想をも超える動きをするのが人間である。その可能性がこのチームにどこまであるのか。
　大島の言う通り、自分自身成長していく前提というのは、姫宮含め、この時誰にも例外はいなかった。