SI全面否定ネタを書く人はいたところがクソかそいつがクソかのどちらか

SIが技術者のパラダイスだなんてことは当然ありえない話だけれども、なんかこう過度に自由気ままなイメージのあるプログラマー（というかITエンジニア）なんて方がほとんど幻想に近くて一部のプレイヤーだけがそういう仕事をしているわけではあります。これは一般的などの職業にも言えることで、士業ですら例外ではないよね。

で。

SIはやめておけ
まあ不幸だったね、としか思えないんだけど、主語が大きいので一応反論というかSIの擁護はしておこうと思う。

工数至上主義

受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。

「時間（工数）をかければ良い成果物ができるかもしれないが」と言っているけど良い成果物というのは費用対効果が合っている成果物のことだ。素晴らしいコード（これは保守性の面で場合によって必要な一方、保守性の面で場合によっては不必要なものである）も要らなければ要件にない余計な機能もいらない。もし時間をかけた結果として出来た成果物に要件と異なる成果が伴っていたらそれは実際のところちっとも良いものではない。
時間をかけることでもっとも「良い」成果物になる部分は「品質」なんだけど、品質においても100%バグのないシステムを作るのが難しい以上、一定の基準を上回る品質であればよい。品質を確保できない理由が「工数の不足」であればそのプロジェクトが単に見積もりに失敗しているか、深刻なトラブルが起きているかのどちらか。まともなSIerであればどちらの場合も顧客にしかるべき説明をし、自責でない限りは追加請求を行うだろう。顧客と対等な関係が築けているかなんていう曖昧な状態にある事自体が失敗で、裁判に持って行ったら勝てるか否かが最低ラインの基準。とはいえ、信頼関係は合ったほうが良いし、客の財布をしっかり把握しているべきだとは思う。

マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。

僕の所属しているグループの標語に「一番信じられないのは人力の作業」というのがあるんだけど…
テストデータは見やすく整形したExcelシートあたりからマクロで生成すべきだし、テスト結果の検証は検証プログラムでやるべきではないのかと思う。もっとも、それが正しいことを証明することもけっこう大変な部分はあるし、穴が生じても一律機械的すぎるとわからないことがあるので人が一通り眺めるという過程は必要だとは思っているけど。

元増田の現場と上司は残念でした。

前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。

先述の通り、予定工数で無難にプロジェクトが終わり、顧客も満足しているなら何の問題もない。しかしだね、予定工数で無難にプロジェクトを終えるためにはマネジメントするにも最低限の技術力がないと判断が出来ないことが多々あるわけで…
SIの現場ではどうしても発生してしまう「作業者」を自社で抱えておくにはあまりにも効率が悪いというのがSIという仕事の悪いところではあるけれども、「技術者」のベースラインは社内にないと苦しい。だからと言って、下請けしてくれるBPさんに技術力が必要ないということではない。ビジネスを広げていくためには技術力のあるBPさんがいればいるほどその可能性は広がっていくし、顧客なんかよりBPさんとWin-Winの関係であるべきなんだと思う。自社の開発者の技術力が高ければ高いほど、ついてきてくれるBPさんの質も上がるのが常である。

開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。

比率的には非常に効率がいいポイントはこの辺ではある。これ以上になるとよっぽどの統率力がないと成立していかない。そもそも、この比率を上げるってことは確かにプロパー社員一人あたりの売上・利益は上がるんだけど、一方で売上・利益あたりのリスクが加速度的に増大していくのでBPを食わせるために働く会社になってしまう。案外このことをよくわかっていない会社が多い気もしている。

そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。

正直なところ、このあたりの話は業界の悪弊みたいなもの。ユーザー企業側の意識が高くないかぎり、SIerとしてメリットのない提案はしづらい結果として、「技術面での改善」なんてものは本質的に不要だからではある。ただし、こういう問題意識を常に持っていることが新規案件に役に立つということを理解している会社は結構ある。

static BP

ほっとけ。

技術の話

ここは手短に。

テストコード書けない

意味がわかんない。ちゃんと動いているなりの理由があるならともかく、そうでないならありえない話だし、まあその会社がクソってことだ。

リファクタできない

ケース・バイ・ケースである。

レビューない

その会社がクソ

新規技術試せない

新規技術を実PJTで試すなどという概念はSIerには不要だ。堂々と新規技術で案件を取るべきだし、それで上手くいくという裏付けはPJT開始前にあるべきだ。試すってなんだ。もっともうちの会社はわりと無謀なので世の中で実績があるというだけで利用して地獄を見ることもままある（無駄にはならないが。

横に倣え

それは現場がクソだろ。悪いのは相乗りすることではなく非機能要件をきちんと満たすかどうかにすぎないけど。

static Perlおじさん

こいつは確実にクソだがプログラム構造仕様書なる謎ドキュメントは色んな所で書くので書き方は工夫すべきだと思うんだけどまあそれはさておきPerlがクラス構造を持ったのは実際そんなに昔じゃない（ここで言う昔は20年単位）であるので我慢しろ。

給与
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。

高くねーよ。とはいえ、大手じゃないかぎり500万を超えてくるにはそれなりに仕事ができる必要はあるとは思うけど。

組織の問題

元増田の会社がクソだね。こういう会社は確かに多いけど、そうじゃない会社も多いんだよ。