はてブのこのエントリーを読んで、私も思ってることがあるので書き記して置こうかと。

2016-11-25 エンジニアから見たSIerがクソな理由
http://crapp.hatenablog.com/entry/why-sier-sucks

私もいわゆるSIerといわれる会社を渡り歩いている技術者の端くれ。8年ほど正社員としてグダグダやった後に嫌気がさしてフリーになり、これまで10余年の間、延べ7、8社くらいソフトハウスやらメーカー系SIやら独立系ベンダーに潜り込んでシステム開発をやっている。確かに、その大半は“クソ”だったといえるかもしれないが、その理由の大半を占めるのは、開発における理不尽な縛りだったと思う。

その“縛り”というのは、現場の風紀上のルールやISMS等セキュリティ関係の縛りもあるけど、それ以上に開発環境の縛りの方ね。上のエントリの人もいってるけど、まず開発マシンとして与えられるマシンスペックがショボい。CPUにCore2Duoあたりが出回ってる時代にCeleronだったり、64bitなOSに移行しようかという時期にメモリが2GBしか積まれてなかったり、今現在私が使ってるマシンも2世代前くらいのCorei5にメモリ4GBで、Eclipseでtomcat2つ起動したらもういっぱいいっぱいになる。これなら3年くらい前にゲーム用に作った家のBTO（Corei7にメモリ8GB）の方がだいぶ高性能だ。

ローカル環境が高望みできない分、サーバが充実しているかといえば、それもない。開発用の共有サーバはあっても、アプリサーバやネットワークの設定などは管理者しか行えず、開発者は好き勝手にいじれない。まぁこれはおバカな素人が壊しかねんということでわからんでもないけど、アプリのメモリ領域を増やしたりACLを追加したりといったことをするには、いちいち管理者にお願いすることになる。OSの根幹に関わる設定ならそうするのが妥当であろうが、アプリの設定くらい開発者に委ねても良くないか。DBも当然システム権限のあるユーザは解放されていないので、DBの設定の変更は当然できないし、見ることもできない。これまた問い合わせることになる。あと、ユーザ（スキーマ）も開発者ごとに割り当てられることは稀で、大抵1つのユーザ（とスキーマ）をメンバー全員で使い回すことになる。

そうした開発サーバが存在するのはまだ恵まれた環境といえるかもしれない。開発サーバがないことすらある。そういう場合はどうするかというと、結合テストで使う環境やステージング環境などを一時的に使うということになる。そのへんになるとさらに利用制限も厳しく、そこにモジュールをのせる際は、運用メンバやプロパー社員を通してデプロイをお願いすることになるので、そう頻繁に使うこともできない。これでほぼ確実に動くだろうというコードになるまでそのへんで動作確認するのは控えてしまうということになる。また、そこにのせる際は、上手くいかなかった場合の原因究明用にアホみたいにログを仕込むという無駄な作業も発生する。トライ＆エラーが非常にやりにくいのである。

あと、近年はネットワークのセキュリティが非常に厳しくなってきていて、開発現場のLANからインターネットに出られなくなっていたりする。つまり、開発中に普通にインターネットが使えない。どういうことかというと、ちょっとわからないことがあってもGoogle先生に聞くこともきない。褒められないことではあるが、ググって使えそうなコードをコピペなんてことは当然できない。それどころか、ApacheやSpringなどOSSのマニュアルやJavadocも参照できないし、OSSのライブラリを落としてきて試すということもできない。同様にmavenのセントラルリポジトリも使えないし、eclipseプラグインの配布サイトも使えない。まぁ、好き勝手に変なモノをダウンロードさせないとか下手なSNSは使わせない対策なのだろうけど、そのへんはプロキシでアクセス先をフィルタするとか、せめて現在の開発に必要なサイト（Java開発なのでoracleやsunドメイン）はホワイトリストにしてフォワードすれば良いものを、インターネット全面シャットアウトには閉口するしかない。これは開発効率ダダ下がりである。

さらに極め付けの“社内フレームワーク”とか“社内ライブラリ”といった必殺技を放ってくるSIerもある。これは何かというと、多くのWebシステムはOSSとして公開されているフレームワーク（JavaならSpring、PHPならCakePHPなど）を使って構築されているのだけど、それをそのまま利用するのではなくて、その会社内で建前上“さらに使いやすくカスタマイズ”されたフレームワークが用意されていることがある。が、これは技術者にとって迷惑以外の何者でもない。

そうした社内フレームワークの多くはSpringやHibernateなど複数のOSSをパッケージした薄いラッパーであり、基本的にはそれらのフレームワークを利用する感覚でいける…と思いきや、妙な制限がかかっていて本来使えるはずの機能が無効化されていたり、余計な追加機能が自動で働くようになっていて意図しない動作になったりする。しかも、その元のOSSはバージョンが最新ではなく1つか2つほど前のもので、解決されているはずの既知の問題をいくつか抱えたままだったりする。勿論そのOSS最新バージョンでは利用できるはずの便利機能も使えない。今現在まさに私はそうした災禍の渦中にいて、基本はSpringなのにサービスにAOPが挿せないという意味の分からないフレームワークを使わされている。そう、“使わされて”いる。「良かったら使ってね」ではなく「これを使え」という強制なのである。これは今回に限ったことではなく、社内フレームワークなるものを用意している現場では、例外なくそれを“使わされる”のである。

