  |
はてなキーワード: SIerとは
まだまだ一部のエンジニアにとって、という話だよね。
少なくとも英語の読み書きができないと最新のテクノロジー情報をキャッチアップできないとか、stackoverflow読めなくて問題解決できないとか、オープンソースにコントリビュートできないとか、これはまさにその通りだよな。オレもオレなりに英語力の不足を痛感する機会は腐るほどある。
でも日本にいる80万人以上のITエンジニアのうち、そうした能力を必要とされないエンジニアがこの日本の大部分だ。
なぜならSIerみたいな受託開発・運営がソフトウェア業界の売上高6兆ぐらいのうち半分以上で、かつ彼らの大部分は日本語ドキュメントが充実してる枯れきった技術を使い続けるから。
枯れた技術で安定性を担保ってのはわかるが、公式のサポートが終わってるJava4~6,PHP5.0~5.3を使ってんだよ。保守じゃなくて新規案件だよ。COBOL,アセンブラみたいな化石言語を保守し続けるところもあるがあれはもっと別の世界から来たナニカって感じだな。そっちはよく知らん。
オレは新卒で入った受託ソフトハウスや大手SIerで計8年働いて、6年ぐらいはwebアプリのプログラマ・SEとして色んな現場みたが、オレも含め一緒に仕事する人は誰も英語なんて求められてなかった。英語読むより怪しいExcel仕様書なりソースコードのコメント読むなり顧客のメール読むなりして汲み取るのが大事だし、コーディングで困ったら日本語でググればまずヒットする問題ばかり。
コーディングで英語を使うと可読性が下がるから変数名・メソッド名・データベースのテーブルやカラム名もヘボン式ローマ字表記で書けってわけ。顧客マスタは「KOKYAKU_MASUTA」だし、担当者は「TANTOUSHA」と「TANTOSYA」で表記ゆれ、笑えるよな。
とにかく言いたかったのは、docker1.12だとかRails5だとか機械学習の新しいフレームワークだとかそういう話題でワイワイやってる層とはまったく別の層がいて、そいつらに英語は全く必要ないしこれから先の何年も求められずにやっていくだろうっていうこと。
悲しい愚痴、以上。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが，この記事もその反論記事・支援記事も含めて，「ウォーターフォールを採用する（せざるを得ない）理由」について書いてあるものはあっても，「ウォーターフォールのメリット」について書かれた記事が見当たらないのには驚く。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
まずこの記事。「メリットはない」って言ってるんだから，書いてないのは当然なのかもしれないが，アジャイルのメリット＝なぜアジャイルがいいのか，についても書かれていない。これではFUDといわれてもしかたない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
「日本でアジャイルが流行らない理由」≒日本でウォーターフォールが採用される（消極的な）理由は書いてあるが，ウォーターフォールのメリットについては書かれていない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
タイトルから期待して読んだが，「ウォーターフォールの課題と言われてるものは，実は解決されてるよ」という記述が大半を占める。
最後の一節は「アジャイルの問題」として，「変化に人間がついていけない」点が挙げられていて，その裏返しでウォーターフォールがいいよ，ってことを言いたいのかもしれない。しかし，アジャイルは「変化に機敏に対処する」ことが眼目であって，何でもかんでも変化させなければいけない，というものではないので，指摘自体が的外れに見える。
http://arclamp.hatenablog.com/entry/2016/06/23/172941
冒頭，
とあって，メリットを語ってくれるかな，と期待させるが，結局「スコープが確定しているならウォーターフォールでいい」，という消極的な採用理由が述べられるだけで，メリット＝積極的な採用理由は述べられていないように見える。
それを語る前に，まずウォーターフォールを定義しておく。現在日本でウォーターフォールとして認識されているプロセスは，国防総省式の「戻りの線」なしのものである。即ち，確定した要件なり仕様なり（以下まとめて「スコープ」と呼ぶ）は変更しない。「ウォーターフォール」という名前自体が，この一方向性に由来している。従って，ウォーターフォールの定義としては，「（フェーズゲートを超える際に）確定したスコープは変更しないプロセス」で良いだろう。
この定義に沿わないプロセスは，「偽ウォーターフォール」であり，以下に述べるウォーターフォールのメリットを受けることはできない。メリットを享受できないだけでなく，この種の「偽ウォーターフォール」は（「偽アジャイル」同様）大きな害悪を撒き散らす。
さて，「確定した要件・仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが，手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者／受注者含め何がうれしいのか。
答は
である。
すごく当たり前のことなのだが，これが書かれている記事が見当たらない。
そしてウォーターフォールのメリットはこれだけで，それ以外にはメリットと言えるものはおそらく存在しない。
ここで，前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。
よく見るとこれらは，いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく，本来の意味での「品質」，即ち利用者の役に立つか，使いやすいか，ということまで含むものである。スクラム（アジャイル）を知る人であれば，「トレードオフ・スライダー」の「品質」に相当するものだと理解してもらえればよい。
そうすると，前節のウォーターフォールのメリットは，以下のように言い換えることが可能である。
「ウォーターフォールのメリットは＜品質を固定することで＞コストと納期がぶれるリスクを小さくできる点にある」
これで問題が明らかになった。要するにウォーターフォールは，コストと納期のために品質を二の次にするプロセスなのである。
その結果，これまでどんなことが起きてきたか。
開発の途中で，要件や仕様に問題が見つかったとしても，あくまでウォーターフォールの定義に殉じると，出来上がるのは「使いにくい」「使われない」システムである。
「事業会社をIT会社に転生させることが、これからのSIerのミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に，その実例らしきものがでてくる。
これを行った瞬間から，ウォーターフォールはその（ほぼ）唯一のメリットを失い，混沌が始まる。
最も多いパターンは，発注者側が（もはやスコープ＝品質を固定するという前提が失われているにも関わらず）納期とコストの確定というメリットの享受を譲らず，プロジェクトがデスマーチ化する，というものであろう。あるいは，コストは譲るが納期は譲らない，というパターンの方が多いかもしれないが，いずれにせよデスマーチ化につながりやすいことは間違いない。
そしてこの副作用として何が起きたかというと，受注者側がそれを見越して納期とコストにバッファを積むようになった。当然それは見積もりの不透明感につながり，発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。
スコープの変更の必要が生じたら，どちらに転んでもいい結果は得られない。となると，ウォーターフォールがうまくいくのは，「スコープが明白で，変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので，そのような案件がどの程度あるかはわからないが，直感的には「ほとんどない」のではないかと思う。なぜなら，そこまでスコープが明白であれば，今はパッケージやSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。
もう一つの可能性としては，スコープが変更不要になるまで，とにかく事前の準備と調査を徹底的に行う，というパターンもありうる。しかし，これは「準備と調査」の過程で事実上いろいろ試作することになる（そうしないと変更のリスクが消せない）ので，もはや作業プロセスの大半が実はウォーターフォールではない，ということになるだろう。
ではアジャイルのプロセスを導入すれば，これらの問題はすべて解決するか，というとそういう話ではない。ウォーターフォールにメリットが（ほとんど）ないことと，アジャイルが有効であることとは，独立な議論である。
そもそも「アジャイル」というのは考え方であってプロセスではない。だから，考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって，害悪を撒き散らすことが多い。
アジャイルの考え方は，主に以下の2点でウォーターフォールと大きく異なる。
1. スコープの変化がありうることを前提としている
2. スコープ＝品質＝役に立つこと（＝使えないものを作らないこと）が最優先であり，そのためにコストや納期が変化を（ある程度）受け入れる
この考え方こそアジャイルの本質であって，CI/CDやDevOpsなどは，変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし，CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。
また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために，スコープはできるだけ確定する努力をする，というのはアジャイルでも変わらない。変えるべき時は変える，という点が違うだけだ。なんでも後で決めればいい／変えてもいい，というのは「偽アジャイル」であって，害悪でしかない。
もちろんこれがあれば何もかもが解決する，という類のものでもない。上述の2点があるだけで（少なくとも今のたいていの開発案件において）ウォーターフォールよりマシになりうるとは思われるが，別の問題（例：納期やコストの変化をどう扱うかという問題）も，同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり，これが「納期やコストの変化」と絶望的に相性が悪い。
もっとも，今の「ウォーターフォール」によるソフトウェア開発が，請負契約の成立条件である「契約時にスコープを確定（し，変更しない）」を厳密に守っているわけでもない以上，これだけを理由にアジャイルを否定するのはどうかとも思う。
契約については，IPA等でも取り組みがあるようだが，いずれにせよ契約を行うのは発注者と受注者であり，受注者側だけでどうこうできる問題でもないので，発注者側の意識の変化を期待するしかないかもしれない。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログに対するSIer側からの反応を見て危機感がないよなーと思った。
「ウォータフォールは一切メリットがないので止めておきなさい」っていう言葉のメリットって誰にとってのメリットかっていうのに齟齬がある感じ。
受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。
確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？
実際につくった後で「思ってたんと違う！」と言われても、「要件定義で合意した通りですよね？」と言える仕組みで自分たちがお金を貰えないリスクを抑えてるんでしょ？
だから顧客にとっての価値に言及せずにウォーターフォールにもメリットがあるって言うのはポジショントークじゃないですかね。
そりゃ「ウォーターフォールは一切メリットがない」なんてことはないですよね。SIerにとっては。
ウォーターフォールじゃないと契約できないとか日本の文化があるからアメリカのやり方はなじまないとか言ってて、じゃあその日本に馴染むやり方で価値のあるシステムが組めてるのかっていう。より価値のあるシステムを生み出そうとしてるのかっていう。
そうやって現状に甘えてるばかりで、より価値を生み出せるやり方をするプレイヤーが出現したらどうなるのか、みたいな危機感がないですよね。
知らんけど。
この記事を読んだ。
http://anond.hatelabo.jp/20160619185731
元COBOLエンジニア、現Rubyエンジニアとして増田の記事がどうしても許せなかったので反応してみる。
この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。
汎用系の現場でもRubyの現場でも優秀な人はたくさんいたし。
今では信じられないほどの経験を当時（といっても2年前）はしていた。
改めて今、RubyというかRailsを始めてよかったなーと思う。
いやー、これが一番ひどかったな。
まず静的デバッグ（机上デバッグ）といってコンペアファイル、ソースコード、コンパイルログをそれぞれ紙出しして提出用（クライアント）、リーダー、上司用の3部印刷する。
全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。
そしてインデントもレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。
定規で計るんだよ。半角スペースが5ミリだったっけな。
それで5ミリずれてたら指摘するんだよ。目がつかれたよね。
っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。
これもびっくりだよね。
専属の社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。
ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。
ネットは使えない。現場に入る時も持ち物チェックとかあるしな。
常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。
まだまだあるんだけど、これだけでもひどい現場だったなーって思う。
そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。
Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。
この先もっともっとブラックボックスなフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。
大学時代、これといってやることもないからウェブサイトを作って遊んでいた。
当時はHTML,CSS, JSを書いてレンタルサーバーにおいて表示させて楽しむところから始まった。スポーツのニュースサイトのRSSを読み込んで表示するだけのサイトを作ったりした。しばらくすると、Rubyというプログラミング言語を学びながら、ウェブフレームワークを使って動的なウェブサイトを作ってみた。赤の他人がウェブサイトに書き込みをした時はとても嬉しかった。
バイトをしておらず、金がなく友だちもいなかった。没頭できる唯一の趣味がウェブサイト制作、その周辺のプログラミング作業だった。ネットを検索すれば以下のような「ウェブサイトをつくって大成功」みたいな記事がたくさん見つかる。自分も、バイト代くらいはウェブサイトで稼げないものかと淡い期待を持っていたのだろう。
http://www.itmedia.co.jp/bizid/hitori_index.html
並行して、簡単なTIPSやプログラミングに関する概念の解説みたいなことをブログに書いていた。どちらかといえばそちらのほうが人気を獲得していた。作ったウェブサイトはどれも流行らず、結局閉じることになってしまった。
頭のわるいFラン大学文系人間だった。黒い画面にテキストを打ち込むだけですごいことをしている気分になった。金にならなくても、少しずつ自分のアイデアが形になっていくのが楽しかった。
しばらくして、これといって話題になるようなウェブサイトも作れずに就活の時期を迎えた。一流のIT企業をいくつか落ちて、中規模SIer（１次請け〜２次請けくらいの案件を取り扱う）にSEとして入社した。
仕事が始まると、毎月定まった給料がもらえることに感動した。真面目にバイトしたことなどなく、派遣の単発バイトばかりだったため、まとまった給料をもらえる、そのこと自体に感動した。しかも、いくらか興味のある仕事だ。それはとても嬉しい事だった。
しかし、さらにしばらく経つと、どうも何かがおかしい。ウェブサイトを作っていたときに感じていた楽しさ、没頭感とか全能感といったような類のものが丸っきり無くなっていた。よく、大手のSIerに入社するとコードが書けなくて幻滅するというが、自分が入社したのはプログラムを書く上でとてもいいポジションだった。下請けのマネジメントをする会社でもなく、ブラックな環境でめちゃくちゃな開発体制を強いられるわけでもない。
それなのに、プログラムを書くことに楽しみを感じなくなってしまった。入社当時は休日にプログラムを書いていたが、今ではそれが苦しい作業になってしまっている。なぜなのかわからない。
あの全能感はどこへいったんだ。
企業が持っている開発タスク、チケット化してこれをこなしたら数万円もらえる、みたいなプラットホームがあればいいのに。
フルリモートで出社日決まっていない、ほぼバイトに近い働き方でベンチャー企業と関わったが、すごく良かった。
やったのはサイトのパフォーマンスチューニング。（基本MySQLのインデックス貼っただけだけど…）
・・とは言っても、スタートアップ時などは
作りながらいろいろ思うところや、気付きとかあったりすると思うので、
手触りの感覚でやらねばならぬところがあって（たぶん）
そういうところを重視するには内製化しないといけないのかなー。
すげー優秀なプロデューサーがいて、
開発はCTOが仕事をチケット化してフリーエンジニアに依頼する、
みたいな感じになればいいのになー。
与信があるエンジニアだけにするようにすれば、
品質も保ちつつ開発リソースも柔軟に担保できるみたいな感じにならないかなー。
会員制のクラウドワークスか。
エンジニアの単価はdayで2.5〜4万にしてほしす。
ある程度やってきたエンジニアを上手いこと活用するプラットホーム的なの作ればいいと思うんすよね。
26歳〜39歳ぐらいのイケイケのエンジニアをプールしているみたいな。
経験してきたハイスキル業務をこなす。一回やったから負荷は少ないだろうし。
慣れてきたらエンジニア個人ではなく、エンジニアチームで仕事をこなすようにするとか。
わしは、そういうのがほしい！！！
定職一個持ちつつday 2〜3万の案件をこなして正社員給与＋月でフリー活動24万ぐらいの収入を安定してほしいなー。
社内の技術評価とかよくわからんものに振り回されず、実案件をこなす実力を求めるようになると思うので
いいと思うんだけどなー。
↓ここ！
ベーシックインカム >> 終身雇用 >> 正社員+兼業 >> フリーランス
↑ここ！
終身雇用はやめて正社員制度は生きるけど、稼ぎたい奴はフリーで活動して稼げば、的な。
安定して働きたいやつは正社員としての受け皿があるし、
まあ、もっと金ほしいんだが？ってやつは独立するのかな・・・。
・・・金がほしいある程度経験を積んだ専門職に最適化したく思っただけなので
技術のブレイクスルーを起こすようなそんな奴らに最適化された仕組みはまた別なのかな。
ポスドク的な奴を救う感じの何かもあればいいのにね。
第1位
海外大手支社(Go◯gle, Micros◯ft, Ci◯co等)
勢いもあって楽しそう。高収入。結局は支社で本社ではない。結果を出さなければならない。
第2位
好きな研究に専念できる。頭が良かったりコネがある人が入れるイメージ。
第3位
第4位
下請けに任せて結構楽できそう。好きなことはできないイメージがある。クライアントにヘコヘコ頭を下げてるイメージ。
第5位
メーカ(Sha◯p, So◯y, To◯hiba等)
かつての日本の人気企業。最近は落ち目。いつリストラされるか怯えながら働いているイメージ。入れれば親からすごいと言われる。
第6位
ちゃらそう。溶け込めれば楽しそう。
第7位
ソシャゲ(Cy◯ames, ◯Lab, De◯A, Gr◯e, mi◯i等)
勢いはあるが、流行り廃りが激しいから安定感はない。市場がドメスティック。
第8位
第9位
第10位
相関的には
1＞2＞3＞4＞＞5＞6＞7＞＞＞＞＞8＞9＞＞＞＞10というイメージ。
ただ4,5,6あたりは人によって考え方に差があるイメージ。あと最近の大手SIは研究開発にも力を入れているところが多い気がする。
番外
好きなことできる。高収入。頭が良くないと無理。
http://anond.hatelabo.jp/20160413023627 を見て触発されたので書く。
タイトルのようなことについて、実態というか現実というか、そういうのを当たり障りない範囲で書こうと思う。全ての企業や学生に当てはまるはずはない（むしろかなり偏見や単純化を混ぜてる）けど、参考になれば幸い。
ちなみにトラバ先は研究を志望したという話だけど、本エントリは研究志望というよりは一エンジニア志望向けかも。
あえて定義はしないけど、Github で公開されてるような OSS を使ってます/いじってますとか、LL 使って Web アプリ作ってますとか、アジャイルやらテストコードやら最近主流の手法使ってますとか、そんな感じで捉えていただければ幸い。あるいはメインフレームで COBOL とか周辺機能を全部車輪の再発明してるC言語製アプリとかそういう古い仕事ではない仕事、と捉えてもいいかも。
トラバ先のトラバの言葉を借りると「日本的な旧来型のIT大企業」という感じ。
ITという言葉には色々な意味がある。大手IT企業だとこれが特に広い。もちろん「モダンな開発」も含まれているけれど、そんなの全体のごく一部でしかない。（主観だけど数 % とかじゃないだろうか）
話は少しそれるが、大手IT企業は元々メインフレームなど「化石」で発展してきた経緯がある。何十年以上も昔、コンピュータといえば化石しかなくて（それでも当時は最先端）、それを個人やそこいらの企業では相手にできないような大組織に対して導入してきた。プログラミングの手法やノウハウが十分存在しない時代だったけど、それでもやるしかなくて、幸いにも昔は今ほど不景気ではなかったし人材も豊富だったから人海戦術で何とかなった。
そうやってつくられた化石コードと化石システムは今なお動いているし、時代に合わせてそれなりに機能追加もある。大手IT企業は化石から離れることができない。現代が化石で食べていけるほど甘くない時代だとしても。
そもそも化石に詳しい化石人が現役引退や昇進などによりいなくなったということもあって、実は現状維持ですら大変である。たとえばレガシーで汚い膨大なソースコードを知る者は誰もいない。もちろんネットで調べても答えなど出ないし、IT界隈のコミュニティに頼ったところで知る者はやはりいない。どんなに時間がかかっても読んで、理解するしかない。どんなに時間がかかっても。
以上のような現実があるので、化石のお仕事に新人を割り当てることも普通にあるし、むしろそうなる確率が圧倒的に高い。
大手IT企業にとって新人とは「専門的な技能や経験は無いが、地力(頭の良さ、伸びしろ、根気など)はあるため近い将来使える戦力になる卵」である。
対人コミュニケーションには自信ありますという遊んでばっかのリア充も、OSS に Contribute してました大学はほとんどパソコンと向き合ってましたという趣味グラマも、同じ「新人」でしかない。
「新人」は技能も経験もないので、いきなり一人前の仕事を任されることはない。電話応対、飲み会の企画運営など雑用全般を任されつつ、簡単な仕事がアサインされる。
この簡単な仕事というのが曲者で、手順書にしたがって環境を整えるとかテストをするとか、そういう仕事だ。手順書を読める程度のIT知識があれば誰でもできる。でもボリュームは多いし、手順書は不完全で不正確だからわからないところが多々あって、忙しい先輩や上司に何度も相談しにいくことになる。言うなれば「属人性の高い単調な手作業仕事」とでも言えようか。
ITを知らない素人新人ならこれが仕事だと抵抗なく受け入れられるが、ITを知る新人だったら、これはとてつもない苦痛だろう。配属先が「モダンな開発」を行う部署であれば苦痛具合も軽減されるし、なんなら「君結構詳しいんだね。じゃあ早速本格的な仕事任せてみようかな」なんてこともありえる。化石部署だとそんなことはない。だって、仕事で扱ってるシステムは化石だからモダンなIT知識なんて役に立たないもの。
この「新人」に、早くて数ヶ月、遅くて数年耐えると、次第に仕事を任せてもらえるようになる。設計やコーディングといった、エンジニアらしい仕事だ。といっても、配属先が化石部署であれば、当然扱うのも化石なわけで、いつまでたっても化石で苦しみ続けることになる。
一方で化石部署から異動し、「モダンな開発」を行う部署で働く者も存在する。これには色んなパターンがあるが、おおよそ以下のような状況が重なって異動するパターンが多い気がする。
大手IT企業では エンジニア→中間管理職(部長以下)→偉い人(部長より上) というキャリアパスがつくられている。特徴は
こんな感じ。
いつまでもエンジニアとして働いて、でも給料はそれなりにもらって、ということはありえない。成果を出せば昇進するし、昇進すればエンジニアから離れていく。成果を出さなければエンジニアとしていれるけど、いつまでたっても給料は増えない。大手だけあって新人時点での給料はそこそこ良いけれど、30代以上になってくるとそれでも苦しい(物欲無き健康的一人暮らしなら問題無いが、家族を養うつもりなら相当苦しい)し、そもそも無能な管理職に振り回されることに対して苛立つだろう。つまりエンジニアとして何十年も働き続けにくい。
「昇進するつもりだから問題無し」と考えている人も要注意である。というのも、大手IT企業は管理職で溢れかえっているからだ。新人が昇進するのは非常に難しい。昔は割と誰でもなれていたし、実際「こんな奴がなんで管理職になれてんだ？」っておっさんもたくさんいるけれど、今は違う。一握りの社畜（必死に仕事に食らいついてきた＆先輩や上司からのウケも良い）だけが昇進できる。たとえエンジニアとして優秀な仕事をし、正当な意見を主張してきたとしても、空気を読んでウケの良い社畜にならなければ昇進はできないのである。
大手IT企業の研究所は非常に狭き門である。トラバ先でも言及されているが、博士課程を終えたようなガチさに加え、当然のことながら学歴も必要になってくる。実際、研究所の人間は英語を当たり前に読み書きできたり、分厚い技術書を躊躇なく読み込んだりするような変態であり、裏を返せばそれほどの実力と熱意がなければやっていけない世界というわけで。とにかく多少ITに覚えのある凡人が入れる場所ではない。
また、入社後に研究所に異動するケースもほとんど無い。一般部署の凡人をわざわざ引き入れる理由が無いからだ。
ここまで色々書いたが、そもそもなぜ大手IT企業を目指すのか。それは以下のような理由や期待があるからではないか。
確かに上記のメリットはある。あるけれど、ここまで書いたように
といったこともあるわけで。
「モダンな仕事をバリバリしたいならベンチャー行け」という話もあるけれど、ベンチャーで通用するほどの人材ならそもそも大企業を選ぶことに悩みなどしないだろう。大企業を選ぶということは、実力なり待遇なり何かを求めているわけで、そうなってくると大企業以上に適切な選択肢は無い。でも、その大企業にも上記のデメリットがあるわけで。
世の中は甘くないですね。
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。UIの共通化は？出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな！みんなモチベ低い！
ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ！！周知しよ、難癖つけられそう笑
追記 : 2015/08/22
でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。
よく技術者と営業の対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。
営業はキツイよなー、成果出なきゃやり甲斐が生まれないでしょ。
追記 : 2015/08/24
この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。
「一生面倒みる覚悟がないなら助けるな」
大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。
追記 : 2015/08/26
面談。褒められた。評価評価うるせぇ。評価＝給料だからあんま興味ねーよそこには。給料で転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身の経営者がいる会社に入りたかったなほんとに。
っかangularjsすごいいいなと。双方向データバインディングとHTML拡張。フロントと完全分離出来るのがあつい。
追記:2015/09/07
夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱な会社始まり。
僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい（近々、エグいの書く）。まぁ、回避したから問題ないけどさ。
追記:2015/09/16
ちょー出世した。事業責任者的な感じ。給料もめっちゃあがる。転職して半年、プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときにゴリ押し回避の方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。
これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。
追記:2015/09/30
今日、いろいろ発表された。なんか抜擢されたからおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手（俺も）。ちょっとガッカリ。自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代はスーパーエリートばかりなのになんかおかしいと思った。
もうasp mvc飽きたなー。angular楽しいからまだいいけど。
最近はrailsが楽しい！ちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ！但し、サイトいつ出来るかなー。
追記:2015/10/15
やっぱ感情的な人はあんまり好きじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしいからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議。
っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかんと人間的におかしくなるね。
追記:2015/10/19
いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ。調子乗ってたら激安家賃の家にすまねーだろぅがよぅ！
って感じで愚痴はこれまで。
つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラムの本質を突いていてjsも馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。
追記:2015/12/07
好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。
追記:2016/02/11
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。UIの共通化は？出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな！みんなモチベ低い！
ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ！！周知しよ、難癖つけられそう笑
追記 : 2015/08/22
でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。
よく技術者と営業の対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。
営業はキツイよなー、成果出なきゃやり甲斐が生まれないでしょ。
追記 : 2015/08/24
この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。
「一生面倒みる覚悟がないなら助けるな」
大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。
追記 : 2015/08/26
面談。褒められた。評価評価うるせぇ。評価＝給料だからあんま興味ねーよそこには。給料で転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身の経営者がいる会社に入りたかったなほんとに。
っかangularjsすごいいいなと。双方向データバインディングとHTML拡張。フロントと完全分離出来るのがあつい。
追記:2015/09/07
夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱な会社始まり。
僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい（近々、エグいの書く）。まぁ、回避したから問題ないけどさ。
追記:2015/09/16
ちょー出世した。事業責任者的な感じ。給料もめっちゃあがる。転職して半年、プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときにゴリ押し回避の方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。
これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。
追記:2015/09/30
今日、いろいろ発表された。なんか抜擢されたからおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手（俺も）。ちょっとガッカリ。自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代はスーパーエリートばかりなのになんかおかしいと思った。
もうasp mvc飽きたなー。angular楽しいからまだいいけど。
最近はrailsが楽しい！ちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ！但し、サイトいつ出来るかなー。
追記:2015/10/15
やっぱ感情的な人はあんまり好きじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしいからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議。
っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかんと人間的におかしくなるね。
追記:2015/10/19
いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ。調子乗ってたら激安家賃の家にすまねーだろぅがよぅ！
って感じで愚痴はこれまで。
つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラムの本質を突いていてjsも馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。
追記:2015/12/07
好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。
追記:2016/02/11
ジコブンセキ
は？ゼミもバイトもサークルもボランティアも旅行もやってないんだが。エピソードは何でもいい？じゃあもっとクソみたいな体験で文例載せろよボケ。
あれもしかしなくても自分ってダメ人間なのか？そもそも働くことが向いてない結論に至る。
もう何回書いたかわからない。一つ文字を間違えると初めからやり直さなければならない。手書きで長文を書くというのは現代人にはつらい。似たような、でも少し違うことを書くのは気をつかう。これ前の会社の志望動機じゃん死ね。
しかしこれは前時代的に見えるが、書かれている文字から相手の性格や人格までもがまるわかりになるという高機能なものなので侮れない。
どこの説明会に言っても念仏のように唱えている。セイチョウしないと死んでしまうの？私はもう死んでいるのか。
ナイテイ
まだ自分はこの目で見たことがなく、本当に存在するのかも疑わしい物。どうやらとても幸せなものらしいが、自分にはわからぬ。ただこの言葉を聞くたびに心が痛む。ちなみに前にナイが付く私のものは偽物らしい。
シャカイ
SIerはブラック。日本はブラック。パワハラ、サビザン、リストラ、カロウシ。
シャカイというところは魑魅魍魎が蔓延り、普通の人々は精神を病んで脱落していき、悪鬼になられば生き残れない恐ろしいところらしい。そんなところに入らなければならない自らの宿命を呪う。
オイノリ
ケンショウやらゴカツヤクとはそんなにも何回も祈られればならないものなのか。時間差で攻撃を受けるのが地味な嫌がらせだ。１週間ほどと言って翌日にはオイノリされたり、全く忘れたころにオイノリされる。命中率100％なのは仕様？回避コマンド求む。
続く？
ビジネスモデルの違いが大きいよね。
サービス開発は、沢山の人にプログラムを使い続けてもらうことで収益を上げるモデル。
SI開発は、作ったプログラムで業務効率化をはかり人件費を節約して収益を上げるモデル。
なので
サービス開発は、利用者が魅力を感じるために改善し続ける必要があり、継続投資に意味がある。
UIの改善、パフォーマンスの改善、接続数のスケール、セキュリティ、他社サービスとの接続、各種デバイスへの対応などなど。
早くローンチが重要な場合もあるので、まずベータで出してブラッシュアップさせてVer1.0を目指すことも可能。
受注業務で１０人が電話やFAX応対してたのをWeb化、自動化して３人で回せるようにする。
営業が残業して顧客情報をExcelで管理してたのを一元化して残業代を削減する。
とかとか。
なので開発予算が最初に決まるし、継続的に高いお金をかけて改善していく意味もほとんどない。
（システム導入時のようなコストインパクトを改善では出すのが難しい）
素敵なUIにする必要はないし、少しくらい応答が遅くても問題ない。「運用でカバー」だ。
オーダーメイドなので開発費は高くなる上に
継続的に改善しないので、導入時点でVer1.0どころか、2.0、3.0 の機能を求められる場合もある。
そりゃ保守的になる。
枯れた技術・設計がいいし、少しでも安いエンジニアを使いたくなる。
設計の手戻りは許されないので、顧客との調整力、フェーズごとに仕切れる段取り力、「ここまでしかやらない」と言える交渉力
決められた作業を決められた期間に決められたコストで実行するマネジメントが重要になる。
プログラムは自社フレームワーク化して、コーディングをパターン化していくこと。
新規サービス開発で求められるような技術力は基本的に不要だし、技術動向は一部のR＆D部門の数名が研究していればOKな世界。
マイナンバーやeTax関連でも、クラウドサービス化して「利用者が増えれば収益が上がるモデル」になってるところは
高い技術力の人がいて頑張ってるんじゃないですかね〜
SIer=技術力無い、Excel管理だけって思い込みもどうかと思うけど
メーカー系の研究部門には技術屋が揃ってるし、新しい技術も当たり前に取り入れてるよ
まあ博士じゃないと配属されなかったりするけど
