１４ チームリビルディング
２０２１年７月。
今年の夏は、いよいよこのプロジェクトで最後の夏となる。
一年前は、本当にお祭り状態というほど統制がない状況であったが、、今の時点で全ての機能が稼働しており、仕事も予定した通りに進められた。ただ一つ、ＳＴ２の業務オペレーションテストのボリュームと、今のプロジェクトの現有体制が釣り合うのかどうかということが最大の関心事であった。
そんな中、業務アプリ初代リーダーの中井が復活していた。
サクセス社の引き継ぎは緑システムが行ったが、銀行業務のテストシナリオを作っていくためには、スキル不足だった。中井は業務アプリチームで上流工程を担当していたため、スキル的には申し分ない。
２０１９年１２月に離任してから約１年半。普通であれば一度酷い目にあったプロジェクトには戻りたくないものだ。だが中井は中井で最後までやりきれなかったことに悔しさを感じていたようで、それは彼の中でも後悔となっていた。そのため就業条件を合意し、晴れてカムバックしてきたのだ。
「中井、おかえりなさい。開発工程は何とか終えたので、これから業務オペレーションテストに専念します。ついてはこの先の品質コントロールは中井に任せたいと考えています。」
「姫宮さん、しばらく離れてしまい申し訳ありませんでした。私自身ずっと気にしていましたので、ようやく戻ってこられたという気分です。業務オペレーションテストも承知しました。」
これでチームを管理する王子に加え、中井の持つ業務スキルも揃った。真鍋と約束した業務チームの管理体制を、ようやく社員で固めることが出来た。まず中井が取り掛かったのは、緑システムの担当者とテストシナリオを作成していく作業であった。
「下川さん、セキュリティや円定期の業務フローから私がテストパターンを抽出していきますので、具体的に入力データを当てはめてもらえますか。そうすればテストシナリオになるはずです。」
銀行業務といっても、結局は画面をどう操作していくかの話である。中井は要件定義を行いながらずっと銀行業務を理解していたため、ＧＣＳＣの中では一番詳しかった。
そうして中井指示のもと緑システムがテストシナリオを作っていった。口座開設の途中で解約した人や、引っ越して住所が変わった人、その途中でカードを紛失してしまう人など、実運用上発生する様々なケースを抽出した。業務シナリオでは、どんなイレギュラーな状態までも網羅しておく必要がある。銀行業務とは、あらゆる想定外を想定して初めて、完成するのだ。
ここまで網羅したテストが用意され、全てのテストを通すことが出来れば、実運用に耐えられるということになる。
テストを開始し翌月の８月。
しばらくこの業務オペレーションテストを行っていたが、想定以上に不具合が発生している機能があった。以前、作成分担を巡って大猫次長の怒りを買ってしまった印刷機能である。
印刷機能を作るには作ったが、サクセス社もその後撤退したため、最低限の実装のみ行なって終わりにしていた。そのため、品質強化として、印刷機能については特に細かく機能を再確認することとした。
品質管理について、製造工場の場合、製造工程のどこかに明らかなミスや過失があれば、そのロットについては全て破棄すべきということが判断できる。だがシステムの場合、プログラムを作った過程は人それぞれで異なっており、また頭の中で考えていることが大半であるため、どのような間違いが混入したのかということは、作業を見ていてもほとんどわからない。そのため作られたものに対して一通りテストを行ってみて、特に不具合の多い機能があれば集中的に追加テストを行うことで品質を高めていくという方法が取られていた。
システムへの入力データが無限に存在するように、テストを行うパターンなど無数に存在するのだ。ある程度のバリエーションでテストしてみて、特定の部分に不具合が偏っていると、その機能が丸ごと怪しいと考えられる。このようにして効率的に品質を高めていくのである。
中井も復帰したことで、業務チームのテストは着実に進んだが、最後に移行を推進する人物を立てる必要があった。
システムの移行は、まさにこのプロジェクトの集大成となるイベントである。そもそもデータ移行が終わらないことには新たなシステム運用は始まらない。そして勘定系、フロントチャネル含めたシステム全体の移行に与えられたのは、丸三日間であった。
そんなに何をするのか？と思われるかもしれないが、移行するデータ量は約５００ギガバイトある。１ギガｂｐｓで転送して、転送効率半分で見てもそれだけで２時間３０分かかる計算だ。さらに現行システムとはデータベースの格納形式が異なるため、データを現行システムから抽出し、プログラムで編集を行う必要がある。その結果を一つ一つ検証することも含めると、データの移行だけで丸一日かかる計算であった。
システム移行ではデータ移行以外にも、システムを本番環境に反映するリリース作業、その後の稼働確認もある。さらにデータ移行の間止めていた銀行業務を再開し、サービスインまでに間に合わせる必要もある。そのため移行直後は業務オペレーションの集中処理なども行う必要があった。特に丸三日間も銀行システムを止めるということは、かぞく銀行を利用している会社の給与支払いや家賃の振込などを止めるということである。そのようなことが出来るタイミングは年に数回あるかどうかだ。そうすると移行に失敗した際の復旧手順も確実にしておくことも重要だ。どうしてもダメな場合には、残念ながら現行システムに戻し、再開するという手順も必要になる。結局移行期間中にしなければならないことはたくさんあるのだ。そのため、逆に三日間でギリギリ収まるかどうかという計画だった。
この移行チームに対しては、また別の要員がアサインされた。
内海という、主にプロジェクト管理を担ってきた人物だ。移行についてはあまり経験したことはないが、きめ細やかに管理を行い、確実に進めてくれそうな性格が、間違いが許されない移行計画を任せるに相応しかった。
移行で重要なことは、移行期間の中で実施すべきことを漏れなく定義し、そして移行期間内で作業を完了させることであった。そのため内海の仕事は移行計画の作成から行う作業となった。
「そもそも、どこからどこまでが移行の範囲かわかりませんので、そこから調べていきます。」
「ああ。これまで移行方針にはまとめているので、そこから復習して、わからなければ聞いて欲しい。」
移行にはこれまであまり携わったことがない。そもそもこのシステムもチャネル系のシステムとは聞いているが、どんなものかを理解するところから始まる。内海はまずシステムそのものを理解するために、業務アプリチームに半分加わり、テストをしながらシステムを理解していった。
「中井さん、行内端末からのテスト方法を教えてもらえませんか？」
「内海さん、事務端末の操作マニュアルがあるから、それに従うと良いですよ。」
「今使える契約者ありますか？普通預金だけでなく家族預金とか、一通り資産を保有しているやつが良いです。」
「そこまでのはないから、１人作っておきましょう。」
「ありがとうございます。」
内海が着任し日々キャッチアップを行ない、システムを理解していった。システムを動かすにはどのような資源が必要か、現状はどのようにシステム運用が行われているのか、その中に３日間の移行作業をどのように差し込んで、いつ何を移行していくのか。
移行がどれだけ大変か、自宅を引っ越す場合を例に考えると、引っ越し先の住居が決まり、電気や水道といったインフラが使える状態になってから移転するはずだ。その後住民票の異動、元の住居を明け渡すために不動産会社の立ち合い、鍵の引き渡しなども必要だ。もっとも、自宅の場合だと新居と２重契約の期間を設けておくことで、トラブルがあったとしても元の住居に住み続け、リスクを回避することは出来る。
だが銀行システムを引っ越そうとすると、有効な契約は１つしかあってはならない。もしも新旧システムが同時に稼働し、どちらでも顧客の銀行口座が有効な状態だとすると、旧システムに入金した記録が新システムに反映されず、入金がなかったことにされてしまいかねない。そのため、移行期間の３日間は全てのシステムを止め完全に移行が完了してから、４日後に新システムのみで営業を再開することになる。
また、そもそも引っ越し手続きを洗い出すだけでも相当パワーがかかるものだ。それを限られた期間で完了させるため、１つ１つの契約先とも分刻みで手続きの時間を決めたとしても、自分の移動時間を正確に把握しておかなければ不可能だ。
そのため、移行を推進するということは、引っ越しに関わる全ての手続きを洗い出し、確認することが求められる。システム移行に関するテストもそれを確実に行うため、リハーサルという形で何回も引っ越しをシミュレーションしていくのである。このプロジェクトにおいても、ＳＴ２の期間中に合計３回の移行リハーサルが予定されていた。
２０２１年９月。
そんな中、かぞく銀行が考えてきた移行計画に大誤算が発生した。移行計画自体は問題なかったが、肝心のデータ移行を行うプログラムが、年末まで完成しない見通しとなった。仕様変更などが重なり、来年の１月いっぱいかかるということであった。大量のデータを相手に移行プログラムも複雑化し、その結果当初期間中に全ての仕様変更を取り込むことが間に合わなくなってしまったのだ。そしてこの時の誤算によって、その後のスケジュールが大きく変更された。
計画は変わり、移行プログラムの確認が２月までできなくなった。もしそここで何か問題が発覚した場合、残りのチャンスは３月、４月の２回のみとなる。全体で３回のリハーサルが確保されたが、本番リリースまで残された期間は２カ月あまりだ。４年間も開発をしてきたシステムで、移行に問題があっても対応できるのが２カ月間しかないというのは、さすがに大きなリスクを抱えることになる。
そのため、テスト環境を使った全体の移行テストを追加で実施することになり、その分の作業を追加契約することになった。その体制は本番移行まで引っ張ることになる。いよいよチーム「レインフォース」の最終形態が出来上がった。
２０２１年１１月。
追加作業に増員を加え、ＧＣＳＣとして最後の体制でＳＴ２がスタートした。いよいよ最後の工程だ。この工程が終わると、本番移行しか残されていない。過去４年間、基礎検討から入れると６年間という期間をかけて作り上げてきたシステムも、あと半年もすれば世の中にリリースされる。残された期間は限られるが、逆にチーム「レインフォース」の気分は高揚していった。
「この先はいよいよ最後の工程です。体制も確定し、皆さんと一緒に本番稼働を迎えられることになりました。ＩＴ１の酷い状態からここまで立て直すのに時間はかかりましたが、後悔の無いよう、残り半年走り切りましょう。」
ＳＴ２の工程キックオフで、プロジェクトメンバー全員を集め姫宮から新体制が説明された。
「姫宮さん、いよいよね。あたしが最後までいるなんて最初は想像もしてなかったけど、決まった以上はやるだけよ！」
「新島さん、宜しくお願い致します。」
「ところで、移行ってこれまでほとんど関わってなかったじゃない？あたしたち、何をどこまで進めていけば良いわけ？」
新島はここ数ヶ月、大手製作所の業務オペレーションテストに付き合わされていたため、ＧＣＳＣの最新状況が伝わっていなかった。そのため姫宮から一通り移行計画の概要が説明された、そこを担っていく内海から詳細説明が行われた。
「・・そして移行は私と長澤さん、千田さん、真鍋さんとで担当します。長澤さんの持つ基盤フレームワークノウハウ、真鍋さんの持つ業務アプリのノウハウ、そして千田さんが関わってきた運用スキルがありますので、どのような事態にも対処できると考えています。」
「そーなのね！それは心強いじゃない！」
「はい！そして私がこのチームを管理していきますので、百人力です！！」
「それは自分で言うことじゃないわよ！」
「失礼しました・・。」
「ははは。」
緊急事態が宣言された頃と比べると、全く別のチームだ。実際サクセス社が離れ、中井や王子、内海など社員が参画したことで顔ぶれは大きく変わった。ここへきてようやく必要な役者が揃ってきた、という実感が姫宮の中に込み上げてきた。４年間かけて体制を作ってきたようなものだ。
システムを開発するプロジェクトでは、エンジニアは一番重要な要素である。だが開発したシステムの品質を評価し、最終品質を担保していくという管理活動も重要だ。銀行とも交渉し、大手製作所とも相談し、決まっていないことを決めていく。そのためにはコミュニケーション力も重要である。
つまり、どんなに優れていても皆が同じ能力や性格では結局うまくいかないのだ。お互いに補うことが可能な体制であれば、一人一人は何かに秀でていれば良い。物の良し悪しは置いておくと、今日のメンバーのやり取りを見て、姫宮には本番リリースが成功している明確なイメージが持てた。
２０２１年１２月末。
この年末で、システム移行のリハーサルが行われる予定だ。とはいえ、移行プログラムは２月までお預けであるため、新しいシステムが本番のネットワーク環境で稼動できるか、その流れをシミュレーションすることを確認する予定だった。ここがクリアできなければ、データ移行どころではない。移行後に外部の通信事業者との接続を行い、通信できるかどうかで検証する予定となっていた。
「１月１日の朝６時から稼働確認を行います。ＧＣＳＣさんは専用端末前に集合してください。」
銀行が宣言するチェックポイントの合図とともに、その時間帯にシフトを予定していた姫宮や内海、神城、新島などが集合した。そして、朝６時となり、全システムで一斉に稼働確認が行われた。
「残高照会でエラーが出ています。」
稼働確認を担当していた真鍋が第一報を上げてきた。あるシステムからの照会だけが通らないという。すぐに新島が反応した。
「何よ、この経路がエラーになるってことは、電文に何か異常がありそうね。」
「千田ちゃん、ソースコード上はどうなってるか、調べてちょうだい！」
しばらくして千田から確認結果が報告された。
「ここでエラーが起きるということは、照会要求のパラメータのどれかに誤りがあるはずです。一つ疑わしいのは、暗号化に使っている情報ですね。」
「そんな、そこはこれまで何度も確かめてきたし、間違ってるわけないじゃない！」
「あくまでロジックから考えられる話です。これ以上は電文を確認しないと、わかりません。」
かぞく銀行と繋がる外部システムとの通信は、基本的に暗号化されている。
暗号化のための情報は、銀行によって管理され、現行システム通りに登録されていた。はずであった。
「まあ仕方がないわね。万が一登録した内容の間違いってこともありえるから、確認してもらいましょうか。」
そして牛元調査役に状況が報告され、システムに登録されている鍵を一字一句再確認してもらった。
「新島さん、暗号化情報は絶対に正しいですよ。現行システムに問い合わせたのがこっちの文字列で、登録しているのがこの文字列。ほら、完全に一致してますよね？」
「確かに同じだわね。やっぱり、ここでは無かったってことね・・。」
「他、思い当たるところは無いのですか？稼働確認終了まであと３時間ありますので、怪しいところは全て確認をお願いします。」
そう言って、再びＧＣＳＣに調査のたまが差し戻された。
だがしばらく調べていたものの、他に思い当たる部分は見つからなかった。
「怪しいところって、あとは暗号化ロジックそのものくらいしかないじゃない。Ｊａｖａの標準関数使ってるし、今更その中をデバッグしろって言うこと？ねえ神城ちゃん、ずっと黙ってるけど何か思い当たることでもないの？」
確かに神城は、ここへ来てずっと黙っていた。
「本当は本番のデータを弄るなんて事はしたくは無かったのですが、通信電文からデバッグすることは出来なくはないんです。」
「え？どういう事よ。本番システムよ？平文にする方法があるってこと？」
「そういうことです。」
神城が奥の手を隠し持っていたらしい。
「万一こういうこともあるかもしれないと思い、暗号化された通信電文を退避させているんです。」
「なんていう人！でもどうやって復元するの？」
「複合化ツールも、本番環境にあります。」
「ナイス！では複合してみるしかないじゃない！千田ちゃん、直ぐ実行よ！」
前に進める糸口になりそうだ。そしてそこへ、当日の移行作業を管理している内海が、様子を確認してきた。
「新島さん、あと１時間で稼動確認を完了させる必要があります。ログインできないっていう問題、どうなりましたか？」
「わかってるわよそんなこと！今からそれを証明に行くの！黙って待ってなさい！」
そういって一目散に本番システム室に向かっていってしまった。
「内海さん、少しずつ進めていますので、もう少し待っててください。」
神城が冷静に付け加えた。
―そうして、複合化してみた結果
「何よこれ、そもそも聞いていた暗号化情報では複合すらできないじゃないの。やっぱり相手側の鍵が間違ってるってことね。まさか行員の人たち、また私たちだけ悪者にして、自分たちは潔白だとでも思ってるわけ！？」
その情報は牛元調査役を通し、先方のシステム担当に伝えられた。
「新島さん！相手側の暗号鍵が違うということでした・・信じがたいですが、テスト用の暗号鍵を使って通信を飛ばしてきているみたいです。」
「何よそれ！直ぐに修正させてちょうだい！本当にあんたたち行員ときたら、こっちが動かないと何にも動いてくれないんだから！！」
「立場上仕方がないんです・・入れ替えてもらっていますので、もう一度稼働確認をお願いします・・・。」
肩身の狭そうな牛元調査役が少し気の毒であったが、その後無事に全機能の稼働確認を取ることが出来た。
本番システムでは、何が起こるか予想も出来ない。信じられないことも起こってしまうのが、本番システムである。だが事実に基づいて１つ１つ確認していけば、必ず正解には辿りつける。たとえ裏技まがいであっても、あの時神城の奥の手がなければ、稼働確認の時間内に答えには辿り着けなかっただろう。最終的に行使するかどうかは別問題として、検証する手段を確保しておくことは、最終的には自分たちの身を守ることにつながるのだ。
２０２２年２月。
年末年始リハーサルが終わり、残りは３回ある移行データリハーサルのみとなった。システムメンテナンスの行われる夜間時間帯のみに行われる。まず現行の本番システムから、データ抽出を行うことから行われた。だが早速、データの抽出時間に関する問題が発生した。
「現行システムからのデータ抽出時に問題が発生し、修正のうえ可能な範囲だけで再実行を行い、まだ実行中の状況です。本来なら本日４時までに終える予定でしたが、６時間延期しているため１０時までかかります。」
銀行の移行対策本部も、想定外の計画変更に慌ただしかった。本番環境では本当に想定外のことが生じることを、肝に銘じる必要がある。
問題の解消も必要だが、どのように後続作業に影響を出さないようにするかも重要だ。対策本部は、問題が生じた場合でも影響を最小限にコントロールするためにあるチームであった。彼らの判断で移行プログラムの問題は保留し、一部手作業で再開した。だがその後、その手作業が影響してしまい、さらに後続の処理がエラーとなった。
「後続処理でエラー発生中。復旧に４時間かかる見通しですので、さらに４時間延期し、１４時完了とします。」
だがさらに、立て続けにミスが発生する事態となった。
「復旧処理の途中ですが、復旧手順に誤りがあり、もう一度復旧が必要になります。」
一度生じた問題は、後々尾を引く。一部が手作業になったことで前提が変わってしまい、後続作業が誤ったオペレーションとなっていた。手作業のミスをまた手作業で補った結果、２次被害を生じさせてしまったのだ。これでは何の移行をしていたのかわからなくなってしまったため、もう一度先頭から実施した方が良いということになり、全てやり直しとなった。最終的に丸１日の遅れを以てようやく２月のリハーサルは完了した。
とはいえ問題は直ぐに修正され、３月に向け準備が進んでいった。そもそも問題連鎖の原因である、データ抽出時の問題が起きなければ、後続の手作業も不要だった。移行作業が丸１日遅延するという致命的な問題が生じたが、やらなければ分からなかったことであり、皆の経験値にはなった。失敗したことを記録し、改善して次に望むという基本的なサイクルが重要なのだ。
２０２２年４月。
次のデータ移行リハーサルである３月は、またデータ抽出時に問題が生じたが、今度は時間内に完了することが出来た。そして４月のデータ移行リハーサル。リハーサルの最後となるこの回では、移行作業全てがオンスケで進み、全く問題なく終えることが出来た。
回を重ねるごとにＧＣＳＣの移行作業も洗練され、様々な改善が図られた。問題があれば関係者で話し合い、解消されるまでそれを繰り返しくということが、このチームとして自然に出来るようになっていた。以前では考えられなかった光景だ。
かつて半分消えていた天井の蛍光灯は、今は煌々と明かりを灯している。もう、かつてのチームとは違う。このチームで本番移行も予定通り終了することを、全員が信じていた。
この記事が気に入ったらサポートをしてみませんか？