2016-01-23

SIはやめておけ

20代の数年間SIで働いた。1年以上前退職して今は別業界にいる。

今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくり暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。

一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。

以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。

工数至上主義

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

まり、どう頑張っても売上は同じなのだから、良いもの価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。

これが諸問題の根源で、いかに述べるような組織プロジェクトが出来上がっていく。

作業効率化しない

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

私は定型作業効率化しようとjsやrubyスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。

あるとき上司に肩越しに自分作業を覗かれて「何やってるの?」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの?工数に乗ってないよね?」「スクリプトテストもちゃんとしないと結果が正しいって保証できなくない?」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分作業工数内で完結する。むしろ工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず(読めないので)1時間無駄にした。

技術力いらない

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

社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術=技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。

そういう人が集まっているor残っている組織なので開発者ほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム部長お気に入り課長になり、部門長のお気に入り部長になる。その繰り返し。

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

私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。

意識の低い開発者メンバー

上述の通り、案件で接する開発者基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。

まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度(この場合顧客は私が所属する企業)、請負場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズド世界で生きている。

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

static BP

ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパー技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。

だが、拍子抜けした。あまりにも仕事が雑なのだコミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分ブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。

また、彼はJavaの有名なフレームワークであるStruts拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークバージョンを上げると壊れるというのが残念な点で負債になりかけていた。

私は異動したが、彼は今でもそこにいると聞いた。

技術の話

テストコード書けない

(最低限のものしか作らないから)安くて早い!という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何?」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの?』って問われるから絶対言うなよ」と拒否された。

保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。

リファクタできない

先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコード顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。

レビューない

私がいたどの案件にもコードレビューがなかった。リーダー開発者数人という構成場合、まず開発者は全員下請けリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステム挙動実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解齟齬が頻発していた。特に入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。

そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。

新規技術試せない

無難プロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業マネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術(言語フレームワーク)がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらラッキーぐらいの考えでいる。

常に横に倣えのアーキテクチャは私にとって面白くはなかった。

横に倣え

また横に倣えが加速してさらに悪い事に、同じアーキテクチャネットワーク再利用するために既存のサーバに新システム相乗りすればよいという発想も珍しくない。「資産再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックオンプレミスサーバ上で複数アプリケーションサーバ運用した結果、予想通り耐障害性が下がった。

また、Oracleライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システム共倒れになったこともあったがOracleのバグとして報告していた。

static Perlおじさん

新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。

まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか?」と聞いたら「Perlクラスなんて必要ない。構造プログラミング研修でならってないのか」と返ってきた。「俺が前に書いたPerlバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。

また、そのプロジェクトのメイン言語Javaで、Eclipseを使っていたのでPerlプラグインを入れてコーディングデバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグイン品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタしろと言っただろ!」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。

待遇・制度

給与

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

個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。

マシン

会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者基本的デスクトップ使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。

組織問題

とにかくクローズド組織

つの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから

情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメール添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダ権限を持った人間しか見られない。何で他の部や課が行った過去の見積提案資料自由に見られないんだよ。

ソースコードリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。

会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。

意思決定の遅さ

どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクト利害関係者ならまだわかるものの、まったく関わっていない上長(課長部長、時には部門長)を通さないと進まないという異常さ。

コスト削減

利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自ノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員デスクトップを使っている。ITとは。

本当に無駄しか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員派遣で雇うべきという提案が何度もされたが、課の予算オーバーするから無理だという回答しか返ってこない。

残業削減

表向きは社員健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システム監視し、削減できていない組織や人間評価を下げるようになった。

その結果、サービス残業が復活した。30時間を超えると部長説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員残業時間を管理するとかい無駄な仕事を増やしたし、管理される社員ストレスサービス残業に繋がったので下策だと思う。

他人残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

そもそも無駄作業や工数至上主義作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。

辞め方

