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

夏休みなので、たまたま読んでいたCoders at Work プログラミングの技をめぐる探求という本の中にJamie Zawinskiのインタビューが載っていた。この本は著名なプロラグマを集めたインタビュー集で、Unixを創ったKen ThompsonやらDonald Knuthやらすごい人たちが登場している。 その中でJamie Zawinskiはそれほど著名でもなければ誰もが使っているすごいシステムを開発したというわけでもない。私が彼の名前を知ったのはNetscapeのソースコード公開時にMozilla.orgを仕切っていた頃なので、20年近く前である。 彼はxemacsの開発者としても著名で、当時GNU Emacsではなくてxemacsを日常的に使っていたので馴染みにある名前だった。xemacsとGNU Emacsはのちにマージされるのだけど前者が今で言う所のバザール型開発で、後者が

継続的インテグレーション(CI - Continuous Integration)と継続的デリバリー(CD - Continuous Delivery)について知りたかったら、闘うプログラマー［新装版］を読もう。 これはWindows NTの開発物語だ。大規模基盤ソフトウェアの現場の葛藤を生々しく描いていて、ソフトウェア開発に従事しているものには必読書といっても過言ではない。 デスマーチ、ドッグフードを食う、ビルド、業界人なら誰でも聞いたことがあるジャーゴン（業界用語）がちりばめられている。本書によって、それらの用語を覚えた人も少なくないと思う。 「カトラー（開発の総責任者、伝説のプログラマー）は、オペレーティング・システムを開発するときは、機能を増やすより、スケジュールを短縮するべきだと考えている。最初のバージョンは、機能を減らしても、早くリリースしたほうがいい。最初は機能を最小限にして

PBL(Project Based Learning)の授業を持っていて、その教員が集まってあーだこーだという会に参加している。PBLという手法は必ずしも教員にとっても経験豊富なものではないので学生の指導方法とかに悩みが多いので、いろいろな立場の人が集まって、あーだこーだ試行錯誤や悩みについて披露し合う。 産業技術大学院大学でのPBLはウェブアプリケーションの作り方を学ぶというもので、モダンなソフトウェア開発手法やクラウドを前提としたツールなどを利用してチームで実際にものを作る。 *1 キーワードとして、Continuous Delivery (CD), Test Automation, Continuous Integration (CI), Version Control System, Test Driven Development (TDD), Platform as a serv

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

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

先日、オープンソース関連のセミナーを聞く機会があって、弁護士の先生がオープンソースをコンプライアンスの観点から解説をされていた。 弁護士の仕事はクライアントからの相談事を主に法律等の観点からアドバイスすることなので、クライアントがオープンソースにはどのようなリスクがあるかという質問をすれば、当然ながら「XXXというリスクがある」とか「XXXのリスクを避けるためにYYYという対策をとる必要がある」とか言う回答になる。 コンプライアンスという観点から、オープンソースのライセンスを検討すれば、GNU GPLのオープンソースを利用して、著作権者から訴えられない利用方法とか、MITの場合はどうだという方向になる。 クライアントも別にオープンソースに詳しいということもないから法律的な相談をするわけで、いかにリスクを最小化するかという文脈では上記のようなやりとりになる。 つまりこの文脈の中では、オープン

ソフトウェア開発におけるブルックスの法則とは何か。 http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる ブルックスはIBM System/360用オペレーティングシステムOS/360の開発総責任者だった人で、その経験をもとに人月の神話【新装版】というエッセーを執筆した。 人月の神話は、ソフトウェア開発を志す人なら必ず一度は読まなければいけない良書だ。読んでいない人は、悪いことは言わないから、ともかく読むことをおすすめする。 初版が出版されたのが1975年（日本語訳は1977年）で、20周年記念版が1995年に出た。ブルックスの発見した法則があきらかになって約40

