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

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

プログラムを作ることはそれほど難しいことではない。それを製品にしてビジネスとすることは非常に難しい。「正しくものを作ること」より「正しいものを作ること」のほうがはるかに難しいのである。 いわゆるウォーターフォールモデルでは開発プロセスの初期に仕様を固定してそれを「正しく作る」事に注力する。１千行あたりのバグ数とか月当たりの生産コード行数などが、いかに「正しくものを作ったか」の生産性の指標になる。ソフトウェアファクトリとか日本のソフトウェア産業の得意とするところである。開発プロセスの初期段階で仕様を固定するので、状況の変化とか、顧客の要求の変化とかには取り合えず目をつぶるので、作られたものが顧客に必要とされているものかは、ものができてみないかぎりよく分からない。まあ、原子炉の制御システムみたいに信頼性が絶対条件だとか、システム要件が何年経ってもほとんど変化しないものには、そーゆー開発プロセス

本日開催した、「声優ハッカソン」に審査員として参加した。 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 会場の様子 伊勢さんと森藤さん 及川さん 会場から、会社から勉強会の参加が禁止されているという話を聞くのですが、そのような場合はどうしたらいいですか、という趣旨の説明を受けた。 世界はソフトウェアで出来ているという時代にわれわれは生きている。ソフトウェアは人が創る。そのためによい人材を雇用するのが経営のトッププライオリティになる。勉強会への参加や発表を奨励することはあっても禁止することはナンセンスだ。そんなこともわからない経営者

Regional Scrum Gathering Tokyo 2015に参加した。 http://2015.scrumgatheringtokyo.org/ Day 1 program Regional Scrum Gathering Tokyo 2015: Schedule 朝からJames Coplienの話を生で聞けるなど豪華なセッションがあって、お得感満載なイベント。産業技術大学院大学もスポンサーになっていてenPiTのちらしなどを配布していた。弁当もがっつりでていた。美味しかった。 (James O. Coplien) スクラムについての誤解などを解説、議論していた。わたしはスクラムの基本を彼から習ったので、そーゆーもんだと思っているが、ちまたに流布されているスクラム的なあれやこれやについて、それは違うというスタンスで解説した。ある意味、そもそもなんでスクラムが必要なのかというと

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

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

DevLOVE甲子園2014 西日本大会 - DevLOVE関西 | Doorkeeper 会社の勉強会（毎週火曜日17時からゆるゆる開催）でDevLOVE甲子園2014西日本大会に出場した田中選手の追加公演を観戦した。大阪会場とは社内TV会議システムを利用し、東京の第二会場、仙台などともつなぎ中継した。（荻野さんいつもありがとう） （おかしや飲み物を飲み食いしながら聞いた） 内容は2010年入社の新人エンジニアが、数々の困難に立ち向かいながらも徐々に成長していくというロードムービーなのだが（この設定が泣ける）、周りを固める、脇役がいい。主人公がどうにか仕事にもなれたとき、上司が異動する。主人公は一人になる。途方にくれる。いきなりピンチである。無理だ、自分には絶対無理だ。しかし、持ち前のがんばりと周りの協力もあり、師匠がやっていた姿をまね、最初の困難をどうにか切り抜ける。秘伝書を楽天ブック

楽天グローバル人事部の企画で温泉ハッカソンが開催された。 温泉ハッカソン いそいそ東海道五十三次を歩いて参加した*1 ハッカソンと言うのは、シリコンバレーあたりのスタートアップが、半日から一日くらいでちょっとしたプロトタイプを作るというイベントで、最近では日本でもあちらこちらで開催されている。サービスとかちょっとしたツールを作ったりすることが多い。独りで作る場合もあれば数人でチームを組んでやることもある。企業内で行うこともあれば、誰でも参加できるものもある。作ったものをコンテスト形式にして表彰する場合もあれば、単に作ることを目的にする場合もある。 今回の温泉ハッカソンは、学生向けイベントとして企画されていて、温泉という非日常とソフトウェア開発を掛け合わせた、世界初の試みと言える（笑）。学生は３人一チームとして参加し、24時間でなにがしかのソフトウェアを作る。最後に全チームでプレゼンをして、

サイボーズ式の小崎さんのインタビューが面白い。*1 仕事が楽しくなくて、後ろ向きな動機からはじめた仕事が本職になっちゃうとか、人生のなかで二つの俺プロジェクトとか、仕事をサボって勝手にやってみたらうまくいったとか、なかなか面白い。 言われたことをちゃんとやるというのは重要だけど、言われたことしかやらないというのでは成長がない。勝手に何かをやって、学んでいくと言うのが成長には欠かせない。 自分にとってもオープンソースなんかは業務とは一切関係ないところからはじめていつのまにかにそれが仕事になっていて、あまつさえ会社を立ち上げてしまった。 Googleの20％ルールはそれを制度化したものとして有名だが、正式な業務以外を勝手にやるものをシャドーワークとか、スカンクワークとか言う。社内でそれを黙認したり、むしろ奨励したりする企業もある。DECはそのようなプロジェクトをミッドナイト・プロジェクトとよん

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