トラックバック - http://anond.hatelabo.jp/20160123131828
  • http://anond.hatelabo.jp/20160123131828

    ブラックならともかく、わりと大手のSierっぽい。 金もらえるならなんでもいいならむしろオススメだろ 自分に合わなかったことを一般化しすぎだわ 主語がでかい定期

    • http://anond.hatelabo.jp/20160123141431

      こういったコメントが付く時点で社会のディストピア感を感じる。 誰が見ても「非効率」であることは明らかなんだし、1人あたりの生産能力を向上させることこそが産業革命以後の資...

  • [プリンシパル][エージェント][外注][相見積もり]プリンシパル=エージェント理論

    エージェンシー・スラック(agency slack)とは、エージェントが、プリンシパルの利益のために委任されているにもかかわらず、プリンシパルの利益に反してエージェント自身の利益を優...

  • http://anond.hatelabo.jp/20160123131828

    SIはやめておけというのはわかった。 じゃあ、どこならいいんだ? 何ならいいんだ? 要するに、どこに行っても何をしても、このご時世働くのは大変で、給料は上がらなくて、つらく苦...

    • http://anond.hatelabo.jp/20160123163720

      誰に何の仕事が向いているなんてわからないが、確かに好きなことをする、と言うのは精神衛生上すごく良い。そして給料も良ければなお良い。 でもどの仕事にどういう人が向いている...

  • SI叩きが酷くて気分悪い

    http://anond.hatelabo.jp/20160123131828 とか、ここ二日ほどSI叩きが酷くてちょっと気分悪い。 やれ技術が古い、テストをしないだのと叩かれまくっているけど、SIerって言っても色々だと言いたい...

    • http://anond.hatelabo.jp/20160123172824

      >>> ちょっとしたニッチな固有の技術を持っていて それを売りにした製品を自社開発すると同時に、受託開発も引き受けている。 固有技術なので顧客には完全なブラックボックス...

    • http://anond.hatelabo.jp/20160123172824

      世の中にはこんな企業があるという事が分かってたら、そこに転職するので教えてください。 文末のこの1行が全てを物語っているよなw

    • http://anond.hatelabo.jp/20160123172824

      ちょっとエッチな固有の技術ってなんだよ!

    • http://anond.hatelabo.jp/20160123172824

      そういう会社がもし存在したら、それはSIerとは言わないのである

    • 普通にあるよ(海外に)

      http://anond.hatelabo.jp/20160123172824 博士号歓迎で独自技術を持っている会社なんて海外にはごろごろあるよね。国際機関とか大学とか除いても。給料八百万円(7万ドル弱)なんて低すぎると思...

    • http://anond.hatelabo.jp/20160123172824

      私は以前、製薬会社で実験データのデータベースや様々な表示システムを作ったりマイクロアレイ解析などしてた。 その手の仕事をしている人は、社内に主にたった5人しか居なかった...

  • http://anond.hatelabo.jp/20160123131828

    業務系じゃなくてWebとかOSS界隈の受託だったらもう少し違ったのだろうね、この人、そっち向きだろうと文章見て思った。もったいない。日本はこうやって優秀な人材を失っていくのだ...

  • SIerだけど、楽しんで仕事してるよ

    http://anond.hatelabo.jp/20160123131828 にてSIerがボロクソに叩かれているので楽しんでいる人間もいると伝えたい。 売上高500億以上のいわゆる大手SIerに勤めている。 工数至上主義なのは否定...

  • http://anond.hatelabo.jp/20160123131828

    読んだ印象は「若いなー」って感じ。 傾向としては技術力を重視しないってことだと思うけど、 金儲けをしている以上、技術よりは金儲けを重視するのは至極当然な話。 経営者は、「...

    • http://anond.hatelabo.jp/20160124033041

      SIerに務めたことがない方では? 大手SIerは、売り上げにつながる形であることを示しても、そう簡単に変わるものではないことをご存知ない。 50%作業を削減できますって論理的に説明...

      • http://anond.hatelabo.jp/20160124085555

        すねちゃって扱いづらいエンジニア、って感じ。技術はありそうだけど・・・。 50%作業を削減できますって論理的に説明しても、それを周知徹底、ルール化、ネゴシエーションするだ...

        • http://anond.hatelabo.jp/20160124104401

          横だけど、エンジニア個人からしたら、そういう状況だったら転職するほうが合理的では?

        • http://anond.hatelabo.jp/20160124104401

          その通りなんだけど、だったらなんでこんなことになってるのか?っていうね... 売上の最大化が会社にとっての第一義にも関わらず、非効率を尊ぶ社員が多いのはなんで?しかも大手で...

          • http://anond.hatelabo.jp/20160126113646

            非効率を尊ぶ社員が多いのはなんで?しかも大手で。 これは、一見非効率に見えることが実は合理的な行動の結果なのだ、と解釈するのが妥当じゃないかな。エンジニア的に「効率的...

            • http://anond.hatelabo.jp/20160126122518

              大手SIでそれが取り入れられてないとすれば、それにはその理由があるからだ、と考えるのが妥当。 理由なんてないよ。変化に弱い大企業病そのもの 確立した時(たとえば COBOL の時代)...

              • http://anond.hatelabo.jp/20160130004909

                あー、大手SIそんなに知らないんだけど、大企業病そのものなんだね。つまり、日本語の壁と規制の壁(官庁系の超大規模開発は日本ベンダー優先)によって、日本企業が守られているか...

  • http://anond.hatelabo.jp/20160123131828

    まじで言ってんのかな。 工数を上げれば良い物ができるかという話は工数と品質の関係を数値で示さないと意味が無い。費用対効果すら提示できない状態で工数を上げたほうがいいって...

  • そろそろホワイト企業のSIの話をしよう

    http://anond.hatelabo.jp/20160123131828 「SIはやめておけ」に書いてあることが業界の標準だと思う。 例外として自分の会社の話をしたい。 でも、その前に、言いたいことがある。 まず勘違い社...

  • ここ最近のSIer批判について

    ここ最近のSIer批判について http://anond.hatelabo.jp/20160123131828 きっと、Web系の仕事は楽しいのでしょうね。 最新の技術をバンバン取り入れて、自分の裁量でどんどん動けて。 華やかな世...

  • SIに限らず、IT系企業経営者に対する組織改善要求

    http://anond.hatelabo.jp/20160123131828 SIer ではないのだが、私もIT系企業に勤めているので共感できる所もあった。 こうした問題が、なぜ起こってしまうのか?というと、理由は様々であり一概...

  • SIとアニメ産業の問題は似てるよね

    http://anond.hatelabo.jp/20150526175312 ↑を昔描いたんだけど アニメ産業の問題はオリジナルで勝負しないことだってことってかいたら わかってないなぁみたいな反論が来たんだけど 結局よくよ...

    • http://anond.hatelabo.jp/20160125064623

      お前はエセ宗教家であり、論理がなってない 自分の発言の定義を後から捻じ曲げて話を逸らすガキだ

    • http://anond.hatelabo.jp/20160125064623

      市場規模に対して供給側が過剰な印象はある。 小さい市場を大勢で奪い合ってるからそれぞれの取り分が小さくなってるイメージ。 ジブリの鈴木Pみたく一般層にまで市場を広げようと...

記事への反応(ブックマークコメント)