人形つかい（3） 私はシステムエンジニア

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

» 2011/06/06

　2度目のエースシステム訪問は、東海林さんとぼくの2人で行くことになった。もう営業的な話をする段階ではないし、技術的な話がほとんどになるので、と東海林さんは言っていたが、黒野さんは不安そうだった。技術部連中だけで行かせたらケンカになるとでも思ったらしい。

　会社を出る直前、東海林さんがタバコを吸っている隙に、ぼくは黒野さんに隅の方に引っ張っていかれて、しっかりと釘を刺された。

　「頼むから東海林さんが暴走しないように注意しててくれよ」

　「暴走って」ぼくは笑った。「東海林さんがですか？」

　「別に暴力をふるうとか、大声で悪口を言うとか、そういうことを心配してるんじゃないよ。ただ、あの人、技術的におかしいところがあると立場に関係なく正そうとするからな」

　――エンジニアとして悪いことじゃないと思うけどなあ。

　「それって自分の仕事にプライドを持ってるってことじゃないですか」

　「プライドだけじゃ仕事は回らないってこと」黒野さんは苦笑した。「細川くんも大人になったらわかるよ」

　「でも、ぼくに東海林さんを止めるなんて無理だと思いますよ。備品としてスタンガンでも購入してもらえますか？」

　「いい考えだな、申請しとくよ。じゃ、頼んだからね」

　具体的に何を頼まれたのか、よくわからないまま、ぼくは東海林さんについてエースシステムに向かった。

　うちの会社からJR横浜駅までは地下鉄で10分だ。定期的に通うことになるだろうから、会社から近いのはありがたい。地下鉄の中で東海林さんは自分のスマートフォンの画面を見ていて、ほとんど会話はなかったが、一度だけ、ふと思い出したように顔を上げて訊いてきた。

　「そういえばAフレの方はどうだ？」

　「全然です」ぼくは首を横に振った。「ダメダメです」

　あれから、他の仕事を後回しにして、Aフレを理解しようと頑張ってみたが、どうにもならなかった。添付されていたプラグインファイルを自分のEclipseに入れて、ドキュメントの手順通りに試してみたのに、うんともすんとも言わなかったのだ。例外ログすら出力されないので話にならない。佐々木さんにメールをしてみたが「技術の方から回答させます」と返信が来ただけで、それ以後何の音沙汰もない。

　「そうか」

　東海林さんは、それ以上何も言わなかった。

　やがてぼくたちは横浜駅に到着した。地上に出ると10月の心地よい風が迎えてくれた。

　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

　エースシステムに着くと、今日はミーティングスペースではなく、少し先にある会議室に通された。ボート型の立派なテーブルと、電話会議用らしいプラズマTV、天井にプロジェクタが設置されている。隅の方にはWiFiルータまであった。

　気後れしながらカバンを置くと同時に、3人の男性が入ってきた。先頭は佐々木さん、1人は東海林さんと同年代、もう1人はずっと若く、ぼくと同じか少し下に見えた。いただいた名刺によると年長の方が第１開発室室長の林さん、若い方が同じく第１開発室システムエンジニアの橋本さんだ。

　「それじゃあ後は技術者同士で」ぼくたちが着席すると、佐々木さんは仲人のようなことを言って出ていってしまった。それを見送って、林さんが口を開いた。

　「さて、それではお願いしたいシステムについて、ざっと説明させてもらいましょうか」

　林さんはそう言うと、ダブルクリップで留めたドキュメントを渡してくれた。表紙には、こう書かれている。　

承認くん　システム概要説明書

　「承認くん？」東海林さんは目を丸くした。「これは？」

　「今回のワークフローシステムの正式名称です」林さんはこともなげに答えた。　「いい名前でしょう」

　「はあ......」Aフレといい、エースシステムにはネーミングのセンスがある人はいないのか。そう思ったものの、もちろん口には出さなかった。

　「承認くん」はK自動車の港北工場で使用されるワークフローシステムである。K自動車は日本のみならず、全世界に支社や工場や支店や販売店を抱えており、それらを結ぶ全社的な電子承認システムも当然持っている。

