2014-03-11
■[Work]SIerの社内フレームワークを前向きに捉えてみる 
その昔、僕が客先常駐ソルジャーだった頃、そこには辺り一面炎上プロジェクトばかりでした。
僕の参加していたプロジェクトでは、
- SQLで書いたら数秒〜数分で済むであろう処理をなんちゃってEJB 1.0のような独自フレームワークを使って数時間かけて処理し、挙句に朝までに終わらないと問題になって作り直したり
- なぜかすべてのバッチがSQL*Plusを叩くシェルスクリプトで実装されており条件分岐で済むようなケースがすべて別ファイルとしてパターン数分用意されていたため処理を少し修正するだけでも数百のシェルスクリプトを修正しなくてはいけなかったり
- はたまたオンラインの処理では1人のユーザがボタンを押すだけで200M以上のメモリを消費しこれ想定ユーザ数での使用にどう考えて耐えられないでしょみたいなものがあったり
- ResultSetをJSPまで持ち合わしてどこでもクローズされていなくてJMeterで叩いたらすぐにカーソル数が足りなくなってしまう問題がプロジェクトの終盤に発覚したり
などなど、それはそれは酷い有様でした。
僕の経験上、これらの問題はプロジェクトの初期に技術的な方針を決定した元請会社のプロパー社員もしくはそれに極めて近い立場の方の技術的な経験不足が原因でした。
ご存じのとおり、SI業界では多重下請構造が常態化しており、それなりの規模のプロジェクトになると実際にコードを書くのは元請の社員ではなく下請のプログラマの方が中心になります。つまり、実際にシステム開発を行う上で必要になる技術力を持っているのは下請ということになります。
しかし、大きなプロジェクトの場合、プロジェクト初期は（元請のプロパー社員を中心とした）少数のメンバーで立ち上げ、プロジェクトが進むに従って下請の要員を増やす、という形を取ることが多いです。そのため、プロジェクトの序盤に技術的な知見の不足している元請のプロパー社員がシステムのアーキテクチャを決めるというような危険極まりない事態が横行していました。
当時はまだJavaも黎明期でしたし、企業システムのWeb化も始まったところという状況でしたから、実際に手を動かすことの少ない元請社員たち（本来彼らに求められているのは顧客との仕様調整であったり開発要員のマネジメントであったりするわけです）に技術的な知見が不足しているということは必ずしも責められるべき点ではないと思いますが、そういった部分を技術力のある下請に任せていれば避けられた失敗も少なからずあったように思います。
しかし、元請SIer（および一部のユーザ企業）ではこのような失敗を避けるため、プロパー社員の技術力を向上させるのではなく、技術力のある下請に任せるのでもなく、各プロジェクトでアーキテクチャを考えなくてもいいように社内フレームワークなるものの整備に乗り出したのです。
なにかと悪名高いSIerの社内フレームワークですが、もともと技術力にバラつきのある下請プログラマを統制するためのものではなく、技術力のない元請社員がイマジネーション溢れるドリーミングなアーキテクチャを生み出してしまうことによる損失のリスクヘッジと考えるとある程度納得できる部分もあるのではないかと思うのですが、いかがでしょうか。