  |
はてなキーワード: Siとは
C「よう久しぶりだな兄弟。この前、海洋プレートごとマントルに引き込まれて以来だから、かれこれ7000万年ぶりか？」
H「再会するときはダイアモンドになっているんじゃなかったのか」
C「うっさい。地上でナメクジ共のうんこになりまくるよりはマシだい」
P「ガスになって脱出するチャンスがあるCはまだ恵まれている……」
N「俺なんて、せいしが入ってきたせいで、おならになったと思ったら、今度はせいしが出て行っておしっこだぞ」
C13「お前らはまだいいよ。あいつら何度も何度も短期間で俺のことを使い回しやがって……」
H「熱帯雨林のC同位体か」（上層で電離して宇宙に飛ばされそうになったとは言いにくい雰囲気だな）
C13「チクショーメ！」
C12・C13・元C14「「偽乳はだまってろ」」
O「うるさあい！！おまえら全員デトックスしてやる！うんこになるより肛門になるほうがつらいんだぞ」
なんと自宅に居る時間は5時間だけ？継続してたらデスマーチよ。
法律守って作業者が自宅に9時間いられるようにマネジメントするのがお仕事。
（鎮火の初動は、終電まで働かせといて健康管理は自己責任とか言う人の排除から）
というわけで、みずほ銀行が最近また話題になったので、振り返ってみよう。
で、記憶に新しい2011年の東日本大震災システムトラブルの影響で、
システム刷新して再発防止するぜ！というのが2012年スタートの話。
みずほコーポレート銀行にみずほ銀行が吸収合併されて、
はい、クソメンドクサイですね。
しっかし、この合併って超ややこしくて
とか並べると、ウワー関わりたくね－って判るでしょ。
今のみずほ銀行は、旧みずほコーポレート銀行なので、旧富士銀行なのね。
法人格（法律上の会社人格）も、SWIFTコード（世界的な銀行識別番号）も、旧富士銀行のを使ってる。
でも、日本国内で使う統一金融機関コードは、旧みずほ銀行で、旧第一勧業銀行で、旧第一銀行なのね。
なぜなら、旧第一銀行の統一金融機関コードは0001で、旧富士銀行が0003だから。
しかも、元みずほコーポレートたる興銀は企業向けメインで、元みずほ銀行は個人向けがメイン。
AKBと宝塚歌劇団が合併したみたいなもんスよ。そりゃ一歩も引かないわな。
という政治的決着を経て、
外向けに儲かってるところは興銀の日立
（全銀システムはそもそも開発保守をずっとNTTデータがやってるんで、そこしかやるところがないという）
そして三菱東京UFJ銀行の開発はちゃんと終わりました。あそこも無茶やりました。
旧UFJは派閥抗争で完全に疲弊しきった所を、天下の三菱御三家、東京三菱銀行が救済しました。
だから、旧UFJ系（日立）は「実利で残した」という形で、東京三菱側(IBM)が完全にコントロールしてた。
主導権が完全に旧東京三菱側にあるので、旧UFJ(旧三和銀行)がなんか言っても鼻で笑われるレベルね。
つまり、クライアント（依頼主）側の命令系統がキッチリしてるかどうかが全て。
家を建てる時にさ、大工と左官職人と配管職人とガラス屋と設備屋が居るから完成しないとか、無いでしょ。
それぞれの職人にそれぞれの指示をして、結果として一つの建物ができるのはそんなに珍しく無い。
（もちろんちゃんと連携しとかないと穴空いてないから換気扇付けられんとかあるんだけど）
だもんで、日本IBMのプロジェクトマネージャーに全権委任して、組み直せば終わるよ。
みずほ銀行内の揉め事は、全部林さんがOK／NG決めて、IBMのPMが采配して進める。
要は、クライアント（依頼主）側の意思統一ができていないのが一番の問題。
これは、ベンダーがーとか多重請負構造がーとか、そういう問題じゃない。
第一勧業銀行と富士銀行と日本興業銀行の合併が終わってないのが問題。
（外面の話じゃなくて、内部的に一つにまとまってるかってことね）
自社もまともにできてないのにSIとか臍が茶を沸かすぜ。
みんなコダワルねぇ。
ヤヤコシイということだけ判ればエエのに。
とするじゃろ
/*合併前の法人格リスト 第一勧業銀行, 富士銀行, 日本興業銀行*/
社名変更(みずほ銀行, 吸収合併(吸収合併(第一勧業銀行, 会社分割（富士銀行, 富士リテール）), 吸収合併(新規設立(みずほ統合準備銀行), 会社分割(日本興業銀行, 興銀リテール))))
社名変更(みずほコーポレート銀行, 吸収合併(富士銀行, 日本興業銀行))
社名変更(みずほ銀行, 吸収合併(みずほコーポレート銀行, みずほ銀行))
第一勧業銀行が第一銀行から来てることは知らなくて良いなんてコメントは甘い甘い。
日本では古いほうがエライ。それは実にシンプルに帰属意識や誇りに結びつく。
今をときめく日本銀行よりも第一銀行(第一国立銀行)の方がエライのよ。
よしもと新喜劇とAKBと宝塚歌劇団が合併したみたいな話に例えると
「じゃあそれで」
「えぇ……」
「しないだろJK」「含めるに決まってるだろ？」「千秋楽だけ生花は衣装扱いで」
「えぇ……」
「どうかな？公演の日取りは決まってるけど」
「「「おおむね順調です！」」」
（三行で正確に知りたいってのは業腹ってもんだ）
コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある（特徴のない言語は廃れていく）。
あまり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。
なお、取り上げるのはある程度広く使われている言語に限りたいと思う。
| 言語名 | 概要 |
|---|---|
| C言語 | 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグ出やすい |
| C++ | マニアック言語、高速、習得大変 |
| Java | サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる |
| C# | 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語 |
| Perl | 広く使われていたが今は若干時代遅れのスプリクト言語。汚い |
| Python | Perlにかわって主流になりつつあるスクリプト言語。綺麗 |
| PHP | Web開発にフォーカスされたスクリプト言語。一世を風靡した。 |
| Ruby | とても綺麗なスクリプト言語 |
| JavaScript | ブラウザで実行出来る唯一の言語。言語自体はいまいちだが、ブラウザの事情で需要あり |
| Go | サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語 |
メモリに直接アクセスして書き換えるといったコンピュータの機械語に近い言語構文を持つため、高速な処理が可能な言語。
コンパイラの歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語。
一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディングの効率が良くなく、多種多様のバグを生みやすい側面も持つ。
ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。
C言語にオブジェクト指向を導入した言語。C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。
C言語の速度を維持したままオブジェクト指向やテンプレートなどの効率的な記述を可能にしようとした意気は真っ当だったのだが、
当時最先端だった色々な技術や思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。
「C++を理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。
速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。
サーバサイドで安全にコードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。
当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリの解放忘れというバグを生まず、
サーバサイドなどで何千時間と動作するソフトウェアに適した言語として受け入れられた。
必然的にエンタープライズ用途で利用されることが多く、各種ツールなども豊富。人海戦術がしやすい言語という側面も出てきた。
一方でブラウザにHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。
ガラケーのアプリや（ちょっと違うが）Androidなど、クライアントサイドでも使われることがある。
プログラミング言語で最初にJavaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。
クライアントサイドで安全にコードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。
元々はWindowsのクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。
マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。
Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。
自作のゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。
ほぼ全てのLinux系ディストリビューションに含まれており、ツールや様々な用途で使われていた。
上に紹介したC、C++、Java、C#のようなコンパイル言語とは違い、（少し語弊はあるが）1行ずつ実行してエラーがあれば止まるスクリプト言語である。
ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインのコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である。
20年近く前にWebでCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。
しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存のコードもどんどん別の言語に置き換えられていることが多い。
日本の大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。
後発のスプリクト言語。こちらもほぼ全てのLinux系ディストリビューションに含まれており、それゆえに広く使われている。
インデントまで言語仕様で規定することで、誰が書いても読みやすいコードになるように考えられている言語である。
Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。
ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。
最近だとマシンラーニング系のライブラリでPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。
Web開発に特化したスクリプト言語。CGIの代わりに使われ始め、一世を風靡した。
以前CGIでWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。
またphp.netの豊富なドキュメント＆スニペットのおかげもあり、開発初期の効率が大変に良い言語である。
残念なことに、言語やAPIの設計がいけていない点が多く、一部の人からは蛇蝎の如く嫌われている。
今でも根強い人気があり、海外でも小規模プロジェクトの最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。
Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。
なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。
綺麗なスクリプト言語。日本発で世界的に普及している数少ないIT技術の一つ。
言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWeb用フレームワークの登場で、Webアプリでの採用例も一気に増えている。
基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである。
スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語。
サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。
一方で、なぜかRubyが採用するWeb側のフレームワーク（具体的にはprototype.jsやCoffeeScript）はいつもクソなので、そちらは深入りしないのが吉。
ブラウザで動くスプリクト言語。ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語。
言語としてはプロトタイプベースのオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。
言語仕様がイマイチで、大変バグを生みやすい言語であり、また関数のスタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが
ブラウザで動く言語が現在これしかないので、大きなシェアを持っている。
一部の物好きがサーバサイドでこの言語を使おうと（主にnode.jsで）四苦八苦している（とはいえ、1つの言語でWebとサーバが完結するのは大きなメリットだ）。
ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。
まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。
Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である。
最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsでサーバサイドもできるしで、意外とオススメだったりする。
C、C++やJavaと同じでコンパイル言語。サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語。
その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。
それ以外の目的ではあまりこの言語を採用するメリットはないが、ニッチな用途をピンポイントで抑えており、これから広く利用されることも期待される。
コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである。
繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。
ここに挙げた言語は何らかの特徴があり、何らかの用途で必要なので生き残っている。
その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。
さぁさぁ、増田のみなさん！クソ雑魚ナメってますか？二段ジャンプってますか？
アナルパァぁああああーーーール！をケツに突っ込んで普及活動に勤しんでますか？
そ・こ・で！
はてな随一のサービスと謳われるはてな匿名ダイアリーの2016年ブックマーク数ランキングを発表したいと思いまーーーす！！！
| 順位 | ブクマ数 | 投稿日 | タイトル |
|---|---|---|---|
| 1位 | 2598users | 3月31日 | お坊さんをお呼びした家族葬(D.I.Y.葬)が総額42,360円で完璧に出来たお話 |
| 2位 | 2596 users | 6月16日 | 我が家のインドカレー |
| 3位 | 2203 users | 2月15日 | 保育園落ちた日本死ね！！！ |
| 4位 | 1976 users | 2月18日 | 保育園の第一志望受かったけどやっぱり日本死ね |
| 5位 | 1838 users | 5月31日 | リフォーム業者の営業が仕組みや値段について書くよ |
| 6位 | 1522 users | 1月 2日 | １日１０時間の勉強を半年続けた |
| 7位 | 1504 users | 1月23日 | SIはやめておけ |
| 8位 | 1478users | 1月18日 | 35年勉めて幹部もやった会社を辞めることになったので、愚痴る。 |
| 9位 | 1238 users | 4月13日 | 富士通を退職した話 |
| 10位 | 1168 users | 6月 2日 | 留置場入った日本死ね！！！ |
| 11位 | 1116 users | 4月24日 | 富士通を退職して思うこと |
| 12位 | 1047 users | 5月30日 | 船員さんが足りなすぎてたぶん日本は死にます。 |
※本ランキングは2016年に投稿された増田で、6月30日時点でブクマ数が1000を超えているものを掲載しています。
さぁさぁ2016年増田ブクマ数ランキング！大方の予想を覆してTOPを飾ったのはー！
D.I.Y.葬！！D.I.Y葬です！！！
2016年TOP増田を飾ると予想されていた保育園落ちた日本死ね！！！を追い越しD.I.Y葬がTOPに躍り出ました！！
やはり葬儀を4万で済ませられる魅力にはブックマーカーも勝てなかったか！？
そして2位、2位はこれまた保育園落ちた日本死ね！！！ではなく
TOPのD.I.Y葬との差は本ランキング集計時点でたったの2ブックマーク！
たかだか半月前に投稿された増田にも関わらず猛烈な勢いを見せています！！
やはり増田といったらウンコ！ウンコといったらカレー！鯖よりもインドか！！！？
国会に取り上げられたというアドバンテージを以ってしてもライフハック系の増田には歯が立たなかったか！？
しかししかし、3位に陥落してもその影響力は健在！日本死系の増田が以降のランキングに3件も続いております！
～・～・～・～
(以降のランキングの発表につきましては都合上割愛させていただきます。各人、トラバ・ブクマにて思い思いに盛り上がり下さい)
～・～・～・～
最高例を持ち出すのは卑怯かも知れないが。
エンジニアで年収４ケタってどうやったらなれるの？稼いでる人に聞いてきた
https://codeiq.jp/magazine/2016/06/42239/
こういう例は、一般公務員には無いから。ダメなSIじゃなくて、ちゃんと仕事が身に付くいい会社に入って自分を研鑽して自分を高く売れる人なら、公務員より夢があるし、世界に出ていけるチャンスもあるし、プログラマ悪くないと思うけどね。
SI界の最底辺職業という意味でのプログラマなら、夢が無いにも程があると思うが。その中でも頭角を現せる人もいるから、あとは本人次第って所もあるだろうけど。
ttp://anond.hatelabo.jp/20160102221820 1526 users
SIはやめておけ
ttp://anond.hatelabo.jp/20160123131828 1520 users
35年勉めて幹部もやった会社を辞めることになったので、愚痴る。
ttp://anond.hatelabo.jp/20160118000740 1479 users
ttp://anond.hatelabo.jp/20160218153103 1979 users
お坊さんをお呼びした家族葬(D.I.Y.葬)が総額42,360円で完璧に出来たお話
ttp://anond.hatelabo.jp/20160331150720 2604 users
ttp://anond.hatelabo.jp/20160424135253 1098 users
ttp://anond.hatelabo.jp/20160413023627 1242 users
ttp://anond.hatelabo.jp/20160531150129 1817 users
まいとしだいたいこんなもん
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
第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は研究開発にも力を入れているところが多い気がする。
番外
好きなことできる。高収入。頭が良くないと無理。
「富士通を退職した話」を読んで、20年近く努めている側からの感想と疑問について書いてみたいと思います。
私も、情報科学を大学時代専攻した後、新人で山奥というかむしろ雲の上にある天空の工場に勤務してメインフレーム関連の仕事をしていました。
その工場に配属される新人は（希望すれば）寮に入るわけですが、高専卒は工場の敷地内にある山頂の寮で二人部屋、学士卒は山の５合目にあるアパートの一人部屋、修士とドクターは街中にあるマンションという感じでした。
街中の下界から工場がある天上界への通勤はバスで移動することになるのですが、わたしは、バスのディーゼルエンジンの排気ガスが苦手なので、頼み込んで工場の敷地内にある寮にしてほしいと願い出て、山頂の寮に特別に入れてもらいました。そもそもが２人で一部屋なのですが、学歴の関係か私は一人で２人部屋を使わせてもらっていたため、ものすごく広々と部屋が使えました。
わりと頼み込めば、人事や勤労も柔軟に対応してくれる会社という印象です。
２０年前でさえ、メインフレームは古いというイメージがありました。
ただ、私は古臭い部署に配属されたことは不幸とは思いませんでした。電話からスーパーコンピュータまで幅広く扱っている世界でも稀な会社に入ったからには、いろんなことを経験してみたい。
そのためには、そろそろ絶滅してしまいそうなメインフレームを今経験せずにいつ経験出来るのか？くらいな感じでむしろラッキーくらいに考えていました。
最新の流行を追いかけるのもそれはそれで面白いが、そういったものは出来合いのライブラリを組み合わせて流行を少し遅れて追っていく２位集団であるし、やりたければ個人で家でも出来るじゃないか程度の感覚です。
ただ、せっかくメインフレームの部署に来たのですが、私の担当はワークステーションで動作するUNIXやPCでの開発が主体でした。
そもそもが、メインフレームを扱っていた部署ですから、先輩の人達はあまりUNIXやPCに詳しくなかったので、大学でUNIXやPCを経験した新人が入ってきたことは非常に重宝されました。
その部署では開発言語は、社内の独自の言語（Cよりもさらに機械語に近い言語をマウスでグラフィカルに操作してコーディングする言語）を使っていました。もともとはメインフレーム用の言語なのですが、UNIXワークステーションやPC用にも
その言語コンパイラはあり、あわやその言語でUNIXの開発する羽目になりそうだったのですが、私は猛烈に反対して自分の意見を通しました。当時はJavaやRubyなどの言語は無くCが全盛でしたが、
その部署の開発メンバーはCをほとんど知らなかったのです。そこで、社内のカイゼン活動として、C言語の勉強会を開くことを提案し私が講師になってC言語をメンバーに習得してもらい、
PCやUNIXでの開発は独自言語ではなくC言語を利用することを認めさせました。
元の増田の方は、自分はエクセルのVBAソースが見れない立場のようだと言っていましたが、ソースをみようとしたらシートにロックがかかっていたのを見て諦めてしまったのではないでしょうか？
元のEXCELを使った業務が非効率であるならば、業務の改善活動として提案すれば、それを拒む上司というのはちょっと考えにくいです。
忙しい部署にも、改善活動のノルマが課せられるのですが、先輩はそういったことに関わっている時間が中々取れないので新人がそういった仕事をやると宣言しても拒むのはまずありえません。
下請けのプログラマーからみると富士通のような会社は中間搾取していて高給をとっているのに、仕事は丸投げという印象があるでしょうが、実際やってみると案外大変です。
私は、富士通本社のSE的な立場、グループ孫会社に出向して、そこから顧客先に派遣される４次受け５次受けのプログラマ両方を経験しましたが、はっきりと下請けの方が精神的に楽と感じました。
客商売や、自分でやっているわけではない人に依頼した仕事について、責任をとるのは非常に苦しいものがあります。そもそもプログラミングはとても楽しいというのもありますが。
私見ている範囲では違う部署に異動したいという希望は100％通りました。異動を希望しているのにその部が解散するまでその部署にいる羽目になった人など見たことがないです。
もちろん、「プロジェクトが佳境で君に今抜けてしまわれては困る」というケースはあるのですが、IT業界のプロジェクトの開発周期は年々短くなる一方ですから、割と早い段階で異動の希望は通る感じです。
もとの増田の方は巨大プロジェクトだったので大量の人がいるわけですが、こういった部署は異動の希望は通りやすいです。
なぜなら、新規プロジェクトで最も忙しいときは大量の人員を動員しているわけですが、バージョン２、バージョン３あるいはメンテナンスのフェーズに入ればそんなに大量の人員は必要がないので、会社としてもその部署の人員を異動させたいわけです。
けれど、プロジェクトで中核の技術を担っているようなメンバー、マイホームを天上界に立ててしまったメンバー、新しい仕事に対応しにくい高齢のメンバーは異動させにくいので、
EXCELをいじっているだけのような新人は異動の希望が通りやすいのです。
もとの増田も、もう少し我慢していれば希望が通った可能性は極めて高いですが、プロジェクトが佳境でまだ新人で入ったばかりといった状態では、もう少しその部署で頑張れと言われるだろうと思います。
ただし、異動先の都合もありますので、ここから出たいはほぼ１００％通りますが、あそこに行きたいは必ずしも通りません。
今更「京」のスーパーコンピュータをやりたいといっても、人気部署ですし、プロジェクトの最盛期は過ぎているのでその希望が通る可能性は低いでしょう。
色々な部署がある大きな会社では、管理職クラスは頻繁に異動が起こりますから、嫌いな上司はわりと直ぐにいなくなります。小さい会社だとそもそも部署が開発部と人事部と営業部しかないというかんじなので、上司がやめるか自分が辞めるまで、嫌な上司と付き合う羽目になりがちです。
新人研修期間が終わった後、人事の面談のチャンスがあるのですが、そこにはコツがあります。
「おおざっぱにはっきりと希望を言うこと」です。
いちばん最悪なのが、大学での研究を話し、それを活かせる部署に行きたいと話すことです。
人事の人は技術には詳しくないですから、研究内容が最先端であればあるほど、人事の人には通じないです。
キャッシュコヒーレンシが。。とか話すと、「よくわからないけどこの人は基本ソフトウェアに向いているのかな？だったら、自社でOSを開発しているメインフレーム回そう」という感じになってしまいます。
それよりは、人事の人が、会社組織のどの部署に配属すればいいかわかりやすいように、おおざっぱに希望をいうことです。
例えば、
上記のことを強い口調ではっきりというのが良いと思います。
そのうえで、できれば○○製品をやりたいだとか、こういった業種のSEをやりたい等の希望だすと、どの部署に配属すればいいか相手にも伝わり希望が通りやすくなります。
私の同期で入社して新人研修で山奥に配属されたバブル時代の末裔のようなおねーちゃんとか、数人は、割とはっきり希望をいって、下界に戻っていきました。
ビジネスモデルの違いが大きいよね。
サービス開発は、沢山の人にプログラムを使い続けてもらうことで収益を上げるモデル。
SI開発は、作ったプログラムで業務効率化をはかり人件費を節約して収益を上げるモデル。
なので
サービス開発は、利用者が魅力を感じるために改善し続ける必要があり、継続投資に意味がある。
UIの改善、パフォーマンスの改善、接続数のスケール、セキュリティ、他社サービスとの接続、各種デバイスへの対応などなど。
早くローンチが重要な場合もあるので、まずベータで出してブラッシュアップさせてVer1.0を目指すことも可能。
受注業務で１０人が電話やFAX応対してたのをWeb化、自動化して３人で回せるようにする。
営業が残業して顧客情報をExcelで管理してたのを一元化して残業代を削減する。
とかとか。
なので開発予算が最初に決まるし、継続的に高いお金をかけて改善していく意味もほとんどない。
（システム導入時のようなコストインパクトを改善では出すのが難しい）
素敵なUIにする必要はないし、少しくらい応答が遅くても問題ない。「運用でカバー」だ。
オーダーメイドなので開発費は高くなる上に
継続的に改善しないので、導入時点でVer1.0どころか、2.0、3.0 の機能を求められる場合もある。
そりゃ保守的になる。
枯れた技術・設計がいいし、少しでも安いエンジニアを使いたくなる。
設計の手戻りは許されないので、顧客との調整力、フェーズごとに仕切れる段取り力、「ここまでしかやらない」と言える交渉力
決められた作業を決められた期間に決められたコストで実行するマネジメントが重要になる。
プログラムは自社フレームワーク化して、コーディングをパターン化していくこと。
新規サービス開発で求められるような技術力は基本的に不要だし、技術動向は一部のR＆D部門の数名が研究していればOKな世界。
マイナンバーやeTax関連でも、クラウドサービス化して「利用者が増えれば収益が上がるモデル」になってるところは
高い技術力の人がいて頑張ってるんじゃないですかね〜
午後Ⅱ 問題
問１ システム開発プロジェクトにおける要員のマネジメントについて
http://anond.hatelabo.jp/20160413023627
http://nzmoyasystem.hatenablog.com/entry/who_loves_SI
設問ア あなたが携わったシステムインテグレーション業界における特徴、プロジェクト組織体制、要因に期待する能力について800字以内で述べよ。
設問イ 設問アで述べた業務の中に、要因に期待した能力が十分に発揮されていないと認識した事態、立案した対応策とその工夫、及び対応策の実施状況について、800字以上1,600字以内で具体的に述べよ。
設問ウ 設問イで述べた事態について、あなたはどのように評価しているか。今後改善したい点とともに600字以上1,200字以内で述べよ。
富士通入社5年目の自分だが、ちょっと会社の庇護をさせてほしい。彼の求める仕事が会社に存在しなかったわけではない。
弊社、ここ数年、OSSの利活用に猛烈に注力している。有名どころではCloud Foundry参画の話http://www.publickey1.jp/blog/15/26_paas.html、OpenStackへのコントリビュート（リンク先は作為的な抽出なので注意）http://stackalytics.com/?release=all&metric=commits&module=api-site
彼の求める仕事はおそらくあったはずで、彼がその仕事をできなかったのは運（縁）がなかったという話で同情するし、彼の上司はクソだという点にも同意する。（彼の心象にも、富士通への風評的にも、それ以前に人としてよろしくない）
Excel某の話は自分も経験があって、弊社開発の闇。１年目は彼と似たつらい思いもした。そういったことも全部自動化できればよいが、マンパワーで解決してしまいがち。ただ、２年目からは新製品の開発を含めガッツリ開発できたし、今はSIの上流工程を担当させてもらって（苦戦はしてるけど）充実してると感じる。
彼の境遇から辞めたことを批判できないが、面白い未来もあったかもしれないというお話。
今後の彼に幸あらんことを。
大手SI会社なんて基本はシステム開発保険屋としての人材プール。
とにかく人が余るので、使えない人をいかに纏め上げて成果を出せるかがメインストリーム。情報処理系の学位なんか飾りです。
増田の理想を阻害してるのは人材流動性を低下させてる終身雇用制度に因るものが大きいので、終身雇用を頑なに守る組織から離れるのは自然な流れ。
理由は簡単に言ってしまえば自分の目指すキャリアパスとのミスマッチ。
おそらく人事部の書類にも、今頃そんな感じのことが書かれているんだと思う。
なぜ好き好んでそんな会社に入社して、短期間で退職するはめになったのかを書こうと思う。
入社する前は大学の情報系学部に通い、大学院まで進学して専門分野の研究にそれなりに熱意をもって取り組んでいた。
それもあって、同じ分野の研究を企業として行なっている同社に入社しようと考えた。
内定の前後にいくつかの職種のマッチングを行う機会はあり、自分の希望についてはしっかりと主張したつもりだったけれど、
入社して1週間後に告げられた自分の配属先は、山奥の工場でメインフレームを主とするシステムの開発・保守を行う関連会社への出向だった。
当然この決定に対して人事に不服を申し立てたけれど、返ってくる答えはあらかじめ用意してあったような定型文と、「みんな我慢しているからお前も我慢しろ」というお説教だけ。
もちろん、規模の大きい会社だし、全員が希望通りの職種につけるとは思っていたわけではない。
でも、曲がりなりにも現代のIT企業に入社したつもりなのに、20代そこそこの新卒社員が化石みたいなプラットフォームの世話を押し付けられるなんて想像だにしていなかったし、
綺羅びやかな会社説明の資料の中にそんな説明を見た覚えもなかった。
もちろん決定は全く覆らなかったのだけど、その後も思いつくだけの人脈を辿って色々な人に相談して助言を貰い、
せめて担当業務はオープンプラットフォームにしてほしいとか、COBOLは嫌だとか、ついでに可能であれば山奥の工場に押し込まれるのも勘弁してほしいとか、
できる限り主張をしつつ、しばらくの間実際に働いてみてから身の振り方を決めることにした。
それからしばらくの間新入社員研修をこなし（富士通に限らず、いわゆる日本的な大企業は研修期間がやたらに長い）、
そろそろ本格的に業務に携わりたいと思っていた矢先、上司に告げられた自分の担当業務はほかでもない、あの20万人月案件だった。
例によって守秘義務があるので詳しくは書けないのだけれど、業務を行うツールはもちろんMicrosoft Excel。
自分の仕事は言われたとおりにExcelシートに入力し、マクロを実行して成果物となるファイルを吐き出すことだった。
このマクロの挙動はとても怪しいものだったのだけれど、どうやら自分はこのマクロの修正はおろか、ソースを見ることもできない身分らしい。
SIの現場で日々行なわれている業務内容については詳しく知っているわけではなかったけれど、自分のやっていることが著しく非効率的であることだけははっきりとわかった。
そもそも、具体的な配属先については希望とズレがあったにせよ、少なくとも自分は開発職として入社したはずで、SI業務がやりたくてこの会社に来たわけではない。
とどめに「君はオープンプラットフォームでの開発には多少覚えがあるらしいけど、メインフレームではそんなものは役に立たないから。」なんて台詞が飛んできた。
確かに、Excelシートへの入力作業に情報学の修士号なんていらないし、キャッシュコヒーレンシの話なんてオタクの気持ち悪い自分語りみたいなものでしょうね。
結局これが引き金になって、転職を決意した。
しばらくの間働いてみてそれから考えるなんて、とんでもなく愚かなことだとようやく気付いた。
ただ、短い期間ではあるけども世話になった上司と、開発職の社員をSI業務に割り当てざるを得ない状況については自分も一定の理解を示しているつもりだったので、
多少なりとも会社への影響を軽減できればと思い、転職するつもりである旨を早い段階で上司に明かした。結果としてこれが大きな間違いだった。
転職の旨を伝えた週の金曜日、自席に上司から電話があり、「働く気がないならすぐに辞めてもらう」といった調子で一方的に退職日を設定された。
流石にこれは法的にも問題がある行為だと思い、すぐに折り返し電話をかけて抗議し、翌週時間をとって直接話すことになった。
翌週直接話してみると、上司はケロッとした顔で「なんだ、働く気がないわけじゃないんだ、勘違いしてた。じゃあ退職日はいつにする？」なんて聞いてきた。
自分が抗議しなかったらどうするつもりだったんだろう。
幸い、書類上は見栄えのいい学歴と、知人からの紹介と、"多少覚えのある"スキルのおかげで転職には全く困らなかった。
そろそろ就職活動が本格的に始まる頃だけど、今の就活生には是非とも就職先は慎重に選んで、貴重な若い時間を無駄にすることがないようにしてもらいたい。