　ただ、各拠点にはその拠点でしか使用しないような承認ルートなどがあり、それらはいまだに紙の書類と印鑑で決裁が行われていた。たとえば、港北工場周辺に点在するタクシー会社のタクシーチケットの申請や、工場内の食堂とカフェテリアの関係で出入りする業者に対する注文／支払など、例外的な承認ルートは多岐にわたる。

　K自動車は、過去に発生した資材の横流し事件の後、いかなる決裁も承認ルートをスキップしてはならないことになっている。電子承認であれば出張先からでもリモートログインで決裁できるが、紙を使う決済では、印鑑が必要で、当然捺印する関係者がいなければならない。このため、重要な決裁が遅れてしまうこともしばしばだった。

　おまけに紙では、ファイリングしておくスペースも必要となるし、後で検索するのも手間がかかる。今回の電子化プロジェクトで、それらの不都合を一気に解消することが期待されているわけだ。

　エースシステムにとっておいしいのは、港北工場で実績を作ることによって、今後、全国に点在する各工場に対して「承認くん」の売り込みが見込めるということだ。当然、機能追加やカスタマイズは無数に発生するだろうし、「年間保守料」という名目での定期収入も見込める。受注に必死だったのも無理はない。

　しかし導入に失敗したら、K自動車からの受注が大幅に減ってしまうかもしれないし、SIerとしての信用も打撃を受けることになる。どんな手を使ってでも成功させたいと考えるのも当然だ。

　通常なら、下請け業者――ぼくたちのことだ――への説明に、室長レベルが出ることはないのだが、今回、足を運んでいるのは、エースシステムが「承認くん」プロジェクトを重要案件として重視しているからだ、と林室長は説明した。

　――失敗したら、この人はどっかに飛ばされるのかな。

　ぼくは不謹慎なことを考えた。

　「......とまあ、背景はこんなところです。何か質問はありませんか？」

　東海林さんは少し考えて首を横に振った。

　「いえ、今のところは大丈夫です」

　「それでは、橋本の方からシステム的なことを説明させます。私は打ち合わせがありますので、これで失礼します」

　林さんはそう言うと、自分の資料をまとめて会議室から出ていった。その後、この人の姿を見たことは、数えるほどしかない。

　「では、私からシステムの説明をします」

　橋本さんはぼくたちに「開発手順書」と印刷されたドキュメント一式を渡すと、自信たっぷりに説明を始めた。

　「承認くん」は、機能別に申請、承認、管理の3つのサブシステムに分類され、うちの担当は承認サブシステムとなるらしい。申請部分、管理部分は、他の下請け会社の担当だ。

　「承認はサブシステムAです」橋本さんは命名規則表の該当部分を○で囲った。

　「A01F001みたいなパッケージになりますね」

　例えば、承認の機能No.1のパッケージは、

　jp.co.kmotor.shouninkun.A01F001

　となり、その下に、A01F001L001.java のようなクラスを作成していくことになる。jspの階層も/shouninkun/A01F001/A01F001P001.jsp のように、対応するパッケージ名と一致させていく。

　――こりゃ厄介だ。

　覚えにくいことこの上ない。大手SIerではこういう管理方法が、まだまだ生き残っているとは知っていたが、実際に遭遇してみるとうんざりしてしまう。

　東海林さんは一応、抵抗を試みた。

　「この命名規則は変更できないんでしょうか？」

　「できませんね」橋本さんはきっぱり答えた。「これは弊社のプログラム管理台帳の規則ですから」

　「でしょうね。すみません」

　「設計書は、現在、作成中ですが、機能数はだいたい40ぐらいにまとまりそうです。それぞれ規模は違いますが」

　「規模というのは」東海林さんは皮肉な口調で言った。「ステップ数のことですね？」

　「そうですが？」橋本さんの顔は真面目そのものだ。

　「きっと循環的複雑度などで測定するんでしょうね」

