英語化の弊害 2012-10-03 - 未来のいつか/hyoshiokの日記
タイムラインに英語化の弊害とかいうのが流れて来て『デキル人がダメ人間に見える』みたいなのを目撃する。 そーゆーのあるよなーとか思う。 でも、日本という地域でデキルと思われていても、世界に出るとガラパゴスってのはよくある話で、結局だめなんじゃんということか。身も蓋もない話で救いがないなー。 とか思ったのだが、この気持ちを精密に言語化できないので、推敲なしに脳内の思いをだだ漏れしてみる。 わたしの英語の原体験はDECとかOracleとか米国系企業の日本法人に勤めていたころにさかのぼる。DEC時代も米国本社に出向する機会はあったのだけど、本当のところはOracle時代、片道切符で米国本社でぺーぺーのエンジニアで働いた経験だ。 当時はもちろんインターネットが商用化した前後で、欲しい情報も十分にあったわけではないし、Oracleの米国本社でエンジニアとして働くということがどのようなことかの情報もまっ
ぐうたら英語勉強法 2012-07-22 - 未来のいつか/hyoshiokの日記
なんだかいつのまにかに会社の公用語が英語になっちゃったものだから自分なりの英語勉強法を忘れないうちに記しておく。 2010年春頃、大々的に社内公用語を英語にするというアナウンスが外部向けにされて、マスコミに面白おかしく取り上げられた。社内でも当初は、本当かなーみたいな半信半疑の空気が流れていて、マジかよと言う人もいれば、いやうちの会社のことだから何が何でもやっちゃうだろーと言う人もいた。 私と言えば、それまで一度もTOEICなるものを受けたことがなかったので、だいたいどの位の点数をとれるかも皆目見当がつかなかった。 職級ごとに目標の点数が決められて、社内公用語英語化までに、その点数を取ることが義務づけられた。 社外の友人との飲み会なんかの鉄板ネタはこの英語化の話で、ほぼ間違いなくそのネタでいじられた。今回はその話はしない。 CASECというテストが会社で受けられて、TOEICでのだいたいの
社内SNSを活性化するたった一つの方法 2011-08-25 - 未来のいつか/hyoshiokの日記
があれば苦労しないよね。 昨日EGM Summitなるものに参加した。ここでEGMとはEmployee Generated Mediaのことで、社内ブログ、掲示板、SNSのようなものらしい。 弊社はYammerというTwitterのようなものを社内SNSとして利用している。全社的に春頃から導入しているのだが、無償版を随分前から有志が勝手に導入して利用していた。 社内Twitter的なものとしてSalesforceのChatterというのを試験導入したのだが、まったく普及しなかった。閑古鳥がないていた。営業でSalesforceを日常的に使用している人ならともかく、つぶやくためにわざわざログインするということの敷居の高さを越えられなかった。 一方でYammerは、Twitter的な機能だけではなく、Facebook的にスレッドがまとまって表示されたり、likeボタンがついていたり、写真やファ
Twitterの書き込みをきっかけに仕事についてあれやこれや考えてみた - 未来のいつか/hyoshiokの日記
先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件／環境／待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の（１）良いところ（あれやこれや）、（２）悪いところ（あれやこれや）と、仮に転職するとして、その候補となる会社の（３）期待値（あれやこれや）、（４）転職するにあたっての手間暇（あれやこれや）をざっくり天秤にかけて、いまのところにとどまるインセンティブA＝1-2、転職のイン
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
ガラパゴス化する就活 - 未来のいつか/hyoshiokの日記
わたしが学生だったころ（1980年代前半）の就職活動というのを思い返して見ると、高校生のときに漠然と大学の学部を決めて、大学生活を送るうちに希望の業界をイメージしていくという感じだった。 例えば、工学部であれば車が好きな奴は自動車メーカーに、経済学部であれば、商社とか銀行とか。工学部でも電気メーカーを希望するのは電気科とかであり、自動車メーカーを希望するのは機械科を専攻しているやつで、その逆はあまり考えられなかった。電気回路全然だめだよという奴は電気科にはいかないし、熱力学とか製図をとらない奴は機械科にはいかない。（必修がどうだこうだというより、自分の好きな科目とか得意な科目、あるいは苦手な科目を勘案の上、学部や学科を選択していくイメージだ） 高校生ころにざっくりとした学部の選択をし、大学生活を送りつつ、徐々に職業というのをイメージしていく。わたしの場合、2年生を二度やっているので（とほほ
社内公用語を英語にすること - 未来のいつか/hyoshiokの日記
最近楽天の社内会議を英語でやっているということをおもしろおかしく伝えられているが、中の人として一言ふたこと。http://mainichi.jp/select/biz/news/20100513mog00m300020000c.html まあ、言うまでもないことだけど、日本のGDPが今後全然増えないなかで企業が成長していくとしたら、海外にでなければいけないことは火を見るよりもあきらかなので、外に出て成長するか、外にでないで成長を放棄するか極端に単純化するとそのようなお話になる。いやいや、日本国内でも十分成長余力はあるという立場ももちろんあるが、それ以上に海外の成長が大きかったとしたら、限りある経営資源を有効活用するために、どっちの方に投資するかということである。 日本のサービス業で海外で成功した事例というのはほとんどない。製造業であれば、SONYやトヨタなどいくらでもあるし、かつての日本の
ロートルの嘆き、アジャイル開発って何 - 未来のいつか/hyoshiokの日記
20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数
未来のいつか/hyoshiokの日記
東大総長の平成30年度卒業式告辞で見田宗介の名前を知り「まなざしの地獄」とともに読んだ。本書は「脱高度成長期」をむかえた現代社会がどこに向かうのかを正面切ってとりあげている。 指数関数的な経済成長というのがありえないということを我々はすでに知っている。地球の資源は有限だし、人口増加も頭打ちになっている。しかしながら、我々の精神性においてはどこかに経済成長を望んでいるし、暗黙の仮定として、それを前提としている空気もある。 見田宗介はロジスティック曲線とよぶS字型の曲線を例に現代社会の行く末を占う。(8ページ) 1970年代のローマクラブの「成長の限界」を持ち出すまでもなく、成長はどこかに限界がある。それをロジスティック曲線が端的に表している。 「貨幣経済という人間の最大の発明の一つ」（132ページ）で欲望はどこに向かうのだろうか？ 「生活のための物質的な条件が確保されれば、それ以上の経済など
NIH症候群 2009-08-25 - 未来のいつか/hyoshiokの日記
自前主義というか、車輪の再発明というか、おれがおれがというか、そーゆー行動スタイルをNIH (Not Invented Here Syndrome)症候群と呼ぶ。 独自で作ったばりばりのソフトウェアなんてオープンソースにして公開したところで誰も使わないし、使ったとしても誰も改良してくれないし、従ってバザール開発にもならないにも関わらず何を勘違いしたかオープンソースにして、閑古鳥がなくなんてことがあるのかないのか知らないが、企業がオープンソースに関わろうとするなら、いきなり敷居の高い独自ソフトのオープンソース化なんてことはやめておいて、既存のOSSプロジェクトにおずおずと参加させてもらうというような方法がいいと思う。（もちろんわたしの個人的な意見であることは論をまたないけど） 個人の場合は、趣味で好きでやっているんで、どうでもいいのだけど、好きなものを好きに作って、自分の情熱の赴くままに作っ
2009-08-22
セキュリティ＆プログラミングキャンプ2009のわたしの講義で、「オープンソースにすると企業は損をするんじゃないですか」という本質をとらえた質問がでて、講師陣が、いきなりいろいろ議論を始めた。 企業の行動原理は、利益の追求だから、利益を生まないアクティビティは原則として行わない。オープンソースも例外ではない。 利益＝売上-経費 なので売上が増えるか、経費が減るかという観点から投資判断をする。当たり前ですな。 例えばマイクロソフトが自社の製品をオープンソースにすると、売上が伸びるか、あるいは経費が減るかというと、どちらもそうとは言えないので、マイクロソフトが自社製品をオープンソース化することは考えられない。先日マイクロソフトがHyper-V向けのLinuxドライバをGPLで公開したことが話題になったが、Linuxドライバを公開する事が自社のHyper-Vの魅力を増し、売上向上を期待して公開した
仕事で文書を書く必要がある人は理科系の作文技術を読むべきだ - 未来のいつか/hyoshiokの日記
仕事で文書を書く必要がある人は「理科系の作文技術」(ISBN:9784121006240)を読むべきだ。 ここでいう仕事で書く文書というのは他人に読んでもらう文書をさす。他人に読んでもらうことを前提としないメモの類や狭義の日記などはこれにあたらないので、どう書こうが構わない。他人に読んでもらうことを前提とした文書は、相手に内容が伝わらなければ意味がないのだから、間違いなく相手に通じるように表現しなければならない。 小説、詩などの文学作品は、ここでいう「仕事で書く文書」に含めないことにする。文学作品と対比して、仕事で書く文書の特徴はどこにあるのか。それは、読者に伝えるべき内容が事実と意見にかぎられていて、心情的要素を含まないことである。 仕事の文書を書くときの第一の原則は、「必要なことは洩れなく記述し、必要でないことは一つも書かない」ことである。何が必要かは目的により、また相手の要求や予備知
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
