新卒で入った会社の同期会に出た。2012-12-12 - 未来のいつか/hyoshiokの日記
わたしは、1984年に日本デジタルイクイップメント研究開発センターという会社に大学院を修了して新卒として入社した。日本ディジタルイクイップメント研究開発センターというのは米国のコンピュータベンダーDigital Eiquipment Corporation（これよりDECと記す）のEngineering部門の子会社で、当時日本には別法人で日本ディジタルイクイップメント株式会社という販売サービス子会社というのもあった。後に二つの日本法人は合併する。 これはIT産業の歴史の話なので若い人にはなじみがないことだと思うので、ちょっと詳しく書くと、当時、IT業界というのはIBMがその覇権を握っていて、日本のハードウェアベンダーがそのIBMにキャッチアップするために熾烈な戦いを挑んでいた。世界的にみると、IBMの後を、DEC、日本のハードウェアベンダー、富士通、日立、NEC、東芝、三菱、沖電気などが競
カーネル読書会のこと 2011-10-10 - 未来のいつか/hyoshiokの日記
カーネル読書会の運営で困ったので、ここで相談してみる。 カーネル読書会に限らず、勉強会一般に言えることだと思うので、勉強会の運営を一般化していうと、（１）ネタの選定？とお題提供者との各種調整（スケジュールや、内容のすり合わせ）、（２）会場の確保、（３）告知その他、（４）当日の運営あれやこれや、（５）それ以外のあれやこれや。というのがあると思う。規模が大きくなって有償イベントになると、それ以外のあれやこれやが大きくなるのだけど、無償の数十人規模の勉強会ではそれは発生しない。あえていえば、ビアバッシュや懇親会をどうするかという話があるのだけど、本日のメインポイントはそこではない。 カーネル読書会というのは1999年4月からやっているオープンソース系の勉強会で、主にLinuxのことについて取り上げて2009年10月の第100回にはLinuxを作ったLinusも参加してくれた。今年の5月には第10
自分のhistoryを分析する。DevLoveターミナル勉強会に行ってきた 2011-09-19 - 未来のいつか/hyoshiokの日記
CUI -- How to Analyze History command View more presentations from Hiro Yoshioka CUI(Command User Interface)というのはGUI(Graphical User Interface)と異なってコマンドを覚えなくちゃいけないし、コマンドをタイプしなくちゃいけないので、初心者にはちょっととっつきにくい。 コンピュータとの操作をGUIの時代からやっている人にとっては面倒な使いにくいものなのかもしれないが、CUIにはCUIのよさがある。それを伝えてみたい。 CUIのコマンドは自分の意志をコンピュータに伝える言葉である。CUIはそのコマンドを記録することが簡単にできる。なんといっても文字だから簡単に分析できる。 自分はコンピュータに何を語っているか。自分は日々何をしているのかを知ることが自分の作業を
社内SNSを活性化するたった一つの方法 2011-08-25 - 未来のいつか/hyoshiokの日記
があれば苦労しないよね。 昨日EGM Summitなるものに参加した。ここでEGMとはEmployee Generated Mediaのことで、社内ブログ、掲示板、SNSのようなものらしい。 弊社はYammerというTwitterのようなものを社内SNSとして利用している。全社的に春頃から導入しているのだが、無償版を随分前から有志が勝手に導入して利用していた。 社内Twitter的なものとしてSalesforceのChatterというのを試験導入したのだが、まったく普及しなかった。閑古鳥がないていた。営業でSalesforceを日常的に使用している人ならともかく、つぶやくためにわざわざログインするということの敷居の高さを越えられなかった。 一方でYammerは、Twitter的な機能だけではなく、Facebook的にスレッドがまとまって表示されたり、likeボタンがついていたり、写真やファ
デブサミで『ハッカー中心の企業文化を日本で根付かせる』という講演をしてきた 2011-02-27 - 未来のいつか/hyoshiokの日記
ハッカー中心の企業文化ってなんだなんだ。一体何について話をするんだ。という疑問は自分でも持っていた。ずいぶん大げさなタイトルにしてしまった。後の祭り。発表のずいぶん前からあれやこれや悩んでいたのあるが、今ひとつ構想がまとまらなかった。 その悩みに一つのヒントをくれたのがケンオルセンが亡くなったというニュースだった。自分が新卒として入社したDECという会社はどのような会社だったのか。そして、その会社が自分のエンジニアとしてのキャリアにどのような影響を与えたのか、与えなかったのか、それを軸に自己紹介をしつつ、自分の考えるハッカーセントリックな企業文化とは何かを話してみようと言う風に思い至った。*1 デブサミは2月17日、18日と2日間目黒雅叙園で開催される。わたしのセッションは18日の朝一である。 ハッカーセントリック(Hacker Centric)というフレーズはポールグレアムのエッセイ「Y
昔DECという会社があった。エンジニアとして必要な事はDECで学んだ。 - 未来のいつか/hyoshiokの日記
大学を1984年に出て、新卒で入社した会社がDECという会社だった。その当時日本デジタルイクイップメント研究開発センター株式会社というのが日本にあってそこに新卒バリバリで入社した。その会社は米国のDigital Equipment Corporation (以下DECと称す）の日本子会社であった。当時はDECの販売子会社日本ディジタルイクイップメント株式会社と別会社で、後に合併して日本ディジタルイクイップメントになる。 エンジニアリング部門の子会社なので、トップはPhD（博士号）を持っているし、米国本社からの出向者もいて、技術系の外資という感じだった。一方で、新卒入社ということもあり、同期も少ないながら（6名）いて、日本DECの同期と合わせれば、200名近くいて、日本企業的な感じもあった。 DECをコンピュータ産業史的な観点から眺めると、当時コンピュータ産業を支配していたメインフレーム、す
許可を求めるな謝罪せよ
インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。 http://twitter.com/#!/hyoshiok/status/33183999060873216 この「許可を求めるな。謝罪せよ」というフレーズは@kawagutiに教えてもらったのだが、彼は@hiranabeから３Mの社是として聞いていて、その心はというと、ともかく試してみてうまくいかなかったら、その時また考えるというような趣旨の行動規範ということらしい。*1 関係各位の許可を求めていたら絶対物事は進まないし、何も始まらない。何かをやってうまくいくこともあれば失敗することもあって、その試行錯誤によって人は学
そろそろ勉強会について一言いっておくか。 - 未来のいつか/hyoshiokの日記
自称勉強会マニアと呼ばれている@hyoshiokです。（それって自称じゃないじゃん。セルフツッコミ） それはともかく、勉強会の達人は「勉強会に勉強しにいくのは素人」とか、勉強会はあくまで手段であって目的ではないとか、勉強会マニア（苦笑）とか、まあいろいろ言っているわけであるが、わたしも勉強会について一言いっておく。 勉強会は主催者発表者参加者それぞれの思いがありそれぞれ渾然一体となって出来上がっているから同じものは世界に二つとないし、同じ主催者の勉強会でも毎回毎回微妙にことなるライブなセッションである。十人十色である。 なので、勉強会はなになにでなければいけないとかなになにであるべきだというものは一切ないし、自分が「これが勉強会だ」というようなことを言うつもりもない。 一方で勉強会に集う人々、主宰する人々、それぞれにある種の共通の価値観みたいなものはあるような気がする。十人十色なので全員が
状況に埋め込まれた学習 - 未来のいつか/hyoshiokの日記
われわれは学習というのを学校制度の中のかぎられた活動という風にとらえがちである。もちろんそんなことはない。わたしたちは日々の生活のなかで、あるいは仕事の中でなにがしかを常に学んでいる。学び続けている。 単に形式化され言語化された知識を獲得することが学習なのではない。 徒弟制度のような非熟練者が熟練者のもとで作業に参加することによって技術を習得していく方法について焦点を本書はあてている。 ソフトウェア開発コミュニティへの参加ということが、オープンソースの発展によって、より開かれた形になり、一つの企業に属さなくても自由にできるようになった。ごく限られた範囲でしか見聞き出来なかったソフトウェア開発のベストプラクティスがオープンソースコミュニティによってインターネットを介して自由に流通している。 その事例を間近で見聞きするにつれ状況に埋め込まれた学習の有効性を確認することができる。 本書の訳者あと
Twitterの書き込みをきっかけに仕事についてあれやこれや考えてみた - 未来のいつか/hyoshiokの日記
先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件／環境／待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の（１）良いところ（あれやこれや）、（２）悪いところ（あれやこれや）と、仮に転職するとして、その候補となる会社の（３）期待値（あれやこれや）、（４）転職するにあたっての手間暇（あれやこれや）をざっくり天秤にかけて、いまのところにとどまるインセンティブA＝1-2、転職のイン
LinuxCon Japan 2010、第106回カーネル読書会、U-20プログラミングコンテスト、PHP祭りなど - 未来のいつか/hyoshiokの日記
先週は、LinuxCon Japan 2010から始まって、第106回カーネル読書会、U-20プログラミングコンテストの最終審査会、そしてPHP祭り(PHPmatsuri)へ参加とコミュニティ三昧の一週間だった。 英語三昧 コミュニティ三昧ではあったが、英語三昧でもあった。 LinuxCon Japanは日本で開催されるカンファレンスであるが、公用語が英語になっていて、日本人の発表も英語、当然質疑応答も、日本人同士でも英語である。キーノート以外には通訳はつかない。 昨年のLinux Symposium Japan以来の英語でのカンファレンスで、当初は英語の発表で大丈夫かという声もあったが、やってみたら、意外とどーにかなったというのが実状である。日本人にとっては、英語での発表は相当敷居が高いが、Linuxの世界では、避けて通れないのでしょうがない。 海外からカーネルハッカーが来るので、彼らと
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
2010-08-07
@kakutaniにお勧めされて禅とオートバイ修理技術を読んだ。禅の本でもなければ、オートバイ修理技術の本でもない。では何の本なのか。 一種のロードムービー仕立てになっている。主人公は息子クリスと友人夫妻とでオートバイによる旅にでる。ミネアポリスからカリフォルニアまでオートバイでいく。いったいどのくらいの距離があるのだろう。*1 ロードムービーと言うのは、主人公が旅をしながら、様々な問題に直面し、それを乗り越えることによって成長していくという骨格をもった物語で、本書はまさにその形式に則っている。 バイクによる旅なんてことをいうとわたしの世代ではイージーライダーなのであるが、60年代のヒッピー世代を彷彿とさせる物語になっている。 自分もいつの日か全米を車で（オートバイはさすがに体力的にきつそうなので）旅をしてみたいと思っているのだが、ハイウェイをひたすら西に行くというのにそこはかとなく憧れる
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
勉強会カンファレンス2010に行ってきた - 未来のいつか/hyoshiokの日記
勉強会カンファレンス2010*1に行ってきた。そこでの感想など。 勉強会のメソッドは勉強会の数だけある。共通の問題もあればその勉強会固有の問題もある。それぞれの問題を出し合って、みんなでその解決策を議論するという方法は大変有効な方式だと再認識した。 最後のセッションで、岩切さんが、自分の困っていることをプレゼンしていて、そこからいろいろな議論が湧き上がってきて、非常に盛り上がったが、あんな感じのセッションがわたしにとって理想的な形だと思った。 岩切さんの困っていることというのは、ざっくり言うと、カンファレンスを開いても一列目、二列目の人たちは、笑いもしないし、ぴくりとも動かないし、隣の人といきなり話を始めて、何かを持ち帰っていこうというような感じの人がほとんどいない。それを聞きにくる人を巻き込んで、何かをしたい、だけど日本人だからそれができないかというと、DevLOVEなんかにいくと、とっ
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
社内公用語を英語にすること - 未来のいつか/hyoshiokの日記
最近楽天の社内会議を英語でやっているということをおもしろおかしく伝えられているが、中の人として一言ふたこと。http://mainichi.jp/select/biz/news/20100513mog00m300020000c.html まあ、言うまでもないことだけど、日本のGDPが今後全然増えないなかで企業が成長していくとしたら、海外にでなければいけないことは火を見るよりもあきらかなので、外に出て成長するか、外にでないで成長を放棄するか極端に単純化するとそのようなお話になる。いやいや、日本国内でも十分成長余力はあるという立場ももちろんあるが、それ以上に海外の成長が大きかったとしたら、限りある経営資源を有効活用するために、どっちの方に投資するかということである。 日本のサービス業で海外で成功した事例というのはほとんどない。製造業であれば、SONYやトヨタなどいくらでもあるし、かつての日本の
達人プログラマーの思考法と学習法 - 未来のいつか/hyoshiokの日記
無理してベストセラーを読む必要はない。自分にあった本を自分にあったペースで読んでいけばいい。GW中に昔（1年くらい前）献本された「リファクタリング・ウェットウェア」を読んだ。 達人プログラマでお馴染みのAndy Huntの著書である。正直言って、この本のタイトルにぐっとこなかったので、本書を1年近く寝かせておいたのであるが（献本いただいた宮川さんすいません）、ふと思いたち、読んだ。面白かった。副題の「達人プログラマーの思考法と学習法」が本書の内容を的確に表現している。 情熱プログラマーを読みながらも感じたことなんだけど、プログラマーとして、どのように学ぶかという問題にはもちろん正解はない。だけど、人間は弱いものなので、そのような正解を求めて本を読む。様々な自己啓発書が本屋にあふれているのがその証拠だ。私自身、そのような自己啓発書の類の書籍にはあまり興味がないので、買うことも読むこともほとん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
時短な人がいる場合の社内勉強会開催のTips - 未来のいつか/hyoshiokの日記
