８ フロントチャネル第一戦線
少し遡ること２０１８年１０月。基盤フレームワークが設計を開始した頃、業務共通チームは大島がようやく本格合流した。以前も書いたが、このチームの成果物は、開発者が利用する機能をまとまった機能単位で提供することであった。
だが彼らの開発計画は最初から出遅れ、その後プロジェクトを大惨事に導き、数多の困難の引き金となってしまうのであった。
不幸の始まりは、大島が以前のプロジェクトの引き継ぎに時間がかかり、本格参入時期が遅れたことにある。大島不在の場合は小岳がチームの面倒を見ることになっていたが、小岳はまだ見習いであり、大島がいないと物事がほとんど進まなかった。それを補うためでもあった神津の合流も、結果的に入社が決まるまでに数ヶ月を要していた。チームをリードすべき人間がいないと、メンバーだけではほぼ活動が停滞するのがプロジェクトだ。
さらに不運なことは、このチームを担う専任パートナーがいなかったことである。基盤フレームワークチームであればイージー社、業務アプリチームであればサクセス社という主要な委託先がいる。だが業務共通チームは派遣の高橋の他、複数の会社から寄せ集めるようにしてチームが出来ていた。
仮にこれが一つの会社にまとめられていたとしたら、その中でリードする人間がいるはずであり、たとえＧＣＳＣの体制が脆弱であったとしても、チームとして機能したことだろう。だが本当に寄せ集めになっていたこのチームには一体感がなく、人の集まりでしかなかったのだ。
このような状況が生じた背景として、ちょうどこの頃はメガバンク各行のシステム更改がピークを迎え、銀行業務が担えるハイレベルなエンジニアが労働市場で枯渇していた。そのためエンジニアを集めてみたものの、アプリの開発経験はあっても、業務共通機能は作ったことがない人たちばかりとなってしまった。
この問題に対して姫宮はエンジニアを集めるため本社に幾度となく調整の要請を出してきたが、人が集まったこと自体がマシだったと思えるほど、本当にエンジニア不足であり、どうにもならない問題であった。そのため最後は片っ端からかき集めた結果、この体制になってしまったのである。
このような三重苦を抱えながら、チームは要件定義を開始した。どれだけこのチームが未熟で大変だったのかを理解するには、ある日行われた、チェックコンポーネントの要件定義レビューに関する、パートナーの大谷氏とのやり取りを見れば十分だろう。チームとしての最初の活動である。
―チェックコンポーネントのレビューにて
「大谷さん、では説明をお願いします。」
レビューア（レビューする人）でありファシリテーターの大島が大谷へ説明を促した。
「すみません、このチェックコンポーネントというのは、チェック機能を準備すれば良いのですよね？必須チェックと、数字チェック、全角文字チェックは必要になると思って定義してみたのですが、それで良いのでしょうか。」
作成した成果物について大谷から説明してもらうことを期待していたのだが、逆にいきなり質問されてしまった。さらに、それに呼応するように、小岳が無邪気に質問した。
「あれ？それだけで良いのですか？私はチェックってもっといっぱい用意されるのかと思っていました。」
彼は見習いであり、レビューする立場にはないが、各コンポーネントのレビュー内容を共有するため、何回かはチーム全体でレビュー会を開くことになっていた。そのためこの日は小岳や高橋などチームメンバー全員が参加していた。
「そうなんでしょうか？その、どうやって定義していけば良いかが私は分からないのですが・・・。」
自分の質問で困惑させてしまったと、小岳は申し訳なさそうな小声で呟く。
「それは・・私にもわかりません・・。」
レビューとは成果物の誤りや漏れなどを指摘することによって、質を高める活動だ。そのためレビューアは有識者である必要がある。その意味で、わからない人間がレビューをすることほど無駄なことはない。だが今一番心細いのは大谷だ。
「そうですか・・。」
そういったまま黙りこんでしまった。他のメンバーに助けを求めようと見渡したが、誰も顔を合わせようとしない。そしてそのまま場の空気が一気に重くなってしまった。
そこへ同席していた高橋氏が見かねて声をかけた。偶然にもこの辺りには土地勘があるようで、考え方を示してくれたのだ。
「そういうのはですね、現行システムの設計書を引っ張ってきて、全ての画面で行われているチェックを並べて、多い順に作っていくんですよ。そうすれば必須チェックだけでなく、口座番号や電話番号、メールアドレスなどの属性に従ったチェックのセットが一通り洗い出せるでしょう？」
レビューに人を集める意味は、参加メンバーの反応を見て力量を観察出来るという側面もある。もっとも、このとき高橋が反応したのは偶然でしかない。逆に高橋の助言によって具体的な作業が見えてきた大谷は、助け舟にすがるように話の方向を変えてきた。
「なるほど、では現行システムの設計書を全部見なくてはならないのですね。結構大変な作業になりますので、１週間ほどお時間を頂けますか。」
これではもはやレビューではなく、進め方の打ち合わせだ。レビューらしいことは何もしていない。大島はチームの管理者としてこの提案を受けるか少し考えたが、この高橋氏のスキルも上手く使えないかと急なアサインまで思いついた。
「わかりました。ではまず１週間後に洗い出しの結果から、チェック機能の候補を整理してもらえますか。この辺りは高橋さんがお詳しいようなので、作業状況をチェックして頂き、また次回もレビューをお願いします。」
そう指示されると高橋は渋々答えた。
「わかりましたが、自分の設計作業もありますからね。そちらも期間の猶予を頂きたいのですが。」
「そうですよね。必要な期間は確保するようにしましょう。」
高橋にとっては貰い事故だ。黙って聞いていれば良いから参加しろと言われたレビューで、なぜ仕事が増えるのか。怪訝そうな表情でたまらずグチをこぼした。
「そもそも、レビューって完成したものをチェックするんですよね？相談会になっていませんか？これ。」
全ての機能とは言わないが、ほとんどのやり取りはこのようなものであった。ちょっと遠目に見ても、素人が集まり、相談しながら当たり障りのない合議制で進めているようにしか見えない。
しかしながら、大島としては困っている大谷を助けられた気分であった。小岳も最初こそ余計なことを言ってしまったと後悔していたが、結果的に助け舟の呼び水になったと、満足していた。
煽りを食らった高橋は、はじめの方こそ、それでもチームのためになるのであればと前向きに考えていたが、実際にはほとんどの機能で似たような展開となっていった。そしてこれらのことが次第に彼の中で不満を募らせることになる。
成果物を検査すべきはずのレビューが終始このような状態であり、このチームの要件定義は遅々として進まなかった。だがそんなこととは無関係に、プロジェクトの要件定義工程は進んでいく。
２０１９年１月。
業務共通チームの中間状況報告として、朝比奈調査役との確認会が行われた。参加者は、大島と小岳だ。
「えーっと、これが要件定義の成果物ってことで、合ってます？？要件定義のはずですが、中身はＲＦＰと同じような内容が書かれているだけですよね。単なる書き写しにしか見えないのですが、これで一体何を定義したというのでしょうか？」
目の前で一つ一つファイルを開き、状況証拠を確認しながら、嘲笑うように質問した。いつもそうだが、朝比奈調査役の関心ごとは確かに重要であり、質問も本質的で狙い撃ちしてくる。聞かれたくない質問なだけに、大島はしどろもどろの回答しか出来なかった。
「えーと、まあ、要件を定義するという意味では、ＲＦＰの内容は全面的に前提とすべきものだと考えています。では次の工程の設計では何をするのかと言うと、要件定義で決めた各機能について、テーブルや入出力項目を決めていくわけですね。」
「はい。つまり・・何が言いたいのでしたっけ？」
朝比奈調査役は不思議そうに大島の顔を見つめながら聞いた。
「はい。つまり、その、ここまでＲＦＰで要件が決まっていますので、それらを具体的なドキュメントにしていくことが、基本的な要件定義の活動だと考えています。」
「うーん。改めて要件定義や基本設計の工程を説明してもらわなくても、そんな事はわかっているのですが・・。」
大島たちは検討を繰り返していたが、成果物としてはほぼ何も進んでいない状態であったため、何とか時間稼ぎのための説明をしようと必死であった。だが、彼が説明していることは、状況の説明とは程遠いものであり、意図はとっくに見透かされていた。
すかさず次の質問が飛んでくる。
「で、いつまでに何が出来るのでしたっけ？？」
「はい。いずれにしても、まずは詳細なスケジュールを作成します。」
目先のことで精一杯の大島には、今後の予定など考える余裕すらなかった。逆に朝比奈調査役は、半笑いで聞いている。
「そうですね。まあ時間はまだありますし、ＧＣＳＣさんがこの先どのような進め方にされようとしているのかわかれば、私も具体的に入ってレビュー出来ますしね。可能なことはご協力しますので、決めてくださいね。」
「はい、ありがとうございます。」
朝比奈調査役の厚意はありがたいが、先のことが何も考えられないこの時点ではどうすることもできず、話は聞き流すことしかできなかった。
大島は、かつて帝国銀行のインターネットバンキング開発プロジェクトを支えたうちの一人である。姫宮もよくその人となりを理解していたつもりだった。彼は仕事を要領良く進めてくれるのだが、どこまで深く物事を考えているのかわからないところがある。少しお調子者なところもあるが、それは愛嬌であり、受け入れてくれる顧客には逆に評判も良い。しかしながら朝比奈調査役の前では、理屈に基づいて話すこと以外は無力であった。
姫宮の期待も、ＲＦＰに示されていたシステム化構想を確実にシステムとして作り上げるために、大島にはその設計思想を引き継いでもらいと思っていた。だが彼は、ＲＦＰの背景にあるそもそもの要求や目的などを把握しようとしなかった。
ＲＦＰで要求されたものだけを作れば良い。それは間違いではないが、検討を進めていくと、姿形を変えた方が良いものが出てくる。扉はスライド式か、それとも引戸が良いのか。実際に住む人が希望する生活スタイルや動線によって、家に対するニーズは変わっていくはずだ。一般的な家の作りが引戸だからと、それで最終的な仕様が確定しているわけではないのだ。
だが大島は、ＲＦＰ以上に踏み込んで考えようとしなかった。このスタンスにより、朝比奈調査役の不信感が増していくことになった。
ひと月後の状況報告会。
「大島さん、結局要件定義は、ＲＦＰの書き写しのままで進めるのですか？」
「はい、以前もお伝えした通り、そうしようと思っています。」
「まあ、良いですよ。では設計はどのようなスケジュールで進めますか？早くできるものからで構いませんので、いつ何ができるのか、出してくださいよ。」
いくら言われても、今のチームのパフォーマンスでは、いちいち皆んなで相談してからでないと結論が出せない。そのため即答は避けたかった。
「それは、持ち帰り検討してきます。」
ここ数週間、大島は同じ理由で言い逃れてきた。だが朝比奈調査役としても、これまで何度も待たされ、一週間ごとに延期延期と言われ続けてきた。ここは見逃がすわけにはいかなかった。
「前回もそのパターンで逃げましたよね？一体、いつになったらスケジュールを見せてもらえるんですか？もう、こちらから指定しますので、それでどうですか？まずはチェックコンポーネントの設計をレビューしましょうよ。」
これまで何度も言い逃れてきたが、大島は追い詰められてしまったと思った。でも今日まで引っ張ってきて、要件定義はＲＦＰの書き写しで良いと言ってもらえたのだ。そろそろ仕方ないと言い聞かせるように、観念して答える。
「はい、わかりました。」
朝比奈調査役はすかさず即答した。
「では次週準備お願いしますね。」
チェックコンポーネントは要件定義から難航し、高橋が無茶振りされた機能だ。その後のフォローもなく、高橋がイヤイヤ面倒を見ていた状況であり、設計はまだ途中であった。つまり現時点で朝比奈調査役にこれを見せたところで、結果は見えている。そして、そのまま翌週のレビュー会を迎えた。説明は、設計担当者の大谷から行われた。
「どのように考えたら、これらのチェックのラインナップになるのでしたっけ？業務アプリの開発者はどのように使えば良いのですか？例外処理はどのようにまとめるのですか？その際の画面遷移のパターンは？基盤フレームワークとどう機能分担しているの？機能追加にはどう対応・・・。」
説明をしている大谷は、朝比奈調査役に質問されるたび、目線が合わないよう大島の方に顔を背けていた。これらの質問は間違いなく設計者である自分に向いているとは思ったが、途中から高橋の言いなりとなって資料作りだけしてきた大谷は、当然答えを持ち合わせていない。肝心の高橋は、銀行レビューまでは自分の範疇ではないと、この場には居なかった。
ついに大谷は何も言えずに困り果て、後半は朝比奈調査役が言葉を発するたびに終始うなだれていた。
大島も直接機能の設計を行ったわけではないため、助けを求められてもすぐに答えられない。なにせチーム内で都度集まって、話し合いで決めてきた設計だ。矢継ぎ早の質問攻めに対して、部分的に答えてみたものの、もはや後半はたじろぐことしか出来なかった。
その状況の中で、次第に矛先は大島自身に向けられていく。
「大島さん、本当に理解していますか？チームリーダーをされているのですよね？コンポーネント間がどうつながって、基盤フレームワークとどう分担されて、業務アプリ開発者がどうやって開発を進めていくのか。そこが全部クリアに決まっていないと、共通機能の設計とは言えませんよ。基盤フレームワークのアウトプットはそこまで踏み込んで整理されていますけど、見たことあります？次回までの宿題にしておきますので、説明してくださいね。」
半分笑っているが、半分笑っていない。怒っているのか、試しているのか、表情からは全く感情が読み取れなかった。そこがまた悩みの種となっていった。
因みに業務共通チームの担当している機能は、このチェックコンポーネントの他、銀行支店管理やカレンダー管理など２０個以上ある。つまり、これらのやりとりがあと２０回以上あるということだ。一つだけでも相談して進めるのにとても時間がかかるのに、大島は今後の展開を想像しただけで目眩がした。
さらに朝比奈調査役の、この能の仮面のような表情から、次は一体どんな質問が出てくるのか、全く想像が出来なかった。そのためレビューを繰り返していくたびに、朝比奈調査役と対峙することが、次第に大島にとって恐怖となっていった。説明会以外にも、毎週行われる朝比奈調査役との進捗会でも詰められながら、大島は次第に追い込まれていった。
そして、２０１９年２月末。姫宮は大島から面談を求められた。
姫宮も、この数ヶ月の大島のやつれ具合に、どのような話なのかはすぐに察した。
「姫宮さん、自分ではもうこれ以上進められません。申し訳ありませんが、お休みを頂きたいです。」
「そうか。ここまで辛い思いをさせてしまって、申し訳ない。」
二人の間では、これ以上は何も言葉は交わされなかった。いや、かけるべき言葉が見つからなかった。全ては、姫宮のアサインとフォロー不足のせいであり、犠牲者は大島の方なのだ。もちろん姫宮も、この日はじめて状況を理解したわけではない。チーム内レビューにも参加し、改善のための助言や、朝比奈調査役との打ち合わせの度に逐一状況を把握してきた。だが有効な手立てがないまま、ここまで過ごしてしまった。
大島は、この日をもってプロジェクトを離任した。そしてチーム「レインフォース」にとって、この日が最初の失敗となった。
翌日―
事の次第は、そのまま会社の上層部へ伝えられた。当然ながら、なぜこのような事態となってしまったのか説明が求められ、姫宮は南町専務に呼び出されていた。
「姫宮くん、君たち、何でそんなことになってるんだっけ？」
「申し訳ありません。顧客の理詰めに、大島一人で対峙していたような状況で、次第に本人が追いつめられる状況となりました。以前から言っているように設計メンバーのスキル不足が根本原因ですので、チームリーダーの交代だけでなく、プロジェクトメンバーの強化もお願いしたいと考えています。」
「神津だっているんだろう？東山はどうした？結局管理者がわかってないってことが、一番の原因なんじゃないの？君も含めて。ね。」
管理責任を問われたところで、設計を進めるのは担当者だ。家の建て方を知らない人が集まっている以上、このまま続けても絶対に家は建たない。
「私に責任を取らせたいのであれば、どのようにでもしてください。でもメンバーを強化しない限り、この先の設計は進みません。」
「だから、出来ないなら作るんじゃなくて、使えって言ってるんだよ。何逆ギレしてんの？君の、その中途半端な判断がこんな事態を招いたんだろう。やっぱりまだわかってないよねぇ。」
使えと言われても、作る前提で取った仕事だ。多少の流用はしているが簡単に方針を変更できるわけがないだろう。と姫宮は心の中で言い返した。だがそんなことをしていても事態は進まない。そんな姫宮を、南町専務は腕組みしながら半笑いで見ている。
「まあいいや、設計者については技術部と話しておきますから、後日面談しておいて。」
不服そうな表情から察してくれたのだろうか。既に次の手は打たれており、そのことを告げてくれたのだ。さすがに南町専務も会社の人間である。危機になる前に救おうと、技術部にいる適任者が調整できるよう、手を回してくれていたようだ。
「ありがとうございます。」
この時ほど、大きな会社にいて良かったと思ったことはない。ＧＣＳＣは大手ＳＩｅｒであり、数千人というエンジニアが働いている。プロジェクトがトラブル状態になった場合、何としてでも人を集め、ヘルプのために投入して解決する。その際の動員力は中小企業のそれとは桁違いであり、もはやＳＩ業界のお家芸となっていた。
逆にプロジェクトをそのような状態にした人物は、トラブルメーカーとしてレッテルが貼られてしまう。「まさか自分のプロジェクトが」と、この時は姫宮も天を仰いだが、そんな感傷に浸る間もなく、この時の会社の速やかな対応は何よりの助けとなった。
この段階での体制強化により、かつて大島と同じくプロジェクトへの参画を切望していた三宅、そして技術部からは新島というエンジニアが合流してくれることとなった。その頃の三宅は日の丸銀行のプロジェクトでチームリーダーを担っていたが、大規模なグローバルプロジェクトには関わっていなかったため、このタイミングでは比較的調整がしやすかったようである。
彼はプロジェクト管理も十分任せられるうえに、エンジニアと対等な目線で話しができるなど非常にバランス感覚に優れており、このチームを任せるには十分な才能を有していた。そのためメンバーさえ強化されれば、朝比奈調査役とも十分渡り合えると確信を持つことが出来た。
もう一人の新島は、技術部に所属しているシニアエンジニアだ。技術部は、主にシステム上の技術課題を担当している部署であり、職人と呼ばれる人たちが多かった。その中で新島は、社内で自社システムを開発するプロジェクトに従事しており、そちらは直ぐに調整ができた。そのため面談の翌日から来てくれることになったのである。
さらにメンバーの強化として、技術部の中堅エンジニアである藤原が着任した。真鍋ほど若くはないが、３０代前半にしてＪａｖａ関係のプロジェクトを多く経験していた。業務共通チームのパートナーが複数社となっていた状況は続いたが、このタイミングにして、これらはかなりの強化となった。プロジェクトのスタートから約９カ月が経過していたが、ようやく設計経験者が参画したのである。
技術部の二人が着任する前日、姫宮が面談を行った際に、一通りのプロジェクトの説明を行なった。すると新島が速攻で質問をしてきた。
「どうも、姫宮さん。早速教えてちょうだい。どんなシステムで何を作ろうとしているの？お客さんの役割、プライムベンダーとの関係とか、全部教えてちょうだい！」
新島氏について表現すると、屈託のない人物で、プロジェクトの目的達成をただひたすら考えているような、生粋のエンジニアだ。旧ＧＣＳの出身で、銀行系では外国為替という難しい業務のシステム開発を長く経験しており、知識としても申し分ない。その上、出だしのように前のめりであるため、チームの課題解決をリードしていくのに相応しい人物であった。
ただし少し、話し言葉に特徴があった。男性であるが「〜してちょうだい。」という言い回しを使う。これは主に昔から女性が使ってきた言葉だ。それも旅館の女将が女中に指図する時のような、上下関係を前提とした言い回しである。
ただし強い命令口調ではなく、図々しい中にも親しみがあり、相手を身内のように扱っていると暗に伝え、厳しさとともに懐の深さや温かみをも感じさせてくれる言葉だ。それによってチーム内でギクシャクしていた関係性が改善するきっかけとなり、風通しが良くなっていった。新島にとっても、これから直面することは他人事ではなく、自分ごととして自信と覚悟を表していた。
この時は姫宮から、対象システムはインターネットバンキングであること、勘定系と同時更改を行う予定であることの他、プロジェクトの概要や体制、現在の問題点などについて一通り説明を行った。
「あら、それは大変ね。インターネットバンキングなんて直接経験したことはないけれど、外貨送金に比べたら業務的にも随分楽なものね。きっと大丈夫よ。任せてちょうだい！」
新島は外国為替のうち外貨送金というシステムの開発経験が豊富であった。資金などの取引情報を電文に乗せて通信するという意味では、インターネットバンキング以上に複雑なシステムを経験しており、職人の域に達している。翌日着任して、直ぐに作業に取り掛かった。
「ちょっとそこのあんた！この機能について教えてちょうだい！」
「そっちじゃなくてこっちでしょ。なんでこんな設計しかできないの？あんたやったことないわけ？もう代わって！」
「あんたはこれやって！三宅さんスケジュール書いてちょーだい！」
こんな調子で、あっという間にチームの中心となっていった。そして気がつくと新島が全ての指揮を取っていった。いや、むしろこれは当然だろう。もともとのチームメンバーの経験値が低すぎるだけで、頼れる人物が一人入ると、ここまで活気も違うのかと思わせるほどの、チームの変貌ぶりであった。
そして大谷が担当していたチェックコンポーネントをテコ入れしたかと思うと、朝比奈調査役にとって２度目となる設計レビューがやってきた。二人はこの時相まみえることになったのである。
「朝比奈さん、はじめまして。新島と申します。なんだかうちの連中が訳わかんなくてすみません。ずいぶんお困りになったことでしょう。」
新島流のアプローチだ。知らない人でも懐に入るのが上手い。というかやや図々しい。
「えーっと、新島さんですよね。お噂は予々伺っております。宜しくお願いしますね。」
「それは至極光栄です。では早速ですが、チェックコンポーネントの設計レビューをお願い致します。」
そういうと、ディスプレイに表示されている設計書を一気に説明した。
「チェックコンポーネントでは、インターネットバンキングの入出力項目に対する標準的なチェック機能を提供します。現行システムを分析して項目ごとのチェックパターンは洗い出しましたので、それぞれにチェックメソッドを定義していきます。。」
順調な滑り出しだ。朝比奈調査役も画面を見つめ、新島の話を聞きながら頷いていた。
「なるほど。それだけ定義することがあるとすると、開発者はどうやって間違いがないように使い分けられますか？」
以前のチームであれば全員思考停止になること間違いなしの質問だが、新島はすぐに反応した。
「画面ごとに入力フィールドを格納するＪａｖａＢｅａｎに、属性付きでフィールドを定義してもらいます。その際に間違って定義しないよう、Ｂｅａｎ定義書をＥｘｃｅｌで作ってもらいますが、予め用意しておいたチェック仕様をプルダウンで選んでもらおうと考えています。」
「なるほど。プルダウンで選べば間違いないですし、設計さえ間違ってなければ、そのまま実装まで落とし込めるということですね。」
「そうですね。定義書さえ作ってしまえばソースコードなんて自動生成できますし、変数とチェック仕様はＪａｖａのアノテーションでマッピングしますので、問題ありません。Ｂｅａｎバリデーションのチェックとして拡張するという方式です。藤原、あってるわよね？」
「はい。バリデータクラスとアノテーションを作ることによって、どんなチェックでも使いまわすことが出来ます。ですので、その設計で問題ございません。」
新島の勢いと、藤原の精密機械のような返答。二人の説明に納得したように朝比奈調査役が答える。
「なるほど。イメージ通りですね。ではその方向で開発をお願いします。」
良いと言われたが、新島にはまだやることがあった。
「その前に、業務アプリケーション設計者が基本設計を行う際に、標準チェックを埋め込んだ定義書を配布する必要があります。そのためまずは設計標準を作っていこうと思っています。そちらを先にスケジュールしますね。」
「そうですね。まずは標準設計書と、作り方などをガイドにして配布できるようにお願いします。」
こうして朝比奈調査役の設計レビューを終えた。最後はオマケもついたが、全く落ち度のない無難なレビューとなり、朝比奈調査役も満足したようだ。この日のレビューが終わった後、朝比奈調査役が姫宮のところにやってきた。
「姫宮さん、あの新島さんという方、めちゃめちゃ詳しいじゃないですか！若手の藤原さんでしたっけ？彼もＪａｖａ に詳しそうで。これはＧＣＳＣさん、凄いチームになってきましたね！」
朝比奈調査役の思考はエンジニアなのだろう。そういえばかつて自らフレームワークを作っていたと聞いたことがある。彼についていける人は異次元の人たちばかりと思ったが、予想通り新島も異次元だったということだ。逆に姫宮だけが３次元で生きているのが、なんだか場違いに思えてきた。この世界は、全くの異次元で構わないのだ。
２０１９年４月。
新島、藤原の活躍と、神津、そして東山もチームに参戦し、業務共通チームの設計は軌道に乗ろうとしていた。しかしながら、初期の遅れが尾を引き、設計完了までまだあと３ヶ月かかる見通しとなっていた。
当初の算段では、業務アプリケーションチームが基本設計に着手する２０１９年６月までに業務共通機能の設計を固め、業務アプリとして何をどう作るかを綺麗に提示出来るはずだった。ところが、今のこの段階で終わっている設計は全体の約３割。ほぼ予定通りの基盤フレームワークチームに対して、業務共通チームは、業務チームの設計を進めるために必要な、最低限の設計だけが出来上がっていたのみだ。当初の目標に対して全く進んでいない。そしてこの事態は、チームの運命を左右する出来事を生じさせてしまう。
取引履歴という、オンライン処理の結果を記録していく機能がある。パスワードの変更や振り込みなどをいつ行ったのかをシステムで記録し、後で確認できる機能だ。これも業務共通チームで提供する予定であった。その設計についていつも通りチーム内でレビューを行っていた時のこと。
設計者は小岳。大島リーダー時代は小岳も腹心として立ち回っていたが、現在の体制では一担当者となっていた。ただ見習いであるという点は変わりない。その小岳が取引履歴の設計を担当していた。
「小岳さん、設計の前に、業務共通機能としてどんな情報を記録するのか、ちゃんと決めないとダメじゃない。」
「そうですか。考えてはみたのですが、記録したい情報は業務アプリによって変わるんじゃないかと考えていまして。絶対必要となりそうな情報だけを記録することを考えたんです。」
見習いというレベルは変わらなかったが、小岳は小岳で頑張っていた。
「ちがうちがう。そんなことしたら業務アプリにも記録させることになって２度手間になるじゃない。１回で必要なものが全て記録できるようにしないと。」
「そうなんですか。でもどうすれば良いのでしょうか？」
「そんなの簡単よ。現行システム調べて、必ず記録している情報と、取引ごとに取ってる情報を分けるのよ。そして前者は共通のテーブルにして、後者は個別テーブルに記録する。履歴格納用のＢｅａｎクラスは、必ず共通Ｂｅａｎを親クラスに持って継承する。あとはそいつを使って登録用のクラスで一緒にレコードを作成すれば、一発でＯＫ牧場よ！」
レコードとは、取引履歴一件分を指している。新島のアタマでは、チェックコンポーネント同様に現行システムの設計から共通項目を抽出してまとめて設計しておき、Ｊａｖａの機能で共通項目、個別項目を同一のものとして扱えば設計の無駄がない、ということであった。
技術的な部分は分かりにくいかもしれないが、Ｊａｖａの持つオブジェクト指向のメリットを活かした設計であるのは間違いない。そして小岳も新島の話に一応はついて行く。
「新島さん、でもこの前の朝比奈さんのレビューでは、履歴として記録する内容は新たに設計されるため、まだわからないと言われていました。なので現行システムの設計って、調べても意味ないんじゃないですか？」
小岳は無知なだけに無邪気である。設計の進め方について新島に進言するとは。この後どんな反論が返ってくるかわかったものではない。
「ちょっと、あんた！！一体何をわかってるっていうのよ！だいたいあんた達がさっさと作っておけばこんな事にならなかったのよ！いちいち業務の設計待ってたら、共通機能の開発が終わらないじゃない！だから設計の進め方を教えてあげてんのに、何もわかってないわよね！素人ばっかり集めてるからこんな事になるのよ！それにこの・＆＠◆￥％・！！！」
・・想定通りの反応だ。彼の言葉を要約すると、まず共通機能としての仕様があって、業務アプリはそれに従って設計するべき、と新島は言っていた。
家を設計する場合を例にすると、ユニットバスなどは最初から決められた規格があり、それに合わせて部屋の間取りを設計するはずだ。間取りを自由に決めらてから規格品をはめようとしても、サイズが収まらないなどの問題が後から出てくる。そのため、各部屋は標準規格に従って設計する必要があるのだ。そしてこの場合のユニットバスが、共通機能になる。
それに対して、小岳や朝比奈調査役の言っていることは、全てゼロベースで設計していく場合の進め方であるため、部屋の間取りをどうしたいのかを聞いてから個々の規格を設計するべきではないか、ということであった。理想の家を作りたければ、発注者が仕様の策定に深く関わっていくべき、というのはわからないでもない。ただ、そのためのニーズを引き出し、仕様に落とし込むことに対しては、設計者の力量が大きく左右する。
どちらも意見としては正しく聞こえるが、業務アプリの設計は今始まったばかりで、少なくとも設計が固まるまであと６ヶ月はかかる。共通機能の設計を先に提供するためなのに業務アプリの設計を待たねばならぬとは、順番が逆転しているといえよう。とはいえニーズと異なるものを作っても、使い物にならないかもしれない。
このような判断はシステムを開発していく上での大きなジレンマとなりうる。
前者のような考え方は、マーケティングで言うとプロダクトアウトに似ている。メーカーが試行錯誤して作った製品を市場に投入していく戦略で、作れば売れるという前提の考え方だ。対して後者はマーケットインの発想であり、利用者や消費者のニーズを分析し、必要とされるものだけを売っていく戦略だ。
後者の方が多くの技術者に支持されるものを開発できるのは間違いないが、ニーズを把握し分析していくことには、多くの時間がかかる。そのため前者で行くのが近道なのだが、設計の手戻りが発生しないよう、色々な事態を先読みしておく必要もあり、経験が問われることは間違いない。
ただ、そうこうしているうちに業務アプリは６月から一通り設計に着手してしまっている。このタイミングで業務の設計を無視したものを出すわけにも行かず、このようないくつかの機能は、業務の基本設計を待つことになった。
新島たちの合流により軌道に乗りかけたかと思えば、逆に設計は単独で進められない。このように、チームは３歩進んでは２歩下がるという状況であった。ただ、これはこの先の大きな不幸の始まりに過ぎない。
これより少し前、チームの立ち上げ初期からいた大谷が、大島の離任に合わせ契約終了となってしまった。本人もスキルの差を痛く感じていたため、仕方がなかった。さらに以前から不満を溜めていたパートナーの高橋が、突然離任してしまった。それも何の前触れもなく、ある日会社に来たと思ったら、派遣元の自社の営業に対し電話口で怒鳴り声をあげ、そのまま執務室を出て行ってしまったのだ。派遣社員という自由な身分のエンジニアを雇っていた弊害だろう。派遣契約であることから会社として仕事の完成責任もないため、交代を入れることもなくそのまま終了の扱いとなってしまった。
そのうえさらなる不幸がこのチームを襲う。
再就職をしてここまで協力してきた神津からも、突如退職の申し出があった。奥さんの健康がまた悪くなり、近くでサポート出来る環境を作りたいということが理由らしい。ただこれは建前だろう。神津に対する期待も大きかったため、大島が離任し、神津がチームの中心になると考えると当面プロジェクトを続けることになってしまう。そうなる前に自ら身を引いたと考えるのが、妥当と考えられる。
この局面で離任が多発したのは、どれも偶然の出来ごとと思いたいが、こうも重なると、もはやこのプロジェクトが呪われているとしか思えない。そうしてチームの活動がなかなか浮かばれずに時間だけが過ぎていった。
そして２０１９年７月。
チームは人の入替によってどんどん刷新されていく。もはや初期メンバーは小岳くらいしかいないというほどチームは入れ替わった。一年立たずして、チーム自体が再構築されていた。一方新島と藤原が合流して以来、新生チームの決起会も行っていなかったため、時間のあるこのタイミングで実施しようということになった。その決起会は久しぶりの魚見で開催することとなった。
「はじめまして。大将、宜しくお願いするわね。」
女将と大将が対峙する。本人たちは絶対意識がないだろうが、姫宮には奇妙な関係に見えた。
「皆さん、今日はこの時期が旬の鰹が入っています。藁焼きにしてお出ししますから、沢山召し上がってください。」
大将は、いつも通りのペースである。
「藁焼きって、高知のでしょう？魚に合わせて何でもメニューをアレンジしてしまうなんて、大将なかなかやるじゃないの。」
業界は違えど、新島も職人だ。見ただけでそのレベルがわかるのだろうか。
「そんなことより姫宮さん、何なのこのプロジェクトは。多少はトラブルだと聞いていたけれど、ちょっとどころじゃないじゃない。神津さんまで辞めて行っちゃうって、ちょっとこの先考えないと回らないわよね。とにかく技術者が重要よ。何とかならないの？」
何とかしたいし会社とも人の話は散々してきたが、新島たちが入った瞬間がピークだったとは、言えない。
「ええ、引き続き強化に向けて募集は行いますので、もう少し待って頂けませんか。」
「待てと言われても、いつまでも待ってたらプロジェクトが終わってしまうじゃない。早くしてちょうだい。それから最近来た王さんだっけ？そもそも日本語から勉強してもらわなくちゃ、話にならないわね。教えるのにも凄い時間かかってるんだから。」
「日本語は全く問題ない様子でしたが、そうなのですね。」
「そうなのですねじゃないわよ！なに淡々と返事してるのよ！あんたのせいでこっちは大変な思いをしてるのよ！わかってんの！」
新島は感情の起伏も大きい。人間だから当然なのだが、今日は酒の勢いもあり、それを剥き出しにしているようだ。ここは冷静になることが重要だ。
「新島さん、申し訳ありません。これまでの体制は私が作って来ましたので、全ては私の責任です。いくらでも責めてください。ただ、直ぐにどうすることも出来ないため、皆さんのご協力をお願いしたいと思っています。」
「ふん！何よ！」
「はっきり伝えておくと、次の援軍は来ない可能性もあります。来ることを前提にしておくのではなく、少しでも今のチームの底上げをして欲しいのです。」
「そんなの、何でアタシがやらなきゃなんないのよ！！冗談じゃないわ。あんたたちの仕事でしょ！だいたいあんなクソ・・△！◆＆※！！！」
・・今夜は長くなりそうだ。姫宮はつくづく人間というものの扱い方を考えさせられた。コンピュータの方がよっぽど素直で、物分かりが良い。この状況をボタン１つでリセットすることができれば、どれだけ楽になるだろう。
次期システムプロジェクトにおけるフロントチャネルの第一線は、最初から困難な道のりを歩んだ。それは勘定系も含めたプロジェクトの中で最も過酷な激戦地帯であることには違いない。ただ、悩みどころがシステム開発というより、スキルや人間関係に四苦八苦しているだけの、自爆にも近いレベルの事ばかりだ。特異さはあるものの、普通のチームで、普通のシステムを、普通のスケジュールで開発を進めることがこれほど困難なことになるとは。
とはいえ現実は直ぐには変わるものではない。フロントチャネル第一戦線は、陥落することなくプロジェクトを完遂することが出来るのだろうか。全てはここに集うチーム「レインフォース」全員の手に委ねられた。
この記事が気に入ったらサポートをしてみませんか？