ブリング・ミ・トゥ・ライフ

堀井たくぞう

小説

25,079文字

2004年・冬。ITビジネスに翻弄される女性エンジニア――実話に基づいた物語。てか、ほぼ実話です。

私は自室のCDラックの前で逡巡を重ねていた。

そのCDコレクションは膨大だ。80年代の半ばにCDというものが登場してからの三十余年――それは私が小学生の頃から現在に到るまでの期間に該当する――に亘って買い集めたものである。小学生の頃はまだビニール(もちろん当時はビニールなどとは呼ばずLPないしシングルと呼んでいた)の方が主流だったが、新しモノ好きの父の影響で私は最初からCDを手にした。基本的に手放したものはない。ほんの数枚ほど友人に貸したままのものがあるだけ。その友人とは疎遠になってしまったので、返してもらう機会は恐らく永遠に失われてしまっている。

仕事のBGMとして流すための、今の気分に合った音楽をチョイスする――これだけ膨大なコレクションを前に私はその簡単な(と思われる)選択をできかねている。

その状況に少しずつ自分がイライラとし始めているのを感じて、音楽を流すのを諦めようかとも考える。

恐らく今の気分に合った音楽というものは存在しないのだ、厳密には。

気分に合う音楽を探すという作業は、過去に味わったことのある様々な気分のバリエーションの中から今の気分に似たものを選んで、その型に今の気分を無理やり当て嵌めるようなものなのではないか。つまりは音楽の方に自分の気分を合わすわけである。そして、若いうちはそれでよかった。気分の方にそれだけの柔軟性があったから。だが、歳をとって偏屈になり、すこしでも音楽の方に歩み寄ろうなどという姿勢は失われた、とか。

もし自分が優れたミュージシャンだったら、常に自分だけのために自分の現在の気分に合った音楽を奏でることができたりするのかもしれない。しかし仮にそれができたとして、それをBGMに仕事をすることはできない。そのためには自分が二人、必要だ――おい、ちょっと待て。自分が二人いたとて、その二人の気分がシンクロしているという保証はあるのか、むしろ二人はいがみ合うだけではないのか――ああ、バカバカしい。

そんなことを考えながら、私は机の前に座り、仕事にとりかかる準備をする。

私はミュージシャンではないし、楽器も弾くことはできない。単なるリスナーだ。ジャンルにこだわることなく貪欲に聴き漁るリスナー。それだけに自分にフィットする音楽を探し出すアンテナにだけは自信があったのだが、今はこうして仕事のBGMに流すCDの選択さえ放棄せざるを得ない。

今でも私の知らない何処かでは無名のミュージシャンらによって産み出された才気に満ちた音楽が私によって見つけ出されるのをじっと待っているのだろうか。それとも彼らは私のような中年女性リスナーなど眼中になく、ひたすら若者に媚びたような音楽だけを量産しているのか――などと考えていると次第に腹が立ってきて、音楽なんぞ流さんでいいだろう、という気にもなる。

BGM抜きで私は仕事を始めた。

私はプログラマだ。コンピュータ・プログラマ。人は私のことをアーキテクトと呼ぶこともあるが、私自身は自己をプログラマと規定している。

しばらくいろいろとあって仕事はできなかった――いろいろあったのは主に私の頭の中の出来事であったのだけれど――が、何かしないことには暮らしていけない。なんとか体勢を立て直し、昔のツテを頼りに自宅で仕事をするようになった。それがこの一、二年のことである。

仕事の打ち合わせ的なことは全てメールとチャットを介して行われるので、私が仕事のために外出をすることは、ほぼ、無い。もし実際に顔を合わせて打ち合わせないとならないとなると、そのためだけに半日が費やされてしまう。交通費だけで私の一日の勤労の対価が消えてしまう。

そういう場所に私は引っ込んだのだ。

であるからして、私は仕事のために外出はしないが、その代わりに、毎日の散歩を自らに課している。これは、嵐でも来ない限りは雨の日も風の日も欠かすことがない。散歩には、雨の日は雨の日の、風の日は風の日の、良さ、というものがある。天気のいい日にしか散歩しない、というのは喩えて言えば、そう、クラシックしか聴かない音楽ファン、寿司しか食べない美食家、恋愛小説しか読まない読書家――あまりいい喩えが思いつかないな。

そんなことを考えながら仕事を始めようとした私の手は、しかし、すぐに止まった。昨日の私は、ウェブサイトに追加される予定の新機能に必要な新しい変数のひとつを既存のどのクラスに入れるかで迷っていた。転校してきた生徒をどのクラスに編入するかみたいな単純な話ではない。その変数の意味合いとクラスの特性とを考慮した正しい選択をしないと後々に様々なプログラミング上の問題を引き起こす可能性がある。つまりここではホグワーツの組分け帽子の素養が求められるのだ。その選択での迷いが払拭できなかったので、とりあえず一晩おいて考え直そうと思いつつ昨日は一日の仕事を終わりにしていたのだった。

迷った時に、そのまま突っ走らずに、とりあえず時間をおいて考え直す、というのは私の常套手段である。リフレッシュした眼で事態を見つめ直すことで冷静に最適解を選択することができる。突っ走ってしまえば、後から選択が間違っていたことに気づいたとしても、引き返すのは難しい。私のように長く仕事をしていればその分たくさんの失敗を積み重ねてきてもいるわけで、それだけに回避術もいろいろと身に付けることになる。

私が今、手がけているのは、海外ホテルの検索・予約機能を提供するウェブサイトの設計・開発だ。このサイトはもうすでにプロダクション(本番)で稼働中であるが、常時、追加の新機能を開発中の状態である。

細かい機能は常に試行錯誤で改善されていく。変化が毎回、良い方向に進むとは限らないが、それでも変化を続けていれば全体としては良い方向に進めることができる。悪い方向に進んでしまうことを恐れずに変化し続けること、それがネットの世界での生き残り戦略だ。いや、それはネットの中だけに限らないか。

過程でしかない。その観点では、どんな変化も正当だ。傍目にはどんなに悪い方向に進んでいるように見えようとも。

それから今は、細かい機能の改善だけではなく、連携先のB2B旅行業者の追加という大きな作業を抱えている。

B2B(Business To Business)旅行業者というのは、まあ、インターネット上のホテル予約の卸業者みたいなものである。私の開発しているウェブサイトは(というか大抵のホテル予約サイトというものは)APIを介して、そういった業者から世界中のホテルの詳細データやら、空部屋状況、料金などを取得し、また、こちらからは予約リクエストを送りつける。

私の開発しているサイトは既に二つのB2B旅行業者と接続済みだ。今回が三つめとなる。

今度の業者はイタリアに本拠を置いていて主にヨーロッパのホテルの在庫を多く抱えている。だが既存の二つの業者も当然ヨーロッパの在庫も持っているので、在庫の重複が発生することが予想される。つまり同一のホテルの部屋をAという旅行業者経由でも予約できるしBという業者からでも予約できるという状況。しかも料金は同じかもしれないし、そうでないかもしれない。それをプログラム的にどう処理するか、という問題がある。今回は、既存の二つ同士で重複が発生した場合と同じように処理することになるだろう。二つが三つになることでロジックが少し複雑になるという側面はある。

もっと大きな問題は、業者によってデータ項目の粒度がまちまちなことだ。些細な項目になるほど、業者によって情報の提供の仕方はバラつくことになる。例えばドライヤー。ある業者はドライヤーについて何の情報も提供しない。別の業者はドライヤーあり・なしのフラグだけを提供する。また別の業者はドライヤーが部屋に備え付けの場合とフロントで借りられることを区別した形でデータ提供してくる。