　「循環......なんですか、それは？」

　「いえ、何でもありません」東海林さんはほとんど聞こえないぐらい小さなため息をついた。「できている分だけでもいいので、いくつか設計書をいただくことはできますか？」

　「いえ、それは無理ですね。できたものは上長の承認待ちなので。そこでOKが出ないとお渡しできないんですよ」

　「なるほど。いや、早い段階で見ておけば、疑問点などを質問できると思ったんですがね」東海林さんは話題を変えた。「まあ、それはともかく、開発の進め方ですが......」

　「基本はこうですね」橋本さんはドキュメントから該当ページを広げた。

• 【エース】設計書、ユニットテスト仕様書作成
• 【協力会社】実装、ユニットテスト
• 【エース】単体テスト、結合テスト、総合テスト
• 不具合の場合、不具合票を起票後、実装、ユニットテストへ
• 不具合なしの場合、完了

　「バグ修正はもちろんですが、そのバグが仕様の不備に起因するものだったら、どうなるのですか？」

　「うーん。そういうことはあまり起こらないと思うんですけどね」橋本さんは困ったようにうなった。「何しろ上長がチェックした設計書しか、そちらに渡らないはずなので。まあ、その場合は、ご相談ということで」

　――あまり起こらない？ 逆じゃないのか？

　ぼくの短い経験から言っても、バグの半分以上は、実装レベルではなく、仕様レベルで生まれるものだということぐらいはわかる。実装レベルのバグはユニットテストを真面目にやれば、ほとんどが発見できるし修正も容易だ。それに比べて仕様レベルのバグは、開発サイクルの後期になるまで発覚しないこともあり、修正も困難なことが多い。

　「ご相談とは？」東海林さんは追求した。「その場合の修正は、追加の見積もりを出させてもらえるか、他の機能の実装と相殺してもらえるということですか？」

　橋本さんの顔に苛立たしげな色が浮かんだ。ほとんどあり得ないことなのに、何をこだわっているんだ......口には出さないが、そう思っていることは明白だった。

　「私はそこまで決めることはできませんよ。その時になったら考えるということではいけませんか？」

　いいわけがない。そう思ったものの、そういう交渉は技術者がやるべき仕事ではないのも確かだった。

　「わかりました。では、そうなったときに相談ということで」玉虫色の答えで、東海林さんは矛を収めた。それからぼくの方を見た。「Aフレについて訊いてみたらどうだ？」

　「あ、はい」

　いきなり話を振られてびっくりしたが、ぼくは用意してきた画面のハードコピーを取り出すと、プラグインが動作しないことを説明した。

　「ははあ、なるほど」橋本さんはハードコピーを眺めた。「すみませんが、私はこっちの方はよくわからないので。これをお預かりして、誰かに訊いてみます」ぼくは了解したが、気になっていたことを質問しないではいられなかった。

　「あの、このAフレって、まだ完成していないんですか？」

　「そうらしいですね。まだベータ版らしいです」橋本さんはあっさり言った。「でも心配いらないですよ。もうすぐ正式版としてリリースできそうだって、開発チームが言ってたみたいですから」

　――伝聞の伝聞じゃないのか？

　「それで今はどうやって開発をしているんですか？」

　「とりあえず動作する部分だけを優先してやってるみたいですね」

　橋本さんがこともなげに言った言葉は、しかし新たな不安を呼び起こしただけだった。

　「後から不整合とか出てこないですかね」

　「大丈夫でしょう。何とかなりますよ」

　――その根拠のない自信は、一体どっから......

　キリがなさそうなので、「何とかって何ですか？」とか突っ込むのはやめておいた。ぼくは東海林さんを見て、バトンタッチの意を伝えた。東海林さんは頷いた。

　「サンプルソースなんですが、いただけるものありますか？」

　「いえ、このサブシステムでは、まだ難しいですね。もう数日お待ちください」

　「じゃあ、うちの作業開始はそれからということですね」

　「そうですね」

