  |
はてなキーワード: ibmとは
給与がかなり厳しい故に人材の質も高くなく、あと人がとにかく多く、社屋が暗い
給与がかなり厳しいがどうもトップレベルマネジメントや管理職の品質がいいようで会社としての対応はしっかりしている印象
一方でワーカーは続々流出中とのこと
よく知りません
同社出身の人は鬼のようだったり目がすわっていたりという人が多く、恐ろしい環境だったのでは・・と推察
よく知りません
よく知りません
異様な落ち着きがある。公家でしょうか。儲かっているのかは謎
昔はつらそうというイメージ、今はニュースをはたりと聞かず。どんな会社になったんだろう
一人一人はしっかりしていて良い人なのだが組織がややこしすぎて働くのは大変そう
営業現場はいろいろあるようですが、同社系IT人材は優秀で動きの良い人が多い。やはり激しい環境でふるいにかけられているのでしょうか
総合的には悪い感想だったのですが、良い点と悪い点について書きます。
翻訳を始め、会場の広さやスクリーンなど、キャパに見合ったとても良い会場だった。
やはり国内外からiOSエンジニアがたくさん参加されていたので、普段聞けないような話をたくさん聞けたのは良かった。
特に、日本でユーザ数の多いアプリを手がけているエンジニアの話は貴重で、これだけでも参加した価値はあったと思う。
やはりTry!Swiftとついていることもあって、聞きたかったのはSwiftの話だったが、3割くらい無関係or設計やプロダクトの話だった。
決して勉強にならなかったわけではなかったのだが、前年のTry!Swiftがすごく良かったと聞いていて参加した分、期待外れは大きかった。
また、LTは全く関係ない話でも募集していたかもしれないが、それなら元から予定していたトークの間に挟むなど順番も考えて欲しかった。
特に、そのトークに問題があったわけではないが、一日の最後がLTであることも悪い点の一つだった。
これは特に三日目のハッカソンの際に感じたことだが、どうも内輪で盛り上がって置いてけぼりに感じることが多かった。
また、三日目は一日を通してグダグダだったと言わざるを得ないと思う。
これは違うかもしれないが、この日はアプリ道場の方々がメインで立ち回っていた様に見え、初日・二日目と違った様に思う。
など、あげればきりがないと思った。
名指しして申し訳ないが、今後アプリ道場が運営に関わるイベントは参加しないと思う。
決して安くない参加費を払って参加しているわけなので、少しでも知見を得たかったが、どう見ても価格に合う様な価値は得られなかったと思う。（良い点にも書いた通り、参加した意味がなかったわけではない）
隣の芝生ではないが、次週のDroidKaigi 2017がとても良さそうに見えて、参加費も半分以上違うことからこちらの方に参加すれば良かったと感じる。
遠方から来ている以上どちらも参加は難しく、より興味のあったTry!Swiftを選択したが、その分残念だった。
悪い感想エントリになったが、あくまでも個人の感想であり、全員が全員こういった感想ではないと思う。
で、でんでんででん！
春、春、春！
で、でんでんででん！
春、春、春！
とりあえず、迫り来る何かに追われてるの。
ひょ、ひょっとして
は、春！？
春がやって来るわ！
そして、次から次にやって来る。
迫る初夏！
初夏が来る前に
春がアイルビーバッグと言って
また来年やって来るわ。
そして、また迫り来る初夏！
繰り返されるこのポリリズム！
もう、何回も何回も何回も言ってるけど
この歌好きなのよね。
まあ、そんなもうミニスカなんてガラじゃないけど、
そんなことしたら、
そんな適当なことを言ってたら、
恐るべし春！！！
そう言えば、
あれって、当時IBMの一歩先行くために
ふーん。
そんなことより、
桜が咲くのももうすぐだし楽しみね。
桜餅の葉っぱって食べる派？食べない派？
私は食べてもいいもんだと思ってたわ。
きっと正確なのが導き出せボッシュートされるはずよね。
うふふ。
お店を変えてみたわ。
手軽に歩きながら食べれるのがいいわね。
すいすいすいようび～
今日も頑張りましょう！
皆さまはチームワークがいいと聞くと
「誰かがミスを犯しても、周りのみんなが助ける」
なんて考えるのではなかろうか？
浅薄だな〜、本当のチームワークはそうじゃない。
と思ったあなたは一流。数々の修羅場を乗り越えてきた老練家ですな。
本当にチームワークがいい組織は、
みんなに迷惑がかかるという使命感を背負っている人間が集まっている状態こそ、
チームワークがいいというものだ。
例をあげるとDeNA。チームワークがよろしくない。
チームワークは乱れない。
各々がお互いの力を信じている。
世間的にはDeNAのほうがチームワークが良いと思われがちだが、
じっさいのところはGREEに軍配があがる。
中日と同じで今は低迷しているが、あの手の組織はいつか這い上がる。
それでも任天堂の壁は厚い。ニンテンドウ チームワーク クッキョウナリ
あの映画の中にはチームワークの全てが詰まっている。
シルヴェスター・スタローン、ジェイソン・ステイサム、ジェット・リー、ブルース・ウィリス、シュワルツェネッガーと主演級の俳優が同じチームのメンバーとして登場する。
そして彼らは皆一流。最強のチームワークを誇る。
この名だたる企業コンソーシアムのチームワークは最悪。
https://www.google.co.jp/maps/place/@35.6386097,139.6999833,521a,20y,41.58t/data=!3m1!1e3!4m5!3m4!1s0x60188b48682c837f:0xa07320890573c72c!8m2!3d35.6427516!4d139.6999923
みずほ銀行PJの陣頭指揮を取っているはずのみずほ情報総研、開発拠点は全国にありますがその中でも有数の規模を誇るのがこの中目黒です。
毎日夜遅くまでフロアの電気が付いているそうですが、大変ですね。
Google Mapで見ると室外機が沢山載っている、まるで要塞のような建物が見えると思います。
ここはみずほ銀行のシステムの中核をなすデータセンターの一つです。
IBMのメインフレームが沢山入っていたそうですが、今後はどうなっていくのでしょうか。
ちなみにこの建物、建築業協会賞を受賞しているそうです。かっこいいですしね。
中目黒センターの南にある、駒沢通りに面したちょっと変わった形のビルが秋元ビルです。
ここの数フロアをみずほ情報総研が事務所として借り上げています。
みずほ関連の怪文書で中目黒という単語が出てきた場合、中目黒駅近くのみずほの建物ではなく
秋元ビルと中目黒センターの間には、自販機と灰皿が設置されているのですが
朝の九時頃には首から「MIZUHO」のカードキーを下げた方々が大勢喫煙されています。
どんな立ち話をしているのか、気になりますね。
次回は多摩が出来たらいいですね、では。
なんと自宅に居る時間は5時間だけ？継続してたらデスマーチよ。
法律守って作業者が自宅に9時間いられるようにマネジメントするのがお仕事。
（鎮火の初動は、終電まで働かせといて健康管理は自己責任とか言う人の排除から）
というわけで、みずほ銀行が最近また話題になったので、振り返ってみよう。
で、記憶に新しい2011年の東日本大震災システムトラブルの影響で、
システム刷新して再発防止するぜ！というのが2012年スタートの話。
みずほコーポレート銀行にみずほ銀行が吸収合併されて、
はい、クソメンドクサイですね。
しっかし、この合併って超ややこしくて
とか並べると、ウワー関わりたくね－って判るでしょ。
今のみずほ銀行は、旧みずほコーポレート銀行なので、旧富士銀行なのね。
法人格（法律上の会社人格）も、SWIFTコード（世界的な銀行識別番号）も、旧富士銀行のを使ってる。
でも、日本国内で使う統一金融機関コードは、旧みずほ銀行で、旧第一勧業銀行で、旧第一銀行なのね。
なぜなら、旧第一銀行の統一金融機関コードは0001で、旧富士銀行が0003だから。
しかも、元みずほコーポレートたる興銀は企業向けメインで、元みずほ銀行は個人向けがメイン。
AKBと宝塚歌劇団が合併したみたいなもんスよ。そりゃ一歩も引かないわな。
という政治的決着を経て、
外向けに儲かってるところは興銀の日立
（全銀システムはそもそも開発保守をずっとNTTデータがやってるんで、そこしかやるところがないという）
そして三菱東京UFJ銀行の開発はちゃんと終わりました。あそこも無茶やりました。
旧UFJは派閥抗争で完全に疲弊しきった所を、天下の三菱御三家、東京三菱銀行が救済しました。
だから、旧UFJ系（日立）は「実利で残した」という形で、東京三菱側(IBM)が完全にコントロールしてた。
主導権が完全に旧東京三菱側にあるので、旧UFJ(旧三和銀行)がなんか言っても鼻で笑われるレベルね。
つまり、クライアント（依頼主）側の命令系統がキッチリしてるかどうかが全て。
家を建てる時にさ、大工と左官職人と配管職人とガラス屋と設備屋が居るから完成しないとか、無いでしょ。
それぞれの職人にそれぞれの指示をして、結果として一つの建物ができるのはそんなに珍しく無い。
（もちろんちゃんと連携しとかないと穴空いてないから換気扇付けられんとかあるんだけど）
だもんで、日本IBMのプロジェクトマネージャーに全権委任して、組み直せば終わるよ。
みずほ銀行内の揉め事は、全部林さんがOK／NG決めて、IBMのPMが采配して進める。
要は、クライアント（依頼主）側の意思統一ができていないのが一番の問題。
これは、ベンダーがーとか多重請負構造がーとか、そういう問題じゃない。
第一勧業銀行と富士銀行と日本興業銀行の合併が終わってないのが問題。
（外面の話じゃなくて、内部的に一つにまとまってるかってことね）
自社もまともにできてないのにSIとか臍が茶を沸かすぜ。
みんなコダワルねぇ。
ヤヤコシイということだけ判ればエエのに。
とするじゃろ
/*合併前の法人格リスト 第一勧業銀行, 富士銀行, 日本興業銀行*/
社名変更(みずほ銀行, 吸収合併(吸収合併(第一勧業銀行, 会社分割（富士銀行, 富士リテール）), 吸収合併(新規設立(みずほ統合準備銀行), 会社分割(日本興業銀行, 興銀リテール))))
社名変更(みずほコーポレート銀行, 吸収合併(富士銀行, 日本興業銀行))
社名変更(みずほ銀行, 吸収合併(みずほコーポレート銀行, みずほ銀行))
第一勧業銀行が第一銀行から来てることは知らなくて良いなんてコメントは甘い甘い。
日本では古いほうがエライ。それは実にシンプルに帰属意識や誇りに結びつく。
今をときめく日本銀行よりも第一銀行(第一国立銀行)の方がエライのよ。
よしもと新喜劇とAKBと宝塚歌劇団が合併したみたいな話に例えると
「じゃあそれで」
「えぇ……」
「しないだろJK」「含めるに決まってるだろ？」「千秋楽だけ生花は衣装扱いで」
「えぇ……」
「どうかな？公演の日取りは決まってるけど」
「「「おおむね順調です！」」」
（三行で正確に知りたいってのは業腹ってもんだ）
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
元の話も
「赤ちゃんを同伴してIBMが開催したテクノロジーコンファレンスに参加した」
ってだけだしね。
写真を見る限り赤ちゃんはまだ低月齢（首は座っているが激しく動く事は出来ない、3～6か月くらいと思われる）だし
それくらいで大人しい子なら授乳時間とおむつ替え場所さえ確保出来れば
抱っこでコンファレンスで話を聞くくらいなら出来るさ。
でももっと大きくなれば下に降ろせ動きたいと騒ぎ出すし
下に降ろせば好き勝手に暴れるから親がつきっきりで見てないと無理。当然仕事になんてならない。
言葉で聞こうとするのが間違い。
自分の場合、「自分で調べ物しますか？」客「Yahooとか見るわね」→「いつもYahoo!とか見るソフトを開いてください」→ブラウザ判別が必要な場合「画面右上にはバツ印がありますよね？ その下には何がありますか？」という風に聞く。
Chromeなら「横の三本線」になるし、edgeなら「・・・・」になる。
そういう風に、ブラウザごとに明らかに違う場所を複数覚えておいて、
右上や左上はじといった風に誘導しやすい場所から、見えているものを教えてもらう。
そしたら、向こうは見えているものをいうだけ、それでこっちは何のブラウザか分かる。
もうちょっと頭を使うんや！がんばれ！
http://blog.livedoor.jp/itsoku/archives/47616816.html
とそのブックマーク
http://b.hatena.ne.jp/entry/blog.livedoor.jp/itsoku/archives/47616816.html
をみながら思ったんだ
要約するとアメリカは時給１２万円のコーダーの仕事があるらしい
そんでとうぜんにほんじゃそんなことないという流れで
日本はハードばっかりにこだわってソフト軽視だという（まぁそうだろうね私もそういう印象あるよ）
なぜか、このスレの連中（名前からしてビジネス＋）は、文系のせいにしたり大企業のせいにしたりする
このまとめをまるまる信じるとして思うことがある
一瞬なるほどそうなんですかって話になりかけたが
そしてHPやDELLなどのハードにこだわっていろいろ大変なことになってる会社もあるわけだが
なにが言いたいかって、べつにアメリカもその点では変わらないじゃんってことだよ
じゃあなにが違うのかって
理系がベンチャー立てて、googleみたいな企業立ち上げられるかどうかだよね
それだけの話だよね
そこだけが違う
理系（）がベンチャーでgoogleとかほかのIT企業立ち上げたら話は終わるんだよ。amazonでもいいしoracleでもいいし、あとなにがある？あんましらないけどねｗ
もちろんそれが一番難しくてできないから、理系（）のルサンチマン馬鹿どもは文系のせいにしたり、企業のせいにしたりしてるんだろうけどｗ
アメリカだって恐竜って言われてるGEとかIBMみたいな旧態然とした、大企業ってのもありつつベンチャーでITが盛り上がってるわけだからさ
アメリカ人がGEとかIBMのせいにしてるわけじゃないでしょ（まぁそもそもGEもIBMも利益率かなりいい優良会社だけどね）
ようするに能力のないバカが2chで騒いでるんだろうってことが言いたいんだけど
この２ｃｈまとめみたいにルサンチマンやってるダサい連中じゃなくもっとまっとうな理由ってないのかなって思ったわけですよ
日本にはこういう問題があるんだってのがあるんだったら教えてほしいとおもってね
そもそもなんでこの手の奴らって文系理系でわけるのかね。もっというと理系側がわけたがってるよね。お望み通り理系でわけてやったんだから理系の皆さん返信よろしく
就活の参考にしたい
http://anond.hatelabo.jp/20160123172824
博士号歓迎で独自技術を持っている会社なんて海外にはごろごろあるよね。国際機関とか大学とか除いても。給料八百万円(７万ドル弱)なんて低すぎると思う。
例１ エンジニアより：
MathWorks（Matlab作っている会社）物理モデリングシニアエンジニア
条件：
ー 非線形で相互に接続されたシステムの定常状態および動的状態のモデリングおよび計算技術の経験
ー 工学、数学、コンピュータサイエンスの修士号もしくは博士号取得
例２ SAS institute（分析ソフトウェア世界1位 SASを作っている会社）
http://reviews.greatplacetowork.com/sas
ワークライフセンターには、正社員のソーシャルワーカーが複数在籍しており、さまざまな教育やサービスを従業員とその家族に提供している。図書館を併設。子供の教育、大学、介護、離婚、シングルマザーなどの状況をサポートする社員相互のメンターのネットワークを提供。
フィットネススタジオには、５０メートルプール、エアロビスタジオ、マシーン、バスケットコート、ランニングトラック、ソフトボール場、サッカー場を含む運動施設がある。年に１５００のスポーツプログラムを提供。マッサージサロン、美容室、ネイルケア、スキンケア、ジュエリー修理、靴修理、その他のサービスを割引価格で提供
例３ 研究者より：
Mathematica政策研究所 国際研究者（International Researcher）
条件：
ー 様々な状況で技術的な話を明快に説明するための、極めて優れた英語でのスピーキングおよびライティング能力
私はどちらかというとデータアナリストで、SIの本流から外れるけど、SI本流でもそれこそシリコンバレーとかに技術を持った会社はうじゃうじゃあるんじゃありそう。IBMの研究所とかでもよいだろうし。
久しぶりに『批評空間（ http://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/ ）』を覗いてみたのですよ。
いやぁ～ 昔と変わりませんなぁ。
ノベルゲーだからテクノロジー上の大きなブレイクスルーがないのを割り引いても、ゲーム内容・ファンの意識には往年を偲ばせるものがあります。
まず物語のパターンが古典落語や歌舞伎並にテンプレ化されてるじゃないですか。
パーツの組み合わせが変わってるだけなんですよね。GoogleのDQNやIBMのワトソンでもシナリオ書けそうです。
次、ユーザー層。
ゼロ年代くらいのファン層がまんま繰り上がってオッサンになっている印象を受けます。
発売日の延期、修正パッチをネタにして騒げる人たちなんかは、ワシントン条約で保護すべきでしょう。
エロゲ界隈は真性オタの牙城と言いますか、原理主義者の聖域のままであってほしいですね。
電車男以降、オタクがライト化するのに抗して生まれた"キモオタ"概念が近年ベタになりつつあるのは懸案事項であります。
『オタキング→ダイエットに成功したサブカル博士→家族をシェアするイロモノ』というキャリアを"詰んで"しまった岡田斗司夫には失望しました。
経産省の旗振りのもと、AKBや深夜アニメと一緒に『クール・ジャパン by 秋元康』なんていうプロモーションされたら海外のファンコミュに亡命します。
CTC → A社の発注が 5000万で、B社に丸投げだったら、2500万くらいだろう。
A社のCTCへの見積もりは、見積単価が 120万/人月（ちょっと安いか？）で、40人月くらい。
A社の原価率を85% として、原価が 34人月。
B社の単価を 80万/人月としたら、マックスで 2720万。
多少駆け引きがあって、2400～2500万ってところが妥当では。
・ニトリは内製っぽいけど...
ニヨニヨするとか言われてたページには、こんなコメントが入ってる。
＜!-- Customize for NITORI start--＞
＜!-- Mod for Nitori End --＞
WebSphere をミドルウェアに決めたときに、カスタマイズも発注してたことは十分考えられる。
「これは仕様通りです」とかなんとか、そんなやり取りをいっぱいしたんだろうな...
・ベータ版なんて作らない
ウォーターフォールで一直線。
ニトリ社のレビューというか、受け入れ試験があったとして、そこで出されるのは
完成品、もしくシステムテストがある程度残っている本物。
リニューアルオープンが延期したのは、本当に間に合ってないだけ。
6月1日が延期したのも、ろくに動くようなものじゃなかったんじゃないか。
リニューアル後の性能問題も、何だかんだで一週間で復旧できたわけだし。
・表に出ないだけで...
ふわっとした仕様書を杓子定規に実装した、というよくあるパターンな気がする。
別ウィンドウで表示される「リニューアルオープンの遅れに関するお詫び」にまで販売サイトのヘッダ、フッタがきっちりと表示されている。
http://www.nitori-net.jp/store/ja/ec/%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B6%E6%9C%8823%E6%97%A5
この硬直さもウォーターフォールっぽい。
css がど真ん中に挿入されているのも、さもありなん。
http://anond.hatelabo.jp/20150515014847
で言っている内容はよく分かる。
正直、大阪都構想は賛成反対両方が「民衆（悪く言えば衆愚）」チューンナップされすぎててイマイチだ。
選挙カーで名前を連呼した方が、当選しやすくなる、という例のアレと同じだ。
「絶対反対」と街宣車で連呼したほうが、具体的にデメリットを伝えるよりも、
本当は言葉を尽くしてきちんと説明して、風邪のガキ連れ来た親だの、
毎度毎度やってくる爺婆だのにお引取り願うのが正しいハズだ。
でも、ちょろっと咳止めでも出しときゃ納得する。
今の選挙はそういう状況だ。
お医者さんには、2種類いる。
臨床は、いわば街のお医者さんだ。
人体実験はダメなので、基本的には「前例のある処置をする」エキスパートだ。
病気の新しい診断法や、治療法を発明する。治験と呼ばれる人体実験もする。
もっと言えば、より基礎の研究として、神経細胞の構造を調べたりネズミの皮膚を弄ったりする。
このうち、臨床は、当然患者に対して説明をする。
わかりやすくメリット・デメリットを伝え、決断を促し、場合によってはセカンドオピニオンも勧める。
「マウスの皮膚組織にある線維芽細胞への遺伝子導入法」のメリットを語るのは難しい。
すると、「これは、肺をシャーレで複製して本人の臓器を移植できるような再生医療に繋がるんです！」と資金を勝ち取る必要がある。
結果、iPS細胞が生まれてノーベル賞までとったが、肺の複製は盛り過ぎじゃね？と言われればきっとそうだろう。
たぶん、元増田の言う、「政治は庶民生活へのメリットを判りやすく」は筋が悪いと思う。
その筋を進めていくと「反対！反対！」と街宣カーで叫ぶ情報伝達に繋がる。
たぶん、「どんなに判り難くても良いから、きちんと情報開示して欲しい」じゃないだろうか。
「線維芽細胞への遺伝子導入法」の予算獲得のために「将来の再生医療」を謳うのは仕方が無い。
でも、具体的に何をするか、その結果がどうなるかは、医学者にはある程度目安がつく。
現在の直接投票は、基礎研究医の予算獲得や、基礎研究の方向性を、(医学の知識が無い)病院の出資者が決めている状況じゃないだろうか。
こういう時、金を出す出資者に医学者と同じ知識や、研究のメリットを語っても、恐ろしく遠回りになるだろう。
大抵こういう時は、適切な経験を積んだ医学者のアドバイスがあるはずだ。
たぶん、以下の流れが、必要なことだと思う。
現状、２番がホトンド居ないのが問題なんじゃないんだろうか。
１番と３番（つまり、政策立案者と、民衆）とを直接繋げるのは、双方にとって負荷が高すぎるか、飛躍させすぎないと届かないだろう。
「線維芽細胞への遺伝子導入法（≒ある政策）」に賛成して欲しい時に、
それを「出資者（≒投票者）の直接のメリット」で伝えるというのは難しいのではないか。
それの方向性では、「肺が複製できて、再生医療出来ます！（≒無駄が減って財政破綻しなくなる！）」と言うしか無い。
そしてそれは、確認しようがないし確からしさも確認できない、エビデンスの妥当性が判断できない飛躍になるだろう。
そして、飛躍無く詳細に判りやすくどんなに噛み砕いても、素人に医療の基礎研究の妥当性は判断できない。
そこに必要なのは、医学（≒政治）の知識を持ったアドバイザーじゃないだろうか。
最先端の医学者が出資者の前でプレゼンするのは、なんか違うような気がするんだよなー
どうやっても真摯な研究者は「絶対」を口にしないし、それを約束する山師にプレゼンでは負けちゃうし
そして今の政治は、この「判りやすく伝えろよ」プレッシャーで、山師が跋扈してる気がする。
「良くわからないから反対」というヤツだが、コレかなり強力な「迷信」だと思う。
世の中の物事はたいてい予想通りには行かない。
すると、「やってみても失敗しそうだから反対」は凄く言いやすい。
この意見そのものは正しいことが多い。だってたいていは予想通りに行かないもの。
でも実は、その賛成反対というのは、次の2択だ。
こう置き換えて考えるとわかりやすいだろう。
ここまで明確だと先行きがある程度予想できるので想像しやすいだろうが、
「結婚にメリット・デメリット色々言うヤツがいて正直良くわからん」という質問者に
「明確に自分の生活に対するメリットが見いだせないなら、とりあえず止めたら？」とは言わないだろう。
「よく判らんから、線維芽細胞への遺伝子導入法に予算付けるの無しな」してたら永遠に再生医療は進化しない。
でも、とりあえず何でも賛成してトンデモな研究に予算をつけるのも違うところが難しいんだよねー
開発者のかっこ悪さやルールの範囲内（今回は修正不可ルールがいまいちだったっぽいけど、それを決めたのは対戦相手じゃない）で戦ったプロ棋士への敬意のなさはおいておいて。
IBMスルガ銀行訴訟やマイクロソフトの月次パッチに対する反応の時も少し思ったけど、はてな・Twitter界隈の流れを見る感じプログラム・システムの完璧さへの信仰、それをエンジニアに当然の如く要求する思いが渦巻いているようで純粋に怖い。
将棋なんか局面が10の220乗あり得る（らしい）ので、将棋を適切に行う機能に対するカバレッジ100%の検証を実施せよと言われたらそれをするしかないわけだが当たり前だが出来るわけがない。
工数やシステム投資は絞られるのに責任だけが増大している気がどうしてもする。初版から潜在不良なしのパーフェクトを求められる環境だとすると我々はどうすれば/どのような心持でいればいいんだ？組み込みなんかそれに近いわけだし教えてほしい。
やあ、今日は二回目だよ。
さっき書いた奴はどちらかというと実践的すぎて、つまらなかったかも知れないよね。
前回の記事
http://anond.hatelabo.jp/20150224002209
神のOS LinuxにはWindows界では理解されないエディタについての戦争がある。
vimとEmacsが民主党と共和党みたいな感じで戦っている。
実際に戦って死人も出ているんだ。
2003年には武力闘争にまで発展し、PKOが介入することになったけれども
今はグローバル化して国境なき紛争として、様々な場所で問題を引き起こしている。
それはプログラミング。
刀なのだ。
すべてなのだ。
よって、どのエディタを使うのかはどのようなイデオロギーを持ってそしてどのように戦うか、ハッカーにとってはアイデンティティに関わる重要なこと。
さて、僕はどの立場の人間なのかということを明らかにする時が来たようだね。
僕のハッキングスタイル、コーディングスタイル、そして思想がいま明らかになる。
しかしこれはかなり実践的なデザインで、僕の攻撃スタイルにとてもあっている。
まず、コーディングシートを塗るときに素晴らしい下敷きになる。
２Bの鉛筆で力強く塗っても全く穴があかない下敷き。
かといって硬すぎずクッションのように包んでくれる。
強い武器でいて優しさにあふれている。
やばい！攻撃の途中だがコーディングが間違っていたかも知れない！！
そういう時は素早くジャポニカ学習帳を開く。
ジャポニカ学習帳【じゆうちょう】を開くとそこには真っ白い無地のページが広がっている。
そこに一心不乱に0と1を書く。
０と1を書いて、自分がコーディングシートに示していたアドレスをメモして、どの値を入れていたのかを確認し、順次立ててメモリ空間の二進数がどう変化していくのか書いていくのだ。
機械語は日本語と同じ、九九のように二進数の計算を進めていく。
IBMの研修でもらったフローチャート用定規もつかったりする。
すべてが分かった時に再びコーディングシートに移る。
すべてが終わった。
すぐパンチャーに渡すんだ！
何枚ものコーディングシートをジャポニカ学習帳に挟む！ページを間違えないようにね。
そしてそれをフリスビーのようにパンチャーに投げるんだ。
今回のLenovoのPCの件で、Superfishが仕込まれてるのは基本的にコンシューマー向けの機種だけど、企業でLenovoのPCを買ってるところもいい加減見切りをつけるきっかけになりそうだなぁ。
基幹システムでIBM使ってるところはPCもIBM製使ってるところが多くて、Lenovoに買われてからも引き続きLenovoのPCにしてたところは多いはず。システム会社がIBMの基幹システムを提案してくるならPCもIBM（からのLenovo）で、他の製品持ってないんだよな。
ここ最近のLenovoはほんとに自社ソフトウェアのプリインストールが多くて設定時に消してんだけどほんとめんどい。
