だいだひろ

 冬になり,空気が乾燥しています。皆さんはどのようにスキンケアをしていますか? 私は肌がかぶれやすいのでWELEDAを愛用しています。輸入すると格安になるのですが,個人で買うと輸送費がかさむので,結局苦労するぶんだけ無駄になります。自作するか…。

 “良いアイデアを思いついた”と思っても,実際にトライしてみると思わぬ壁にぶつかって挫折することはよくある。プログラムでも「この方法でならイケる!」と勇んでやってみても,仕様上の制約などでうまくいかないことがあるだろう。これが自分で請負った作業で起こることなら能力不足と我慢もするが,人から押し付けられたやり方だと納得いかない人も多いだろう。

 しかし,SI(システム・インテグレーション)をしているからには,この状況から逃げ出すことはできない。なぜなら実際にコードを組むプログラマは契約上では最下層にいるので,もし依頼主が思いついたやり方がNGだと気づいても,なかなか切り出すことはできないからだ。言ったら言ったで生意気と思われるのが見えている。しかし,そのやり方で実際に失敗すると我々プログラマのせいにされる。理不尽だがしょうがない。SIの現場では「王様は裸だ!」と言ってはいけないのだ。

 今回はこのタブーに触れてしまったエンジニアの末路を紹介しよう。このように,やるせないことも多い現場ですが,志を高く持って働きましょう。

KY

 とある社内システム。社内といっても規模が大きいので,結構な稼ぎになるプロジェクトだった。当然,ソフトハウス側は喜び勇んで,お客様のシステム部と連携し,着々と設計を始めた。これといったトラブルもなく製造まで進んだころに事件は起こった。突然,お客様のシステム部の課長が「任意の場所にログを差し込めるような仕組みを作りたい」と言い始めたのだ。今なら“DI(Dependency Injection)コンテナじゃね?”と言えるのだが,当時はそんなものは無かった。

 このプロジェクトは社内システム部社員の勉強も兼ねていたようだが,問題は製造部隊。「先月,Javaの本を読みました。さぁ,作りましょう」ってノリ。協力してくれたソフトハウスからはそれなりのJava経験者が参加していたが,それはそれで入社以来ずっとJavaだけという開発者。メモリーアクセスを知らない子供達だ。デバッガのモジュールを拡張すれば,任意の処理を差し込めることが理解できない。このプロジェクトを技術的にサポートしているのが彼らなので,“やっぱりできませんよね”的ムードがいっぱいになったころにこの話を聞いたのが私の上司。

 他社がメインで製造するプロジェクトだが,前にトラぶったときにこの会社に世話になったことがあるそうで,ドライバで似たような機能を作ったことがある私に声をかけてきた。ざっと聞いた要件から,Feasibility Checkを行い,設定ファイルでアドレスを指定すれば,そこに任意のコードを差し込める仕組みを作った。

 「差し込みたい先のアドレスはどう調べるの?」という質問に“バイナリから解るでしょ”と言うわけにもいかないので,調べ方を説明したドキュメントも添えてみた。これを紹介したら“さぞ喜んでもらえるだろうなー”と久しぶりに前向きな気分になったのもつかの間,あっと驚くどんでん返しが待っていた。

 このログ機能,もともとはお客様の課長の思いつきで始まったのだが,進ちょく会議でこの人の上司である部長にまで話がいったときに「そんなのできるわけないだろう。やれるもんならやってみろよ」と嘲笑されたそうだ。この部長,年代からいってもメモリーアクセスを知っている子供達だと思うのだが,社内システム部としては例外だったらしい。

 プロジェクト製造チームのステークホルダー内で最高位の人物が「できない」と言ってしまったものを「できました!」と見せてしまったのだからさぁ大変。2007年の流行語の「KY」(空気が読めない)もいいところだ。部長のこの発言を知らなかったのだからしょうがないが,事態はますます不思議な方向へ進んでいった。

 こんなときに素直に自分の誤りを認める偉い人はなかなかいないので,まずは部長がケチをつけ始めた。部長の心は「こんなのは役に立たない」と葬り去ることなのだが,ソフトハウス側は導入前のリスクチェックと勘違いしてテキパキと答えてしまう。背景を知らないのだから当然だ。可哀相なのは間にいる課長さん。あとになって笑い話として「議論が深まるほど部長は技術的にイケてない雰囲気を醸成してたな~」と話してくれた。みんなのしらけムードがヒシヒシと伝わってきたそうだ。

 だが,これは後になっての話。当時,一番かわいそうだったのはこの課長。きっかけを作ったのもこの課長さんだし,部長の怒りの矛先が自分に向かってくることも目に見えていたのでビクビクしていたそうだ。結局,最後には課長の思いついたログ自体が発想としてイケてないと結論を出して話を丸く?収めたそうだ。

 まぁ,私もツールの保守まで任されてはたまったものではないので,これはこれでよかったのだが,可哀相なのは私のツールを紹介したソフトハウスの方。あとでことの真相を知り,ガクブルしたのはもちろんだが,長い間この部長からの風あたりがきつくなり肩身の狭い思いをしたとのこと。

 「ビジネスがからんだところでは,技術屋らしく誠意を尽くせば良いものでもないんだなー」ということを教えてくれたこの顛末は,今でも私の働き方の指針となっている。“お客様ステークホルダーの心象は傷つけるな”と。

