  |
はてなキーワード: アーキテクチャとは
Hacker NewsはマイクロソフトのインターンEdge開発者がGoogleがYouTubeで他社製ブラウザの速度を妨害するような細工をしていたと告発。67ブクマを集める。今日GIGAZINEが日本語記事を書いていてそっちも盛況。
https://news.ycombinator.com/item?id=18697824
A Style-Based Generator Architecture for Generative Adversarial Networks に5ブクマ。ブクマした人は興奮していらっしゃる様子。
http://b.hatena.ne.jp/entry/s/arxiv.org/abs/1812.04948
[1812.03651] Serverless Computing: One Step Forward, Two Steps Back に7ブクマ。
PhoronixはLinuxカーネル開発者がインテルの32bitアーキテクチャx32のサポートを止めるか続けるか議論しているという記事に3ブクマ。
NMEはベストアルバムオブザイヤー2018に4ブクマ。100アルバムを紹介。The 1975のアルバムが1位。
https://www.nme.com/blogs/nme-blogs/best-greatest-albums-of-the-year-2018-2419656
WIREDは国際アムネスティにトロール・パトロールというプロジェクトがあって、そこの報告書の紹介に2ブクマ。Twitteは女性を攻撃したり脅したり嫌がらせしたりに我慢を強いられる場所になっていて女性にとっては害毒だという。増田民必読？な記事。
https://www.wired.com/story/amnesty-report-twitter-abuse-women/
PS3は当初独自GPUを予定してたけどうまくいかなくて、nvideaに泣きついて型遅れのGeForce7800GTXを採用することになった
GPU設計が高度化していくなかで5年に一度のばくちをするのは危険な時代になった
そしてPS4はPSの歴史のなかでも異例といえる最初からPCを意識した構成で、PCで良いじゃんみたいなことを言われながらの発売だった
しかし同一品を大量に売るコンシューマーのビジネスモデルはPC的なPS4でも発揮され好調な売れ行きだったわけだ
そんななか、PC界隈が怪しくなっている
ご存知のようにインテルはicelakeの製造に手間取っている
AMDはTMSCに依頼し、7nmのCPUGPUをインテルより先に投入するようだが
7nmの先はあるのか、PCの限界が来るのではないかという意見は多い
一方でシュリンクが限界を迎えようとしている時代に新しい流れが出てきた
この流れに乗ってソニーは自分たちでもう一度CPUGPUを設計段階から開発するなんてことはあり得るんだろうか
まぁありえないだろう
少し前になるが、転職活動の一環で難易度が高いと言われているニュースの会社をリクルーターを通して受けてみた。
SNSや勉強会を通じて、優秀な人材がいることは事前に分かっていたし、勉強会で実際に話してみるとただ有名なだけのエンジニアとは違い、技術にもビジネスにも明るく仕事が出来る事が直ぐに感じ取れたからだ。相手は自分のことなど覚えてはいないと思うが。
時を同じくして同僚も受けていた事が分かり、同僚も辞退をしていたのでどんな感じだったか情報交換を行った。
面接を通してミスマッチが発生しなくて良かったと思っているので、その記録を残してみる。
私のキャリアは、ソフトウェアエンジニアを約10年ほどサーバーサイドのプログラムを多く書いており、十数名規模のマネジメント経験がある。
応募ページを見ると、大量にポジションが無尽蔵に羅列してあり、何が何なのか正直よくわからなかったのでポジションサーチというやつに申し込んだ。
まずここでミスマッチが発生した。先方からはフロントエンド関連のエンジニアのポジションを提案され、戸惑いながらも面接に進んだ。経歴書にはフロントエンドも業務で取り組んでいたと書いたためであろう。なお、面接の前にオンラインで簡単なコーディングテストが行われた。
面接は1日に連続して数人と行うスタイルで、このやり方は初めての体験だった。
最初の人は現場の人だったのであろう。非常に初歩的な事を聞かれた。技術的に深いコミュニケーションが出来ず、少し深ぼった話をすると逆になんですかそれはという反応をされたので、レベルが高くない人なのかと察し適当に流すことにした。
なお、コーディングテストの結果はどうだったのか評価を教えてほしいと伝えると、自分もこの問題はよく分からないからと言われた。一体何のために行っているのかテンションが下がる話である。
次はマネージャーとの面接だった。どういうチームがあるのか組織的な事を説明され、相手の会社のアーキテクチャを説明された。その上でどう改善するかという問題を出された。
こういう面接の方法もあるのかと思いつつ、もし前提がこうであればこう改善したほうが良いという提案を何個かしたが、それはこういう理由で出来ないや、今は忙しくて取り組めないという事を返された。隠れた条件を後付けで出されるので、なんかズレてるなと感じ、組織的な課題を聞いてみたところはぐらかされた。
面接によくある、最後に何か質問はありますか？と問われたときに、面接の中で聞かれたことを逆質問し、その課題にどう取り組むかの意見を聞いたところ、適当な感じに返された。
この時点で微妙な人たちが連続して続いたので、私の中では辞退をしようと決めていたのだが、是非2次面接に進んでほしいという案内を受けた。
てっきり1次と2次を連続してやったと思っていたが、この日に受けたのはどちらも1次面接らしい。
リクルーターには別のポジションで受けたいこと、可能であればもっと優秀な人か勉強会で登壇した人と面接をしたい事を伝えたが後者は叶わなかったので辞退を申し入れた。辞退の理由は、面接した人と一緒に仕事をする事になると心労が絶えない事を直感的に感じ取ってしまったからだ。
同僚はバックエンドというポジションで直接応募しており、情報交換した感じでは面接官は別の人のようだった。
聞いた話なので詳細を書くことは出来ないが、Kubernetesの本に関わっている有名な人が出てきたようだったが、そのプロダクトの話をしても全然詳しくなく、実際にサービスで使っている自分の方が詳しくてがっかりしたそうだ。今取り組んでいるプロダクトの課題や目的、背景を聞いても、よく分からないと返されてしまい、萎えてしまったために辞退した模様。その同僚はフリマの会社も受けており、きちんと分かっている人が出てきたのでそちらに行くらしい。
（この増田は意図的に炎上を起こすことを目的として無断転載を行うものです）
（無断転載元：https://komeda.hatenadiary.jp/entry/2018/10/09/150830）
前置き - 実験IIIについて -
今までにも辛いものがあったでしょうが、今期のそれは今までをはるかに上回るそうです。
「それ」とは、もう皆さんお分かりでしょう。
「 情 報 科 学 実 験 III」 です。
情報科学科の授業の中で、最も辛く過酷な授業と言われています。
実験内容は、静岡大学情報科学科の計算機教育用に開発されたマイクロプロセッサであるSEP-3アーキテクチャの実装、つまりCPUの作成を行うことです。
確かに、実験内容だけを見れば、コンピュータサイエンスが好きな人にとっては、とても楽しそうな授業でしょう。
それは「 レ ポ ー ト 、 教 員 」です。
実験IIIでは某教員による、かなりシビアな指導が行われているらしいです。
深夜２時まで続く発表
地獄の再発表
学生の首根っこを掴んで怒鳴る
学生が一度も習ったことのないことを口頭試問で質問し、答えられないことを立ちっぱなしで1時間以上追求する
私がこれまでに聞いて来た愚痴や某教員の暴挙とも言える行いの数々です。
いやぁ、恐ろしいです。
さながらブラック企業のドス黒業務のようですね。耐えられる気がしません。
ズンドコキャベツ太郎
@toradora_haken
somの口頭試問を受けてないくせにsom3は厳しいけど正論しか言ってないだとか正しい事しか言ってない とか言ってる偽善者が嫌いすぎる
somの口頭試問を受けた上でまだそんなことが言えるならへ〜そういう人がいるんだなで済ませられるけど
https://twitter.com/toradora_haken/status/1010069961295839232
れたすのー
@retasnow_tt
僕だったらいいけど、もう1人の泣き出してしまった女子に「何で泣いてるの?」とか聞いてしまうのは本当にデリカシーがないし早くセクハラで訴えられて欲しい
https://twitter.com/retasnow_tt/status/958024564864270336
これから実験IIIを受ける皆さんは、耐えられると思いますか？我慢できますか？
先輩方は乗り越えてきました。
恐らく、私も、あなたたちも、乗り越えられるでしょう。
乗り越えた先には何が待っているのでしょうか？私たちは何を得られるのでしょうか？
実験IIIを乗り越えたという大きな達成感は得られるでしょう。
実験により培った実装力、仲間と共に切磋琢磨したことによる協調性なども得られるはずです。
膨大な量のレポートを書いたことで得られる文章力は、社会に出てからも活きてくるでしょう。
このようなものが得られるという点では、実験IIIの授業はとても身になるものと言えます。
しかし、です。
某教員がやっていること、アカデミックハラスメントに当たりませんか？？
深夜２時までの発表や、反論を許さない体制、アカハラに刻当するのではと思います。
アカデミックハラスメント（和製英語: academic harassment）とは、大学などの学術機関において、教職員が教育・研究上の権力を濫用し、ほかの構成員に対して不適切で不当な言動を行うことにより、その者に対して修学・教育・研究ないし職務遂行上の不利益を与え、あるいはその修学・教育・研究ないし職務遂行に差し支えるような精神的・身体的損害を与えることを内容とする人格権侵害のことである。
アカデミックハラスメント - Wikipedia より
先ほど箇条書きした項目の中に、アカハラに当たるだろうものがありませんか？
ありますよね...。
（ 教育も度が過ぎればなんとやらってやつですね...）
さあ、このような実験IIIの体制を許しておいて良いのでしょうか？
実験IIIのような強いられた環境の中で学習を行うことは悪影響（私の場合）
コンピュータサイエンスを好きでいたい（実験IIIを受けたら嫌いになりそう）
実験III受講中にアカハラが発生した場合、私は必ずハラスメント報告をしたいと考えています。 (打ち消し線の意図は後ほどほど述べます）
このような考えをお持ちの方が、私以外にもいるはずです。
ですが、ハラスメントの報告はどこに？誰に？いつ？すればいいの？と、報告する気持ちはあっても、どう行動して良いのか、誰に相談して良いのかわからない方もいるでしょう。
そこで、今回は静岡大学におけるハラスメント対策の方法をご紹介します。
ハラスメントとは？
先ほどはアカデミックハラスメントについてのみ紹介をしましたが、複雑な社会が展開される昨今、ハラスメントには様々なものがあります。
その他のハラスメント
それは、「嫌がらせ」です。
ハラスメントは、英語では "harassment "と表記し、人を困らせること、嫌がらせなどと訳します。
嫌がらせとは、
他者に対する発言・行動等が本人の意図には関係なく、相手を不快にさせたり、尊厳を傷つけたり、不利益を与えたり、脅威を与えること
https://www.osaka-med.ac.jp/deps/jinji/harassment/definition.htm
です。
ハラスメント（嫌がらせ）の定義からも某教員がしてきたことはハラスメントに刻当することがわかります。
このようなハラスメントに対して、どのような対策をすることができるでしょうか。
ハラスメント問題は、加害者が無意識に行なっている場合もあり、関係者同士で解決を行うのは難しいと言われています。
ですから、内外部の組織に相談をし、解決を行なってもらうことが一般的です。
静岡大学の学生であれば、まずはその窓口に相談を行うのが正解でしょう。
静岡大学におけるハラスメントの相談窓口は、大きく分けて二つあります。
学内相談窓口は、学内の相談員によるハラスメントの相談を行います。
相談員はプライバシーを固く守り、相談内容の秘密を厳守します。
相談箱を各部局に設置してあり、週一回、相談員が内容の確認をしています。
学外相談窓口は、静岡大学から委託を受けた事業者が、無料で、相談者からの相談を行います。
相談はWeb、電話にて行うことができ、学内相談窓口同様にプライバシーを厳守します。
特に問題がないのであれば、学内相談窓口に相談を行うのが正解でしょう。
学内相談を行う方法は、ハラスメント相談箱にハラスメント申立書を入れるか、相談員に相談を行うかの二つです。
ハラスメント相談を担当する相談員への連絡先は、このページに載っています。
相談員の選び方ですが、馴染みのある先生、学部の先生、事務部の方から選ぶと良いでしょう。
相談箱にはハラスメント申立書を入れる必要がありますが、ハラスメント申立書はこのページからダウンロードすることができます。
おわりに
ハラスメント問題は、自分で解決ができない場合、他人に相談しないと、解決することはできません。
（実験IIIの）ハラスメント問題を解決するために、まずは相談員への連絡、相談箱への投稿をしてみましょう。
（実験IIIで深い傷を負わないためにも、後輩たちに同じような思いをさせないためにも、ハラスメント報告はするべきだと考えます。楽しい実験IIIを、みんなで作っていきましょう！！）
ハラスメント報告をしたいと考えていたのですが...
私は先ほど、ハラスメント報告をするつもりです、と言いました。
しかし、今は静岡大学のハラスメント報告のシステム、と言うよりも、ハラスメント委員会（というよりかは静岡大学）に懐疑の目を持っています。
それは、
「某教員はハラスメント委員会の頭だ。だからハラスメント報告をいくらしても無駄。」という噂を複数確認したからです。
あくまで、噂です。ですから、某教員がハラスメント委員会の頭だということに確証はありません。しかし、報告が意味をなさないというのは強ち間違っていないだろうと考えています。
静岡大学では半期の授業が終わるたびに、授業評価アンケートを実施します。
そのアンケート内では、任意のコメントをすることができ、そのコメント欄を使い実験IIIの体制を変えようと訴えた先輩方が複数いることを確認しました。
ですが、現状はどうでしょう。何も変わっていません。
また、2018/10/10当日、このようなツイートを確認しました。
すが藁
@sgwrch105
· Oct 10, 2018
Replying to @hanko96
柚子ノ樹
@hanko96
研究室変更の時に色々担当者と話したけど、学務教務カウンセラー辺りは理解したうえで手を出せない状況だったから、学内で何とかするの無理っぽい。糞オブ糞
https://twitter.com/hanko96/status/1049991508227584000
やはり、静大内部から実験IIIを変えていくのは無理があるようですね...。
元々は、「静大生にハラスメント報告の仕方を周知し、ハラスメントを受けた人がハラスメント報告をすることで、実験III（その他辛いだけの授業）の体制を変えることができないだろうか」という意図を強く持った文章を書くつもりでした。
しかし、静大当局が動いてくれないのであれば、この文章は意味がありません。
ですから、静大のCS実験IIIの現状が世間に浸透し、静大内部を変えるような強い社会潮流を持ってくれないだろうか...という淡い期待も兼ねてこの文章を書きました。
長くなりましたが、私の根底にある願いは一つです。
コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。
数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。
複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと
いったものができた。
（カプセル化）
アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた
（ブラックボックス化）
複数のクラスやコード、データをひとまとめにするにモジュールができた。
（カプセル化）
プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。
IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。
（ブラックボックス化）
（操作の簡略化）
Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。
ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使の紋章..めっちゃかっこいい)というのがある。
https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador
なにが大使やねんというと、サービスAがサービスBに接続するときにサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。
接続にかかわるもろもろ、回線の監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。
その仕組みがはまる例として
・異なるプログラミング言語だとかフレームワークのサービスを織り交ぜている
という時だそうだ。
ふむふむとうなづきつつ、アンチパターンの方で躓いた。
一つのプログラミング言語しか使ってない場合はメリット内からクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、
Consider the possible impact of including generalized features in the proxy.
For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.
一般的な機能をプロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダー⇒リモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。
冪等ってなに？え、リトライ処理でデメリットが生じることがあるの？(ログインの試行回数とか？)
有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので
ググると、"treasure data"の中の人のブログにたどり着いた。
これだよ！！これが俺が知りたかったことなんだ。ありがてぇありがてぇ。
接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、
接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、
...はぁ、勉強したー!!
なんか書いといたほうがいいような気がしたので書いておく。
なんてところもあれば、中身はARMでLinuxですみたいなところもあるし、その中間でRTOS使ってます。ということもある。
ただ、歴史的経緯として、マイコン制御などと呼ばれていたような時代から組込みソフトウェア開発がはじまって、
時代をくだるにつれて最終製品の機能が高機能化、複雑化するにしたがってソフトウェア開発の規模も比例的に、
あるいは指数関数的に拡大しているわけで、NonOSでアセンブラやCで書くという仕事は相対的に減っている。
(なんせ、ある程度高価格、高付加価値な製品を作らなければ国内メーカーは潰れるしかない)
なので、一番規模が小さいところの仕事はなくなりはしないし、働いている人は食いっぱぐれないとは思うけど、
わざわざ新たに飛び込むのは正直オススメしない。
で、問題は規模の大きい方で、当時マイコン制御をやっていたようなベテランやそれに薫陶を受けた開発者が
「勉強」をせずにこちらの方にコンバートするとどうなるかという話だ。
コンパイラはC++11,C++14であるにもかかわらず、Cもどきのコードを書くし、プロセスは巨大だし、
強烈に古臭いアーキテクチャを擬似的にOS上に構築してしまう。
その結果出現するのは、ひたすら肥大化しアンタッチャブルになったコードと原因不明のバグである。
IoTがどうのこうのなんて言っていても、組み込みが専門じゃない人がラズパイとセンサー買ってきて
一日半あればできるようなことを、ああだこうだやっているようじゃやっぱり生き残る道はないんじゃないかなー。
https://anond.hatelabo.jp/20180909073549
↑で色々思い出したのでうっかり書く。
数年前までメーカで組み込みソフト開発やってた。今はWeb系と呼ばれるところに転職した。
どちらも超大手なので、両親レベルの年齢層でも企業名とかプロダクトの名前を知ってると思う。
元の文をディスってるというよりは、うちはこんな感じだったなーと思い出話と捉えてもらえば。
知らなかった。どういう機器を扱うメーカで人手不足なんだろう。自分が転職活動したときは車載機器メーカの求人がやたら多かった。
ソフト開発が好きでそれを超極めてるというよりは、元々優秀で、ソフト開発はいくつかそこそこできることの一つみたいな人が多かったかな…。
旧帝大以上の人がゴロゴロしてたので、その人達がまったり仕事してるから一見緩く見えたけど
雑魚国立大学出身の自分が120%で戦っても、ゆるふわ系高偏差値大卒の方々に多方面で敵わなかった思い出がある。
自分のいた部署では京大とか九大の人が多かったけど仕事の質速さともに、一生敵う気がしなかった。
web系はそこに比べると大学の難易度と仕事出来る度合いの相関がかなり薄いと思う。理由は良くわからないけど、他のメーカ出身の人の話を聞くと同じ感想を持つみたいだ。
まあそれはたしかに。ただその企業でしか使えないスキルもたくさん伸びる…。
古い体質の企業が多いのであんまりスキルなくても給料は年次で増えてく(ごく一部除いて年収600-650万ぐらいから頭打ちになってくるけど)
1年目で500万ぐらいだったけど5年すぎるとほっといても700万ぐらいになって（ただし残業代含む）
誰でも主任クラスになれてそこまでいくと普通にやってれば800万ぐらいにはなった。子供産むと万単位で月の手当つくし住宅補助もあったし退職金も…。
Web系は給料という面では手当も殆ど無いし、そこを除いた額同士で比較しても普通に低い。同じ額もらおうとすると部長以上級にならないともらえない。
古い企業で労働組合がちゃんと組織されていて、会社と色々バトルしてきた歴史のある企業は、やっぱりベースも高いんだよなと思った。
ごりごり忙しいweb系と違って既婚率高い
組み込みのときは深夜残業とか休日出勤しまくってた。既に色々な人が指摘しているけど試行錯誤とか学習含めて会社でしかできないんだもの。そりゃそうなる。
web系の今は休日出勤殆ど無いけど、緊急対応で電話がかかってくると突発的に対応しなきゃいけないのでそれはそれ。
これは嬉しかった。
組み込み系のよくないところ
最新の開発ツールに触れてたい人が発狂するような古い環境もちらほら。github知名度アンケートやっても知ってるが2割超えないところが大半だと思う。
自分も転職するまでgitとかgithubとか使ったこと無かった人なので…。組み込みのときはsvnだった。
開発部はそこまで酷くなかったけど、評価部隊は評価用のソフトをバージョン管理してなくて悲惨だった。
直接人命を預かる機器に関わったことはないけど、ストレージ系だとバグでユーザデータ消えると大トラブルになるのでレビューは厚めだった。
ソフトウェアの品質が高いかというとそうでも無かったと思う…。レビューで担保できるソフトウェアの品質ってわりと早い段階で頭打ちになると思う。
秘伝のタレ化してるけど長く受け継がれて歴史が証明しているコードには勝てない。
部門によってはコード1行変えるのに部長の承認が必要というところもあったみたいだけど（ダムとか電車とかのインフラ）。
自分のとこは弱電はまああればより良い（特許提案とかしやすいし、マネージャクラスは当たり前のように回路やメカや量産の知識も求められるのでHW出身が多かった）けど
担当者レベルならそれこそ担当が違うんでってことで回路のことは回路部隊がやってたし、それで回路担当の評価が良くなることもSW担当の評価が悪くもなることはなかった。
どちらかというとSW担当ならヘネシー＆パターソンの本から重要な部分を抜き出して読んだ程度の計算機アーキテクチャの知識が必要だと思う。
今だとこれ読めば良いんじゃないかな。
ググっても出てこない。社内で作っていうrHWモジュールの開発者は社内に居ることが多いので、やたらドラクエする力がついた。
汎用的なモジュールになると社外のドキュメントを読む必要があるけど、たいてい英語なのでそこは同意。
ただ正確に読んだところで社内外問わず間違えてたり、HWが仕様どおりに動かないことも多かった。
レジスタ設定をするタイミングが超シビアでタイミング合わないとHWがロックするとかデータ失うとか。そんなのばっかり。
それがスキルかと言われると、うーん。転職で活かせそうなところとそうでないところはあると思う。
情報に乏しい状態でとにかくやっつけるスキルは身につくかな…。
店内に入って左端に紙パックやカップ入りのチルド飲料、右端にPETと缶飲料。
「何か冷たいもの飲みたいな」と店内に入った時、店の端から端を往復しなきゃいけない。
これが従来のレイアウトなら、店内に入って突き当たりがPETと缶飲料、角を曲がればチルド飲料、と距離が近かったのに。
それとも、普通のお客さんは来店前にどのタイプの飲料買うか明確に決めてて行ったり来たりが必要なかったりするの？
それとも、こうすると店内の回遊率が上がってついで買いが増える、みたいなデータでもあったりするの？
気になってるの自分だけかと思ったら、ブコメで同様の意見を見かけたので書いてみた。
セブン､1万店で挑む｢売り場大改装｣の勝算 | コンビニ | 東洋経済オンライン | 経済ニュースの新基準パックの飲料は左端、ペットボトルは右端という配置に未だに慣れない。アーキテクチャに沿ってUIを設計したソフトウェアみたいだ。2018/08/18 11:22
noteのテストを兼ねて。実は退職してからすでに1年以上が経過しているのですが、ようやく書きたいことがかけるようになったと思われるのでいまさらながら退職エントリを書いてみることにします。
TL;DR
文章にしてみたら、自分がどういう環境で働きたいかが整理できました。自分の思考を整理する手段として退職エントリはおすすめです。この文章にはそれ以上の価値はありません。
Safe Harbor Statement
ここに書いた内容は僕から見た一方的な内容であり、辞めたひとバイアスがかかっていることをご承知おきください。近しい人が見れば個人が特定できてしまうような記述がありますが、個人や組織を誹謗中傷する意図はありません。
楽天でのおしごと
2011年4月に新卒で入社。ちょうど6年間、金融関連事業を渡り歩きながらWebエンジニアをやってました。お客様に直接向き合うサービスを作る部署なので、開発も運用もやりました。工程でいうと要件定義/設計/実装/テスト/リリースとぜんぶやりました。役割でいうとリードエンジニアっぽい仕事もプロジェクトマネージャもプロダクトマネージャのマネごともやりました。5年目くらいからいわゆる管理職も兼任してました。
謝辞
やめる直前はとにかく退職することに全エネルギーを注いでいたうえ、決意を固めてからは有給消化という名の出社拒否を行っていたので、お世話になったみなさまにはろくに挨拶もせず退職キメてしまいました。すみませんでした。6年間好きなようにやらせていただきました。自由奔放な僕を多岐にわたり支えていただいた皆様には大変感謝しております。ありがとうございました。
現職について
株式会社ディー・エヌ・エーでお世話になっています。相変わらずWebエンジニアです。素晴らしいタレントに囲まれて楽しくすごしています。エンジニアの裁量が大きく、人材に対するリスペクトを感じます。自由なライフスタイルとマッチします。たのしいです。うぇるかむ。
よかったこと
現職での生活を1年やってみて、良かったなと思うこともまぁ少なくなかったので書きます。
面白いことがたくさん起こる
良い意味でアグレッシブな会社なので、思いもよらぬ業務提携がおこったり、わけわからんくらい事業が成長したり、（その逆もあったり、）「その発想はなかった」的な新事業が勃発したりととにかく様々なイベントに満ち溢れています。飽きることはないと思います。
内定式の直後くらいに英語公用語化がうちだされ、「入社日までにTOEICで○○○点とってきてね（とってこないとどうなっても知らんぞ）」的な脅しを人事にかけられました。おかしいな、ドメスティックな会社を選んではいったはずだったんだが・・・英語ができない子だった僕は泣きそうになりましたが、さまざまなバックアップを会社が提供してくれていたように思います。僕が在籍していた頃は英語が一定のラインに達していないと安くはない代償（労基法との兼ね合いどうなってたんだろう?）を支払うことになっていましたが。僕は強要されないと勉強しないタイプなので、結果的に英語スキルを身につけることができたのは良かったと思っています。
福利厚生が圧倒的にすごい
現職もそれなりに規模の大きい会社ですが、比べてみても福利厚生のレベルは圧倒的です。朝昼晩の食事が無償で提供されてました。会社の建物の中にジム・コンビニ・カフェ・マッサージ・クリーニングをはじめそのまま生活できそうな設備が整っています。研修も充実しています。特に、エンジニアにとって魅力的なのは海外カンファレンスに会社のお金で参加できることです。「いいから行け」的にぶっとばされます。
楽天という会社は中にいても自分たちの会社がどんな事業をかかえているのかわからないくらいにたくさんの事業を持っています。ECや金融が有名ですがそれ以外にも大小様々なサービスがあります。新規事業への挑戦も常時おこなわれています。ライフスタイルも開発スタイルも事業ごとにかなり多様性があり、希望すれば社内異動だけでだいたいのやりたいことをかなえることができます。
お給料が高い
いまでいうとインパクトは薄れましたが、僕が入社した頃はかなり高い水準の初任給を出していたように思いますし、その後もありがたいことに高い評価を頂いていたので（同職種・同年代のなかでは）お給料は高かったほうだと思います。
よくなかったこと
主に辞めた理由です。当然にネガティブな内容なので有料にして伏せておきます。楽天に転職を検討している人とか僕の愚痴をよみたい奇特な方向けです。
エンジニアの扱いがよくなかった
これは部署にもよるのでしょうが、僕がいたところではエンジニアの立場が悪かったように思います。たぶん僕の被害妄想です。とはいえ、現職と比べると圧倒的に裁量は小さかったですし、ビジネス職のメンバーとの関係も良くなかったと感じます。なんでもかんでもエンジニアが悪いことにされる傾向にあったり、筋の通らない理不尽な要求にNOといえるような環境ではなかったとは思います。
僕はたいへん素晴らしい上司にめぐまれていました。そのおかげで好き勝手やってこれたのですが、尊敬する上司の仕事は（僕にとっては）つらそうに見えました。自分が将来同じ仕事をやりたいかなと考えると胃がキリキリしてきて絶対イヤだったので。
社内には外国籍メンバーがたくさんいます。日本語がまったくできないやつも一定数います。そんなエンジニアが日本語のサービスを作っています。わからない言語のサービスを作るというのは大変なことです。間違った言葉が書かれていても間違っていることに気づけません。利用規約に間違った記述があった日には大変なことです。英語が公用語なので、英語が使えても評価されないというのはまぁ受け入れましょう。ただ、かわりに日本語が使えることが評価されるかというとそうではありません。ただ単に日本語がわからないやつの代わりに仕事が増えるだけです。ビジネスの人間は日本人ばかりで英語使わないことが多く、調整系のタスクで忙殺されるのが嫌になったので。
システムのインフラは構築はどこの部署にお願いして、rootが必要なDBの操作はまた別などこの部署にお願いして、それが何営業日必要で、とかシステム開発時の制約とか部署またぐ作業のリードタイムがなんぼとかいちいちめんどくさい上に新しいことをやろうとすると面倒なことがたくさんあったので。
僕が最後に携わっていたサービスが世の中に出たのでちょっとみてみたのですが、平成も終わろうとしているのにjQueryバリバリの2000年台初頭構成のWebアプリが完成していました。僕が置いてきたReact＋マイクロサービスなアーキテクチャは無事闇に葬られていました。僕のチームがコミットしていたリリース日よりも10ヶ月遅れのリリースでした。どこからともなくさっそうと現れた「そんな複雑なシステムは運用できない」などとのたまう向上心のなさそうな、他人のアイデアにケチをつけるのがうまいベテラン（？）エンジニアがすべてをひっくり返してしまったようです。（そいつがいかにアレかを13くらいの言葉で説明できるのですが長くなるのでやめておきます）その人物が提示した見積もりは我々がそれまでに費やした工数の3分の1程度だったので、そのとおりに行っていれば去年の夏には終わっていたはずなのですが。そのエンジニアがアレなのは言うまでもないとして、そいつのアレさを見抜けない上長や、IT企業にいながらエンジニアがなにを大事にしているかを理解できずに無茶苦茶な判断をするビジネスの人間に囲まれて仕事をするのが辛くなったので。おかげさまで僕の最後の仕事はその案件で作成したすべてのソースコードの破棄でした。メンバーには申し訳ないことをしました。
退職を決意した最も大きな理由のひとつです。前職最後の人事考課の結果が極めて不満だったので。「どう考えてもこの人達より僕の評価が低いことはないだろう」と思っていた同じ職位の人間よりも評価が低かったうえに、それに対する納得の行く説明も得られなかったので。その当時僕の評価を担当していた上司は非常に管掌が広かったので、いち部下の評価まで細かいことを気にしている場合ではなかったのかもしれませんが。その瞬間この会社に対する信頼は地に落ちました。
半年待ちたくなかった
その後、非公式な場で「評価がまずかったのは申し訳なかった。半年耐えてほしい（※楽天では評価が年2回）」というようなことを何人かの上司から言われましたが、それはつまり「半年待った結果として正当な評価を受けられる」という僕がただ半年間不当な評価を受け入れるだけで、特段メリットがない提案でした。そこに対してどのような補填がなされるかといった説明はなく、耐えた後に得られるものも大したことはなさそうで、しかもそれから半年間の仕事も特段熱意を注げるようなものではなかったので。
朝会という制度がどうしても気に食わなかった
毎週1回（事業によってはそれ以上の頻度で）朝会があります。朝8時からです。そんな時間に起きたくありません。裁量労働だろうがなんだろうが関係ありません。出社しないとどういう扱いを受けるかはここには明言しないでおきます（労基法以下略）。それはヨコにおいておいても朝8時です。内容がつまらないとかではないですが、いちポンコツ社員としては「8時に始まるから7時58分までに出社しなさい」といわれて間に合うように起きることと天秤にかけるほどの重要性が最後まで見いだせなかったので。（というわけで、僕はこの制度が残っている間は絶対に楽天に戻りません。）
応募者に要求している英語のハードルが高い（割に待遇が良くない）ので、優秀な日本人を採用することが極めて難しくなっていたように思います。そのかわり英語はできるけどそれ以外は普通な人物はたくさん応募してきていた印象です。所詮は国内に根ざした企業なので、実務で必要になる英語のレベルはそんなに高くないです。なので英語ができない人のカバーをするのは難しくありませんが、優秀なエンジニアがいないのを何とかするのは極めて困難でした。会社の方針のせいで本当に採用したい人が採用できず、自分が目標にしたいと思える人物・切磋琢磨したいと思える人物が同じ組織に現れず、いろんな意味で先がなさそうだったので。
管理職は向いてなかった
上司からお話を頂いたときは嬉しかったですし、それなりの使命感をもってやっていたつもりでしたが、いま思い返すと管理職の道を選んだのは失策でした。できることは増えましたが当然にやらなくてはいけないことも増えました。僕がやりたいことではありませんでした。とはいえ当時はやりたくないといいだせる状況でもなかった（と思っていました）し、自分のキャリアアップにつながるなら...と打算的なことを考えてもいましたが、僕の考えは甘かったということが後にわかったので。
というようなことを考えていたら働く意欲がなくなったため
以上のような経緯により、それまで持っていたモチベーションが迷子になったので。面白いこともまぁまぁあり、ストレスもある環境でした。「それでも会社が必要としてくれるなら...」と思っていましたが、「お前の代わりなんかいくらでもいるよ」という空気を感じた途端に熱が冷めました。
まとめ
正直、辞めた当時は自分の判断が正しいのかどうかに結構なやみました。勤めていた時はそんなに悪くないと思っていたのですが、現職を経験して思うのはやっぱり楽天はエンジニアがエンジニアリングするのには向いてないということです。社内政治が得意な方にはおすすめです。
windows Mobile用に作られた.Net Frameworkを利用したバイナリならCPUアーキテクチャを問わずにモバイル用のものもPCで実行できたぞ（10年くらい前の話）
と、律儀にマジレスしてみる。
プログラミング言語の範囲で「ある程度他に考え方の転用が効く」という意味なら、
最低でも、OS操作できるスクリプト言語（bash系やWSH+VBScript/JScript, PowerShell等）と、
汎用スクリプト言語（RubyやPython等）もやっておいた方が良いかと。
お仕事で、という話なら言語よりはライブラリの使い方やアーキテクチャへの理解、プロジェクトのルールを守れるようになる、といった事の方が重要になってくるし、
・フロントエンドは流れ早すぎgulpだかなんとかzly とか多くて辛いし、js 嫌いだし、typescript ？、結局同じでしょ。むりー
・おれの主戦場は web アプリだぜ。でも、rails は案件としてはやったことないし、いまから rails やりなくない、php もいまから php7 とか laravel とか追いつけないわ。むりー
・課金とか決済まわりの面倒くさいの、むり。レポートだすのめんどい。何かあったときメンタルつらいし、監査対応？ むりー
・機械学習、数学才能ないし、金かかるし、python3.0 ？ インデントでブロックつくるのあわない。むりー
・アプリ、設計指針多すぎ。クリーンアーキテクチャとか MVVM？ MVP？、むりー
俺はエンジニアなんだけど、なんか詰んでる。メンタルが。むりー
どうしたらいい？
趣味もプログラミングだから何も疑問に感じなかったけど確かに言われてみればそう感じるのも不思議ではないな。
アーキテクチャがどうのこうのみたいな難しい理由もあるんだろうけど、大抵の言語は元々何らかの言語の派生だったり改良版だったりするんだよ。
言語を開発できる能力と影響力がある連中が「この言語のこの仕様がマジでクソ」ってなると、それが言語の改善として提案されることもある。
ただそのプログラミング言語を取り仕切ってる連中とかがその提案を受け入れるかは別で、そうなると別の言語として分裂する。そもそも受け入れられない事を前提にして、最初から「あの言語マジでクソだから俺らが考える最強の言語作った」みたいになることもある。
プログラミング言語って１つにまとまらないんですか？これさえ使えれば全てを扱えるような魔法の言語はどうして存在しないんですか？
どんな言語も「俺らが考える最強の言語作った」っていう感じでスタートしてるせい。結局は好みなわけよ。ある種宗教みたいなもんだ。
例えばRubyっていう言語の仕様が好きで集まった連中がWeb系の人間ばっかりだったら、RubyはWebに向いたノウハウとかツールが集まるようになる。Python教には機械学習や数学に強い奴らが集った結果、そのへんのライブラリが豊富になった。
後からついていく大多数の人間は偉大なる先人がお作りになられたライブラリを活用しないとやっていけないわけで、結果的に「この用途ならこの言語」みたいなのが多数発生するわけだ。
使える言語は増えていくんだよ。意図的に増やしてるんじゃないと思う。
「こういう処理したいけど、俺が使える言語で便利なライブラリないじゃん。じゃああの言語に手を出してみるか」「この仕様クソすぎるんだけどあの言語なら解決できるんじゃね？使ってみるか」みたいなことが往々にしてある。