それをウェブサイト上ではどう表現するか。

データ量が最も少ない形式に合わせる、すなわち、この場合、ホテルの詳細案内ページにはドライヤーについて何も記述を載せない、とするのが一番、ラクではある。三つの業者の提供する情報の最小公倍数だけをサイトに載せる形。それとは逆に、APIで取得できる情報はできるだけ活用したい、全部をウェブサイトに載せよう、とするとホテルの紹介ページに掲載される情報の粒度がバラバラになる。つまり統一感がなくなる。サイトの利用者は、当然、ホテル同士を比較したいので、Aというホテルに「ドライヤーあり」と書かれていれば、じゃあBはどうなんだろう、あれ、何も載ってないじゃないか、どうなってるの? という話になってしまう。最も詳細なデータを提供する業者が世界のあらゆるホテルの情報を提供してくれるのであれば良いのだが、実際には業者ごとにホテルのカバーレッジは異なるのだ。

どうしたものか。

もちろんそれを決定するのは私の仕事ではないが、どういう選択肢があるのかを私の仕事の依頼主に提示しないとならない。そうしないと依頼主は物事を判断できないし、でもそうなると実際には私の選択肢の提示の仕方次第で物事はほとんど決まってしまう。

そういった細かい問題が随所に出てくる。それに対し、いちいち依頼主に説明するための資料を作成することになる。ひとつひとつの問題について、できるだけ中立で公正な立場で説明するものになるよう、私は心を砕く。こういうときに自分の主張を押し出すというのも仕事を進める上でのひとつのスタイルではあるのだろうが、私はそうはしない。できるだけ仕事における自分の責任範囲は最小にしておきたい。私の責任は、ウェブサイトが一貫した正確な挙動をするようにすること、求められる機能を忠実に提供すること、サイトに同時にアクセスして来る大量のユーザをさばく上でのサーバマシンの消費リソースと実行速度のバランスを最適なものにすること。提供する機能の内容を決めるのは私ではない。サイトのビジュアル面も私の担当ではない。

……さっきから私の手は止まったままだ。いつのまにか、どうにもならない過去の記憶が脳裏に呼び起こされそうになるのを必死で押さえ付けていることに気がつく。

ああ、やはりBGM抜きで仕事するのは辛いものがある。

BGMがないと、逆に、頭の中を音楽がぐるぐるしてしまう。私の脳みその一部は音楽のための回路になっているのだろう。だから常に脳内では音楽は鳴りっぱなし。ただ鳴っているだけならいいが、お気に入りの曲が頭の中で鳴っていれば、どうしても最後のフレーズまで鳴らし終えないと気が済まなくなったり、とか、どうしても思い出せない歌詞の一節が気になって仕方なくなったり、とか。そのうえ脳みその音楽回路は仕事で使う回路と混線もしている。

どういうことかと言うと、プロフェッショナルのコンピュータ・プログラマであればコーディングする上で当然のようにデザインパターンなるものを利用するであろうが、不思議なことに私の頭の中では特定のパターンを想起した際に特定の音楽が鳴り始める。例えば、ファクトリ・クラスを実装しようとするときには頭の中でスティーブ・ライヒの『ディフォレント・トレインズ』が流れる、という具合に。それなんかは、まあ良い方で、シングルトンが出て来た日には脳内で「グーチョキパーで、グーチョキパーで、何作ろう、何作ろう……」と延々と繰り返されたりする。

BGMはそういうことを防ぐためでもあるのだ。耳から音楽が聴こえていれば、とりあえずは脳内で勝手に音楽が再生されることを抑制できる。仕事に集中できるというものだ。そう、BGMさえ流れていれば問題なかったのに……。

……ああ、それから、サビしか知らない曲が延々と頭の中でループする、ってのもお約束だ。今の私がまさにそう。何がトリガーになったのかわからないけど、今、脳内リピートしているこの曲はエヴァネッセンスというバンドのスマッシュヒット曲だということだけは知っている。さっき私が思い起こしていたことか、あるいは、今、コーディングしようとしている何かなのかわからないが、この曲と結びついているのだ、私の頭の中で。そして、繰り返すサビのフレーズによって、私は抗いようもなく過去に引き戻される。

あの2004年の冬に……。

 

***

 

冬の冷たい雨が降る朝。私は、東京の西部に位置する、ある私鉄のターミナル駅を降りたところ。改札を出て、通勤の人の流れから少し離れたところで足を止めた。会社の先輩である小松崎さんと此処で待ち合わることになっている。

小松崎さんとは数日前に顔合わせの社内ミーティングでただ一度、会っただけだ。どんな顔の人だったっけ。果たしてちゃんと落ち合えるだろうか。

不安だ。

それは小松崎さんと落ち合えるかどうか、ということについてだけでなく、私が今回、アサインされることになったプロジェクトのことも。

私が超氷河期と言われた就職戦線を奇跡的に乗り越え、世間的には一流と言われるコンサルティング・ファームに入社して、もうじき丸四年という頃だった。仕事はこなせるようになってはいたが、まだ、言われたことをやるだけの下っ端で、そのことに鬱憤を感じてもいた。同期では既にプロジェクトを任されたりしている人物もいたりする――頭はいいのだろうけど口先だけのヤツ。彼は研修以外で一行でもプログラムのコードを書いたことがあるのだろうか。

コンサルファームにもいろんなタイプがあるけれども、今時の大手コンサルのビジネスはいわゆるシステムインテグレータのそれと限りなく近い。だから若手に回ってくる仕事はIT系のエンジニアリング周りの仕事ばかりと言っても過言ではない。

まあ、ITのエンジニアリングと言っても内容は多岐にわたるわけで、大まかに言えば、ネットワークとかハードウェアのインフラ系、業務分析とか要件定義なんかの業務系、OSやデータベースにミドルウェアなどのソフトウェアに強いテック系、オブジェクト指向とか開発方法論に詳しいアーキテクト系、というところか。

他のファームでも同じようなものだと思うが、やはりメインストリームは業務系で、その他は傍流という風情がウチにはある。でも若いうちはなかなかそこはやらせてもらえない。最初はインフラかテックあたりで仕事をこなすことを覚えつつ、業務的なところは先輩を見て勝手に学べ、という風潮。

私はテック系から入って、アーキテクト系に少し興味を惹かれていた。業務系にあまり興味が持てなかったのだ。なんていうか、業務って、業界が違ってしまえば役に立たない知識だし、もちろん業界に依存しない業務もあるけど、会計とかは結局、日本の税法に依存した話だし、法律が変わるたびにあたふたと対応をしなくてはならないわけで(会社にとってはそれが貴重なビジネスオポチュニティをもたらしてくれるわけだけど)、つまり、便宜的なものに過ぎないように思えてしまう。それに対してオブジェクト指向なんかのソフトウェア工学には普遍の数理的な美しさがあると感じられた。

だが、そっち方面を追求することは、すなわちファーム内では傍流で終わる道を目指すことになる。まだそこまでは踏み切れなかった。そんな私の思いとは裏腹に、最近、社内的には「篠原はテック色の強い若手」という押し出しがされている気がする。今回のプロジェクトも、ウェブの最新の開発技術に明るい人材が必要である局面に適任だろうということで私が投入されることになったのだ。ウェブアプリケーションの開発など、ひとつ前のプロジェクトで初めて経験したのだけれども。そこが不安の最大の理由というわけ。

