タグ

ブックマーク / hyoshiok.hatenablog.com (51)

  • 9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記

    当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日ディジタルイクイップメント(DEC

    9月末で60歳定年退職しました - 未来のいつか/hyoshiokの日記
  • ITカンブリア紀の眼はIoTで、インターネットは神経回路網で、クラウドは脳だ - 未来のいつか/hyoshiokの日記

    インターネットによって地球規模の神経回路網が出来上がって、ITカンブリア紀が始まったというような世界観に我々はいる。 カンブリア紀は生物の種が爆発的に増えた時代と言われているが、その爆発には眼の発達が深く関わっていると言われている。生物が眼を持つことによって、他の生物を容易に捕することができるようになって生存競争において圧倒的に有利になったという説だ。捕される側も眼を獲得することによって捕者から逃げるという、ある種の軍拡競争によって生物の種は爆発的に進化・発展していった。 ITカンブリア紀の眼はIoTで、インターネットは神経回路網で、クラウドは脳だ。AIやビッグデータによってバラバラだったものが結線する。世界はソフトウェアでできている。そのような時代に生きている。わくわくする。

    ITカンブリア紀の眼はIoTで、インターネットは神経回路網で、クラウドは脳だ - 未来のいつか/hyoshiokの日記
    lEDfm4UE
    lEDfm4UE 2017/01/04
  • ICT Design Trek 2016に参加した - 未来のいつか/hyoshiokの日記

    はこだて未来大学で開催されたICT Design Trek 2016 (冬)に参加した。 SF映画をみて映画の世界のインタフェースを作ろう!ワークショップです。段ボールやスチロールなどを使って動くプロトタイプを3,4人のチームに分かれて作ります。 <動くプロトタイプ> プロトタイプ作成のためにArduino、iPad、プロジェクタ、スクリーン等を用意しています。もしこだわりの機材、使ってみたい機材がありましたら各自持ち込み歓迎です。 https://ed4bffb52a20331e96dfe5eb2a.doorkeeper.jp/events/38387 Star Trekを観て、それを題材に映画に出ていない何かを妄想して、それのプロトタイプを作るというワークショップである。(何を言っているかわからない。私もよくわかっていなかった) スター・トレック?/リマスター版スペシャル・コレクターズ

    ICT Design Trek 2016に参加した - 未来のいつか/hyoshiokの日記
    lEDfm4UE
    lEDfm4UE 2016/03/19
  • 質問される力 - 未来のいつか/hyoshiokの日記

    セミナーとか勉強会で話をしていて、あるいはそのような勉強会を主催していてよくある悩みの一つが質問が出ないというのがある。 質問がでないのは、日人が奥ゆかしいのだとか、質問するのが恥ずかしいとか、文化的な何かにその原因を求める人もいれば、講師の発表がそもそも質問を前提としていないとか、セミナーの形式にその原因を求める人もいる。 原因はなんであれ、一方通行のセミナーより、インタラクティブな質疑応答が活発にあるものの方が、参加者にとっても講演者にとってもメリットが多いと思うのだが、なかなかその価値観が共有されていない。 その問題についてFacebookで話題になっていたので、ちょっと考えをまとめてみた。 なぜ質問が必要なのか。なぜ質問が重要なのか。 勉強会などで質問が求められるのはなぜなのだろうか。もちろん質問を受けることを前提としないセミナーや講習というものはある。そうではなくて自主的な勉強

    質問される力 - 未来のいつか/hyoshiokの日記
  • 「角川インターネット講座2 ネットを支えるオープンソース」に「ハッカー精神とは何か」寄稿。 - 未来のいつか/hyoshiokの日記

    まつもとゆきひろさん監修の角川インターネット講座2 ネットを支えるオープンソース ソフトウェアの進化 角川学芸出版全集に「ハッカー精神とは何か」を寄稿した。 第一部、プログラミングがすべてを作った 序章、インターネットはソフトウエアでできている。まつもとゆきひろ インターネットを支えるソフトウェアを知る。法林浩之 プログラミングとは何か。久野靖 プログラミングと教育。阿部和広 ハッカー精神とは何か。吉岡弘隆 第二部、オープンソースが高めたネットの価値 ライセンスというプロトコル。やまねひでき オープンソース化が生んだ変化。瀧田佐登子 企業とオープンソース。鵜飼文敏 久しぶりの執筆だったので、七転八倒しながら書くことになった。 わたしのところは、60年代のハッカー達から70年代を経て、Richard StallmanのGNU Projectなどを紹介しつつ、OSSへの流れを歴史とともに解説し

    「角川インターネット講座2 ネットを支えるオープンソース」に「ハッカー精神とは何か」寄稿。 - 未来のいつか/hyoshiokの日記
  • MSが.netなどをオープンソース化って冗談かとおもったらまじだった。これはすごい。 - 未来のいつか/hyoshiokの日記

    いろいろと驚く。昔、オープンソースに敵対していたMicrosoftも自ら基幹ソフトウェアをOSS化する時代である。どんな大企業もオープンイノベーションを無視していけない時代になった。 .NET Core is Open Source | .NET Blog 30年くらい前のいわゆる垂直統合の時代は、ハードウェアからOSからコンパイラやRDBMSや、アプリまですべて自前で提供するというのが優れたビジネスモデルだと考えられていて、その完成系がIBMだった。ハードウェアベンダーは多かれ少なかれIBM的なビジネスモデルを目指していた。それは国産各社も例外ではない。80年代になって、潮目がごろっとかわり、専業ベンダーが台頭してくる。OSならMicrosoft、UnixならSun Micro、RDBMSならOracleCPUならIntel。それぞれの専業ベンダーはそれに資源を集中するので、イノベーシ

    MSが.netなどをオープンソース化って冗談かとおもったらまじだった。これはすごい。 - 未来のいつか/hyoshiokの日記
  • アジアの端っこでグローバリゼーションを考えた - 未来のいつか/hyoshiokの日記

    大学卒業してから20数年会社員生活をして、転職もして、それなりに経験をつんで、その立場からあれやこれや考えてみた。あれやこれや。 最初に就職した会社が、米国外資系ハードウェア会社の日法人(日DEC)、一年程、米国社に転勤になってVAX Rdbという製品開発に参加、次が同じく米国系ソフトウェア会社の日法人(日オラクル)、その時、米国社に出向になって、Oracle8というRDBMSの開発に参加、日に戻ってきて、日オラクルが出資するミラクル・リナックスを立ち上げて取締役CTO、最後に5ヶ月ほど独立行政法人情報処理推進機構(IPA)に出向。そして今は楽天。ミラクル・リナックスの経営は日人がやっていて社も日だが、日オラクルという外資の子会社なので、資的には外資(?)ということになる。なので、わたしの会社員人生は、外資がほとんどだ。 長年外資の子会社に勤めて痛感したのは、重要

    アジアの端っこでグローバリゼーションを考えた - 未来のいつか/hyoshiokの日記
  • ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series) - 未来のいつか/hyoshiokの日記

    倉貫さんが、ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)を紹介していた。 ずいぶん前に読んだのだけど、棚から引っ張りだして、パラパラと再読した。180ページほどなので、お気楽に読めるのであるが、中身は濃い。 最後の章(19章)は「永続的な学習」を取り上げている。1)学習環境を作り上げる。2)ソフトウェア開発における技芸の熟達。3)訓練コースは細心の注意を払って選択すること。4)ソフトウェア開発コミュニティ内で目立つことを奨励する。5)内省的な実践者になる。 学習環境を作り上げる。 1)学習環境を作り上げるために、組織内に講座を設ける。2)興味深いテーマのセミナーには部外者も招待する。3)学習時間はプロセス改善の投資である。 具体的なコツがいろいろ詰まっている。 ソフトウェア開発における技芸の

    ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series) - 未来のいつか/hyoshiokの日記
  • ブルックスの法則 - 未来のいつか/hyoshiokの日記

    ムーアの法則(18ヶ月で半導体の能力が2倍になる)というのは有名だが、それに比べてブルックスの法則は知られていない。 http://commons.wikimedia.org/wiki/File%3AFred_Brooks.jpg *1 ブルックスは1960年代、IBM System/360用オペレーティング・システムOS/360の開発責任者で、後にそのときの経験をもとに人月の神話というを書いた。 大規模ソフトウェア製品開発の難しさを書いた画期的な書物である。IT産業に従事しているなら必読の書である。ソフトウェア開発あるいはプロジェクトマネジメントに関わる人はだまされたと思って読んだ方がいい。わたしの日記でも何度となく紹介している。 それはともかく第二章人月の神話だ。次のような例題がある。12人月かかると見積もられた仕事があるとして、3名で4ヶ月でその作業を完了すると考えた。そして一月毎

    ブルックスの法則 - 未来のいつか/hyoshiokの日記
  • Let them be your heroes. 彼らをヒーローにしよう。 #OSCON - 未来のいつか/hyoshiokの日記

    OSCONのセッションで特に面白かったと感じたものを紹介する。 Let Them Be Your Heroes - Speaker Deck コミュニティ活動をしていて、そのコミュニティを活性化して持続可能にするためには、ヒーローが必要だ。そのヒーローをどのようにして見つけ、育て、励ますのか。そのような観点からの議論がこのセッションだ。 コミュニティーマネージャーはヒーローを見つけ、コミュニティーそのものをエンパワーする。そしてより多くの人をヒーローにするにはどうするのか。どのようにして、ヒーローを発見し、活躍してもらうのか。 ヒーローの特徴。物事をやりとげ、知識(スキルや技量)があって、協力的で、誠実だ。 ヒーローの鼓舞。専門家に聞いてみよう。Ricky Robinnet (http://blog.rickyrobinett.com/about/) 誰? ヒーローの見つけ方。フォーラムの

    Let them be your heroes. 彼らをヒーローにしよう。 #OSCON - 未来のいつか/hyoshiokの日記
  • Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記

    誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事Linuxを使う機会は全然なかったのだけど、自宅のPCSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleLinux版を出し

    Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
  • 再利用できる画像の検索方法 - 未来のいつか/hyoshiokの日記

    プレゼン資料で画像を使いたい場合がある。 インターネットで検索して適当にコピペするというのは、その画像の著作権を持っている人の権利を侵害する可能性が高いので、よろしくない。 そこで、再利用可能な画像の検索方法が必要になってくる。 1) Image検索で、Search Toolsをクリック 2) Usage rightsをクリック。そのなかで権利関係で選ぶ。ライセンスでフィルターしない。再利用、変更可能。再利用可能。非商用、再利用、変更可能。非商用、再利用可能。のなかから選ぶ。 再利用可能な画像はいっぱいあるので、そこから選んで利用しよう。くれぐれも、自分が著作権を持たない、画像をぺたぺたはるのはやめよう。よく、マンガのキャラクタなどを分別なしに使っている人がいるが、おすすめできない。多くの場合は引用の範囲を超えているので、やめたほうがいい。 下記のサーチエンジンのリストも便利だ。 http

    再利用できる画像の検索方法 - 未来のいつか/hyoshiokの日記
  • 意外と会社は合理的、読了 - 未来のいつか/hyoshiokの日記

    意外と会社は合理的 組織にはびこる理不尽のメカニズムを読んだ。 組織に焦点をあてたで、様々な組織を例に、そのメカニズムを解説している。登場する組織には、営利企業もあれば、非営利組織もあれば、宗教団体、警察、軍隊、テロリスト、正義のヒーローなどなど。あ、正義のヒーローは組織じゃないけど、それが戦う悪者は統率のとれた組織だ。 経営学の研究成果をもとに、これでもかといろいろな事例を出してくる。 プリンシパルとエージェント問題というのは、どうやって従業員に期待した仕事をやらせるかという問題である。どのようにインセンティブを設計してそれを運用して行くか。経営者は、従業一人一人が期待通り働いているかいちいち監視することはできない。さぼらないように監視したり、ずるをしないように監視することを完璧に行うにはコストがかかりすぎる。そこで中間管理職をもうけたり、様々なルールをもうけたりする。 これは営利企業

    意外と会社は合理的、読了 - 未来のいつか/hyoshiokの日記
  • EGM Forumの月例会に行った - 未来のいつか/hyoshiokの日記

    今回の場所は、はじめての丸の内、富士ビルにある「3x3 Labo(さんさんらぼ)」。いい場所っすね。 http://www.ecozzeria.jp/fujibldg33/ 今回のお題は「組織改革」。神垣さん、佐藤さん、杉浦さん、わたしが発表。 神垣さんは、この3年会社でやってきたことをお話ししてくれた。ワールドカフェに影響をうけ、会議の中で付箋をつかったり、模造紙を使ったりしながら、自分の部門の会議を変えた。それをやった経験についてお話をしてくれた。 付箋を使うと、みんななにがしかの意見を書く。通常の会議では決して発言しないような人も、付箋には必ずなにがしかを書く。今まで吸い上げられなかった意見、気持ち、空気が可視化される。人々が話をするようになる。 会議が単なる情報を流すだけの場になっていたりするのを、この方式にすると活発な議論が生まれる。そして活発な議論のなかから、人が変わり、新しい

    EGM Forumの月例会に行った - 未来のいつか/hyoshiokの日記
  • かつてオープンソースが当たり前じゃないころがあった - 未来のいつか/hyoshiokの日記

    先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/

    かつてオープンソースが当たり前じゃないころがあった - 未来のいつか/hyoshiokの日記
  • 破壊的イノベーション(disruptive innovation)ってなんだろう - 未来のいつか/hyoshiokの日記

    新経済サミットに出てみて、いろいろな人の発表を聞いた。 登壇した起業家たちは、起業家予備軍とでもいうべき参加者に対し、失敗を恐れるなとか、リスクを取れとかを勧める。それを聞いてほいほい起業をする人が日でボコボコ増えるというようなことはないとは思うが、自分なりに破壊的イノベーションってなんだろうということを考えてみた。 破壊的という位だから、従来の発想の延長にあってはいけない。従来の常識をまっこうから否定するような何かでないといけない。どう考えてもクレージーなアイデアでないといけない。誰もが納得するようなアイデアであれば、それは定義により破壊的ではない。 従来のものより「劣っている」ものとか、明らかに「欠点」のあるものとかは破壊的である可能性はある。多くの人がクレージーと考えるもの、うまく行く訳がないと考えるものが、破壊的だ。 誰もがクレージーと考えるものは、1)当にクレージーでどうしよ

    破壊的イノベーション(disruptive innovation)ってなんだろう - 未来のいつか/hyoshiokの日記
  • 英語を社内公用語にしてはいけない3つの理由。読了 - 未来のいつか/hyoshiokの日記

    英語を社内公用語にしてはいけない3つの理由を読んだ。 英語社内公用語化は、1)日語・日文化の軽視、2)社会的格差・不平等の助長と固定化、3)言語権の侵害、なので、著者は反対という立場をとっている。 あらかじめお断りしておくが、わたしは、この著者の立場を取らない。また、ここでのわたしの意見は所属会社のそれを表すものではなく、あくまで個人としてのものである。 まず、簡単に書を紹介し、その後、自分の意見を述べたいと思う。 「英語を社内公用語にしてはいけない3つの理由」 書の構成は、序文「楽天、ユニクロへの手紙」、第1章英語社内公用語化の実態、第2章英語公用語論の歴史、第3章英語を社内公用語にしてはいけない理由1、日語の衰退を招く、第4章英語を社内公用語にしてはいけない理由2、格差を生み、拡大する、第5章英語を社内公用語にしてはいけない理由3、言語権を侵害する、第6章もしあなたの会社が英

    英語を社内公用語にしてはいけない3つの理由。読了 - 未来のいつか/hyoshiokの日記
  • 社内が英語化してよかったこと - 未来のいつか/hyoshiokの日記

    なんだか、ネガティブなことばかり世間では書かれているので、個人的によかったことなど感想を一つ二つ書く。 どーでもいいことから 英語への抵抗感がなくなる。どっかで英語で話しかけられても怖くない。へらへら対応できる。切符を買えなくて困っている外国人とお友達になれる自信ある。 30分くらいの英語の会議だったら集中力が持続する。 外国籍の友達が増えた。会社に外国籍の人がいっぱいいるので、顔見知りがいっぱい増えた。英語で雑談するのが好きだ。仕事で絡みがなくても気さくに話しても大丈夫である。 海外情報がいろいろ回ってくるような気がする。翻訳される前の情報がいろいろ出回っているような気がする。(まあ、気がするだけかもしれないけど) インターネットで流通している技術情報のほとんどは英語であるということを確信した。日語の情報は遅い、古い、不正確で、量も少ない。ググるときに日語じゃなくて英語のページを見た

    社内が英語化してよかったこと - 未来のいつか/hyoshiokの日記
  • まつもとゆきひろのコピーは作れるのか。 - 未来のいつか/hyoshiokの日記

    Rubyにみるグローバルソフトウェア開発」というタイトルでの講演だった。 http://aiit.doorkeeper.jp/events/8871 まつもとゆきひろのコピーは作れるのか? コミュニティの運営とかは言語化できそうだけど、情熱をコピーすることはできない。心に灯をともすにはどうすればいいのだろう。それを10年間続けるにはどうすればいいのだろう。 OSSを作ることはそれほど難しいことではない。多分、気の利いたプログラマなら誰でも作ることはできる。 githubのようなサービスが開発を支援してくれるし、コミュニティ作りのコストを圧倒的に下げた。twtitterやFacebookやブログなどで開発を告知することも出来る。 にも関わらず、Rubyのように世界中で使われるプロダクトを作った人はまつもとさん以外にほとんど現れていない。OSSを作った人はいっぱいいるが、まつもとさんのような

    まつもとゆきひろのコピーは作れるのか。 - 未来のいつか/hyoshiokの日記
    lEDfm4UE
    lEDfm4UE 2014/03/16
    パッションを持ったプロフェッショナルを創ることは自分にしかできない。
  • 詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記

    わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、

    詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記