人形つかい（11） それでもオンスケ

ワークスタイル | 人間関係 | 職場

» 2011/08/01

　週に1度の情報共有ミーティングは、横の情報連携を強化するためには有益だった。横というのは、主にうちとライズさんとのことで、それまで何となく存在した会社間の壁のようなものが、ベルリンの壁のように崩壊した、というと言い過ぎだが、少なくとも開発室内では情報交換が行われるようになった。

　だが、縦の情報連携、つまり元請けたるエースシステムと、下請けたるわれわれの間の情報交換については、強化するどころか逆効果でしかなかった。エースシステムから降りてくる情報が、実装に必要な最低限の量に絞られてしまったのだ。

　その主な理由は、エースの上級SE高杉さんと、うちの東海林さんのひそかな対立にあった。端的に言えば、東海林さんが高杉さんの要件定義や設計の不安要素を遠慮なく指摘し、高杉さんがそれを嫌ったからだ。高杉さんがそう公言したわけではないが、そうとしか考えられなかった。

　例えば、11月半ばの情報共有ミーティングで、東海林さんはテストデータについて質問した。

「テスト環境に入っているテストデータですが、そろそろ、『あああデータ』から、本番に即したデータに変えてもらえないでしょうか？」

　あああデータとは、テストデータの氏名が「あああ」になっているような、テスト用に誰かが適当に作ったデータのことだ。うちや、ライズさんが使っているテストデータは、すべてそんなデータだった。

「何か不自由がありますか？」高杉さんが無表情に訊いた。

「不自由というか」東海林さんは肩をすくめた。「件数も足りないので負荷が予測できないですし、本番環境に切り替えたときに問題が起きないかどうか確認するのに必要でしょう」

「件数に関しては、自由に増加させてもらって構いませんよ」高杉さんは鷹揚に微笑んだ。「本番環境に切り替えたときの問題というのは意味が分かりませんね。具体的におっしゃっていただけますか？」

　東海林さんが答えるまでに、少し間があった。頭の中で言葉を吟味しているようだった。

「具体的にと言われると困りますが、例えば要件定義や設計で想定していないデータがあるというような場合です」

　東海林さんの言いたいことは、よく分かる。エンドユーザーが入力するデータは、エンジニアの想定よりはるか上空を飛ぶ場合が、多々あるものだ。ましてや「承認くん」は、新規システムであり、マスタもデータもまったく存在していない。

　社員データや原価コードなどのマスタ類はK自動車の基幹システムからコンバートしてくることになっているので、それほどおかしなデータはないかもしれないが、問題は承認データの方だ。こちらは、過去の伝票などから、別の会社がパンチしているところだった。伝え聞くところによると、何らかのバリデーション機能を持つ入力画面などではなく、単にExcelに入力しているだけだという。東海林さんのもっともな指摘を、しかし、高杉さんは憐れむように笑いとばしただけだった。

「わたくしが設計しているんですよ。そのようなことは絶対あり得ませんね」

－－絶対なんて、その方があり得ないと思うけどなあ。

　東海林さんは一気にやる気をなくしたような白けた顔になったが、エンジニアとしての義務感からか、なおも続けた。

「それでも一応、本番データでテストすべきだと思いますが」

「必要ありませんね」高杉さんは強引に話を終わらせた。「橋本くん、他に何か？」

　橋本さんは手元のメモに目を落として、少し躊躇した。

「どうしたの？」高杉さんは責めるように促した。

「はあ。イニシャルデータ作成バッチの仕様について質問が上がっています」

「どんな？」

「各バッチのI/Oの仕様です」

　高杉さんの口から、ふーっとわざとらしいため息が漏れた。

「どちらからの質問？」

　橋本さんはまたもや躊躇ったが、上司に睨まれて渋々答えた。

「サードアイさんです」

　全員の視線が東海林さんとぼくに突き刺さった。高杉さんのそれは特に鋭く、ぼくは耐えきれずに東海林さんに顔を向けた。高杉さんは、しばらく無言で東海林さんを見つめた後、挑むように言った。

「何がお知りになりたいのでしょう？」

「簡単に言えば正しく動作するかどうかです」

　答えた東海林さんの言葉もまた挑戦的だった。高杉さんのきれいに手入れされた眉がひそめられ、ぼくはハラハラしながら2人を見守った。

「正しく動作するに決まっていますよ」

「テスト済みというわけですか？」

「いいえ、テスト中です。でも、結合テストはテスト部門がしっかりやっているはずです」

「ではテスト内容とテスト結果を見せてもらえないでしょうか」東海林さんは穏やかに要求した。

　東海林さんがこだわるのには理由がある。イニシャルデータ作成バッチは、本番稼働の直前に1度だけ実行する一連のバッチ処理のことだ。システム本稼働は来年の2月1日なので、1月31日の夜間に実行する予定となっていた。

　この処理は、K自動車社内規定によるデータ保管期限の5年前からの伝票データを、「承認くん」のデータベースに登録することが主な目的だ。ただ、同時に過去の承認履歴レコードを生成するために、バッチ処理の中で申請処理、承認処理をシミュレートする必要があり、すべての機能が完成するまでは実行することができない。

　1つの工場に限定されているとはいえ、過去5年分の承認データは4千万件以上となり、バッチ処理の全行程に要する時間は、8時間と見積もられていた。当然のことながら、承認伝票は1月31日も生まれてくるので、バッチ処理はそれらの伝票がデータ化された後に実行する必要がある。

　高杉さんがK自動車港北工場と交渉した結果、1月31日の承認伝票は、20:00で受付を中止することとなったようだ。それから1月31日分の伝票をデータ化するのに1時間、チェックにさらに1時間と考えると、イニシャルデータ作成バッチを開始できるのは、22:00となる。すべてが順調にいったとしてだ。

　22:00に開始したバッチ処理は、順調にいけば、2月1日の午前6時に終了する。データチェックは処理途中でも可能だが、最終的なデータチェックや、ログのチェックは処理終了後に行う必要があり、それらに1時間の予定だ。

　つまり「承認くん」の準備が整うのは、午前7時の予定だ。工場のラインは8:30から、一般業務は9:00から開始となるので、バッチ処理が失敗しても最初からやり直す時間はない。文字通りの一発勝負だ。

　あまり考えたくないことだが、もしイニシャルデータ作成バッチが失敗したら、「承認くん」を2月1日に本番稼働させることはできなくなる。カットオーバーを1カ月延期して、仕切り直しにせざるを得ないだろう。そうなったときに発生するであろうゴタゴタは想像したくない。直接の責任はエースシステムにあっても、保身に長けた高杉さんが、うちにその責めを押しつけようとすることは、十分に考えられるのだから。顔を見たこともないテスト部門とやらが、どのようなテストを行っているのか、東海林さんが気にしたのも当然のことだ。

「テスト結果ねえ。それは無理ですね」

「なぜですか？」

「第一に」高杉さんは芝居がかって指を折った。「契約で本番データをK自動車から外に持ち出すことはできません。テスト部門は、K自動車内でテストを行っていますが、データをK自動車以外の人間に閲覧させることも認められていません。わたくしだって見たことがないのですよ。エビデンスもそれに準ずるのは言うまでもないですね」

「……」

「第二にテストはテスト部門に一任してあるので、開発チームが口を挟むべきではありません」

　言外に「下請けはもちろん」と言われているようだった。東海林さんは何か言いかけたが、高杉さんは、それを封殺するように続けた。

「第三に、協力会社の方たちに設計や運用のことまで心配していただく必要はありません。実装に専念していただければ、と思います」

「……分かりました」

　空しくなったらしい東海林さんは、おとなしく引き下がった。

　万事がこの調子だった。東海林さんが、主に技術者としての職業意識から、要件や設計の不安要素を質問すると、高杉さんがそれを封じ込める。高杉さんは、毎回、さまざまな言葉でその理由を説明するのだが、それらはすべて「設計はしっかりやってるから、あんたたちは実装だけやってろ」という意味に集約できた。

　石川さんをはじめとするライズのエンジニアたちは、自分たちの担当範囲だけをこなすことと割り切っているらしく、東海林さんと高杉さんの対立には無関心を装っていたので、援護にはならなかった。うっかり口を出して高杉さんの怒りが飛び火したりしたらたまらない、とでも考えているにちがいない。ぼく自身が同じような考えだったからよく分かる。

　このとき、東海林さんを援護したのは、意外な人物だった。

「あの」橋本さんが小さく声を上げた。「いいでしょうか？」

「何？」高杉さんは不機嫌そうに訊いた。

「テスト仕様だけでも見てもらってはいかがでしょう？」

