１２ 死闘の日々
２０２０年７月。
気象庁によれば、今年の夏は例年以上の猛暑となるようである。気候変動の影響もあるのだろうが、今年は例年以上にヒートアップしているせいもあるだろう。
これから始まるＩＴ１という工程は、システムの機能１つ１つが正しく動くのかを検証するテスト工程である。そしてこの先５ヶ月間、１１月末までひたすらテストの打鍵をする予定となっていた。
次期勘定系システムプロジェクトは、ウォーターフォールという開発方法で進められていた。業務要件からシステム設計していく上流工程、プログラムやデータベースなど、稼動するシステムとして作り、検証を行っていく下流工程。上から下に流れていく水の流れのように、このような開発方法はウォーターフォールと呼ばれてきた。
その中でテスト工程は、構築したシステムが上流工程で設計した通りに動くのか、さらに初期の要件を満たしているのかを検証する工程と位置付けられている。銀行の勘定系システムを含めたこの規模となると、テストだけでも２年間をかけることになっていた。
ここでテストに必要な期間とは、対象システムの特性に大きく依存しているといえる。
そもそもシステムは、大きくハードウェアとソフトウェアから出来ている。ソフトウェアは振り込みや残高照会など、サービス単位に分かれている。そのサービスはさらに小さな機能の集合で出来ている。その機能とは、画面の入力を受け付けたり、それをチェックし、データベースに登録し、画面出力を行ったりする、プロセスのことを言う。さらにこのプロセスは複数のプログラムからなっている。プログラムコード１行を１ステップと呼ぶのだが、サービスをプログラム数で表すと、１回のブラウザからの処理要求に対し、数万ステップというコードを通過して処理されている。
そしてテストというのは、これら全ステップのプログラムの妥当性を検証することから始まるのだ。
まず１つ１つのプログラムが正しいことを単体テストで確認する。次にチェックなど、プロセスの単位でテストを行う。そしてプロセス単位が確認出来ると、今度は画面の流れに沿って、サービスとして機能するかを確認する。サービス単位が担保出来れば、次は関係システムと繋ぎ、インターフェースの正しさを確認する。そこが確認できれば、銀行の業務オペレーションとしての要件を満たしているのかを検証していく。
そうして業務としての妥当性が検証出来れば、次は異常状態に対する対処の方法などを確認していく。例えば性能の許容値を超えるようなリクエストが来た場合に、システムの一部を切り離すなどして稼働を継続できるのかどうか、といった観点である。このような観点は非機能検証と呼ばれ、システムとして持つべき当たり前の品質特性として一般的な考え方とされている。
さらに銀行業務では資金異動を取り止めるなど、予期せぬ事態へも対処出来なければならない。これらをコンタクトセンターなどで模擬的な業務のもと実施し、運用として回るのかを日々確認していくことも必要になる。
仮にこのように段階的な検証をせず、いきなり運用テストを行ったとしたら、問題が発生してもどこの何が原因なのか、他に問題はないのかなどが全く分からなくなってしまう。部品の集まりで出来ている車に例えると、１個１個の部品の品質が担保されていなければ、問題がどこにあるのか、車全体を眺めていてもわからないのと同じだ。そのためテストは出来るだけ小さなまとまりから、徐々に検証範囲を広げていくというのが、一般的な進め方だ。
この一連のテストの中で、最終段階のテストはＳＴ（システム・テスト）と呼ばれる。
ＳＴまで進行すると、検証の対象はプログラムというより業務ルールそのものとなっているため、テストの主役は徐々に銀行の業務や運用担当部門に移っていく。 そのため、テストの推進がベンダーから銀行にどこかでバトンタッチされる。それが切り替わるのが、ＩＴからＳＴ工程に移行するタイミングとなっていた。
ＩＴ（インテグレーションテスト）は結合テストとも呼ばれ、このプロジェクトではさらにＩＴ１とＩＴ２に分かれている。両者の違いは何かというと、フロントチャネルシステムと、勘定系システムが繋がっていない状態で行うテストがＩＴ１で、繋がっているのがＩＴ２と呼ばれていた。
品質を段階的に向上させるため、繋げる範囲を徐々に広げていくという考え方においては、フロントシステム内のみで実施するテストがどうしても必要ということだ。それがこれから行うＩＴ１であった。
テスト工程の全体の流れはこのように進むが、１つのテスト工程についてテスト計画を作成し、関係者が準備すべきデータなど、間違いの無いように進めていく必要があった。テスト計画では、各テスト工程の目的、テスト対象、テストデータ、対象の機能などを定義する。さらに様々な観点のテストが同時並行して進むため、テスト環境やカレンダーが重複しないよう、予めどのテストを優先させるのか、ということなども定義している。そのうえテスト結果に誤りがあると、該当のプログラムやデータを修正し、改めてテストを行う必要もある。そうすると、たとえば実施中のテストを止めてもらうなど、関係者と速やかに連携する必要もあるため、情報共有のためのコミュニケーション方法なども、全てテスト計画として定義される。
そうやっていくと、銀行勘定系とフロントシステムをフルスクラッチで作り替える場合のテストというのは、どうしても２年はかかるのだ。品質が悪いとそれでも足りないくらいだ。
この章の本題であるＩＴ１はベンダーが主役であり、この工程のゴールはサービス単位の品質が担保されているレベルを目指すことであった。そして前の工程のように、全員がプログラミングや設計が出来る有識者である必要はないが、テストを進めるためには様々なデータやスタブ、デバッグツールなどを準備する必要があった。
「長澤さん、ログインを動かすにはどうすれば良いのですか？」
「いや、普通に契約者と認証データを準備すれば進むでしょう。フレームワークからテストデータを提供していますから、それを使ってください。」
「エラーが起きたら、何を確認すれば良いのですか？」
「そんなのログに決まっているでしょう。デバッグしながら動かせばどこで落ちたかわかりますよ。」
「長澤さん、やっぱり私ではわかりません。ちょっと見てもらえませんか。」
「フレームワークのここでヌル（ｎｕｌｌ）になってプログラムが異常停止しているので、コンテキストに値が設定されていないということですよ。設定ロジックのバグか、テストデータがないのではないですか？」
サクセス社の川平は業務アプリチームの運営を任されており、チームメンバーが業務アプリをテストするために必要な情報やテストデータを必死でかき集めていた。
一方ガイドチームの長澤はここ２年間、フレームワークの開発ガイドばかり作ってきたため、プログラムの構造にはとても詳しかった。開発工程で半分放置されてきた業務アプリチームは、知識が少なく、テストが止まる度に彼のスキルを頼った。
逆に些細なことでも直ぐに聞いてくる川平に対して、長澤もあまり良い思いはしていなかった。
「何でこんなこともわからないのですかね。ガイドを見て理解してやっていますか？」
「ガイドといっても山のようにあって、どれを見れば良いのかわかりませんよ・・」
サクセス社も被害者意識を交え、開き直っている様子すらあった。システムの場合、人だけが集まってもスキルが集まらなければ、やはり動かせないのだ。
前の工程の詳細設計・実装工程で散々苦労したが、工程が進めば進むほど、過去に残した課題がリバウンドとして跳ね返ってくる。その意味でＩＴ１も全く予断が許せない状況となった。
そして実は、このような状況は川平たちのチームだけではなかった。
大手製作所は、完成した共通機能を２０２０年６月に受領し、そのまま開発を進めていたはずだった。あれほど画面が動かないと騒いでいたのだ。既にいくつか完成したものがあってもおかしくないはずだ。だが、彼らのテストも止まっていた。
「ＧＣＳＣさん、フレームワークや共通機能と結合させた途端に全く動きません。こちらも設計通り作っているため、何が悪いのか見当がつきません。それぞれで進めても非効率ですので、まずはＧＣＳＣさんの方で先に何が問題なのか確認して、修正しながら進めてみてもらえませんか？テスト用の業務アプリはこちらが提供しますので。」
物事を進めるためには、時には領域を超えて踏み込まなければならない。その意味で森下の言っていることは、少し図々しい感じもするが、今の状況を打開するには必要だった。そして姫宮はこの分担について了承した。
「考えとしてはわかりました。業務側の問題もあるでしょうから、そこはリストにして順次フィードバックしていきます。」
そもそもの要件は一つだったとはいえ、別々に設計と開発を行ってきたプログラムである。繋げてすんなり動くというのは、まずないと考えた方が良いだろう。そのため、プログラムを統合してテストが行えるようになるための作業は、誰かが一人で上から下までデータを流してみて、デバッグという不具合の解析をしながら、とにかく動く状態に持っていくのが早い。
そして、長澤にこの活動の白羽の矢が立った。
「えー！わ、私がそんなことをするんですか？業務アプリなんて全くわからないのに・・。ガイドを見てもらえば誰でもわかると思うんですけど、きちんと読んでいないのではないですか？」
長澤にとっては想定外だ。ＩＴ１は業務アプリが主体で進めていくテストである。フレームワークのガイドだけ作ってきた自分はこの先お役御免とでも考えていたのだろう。だが、こんな器用なことが出来るのは、長澤を置いて他にはいない。幸いガイドチームのこの先のアウトプットは特にないため、テスト支援に専念できそうでもあった。
「業務アプリもフレームワークも、共通機能もみんな設計通りに開発をしたと言ってるんだ。でも事実として全く動いていない。どこかに間違いがあるので、そこを修正するしかないだろう。それを見つけるのが、君のこの先の役割だ。」
チームの役割に即してどうあるべきかを言い出すと、そもそも役割を全うできたのは基盤フレームワークチームくらいだ。ガイドチームも、相手が理解するまで説明を尽くしてきたわけではない。とにかく早く動かして、業務アプリチームにテストを消化してもらうしかない。
「はあ、取り敢えずやってみます。」
納得してはいないが、しぶしぶ着手した。
ところがいざ長澤にやらせてみると、動かなかった機能たちがあれよという間に動いていったのだ。
「え？もう動かしたの？結構簡単に動いたということ？」
「ちょっと長澤さん、認証機能は不具合あって動かないはずなんだけど、どうやって先に進めたわけ？」
そんな状況で、姫宮や新島など見ている周りが不思議だった。
「いや、そんなことだろうと思ったんで、デバッグモードで止めながら動かないところは機能ごとスキップして最後まで通しました。共通機能も動かないところがありましたけど、業務アプリも未完成のところが沢山ありましたよ。全てリストに記載していますので、関係チームに展開してあげてください。」
誰が挑んでも全く動かすことが出来なかったのに、こんなところにまた隠れた才能を見つけた。長澤は人に気を使って生きるより、自分のペースを大切にするのが好きな人間だ。エンジニアには多いタイプである。才能だけで生きて行けるため、必要以上に努力はしない。だがもっと前向きに取り組めば、彼の才能なら世の中でも引く手数多のはずだ。
そしてＩＴ１が始まり１ヶ月が経過する頃、大手製作所の担当していた業務アプリ機能は、ほとんどが動くようになり、本格的なテストの消化モードに突入出来ていた。一方、ＧＣＳＣの業務アプリチームでは問題が続いていた。彼らはまだ半分程度の機能しか動かせていなかった。
「姫宮さん、今のペースで行くと、ＩＴ１が終わりません。」
「えっ？どういうことですか？テストケースも増えているみたいだし、まだ半分も動いていないというのは。」
「画面から叩けるやつは大体動かせましたが、オンライン連携されるものは全く動きません。このままだと遅延するしかありません。」
そうなのかもしれないが、どこか他人事のような言い方だ。
「それで、どうするのですか？」
「・・お願いになってしまいますが、長澤さんに、動くところまで進めて頂きたいです。」
「それはわかりましたが、自分達でも中身を理解してくださいね。」
そうしてこの遅延についても、何とかキャッチアップすることができた。
ところで、テストでは「何故そんなことが」と思うことが起こる。設計書には書いたかどうかはっきりしていなくても、テストでは動くか動かないかという明確な事実があるため、余計に不思議に感じるものだ。
ある日テストを進めていると、画面の中で動かない機能があることが分かった。
「川平さん、印刷ボタンが動かないようですが、開発していないのですか？」
「え？印刷ボタンは我々ではありませんよ。」
それ以上確認しても、では誰が開発するのか、知らないようだった。そのため姫宮から銀行に確認に行った。
「鮒田さん、印刷ボタンについてはこちらでは開発していませんが、誰が開発の担当となっているのでしょうか？」
鮒田調査役はきょとんとした様子で答えた。
「え？いまさら何言ってんの？ＧＣＳＣさんが作るってことになっていたでしょう？」
川平に聞いてもそんなはずはないという。何かの間違いではないではないか。経緯が良く分からないが、とにかく押し込まれないようにしなければ。
「そんな話は聞いたことありませんが、いつそのようなことになったのでしょうか。」
「う～ん。詳細設計進めていたころだから、少し前ですね。でもお宅の笹山さんもそう言ってましたよ。」
笹山は、サクセス社の再委託先として参画している、ウィル社の責任者だ。ＳＩ業界では２次受け３次請けというのがざらにある。２次請けは管理者だけで実態は３次請け社員がやっているというのも珍しくはない。実際サクセス社は川平が管理しているが、大半のメンバーはウィル社だった。そこで笹山にこの件について話を聞くと、かつて中井が離脱した直後、サクセス社に運営を一任させていた頃に決まったことのようだった。
姫宮は直ぐに笹山に経緯を確認した。
「確かにその頃、印刷機能はどのような機能かと聞かれたので答えましたが、自分達で作るとは言っていません。」
笹山はそのように言うが、では何故うちが開発まで担当することになっているのか。とにかくこちらの認識を早く伝え、方向転換せねば。
「鮒田さん、経緯を確認しましたが、仕様の問い合わせに答えたのみで、こちらで作るとは言っていないようです。」
「え？仕様まで考えておいて作らないって、では逆に誰が作る想定だったのですか？」
「それは・・・確認してきます。」
またたらい回しだ。丸投げしていた以上、仕方がないとは思いながら、再び笹山に聞いた。
「いや、特に誰が作るという想定はありませんでしたね。聞かれたことに答えただけでしたので。」
チームリーダーが不在になるということは、結局チーム全体がおかしな方向に進んでしまうものだ。一度間違った方向に進むと逆に元に戻すのに相当な体力を要する。これは何よりも恐ろしいことであった。
「・・・という経緯で、弊社で開発を予定していない機能なのです。必要だというのであれば、改めて発注をお願い致します。」
銀行にも経緯はあろうが、こちらの認識をきちんと伝えなければ、勝手にやることが増えてしまう。ここは業務チームの大猫次長に直談判を行った。
「ＧＣＳＣさん、いまさら何を言っているのですか。印刷機能はあなたたちに委託している機能ですよ。依頼通り開発してもらわなければ困りますよ。」
「いや、でもそこは行き違いがあったようで・・。」
と言いかけたが、逆に怒らせてしまった。
「いい加減にしてください！！画面だけ作ってそこで動かす機能を作らないなんて、ある訳がないでしょう！！」
物は言いようである。理由とは結論ありきであり、通れば何でも良いのだ。このような揉め事は都度活動を止めて事実確認、調整という時間を伴う。様々なことがある度に、過去の判断を何度も後悔したものの、その時点には戻れない。むしろ今後繰り返さないことが重要である。
２０２０年１０月。
ようやくサクセス社もテストが軌道に乗り始めたころ、ＩＴ１という工程は終盤に差し掛かろうとしていた。遅延が発生してから、工程開始時点で１００個あった設計課題も地道に解消していた。
この頃になると、ＩＴ１の品質評価と並行し、翌月より開始されるＩＴ２の準備が進められており、これまでとは違った意味で慌ただしかった。
「ＩＴ２のテスト計画まで手が回りません。それをしろというのなら、ＩＴ１は遅延します。」
また半脅しのようなことを言ってくる。何故開き直ったような言い方しかできないのだろう。
「では、テスト計画はＰＭＯの方で作らせましょう。サクセスさんはとにかくＩＴ１を完了させてください。」
「わかりました。」
ＩＴ２は、ベンダーが主体となるテストの最終工程である。勘定系システムと繋ぎ、次期システムとして完成形となる予定であった。
勘定系システムとフロントシステムでは、フレームワーク構想で散々触れた通り、そもそも役割が異なる。勘定系システムでは、顧客情報や口座情報という重要な情報が管理されていた。対してフロントシステムは、それらの情報を問い合わせて取得し、ブラウザから振込限度額を操作したり、外部システムとのインターフェースを統一して通信することなどが役割であった。そしてＩＴ２で両者をつなぎ合わせ、一連のテストが終わると、インターネット経由で自分の口座に入金したり、残高を照会したりできるようになる。つまり、ようやく銀行システムらしくなっていくのだ。
勘定系はパッケージであるＢＡＮＫＣＥＮＴＥＲを使っている。パッケージと言っても拡張開発をしていたため、１つ１つの検証テストはフロントシステムと同様にＩＴ１で細かく行われていた。
ＩＴ２では本格的にシステム間を接続することになるため、ベンダーを跨ったテスト計画も作られていた。特にテストデータの作成分担、テスト対象とするインターフェースとバージョン、テストシナリオの確認分担、などを細かく決める必要があった。
このテスト特有なこととしては、システムだけでなく会社間での連携も図られた。例えばフロントシステムから勘定系に残高照会を行い、結果をブラウザの画面に出すとする。この時に依頼電文を作っているのはフロントシステムとなるが、それを処理するのは勘定系システムである。このテストの難しさは、勘定系システムの振る舞いをある程度意識したテスト電文を作れないと、必要なテストシナリオをカバーできない。だがフロントシステムから見ると、パッケージの仕様を理解する時間もない。そのため、このようなフロントシステムが仕向けとなる電文は、相手先である勘定系システムの担当者がテストシナリオをレビューするという形式が取られた。
そしてＩＴ２のテスト計画では、テストシナリオとレビューの分担、実施日が事細かく決められていったのだった。
２０２０年１２月
ＩＴ２の準備を進めながら、ＩＴ１についても何とか期限内に終了した。
ＩＴ１の開始時点で機能が全く動かない状況が続いたことで、不具合の数は数百ほどとなっていた。ＩＴ１の品質評価で、発生した不具合について原因分析を行い、設計の間違いなのか、プログラミングミスなのか、あるいはテストの誤りなのか等を整理した。そうして同じような原因となるところを類似見直しをかけ、工程上の不備からも品質を高めた。その後工程は無事にＩＴ２に移行することができた。
「姫宮さん、ＩＴ１では遅延からスタートしましたが、この工程では挽回していきますよ。」
品質評価が終了した直後、川平・笹山が姫宮にそう言ってきた。ＩＴ１では散々ヒヤヒヤさせられたのだ。そこは本当にお願いしたい。だが翌日になり、真逆のことを言いだしてきた。
「姫宮さん、ＩＴ２のテスト計画を確認したのですが、既に破綻しています。今日から勘定系側のレビューが始まることになっていますが、テストシナリオを作る時間が考慮されていません。」
確かにテスト計画はＰＭＯが作ったものだから、開発者が見ると抜け漏れがある可能性はある。だが、今日に至るまで全く目を通していなかったというのか。
「調整中の部分があるとは聞いていましたが、ＰＭＯから聞かれていませんでしたか？」
「テスト計画を作りました、という話は先週ありました。だけど、ここまで調整されていないとは思ってもいませんでした。」
ＩＴ１のテスト計画を作ったのは逆にサクセス社だ。破綻と言えばあれほど破綻していた計画もない。自分のことを棚に上げているところ、何か言わされているように思えてきた。
「で、どうするのですか？」
納得できないというのなら、もう一度考えてもらおう。実現出来る計画を。
「申し訳ないですが、こんな計画ではＩＴ２はできませんので、イチから考え直します。ただ、そこまでさせたということに対して結果はどうなるか責任が持てません。そのことをご認識ください。」
ＩＴ１が遅延した時には散々フォローしたはずだ。そんな言い方をするとは、どういう了見だろう。こうなると別の目的があるような気がしてならない。
２０２１年１月。
委託先もバカではなかったということだろう。前の工程から苦労を共に乗り越えてきたと思っていたが、彼らは彼らで自分たちの置かれている状況を冷静に見ていたのだろう。設計時点から放置され、リーダーもいなくなり、丸投げのような状態が続いた。ＩＴ２の計画も調整が全くされないまま引き渡され、また丸投げされた。きっとこの先も繰り返されるに違いない。
彼らの気持ちを代弁するとこんなところだろう。
その片鱗は何度も感じたが、契約の都度お互い納得してきた経緯もある。だが良くない予想は的中した。ある日、滅多に来ないサクセス社の営業が訪問してきたかと思うと、要件だけを淡々と伝えてきた。
「川平や笹山はこの１年で限界を超えました。もう、このプロジェクトでは続けられません。今後は御社に引き継ぎますので、次の工程からは外して頂きたい。」
これまでも、皆いつもダメになってから言ってくる。そういう結果になるのであれば、もう少し早い段階から別の言い方が出来なかったのか。２０２０年４月以来、欠員は出さないようにと慎重に進めてきたはずだが、欠員どころか撤退という事態を生じさせてしまった。
このプロジェクトの中で委託先といえば、イージー技術者集団、緑システムと、このサクセス社が主要なパートナーであった。このうちイージーはフレームワークのみを開発する目的で参画していたため、既に終了していた。そうすると、残るは緑システムしかいない。絶対にこれが最後の体制変更になるようにしなければ、リリースを迎えられない。彼らからの引き継ぎも成功させつつ、この短いＩＴ２を如何にやりきるか。
人一人ではなく、会社ごと引き継ぐのだ。そのために必要な時間は相当量になることが想定される。だが、ここまで来て立ち止まってはいられない。引き継ぐ以上は跡形も残らないようにする覚悟でやるのだと、自分たちに言い聞かせた。
この記事が気に入ったらサポートをしてみませんか？