「篠原さん」

ぶっきらぼうな口調でいきなり声をかけられた。いつの間にか隣に立っているコート姿の男性を慌てて見上げる。小松崎さんだ。すぐそばに来られるまで気がつかないなんて。しょっぱなからマイナスポイント……。

「おはようございます」

私は体ごと小松崎さんの方を向いて頭を下げた。

「行こうか」

小松崎さんは肘から先だけを持ち上げて指差しながら言う。その手は周囲の通勤の人たちのほとんどが進んでいるのと同じ方向を差していた。

私は小松崎さんの斜め後ろを歩き始めた。どうやら、まわりの通勤の人たちは皆、同じ建物に向かっているらしい。駅にほど近い場所に建つビル。高層ビルというほどではないが、この周囲では一際目立つ建物だ。そこが、私が今回、アサインされたプロジェクトが進行中の顧客クライアントのビルというわけなのだろう。某生命保険会社の本社ビルのはずだ。

そのビルはどんどんと通勤の人たちを吸い込んでいく。そして小松崎さんと私もその流れに乗ってエントランスをくぐった。

小松崎さんに指示されてエントランス脇の警備室の窓口で入館名簿に名前を書く。小松崎さんは自分のIDカードを警備員さんに見せ、ジェスチャーで私が自分の連れだと示した。警備員さんは頷いて私にゲストバッジを渡してくれたので、それをコートの下のスーツの胸ポケットにつけた。これじゃバッジが見えないな、コートを脱ぐべきなのだろうか。でも小松崎さんもまだ脱いでないし、まあ、いいか。

出勤してきた人たちで建物内は渋滞していた。どうやらエレベータ待ちの人たちの行列がエントランスにまで続いているようだ。

「いつもこうなんですか?」

私は隣の小松崎さんに訊いてみた。

「そう。だから時間ギリギリに来ると遅刻になるから要注意ね。ま、俺たちにはタイムカードはないけどな。朝イチでミーティングなんて時は早めに来ないとダメだね」

「わかりました」

小松崎さんの物言いがどうもフレンダリーさに欠けるように感じられるので、私もカッチリした返事を返すしかない。

徐々に列は進んで、私たちはエレベータホールのそばまで来た。エレベータは四機ある。どうやらひとつひとつのエレベータはあまり大きくなく、定員が少ないようだ。

「せめて奇数階行き・偶数階行きを別々にすれば少しは効率よくなるのにな。全機がほぼ各駅停車だからすんごい時間がかかる」

小松崎さんが私に少し顔を近づけ小声で言った。

「はあ、なるほど。そうですよね、たしかに」

私が感心した口調で返すと、小松崎さんは既に前に向き直っていたが、まんざらでもない顔で口の端だけで笑った。

エレベータに詰め込まれていく人たちを眺めていて、ふと、私がこれから参加するプロジェクトの内容を思い出してしまった。事前のミーティングで小松崎さんから受けた説明によると、全業務フロー再構築プロジェクトと呼ばれているそれは、この会社の本社業務のこれまでシステム化されてこなかった部分を最新のテクノロジーを用いたIT技術でカバーすることによりホワイトカラーの五割削減を目指すものだという。

今、私の目の前でエレベータを待っている人たち。まさにこの人たちが削減の対象なのだ。

削減する、とはどういうことなのか。つまるところ、クビ? 先輩たちのプレゼンなんかでよく、システム化で業務が効率よくなるので人間はよりクリエイティビティの求められる仕事に集中することができるようになります、なんていうけど、あれは綺麗事だよなと思う。業務が半分の人間で回るようになれば、いらなくなった残りの半分は営業でもやらされるのだろう。保険の営業。中にはそれで営業の才能に目覚める人もいるかもしれないが、そんなのはホントに例外中の例外で、ほとんどの人は最終的に転職することになるだろうし、路頭に迷う人も確実に一定数は発生する。

もし、私たちの仕事の内容が、今、周りにいるこの人たちに知られたら、この人たちは間違いなく私に憎悪の視線を向けてくるだろう。今から何年か先、ここにいるうちの何割かの人は実際に職を失い、その恨みを私にぶつけてくる。ものすごい形相で私を罵りながら掴みかかってくるかもしれない。

私はそのシーンを想像してゾッとしてしまった。

 

プロジェクトチームの席は八階にあった。広いフロアーの一角にチームメンバーのための事務机が並べられていた。よくあるような独立したプロジェクトルームではなくオープンスペースである。その日からそこの一番通路寄りの席が私の仕事場となった。

業務プロセスをビジュアライズすることがプロジェクトの第一ゴールとされていた。最終的には、コンピュータの専門家でなくともツールを用いて簡単に業務プロセスをシステム上に定義したり変更したりできることを目指す、という。簡単に言えば、人間系の部分も含めてトータルに業務プロセスをデザインでき、自在に外部システムとも連携可能なワークフロー・システムを開発しようとしているのだ。それはなかなかに先進的なITシステムと思われた。

ポイントは、ITの専門家でなくともシステム的なプロセスだとかインタフェースだとかを定義することのできるツールを用意することだった。この会社のすべての細々とした業務にまで我々コンサルファームが入ってシステム化して将来にわたってのメンテナンスを提供していくことなどできない。このクライアントの社員が自ら業務をシステム化していくことが求められる。我々はそのための環境だけを用意する、というわけ。

最終のゴールは五年後に設定されていた。この長大なプロジェクトが最初にパイロットとして取り上げるのは、証券再発行と呼ばれる、社内的には小さな、かつ、これまで(そのイレギュラーさゆえに)ほとんどシステム化の恩恵を被ることのなかった業務である。チームはすでにこの業務のシステム化に向けて動いている。この業務のシステム化によって、IT専門家でない一般社員がシステムを自らデザインできるようにするための方法を確立していくのだ。

プロジェクトチームは内部的に二つのタスクチームに別れており、片や業務分析を行い、もう片方はプロトタイプ開発の環境構築を進めていた。私は環境構築チームの一員となった。既にほとんどのソフトウェアの選定は済んでおり、根幹となるプロセス管理をつかさどるツールについてだけ最終選定が終わっていなかった。二つの製品にまで絞り込まれてはいたのだが、それはいわゆるカタログスペックでの比較に基づいてでの決定であり、これから実際に製品を使用してみながら細かい使い勝手などをみていくという段階でその作業を実施するのに適した人材がプロジェクト内にいなかった。それが私がここに呼ばれた理由のようだった。

IT業界ではアプリケーション間連携やらサービス指向アーキテクチャーなどといったキーワードがブームを形成していて、二つの製品のどちらもその流れを汲むものとなっていた。私はそれらのキーワードを耳にはしていたが、それの意味するところまではきちんと押さえてはいなかった。調べてみると、なるほど、このプロジェクトそのものがある意味そのブームに乗ったものであることがわかった。

あくまで私が理解した限りだが、これまでのやり方では、例えば全社の売上レポートを作成する担当者はまずメインフレーム(大型汎用機)にログインして必要な売上データをダウンロードし、それをパソコンの表計算ソフトに取り込んでデータを集計やら加工やらをして、その結果をファイルサーバにあるワープロの文書テンプレートに貼り付けて文章を書き加えたり見栄えを良くしたりなどして出来上がったファイルをグループウェアに添付して上司の承認を得る、みたいなことをするのである。その作業の流れ、すなわちプロセス、は、人間の頭の中にあるわけだ。あるいは派遣社員に代々伝わる業務ノートに記録されてたりするかもしれない。そして、そのプロセスの各ステップごとでは異なるコンピュータないし異なるソフトウェアを利用する必要がある。もちろんそのそれぞれに異なる知識が求められることは言うまでもない。

