「ポーティング」を含む日記 RSS

はてなキーワード: ポーティングとは

2019-08-10

anond:20190810150839

よくあることですが、

パワハラオヤジ仕事のできない文句の多い派遣さん愛人関係だったんじゃないですか。

そう思うと、職場のレポーティングライン無視した上申とか、一方的な叱責とか、

そもそも仕事ができない人が大きな顔をして職場にいることの理由がはっきりすると思います

2019-02-07

年収950万、もっと稼ぎたい

駆け出しのデータサイエンティストもどきです。34歳。昨年から外資ITにて”データアナリスト”として解析部署採用され、働いています待遇としては年収950万円。額面からみるとかなり恵まれているのは重々承知しているものの、親や家庭の事情があってもっと稼ぎたいと考えています。具体的には40半ばで1500-2000万。ただ、自分スキルセットから鑑みる現在はもらいすぎ、または頭打ちに近いのではないかと思っており焦りを感じています。なのでアドバイスをいただけないかと思いここに投稿してみることに至りました。

もどき”と書いたのは、データ分析経験に乏しいからです。

分析経験

前職では実装まで行う社内コンサル的な業務を6年していました。データをあちこちからもらってエクセル一辺倒(殆どデータ100万行に収まったため)で加工分析インサイトを見つけ施策につなげる等。そこでは高度な統計必要とされず、四則演算にせいぜい大学教養レベル数学までで事足りていました。

企画としては投資回収FSKPI再設定や商流価格体系改善在庫予測適正化システム開発実装に伴う社内外折衝、効果測定。上層へのレポーティングなどなど。内4年間は海外において販社立上げ、地域統括会社での予実管理から現場部隊管理飛び込み営業まで雑多にやっています。ただ、読んでおわかりいただけるように散漫とした経験です。1社目は重電会社での設計を6年していましたが、企業人としてのいろはを除けばこの経験現在ほとんど使われておりません。。。

プログラミング

ほぼできません。遅ればせながら最近始めました。SQLを習い、何て便利なツールなのか!!と感動しながら毎日嬉々としてこねくり回しています幸運にも現在会社にはDWHがあり、すぐに活かすことができていますあんなに加工に苦労していたデータが一瞬で結合・集計されて出てくる快感。。。業務範囲でも需要予測、異常検知などをMLに置換する動きがあり、幸運にも機械学習スクールに通わせていただくことになりました。実務にもすぐ使えそうなのでとても楽しみにしています汎用性のある技術習得することで自身市場価値高まるのではないかと期待しています。ただ軌道にのってもプログラミングがそこそこ使えるようになるまでには少なくとも3-4年かかるのかなあと思っています見積もり甘いでしょうか。そのころには40手前。難しい分野と認識しており、自身能力的に凡庸レベルしか体得できないないし挫折する可能性もあります

さて、冒頭に書いた収入を目指すための選択肢としては①現在会社出世する、②現在データアナリストとしての実力を磨き海外に挑戦、③国内他社へ転職、④起業、⑤副収入先を作るでしょうか。

②は給与が高いアメリカを想定していますしかし、技術力もないし英語もネック。シンガポールでなら何も不便なかったけれども、英語母国語の国で渡り合っていくには非常に厳しいと感じています。(TOEIC970) 1on1ならアメリカ相手でも何時間でも会話できますが、相手が2人以上になると格段に難易度が上がる。。。幼子が2人いる上、海外に挑戦するには年齢もそろそろネックだなあと。シンガポールなら給与的にも実現可能性的にも良いのかもしれません。それ以外ではプログラミングスキルと実績を上げて①か③、というのがある意味王道でしょうか。

そもそも日本におけるデータサイエンティスト給与レンジはこれからの5年10年でどれくらい伸びるでしょうか?アメリカではジュニアレベルで6桁スタートで、チームリーダーなら中央値35万ドルだそうです。夢がある。

https://www.kdnuggets.com/2019/02/data-scientists-expensive-hire.html

一方、次の記事によれば日本では40台で655万程度。信頼性不明ですが現在自身給与から考えるとあまり伸びしろは期待できないように感じてしまます

https://heikinnenshu.jp/it/datascientist.html

