エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠typeエンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。
大震災のあとに 2011-03-20 - 未来のいつか/hyoshiokの日記
東北太平洋沖大震災で亡くなられた方に謹んで哀悼の意を表するとともに、被災された方にお見舞いを申しあげます。 3月11日から10日目となったいま自分に出きることを考えた。 日本にとって史上最大規模のマグニチュード9.0という地震、甚大な被害をもたらした津波、原子力発電所の事故、東京電力の大規模計画停電、首都圏の機能（公共交通機関など）の混乱、いまだにその影響は続く。 この状態はしばらく続く 原子力発電所の問題については、われわれはどうすることもできないので、事態が安定化することを祈る他ない。われわれが何かできることはほとんどない。福島第1、第2原子力発電所の運転再開はほぼ不可能なので電力供給量の回復は短期的には望めない。 東京電力の発表によれば、現在の発電供給力は3400万kW（1時間あたり）程度で、平日夕方18時〜19時のピークが4000万kW（3月17日の予想 http://www.te
なぜシリコンバレーは復活し、ボストン・ルート128は沈んだか。 2011-03-05 - 未来のいつか/hyoshiokの日記
「現代の二都物語」を読んだ。 米国東海岸ボストン近郊の、ルート128。そのまわりには、70年代ハイテク企業がひしめいていた。ボストンにはMITやハーバート大学がありハイテク産業に人材を供給していた。DECや、DG、ワングなどのミニコンピュータベンダーがそこにはあった。 そのベンダーがなぜ競争力を失って、シリコンバレーに破れるのか。地域としての優位性を保てなかったのか。それについて本書は書いている。 結論から言えば、一社で上から下まですべて作り上げる垂直統合型のビジネスモデル、それが東海岸ボストン・ルート128の企業の典型だった、それが自社の技術に固執するばかりに時代の変化に取り残されて、破れさっていくということである。 シリコンバレーでは、各社は自分の得意なところ以外は積極的に外部から調達する。コンピュータベンダーですら、CPUからなにから何まで外部に依存したりする。水平分業型のビジネスモ
デブサミで『ハッカー中心の企業文化を日本で根付かせる』という講演をしてきた 2011-02-27 - 未来のいつか/hyoshiokの日記
ハッカー中心の企業文化ってなんだなんだ。一体何について話をするんだ。という疑問は自分でも持っていた。ずいぶん大げさなタイトルにしてしまった。後の祭り。発表のずいぶん前からあれやこれや悩んでいたのあるが、今ひとつ構想がまとまらなかった。 その悩みに一つのヒントをくれたのがケンオルセンが亡くなったというニュースだった。自分が新卒として入社したDECという会社はどのような会社だったのか。そして、その会社が自分のエンジニアとしてのキャリアにどのような影響を与えたのか、与えなかったのか、それを軸に自己紹介をしつつ、自分の考えるハッカーセントリックな企業文化とは何かを話してみようと言う風に思い至った。*1 デブサミは2月17日、18日と2日間目黒雅叙園で開催される。わたしのセッションは18日の朝一である。 ハッカーセントリック(Hacker Centric)というフレーズはポールグレアムのエッセイ「Y
いつの間にかに200万ページビュー - 未来のいつか/hyoshiokの日記
ご笑覧御礼（ぺこり）。 2004年3月からなので約7年間。 追記 http://tophatenar.com/view/hyoshiok 購読者: 2411 (先月比 +8)、全体で141 位 / 387289 人 (上位 0.04 ％以内)、はてなダイアリーで20 位 / 94156 人 (上位 0.02 ％以内) ブックマーク: 10860 (先月比 +846)、全体で347 位 / 387289 人 (上位 0.09 ％以内)、 はてなダイアリーで91 位 / 94156 人 (上位 0.1 ％以内) グラフ期間中の人気エントリー 仕事で文書を書く必要がある人は理科系の作文技術を読むべきだ 許可を求めるな謝罪せよ。(Don't ask for permission, beg for forgiveness ) 2011-02-05 - 未来のいつか そろそろ大規模ソフトウェア開発に一
なぜDECは市場から撤退しなければならなかったのか。 - 未来のいつか/hyoshiokの日記
DECの企業文化について、先日記した。(昔DECという会社があった。エンジニアとして必要な事はDECで学んだ。) *1 そんなに優れた技術があり、優れた企業文化を持ち、優秀な技術者を多数抱えたエクセレント・カンパニーが21世紀を待たずしてなぜ市場から消えなければならなかったのだろうか。 経営者が愚かで放漫経営をしていたからとか、法律に違反するような経営をしていたとか、そーゆー話であればわかりやすい。その経営者が愚かであったということで決着がつく。 DECの凋落の原因は、むしろ無能な経営者によって引き起こされたというよりも、むしろ、有能だったがゆえに、成功の呪縛から逃れられなかったという風に考えられる。既に起きてしまったことをあれやこれや言っても所詮結果論にしたすぎないが、あえてそれを考えてみたい。 「イノベーションのジレンマ」では、利益を最大化させる資源配分メカニズム（プロジェクトの投資を
2011/2/13現在の歴代ブックマークトップ10 - 未来のいつか/hyoshiokの日記
ふと思いたち、自分の日記の歴代ブックマークのトップ10を眺めてみた。人気順の傾向と対策みたいな。 そろそろ〜一言いっておくか、は釣り系のタイトルの定番であるが、そろそろ止めた方がよさそうだw 仕事で文書を書く必要がある人は理科系の作文技術を読むべきだ - 未... 444 users そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルド... 291 users 許可を求めるな謝罪せよ。(Don't ask for permission, beg for forgi...270 users そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiok... 270 users プログラマのための文字コード技術入門を読んだ 2010-02-14 - 未来の... 265 users 40代、50代の人たちはなぜ表現しないのか - 未来のいつか/hyoshio
昔DECという会社があった。エンジニアとして必要な事はDECで学んだ。 - 未来のいつか/hyoshiokの日記
大学を1984年に出て、新卒で入社した会社がDECという会社だった。その当時日本デジタルイクイップメント研究開発センター株式会社というのが日本にあってそこに新卒バリバリで入社した。その会社は米国のDigital Equipment Corporation (以下DECと称す）の日本子会社であった。当時はDECの販売子会社日本ディジタルイクイップメント株式会社と別会社で、後に合併して日本ディジタルイクイップメントになる。 エンジニアリング部門の子会社なので、トップはPhD（博士号）を持っているし、米国本社からの出向者もいて、技術系の外資という感じだった。一方で、新卒入社ということもあり、同期も少ないながら（6名）いて、日本DECの同期と合わせれば、200名近くいて、日本企業的な感じもあった。 DECをコンピュータ産業史的な観点から眺めると、当時コンピュータ産業を支配していたメインフレーム、す
Innovation Sprint 2011 に参加した - 未来のいつか/hyoshiokの日記
Innovation Sprint 2011に参加した。コミュニティによる価値の創造の一旦を垣間見た気がした。http://innovationsprint.com/ みたままに記す。 川口さん(@kawaguti)がスクラムの父ジェフサザーランドと祖父野中さんを呼んでカンファレンスをしたいと考えているというのを聞いたのは勉強会カンファレンス2010の時だったと思う。おお、いいすね。と適当に答えていたと記憶している。平鍋さん、ピークワン代表の前田さんらが動いて野中さんをひっぱりだし、川口さんが、ジェフとコンタクトをとったようだ。*1 平鍋さんと楽天の田澤さんはIPAの非ウォーターフォール研究会（名前？）の縁で、正式（？）には平鍋さんから田澤さんへの依頼が夏頃にあった。すぐに田澤さん経由で、こんな話が来ているんだけどどうよと来たので、やりましょうよとノリで答えた。 わたしに出きることと言えば
プログラマが知るべき97のこと - 未来のいつか/hyoshiokの日記
和田さん監修、夏目大さん翻訳。下記のような日本人プログラマに書き下ろしもついている。 命を吹き込む魔法 森田 創 ロールプレイングゲーム 関 将俊 ルーチンワークをフローのきっかけに 宮川 達彦 プログラマが持つべき3つのスキル 吉岡 弘隆 快適な環境を追求する 舘野 祐一 見知らぬ人ともうまくやるには 小飼 弾 不具合にテストを書いて立ち向かう 和田 卓人 育ちのよいコード 森田 創 Noといえることの大事さ 宮川 達彦 名前重要 まつもと ゆきひろ 誰かに向かって、「〜するべき」というのは、いささかおこがましい感じもしないではないが、「プログラマが持つべき3つのスキル」というエッセイを寄稿した。日頃言っている、ソースコードを読むスキル、テストするスキル、デバッグするスキルなどについてあれやこれや申し上げた。 書き下ろしの中で、まつもとさんの「名前重要」や森田さんの「命を吹き込む魔法」は
そろそろ勉強会について一言いっておくか。 - 未来のいつか/hyoshiokの日記
自称勉強会マニアと呼ばれている@hyoshiokです。（それって自称じゃないじゃん。セルフツッコミ） それはともかく、勉強会の達人は「勉強会に勉強しにいくのは素人」とか、勉強会はあくまで手段であって目的ではないとか、勉強会マニア（苦笑）とか、まあいろいろ言っているわけであるが、わたしも勉強会について一言いっておく。 勉強会は主催者発表者参加者それぞれの思いがありそれぞれ渾然一体となって出来上がっているから同じものは世界に二つとないし、同じ主催者の勉強会でも毎回毎回微妙にことなるライブなセッションである。十人十色である。 なので、勉強会はなになにでなければいけないとかなになにであるべきだというものは一切ないし、自分が「これが勉強会だ」というようなことを言うつもりもない。 一方で勉強会に集う人々、主宰する人々、それぞれにある種の共通の価値観みたいなものはあるような気がする。十人十色なので全員が
状況に埋め込まれた学習 - 未来のいつか/hyoshiokの日記
われわれは学習というのを学校制度の中のかぎられた活動という風にとらえがちである。もちろんそんなことはない。わたしたちは日々の生活のなかで、あるいは仕事の中でなにがしかを常に学んでいる。学び続けている。 単に形式化され言語化された知識を獲得することが学習なのではない。 徒弟制度のような非熟練者が熟練者のもとで作業に参加することによって技術を習得していく方法について焦点を本書はあてている。 ソフトウェア開発コミュニティへの参加ということが、オープンソースの発展によって、より開かれた形になり、一つの企業に属さなくても自由にできるようになった。ごく限られた範囲でしか見聞き出来なかったソフトウェア開発のベストプラクティスがオープンソースコミュニティによってインターネットを介して自由に流通している。 その事例を間近で見聞きするにつれ状況に埋め込まれた学習の有効性を確認することができる。 本書の訳者あと
寄稿「IT系勉強会について」
情報システム学会メールマガジン読者の皆様、はじめましてよしおかと申します。 IT勉強会について、ぜひ知っていただきたいことがいくつかあります。 上記はIT勉強会カレンダーというもので、hanazukinさんと愉快な仲間達がボランティアで編集公開しているものです。ごらんになって分かるとおり、日本各地で、日々勉強会が開催されています。平日、休日問わず多い日には10件以上の勉強会が開催されています。 内容も、PerlやRubyのようなスクリプト言語の勉強会や、開発方法論の勉強会、あるいはLinuxカーネルの勉強会など多岐にわたります。毎月300を超える勉強会が開催されている姿は壮観なものがあります。
第106回カーネル読書会のお知らせ〜〜LinuxCon Japan開催記念〜〜 - 未来のいつか/hyoshiokの日記
Tweet 毎度お馴染み流浪のカーネル読書会のお知らせです〜 昨年のLinux Kernel Summit記念カーネル読書会と同じ感じで カーネルハッカーを招いてビアバッシュを開催します。 今年は誰が参加してくれるか楽しみです〜 日時：9月28日(火)18:00開場、18:30時ころ開始 お題：あれやこれやご歓談 発表者：みなさん 内容：いきなりビアバッシュ 会費：1000円（予定、学生は無料、コメント欄に学生と記してください） 18:00頃 開場、LTないし自己紹介など 19:00頃 ビアバッシュ 21:00頃 中締め 場所はGREE（六本木ヒルズ）http://gree.co.jp/corporate/location/ 会場の都合上、18:00より以前には開場しませんので、ご注意ください。 参加登録に際しては、受付のためお名前の明記をお願い致します。 またなるべく遅刻のないようにお願
セキュリティ＆プログラミングキャンプ2010を振り返る - 未来のいつか/hyoshiokの日記
当事者の一人として、セキュリティ＆プログラミングキャンプ2010（以下キャンプと記す）を振り返る。 来年度同じようなイベントが開催できるか分からないので、今回ここで振り返ったところでそれが来年実装できるかどうかは神のみぞ知ることなのだけど、まあ、どのようなことが課題だったかということを明文化することは悪いことではないので記す。 キャンプの中の人として、プログラミングコースの主査の立場から言うと、このようなキャンプは世界にも多分例がないし、やる意義は大変あると思うし、できれば、最低でも10年は続けたいと思うのだけど、正直、税金を使って続けることがいいことなのか、考え時だと思った。本当に必要だと思うのだったら、本当に必要だと思う人が（企業とかも含めて）、ファンドして、お金を捻出をしてでもやるべきで、国の支援が切れたから、終わりというのは、あまりにも残念な感じである。 現状の最大の問題はスポンサ
2010-08-07
@kakutaniにお勧めされて禅とオートバイ修理技術を読んだ。禅の本でもなければ、オートバイ修理技術の本でもない。では何の本なのか。 一種のロードムービー仕立てになっている。主人公は息子クリスと友人夫妻とでオートバイによる旅にでる。ミネアポリスからカリフォルニアまでオートバイでいく。いったいどのくらいの距離があるのだろう。*1 ロードムービーと言うのは、主人公が旅をしながら、様々な問題に直面し、それを乗り越えることによって成長していくという骨格をもった物語で、本書はまさにその形式に則っている。 バイクによる旅なんてことをいうとわたしの世代ではイージーライダーなのであるが、60年代のヒッピー世代を彷彿とさせる物語になっている。 自分もいつの日か全米を車で（オートバイはさすがに体力的にきつそうなので）旅をしてみたいと思っているのだが、ハイウェイをひたすら西に行くというのにそこはかとなく憧れる
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デブサミ2011【18-A-1】ハッカー中心の企業文化を日本に根付かせる よしおかひろたか 氏
