ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

高慢と偏見(1)隣は何をする人ぞ

»

 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。

 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。

 「オブジェクト指向など、実業務では使いものにならない!」

 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。

 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこちから人を引っ張ってきている。とにかく猫の手も借りたいらしく、うちのような弱小ベンチャーにも声がかかり、たまたま手がけていた案件が一段落した私が駆り出されたというわけだった。

 部品調達システムは、10年以上HP-UXで稼働していたシステムだったが、ハード・ソフトともにそろそろ限界がきていた上に、システムを作成したベンダは倒産したらしい。当初はそのまま保守を継続してくれるベンダを探したらしいが、ろくな仕様書もなく、ソースの管理さえ怪しいとなっては、どこも引き受けてくれるところがなく、リニューアルとなったようだ。

 元のシステムはC言語とInformixで作られているが、新しく作り直す際にわざわざ踏襲する理由は何もない。OSがRed Hat Enterprise Linux 、データベースはOracle、開発言語はJavaとなった。UIには、一部Flashも採用されている。

 私たち常駐組は、大きな会議室を1つつぶして作られた臨時開発室に集められて開発をしていた。開発PCはログイン時に環境が初期化されるようになっているので、決まった席はない。

 ミーティングや休憩用としては、別にスペースが用意されているので、臨時開発室は比較的静かだった。そのせいか、隣の会議室の声が聞こえてくることがよくある。私の常駐は4月からはじまったのだが、隣の会議室は新人研修会場だったようで、お定まりの社会人マナーや電話応対、グループディスカッションなどが連日行われていた。

 私はだいたい壁に近い席に座ることが多かったので、よく隣から漏れ聞こえてくる内容を聞くともなしに聞きながらキーボードを叩いていた。

 そして5月のゴールデンウィーク明けのこと。

 隣では新人研修が一通り終わり、システム部門の研修が始まったようだった。

 誰かがJavaを教えている。地声なのか熱くなっているのか、講師の声はやたらと大きく、いつもより研修内容がよく聞こえていた。

 唐突に、その言葉が響いた。

 「オブジェクト指向など実業務では使い物にならない!」

 私は思わず手を止めてしまい、壁を見つめた。

 隣に座っていた男性プログラマも同じように手を止めて、まるで隣の会議室が見えるかのように壁をまじまじと見つめている。

 声は続いている。

 「オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな……」

 おいおいおいおい。私は思わず壁の向こうの顔も知らない講師に突っ込んだ。もちろん心の中で、だが。

 ――あなたはオブジェクト指向をほとんど使ったこともないくせに、オブジェクト指向は「使えない!」と断言しているわけですか?

 ――業務アルゴリズムに無縁って、Javaでも.NETでも使わない方が難しいのでは?

 ――オブジェクト指向を使っている人がほとんどいないって、今まさにあなたの隣の部屋ではほぼ全員が使ってますが?

 ――ポリ何とかって、ひょっとしてポリモーフィズムのことですか? っていうか、ポリモーフィズムも理解していないくせに、オブジェクト指向を分かったように語らないでください!

 「……例えば、サンプルの3番だな。ほら、わざわざクラスをnewしてるだろ。こんなことをしなくても……」

 何やらホワイトボードにキュルキュルと書き込む音。

 「……こんな具合に、staticを使えばインスタンス宣言などしなくてもいいんだよ。どっちが楽か分かるだろ? いちいちインスタンス宣言するなんておかしいよ」

 ――え、static? 今、staticって言った? まさかインスタンス作らないで、全部staticで済ませるとか?

 ――冗談ですよね? staticが同じVM内で共有されるってことを分かっていますよね?

 「そもそも自分でクラスなど作る必要はほとんどないしな。Javaでも.NETでもすでにデータベースアクセスでも、ファイル操作でも、数学計算でも、乱数発生でも、言語自体に必要なクラスはほとんど用意されているからね」

 ――いやいやいや、そりゃ違うでしょう。そりゃ、そういうクラスは用意されてますが、だからといってまったく自分でクラスを定義しないで、どうやってシステム作るのよ?

 ――まさかとは思うけど、main() の中に全部の処理を入れちゃうとか? だから、staticしか使わないとか言ってるの?

 「4番のサンプルもそうだな。これよく見ると、おかしいのが分かるね。forループの中でインスタンス生成しているだろう。このサンプルだとループが10回だからいいけど、1万回のループだったら1万個のインスタンスが生成されることになるわけだ。しかも、どこでもインスタンスの削除が書かれてないわな。こりゃ、メモリの無駄遣いもいいところだろう」

 ――あのー、GCという便利な存在を知らないのでしょうか?

 「オブジェクト指向の本とかサイトとか見ると、さぞすごいもののように書かれているけど、ないからないから、そんなこと。20年選手のオレが言うんだから間違いない!」

 もはや突っ込む気力が失せてきた。

 この講師さんが勝手な思い込みをしているのはいい。しかし汚れを知らない新人たちに、おかしなバイアスをかけてしまっていいのだろうか。三つ子の魂百までも、というか、最初に刷り込まれることって大事だと思うのだけど。

 それとも、今まで気が付かなかったけど、この会社のコーディング基準には「staticを積極的に使い、インスタンス生成は可能な限り避けること」とか書かれてるのだろうか。

 ふと気付くと、いつのまにかこちらの部屋のプログラマが全員手を止めて、隣の講義に聞き耳を立てていた。

 常駐メンバーの間では、特に誰がリーダーということは決められていなかったが、リーダー的存在として私たちが頼りにしていたのは、K自動車の子会社であるKシステムエンジニアリングの平良さんという30代の男性エンジニアだった。

 「自社には机がない」と笑いながら言っていたように、10年以上ICTシステム部に常駐していて、社内システムのメンテナンスや運用に携わってきたという。部品調達システムについても、システム部の社員の誰よりも詳しい。開発体制図上のプロジェクトマネージャはICTシステム部の社員だが、私は顔を見たこともない。平良さんが事実上のプロマネだと言っても過言ではない。

 K自動車ICTシステム部の若手社員である小宮山さんも机を置いていたが、この人はスケジュール管理とか勤怠管理とかをやっているだけで、プログラミングのことは分からないようだった。

 その2人が小声で話し込んでいる。平良さんは苦虫を噛みつぶしたような顔だった。

 「ちょっとまずくないですか?」

 平良さんが隣の部屋の方を見ながら言っている。

 「なんか、話している内容がめちゃくちゃですが」

 平良さんの方がずっと年上なのだが、小宮山さんに対して丁寧な言葉遣いだ。もっとも、親会社の社員だからというわけでもない。平良さんは10歳以上年下のメンバーに対しても横柄な態度を取ったことがない。

 「えー、そうなんですか?」

 小宮山さんは状況がよく飲み込めていないようだ。

 「三浦マネージャって、Javaの経験がないでしょう? なんで新人研修やってるんですか?」

 「いやあ、ヒロシさんが関西の方へ長期出張してるでしょう。だからピンチヒッターということで……」

 「でもあれじゃあ研修にならないでしょう。というより、新人さんが偏った考えを刷り込まれてしまいますよ」

 「三浦マネージャはベテランだから大丈夫だと思うんですが……」

 「ベテランといっても、COBOLとC言語でしょう」

 「私にはよく分かりませんが、Javaだって大した違いはないんでしょう?」

 「いえ、大違いですよ」

 平良さんはあくまでも穏やかに、だがはっきりと言った。

 「私に言われても……上層部が決めたことですから」

 「何なら私がやりましょうか?」

 「とんでもない。平良さんに抜けられては困りますよ」

 そう言いながら顔をこちらに向けた小宮山さんは、全員に注目されていることに気付いて、少し大きな声で言った。

 「はい、仕事を続けてくださぁい」

 メンバーたちは一斉にキーボードに注意を戻した。私もEclipseの画面に顔を向けた。平良さんと小宮山さんは少し声を落としてしまったので、会話の内容が私たちの耳に届くことはなかった。

 このときの私は、平良さんが目の前のプロジェクトには関係がないだろう新人さんたちの研修内容に、なぜここまで懸念を示すのかがよく分からなかった。長くて半年ぐらいしかここにいない私と違って、平良さんはこれからもずっと常駐を続けるのだろうから、いずれ彼らと仕事をすることもあるに違いない。そのときに、あまりにも使えないコードを書くようでは困る、ということだろうか。未熟でも、相手は親会社の正社員でもあるのだから、正面切ってしかり飛ばすわけにもいかないだろうし。

 私の考えが間違っていたことは、翌月になって明らかになった。

