SIerの社内フレームワークを前向きに捉えてみる - たけぞう瀕死ブログ

その昔、僕が客先常駐ソルジャーだった頃、そこには辺り一面炎上プロジェクトばかりでした。 当時僕の参加していたプロジェクトでは、 SQLで書いたら数秒〜数分で済むであろうバッチ処理をなんちゃってEJB 1.0のような独自フレームワークを使って数時間かけて処理し、挙句に朝までに終わらないと問題になって作り直したり なぜかすべてのバッチがSQL*Plusを叩くシェルスクリプトで実装されており条件分岐で済むようなケースがすべて別ファイルとしてパターン数分用意されていたため処理を少し修正するだけでも数百のシェルスクリプトを修正しなくてはいけなかったり はたまたオンラインの処理では1人のユーザがボタンを押すだけで200M以上のメモリを消費しこれ想定ユーザ数での使用にどう考えて耐えられないでしょみたいなものがあったり ResultSetをJSPまで持ち合わしてどこでもクローズされていなくてJMeterで

[tarchan]

＞これらの問題はプロジェクトの初期に技術的な方針を決定した元請会社のプロパー社員もしくはそれに極めて近い立場の方の技術的な経験不足が原因であることがほとんどでした。

[ya--mada]

自社だけで賄える自社サービスで、上流での失敗が起きていて、しかも原因が上流の技術面・管理面のスキル不足というね。自分の能力を適正に評価出来ない奴は派遣に切り替えて外部に評価してもらえば良いのでないか？

[kimutansk]

「技術力のない元請社員がイマジネーション溢れるドリーミングなアーキテクチャを生み出してしまうことによる損失のリスクヘッジ」ですか。それは確かに。

[houyhnhm]

ああ、この前見ました。びっくりしました。

[umaemong]

で、その社内フレームワークを作ってるのが技術的な知見の不足している人だったりする。相乗効果ぱねぇ。既存のものを使わずにわざわざ社内フレームワーク作るのって大企業のプライド的な理由が殆どだと思う。

[Muke]

いい話

[kuwalab]

“元請社員がイマジネーション溢れるドリーミングなアーキテクチャを生み出してしまうことによる損失のリスクヘッジ”

[int128]

社内標準のアーキテクチャを用意しておくって大事だよな

[honeybe]

そしてその社内フレームワークで出来る事出来ない事を認識していない元請SIerのせいでドリーミングな仕様を受け入れて「このフレームワークだとべらぼうに工数かかるんですが」と！(過去の怒りがふつふつと

[kumaroku]

あくまでも社内向けで検討するのはいいんだが、それを顧客先で利用するとたいていカスタマイズがはいり顧客ごとに異なったものになる。ガチガチでベースつくっても苦労するだけで報われないことが多い

[gikazigo]

SIerの社内フレームワークを前向きに捉えてみる - 新・たけぞう瀕死の日記

[bash0C7]

“社内フレームワークなるものの整備に乗り出したのです。”

[tagomoris]

“技術力のない元請社員がイマジネーション溢れるドリーミングなアーキテクチャを生み出してしまうことによる損失のリスクヘッジと考えるとある程度納得できる部分もあるのではないか”

[tpircs]

ドリーミングなアーキテクチャｗ