永瀬さんとやっているアジャイル開発手法特論の授業が無事終了。 enPiT BizSysD – 産業技術大学院大学 最後に試験と授業のアンケートを取って、その後、皆さんと打ち上げ。青物横丁のいさりびでわいわい。 いくつかの反省点・感想など。順不同アトランダムに記す。 授業へのフィードバックをどのように生かすか。来年へ向けてということだと、イタレーションが一年になってしまって、全然俊敏じゃない。毎週なんらかの形でフィードバックを貰ってそれを次の授業に生かすというような仕組みがあったほうがよかった。 わたしの講義は、手を動かすのではなくて、単なる授業になってしまっていて、一方通行になってしまった。手を動かすのは課題でやってもらったのだけど、一人一人への指導というところは手薄になった。授業時間中にワークショップをやるというのは学生が40名以上いると物理的に目が届かないので難しい。継続的デリバリーっ

講演とパネルディスカッションに参加した。 第8回システム管理者 感謝の日イベント システム管理者のための夏期講習2014 すべての企業がITを武器にする時代のエンジニア魂を考える 大成建設の田辺さんのお話はお話がすごかった。建設業の場合、多くの協力会社と案件毎にプロジェクトを作っていくわけだが、大成建設では5700社ほどの会社とASPを利用して情報の共有をしている。 約50％の契約書が電子化されているそうである。直接的なメリットとして印紙を貼る必要がないので、協力会社のコストは年間約２億円のコスト削減になるそうである。 国税庁ホームページリニューアルのお知らせ｜国税庁 国税庁ホームページリニューアルのお知らせ｜国税庁 建設業では、紙を利用して図面などを共有しているという印象があったが、IT業界よりよっぽど電子化が進行している。電子署名を利用した契約書の電子化ってどのくらい進んでいるのだろう

社内勉強会は参加者の利便性を考えて昼休みに開催することが多い。昼休みならば、時短勤務のお母さんも参加できるし、夜学に通っている人でも参加できる。 とは言え、社外の人を講師として呼ぶ場合は、必ずしも昼休みにお願いするということが可能とは限らない。その場合は、夜7時ごろから開催になる。 今回たまたま開催した勉強会では、参加者が少なかったこともあって、各自自己紹介をした。そうすると意外と協力会社のパートナー（常駐）エンジニアの方が多かった。 今まで気がつかなかったのだけど（人数が多いときは自己紹介をしないので）、パートナーさんの勉強会に対するニーズというのは潜在的には大きいのではないのだろうか。勤務時間中の勉強会の出席は契約にもよるだろうけど、勉強会は業務ではないのでパートナーさんが参加することは難しい。勤務時間外であれば、問題はない。 職場での勉強会のメリットは移動時間がゼロというところもある

産業技術大学院大学のenPiTという講座で、永瀬さんと共同でやっているアジャイル開発手法特論の授業が今日から開始した。 この授業は事前学習科目という位置づけで、秋に開講予定のPBL (Project Based Learning) を実施するのにあたっての、前提となる知識やスキルをみにつける。ここでは座学でアジャイル開発手法を学ぶ。40人を超える受講者が集まって、昨年より遥かに多いのでちょっと大変かもしれない。昨年は10数人。琉球大学の学生さんもTV会議システムで遠隔地から参加する。TV会議システムの設定に手間取ってしまって、ご迷惑をおかけした。来週はもう少しうまくやりたい。 参加者のみなさんの自己紹介などを聞いた。各自、強い思いを持って参加されていて、その期待に答えるために全力投球をしないといけない。これからの半年間、楽しみである。 enPiT BizSysD – 産業技術大学院大学 e

社内勉強会はほぼ英語でまわしている。社外の人に講演をお願いする場合が、最近の悩みは、日本において英語で講演することをカジュアルにできる人が少ないことである。多分どこかにいるのだろうとは思うのだけど、自分の知り合いで、ちょっと勉強会でお話ししてよと頼める人となるとググッと少なくなる。（先日はMickさん、ありがとーございました） 英語で発表するよーーという奇特な方はぜひご連絡ください。お願いします。 日記の日付を間違えてアップしてしまった。本文は http://d.hatena.ne.jp/hyoshiok/20140402/p1 を参照してください。ブックマークとかもあるので、エントリはそのまま保存する。 id:hyoshiok:20140402:p1

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

先日の話の続き。 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど） http://d.hatena.ne.jp/hyoshiok/20140115/p1 昔fjというインターネットの掲示板みたいなものがあった（今でもあるけど）続き http://d.hatena.ne.jp/hyoshiok/20140118/p1 さすがに長いけど、fjからのコピペはこれで最後になる。 https://groups.google.com/d/msg/fj.comp.oops/FnllPLAnNUg/_m2HEa5QpGMJ Hirotaka Yoshioka 1998/06/02 "SENOH Yasushi" writes: > 妹尾です。 > >いずれにしてもなんとなく > >私の賛成していない設計とプログラミングの分離を前提にしている > >ような気がするんですが…． > 私

昨日、はてなエンジニアブロガー祭りなんかに行ったものだから、なぜブログを書くのかとか、炎上しちゃったことはないかとか聞かれた。 http://developer.hatenastaff.com/entry/2013/12/03/132719 考えた。自分の日記が炎上した記憶はほとんどない。ちょっと釣り気味のタイトルを付けたことはあっても、炎上を狙って日記を書いたことはない。ブックマークがいっぱいついた日記はあるし、そのブックマークのコメントがちょっと上から目線でイラッと来たことはあっても、それによって多くの人から非難囂々ということは多分ない。というかそのような記憶はない。あったとしても忘れているのかもしれないけど。 どう考えても犯罪とか、極度に反社会的な意見を持ってそれを世界に情報発信だーーみたいなことをしていないので、例えば、飲酒運転なうとか、バカ発見機に発見されることはない。もちろん飲