  |
はてなキーワード: システムインテグレーターとは
頭悪い人は使っていて脳みそがオーバーフローしていたが、ある程度プログラミング能力が高い人には（勘定系システムの構築という一点においては）十分に良い言語。
実績のある人が特定の文脈でこれを否定すると、やったこともないやつがほれ見たことかと群がってくる。
十分な活躍の場があるということはわかっているのに、やったこともなくて否定する奴が多い。
いわゆるSIerだが、大規模システムを構築する力に関しては否定できない。
Web系企業で10年エンジニアをやった人よりもSIerの2年目の方がプロジェクトマネージメントスキルは高い。
顧客から要望を聞いて要件定義をできるWeb系エンジニアがどれだけいるのか。
今更否定しようがないほど当たり前になった技術だが使いこなせない頭の弱いエンジニアも多いらしく分断を作っている。
他にも思いついたら追記する。
前回 → anond:20200914214630
自宅に帰った新入社員の増村は、苦渋に満ちた表情で会社から貸与されたばかりのタブレット端末を見つめていた。
（この会社に入ってよかったのだろうか…）
大学でソフトウェア工学を専攻し卒業研究にWebアプリケーションフレームワークをテーマにした増村は、Webエンジニアになることを志望して入社したのである。採用選考において、部署配属は研修後に決定するので志望するWebエンジニア部に配属されないかもしれないと面接官に言われたが、Webに関われるのなら何でもやりますと二つ返事で答えたのだ。入社してから気づいたことだが、Webエンジニア部は小規模な組織であり、会社としては広告事業に携わる営業マンや企画マンになることを新入社員に望んでいるのだ。
（こんなことなら、WebにこだわらずSI（システムインテグレーター）業界を志望すればよかったな…）
しかし、皮肉なことに増村には自信があった。はてなスター研修でトップの成績を収める自信が。増村ははてなブックマーク（以下、「はてブ」と略す）とはてな匿名ダイアリー（以下、「増田」と略す）のヘビーユーザーであった。自宅ではてブと増田に熱中するのはもちろんのこと、大学で講義の空き時間にもスターの通知や増田ユーザー数の伸びに目を光らせているほどであった。そんな増村にとって、羽手生部長の説明は退屈で的外れなものだった。俺が代わりに壇上に立ってスター獲得のノウハウを伝えてやるよと言いたいほどであった。
羽手生部長ははてなの会社経営や事業内容については同業他社としての見識を持ち合わせていたが、その名に反して肝心のはてブの知識があまりなかった。はてブの使い方を説明すると言い、プロジェクターにはてブのトップページを表示させて500ユーザー超のライフハック系エントリーを開き、
とスターをもらえそうにない互助会ブロガー文体のブックマークコメントを残した。そして、新規にブックマークを追加する方法についても説明した。新聞社のWebページからスポーツの記事を探し、巨人が逆転負けしたというニュースにはてブして、
前半リードしていただけに勝てると思ったけど残念です
という、これもまたスターのもらえそうにない残念なコメントをした。
新入社員もはてブを知っている者はほとんどいない感じだった。はてなスター研修を羽手生部長が説明した時も、「はてなってなんだ？」、「名前は聞いたことあるけど使ったことないな」というつぶやきがざわめきとともに聞こえたくらいだ。「ブックマークコメントはいくつしてもいいのですか？」、「アイコンは変更できるようですけど、変更してもいいですか？」などとあまり本質的ではない質問を羽手生部長にする者もいた。それに対して羽手生部長は同一ページのブックマークに二つ目のコメントを入れられないかを試行錯誤していたが、近くに立っていた武隈課長が1ブクマにつき1コメントしかできない仕様だと説明した。その流れでアイコンの変更方法も武隈課長が説明した。
武隈課長ははてブに対する知識はあるようだが、基本的に置物のように立っているだけで研修に関してはあまり実権がない感じだった。しゃべり方や所作に覇気はなく、閑散部署の名ばかり管理職といった風情だった。増村は羽手生部長ではなく武隈課長に以下のようなはてなスター獲得方法についてのクリティカルな質問をしようとしたが思いとどまった。
はてブの経験者だと感づかれたくなかったので、増村は何も質問しなかった。はてブをするものなら誰しも、はてなユーザーであることを隠匿するのは当然のことであろう。FC2・発言小町・ガールズちゃんねる・ふたば☆ちゃんねる・爆サイなどの利用していることを公言しづらいWebサービスのユーザーでも、人と場所を選び酒の席で興が乗った時ならばカミングアウトが許されるだろう。しかし、はてなユーザー（特に増田）であることを公言することは冗談では済まされない。ネット上で誹謗中傷を交わすだけに飽き足らず、現実世界で凶行に及ぶ可能性を秘めた危険人物扱いされてしまうがオチだろう。増村はその日、言いたいことをこらえながら研修の説明をじっと聞いていた。
ちなみに研修としては、スター獲得の最適解を追求するのが目的ではないと増村は感じた。どのようなコメントをすればネットユーザーの好意的な反応がもらえるのかを新入社員同士が競い合いながら探っていき、広報能力を向上していくことを人事としては望んでいるようだった。そのような研修で部署配属を決定するのもどうかと思ったが、研修する側も初めてのことを試行錯誤している感じだったので真意は測りかねた。
増村はタブレット端末をじっと見ながら考えた。はてなユーザーであることは絶対に悟られてはならない。だからと言って、稼げるはてなスターを獲得しにいかないのもプライドが許さない。それに、配属はどうなるのだろうか。スターを大量に獲得してトップの成績を収めたら志望通りWebエンジニア部へ配属してくれるのだろうか。研修で優秀だったからと本人の志望を無視して、Webエンジニア部でなく広告事業関係の部署へ配属するのではなかろうか。
――いったい、俺はどうすればいいんだ…。
かつて日本を代表するPCメーカー、そしてシステムインテグレーターの大手6社に数えられるNEC。それを退職した今、機密に触れない程度に、特に研究所の裏事情を説明していこう。おそらく製品部門は違う苦しみを抱えているだろうが、高額なボーナスもらってるんだから耐えてくれ。
私が入社したのは、研究発表でのいわゆる一本釣りだった。釣りあげた部門も、当時の研究に比較的近かったため、給料をもらいつつ研究ができる、という不純な動機があったのは確かだ。大手特有の研修体制も魅力に感じた。
雲行きが怪しくなったのは1年目の夏である。当時研究所のトップであるE氏による、研究発表の総評の場で「まだそんな研究していたのか」という発言だった。NECのシステムインテグレーションといえば、重要な事業の柱であり、事業部からの引き合いも非常に強かった。折しも、AWSが日本国内での事業が躍進し、オンプレミスとは違う流動性の台頭に、研究テーマとしては佳境の段階であった。そこに貢献するミッションは他の研究テーマでは代用できないものである。
それをE氏は「そんな研究」と一蹴したのだ。翌年、予算はつかず、研究チームは文字通り解散となった。そしてシステムインテグレーションの研究はNECから完全に姿を消すことになった。E氏は光通信の元研究者で、正直なところなぜ偉くなったのか、今でも疑問であるが、少なくとも大のつくIT音痴であることは仲間内では有名である。それこそ当時はデータベースとは何か、すら知らなかったようである。
E氏が理解できる、できないはあったにせよ、そして価値の提供方法まで突き詰めて考えられていたかは怪しいけれど、少なくとも、なんのためにやっているのかわからない研究ではなかった。「バイオプラスチック 漆ブラック」などいった、海のものとも山のものともつかぬものより劣っていたのだろうか。カーボンナノチューブの研究すらまだ留保しているのに。
そしてE氏はNEC常務となり、CTOとなった。社内では最高級（給）のブロガーと称され、「未来について考える」だとか、「～について意識しなければならない」といった、きわめて抽象的、かつ薬にも毒にもならないビッグワードを垂れ流し、評論し、何かをいっているようで、実際には何ひとつ具体的な行動や指示を出せない人物である。そして未来創造会議というような、何ら結論の出ないものに露出するようになった。あれを見た人は、NECが何の会社なのかわからないだろうし、それは製品として何を提供するのかすら伝わらないだろう。漫画雑誌の企画会議ですらもっとマシなものだろう。
研究所といえば、技術部門の花形、と思われる人もいるかもしれない。事実、優れた技術はほぼすべて研究所発である。しかし、本当に優れた技術はNECからの広報には載らず、社外からの引き合いが先行する。なぜなら、広報はインパクトが優先され、そして広報ノルマを充足するために実施されるからだ。そして時には大きな「事故」となる。
数年前、橋梁構造物の劣化診断という技術が日経新聞に掲載された。これは固定カメラが画像を撮影し、振動による変化で構造内部の劣化をモデリングし、内部ひび割れを可視化するという画期的なものであった。事件の発端は、その研究途上であった技術に対し、研究所の理事(*2)がメディアの前で口を滑らせたことである。当然注目され、実用目途についてまで発表することになった。実際には理論検証が完了し、クリアしなければいけない項目の洗い出しの最中であったという。1年後を目途とされた研究テーマは、その後研究所から姿を消した。撮影には非常に繊細な取り扱いが要求され、撮影時の振動に弱いという欠点を克服できなかったと思われる。これは当時画像診断系の学会でも度々指摘されていたもので、研究者の間で共通認識であったが、残念ながら理事には理解できなかったようである。
ここ数年のNECでもっともインパクトがあった事象は2件の談合による指名停止であろう。煽りをくらい、全く無関係の研究所予算がまずは削減された。そして賞与が大幅に減額である。社内ですら、談合当事者やその上司の名前は完全に秘匿され、明に責任をとった人物は存在しないことになっている。おそらく、公表した場合、全社員から報復を受けることを恐れたのであろう。
すると、不透明な人事はいたるところにあることに気がつく。前期の大幅に未達だった中期計画の責任者だった遠藤元社長は会長になり、その策定の中心人物だった新野副社長は社長となった。そして次の新中期計画は1年目でとん挫したにも関わらず社長以下留任ときたもんだ。
グローバルビジネスの低迷。これからのNECの生命線とまで言われていたグローバルBU。彼らは海外売上比率を25%を目指すと宣言していた。中期計画に対して、何ひとつ貢献できずKPIを外したそのトップ、真っ先に責任を取らなければならない人物M氏は、翌年副社長となった。その自浄作用の無さもさることながら、株主や債権主の銀行は一体何を考えて、彼らの役員人事を承認しているんだろうか。株価は買値の1/10となった、もう値動きすら見たくないから早く潰れてくれ、と思っているのだろうか。
今後、NECは暗黒の時代を迎えるだろう。折しも今年は3000人のリストラを掲げ、断固と構造改革を実施する覚悟を強調する新野社長。しかし、彼にあるのは覚悟だけであり、スタッフを減らす方策すら定まっていないだろう。現状、10人が事業で仕事をし、8人が彼らの事務を担当するような人員比である。そして今回の早期退職は主に事業の主力たちが手をあげるようである。
思えば、個人の努力が何に対しても反映されず、学習性無気力に苛まれ続けたNECライフであった。管理能力に長けた上司はおおむね本社に接収され、帰ってくることはなかった。そして残ったのは、管理職不適格でありながらも、降格制度が存在しないことによる吹き溜まりである。会社に学会の仕事をしにきている主幹研究員なる人種もいれば、1時間前の記憶すらないような痴呆老人である。そんな中、近頃はカルチャー変革(*3)を謳っているようだ。NECの暗黒時代たる本質まで踏み込み、ぜひNECを再生していただければと思う。
(*1)ビジネスマナー研修や思想教育といったものから、ディスカッションなどがあったが、参加者も講師もレベルが低く、こいつら大学出てるのかすら怪しげだった。彼らが同期となって、社内キャリア形成上意味をもつ存在だと思うと、ぞっとした。さまざまな節目に集合研修は行われたが、効果を測定する様子もなく、ただそこに予算があり、研修を実施することが担当者の評価だ、というような空気であった。そしてその直感は、NECのスタッフ部門全体に共通するものであると後にわかる。
(*2)理事とは事業部長、本部長、中央研究所傘下の研究所長経験者で、様々な理由で部門が消滅したりすると発生する役職である。最近では、関西研究所CCII本部長、シンガポール研究所を歴任し、価値共創センターを立ち上げ、これらのすべてを失敗させたY氏が理事となっている。彼らは理事になると、「天下り」先を探すことがメインの仕事になる。そして彼らが天下れば、空席となった理事は別の元所長が補充される。
(*3)カルチャーは変革できても、働き方全般や違法裁量労働たるVワークの制度は変えられないだろう。また社員のモチベーションを上げるための施策は、すべて人事部門判断によって握りつぶされると思われる。総務部は人事部門の抵抗をどのように回避するのか、外様の役員の腕の見せ所だろう。
こんな記事があった。
「Web系企業に転職して最高だったという話をしたい - ある研究者の手記」
http://mztn.hatenablog.com/entry/2017/12/03/122429
私はシステムインテグレーターからウェブ系に転職したが大失敗した。
システムインテグレーター時代は仕事が分かりやすかった。プロマネがいて、自分がいて、パートナーの方々がいて、役割分担が明確。ところがウェブ系は役割分担が不明確で、誰か指示を出してくれる人もおらず、自分で気づいて仕事をしなければならない。
この自分からタスクを見つけるのが本当に苦労した。別に自分からやるべきことを見つけられなかったわけではない。システムインテグレーターにいた時はウォーターフォールからブレークダウンしてタスクを洗い出すことはよくやってた。むしろ得意だったくらいだ。ところがウェブ系はそもそもウォーターフォールではないことが多いので、その基本的な部分が違うことで、何をしていいのか全くわからない状態が続いた。完全にお荷物さんになり、転職を激しく後悔した。根本的な原因としては特定の技術のエキスパートではなかったので、入り込める余地がなかったことだと後から分かった。
合う合わないが本当にある業界だと思った。迂闊にウェブ系に行くことは絶対におすすめしないです。よほど自分に自身があったり、特定技術にかなりの強みがない人は、システムインテグレーターにいるのがトータルで見て絶対に幸せだと思います。
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に貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃に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にまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
これまで2社の超絶ブラック企業を経験し、やっとまともな待遇(それ以外がまともとは言っていない)の会社に入れると思った矢先にこれ
数日前まで「月給5万円アップだうっひょ～」とか思ってたけど前の会社が安すぎただけだからそうでもないのかもしれない
WEBサイトにアクセスしてみるとトップはApacheのテストページが表示されたり他のページは404エラー吐かれたりこりゃただごとじゃないな
内容としてはこれで終わりなんだけど短すぎるのも申し訳ないのでこれまでのイカれた経歴を紹介するぜ
・第一部
「未経験でも充実の研修でエンジニアに！」との謳い文句に騙され未経験で某特定派遣会社に入社
テキストを読むだけの研修後、某中堅システムインテグレーター(C社)に派遣→某大手システムインテグレーター(I社)にパートナーとして又貸し→I社の子会社の業務へ
三次受けという身分が狭い環境で残業してもお給金が全く増えない激務に耐えるがストレスで不眠症と謎の腹痛に襲われ退社
・第二部
「やっぱ自社開発やってるところで行こう」と思った愚かな私めは地元のよくわからない会社から内定をもらって親に「どこでもいいからとりあえず金稼げ」と言われ入社
求人に残業代は1000円/時間と書いてあったのでほっとしていたら、そんなことはなかった
経験浅い人間を数人だけ安月給で雇い、意味の分からない納期を指定してくる社長とマネージャーにありがたいお言葉をいただきながら毎日終電までの激務(ボランティア)に身を投じる
私はサーバサイドもクライアントサイドも書いていたがLinuxが触れない5歳くらい年上のサーバサイドエンジニアが爆弾コードを大量に仕込み、火消しで終わらない
クライアントサイドはデザイナーが凝り性なのか、納期ギリギリまでデザインを上げてこないので実装できなかったが納期数日前にデザインを上げてきて自分だけ定時退社してるのにキレそうになりながらもレッドブルをキメる
頭頂部にBB弾程の大きさのハゲが生まれ、ストレスでタバコの本数が2倍に増える
第二部完
そして数ヶ月転職活動を続け、それなりのところから内定をいただいたが表題の通りで入社日当日に転職エージェントを通してお断りする
今に至る
気をつけるべきこととして、入社前に会社の下調べを死ぬ気でするようにしてほしい
ネットストーカーばりの情報収集能力を身につけないと、不眠症・腹痛・ハゲ・タバコ・太る・痩せる等の体の異変に悩まされることになる
ベンチャー企業や中小企業を受ける場合は面接の際に相手は半分嘘をついてると疑ってかかるのもおすすめです
あと未経験の人は研修が充実しててもその後が充実してるとは限らないからそういうのを売りにしてるところには行かないほうが良いと思います
私の場合はその両方が充実してなかったが
そう思いながら目が覚めた
そう、これは夢だったのだ
これらは夢オチ・フィクションなので実在する出来事・人物・団体ではないということを文末ながらお詫びしたい
この話をしたらハロワでおっさんに同情されて喫煙所で20分くらい話した
レッドブルは飲み過ぎると肝臓に良くないよと注意されたので先日の健康診断で肝臓が炎症を起こしてたのはそれかと納得したのであった
日本においては文理問わず広く雇用を受け入れている業種であり、コンピュータサイエンスを初めとする情報工学の一切に精通しておらずとも就業が容易である。また、システムインテグレーターを筆頭として、そうした者でもＳＥ（エス・イー）と呼ぶ習慣が浸透しており、エンジニアというサイバーな印象を想起させることで職業のイメージアップを図ることに成功している。 そのため2008年現在、情報工学の修得を避けつつも技術者という肩書きを手軽に獲得したい者、あるいは情報工学の修得に失敗した者が心のより所として、システムインテグレーターへの就職を妥協して受け入れる傾向が強い。 業界全体の傾向として、同業界においてはしばしば「コミュニケーション能力こそが重要」と啓蒙されている。システムインテグレーターで要求されるコミュニケーション能力の水準は、他業種と比較した場合でも特別、高いものが要求されているわけではないが、前述のような学生が就職後に劣等意識を抱かぬよう、技術力の低さを補うための代替スキルとしてこうした言葉をあえて担ぐといった手法が取られている。 技術的な能力の有無は、ある対象の個々の要素を「知っている・知らない」の二分法から導き出せるケースも多く、そうした技術的な知識の修得には時間がかかるため、学生時代にこれを十分に満たせなかった者への救済手段として「コミュニケーション能力こそが重要」だと説き、これを能力開発の上位に置く企業も少なくない。
富士通、NEC、日立製作所、東芝、三菱電機などのコンピュータメーカーの情報処理部門から独立した会社、またはそのメーカー傘下に入った会社。メーカー製品と組み合わせたソリューションの提案に強みがある。主に親会社から、開発案件を元請額の八掛け程度の額で受注して開発を行う。70年代からバブル期にかけての過剰な雇用によって後年、技術者のだぶつきが発生し、こうした社員への業務をあてがう目的で日経BPやアイティメディアなどの情報媒体を利用し「システムインテグレーターもエンジニアの業務」、「情報産業の花形」と業界ぐるみで盛り立て、モチベーションを維持する手法が取られている。
上述の企業はシステム構築のプロジェクトにおいて商流の上位に位置する傾向が高く、そうした経緯であてがわれてきた、本来行き場の無かった社員が進行の指揮を執るケースも少なくなく、しばしばプロジェクトの破綻をきたしているのが実情である。