ITに携わることのない人はコンピュータなぞ皆同じようなものと考えているだろうが、メインフレームとパソコンとでは囲碁と将棋くらいの違いがある(私はどちらもよくは知らないのだが)。囲碁を知らぬ一般人に何かをやらそうとすると「とにかく右から五番目、左から七番目の位置に石を置け」みたいな話になる。大抵のユーザーは自分が何をやっているのかを理解することなく教わった通りのコマンドをそれこそ呪文のごとく繰り出すだけの存在となる。それで物事が正常に進んでいるうちはいいが、遅かれ早かれイレギュラーな出来事が発生する。ユーザはなにもわからないままに呪文を発し続ける。そのことが状況を悪化させる。取り返しのつかない事態に至ることも起こりうる。だが今の仕組みでは他にどうしようもなかったりする。そこに現れた強力な助っ人がアプリケーション間連携ソフトウェアだ。これは、異なるコンピュータ間および異なるソフトウェア間の橋渡しをしてくれるものであり、それのおかげでユーザはひとつの業務をこなすためだけにいちいち色々なコンピュータやソフトウェアの知識を持つ必要がなくなる。

その裏で、これまで人間が画面を介して利用することだけを前提として作られてきたソフトウェアは、そうではなく機械からも利用されることを(この場合はアプリケーション間連携ソフトウェアから利用されることを)前提とすべきであると変わり、そこでサービス志向アーキテクチャという考え方がでてくる。ソフトウェアの個々の機能をサービスという形で切り出し、規約に沿ったインターフェースにより外部(つまりは別のコンピュータ)から利用可能にする、というものだ。そうすると、いろんなコンピュータに点在する様々なサービスを組み合わせて、それをひとつの仮想的なソフトウェアとして利用することができるわけである。

ここでのサービスの組み合わせ方が、つまりは、プロセスとなるのである。派遣社員の業務ノートに書かれている手順をそのままコンピュータ上にプロセスとして定義してやれば、ボタン一つで全社の売上レポートが、はい出来上がり、となるわけだ――実際はそう上手くはいくまい、という気がしなくもないが。

とはいえ、流行りの新しい考え方に基づいた製品に触ることのできる機会が与えられたことは単純に嬉しかった。

とりあえず私は、プロジェクトでこれまでに作成済みの資料やらソフトウェアベンダーが公開している資料やらを読み漁った。作成済み資料は既に結構な量に達していて、それを読むだけでも数日を要した。

選定最終候補になっている二つのソフトウェアについては、評価用のメディアとライセンスの入手の手配は既に済んでいたが、セットアップはまだだった。それは当然、私の仕事と目されていた。

私はまず、候補のひとつであるルカヘッド社の製品をサーバにインストールしようとしたが、セットアッププログラムは途中でエラーを表示して、製品はインストールされなかった。

――なるほど。と、私は思った。

なにが「なるほど」なのかというと、つまりは私がここに呼ばれた理由が腑に落ちてきた、ということである。おそらく既にこのプロジェクトの誰かが製品のセットアップを試みたのに違いない。そして、これは手に負えない、と判断したのであろう。

私は口の中にざらつくものを感じた。なんだろう、自分はババをひかされるためにゲームに招かれたのかもしれない、という疑念。とたんにプロジェクトのメンバーらの悪意にとり囲まれているかのような錯覚に襲われる――いやいや、これはむしろ私に与えられたチャンスなのだ、力の見せ所なのだ、と自分に言い聞かす。きっかけがどうあれ、私はプロジェクトの一員となったのだし、自分が役に立つ人間であることを皆に示さないとならないのだ。これしきの逆境でモチベーションを下げるわけにはいかない。

私は試しにOSのロケールを米国に変更してみた。いつだったか、この製品と同じく舶来もののソフトが正常に動作しない時に、それでうまく動作させることができたことがある。製品の日本語対応がきちんとしていないせいでエラーになることがよくあるからだ。

案の定、インストールは正常に完了した。

チョロいチョロいと思ったのも束の間、次なる困難に突き当たる。

引き続いて私はマニュアルにしたがってサーバプログラムを起動したのだが、それはすぐに終了してしまうのだ、本来は常駐するはずなのに。ロケールは米国のままなので、言語の問題ではないのだろう。この製品は出荷前にきちんとテストされているのだろうか、まったく……、などと思いつつ、私は自分の作業内容やサーバの設定などを一通り再確認する。エラーログを探し、出力結果をチェックする。特にエラーは出ていない。メモリー不足なのか(というのはJavaで書かれたプログラムがログも吐かずに落ちるのは大抵、メモリー不足が原因だから)。いや、そんなはずはない、少なくとも物理的にはメモリーは潤沢に積まれている。設定ファイルの内容をチェック。起動パラメータで明示的にメモリーサイズを指定した方がいいのかもしれない……。

私はウェブで情報を検索しつつ試行錯誤してみたものの、結局、サーバプロセスを正常に起動させることはできなかった。前途多難だな、と思った。

まだ正規のユーザではないので、ベンダーのサポート窓口は使えない。担当営業経由で問い合わせるしかないだろう。私は小松崎さんと相談の上、先方の営業担当者の連絡先を教えてもらい、問い合わせのメールを投げた。

どうせすぐには返信は得られないだろうから、もう一方のギニソフト社の製品のセットアップに取り掛かる。私はOSのロケールを日本に戻した。

まあ、そんな感じにスタートした製品の評価作業は、遅々として進まなかった。ギニソフト社のプロセス定義画面はキャンバス上にアイコンを並べて矢印で連結する、という直感的なユーザインタフェースであったが、私は真っ白なキャンバスを前に途方にくれた。とりあえずベンダーの提供するチュートリアルはやってみたし、その内容は理解できた。しかし、それを実システムにどう応用すれば良いのか、まったくわからなかった。

ルカヘッド社の方は、結局、翌週になってテクニカルコンサルタントと称する人がやってきて、新しくビルドされた製品をインストールしていった。結局、起動しなかったのは製品のバグのせいだったのだ。早くもルカヘッド社製品の方には品質にクエスチョンマークがついた格好だな。でも、こうしてすぐに修正された製品を持ってくるあたり、サポート姿勢としては悪くないかも。

私のプロジェクト参画から半月ほどが過ぎて、小松崎さんが仕事の進捗状況を確認しにきた。日次にレポートは提出しているので、あらためて状況を確認したい、ということだろう。

「えと、正直、まだ先は見えてこない感じですね。ようやっと環境が整った、という程度で」

私のそのセリフに、小松崎さんは無表情のまま固まった。少しの間の後、次のように彼は言った。

「んー、ま、いろいろとあったことは把握してるけどさ、スケジュールというものがあるんだよね。今月中にはどっちの製品を使うか決めないとならない」

――今月中か、あと半月でなんとかなるかな、と内心、考えた私をよそに小松崎さんは続けた。

「そこから逆算して、来週頭までには結果レポートをまとめてほしい」

「い⁉︎」

「いや、だって一発でクライアントを納得させるレポートが書けるとは思ってないだろ?俺たちがレビューして、それから足りないところを再度調査して、またレビューして、って二、三回はやらないと」

「それはそうですが……。しかしそんなスケジュールの話は聞いてませんでしたけど……」

そう私が言うと小松崎さんはあからさまに不機嫌そうな顔つきになった。