(続く)

 はじめまして。リーベルGと申します。

 いろいろと不条理なことがある、というよりは不条理なことの方が多い気もするIT業界。その奇妙な世界の物語を小説形式で掲載させていただきます。

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

Comment(13)

コメント

AC/DC

ひょっとして、このマネージャーのモデルは、あの釣り名人さんかな?
ともあれ、続きを楽しみにしてるっスよ。

レモンT

ハンドルに惚れました。貴方の行くハムレットはどんな街ですか(^^;;
 いろいろあって荒れやすい話題ですが、過去の不幸を乗り越え今度こそ建設的な会話が行われることをお祈りしております。
 この業界にいる以上、お互い死行錯誤(Trial and Terror)の日々とは思いますが、貴方の御活躍と御健勝を願っております。

リーベルG

レモンTさん、こんばんは。
やっぱりわかる人にはわかっちゃいますねえ(^^;

メロンシロップ

「オレはもう20年以上システム業界にいるけどな、その長い経験
から言うと、オブジェクト指向なんてものは、理論としては面白い
けど、およそ実用的とは言い難いものだな。」

まったくその通りだと思う。
現場ではオブジェクト指向を使っていない。

坂本昌彦

オブジェクト指向を使ってる現場もあれば、使わずに済ませられるので使ってない現場もあるって感じでしょうか。もちっと細かく言うと、「オブジェクト指向のプログラミング言語を使ってる or 使ってない」+「プログラミングの設計でオブジェクト指向を活用してる or 活用してない」の 2x2 = 4とおりですかね。
「オブジェクト指向のプログラミングを使わずに」「設計でオブジェクト指向を活用してる or 大いに参考にしている」ってー場合もありますよ?X-WindowsのGTKがそうでした。
どちらにしても、いくつかあるツールのうちのひとつ、って感じですね。

もっとも、ツールを作った人が想定している使い方に素直に従っていれば皆さんそれなりにハッピーなんですけど、オレオレ流に勝手解釈して使う人が出てくると死人が出るんですよね。ITに限らず。
「暖まって乾燥するから」と、濡れたペットを電子レンジに入れてチンしてしまう可能性はどこにでもあるんでしょうねぇ・・・。

Buzzsaw

たとえ継承やポリモフィズムを書籍で学んだところで、すぐに良さを実感することが
出来ない所がOOPの難しさかと考えます。
使い古されたExcelフォーマットにタイピングしただけでSE・設計者となって
しまっている、しかもPGを組めない人にとっては超えられない壁かも。。

「オレオレ流解釈」ってありますね。インターフェイス内のメソッドを個人の
判断で勝手に増やされたときは焦りました。でもFramwworkまわりはちゃんと
説明しないといけないですね。OOPを知っている(つもりの)人間も反省しないと
です。

あのにますえふてぃーぴー

他人の作ったPGと連携する場合にオブジェクト指向の偉大さに気が付くのかもしれません。

逆に言えば力業でもどうにか出来てしまうのがIT業界ですので、
オブジェクト指向の便利さに気がつけない人がいるのは事実ですね。
考え方自体は昔からあったような気がするんですけどねえ。

ひろし

これ、ぜったいモチーフはアレでしょ?
意地悪だなあ。大好きだよ。こういうの。
さりげなくオイラを登場させてるところも憎い。

通りすがり

多分、元ネタとなったであろう人は懲りずに居座ってるようですが・・・。

それはさておき、レガシー系の業務アプリほど、まともにオブジェクト指向でやれば効率高いはずなんですけどね。
『××』帳票とか『○○勘定科目出力』とか、バリエーションはいくつかあっても昨日は似た様なものですからね。その部分上手く派生で差分逃がせば開発工数だいぶ下げられますからね・・・。

それ以前に、Javaや.Netのテストフレームワークを活用するにはオブジェクト指向はある程度必須ですし、その発想はCやCOBOLでも使えますからね・・・。

pringles

>さりげなくオイラを登場させてるところも憎い。

え、どこに登場してるんですか?

pringles

最近、ここのコラムであまり面白いのがないと思っていました。
数行だけのコラム、まるで個人ブログの延長のようなコラムなどなど。
そんななか、久しぶりに読み応えがありそうなコラムです。
元ねたになった人からのクレームとかありそうですが、気にしないで続けていただきたいです。(ってか、編集部さんへのお願いでもあります)
続きを楽しみにしていますヨ!

アラファイブ

ちょっと心配なのですが、

COBOLでもエントリ系ならPFキーの割り込みとかで、マルチスレッド
に必然的になりますが、バッチ系だと1つのジョブステップでは、SQL
実行計画の中の1なめに相当する事をやって、出力はシーケンシャル
ファイルになる訳で、バッチ系に限るならstatic固定で十分なのもたしか
です。もし、全く互いに影響が無く、並行稼働出来るならジョブを並列
で動かすでしょうし。

その辺がごっちゃになっていると、後で逆に、悪いを良いと言い張る
技術者にあるまじき存在にされかねません。攻めるならエントリ系に
限るべきです。

なお、
1ジョブ=複数ジョブステップ
のつもりです。

kent

まさか自分と同じ名字が出てくるとは・・・。少しドキッとした。

コメントを投稿する