しかも、使わされる以上はサポートもさぞ充実しているのかと思いきや、そうでもない。フレームワークを作ってるチームはシステム開発とは別の部署で、彼らはまるでシステム開発チームのためにパッケージソフトをつくって提供してやってる的なスタンスだったりする。問題が起こったとき原因をこちらで調べようにも、丁寧に隠ぺいされていて、利用者側での調査にも限界がある。Javaライブラリであればjadである程度調べられなくもないけど、それがネットワークミドルとかだったりすると、サーバで稼働しているそれをこちらで調べることは不可能である。

「これはどうなってるんですか？」と問い合わせるのもワークフローだったりするし、問い合わせてから回答が返ってくるのも1日以上は待たされる。酷いときは3日経ってやっと回答が来たかと思えば「過去のQAのここに同様の事象に対する解決法があります」などとトボけたことを言ってきたりする。よしんばそうだったとして、それならすぐ回答返せよ！って話だし、もとよりQAの方法で解決できなかったから問い合わせてるのである。こちらは1週間後に始まる結合テストに間に合うように1日でも早く問題解決しようと動いてるのに、あっちの連中は遅くとも3営業日以内に回答すれば良いという姿勢で、その時間感覚が致命的にズレてるのである。

ここまででも十分クソ環境なのだけど、現場によってはさらに追い討ちをかける、ダメ押しが存在する。それはその現場に長年鎮座する老害技術者、先のブログでいう“長老”の存在だ。これに遭遇する頻度は今のところそれほど多くはないけど、今現在の現場ではまさにその存在の痛さに苦しめられているので、これについても書いておこうか。

過去に経験した長老の特徴をかいつまんで書くと、長年その現場にいるだけあって既存システムの仕様はよく知っている、そのため現場では広く信頼がある（ように見える）、しかし実際の技術力はそれほど高くない、仕様は知っていても中身のコードに関しては誤解が多々ある、現行システムのアーキに囚われていることが多い、ゆえに最新技術に疎い、と、こんなところか。

とにかくシステムの仕様を把握していること、PMをはじめプロパー社員よりもずっと長くその現場にいたことから、何かと言えばその長老に聞けば何でも返ってくる、いろいろ知ってる人という扱いになっていて、信頼も厚い。そのため本人も周囲に対して強気で、特に若い人に対して（相手が他社や現場のプロパー社員であっても）上から目線で話をする。思い込みも激しくて、何でも自分の知っている知識前提で語ろうとする。例えばWebサービスについてその長老はSOAPの知識しかない場合、インターフェースとしてWSDLがあるはずという前提で話すのだけど、RESTの場合は違う。もっといえば、既存のシステム間通信は全部SOAPだと思い込んでいて、それ以外はないと思い込んでる（というか、それ以外の通信方法を知らない）有様だったりする。もっといえば、SOAPという技術そのものが今どきは最早絶滅危惧種ということすら認識していない。

その前提でPMにも話をするのだから事態が混乱する。PMは技術については素人なので、この長老がいうなら確かなのだろうと信頼してしまう。とある機能が例のフレームワークで提供されているらしいという話になったとき、そのAPIは何なのかということになって、そこでフレームワークのチームに問い合わせれば良かったのだけど、その長老がいうにはWSDLがあるはずだと。実際、私も最初それを信じて調査を進めていたのだけど、どうもWSDLなんぞない。ならばRESTかと思いきや、実は単純なサーブレットだったというオチが付いた。Webサービスですらなかったのである。

ただ、それが判明した段階になっても自らの誤りを認めようとせず、フレームワーク側のせいにしたり、その調査の初動にあたった若手のせいにしたりして、恥ずかしげもなく自分は悪くないアピールをする。それでも彼は長老であるから、周囲は「その通りですね」と相槌を打って信頼性は揺るがない。実はちゃんと技術力があり知識がある人が彼の言動をみたら、彼がいわゆる“張子の虎”であることはバレバレなんだけどね。しがない技術力の私ですら現場入りして1ヶ月も経たないうちにそれを察知したくらいで。

以上はあくまで私の経験の話なのだけど、もしこれが今の日本における多くのSIer現場の状況であるなら、そりゃ米国のITイノベーションに歯が立たんわなーと思うことしきりで。といっても、米国の現場がどうだか私は知らないんですがね。少なくとも、GoogleとかMSとか、或いはAppleとかそのへんの現場って、アーキテクチャは常に最新を追いかけていて、セキュリティに配慮しつつもオープンで、技術力のないヤツは速攻で見破られて蹴落とされるといった感じで、だからどんどん先進的で実用的なモノが生まれてるんじゃないか、と想像してる。