「あのね、俺たちの仕事には常にスケジュールってもんがあるんだよ。聞いてない、じゃなく自分で意識してちゃんと確認しろよ。製品選定にいくらでも時間をかけられると思っていたわけじゃないだろ?」

「は、はい。もちろんです」

私がそう言うと、小松崎さんは無言で自分の席に戻っていった。

なんだよ、やりづらいなあ――私はやり場のないイライラを感じた。そもそもこの製品評価の仕事だって明確に私の仕事とアサインされた記憶はないのだ。ミーティングとかの場の話で、なんとなく自分にそれをすることを求められているような感じだったので、とりあえず指示待ちでいるのも嫌だから率先して手をつけてみた、って流れだった。最初からこのプロジェクトにおける私の役割と権限を明確にしてくれれば、やるべきことはキチンとやるのに。もちろんスケジュールだって事前にきっちり決めてとりかかるのに。役割も権限も見えないから探りながらやり始めるしかなかったのに、手をつけてみたらそれがいきなり「当然に私がやらなければならないこと」になって義務として押し付けられた感じ、とでも言えばいいか、このイライラの出所は。

いや、いかん、なんとかモチベーションを維持せねば。とにかくやるしかない。一週間でなんとか形だけでもそれらしくレポートを作成しよう。どうせレビューでけちょんけちょんにされるのだから、まずは体裁だけでよかろう――。

などと考えつつ、私は調査項目のリストアップを始めた。プロジェクトの資料を再度読み直しながら必須要件を抜き出していく。

とにかく手を動かし続けた――どうせちゃんとしたレポートを書くことはできまい、まずはわかる範囲のことだけどんどんと書いていこう。わからないところは後回し、そのうち足りないところがどこかも見えてくるに違いない――。

火曜、水曜……、連日の深夜残業になる。こっそり習っている木曜日の英会話も今週はパス。

ルカヘッド社の営業さん経由で高林さんというエンジニアを紹介してもらえたので、私は何度も電話して質問攻めにしてしまった。が、彼は常に丁寧にわかりやすく質問に答えてくれた。一方、ギニソフト社の方はメールでの質問しか受け付けてくれなかったため、私はスプレッドシートで質問票を作成し、その長たらしいリストを先方に送りつけたが、回答が得られるまでには時間がかかりすぎた(そのうえ回答内容には不備も少なからずあった)。まあ、それは客観的に見れば、私が急ぎすぎているだけなのだろうけど。こちらの事情は伝えたが、それに配慮するかしないかは向こうが決めることだ。

結局、テストが追いつかず土日も仕事をせざるを得ない状況となった。幸いクライアントの社員さんも土日に出社している人がおり、オフィスに入れないということはなかった。土曜日、人が少ないせいか、フロアは冷え冷えとしていた。私があんまり寒そうにしていることに気がつかれ、クライアントの社員さんの一人が「待ってな、今、暖房を強くしてやっから」と言って席を立ち、しばらくして部屋は暖かくなった。私はその人に感謝を伝えたものの、今度は暖かすぎて何度か私はウトウトとしてしまった。日曜日はその社員さんはおらず、私はコートを着たまま仕事をした。

なんとか月曜には分量だけはそこそこのレポートが出来上がった。自分の感覚としては、網羅的な内容になっているとはとても思えなかった。あくまで私に見えた範囲内のことをテストしたり調査したりした結果を束ねただけのもの、でしかない、はず。

夕方にレビュー会が設定された。出席者は小松崎さんをはじめプロジェクトのリーダー的立場の三名の先輩で、私は作成したレポートを事前に彼らにメールで送りつけておいた。

先輩らの反応は意外にあっさりしたものだった。ルカヘッドの方がいいみたいね、くらいの。レビューではいくつかの指摘事項はあったが、どれも本質的なものではなかった。私は拍子抜けしたが、おそらく先輩らは事前に送付しておいた資料を読み込む時間がなかったのだろう、きっと後から色々と重大な指摘事項が挙がってくるに違いない、と考えた。

それから数日、私はレポートのブラッシュアップをしつつ、前の週の超過勤務による疲労の回復に努めた。

その翌週の月曜に二回目のレビューが実施されたが、やはり特に大きな修正は求められなかった。さらにその翌日にはクライアント側の主要メンバーとの会議が開かれ、私はそこでレポートの説明をした。質問がいくつか出て、私は回答した。会議は滞りなく終了した。

とりあえず最初のミッションをコンプリートした、というところで、私は安堵の吐息を漏らしたのだった。完璧な仕事ではなかったが、やれるだけのことはやったし、何より、誰からも文句は出なかった。及第点を得た、と感じられた。

翌々日には、ルカヘッド社の製品の採用が決定した、というクライアントの意向が小松崎さんの口を経由して私に伝わってきた。

 

一ヶ月後、私は自らが敷いた地雷原を絶望的に行進しているような状態と化していた。

どこでボタンを掛け違えたのかまったくもってわからないけど、とにかくルカヘッド製品は私たちが必要としていたものとは似て非なるコンセプトのものだったのだ。しかしクライアントは既に二千万もの金を払って製品ライセンスを購入してしまっている。今更これを使うのを止めるというわけにはいかない。

ルカヘッドとギニソフトの製品の機能比較のために、私が作成したマルバツ表。そこにつけたマル印のひとつひとつが私の心の重荷と化した。その多くは、マルといえばマル、だが、こちらが本来期待したような意味合いでのマルではなかったのだ。そこにマルをつけてしまった責任は私にある。プロジェクトのメンバーは誰も、そのことで私を責めるようなことはなかった。小松崎さんでさえ無言を貫いたが、むしろ私としては一発、思い切り叱られてしまった方がスッキリしたかもしれない。

唯一の救いは、仮にギニソフトのほうを選択していたとしても状況は大して変わらなかったろう、と思えることだけだった。

自分の作成したレポートの内容を思い返しつつ、私は暗澹たる気持ちになった。できることなら今すぐここを抜け出して、何もかも忘れて南の島あたりでのんびりしたい。だが、そんなことは言ってられない。とにかくなんとかせねば。

ひとつひとつの項目について、ワークアラウンドを考案する。これにはルカヘッド社の高林さんが大いに貢献してくれた。彼はなかなかのアイデアマンのようで、私が電話でこれこれこういうことをルカヘッド製品で実現したいんだけど、と相談すると、じゃあこういう風にしたらいいんじゃないですか、と案を出してくれる。私はそれを実際にサンプルアプリケーションを作ってみながら検証する。なんとかなりそう、となる。これを繰り返しているうちにある種のコツが掴めたようで、高林さんに訊かなくとも自分だけでワークアラウンドを考案できるようになってきた。ほぼ全ての項目についてワークアラウンド方法を捻出するのにさほど期間はかからなかった。

問題は、このままだと、これから実際の業務アプリケーションを組んでいくにあたり開発者全員がワークアラウンド手法に精通していなければならないことである。それではツールを使う意味がまったくない。最初はウチのメンバーが開発するからいいようなものの、最終的にはエンジニアでない人物が業務プロセスを組める必要があるのだ。

「ワークアラウンドを全てライブラリに実装してフレームワーク化するしかないな」

その問題について相談すると、小松崎さんはこともなげにそう言った。

……確かに。ルカヘッド製品の外部アプリケーション連携の機能を駆使して、自分らが作ったライブラリのメソッドを常に呼ぶようにする。ルカヘッド上で定義したプロセスの全てのイベントにフックをかけて、こちらのライブラリの機能が動くようにすればいい。ルカヘッド製品のバックボーンとフロントエンドだけを利用して、中身だけを全て自分らのライブラリに置き換えてしまうようなイメージだ。実際にはそう綺麗にできるものでもないが、概略としてはそういうこと。