ともちゃんがGitHubを勉強したいにゃん、ということなので、勉強会に行ってきた。みんな猫耳つけて発表するというわけのわからない勉強会であった。 http://atnd.org/events/48075 Introduction to Git and GitHub #git_nyan from Hiro Yoshioka のれんがかかっていた。 これらはすべて手作り 沢田さんの説明 LTもあった GitHub実践入門とステッカー わたしのお話は、GitがLinusの自分の問題を解決することから始まったというような歴史の話からあれやこれや。Linuxのソースコードを管理するためには分散型、高速、高信頼性などが必要。 Linusは自分のPCのバックアップをとっていなくてもコミットしたものをインターネットにおいておけば誰かがコピーして、そのコピーは改竄することが非常に難しいので安全に複数のバック

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

集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ） バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1 一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成

自己紹介というのは、簡単なようでいて難しい。自分は何者かを5秒でいう。15秒でいう。3分でいう。それぞれに難しいものがある。 社会人として、自分を知ってもらうということは、仕事の一環として、最初の一歩だ。仕事じゃなくても、コミュニティでの自己紹介とか、親戚一同での自己紹介とか、簡単なようでいて難しい。 その場所にあなたはなぜいて、何者かを簡潔に表現する。それが難しい。 例えば、仕事上での初対面であれば、名刺交換をしつつ、XX株式会社、開発のよしおかでございます、でいいのであるが、勉強会で、全然自分の会社のことを知らないあるいは興味のない人に、第二営業部第三課の営業やるおです、なんて所属を説明しても、自己紹介にはならないし、そもそも第二営業部第三課が何をやっているかなんてことは参加者は知りもしないし、しったこっちゃない。なんできみがここにいるのかが意味がわからない。勉強会で営業やるお君が自己

ふと思い立ち、「人月の神話」「理科系の作文技術」とかIT業界で生きる技術者に勧める100冊みたいなのを考えてみた。どんなものがあるのだろうかとtwitterで聞いてみたら、「100人のプロが選んだソフトウェア開発の名著」というのを教えてもらった。というか、わたしも一冊紹介していることをすっかり忘れていた。すいませんすいません。（ぺこり） そこで、久しぶりに、読み返してみた。というか今までじっくり読んでいなかった。すいませんすいません。そして未読のものに付箋をつけた。付箋だらけになった。 100人のプロが選んだソフトウェア開発の名著 http://www.seshop.com/1satsu/100nin/ それはともかく本の紹介もさることながら、それにまつわるお話が面白い。読んだことがない本の紹介だと、ふーん、そうなのかぁーと思うこともあれば、ぜひ読んでみたいと思うものもあり、自分の趣味と皆

仕事の世界の「古い約束事」とは？ 『私が働くのは、給料を受け取るため。その給料を使って、私はものを消費する。そうすることで、私は幸せを感じる』342頁。 所得を増やし、消費を増やすという価値観だ。それが20世紀の大量生産、大量消費の価値観だ。 『過去二十年間の働き方や生き方の常識が多くの面で崩れようとしている。例えば朝九時から夕方五時まで勤務し、月曜日から金曜日まで働いて週末に休み、学校を卒業してから引退するまで一つの会社で勤め上げ、親やきょうだいと同じ国で暮らし、いつも同じ顔ぶれの同僚と一緒に仕事をするーーそんな日々が終わりを告げ、得体の知れない未来が訪れようとしている』4頁。 得体の知れない未来 その得体の知れない未来とはなんなのか。その未来にどのようにわたしたちは対応するべきなのか、そのヒントがある。 2025年頃をこの本では想定していて、様々なシナリオを提示しつつ、３つの働き方のシ

インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。 http://twitter.com/#!/hyoshiok/status/33183999060873216 この「許可を求めるな。謝罪せよ」というフレーズは@kawagutiに教えてもらったのだが、彼は@hiranabeから３Mの社是として聞いていて、その心はというと、ともかく試してみてうまくいかなかったら、その時また考えるというような趣旨の行動規範ということらしい。*1 関係各位の許可を求めていたら絶対物事は進まないし、何も始まらない。何かをやってうまくいくこともあれば失敗することもあって、その試行錯誤によって人は学