　高杉さんと東海林さんは、あっけにとられて、2人そろって橋本さんの顔をまじまじと見つめた。橋本さんは、それらの視線を避けるようにうつむいたが、それでもなけなしの勇気を振り絞るように続けた。

「あの、あくまでも念のために……」

「あなたが口を挟むことではないと思うわよ」口調は優しかったが、高杉さんの表情は険悪だった。「それとも、わたくしの設計が信用できないといいたいのかしら？」

「いえ……」

「それなら余計なことを言わないで」

「……」

　橋本さんはそれきり沈黙してしまった。そんな橋本さんを、東海林さんはしばらくの間、意外そうに見ていた。

　その日の情報共有ミーティングはお開きとなった。

◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

　数日後、ぼくは、以前に担当したシステムに関して打ち合わせがあったため、昼食後、自社に戻った。打ち合わせは、技術部長の斉藤さん、営業の黒野さん、ぼくの3人で行われ、それほど時間がかかることもなく終わった。もう一度エースシステムに戻ろうかと考えていると、黒野さんが心配そうな顔で訊いてきた。

「ところで、エースさんの方はどう？」

「そうですね。ほぼオンスケで進んでますが……」

　自分でも意外だったのだが、ぼくたちの開発自体は、ほぼスケジュール通りに進んでいた。その最大の理由は、ユニットテスト以上のテストを行わなくてよかったことだ。基本的な画面フローはAフレによって制御されるので、Aフレの定義の記述方法さえ理解してしまえば決まり切った手順にすぎない。重要なビジネスロジックに集中できる、という点では、Aフレは有効な手段だと言えた。

にもかかわらず……

「進んでるが？ 何か他に問題でも？」

「何というか……気持ち悪いというか……」

　実装自体が順調にもかかわらず、ぼくは何となく違和感のようなものを感じていた。多分それは、自分が実装している機能が、システム全体のどのピースなのかまったく分からない、という達成感のなさから来るものだったのだろう。

　うちのような小さなベンチャーだと、エンジニアは全員が要件定義、設計、実装、テスト、設定、保守と、システム開発の全行程を担当することがほとんどだった。それは多くの知識の習得が必要となるし、全責任を負うことになるのだが、カットオーバーしたときの達成感は何物にも代えがたいものがある。ぼくなどは、その達成感だけのために、高いとはいえない給料にも、深夜を超える労働にも耐えているようなものだ。

　ぼくがそういったことを説明すると、黒野さんはわけが分からん、という顔をした。

「よく分からんが、実装だけに集中できるのなら、それはそれで楽じゃないのか？」

「それは、そうなんですが……」

　確かに楽と言えば楽だ。自分の実装担当以外は責任もない。

　しかしぼくも一応は、単なるプログラムバカではない、エンジニアのはしくれのつもりだ。自分の関わったシステムはきちんと本番稼働してもらいたいし、エンドユーザーの喜ぶ顔も見たい。何よりも自分自身が何かを得たいと思う。その上で会社に利益をもたらすことができれば言うことはない。

　この開発案件では、そういう喜びはどうにも得られそうにない。

－－そんなことを言っても分かってもらえないか。

　言葉を探しているぼくを見て、黒野さんは笑った。

「まあ、いいや。とにかく今後の付き合いもあるから、トラブルだけは起こさないようにな」

－－ぼくに言われても困るんだけどなあ。

　トラブルを起こすとしたら、多分東海林さんだろう。職人気質の東海林さんは、普段は黙々と自分の担当の設計や実装をこなし、他人の仕事に口を出すようなことはないのだが、スケジュール表や予算管理表を手にした管理者や営業が余計な口を挟むと、とたんに辛辣な性格に豹変する。営業の黒野さんとの口論はしょっちゅうだし、技術部長の斉藤さんとも何度もケンカしている。

　さすがにエースシステムが元請けだという意識はあるようで、高杉さんに対しては、技術的な間違いを指摘しつつも、一定の礼儀は守っていたのだが、それだけに鬱憤が晴れないようで、喫煙ルームへ足を向ける回数が増えていた。

　とにかく、2月のカットオーバーさえ無事に迎えられますように、ぼくは普段は信じてもいない神様に祈った。

（続く）

　この物語はフィクションです。実在する団体名、個人とは一切関係ありません。似たような行動や言動があったとすれば偶然の一致でしかありません。また、特定の技術・製品の優位性などを主張するものではありません。