私は、作成済みのサンプルアプリケーションからワークアラウンド機能を抽象化しつつ抜き出し、ライブラリとして実装した。この作業はなかなか大変だった。一口に抽象化といっても、それにあたっては色々と想定しないとならないことが多いので、簡単な作業ではない。だが楽しくもあった。難易度の高いパズルを片端から解いていくような感覚。しかもそこには模範解答がない。自分が納得するかどうか。帰宅途中の電車の中でも、家で風呂に浸かっているときにも、私は頭の中でこのパズルに取り組んでいた。

突貫作業を重ね、なんとか、まる三ヶ月でライブラリの最初のバージョンを作り終えるところまで漕ぎ着けた。まだエラーハンドリングなんかはきちんと組み込まれていないが「とりあえずは動く」程度のアルファ版。プロジェクトのスケジュールでは、まもなくパイロット業務の実装が開始されるので、このタイミングまでに動くものが用意されている必要があった。

パイロット業務の実装フェーズが始まって最初のうちは順調だった。

だがプロセスの実装が進んでだんだんと内容が複雑なものになってくると想定外のことが起きるようになった。その度に私は、起きている現象を調査し、ライブラリを修正した。ライブラリの中身は複雑になり、もはや私以外にはメンテナンスが不可能な状態と化した。

実装フェーズが終わり、テストフェーズに入った。私は針のむしろに座らせられている気分だ。

まもなくテスト担当者から悲報が挙がった。曰く、テストするたびに異なった結果になる、安定した結果が得られない、原因は不明――。

私は頭を抱えた。結果が都度、異なるというのであれば、疑わしいのはマルチスレッド対応がきちんとできていない、とかだろう。それを念頭にライブラリのコードをすみずみまでチェックする。しかし問題は見つからない。ひょっとするとルカヘッドの製品側に潜在していたバグをなんらかの形で踏んでいるのかもしれない。そうだとすると私の手には負えない。バグの所在がわかれば回避のしようもあるかもしれないが……。

プロジェクトのスケジュールが遅延し始めた。小松崎さんに状況を問われた私はこう答えた。

「……これは製品のバグを踏んでいるのかも。もともと本来的な使い方をしていないので製品のせいなのかウチのせいなのか判別が付き難いです」

「ルカヘッドのサポートに問い合わせてみたの?」

「いえ。あの、ルカヘッドのサポート窓口はですね、問い合わせの際は不具合を再現可能な最小限のセットと再現手順を提出しないとならなくて……。今回の場合、不具合の出る部分だけを切り出す、ってところまで問題が切り分けられてないので、作ったものを丸ごと提出することになってしまいますし、仮に向こうがそれで受け付けてくれたとしても、確実に問題を再現可能な手順というのもわかってないです」

「そんなこと言ってられないじゃん。まずは訊いてみろよ。やれることはやっておくんだよ」

「……わかりました」

私はルカヘッド社のサポート窓口のホームページの問い合わせフォームを開いた。その画面を前にハァとため息をつく。問い合わせ内容を記述するためのボックスにカーソルをあてながら、なんと書いたら良いものか、と考えを巡らす。私のこの数ヶ月の仕事の経緯をこの小さなボックスに書ききれるわけがないのだけれど、そこまでやらないと状況を理解してもらえないとも思う。

気を取り直し、起きていることの簡潔な説明と再現のための手順をフォームに書き込んだ。それから私の作ったライブラリとエクスポートしたプロセス定義ファイルをアップロードする。障害の重要度の指定で「最大」を選択してフォームを送信した。果たしてどんな反応が返ってくるか……。

翌日の朝、ルカヘッド社のサポートからはなんの連絡も届いていないので、私は再びホームページを開いた。そこから私の問い合わせのステータスを確認することができる。見ると「USの開発元に問題はエスカレートされた」と一行だけの説明が書かれていた。日本法人では手に負えないと判断されたということか。

私は高林さんに電話してみた。

よくよく聞いてみると、高林さんはルカヘッド社で顧客向けの研修講師を担当しているエンジニアなのだという。だからあんなに説明がうまかったのか。だが、私が昨日、サポートに投げた問い合わせについて、担当でないにもかかわらず彼は既に把握していた。「小さい会社ですからね」と高林さんは電話口で軽く笑いながら言った。

「篠原さんの問い合わせはすぐにUSにエスカレーションされました。なかなかああいった問題まで日本サイドで追いかけるだけのリソースがないものでして」

「そうですか……。その、それで、回答をいただけるのって、時間がかかったりするんでしょうか。あの、申し上げ辛いですけど、プロジェクトのスケジュールが遅れてまして――、えと、その問題のせいで。できるだけ早く回答が欲しいんです」

「ええ、わかります。USには私からも、出来る限り早く回答するように伝えます。それでも、申し訳ないですが、いつまでに回答できるかを保証することは残念ながらできないです。でも、とりあえずステータスを毎日更新するようにさせます。すいませんが私にできることはそれぐらいかと……」

「ありがとうございます。助かります。すいません、高林さんのご担当じゃないのにお手数をおかけしてしまって」

「いえ、これくらい全然問題無いです。こちらこそ、すいません。ウチの製品でご迷惑をおかけしてしまって」

「あ、いや、まだ製品のせいと決まったわけでは……。私の作り方の問題かもしれませんし……」

そんなやり取りの後、私は受話器を置いた。正直、あまり期待はできないな、と思いつつ。小さいとはいってもグローバルに展開しているソフトウェア企業の製品開発元が日本のひとつのプロジェクトのために優先的に物事にあたってくれるとは考え難かった。ましてこちらは明らかにフツーじゃない使い方をしているのだし、仮に最優先で調査をしてくれたとしても簡単に回答が出てくるとも思えない。

案の定、数日経っても問い合わせのステータスは「調査中」のままだった。私自身の調査も手詰まりで、ルカヘッドからの回答にわずかな望みをかける状態となってしまっていた。私は再び高林さんに電話をしてみた。彼は恐縮しつつ「USサイドにメールで状況を問い合わせてみます。でも時差があるので回答は明日になります」と言ってくれた。

受話器を置いて、ふぅ、と息をついた私の肩を誰かが叩いた。慌てて振り向くと、それは水谷さんだった。プロジェクトのクライアント側のリーダー。「ちょっといい?」と言われて私は打ち合わせブースに連れて行かれる。開口一番、こう訊かれた。

「ルカヘッドのサポートに問い合わせてくれてるって聞いたんだけど、どう、状況は。なんか回答、返ってきた?」

「あ、いえ……。アメリカの開発元にまで問い合わせがエスカレーションされた、ということだけで、まだ何も……」

「あ、そう。どうなの? 篠原さんからみて。向こうから回答は出てきそうなのかな」

「うーん、正直あまり期待はできないかと……」

「そうか。いや、小松崎さんから状況は聞いているんだけど、今回は御社も初めて利用する製品だということで、あまり使い方に精通していないと。ちょっと使い方にマズい点があったかもしれないという話だったんだけど篠原さんも同じ認識?」

「あ、はい。そういう面はあると思います」

「このままじゃ埒が明かないから、もう、ルカヘッドの人に来てもらって、ちゃんとした使い方を教わった方がいいんじゃないかな。その方が早いでしょ」

「え、来てもらえるんですか?」