少しでも増やすために、雇われ以外の副業も考えてはいますがなんとなく踏み出せていない状況です。まとまってない文章すみません

2018-10-12

anond:20181012181047

もともと日本企業で働いていたけど、家族関係EUに来ました。

MSc日本で取っているけど、働いている中でもっと学びたいことができたので、冬学期からまずはnon-degree studentとして通っています

こっちの人は大学授業料無料なのが羨ましいけど、EU外の人にとっても日本大学に比べて格安授業料なのがありがたいですね。

私はオーストリアにいるので基本ドイツ語の授業が多いけれど、ERASMUSで他の国から学生も多いからか、英語の授業も多く、学生先生英語が通じるので助かっています

私が日本で通っていた大学にはこんなにも多くの英語講義がなかったので、日本に来る留学生はとても大変だったんだなぁと思います

中国自然科学系については詳しくわかりませんが、調査対象地域として中国をやられている方は、現地調査収集データの取扱について中国政府から色々言われることが大変だと言っていました。

生物化学実験系の分野だけかもしれませんが、オーストリア大学院生と日本大学院生を比べると、日本大学院のほうが、修論実験に対して重きをおいたカリキュラムになっているように感じますオーストリア場合は、大学院に入っても研究室にいるより授業に出ている方が長いように見受けられます。前述の通り、講義といっても学生に対してプレゼンや何かプロダクトを作ったりレポーティングにより評価することが多いので、こちらの学生の方が自分の成果を表現する能力が高くなるように感じます。一方、日本大学院ではゼミ実験が重視されているため、実験操作や実務能力に重きをおいているように感じます

私としては、今の時点でどちらが大学院のあり方として優れているかはよくわかりません。

日本からたことのない学生は、研究に対して保守的になりがちなので、あなた日本学生生活を過ごしたことがない場合、戸惑いがあるかもしれません。

私が学部生で研究室を決める際、先輩から、「いくら有名な先生研究室でも、実態は違うかもしれないから、研究室訪問をして、本当に自分がそこで一緒に研究したい人たちがいるか基準にしたほうがいい」と言われました。

有名な先生資金調達がうまく、予算が潤沢にあるかもしれないが、学生指導を全くしない先生もいます

いい研究室が見つかるといいですね。

2018-09-24

anond:20180915214027

NEC研究提案会議テーマリーダープレゼンを行い、研究所長と中央研究所長が審査するものです。件の研究テーマも、江村氏の責任の下で承認されたもののはずで、それを「まだ~」という発言は極めて無責任だと感じました(私もその場にいました)。また、私がその分野に明るくないことを差し引いても、当時の技術水準であの研究テーマは極めて先端性を有しており、今後20年間のSIビジネスをけん引できる可能性に満ちているものだっと思います。それこそ、「企業の基幹システムAWSマイグレーションNEC見積もりも含め、一番仕事が早く、安心感がある」、というようなステータスにすることは可能だったと思います。江村氏はCTOになる以前は、常々からNECSIをもうやりません」と公言していましたが、NECSIビジネスレベニューの増大は不可能でも、規模としてのシュリンクが非常に困難です。そのため、最低限のSIビジネスをやっている人たちが、それで食っていくための武器必要です。特に外部リソース活用が不得手なNECにとって、NEC発の技術なのかどうか、非常に大きな意味をもっています。私がかかわるところでは、顔認識世界でみれば3流ですが、それでもNECであることを最重要視して商流に乗せています

専門性をもってビジョンを示すことは研究者として重要であることには同意しますが、それは提案を聞く姿勢がある場合に限っていえることです。江村氏の経営では、「わからんから却下、再提案」ということが横行していました。その分野のビジネス判断として事業部ネゴシエーションテーマリーダは実施してニーズ特定し、ビジネスチャンスを示すこと。そしてリスク要因として将来そのビジネスを取り巻く環境変化を示しても、江村氏はそれらを理解できず、却下することがしばしばありました。無論、配下研究所長がリーダーシップを発揮し、責任をもって推進する、と援護があれば進むこともありますが、NECではそのようなリーダーシップをはぐくむことは不可能でしょう。なぜならNECリーダーは、自身責任明確化しないまま、YesともNoとも言わずに、上位のポジションが空くのを待つことが基本姿勢からです。結果、研究者が優れた業績を上げればそのウマに乗ってポイントを得るし、却下した研究テーマで他社が優れたポジションを獲得しても、そのテーマ投資しなくて正解だった、などと宣うのです。

