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

タイトルは釣りです、すみません。無駄に長いのでお忙しい人は、どーぞ、飛ばしちゃってください。 自分は今年の9月で満60歳になる。60歳というと多くの日本企業の御多分にもれず定年である。定年後に何をするのかしないのか、ここで簡単に記してみる。 日本の伝統的な大手企業（経団連に属するような企業）では、定年などの制度がしっかり整備されているので、先輩たちがどんな暮らしをしているかおおよそのロールモデルがある。一方で自分が今所属している企業は20年ちょっと前に創業したネット系である。規模は大企業だが相対的に若い企業なのでそもそも50代の従業員がそんなにいなくて定年退職した人も数えるくらいである。 日本において職業プログラマの世界では、特にフリーランスではなくて会社に所属している場合、35歳定年説というのが炎上系のネタとしてよく議論される。特にSI系の場合、多重下請け構造の中で歳を食ってプログラミン

理科系の作文技術(中公新書)という1981年に発行された名著がある。 先日、その本についてお話しする機会があったのだが、それを話すにあたって、作文技術の本をあれやこれや手に取ってみた。本屋で適当に見つけたものやら図書館で手に取ったものなど、備忘録としてリストしておく。必ずしも読了、精読したわけではない。（順不同） それぞれについて、理科系の作文技術との比較などをしてこの日記をアップデートしたい。（2017年6月1日時点で整理中です） 理科系の作文技術（リフロー版） (中公新書) 【新版】日本語の作文技術 (朝日文庫) 論文の書き方 (岩波新書) 論理が伝わる 世界標準の「書く技術」 (ブルーバックス) レポートの組み立て方 (ちくま学芸文庫) 仕事文の書き方 (岩波新書) 理系のための 論理が伝わる文章術 実例で学ぶ読解・作成の手順 (ブルーバックス) The Elements of St

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

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

本日開催した、「声優ハッカソン」に審査員として参加した。 https://apps.rakuten.co.jp/special/rakkathon201602/ 声優ハッカソンというのは、プロの声優の声を使ったアプリを作るというイベントだ。何を言っているか、実のところわたしも参加するまでわからなかった。頭の中に？マークがぐるぐるしながら参加した。 アプリの題材はなんでもいい。ゲームでもいいし、VRやARでもなんでもいい。ゲームであれば、ナレーションをプロの声優にやってもらう。とかなんとか。 2日間でアプリを完成して、最後に2分間のプレゼンをする。 プレゼンの評価ポイントはデモである。どんなに高尚なアイデアであろうが実装されていないものに価値はない。ハッカソンは作ってなんぼという価値観が支配している。 それを勘違いしているグループがいくつもあった。 自分は審査員として、どんな作品もなるべくい

勉強会コミュニティCROSS2016に行って来た。チラシ200枚と楽天のステッカー500枚を配布した。 http://2016.cross-party.com/ 会場は今年も横浜港大さん橋ホール。天気にもめぐまれ気持ちいい。 及川さん、伊勢さん、森藤さんとのパネルディスカッションに出た。 http://2016.cross-party.com/program/x4 会場の様子 伊勢さんと森藤さん 及川さん 会場から、会社から勉強会の参加が禁止されているという話を聞くのですが、そのような場合はどうしたらいいですか、という趣旨の説明を受けた。 世界はソフトウェアで出来ているという時代にわれわれは生きている。ソフトウェアは人が創る。そのためによい人材を雇用するのが経営のトッププライオリティになる。勉強会への参加や発表を奨励することはあっても禁止することはナンセンスだ。そんなこともわからない経営者

キーノートはドワンゴの川上さん。はじめて講演を聞いたのだが、キレキレで面白かった。言いたい放題。 クラウドの登場でウェブエンジニアが簡単にサービスを作れるようになった。それがエンジニアの質の低下を招いているのではないかという指摘をしていた。 スクリプトエンジニア、コンピュータの動作原理を知らないエンジニア、性能の理論的限界を計算できない、開発手法の宗教的依存度が高い、自分の頭で考えるより結果をググって覚えるだけ。二流のエンジニアの大量生産という現象を指摘していた。 自分の会社の会長が、エンジニアをdisるというのは自分がその会社にいたらちょっときついなあという印象を持つのだけど、ベースには技術者に対する愛があるので、ちゃんとコンテキストを理解すれば、そんなこともないのかなと思った。 一つ一つを文脈を無視して切り取ると誤解を招きかねないフレーズである。技術者に取ってのレッドオーシャンを避ける

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

Tech-Party CROSS ビールが始まる前のパネルディスカッションという名の雑談セッションに参加した。 先達に聞くこれからのエンジニア像 会場はこんな感じ。 （山口さん撮影） パネルが始まるまでの一コマ。 （黒崎さん撮影） こんな感じのパネルディスカッション。 パネルというのは話が予想もしないところに行くのが面白いのだけど、通常は予定調和的なところに行ってしまいがちだ。結局、打ち合わせと言う名の飲み会での話が一番面白かったりする。この飲み会をそのまま配信しちゃえばいいんじゃね的な打ち合わせを司会（予定）の森藤さんがメモを取って、そのメモをベースにパネルの構成を考えてくれた。 ところがその森藤さんがインフルエンザでダウンして急遽実行委員長の山口さんが代打で司会を担当することになった。山口さんが森藤さんの残したメモをもとに司会進行すると言うアクロバティックなものになった。森藤さんの言語

2014年は毎日毎日日記を書いた。何日か貯めて一気に書いた日もあったがエントリーとしては365日すべて書いた。 2013/12/14から継続して書いているので、本日で382日間継続中(のべ1219日)である。 記事一覧 - 未来のいつか/hyoshiokの日記 記事一覧をみると、2004年3月に日記を開始し、その年は毎月一つ以上のエントリーを書いている。そして、毎月一月以上書くのは2011年まで続いている。2012年と2013年はまったく日記を書かない月が２ヶ月ほどあった。2013年12月14日に、はてなのブロガーイベントに参加して、それをきっかけにとりあえづ一年間は毎日日記を書いてみようと思ってそれを続けた。 日記を書くというのは極めて個人的な作業である。ジャーナリストや作家のように誰かのために職業として書く訳ではないので、実にお気楽な情報発信で、通常、責任というものはほとんど発生しない

IT系イベントを見つけるための定番はIT勉強会カレンダーなのであるが、最近更新頻度が下がっている。*1 そこで下記のカレンダーがお勧め。いくつかのイベント登録サイトから自動的に情報を収集してアグリゲーションしている。網羅性が高い。 http://eventdots.jp/events/calendar やまのように勉強会とかイベントあるねー。すごいねー。だけど知らない人は全く知らないし、勉強会に参加したこともない。もったいないもったいない。 たまには残業しないで勉強会に行ってみよう。違った世界が見える筈である。 *1:IT 勉強会カレンダー

Twitterなどで返事（リプライ）がひどいものをクソリプ（クソみたいなリプライと言う意味か）と言うらしい。 例えば、下記のような例がある。 特にどうというものでもない言明に対して、いろいろな角度からツッコミがはいる。どーでもいいだろうと思うようなツッコミだらけになって何を話題にしているかすら定かではなくなる。 「XはAである」という記述に対して「AでないXもあります」「AなXが嫌いな人もいる」（あといろいろどーでもいい言明が続く）などなどリプライがついてくる。それをクソリプというらしい。 クソみたいなリプライなので、事の本質からどんどん離れて行く。何か生産的な議論がされるわけでもない。時にはけんか腰の言い合いというか罵り合い発展したりする。 最初の書き込みが、単なる記述で、そこに価値判断（良い悪い）などが含まれていようがいまいが、クソリプが返ってくる。 豆腐の色なんて、どーでもいいわけで

先々週は楽天テクノロジーカンファレンスだったので、enPiT PBLの土曜日の全体会議は欠席した。その欠席した会議にオブザーバーとしてJim Coplein (Copeと称する)が参加していて、それぞれのチームにフィードバックをしていたようだ。先日、楽天ハッカソンでスタッフをしていたら、ふらりとCopeが遊びに来ていて、ちょろっと雑談をした。 PBLのミーティングの感想を聞いた。 このPBLは約10週間でウェブサービスをチームで作るというもので、毎週土曜日にすべてのチームが集まって進捗報告をする。その会議では、今週やったこと、問題点、来週やること、デモなどを行う。そのミーティングにCopeが参加した。 各チームのGithub リポジトリのReadmeにはエレベータピッチが書いてある。最初にそのエレベータピッチを復習して、今週やったことなどを報告する。 エレベータピッチのテンプレートは下記に

技術系カンファレンスなどでよく見かけるLTとは何か。 LTは数分程度（5分以下くらい）のショートプレゼンテーションで、時間管理は厳密に行われることが多い。例えば、5分と言えば、5分以上の発表はできなく、時間が来たら発表は強制的に打ち切られる。 1997年のPythonカンファレンスで行われたとされていて、Lightning Talksという用語が用いられたのは、YAPC 19100 (2000年に開催)と言われている。 日本における歴史はライトニングトークスの歴史(original version)が詳しい。 それによれば、日本で行われた最初のLTは2001年に開催されたYARPC (Yet Another Ruby and Perl Conference) 19101らしい。その後、Linux Conference 2001、XP祭などで行われたようだ。 http://www.jus.o

川口さんとランチであれやこれや雑談をして、社外の勉強会を社内でやることの面倒くささについてのお話になった。 弊社の場合、セキュリティの関係上、社外の人は、受付で入館証を記入の上、ビジターカードを受け取って、セキュリティーゲートを通って、会議室に入る。会議室まで社員のエスコートが必要になる。 社外の人が参加する勉強会を開催するとなると、１）受付、２）エレベータ、３）会議室までのエスコートが最低限でも必要になる。 数人の規模であれば、ロビーで全員待ち合わせて、同時に受付して、会議室までエスコートで、どうにかなる。10人を越えると、遅刻してくる人とかもいて、その度に受付までいかなくてはいけなくなる。さらに20人を越えるとビジターカードをあらかじめ準備しておかないといけないとか、さらに難易度が高くなる。 ある程度人数の大きな勉強会だと、結局、受付係、エレベータ係、会場係など複数人の社員が必要になっ

事務局のグローバル人事部のYukarinが幹事で青横の某居酒屋に集まって先日開催した温泉ハッカソンの反省会という名の飲み会をした。 わたしは反省会が三度の飯よりも好きというたちなので、やる気満々で参加した。 温泉ハッカソンというのは弊社グローバル人事部が企画した学生向けハッカソンで、正直言えば優秀な学生さんと出会いたいという下心が見え見えなイベントである。最近ではインターンシップとか企業と学生の出会いの場が増えているが、そのような活動の一つとして考えられなくもない。 新卒の定期採用という仕組みが制度疲労を起こしているとかいないとかはここでは議論しない。いい悪いは別として、日本と言う地域においては正社員を雇用する方法として新卒採用というのが大きな比重をしめている。 就活というある種、不毛な活動で学生も企業も疲弊している状況のなか、開発系人材をどのように発掘し雇用するかという課題が企業側にはあ

数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース（OSS）を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1

若い人には想像もつかないことだとは思う。おじさんの昔話だ。興味のない人はこんなどーでもいい話なんで飛ばしちゃってほしい。 あなたのお父さん、お母さんが青春だったころの話だ。 30年前（1983年ごろ）、わたしは大学院の学生だった。その年の春に東京ディズニーランドがオープンした。 当時は携帯もなかった。携帯がないころの待ち合わせと言うのをあなたは想像できるだろうか。そんなころの話だ。 飲み会を企画したとする。お店のあたりをつけ、参加者を確認し、予約をする。午後七時に店を予約したとする。現地集合でもいいのだけど、多くの場合は、最寄りの駅で集合していそいそとみんなでお店に行くというのがよくあるパターンであった。 例えば７時開始だとすると、６時４５分くらいに駅で集合して、お店に行く。携帯を持っていないので、当日遅刻すると大変なことになる。時間厳守である。 ７時頃渋谷に集合で店は予約していないんだけ

FacebookのHacker Wayという行動原理のなかに、Done is better than perfect（完璧よりもやることだ）というのがある。IPOのときの目論見書にそれが書いてある。 Registration Statement on Form S-1 The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it ― often in the face of people who say it’s impossible o