「そりゃ、おたくの製品、使い物にならないから返品しますっていやぁ飛んでくるさ。うちから返品されたなんて噂になりゃ、もう商売にならないもの」

「なるほど。いや、来てもらえるものなら、ぜひ来て欲しいです」

「オーケー、じゃ、すぐに向こうの営業に話、つけるわ」

水谷さんはそう言うと、さっと腰を上げた。私は慌てて頭を下げた。ああ、これで救われるかも。久々に気分が晴れる気がした。

 

ルカヘッドのテクニカルコンサルタントの斎藤です、とその男性は名乗った。年齢不詳な感じだったが、意外と歳をとってそう。

打ち合わせブースで向かいに並んで座っている小松崎さんと私を交互に見つつ、斉藤氏は続ける。

「明後日に、あと二人、エンジニアがジョインします。ちょっと来日するのに時間がかかってしまってまして――。お急ぎであると伺っておりますんで、とりあえず今日は私だけがお話を聞きに来ました」

「来日、ですか」小松崎さんが反応した。

「ええ、イギリスから二名、今回のトラブルの対応のために急遽、来日することになりまして。なにせまだ日本にはエンジニアが少ないものですから」

すごいな、海外からエンジニアが来てトラブル対応するなんて。でも、外人がここに来て、いったいどんな感じで対応を進めていくのだろう。想像がつかない。私に英語で質問なんかされても答えられるはずないし。会社で強制的に受けさせられたTOEICは600点くらいだったけど、それはどちらかというと文法とか読解で点を稼いでいてそれなので、会話となるともっとひどいのだ。まあ、この斎藤さんが通訳はしてくれるのだろうけど……。

「実は、サポートの方に出していただいた再現用のモジュールを拝見しまして、昨日から一生懸命、見てるんですけど、あれ、なかなかに作り込んでますよね。図にするとこんな感じ」

斎藤さんはそう話しながら、手元に持っていたノートに挟まれていた紙を取り出して、私と小松崎さんの前に出した。

私はその図を覗き込んだ。少し驚いた。よく書けている。そのまま説明用の資料としてこちらに貰いたいくらい。どうやら斎藤さんは私の開発したライブラリの機能をほぼ正確に把握しているようだ。こちらからはモジュールを渡しただけで内容までは説明していないのに。頼もしくはあったが、怖い気もした。自分でもわかっていない私の犯している根本的な間違いを発見され指摘されることになるのではないか、という恐れ。

翌々日に斎藤さんとともに二人の白人男性がやって来た。ひとりは結構年配で痩せていて顔つきが険しく威圧感のある人物だ。エンジニアというよりかは大学教授のような雰囲気。もうひとりは普通のおじさんという風情で、あまり印象に残らない感じの人。こちらも別な意味でエンジニアっぽくないように思えたが、考えてみれば私はイギリスの典型的ITエンジニアがどんな感じなのかなど知りはしないのだ。私の持っているイメージはせいぜいアメリカの映画やテレビドラマに出てくる西海岸的IT企業のものだから、イギリスとは違っていても当然だろう。

プロジェクトチームの机が並んでいる一角が彼らのために空けられた。

斎藤さんは早速、二人に現状の説明を始めた。デスクに置かれたPCの前に斎藤さんが陣取り、その両隣にイギリス人エンジニアが座った。私はさらにその隣に座って何か聞かれたら答えるためにスタンバった。斎藤さんが画面を操作しながら英語で説明をする(英語がペラペラなのかと思っていたが意外にたどたどしかった)。しばらく二人は黙ってその説明を聞いていたが、しばらくすると痩せた方が険しい顔のまま芝居がかった口調で、

「Interesting. Very interesting」

と言った。

シャーロック・ホームズかよ……。私には内心、そのセリフの口ぶりが可笑しく感じられたが、考えてみると彼に真相を暴かれて糾弾される犯人は私なのだ、おそらく。そう思えば笑ってなんかいられない。

まな板の上の鯉、ってやつか、私は――。

彼らが引き続き英語で何やら話をしているのを私は上の空で聞いていた。

 

その晩、私の見た夢――。

海外ドラマでしか見たことのないような広い執務室に私は案内され、足を踏み入れたところ。企業の重役のための個室らしき部屋。正面に大きなデスクがある。その向こうにある高級感漂う椅子に座った男性は机の上のノートパソコンに目を落としている。その背後は一面ガラス張りの窓になっていて、眼下に街並みを一望することができる。この部屋が相当、高い場所に位置していることがわかる。そしてそこからの風景はここが日本ではないことを物語っていた。

デスクの男は私に気づくと顔を上げ、微笑みを浮かべて立ち上がった。背の高い白人男性。髭面で黒Tシャツのうえにダークスーツを着ている。握手の手を差し伸べながら、つかつかと私の方に歩いてくる。私はおずおずと手を出した。身長差のせいで、目の前に来た男を私は思い切り見上げる形になる。

「君がシノハラさんだね、あの素晴らしいライブラリを開発した」

男は口を開くと、そう言った。私が見返すと、彼は真顔であり、皮肉を言っているわけではなさそう。

「え、ええ、そうです」

私はそう返すのがやっとだ。

「見させてもらったよ。我が社の製品があのような画期的な形で利用されるとは考えもしなかった。まさにあれは革新だ。素晴らしい」

男の言葉にどう反応すればいいのかわからず、私はただ頷いた。

「ぜひともあのライブラリを我が製品の標準機能に組み入れたい。どうだろうか、あれを我々に売る気はないかね」

「え……」

私が再度、見上げると、男はまっすぐに私を見ていて、その目は真剣である。

「……あれは業務で作ったものなので、私にはあれを売る権限はありません。そういう話は会社としていただければ、と……」

「もちろんだ。実はもう専任の担当者がその話を進めている。だが開発者である君に敬意を表して君から直接許可をもらいたかったんだ」

「はあ……、会社がオーケーと言うのであれば、私は構いませんが……」

「ありがとう――さて、本題はむしろここからなんだが、単刀直入に言おう、君はウチで働かないか」

「え?」

「私は君にふさわしいポジションと報酬を用意している」

「そんな……、急に言われても……」

「即答の必要なはないが、チャンスはいつまでもあるわけではないということも同時に言わないとならない。これは君にとってまたとないものであることを保障しよう」

「はい……」

「君の決断を待っている。それじゃ」

と言うと男はあっさりとデスクに戻った。すぐさま私の背後のドアが開き、そこに立っていたネクタイ姿の若い秘書の男性が私に部屋を出るよう促した。

廊下に出た私の背後から「バカだな、即答しなければ二度と答えるチャンスはないのに」と聞き覚えのある声が掛かった。振り返ってみると、その声の主は小松崎さんだった――。

目が覚めてから私は妙に落ち着かない感覚に囚われた。なんだろう、それを言葉で説明することができないのだけれども。

 

その後のおよそ二週間にわたり斉藤さんら三人はずっとああだこうだと作業を進めていた。私はそれを横目で見つつ、いったい彼らは何をやっているのだろう、どのように物事が進んでいるのか、聞こえてくる彼らの会話からその糸口が掴めないかと耳を傾けていたが、なにぶん英語なので私には何ひとつわからなかった。彼らが私に質問することはほとんどなかった。日が経つにつれて私は疑心暗鬼に囚われていくのが感じられた。

ある日の午後、水谷さんがやって来て、ルカヘッドの三人と小松崎さんやリーダー格の先輩らを連れて行った。別のフロアーに向かったようだった。会議なのだろうが、このフロアーでやらないということは、クライアントの上層部との打ち合わせなのだろう。何か進展があったのだろうか。私は自分の心拍数が上がったのがわかった。