　それから、スケジュールや、テスト環境の構築方法や、テストデータを提供してもらう話など、いくつか細々したことを質問して、今日のところは終了ということになった。

　「ありがとうございました」

　「いいえ、こちらこそ」

　ぼくは終わったことにほっとして、受け取ったドキュメントを片付け始めた。だが、この日の最大の驚きは、この後にやってきた。

　「ちなみに」東海林さんがカバンにドキュメントを放り込みながら訊いた。「橋本さんは、今までどんなシステムに携わっていらっしゃったんですか？」

　「そうですね......ほとんどがK自動車関係ですね。まだあまり大きな案件はないですが。今回が一番大きいですね、規模としては」

　「Javaですか？」

　「VBが多かったですね」

　「VB.NETですか？」

　「VB6です。K自動車さんのシステムは、まだまだVB6が現役のものが多いんですよ」

　「それは知っていますが......」東海林さんは首を傾げた。「ということは、WebアプリケーションではなくC/S型ですか？」

　「そうですね。あ、ASPのシステムも少し担当しましたが。そういう意味だと本格的なWebアプリケーションの案件は今回が初です。まあ、私はシステムエンジニアなので、プログラミングはほとんど経験ないですけどね」

　東海林さんとぼくの手が、同時に止まった。

　――今、何と？

　東海林さんは顔をしかめて訊き返した。

　「失礼。プログラミングの経験がないんですか？」

　「ほとんどです」橋本さんは訂正した。「入社当時に研修は受けましたが、開発室に配属されてからは、SEとして先輩方についてましたね」

　その口調には、プログラミングの経験がないことを恥じていたり、弱点だと思っているする様子はまったくなく、むしろ誇らしげですらあった。プログラミングなどという肉体労働とおっつかっつな仕事は、エースシステムのような上流会社がやることではないのだ、とでも言うように。

　――実装経験なしで、どうやって詳細設計を書くんだ？

　「失礼ですが、今、何年目ですか？」

　「4年目ですよ。東海林さんはベテランプログラマですよね」

　「ベテランというか、まあ、長いことやってはいますが」

　「大変ですよね」橋本さんは同情するように言った。

　「何がですか？」

　「だって下流工程は苦労が多いでしょう？」

　東海林さんは絶句した。ぼくも、思わずまじまじと橋本さんを凝視したが、橋本さん自身は失礼なことを言ったとは思っていないようだった。

　「いや......あの......」めったに冷静さを失わない東海林さんも、さすがに言葉の選択に苦労しているようだった。「別に、下流工程ばかりやっているわけではありませんよ」

　「え、だって、お2人はプログラマなんですよね？」

　――そりゃ、今回はプログラマとして来ているけどね。

　ひょっとして橋本さんの中では、こんな図式が成立しているんだろうか。

• 上流工程の会社　......　分析や設計しかやらない
• 下流工程の会社　......　プログラミングしかやらない

　東海林さんはしばらく視線をさまよわせていたが、ひとまず脇に置いておくことにしたらしく、気を取り直したように立ち上がった。ぼくも慌てて東海林さんにならった。

　「すみません。ムダ話をしてしまって。それでは、これで失礼します」

　「ご苦労さまでした」

　エースシステムの社屋を出たとき、東海林さんはうんざりしたように振り返った。その表情は明るいとは言えない。

　「これは苦労しそうだな」

　ぼくも同感だった。実装経験のない「自称システムエンジニア」が作る設計書がどの程度のものなのか、今のうちから想像がつく気がする。橋本さんが真面目そうな人であることだけが救いだった。

　この時点では、うちとエースシステムは正式な開発契約書を交わしてはいなかったから、理屈では手を引くことも可能だった。しかし現実的には、そんな選択があり得ないことぐらいは、ぼくもわかっていたし、東海林さんはなおさらだったのだろう。自社に戻ったとき黒野さんが正式契約の話をしたが、東海林さんは嫌そうな顔をしたものの、表立って反対しなかった。

　ぼくたちが開発を正式にスタートしたのは、それから1週間後だった。

　（続く）

　この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。