先日、会社でレガシーコード改善ガイド読書会を行った。1回しかやっていないので、今後どんな感じになるのか正直わからないが、1回目の振り返りを記してみる。 〆会、テスト勉強会（社内）などで有志を募ったところ、なんやかんやで10数名が名乗りを上げてくれた。どんなペースでやるかとか運営をどうするかとかを相談するために、参加希望者で集まった。週1回（木曜日、19時開始）、担当の章などを決めた。第1章〜第5章までは各自で読んで、読書会への参加の動機などを含めて簡単なポジションペーパーとしてまとめることにした。 わたしが、読書会の世話役として、会議室の確保（空き会議室を見つけて予約しただけ）、開催のアナウンスなどを行った。資料置き場の共有ディレクトリ、社内Wikiなどを立ち上げた。*1 テストがないコードはレガシーコードだ！ 「テストがないコードはレガシーコードだ」という強烈なフレーズが表紙に書いてある

20数年前に大学を卒業しプログラマになって、この変化のとっても早い業界でまだ禄を得ている。最近でこそコードを書くことはないが（今でも職業としてコードを書きたいと強く思っている）、それでも、ソフトウェア開発について20数年前に得た知識、経験、スキルが役に立っているように思える。 日進月歩で日々新しいバズワードが登場し、若い人たちはそれをフォローするのにひーひー言っている。クラウドだアジャイル開発だなんだかんだ。 プログラマの一日は、会社に来て、テストを書いて、テストをして、不具合があればコードを修正し、またテストをして、問題がなければコード管理システムにチェックインする。その作業を淡々と日々こなす。この日常の流れというのは、使う道具立てこそ変わったとしても、基本的に変化がないように思える。コードを書くのは20数年前も今もプログラマだし、テストを書くのもそうだし、テストを自動化することは20数

仕事で文書を書く必要がある人は「理科系の作文技術」(ISBN:9784121006240)を読むべきだ。 ここでいう仕事で書く文書というのは他人に読んでもらう文書をさす。他人に読んでもらうことを前提としないメモの類や狭義の日記などはこれにあたらないので、どう書こうが構わない。他人に読んでもらうことを前提とした文書は、相手に内容が伝わらなければ意味がないのだから、間違いなく相手に通じるように表現しなければならない。 小説、詩などの文学作品は、ここでいう「仕事で書く文書」に含めないことにする。文学作品と対比して、仕事で書く文書の特徴はどこにあるのか。それは、読者に伝えるべき内容が事実と意見にかぎられていて、心情的要素を含まないことである。 仕事の文書を書くときの第一の原則は、「必要なことは洩れなく記述し、必要でないことは一つも書かない」ことである。何が必要かは目的により、また相手の要求や予備知

インターネットの未来の一断面を「総表現社会」と梅田望夫は「ウェブ進化論」（2006年）の中で希望をもって述べた。3年たった今日現在、日本という地域では、インターネットを能動的に利用する若い世代（おそらく40前後がその上限）、あるいはヒマ人以外には、表現をする人というのはほとんど現れていない。少なくともわたしと同世代（50歳前後）にはそのような表現をする人はほとんどいない。 例外的なアルファーブロガーというのはいることはいるが、梅田が期待したような、「不特定多数無限大」として1000万人程度の表現する人々は出現していないように思える。 例えば、わたしの世代では、中間管理職として企業の中核を担いつつ、家庭では子供が中学、高校、大学と、進学だ教育だというところで悩み、住宅ローンの返済に追われ、両親の健康状態が心配というような世代なのだが、彼らはほとんど表現していない。日々の日記として、会社の愚痴

文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる