人形つかい（5）システムエンジニアとSQL

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

» 2011/06/20

　誰が誰に頭を下げ、誰が譲歩し、誰が叱責されたのか、それはわからない。数日後に戻ってきた設計書は大幅に加筆訂正されていて、「ローカルフォルダのExcelファイルを開く」という例の仕様は、「サーバ側でテンプレートからExcelファイルを生成し、ダウンロードする」と変わっていた。

　この変更について橋本さんは何も言わなかったが、ぼくにはかえってそれが良くない兆候のように思えてならなかった。橋本さんが作り笑いでもしながら「いやあ勉強になりましたよ」などと言うことまでは期待してなかったが、何か一言あってもよさそうなものではないか。

　ぼくがそう言うと、東海林さんは鼻を鳴らした。

　「だいたい実装知識なしで、要件定義だけならともかく、詳細設計までやらせること自体がおかしいんだよ。何考えてるんだ、あいつらは」

　もちろんこう言ったのは、自社に帰ってきて、エースシステムの人間の耳に届く心配がないときだった。

　その言葉を耳に挟んだ黒野さんが顔をしかめ、東海林さんがタバコを吸いに行った隙に寄ってきた。

　「ああいうことをエースさんに言ってないだろうね？」

　「まあ、ある程度は言っちゃってます。あ、でも」ぼくは慌てて付け加えた。「一応は敬語で言ってますよ」

　「言葉遣いの問題じゃないよ」黒野さんはぼくをにらんだ。「エースさんはお客様だってことを忘れないようにってこと」

　「ぼくに言わないでくださいよ」

　「東海林さんに言ってもきかないだろう。今後のこともあるから、とにかく、できるだけ穏便にね」

　――今後の付き合いについては、一考の余地ありだと思うんだけどなあ。

　技術者としての東海林さんのプライドも、黒野さんの営業的な配慮も、どちらの心情もわかるだけに何とも言えない。

　ぼくは修正された設計書に基づいて実装を開始したが、それとほぼ同時に、今度は東海林さんが問題にぶちあたった。

　それは、たまたまライズの人への用事で橋本さんが開発室に来たときのことだった。話を終えた橋本さんを、東海林さんが呼び止めたのだ。橋本さんはあからさまにイヤそうな顔をしたが、無視するわけにもいかず、仕方なく足を止めた。

　「なんでしょう。忙しいんですけどね」

　「これなんですが」東海林さんは設計書を見せた。「ちょっと確認したいことがあります」

　東海林さんが実装しているのは、ログインしているユーザーが、自分に届いている承認待ちの一覧を表示する処理だ。設計書の該当個所には、次のような仕様が書かれていた。

 　(1) ログイン情報のユーザーIDで、承認待ちマスタ(SyouninmachiMaster)から、承認待ち一覧を取得する（申請日付順）。

　　(2) 取得した承認待ち一覧を順番に処理する。

　　　(2-1) 承認マスタの承認ID(syouninID)で、承認履歴トラン(SyouninRirekiTran)から、承認履歴一覧を取得する（承認日付順）。

　　　(2-2) 取得した承認履歴一覧を順番に処理する。

　　　　(2-2-1) 承認履歴トランの承認者ユーザーID(syouninUserID)で、ユーザーマスタ(UserMaster)を取得し、承認待ち情報（別紙、画面項目定義を参照）を表示する。

　各処理の後には、SQL文が記述されている。東海林さんが問題視しているのは、このSQL文だった。

　「これが何か？」

　「それぞれselect文を発行すると書いてありますが」

　「だからそれがどうかしたんですか？」橋本さんは苛立たしそうに言った。「別に問題ないでしょう」

　「いやいや。問題あると思いますよ」東海林さんは苦笑した。「これだと、毎回毎回データベースにアクセスしなければならないから、とても効率が悪いじゃないですか」

　「効率はSEが考える仕事です」橋本さんは言い切った。「プログラマさんの仕事じゃないです」

　つまり、余計な口を出すな、と言いたいのだろう。ぼくなら、ああそうですか、とつぶやいて言われたとおり実装しただろうが、東海林さんは明らかに効率が悪い仕様を見て見ぬふりなどできない性格の人だ。

　「本当に効率を考えて設計したんですか？」

　「どういう意味ですか？」橋本さんは低い声で訊いた。

　「どう見ても効率悪いでしょう、これは。なんでJOIN しないんですか？」

　東海林さんが言うように、設計書に記述されているSQL文は、どれもFROM句にテーブルが１つしか指定されていなかった。ぼくの担当分の設計書でも、JOINされているSQL文が記述されていた記憶がない。

　「テーブルを結合すると遅くなるからですよ」橋本さんは当然のように答えた。「それぐらいわかりませんかね」

　「この方が遅くなりますよ」

　「どうしてそんなことが言えるんですか」

　橋本さんの声はだんだん高くなっていった。ふと横を見ると、ライズの石川さんが、警告するような視線を送っている。だが、背中に目がない東海林さんはその視線に気付かなかった。あるいは気付いていても、あえて無視しているのかもしれない。

　「少し考えればわかることではないでしょうか？」東海林さんは遠慮しなかった。「たとえばある部長さんに10件の承認待ちがあるとしますよね。それぞれ、リーダー、係長、課長が承認したとすると申請者も合わせて4件づつ承認履歴レコードがありますね。その1人1人の氏名などを出力するなら、少なくとも40回はSELECT文を発行することになるじゃないですか」

　「……」

　「JOINすれば、SQLが1つで済みますよね。どっちが効率的かは明らかじゃないですか？ JOINで試してみましたか？」

　「そんな必要ないですね」橋本さんは東海林さんを睨み付けた。「これで上長の承認ももらってるんですから」

　不意にぼくの頭に、ある疑念が浮かんだ。

　――この人、ひょっとしてJOINが使えないんじゃ……。

　さすがにそう訊くのははばかられたが、東海林さんは頭に血が上ってしまったのか、

　「まさかJOINを使ったことないとか？」

と訊いてしまった。

　――ああ、黒野さんはこういう言動を止めろ、と言ったのか。

　橋本さんの顔が歪んだ。

　「使う必要がないんですよ、そんなもの」低い声だった。「プログラマさんはSEの言うとおりに実装すればいいんですよ。何度も言わせないでください」

　東海林さんは諦めたようなため息をついた。

　「わかりました。そこまで言うなら、このまま実装しますよ」

　硬い表情で橋本さんは鷹揚にうなずくと、東海林さんに背を向けて戻っていこうとした。そこを、ライズの石川さんが呼び止めた。

　「あ、すみません。このテーブルなんですけどね」石川さんは設計書を橋本さんに見せた。「うちのユーザー環境だとカラムが足りないみたいなんですが」

　「……ああ、そうでした。追加しようと思って忘れていました。すみません」

　橋本さんはそう言うと、石川さんのPCの前に座り、おもむろにOracle Enterprise Manager を起動した。カラムを追加するならコンソールでalter table やればいいのになあ、と思っていたら、わざわざテーブル定義を呼び出し、GUI上でカラムを追加し始めた。ぼくはそれを見て、さっきの疑念を修正した。

　――ひょっとして、SQLそのものをあまり知らないんじゃ……。

　見るとはなしに見ていた東海林さんも同じ疑念を抱いたらしい。テーブル定義の修正を終えた橋本さんが、開発室を出て行った途端、石川さんににじり寄った。

　「あの人、SQL知らないんですか？」

　「さあ」石川さんは慎重に言葉を選んだ。「一応、クラッドは知ってるみたいですけど」

　INSERT、SELECT、UPDATE、DELETEは知っているわけだ。

　「でもJOINは知らない」東海林さんは確認した。

　「そうみたいですね」石川さんは首肯した。「訊いてみたわけじゃないですが」

　「DDLも知らない」

　「らしいですね」

　「ひょっとしてテーブル作るときも……」

　「Enterprise Managerからやってましたね」

　ぼくは思わず天を仰いだ。

　――この会社の「システムエンジニア」の定義はどうなってるんだ。

　東海林さんはうなった。

　「なんでそんな人が詳細設計やってるんですか？」

　「さあ、なんででしょうねえ」石川さんは言葉を濁した。「私もここに長いわけじゃないんですが、一応、橋本さんより上の人もいるみたいですよ。出張中とかで、まだ顔を合わせていないですが」

　礼を言って石川さんを解放すると、東海林さんは自分の席に戻った。

　「どうしますか？」ぼくは訊いてみた。

　「どうもこうもないなあ」東海林さんは立ち上がった。「とりあえずタバコ行ってくる」

　残されたぼくは、自分の担当分の実装を再開したが、どうも集中できなかった。

　ベンチャー企業に属している宿命というか、これまで多くの元請け会社のエンジニアさんと仕事をしてきたが、さすがにSQLをほとんど知らないSEというのは初めてだった。マネージャ級になるとそういう人もいるが、その場合は要件定義レベルまでしか手を出さないことが多いので、下請けとしては困ることはなかった。

　橋本さんが無能だとは思わない。もらった設計書は、エンドユーザーからの要求を落とし込む、という点ではおおむね問題がなかった。何かのツールかテンプレートを使っているのかもしれないが、項目の説明、画面の遷移、各処理の前提条件や例外など、ぼくが見てきた過去の設計書や仕様書と比べても遜色がないほどわかりやすくできている。

　それなのに、実装に関わる部分になると、先日のローカルファイルへのアクセスの件など、あまりにも勉強不足が目立つのはなぜなんだろう？ もちろん「プログラミング経験がない」と本人が言っていたとおり、橋本さんにはその種の知識がないのはわかるが、上長がチェックしたときに気付かなかったんだろうか。

　考えていても仕方がないことだった。東海林さんが戻ってきたのを機に、ぼくは思考を実装の方に切り替えた。

　思いがけなく、いくつかの疑問に対する答えがわかったのは、数日後の昼食のときだった。

　（続く）

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