二時間くらい経ったろうか。皆が戻って来た。ルカヘッドの三人と一緒に見知らぬ人がいる。斎藤さんと打ち解けた感じに会話しているところからするにルカヘッド社の人なのだろう。営業さんだろうか。私は席に着いた小松崎さんに視線を送るが彼はいつもの仏頂面で何を考えているのかはわからなかった。

ルカヘッドの人たちはカバンを持って出て行った。その際、斎藤さんは小松崎さんの席に行き、挨拶をして行ったようだ。二人はお互いに頭を下げた。

彼らの仕事は終わったのか。どんな結論になったのだろう……。その頃、私はライブラリを利用したプロセスの定義手順のドキュメント化の作業をしていたが、もはや仕事には手がつかず、事の成り行きが気になるばかりだった。

再び水谷さんが来て、小松崎さんたちとミーティングスペースへと向かったようだ。取り残され、机に座ったままの私の手は、完全に止まっている。視線はPCのディスプレイを向いていたが、画面上の文字を目で追っていても、内容は頭に入ってこなかった。

そのまま夜になり、小松崎さんらは席に戻ってくる気配がないので、私は無言のままに帰宅した。

翌日、出勤した私が自分の席に着くとすぐに小松崎さんが来て私を打ち合わせブースに連れて行った。小松崎さんは疲れた顔をしていた。

「昨日、決まったことを伝えます。えー、今回のパイロットは引き続き完成に向けて開発を進めるけど、他の業務への横展開はされないことになった。その後のプロジェクトの進め方としては、今回の反省を踏まえて、一旦、白紙の状態に戻して検討し直す、と。おそらくルカヘッドを使うのは今回のパイロット限りになる。ま、今回の我々のやろうとしていることに対して我々のとったアプローチがそもそも悪かったのだろう、というのが現時点での見解、ってとこかな、と。それから……、篠原さんの今回のプロジェクトでの仕事は完了した、ということで本日付で当プロジェクトへのアサインを解除します」

「え……」

私の頭は真っ白になった。小松崎さんは、しばらく黙っていたけど、私が何も言わないので、口を開いた。

「何か質問がありますか」

私は気を取り直した。一番、気になっていたことを訊く。

「あ、あの……、ルカヘッドさんの調査結果は、どうだったのですか」

小松崎さんは、やれやれ、という口調になって言った。

「……篠原さんの作ったライブラリの中でエラーが起きていたらしいです。そのエラーのハンドリングが、まあ、中途半端だったためにエラーが表には出てこないで実行結果が不安定なものになっていた、と」

「あ……」

「だが彼らが問題にしていたのはそこではなく、ルカヘッド製品の使い方があまりにも常軌を逸している、と。この使い方では製品サポートの対象外になる、と。それで横展開がNGとなった。いざという時、ベンダーがサポートしてくれないのではクリティカルな業務では利用できないからね」

「……そうですか」

「ま、そういうことだから。……今日はもう、オフィスに戻っていいよ。資料は作りかけのままでいいからファイルサーバに置いといて。せっかく作ってもらったけど残念ながら使われる機会はないだろうから」

小松崎さんはそう言い終わらないうちに腰を上げた。私は黙って俯いたまま現実を受け止められないでいた。

私が悪いと言うのかよ、この無茶苦茶な状況の中で、できうる限りのことをしたというのに。誰がやったにしても、経過は違えど、最終的には失敗したろう。なのに私に責任を押し付けてプロジェクトから切り捨てる、ってわけ……。

自分が奈落の底にいる気がした。暗い、暗い、誰か私をここから出して。でもその叫びは声にならない。誰にも届かない。

 

***

 

古い傷口がぱっくりと開いた気がした。私は吐き気を催し、洗面所に駆け込むものの、口からは何も出ない。その場で座り込み、壁にもたれて息を整える。

午前中は仕事を放棄して、散歩に出かけよう、と考える。明るい日差しの下で、いつもの散歩道を歩くのだ。私はそのことだけを思い浮かべようとする。そのイメージに意識を集中させる。

だが、失敗した。私の頭は再びあの頃に逆戻りする。

――ルカヘッドの一件の後、私はファームのオフィスに戻った。プロジェクトから外されたのが急だったので、当然、私の次のプロジェクトは決まっていなかった。しばらくは新しい技術の勉強でもしようと思い、分厚い技術書に手をつけた。

そのまま数週間が経過し、私より後からオフィスに戻ってきた同僚らが次々に新しいプロジェクトにアサインされていくのを見るにつけ、ようやく私には事情が飲み込めてきた。どうやら私にはとんでもない悪評が被せられているらしい。それでどこのプロジェクトからもお呼びがかからないわけだ。

単なる被害妄想なのではないか。単に私にマッチする空席が出てこないだけのことだろう――。そうに違いないとは思うものの、私にはもう自分を抑えることができなかった。

辞表を出した。

その後、私は某大手システムインテグレータに転職し、そこそこの成果を上げ、プロジェクトマネージメントなどもこなすまでになったが、あまりもの激務に心身ともに限界を超えてしまった。ある日、壊れてしまう。この業界ではよく聞く話だ。

 

ルカヘッドの一件を思い返すとき私が思うのは、あの頃、私に足りなかったのは「正しい闘いだけを戦おうとする姿勢」だろう、ということだ。

他人が設定した戦場で、他人が設定したルールで戦ってはいけないのだ。たとえその他人に悪意がないにしても、だ。それは大抵は負け戦だし、いい勝負に持っていくことができたとしても勝利が見える頃には疲弊しきってしまう。

唯一、自分が戦場を規定し、自分が戦いのルールを定めることが、勝利を確実なものにできる正しい闘いなのだ。

そのことを理解するまでに、私はあまりにもたくさんのものを失った。ルカヘッドの件も心に深い傷として残っているが、それを手始めとしてその後にも大小の多くの傷を負うことで、ようやく、それが理解できたのだ。あまりにも大きな代償。

私は、洗面所の壁に手をつき、よろよろと立ち上がる。もう何も考えまい。

吐き気は続いていたが、私は玄関のドアを開け、眩しい日差しの照りつける外に出る。散歩して、自分を取り戻す。強制的に自分をリセットするのだ。私の、正しい闘いを戦うために。

陽光の中を私は歩き始める。

 

2021年5月2日公開

© 2021 堀井たくぞう

読み終えたらレビューしてください

リストに追加する

リスト機能とは、気になる作品をまとめておける機能です。公開と非公開が選べますので、 短編集として公開したり、お気に入りのリストとしてこっそり楽しむこともできます。


リスト機能を利用するにはログインする必要があります。

あなたの反応

ログインすると、星の数によって冷酷な評価を突きつけることができます。

作品の知性

作品の完成度

作品の構成

作品から得た感情

作品を読んで

作者の印象


この作品にはまだレビューがありません。ぜひレビューを残してください。

破滅チャートとは

この機能は廃止予定です。

タグ

この投稿にはまだ誰もタグをつけていません。ぜひ最初のタグをつけてください!

タグをつける

タグ付け機能は会員限定です。ログインまたは新規登録をしてください。

作者がつけたタグ

純文学

"ブリング・ミ・トゥ・ライフ"へのコメント 0

コメントがありません。 寂しいので、ぜひコメントを残してください。

コメントを残してください

コメントをするにはユーザー登録をした上で ログインする必要があります。

作品に戻る