また、CTOブログ言語道断な内容という主張についても、元の増田同意です。研究資金獲得において、江村氏の発言は全く参考になりえません。資金投入の考え方として、客観指標主観指標の2つの側面があります。まず、エビデンス世界情勢への理解といった点で、客観指標としてガートナーレポートに遥かに劣ります。一方、主観指標として役に立つかといえば、意思決定として、NECが注力すべき研究テーマもぼやけており、責任をもって推進する、という姿勢は全く見えません。元の増田氏は江村氏をIT音痴と評していましたが、私はそれに加えてビジネス音痴でもあると思っています。江村氏が重要視し、集中投資したすべてのテーマ競争優位性を確保することができていません(劣化診断や農業ICT、そして漏水検知は試験プレスは出ているのに、正式に導入されたプレスは出ていないことからもわかります)。それを踏まえれば、キャピタリストとしてのCTOに対する評価は、落第も良いところかと思います。それでも江村氏がそのポジションについていることは、単に大チョンボやらかし研究出身の國尾氏の後釜という意味合い以上のものはないでしょう。

先日の増田以来、研究所内でも重役に対する評価が変わってきたことは喜ばしい点でもありますリーダーシップを発揮しようとしない所長に対するレポーティングは省力化を優先するようになりました。彼らはビジネスを動かすことも、資金調達することも存在感を発揮できないだろう、という見方が強まってきています。この、影響力がない仕事コストを下げようという試みが機能するかどうかは、彼らのプライド次第という面もありますが、うまくいかなければ転職しよう、という現場の考え方が出始めているように感じています

そうしたきっかけをつくってくれた元増田氏には最大限感謝と、そして今後のご活躍を祈念しております

2011-10-18

Steve Yegge の Googleプラットフォームに関するぶっちゃけ話を訳した(前編)

Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html

記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。

2011/10/19 08:14)ありがたい誤訳の指摘をいただいたので3カ所修正

Stevey の Google プラットフォームぶっちゃけ

僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは(しかもその印象は日々強まるのだけれど)、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。

まり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほかバカにしに行くんでもなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベース悲惨のものエンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。

公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシン情報RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。

僕が思うにその pubsub システムライブラリ管理システムが、まさに AmazonGoogle より優れている三つのうちの二つだ。

早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかもしれない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。

でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。

Jeff Bezos悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイト理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。

マイクロマネジメントAmazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色ポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通コントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。

それであるJeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。

彼の巨大な指令はこんな感じだった。

1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータ機能を公開すること。

2)各チームは各々そのインターフェースを通じて通信しなければならない。

3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデルバックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。

4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。

5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界デベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。

6)そうしない者は解雇される。

7)ありがとう!良い一日を!

ハハ!。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。

それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal(ごにょごにょ)Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢インターフェース」という言葉連呼する男だった。 Rick は歩き回り、「堅牢インターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。

それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなものインディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。

  • ポケベル通知( pager escalation )はどんどん難しくなった。だってチケットの本当の持ち主がわかるのに、20回は行ったり来たりしないとならなかった。もしあるチームからの一回の応答に15分かかったとしたら、正しいチームがそれを受け取るまでに何時間もかかってしまう。たくさんの前準備と測定としっかりしたレポーティングをやるようになった。

とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。

中編に続く

2011-04-08

Javaを使ったプログラミング言語

最近Scala信者が増えたが、ScalaGroovyClojure仕事している人はいるのだろうか?

Java比較してライブラリが増えるわけでもなく、応用分野が増えるわけでもなく、良さが理解できない。

検索順位人気順言語登場年特徴
1位95位Scala2003年Java関数型言語の特徴を組み込んだ。
2位71位Groovy2003年Javaより少ない記述量が特徴。
3位-Jython1997年Python 2系のポーティング
4位-JRuby2001年Rubyポーティング
5位-Clojure2007年Lisp方言、つまり関数型言語
6位75位JavaFX Script2008年JavaFXを残して廃棄処分。
 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん