１１　繰り返される補給線

　「どんなに辛いことがあったとしても、太陽が昇らない日はない。」
　かつて姫宮が挫折するたびに、守口部長から言われてきた言葉が頭の中でリフレインする。
　開発が予定通り進まなくても、エンジニアが何人倒れようとも、生きている限りまた最初からやり直すことはできる。それは宇宙の摂理と同じように、ひっくり返ることはない。と言った類の意味であろう。特に多くの困難に直面した３月は、日々心の中で呪文のように唱えていた。
　「はあ、こんな事態になったのは、全て自分のせいだ。」
　辛い時には、辛いことしか考えなくなるものだ。考えても仕方がないのだが、そんなネガティブな感情が姫宮の頭の中の思考を支配しようとしていた。プロジェクトメンバーの険しい表情を毎日目にすると、以前なら鼓舞していたが、今の自分には何もできない。そう考えるとネガティブな感情が勢いを増し、さらに支配しようとしてくるのだ。そして、日々会社に行こうとすると、心臓の鼓動も激しくなっていった。
　その感情に抗えるのはポジティブな感情を持つことだけで、先ほどの言葉を呪文のように唱えると、心が少しだけ前向きになれた。そして今の姫宮に出来るのは、それを唱えることによって、かろうじて心の平静を保つことだけであった。
　姫宮の中で２つの感情がテリトリーを取り合っている。日々そんな虚しいことしかできずに過ごしている。毎朝の通勤は東京メトロ浅草駅から徒歩約１５分。その日もいつも通り、もうどうなっても仕方がない、と考えながら、町の中を道草してはいつも以上に時間をかけ、歩を進めていた。
　時間があったせいか、その日は何故か世の中がスローに見え、日々見過ごしてきた日常の風景を観察しながら歩いた。毎朝ゴミ拾いしている酒屋の店主、手押し車を押しながら、ゆっくりと進んでいく老女。日々緑が増えていく公園の草木。
　「この人、そういえば毎朝掃除をしているな。一日も途切れることなく続けているのは、考えてみたら凄いことだな。しかも、動きに無駄がない。」
　「お婆ちゃん、ヨロヨロしながらどこへ向かうのだろうか、今にも倒れそうで、見ているこちらがハラハラするよ。」
　「この公園、こんなに高い木なんてあったかな。隣のビルより高い。」
　三宅が倒れた際に、蛍光灯が切れたことすら気付けていなかったが、日常の中にも気付いていないたくさんのことがあった。そして自分の認識能力の低さというものを、この時の景色によってさらに痛感した。そう考えていると、当たり前のように見えるものでも、一つ一つの動きの理由や目的が気になってきた。
　彼らを行動させているものはなんだろう。風が吹くと、木々は揺れる。信号が赤になると、老女は立ち止まる。
　全く当たり前のことだ。全く当たり前なのだが、でも世の中は何故かそのように動いている。
　一人ひとりの人やモノは、それぞれの表現方法や認知するという行動によってコミュニケーションを取り、お互いがそれに反応することで、意図した行動を取らせている。なぜこんなことで世の中がうまく回るのかわからないが、その瞬間瞬間ではただ一つの目的をもって動いているだけだ。
　そんなことをぶらぶらしながら考えていくと、あることに気付いた。全てのものに、生きている、動くためのエネルギーを感じるのだ。人や草木はもちろん、信号のような機械であっても、稼働することで目的を果たしている。たとえ壊れたとしてもいつか修理され、また現場で稼働する。
　全ての役割を一人が果たす必要はない。誰か一人のコントローラーがいるわけでもない。重要なのは、個々の果たす役割であり、街とはつまり、役割という目的を持った要素の集まりでしかない。そういえばこれはか何かで聞いたことのある「システム」の定義そのものであることを思い出した。この街の中には無駄なものなど、何もなかったのだ。
　そう考えていると姫宮の中で、グッと湧き上がるものを感じた。
　役割を全うするにはさらにエネルギーが必要である。自分のミッションに従い、生きている限り、動こうとすること。それを動かす個々のエネルギーこそ、この世界が生きている原動力なのだ。
　ぶらぶらするつもりが、街の観察から得られた気付きは姫宮にとって大きな衝撃となった。「太陽が昇らない日はない」とは、役割とエネルギーがある限り、世の中は誰にも止められないという意味もあることに、この時初めて気付いた。
　では自分は、メンバーは、プロジェクトというシステムの一部を担えているのだろうか？担えていないとすれば、何が自分の役割だったのか？監査の時にはどん底に突き落とされたと感じたが、考えてみるとそれ以上下がることはない。むしろこれから上がって行くばかりだ。そう考えると、もはや呪文を唱えていることが馬鹿馬鹿しくなってきた。
　「苦しい時こそ、胸を張ろう。」
　そう考え、その日から姫宮はプロジェクトの現実と向き合うようにした。
　一方本社では、緊急事態が宣言されたことで、それまで動かなかったことが動き出していた。ＧＣＳＣでは、プロジェクト監査の結果として危機レベルが定められている。これには５段階あり、安全―注意―危険―緊急事態―中止勧告という順に定められていた。そして、各段階に応じて必要な対策が行われているかを監視することで、組織的に是正していく活動が行われていた。監査とは、その活動において重要な状況報告を担っていたのである。
　姫宮たちが受けた監査では、危機レベルが上から２段目の「緊急事態」として宣言された。上から２段目といっても、最上位の中止勧告は終わったも同然のレベルであるため、緊急事態はこの先プロジェクトを進めるうえで、人命に関わる危険が迫り、実行プロジェクトとしては最上位の危機レベルであった。監査チームの意見書が文書として社内で認定され、この宣言がそれなりに効果を生み出した。
　２０２０年４月８日。
　監査によって緊急事態が宣言されると直ぐに、本部より様々な人物がプロジェクトを訪れては、姫宮やメンバーたちから取り調べのような打ち合わせが何度も行われた。そして気付くと既に再建チームが結成されていたのである。
　姫宮はこのタイミングで全体を統括するプロジェクトマネージャの立場から外された。というより分担することになった。フレームワークと業務共通チームの立て直しは姫宮が専念するが、業務アプリは北門という人物が統括することとなった。
　姫宮は業務共通チームのリーダー代行となったことで、確かに業務アプリチームまで管理するどころではなかった。これまでも業務アプリチームの相談にはほとんど乗ってやることが出来なかった。そこに北門が入ったお蔭で、姫宮も例の負債の返済に全力で身を投じることが出来た。
　「姫宮さん、私は業務アプリを見ますので、共通チームをお願いします。」
　「わかりました。ではそちらは頼みます。」
　姫宮の所属する銀行システム開発部は、本部の傘下の組織として特定の銀行を担当している。本部全体では５００名程度の社員がおり、銀行システム開発部はそのうち１００名程の社員がいる。
　これまで、プロジェクトメンバーが離脱するたびに要員を補充してきたのは、主に銀行システム開発部だった。だが人を補給しては潰れていくということを繰り返し、新たに送り込める人材は残っていない。そこで先日の緊急事態が宣言されたことで、本部内の風向きが急に変わり、あらゆるところから多くの要員が補給された。
　そもそも共通機能を作れる人物が足りない。いや、ほとんどいないに等しい状況に対して、本部内のＪａｖａ設計経験者が片っ端から動員された。管理チームには北門に加え、本社のＰＭＯであった中林が着任。彼女は監査チームの野田と同じ立場にいたのだが、このプロジェクトの危機に合わせて送り込まれたらしい。この２人が入ったことだけで、プロジェクトの管理体制はかなり強化された。
　だが三宅の離脱後、共通チームのリーダーも空席のままだった。そこで後任として着任したのは、新島が所属する技術部のマネージャーである、君津という人物だった。新島という類まれな能力・・というかキャラをマネジメントできる人物とは、いったいどんな猛獣使いだろうかと、別の興味も沸いた。
　これらの体制強化によってそれまでの方針はリセットし、最短でキャッチアップする計画の検討、それによるリリーススケジュールの再調整などが急ピッチで行われた。さらに予算の組み換え、銀行との調整、関係組織との調整など、全てを同時並行で進めた。この期間のチームのタスク量は、１ヶ月の間で総数にして７００個という規模のものとなった。
　「このタスクの遅れの原因が書かれていませんが？」
　「すみません、直ぐに記載します。」
　「問題の解決期限が切れていますが、どうするのですか？延長するのか、しないのか決めて下さい。しないなら直ぐに解決に向けて動いて下さい。」
　「すみません、更新を忘れていました。」
　「障害票の分類を正しく入力してもらえますか。これでは分析時に困ります。」
　「すみません、基準が分からなくて暫定値のままとしていました。」
　中林が入ったことで、管理すべきものごとが明確になった。それだけでなく、管理資料への入力漏れなどの状態も次々に是正されていった。入力漏れなどは「なんだ、入力されていないだけではないか」と考えてしまいがちだが、忙しいプロジェクトこそこのような事態に陥る。陥った結果何が正しいのかわからなくなってしまい、しばらく経つと誰も状況が理解できない事態に陥ってしまうのだ。そして問題が放置されたまま、トラブルに進行していく・・・
　そもそも管理資料とは必要なものを管理するためにある。それが正しくないとすると、入力の間違いだろうが管理されていないのと同じだ。この時の管理チームは、誰もがそのような「当たり前のこと」をすることで、プロジェクト全体の管理レベルが上がっていくと考えていた。
　４月１５日。
　新たな管理サイクルが出来上がり、まともなチーム運営が開始されたかに見えたが、そこにまたしても大問題が発生した。共通機能のガイドとして提示したドキュメントに、事実と異なることが記載されているという報告があった。発見したのは新島であった。
　「藤原、あんたたち何やってんのよ！」
　「申し訳ありません。私は詳細設計から転記するように王さんに説明していたのですが・・。」
　「じゃあなんで違うことが書いてあるのよ！！」
　聞けば、王が書き起こしたガイドは、途中のある断面の設計書には基づいていたものの、その後藤原が加えた修正分が反映できていなかったということであった。
　「後から修正した内容が、王さんに連携できておらず、私の作成したＡＰＩと相違が生じてしまったようですね。」
　「なんでそんなことになってるの？相違した箇所はどの程度あるのか、至急調べてちょうだい！本当あんたってマヌケね！だからこの前も○＄×＃▼・・・！」
　管理体制が整ったとは言え、この問題は年明けからの作業で埋め込んだものだ。着任したばかりの君津や中林も何が起こったのかはわからない。
　「新島、まあ今は不備のあった個所の特定を急ごう。藤原の反省も後で聞くから。業務アプリに迷惑のかかる話なので、今は一つ一つ確実に確認していこう。」
　「承知しました。」
　藤原は即答した。
　そして一通り調査を行った結果、約３００か所の誤りがあることが判明した。
　「３００か所？何よそれ。全く出鱈目だったってことじゃない。あ～これ全部やり直しだわ。」
　「どうしましょう。」
　「どうしましょうじゃないわよ！あんた自分が何やったのかわかってるの？」
　「はい。それは認識しています。」
　「それ！その言い方！何もわかってないわよね！全く反省がないじゃない！」
　「いいえ、反省はしています。」
　「どこがよ！」
　トラブルが生じると皆イライラするものだ。仕方がなかったと納得できるのであればともかく、分かっていれば未然に防げたこのような人為ミスは、特に犯人捜ししたくなる気持ちはわかる。
　「新島、そんなに攻めたって問題は解決しないだろう。どうすれば良いかを冷静に考えよう。」
　「それはわかってるけど、一つ注意していれば防げた話じゃない。それを簡単に見逃すの？」
　「そうは言ってないけど、今は問題をどう解消するかが先決だと言っているだけだ。人が足りないのであれば俺が補充する！」
　君津の男気ある発言は、新島とは異なるリーダーシップを発揮した。以前の新島なら一方的に言いたいことを言い、無理やりチームメンバーを動かしていたが、君津が入ったことで一方的ではなく、合理的に物事が進むようにもなった。
　もうこれ以上、一人も欠員は出したくない。姫宮はチームの運営を見守りながら、今回の問題について何をどうすべきかを考えていた。問題が生じたときは、関係者に速やかに報告を行う。これは危機管理の鉄則である。が、「問題です」とだけ伝えても、すれば直ぐに「それで、どうするの？」と聞かれるだけだ。結局解決策まで用意しておかなければ、危機管理にはならない。とにかく何も決まっていない状態は急いで脱出しなければならない。直ぐにチーム内で対策会議が行われた。
　「３００か所の間違いがあると言っても、ほとんどはＡＰＩの名称が違うだけで、一括置換すればよいだけです。」
　藤原は説明したが、すかさず君津も聞き返した。
　「本当にそれだけなのか？既に開発は進んでいるんだぞ。いつ置換してもらえば良いんだ？」
　置換すれば良いというのは事実かはわからない。既に大手製作所では開発者にガイドをばら撒いて、実装を始めている。そんなところへ３００個間違いがありましたとは、画面遷移問題の後でもあり、簡単に聞き入れられるとは思えない。
　「大半はプログラム名のスペルミスですが、引数を間違えているものも３割程度あります。」
　「３割って、設計に影響あるものが１００個近いってことじゃない！あんた・・本当のことを説明しなさいよ！」
　「まあまあ、これからどうすれば良いのか考えられるのだから、良いじゃないか。」
　「ふんっ！」
　結局７割は救えるかもしれないが、３割は大手製作所に影響を確認しないとわからなそうだった。共通機能として提供したプログラム名が正しく、ガイドが間違っている。それははっきりしているが、業務アプリは既に誤ったガイドを見て開発を進めている。彼らにとっては今からガイドが修正されると逆に仕様変更になってしまうだろう。そのため、大手製作所に双方の場合の影響を確認してもらい、ガイド修正の影響が大きければプログラムの方を修正するしかない。
　そして翌朝、関係者で打ち合わせが行われた。大手からは森下と寺岡、銀行からは亀村調査役が参加者した。画面が動かなかった問題の対策会議と同じ布陣であり、苦い記憶が蘇った。
　まずは森下が切り出した。
　「ＧＣＳＣさん、今度はガイドの間違いですか。一体、どの程度の間違いがあるのですか？」
　「まず誤りの内容としては、プログラムの名称等です。実装物のスペルミスを修正したものがガイドには反映されていません。」
　新島が淡々と説明した。
　「で、その間違いは何か所あるのですか？」
　「３００か所です。」
　「えっ？３００か所？そんなの・・もう実装は始まってるんですよ！どうしろというのですか！？」
　やはり、想定通りの反応だ。君津が内訳の説明をした。
　「全体で３００個ですが、スペルミスがあるのが２００か所、残り１００か所は引数が異なっており、設計に影響があるかもしれません。」
　「冗談じゃないですよ！もう実装だって始まってるんですから、直ぐに修正版を提示してください！」
　「申し訳ありませんが、直ぐには無理です。修正のスケジュールも合わせてご提示します。」
　そこへ亀村調査役が割って入ってきた。
　「大手さん、まずはどこが間違っていたのかを確認してもらって、影響の有無を教えてもらえませんか。ＧＣＳＣさんは大半がスペルミスだと言っていますし、影響に応じて対応してもらおうと思いますので、これからどうすべきかを考えましょう。」
　この会議の直前に、亀村調査役には一通りの状況は報告していた。数こそ多いため目立ってしまうが、大半はガイドのスペルミス。残りは影響を確認してもらったうえで対応を考えようと話していた。
　「誤った箇所はリストにしていますので、それで確認できると思います。」
　「わかりました。リストがあるのであれば、こちらも確認してみます。」
　問題が発覚した場合、言い方を間違うと様々な反発が生じる。この時も無駄な争いを起こさないよう準備したかったが、こればかりは仕方がない。その日のうちに影響調査したところ、業務アプリで単純置換すれば良いことがわかった。そのため、両社で必要以上に騒いでしまった事件となった。
　結局３００か所のガイドの誤りを修正し再提示するという追加作業が増えてしまったが、君津配下の部署からさらに要員を補充したうえで対応を進めることとなった。持つべきものは責任者だ。こればかりは優秀なエンジニアが１人でどうにかなるものでもない。
　２０２０年５月１日。
　今年も大型連休を迎える時期となったが、プロジェクトは休み返上で何とかスケジュールを保っていた。業務共通チームはその後もいくつか事件を繰り返しながら、今月末に控えている残りの機能のリリースに向けてかろうじて進捗を進めていた。一方で、業務アプリチームの状況が不明だ。
　半年遡ること２０１９年１２月。業務共通チームがこれから色々な事件を迎えようとしていたころ、実は業務アプリチームも窮地に陥っていた。このチームの柱であった、中井が離脱していたのだ。その頃の業務アプリチームでは、業務アプリケーションの設計が終盤となっていた。共通チームのガイドを見て設計を進めるという意味では大手製作所と同じであったが、セキュリティという業務は共通機能にやたら依存した。例えば例外処理。共通機能に例外コンポーネントというのがあるが、画面だけは業務アプリとして開発することとなっていた。画面は共通機能ではない、ということが一つの理由であったが、そのため別々のチームが同じ機能を手分けして開発する、という歪な構図となっていた。
　仲良く開発できればそれでも良かったが、当時の共通チームの状況はそれどころではない。何せまともに設計できる要員が極端に少なったのである。プロジェクトが共通チームの問題で手いっぱいとなっていたため、業務アプリは中井に管理が任せっきりとなっていた。
　会社の異なる大手製作所とは対照的に、ＧＣＳＣの業務アプリチームは、半分放置状態となっていた。中井たちも、共通チームの忙しさに自分たちの問題が発生しても聞くに聞けず、自分たちで何とかしようとしていた。彼らの主要委託先であるサクセス社の川平は、その状態にいつもモヤモヤしていた。
　「中井さん、エラー画面とのインターフェース決めないと設計が進みませんよ。共通チームと課題検討会は出来ないのでしょうか。」
　「川平さん、エラー画面の遷移仕様は決められますか？それがなく話しても、結局業務としてどうしたいかを聞かれるだけですよ。」
　川平が怪訝な表情で反応する。
　「そもそも画面を作るといっても、デザインするだけではないのですか？エラー遷移という汎用的なものの仕様を考えろと言われても、そこは共通チームの範疇だと思うのですが・・。」
　「共通の人たちからは、業務要件を明確にしてください、と言われていますので、まず案を出すところからです。」
　中井は、共通チームの足を引っ張ることは避けたかった。そのため、調整に入るにしても調整案を自分達で考えてからだ、と考えていた。
　対してサクセス社は、設計からＩＴ１という開発工程を中心に委託していた会社だ。彼らにとっては時間をかけて仕様を決めることよりも、出来そうな開発をどんどん進めていった方が、早く約束の進捗が進んでいく。それに、このような決めごとに関わるのは責任を負うことにもなるため、出来るだけやりたくなかった。
　「うーん・・まあ、ちょっと整理してみますよ・・。」
　サクセス社の川平は物事を強引に進めていけるタイプではない。そのため、このような課題は彼の中でいくつかストックされたままだった。そして基本設計も間もなく終わるという頃、川平の中で止まっていた課題が噴出した。
　「川平さん、これらの課題は何故放置されているのですか？これでは基本設計が終わりませんよね。」
　「中井さん、以前から言っているようにこちらも共通チームと話すのを待っているんです。仕様を決めるようにと仰っていましたが、何をどこまで決めれば良いのか、具体的な会話が必要です。」
　この頃はただでさえやることは多い。このエラー画面の検討が止まったところで、他に進めるものは山ほどある。そのため個々に問題の状況を聞かなければ放置しているだけだった。
　この頃は真鍋も業務アプリチームに合流していたが、管理を担う中井の負荷は一気に高まり、体力が持たなくなってしまった。その結果、チーム運営だけ川平に任せ、中井は休職に入っていたのだ。
　その後しばらく業務チームはサクセス社に任せっきりとなっていた。北門や中林が応援に来た頃には、隠れた課題がさらに山積みとなり、２０２０年４月の時点で約１００件が残っていた。１件あたり２日かかるとすると、ざっと２００人日。これは３人が専任となって進めても、３ヶ月半かかる計算だ。これにはそもそもの問題もある。かつてプロジェクトの提案を進めていたころ、見積が予算の３倍となってしまい、あれこれ理由を付けて予算に収まるように圧縮をしたことがあった。やらなければならないことは当初のＲＦＰと変わっていないが、やるための人が圧倒的に少なくなってしまっていたのだ。
詳細設計・実装工程の真っただ中に、突然それまでの２倍に当たる要員が補充されてきた。そのタイミングで補充しなければ、工程内で終わらないのは確実だった。２０２０年５月時点では、プロジェクトを開始して最も人数の多い７０名以上の体制となっていた。もはや誰が誰だかわからない。
　一般的な開発プロジェクトのピークはこの実装やＩＴという工程である。これらの工程では、プログラムの本数分の開発人数が必要になるため、どの開発プロジェクトでも最も人数が多い工程となるのだ。だがこのプロジェクトではさらに過小な見積、課題の噴出という事態も発生したうえ、この時の要員の増加率はさらに異様な状態に見えた。
　かつて大島に始まり、神津や三宅など連鎖的に要員が離脱。それだけでなく、メンバーの小岳やＰＭＯの池田、その後も２ケタを超える要員が日に日に離脱していった。呪われたプロジェクトと揶揄されてきたが、そのたびに補充を繰り返し、もはや元の体制は影も形もない。プロジェクトの山場となるこの工程は、とにかく終わるまで要員を動員し、一度進めば撤退などありえない、最大の消耗戦となるのだ。
　そうして実装も終わる頃の２０２０年６月。
　何とか必要な体制を揃え、入替を繰り返しながらも遅れのないよう開発を進めていた。既に全員満身創痍だ。この頃のプロジェクトは、開始して２年が経過しようとしており、ちょうど折り返し地点となっていた。この先は開発したプログラムを１つ１つ検証していくテスト工程に入っていく。システムはプログラムだけでは完成しないが、原型は出来上がったといえるだろう。ただし、あくまで設計が正しく、その通りに実装されていれば、という前提付きだ。
　残り２年もあるというテスト期間は、どのようになっていくのか。
　開発が終わった今、結果は神のみぞ知るところとなった。