それ,逆ですよね?

 次は,知人の話。ネットワーク設計でそのプロジェクトに参加した彼女は,すぐに体制のいびつさに気づいた。まず,なぜか必ずレビューがお客様以外の社外コンサルタントを通して行われていた。そして,そのレビューで出されたコメントは,お客様でも文句が言えず,その通りに構築を進めようとしていたのだ。構築業者がお客様の意見に文句が言えないのは何度も見てきたが,お客様が社外コンサルに頭が上がらないなんて。なかなか見られない構図に最初は「?」だった彼女。

 しばらくしてそのコンサルを交えたレビューに参加した彼女は,そのコンサルのコメントにあ然となった。「大規模だし,OSPF(Open Shortest Path First)よりRIP(Routing Information Protocol)のほうがはるかに効率的に管理できるだろう」。そりゃOSPFでも管理者が制御しきれなくなれば問題は複雑になるけどさ。彼女もいろいろとシチュエーションを考えてRIPのほうが良いパターンがあることは認めた。でも「効率的に管理」はないよなぁと思い「それ,逆ですよね?」と言ってしまったからさぁ大変。コンサルはわめくわ怒鳴るわ,罵声浴びせるわ。散々にこき下ろされ,ほとほとあきれた彼女が見たものは,しきりに謝っているお客様だった。

 ことの真相は,お客様の社長がこのコンサルを気に入っていて,社長じきじきの指示でこのプロジェクトに参加していたという,なんともよくある話。さらに言うと,このコンサルの派遣元は,いわゆる天下り養老院。お偉い方々がたっぷりいるので誰も文句が言えない。さらに面白いのはこのあとの顛末。RIPが現実的な解ではないことはみんなわかっているので,うまくコンサルを誘導する作戦に出た。このコンサルが「YES」と言わない限り,RIPで作ることになるからだ。

 ところが,勘違いはなかなか直らないからタチが悪い。コンサルに本を送るとかセミナーに参加してもらうとか,何とかコンサルの自助努力で解決する方法を試したが,効果なし。結局,「OSPFの試験導入のため」との理由でコンサルに納得していただき,本番では事なきを得たそうだ。こんな人が普通のエンジニアより給料もらってるかと思うと,やになるネェ。

CS向上がゴール

 システム開発も,ビジネスで考えると顧客満足度向上が目指すべきゴールの一つであることは変わらない。やっかいなのは,システム開発ではプライドの高いお客様に納得してもらうために,技術的正当性を曲げなくてはならないことがあることだ。常々思うのだが,自分の経験や知識が古くなったころに組織の進路を決断できる偉い立場になる形態は良くないのではないだろうか? 特にこの業界は技術が日進月歩以上のスピード感で進んでいくので,実現方法は現場の優秀な方にゆだねたほうがスムーズに進むだろう。

 ところが現場では「技術力も自分がNO.1」となりたがる方が多い。そんな方を相手にCSを向上しようとすると現場は疲弊するので,SI業界のイメージ向上のためにも,この業界で偉くなった方には役職の高さと技術力の高さとを勘違いして悦に入ることの無いよう,身を引き締めていただきたい。え? こんな記事を書いているおまえはどうなんだって?私は優秀な人が下にいたら任せますよ。だってそのほうが楽できるも~ん。ま,まさかの時にトラシューはやってあげますがね。

■変更履歴
本文で「お客様意外」としていましたが,正しくは「お客様以外」です。お詫びして訂正します。本文は修正済みです。 [2008/01/07 11:00]