納品のない受託開発でおなじみのソニックガーデンの倉貫さんの新刊だ。一気に読んだ。 そもそもの問題意識として、判断の難しい現代の仕事において、コントロール型のマネジメントでは上司やマネージャがボトルネックになっている（6ページ）というのがある。 とはいうものの流石に管理をしないで成果を出すことができるのだろうか？という疑問に答えるのが本書だ。 一気に管理なしというところまでは行かないので、段階を踏んで成果を出す働き方を提案している。 生産的に働く（楽に成果をあげるために見直す） 自律的に働く（人を支配しているものをなくす） 独創的に働く（常識や慣習に従うことをやめる） 管理するのは成果を上げるためなのだけど、管理そのものを目的化してはいないか。成果が上がるのならば、何も生産しない管理をなくしてしまえばいいという発想である。なかなかすごい。 人を動かすのは鞭なのかアメなのか。本書で提案している

9月末に60歳定年退職して、東京大学大学院情報理工学系研究科電子情報学専攻博士課程に入学した。*1 9月末より現役の東京大学生である。博士課程の大学生がどんな生活をしているのか、日記を認めることにどのような意味があるのかという疑問を持たなくもないが、定年退職後のおじさん学生の日記も多くないので自分の経験がだれかの役に立つかもしれないと思い記すことにする。 授業のことなど 9/21に入学式があって、その次の週から授業だが、自分が履修する授業は、10/1の週から開始だった。 輪講（必修）が金曜日午前中にあるので、9/28にいそいそと学校に行ったら、次週から開始ということで、いきなり空振りになってしまった。 図書館で時間を潰していたら、研究室の修士1年生のSさんが声をかけてくれたので、二人で生協食堂で昼飯を食いに行った。初ランチである。（緩募。ランチ友達） その足で会社に行って最終出社日の各種手

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

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

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?を読んだ。 編集の傳さんから直々の献本。ありがとうございます。 先日読んだ、倉貫さんの「納品」をなくせばうまくいくが面白かったという日記 *1 を読んだ傳さんが送ってくれた。 刺激的なタイトルである。副題が「これからのSIerはどう生き残ればいいか？」である。このままでいいのか、いやいいわけはない、という問題意識の本である。 わたしは、SIerでもないし、SIerに勤めた経験もないので、あくまで部外者の感想にしかすぎないのだけど、本書で述べられていることはいちいちその通り、おっしゃる通りである。 IPAの「IT人材白書2014」からの引用があるが、それが衝撃的で、ユーザー企業が今後新規／拡大をしていく分野（SaaSやPaaSなど）、IDCサービスへのSIerの関心は低く、SIerの今後の新規／拡大を予定している事業に

エンタープライズ系ってなんだろう。ウェブ系ってなんだろう。勝手に脳内イメージを言語化してみた。読者諸氏のコメントを待つ。(想像でものを言っています) エンタープライズ系 ウェブ系 開発手法 ウォーターフォール アジャイル 開発 外注 内製 会議 多い、長い 少ない、短い 資料 人数分カラー印刷 印刷なし 進捗管理 エクセル バーンダウンチャート ソースコード管理 ファイル名日付 Git 服装 スーツ Tシャツ 新技術の取得 ベンダーのセミナー 勉強会 テスト 人海戦術 自動化している 休日の過ごし方 休日出勤 趣味のプログラミング 休日の過ごし方、その２ ゴルフ 趣味のプログラミング、子供と遊ぶ ダイバーシティー 最近結婚してやめた人がいる 最近外国籍の人が増えている 上司 年上 年下もいる 飲み会 おじさんばっか おたくとコスプレ 転職 したことがない 同業他社から転職して来た 趣味、尊

スゴ本オフは、みんながすごいと思っている本（スゴ本）を持って来て紹介するオフ会。場所は先日おじゃました、渋谷のHDEだった。（渋谷方面から代官山、恵比寿、目黒方面の見晴らしが素晴らしかった） 今回のテーマは「グローバル」。グローバルしばりのスゴ本がいっぱい紹介されていた。 初めての参加だったのだけど、飲み食いしながら本のお話をする。ちびっこたちも参加していて楽しい。 わたしも適度に酔っぱらった。（いつものことだけど） 最後に、紹介した本の交換会があって、それも楽しい。 紹介された本のリスト。すごいなー。 http://calil.jp/recipe/5258917525323776

今日の読書会は、ちょっと雑務でごたごたしていて、遅れぎみだったら早瀬さんから電話がかかってきて、「ビール足りないすよ」ということなので、近所のコンビニによって、ビールとつまみを調達して参加した。いつのまにかに、参加者が8人になっていて、毎回会を重ねるごとに徐々に増えてきて喜ばしい。 「ビールです」（どや顔）。「お〜〜〜」（一同）。 今日は第4章「Implementing a Test Strategy（テスト戦略の実装）」。るかさんが綺麗なプレゼン資料を用意していて、それをもとに皆であーだこーだと議論を深めた。 テストの類型でBusiness-Facing vs Technology Facingという軸とDevelopment Process vs Critique the Projectの軸というBrian Marickが提唱した4象限のものを使いながら説明して、自動化できるもの手動で

釣りの仕方を教えてもらうという機会は人生においてそうそうあるものではない。老子曰く「授人以魚 不如授人以漁」。魚を与えるのではなく、釣りの仕方を教える。ということらしい。*1 新卒は、研修でいろいろな釣りの仕方を教わっている最中かと思う。新人ゆえの特権だ。中途入社の人間は基本的には放置というのが世の常だろう。釣り方は既に身につけているという前提で雇用されているのだからしょうがない。 よく考えてみると例えばDebugの方法とか誰かに教わったかというと多くの人は見よう見まねでどうにか自分のスタイルを確立していったのではないだろうか。いまでこそ、テストの方法とか、ソースコードの読み方のような書籍があるけど、そのようなものは例外的な存在のような気がする。 IT業界のような変化の激しい業界では、2年前には影も形もなかった技術がぽっとでてきて業界を席巻しているようにみえる。そして、そのようなものは当然

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

奇妙な名前の同好会を作ったのは約半年前である。半年同好会の会長（ぐはは）をしてみての振り返りをしてみた。 勉強会勉強会*1というこれまた奇妙なコミュニティをかれこれ二年くらいやっていて、勉強会に関するちょっとしたノウハウ、運営上必要になる情報等をいろいろな人やコミュニティと共有してきた。勉強会というか勉強家愛というか、勉強会が好きでしょうがない、手段と目的を履き違えたような多様な人たちといろいろ集まってみて、IT系の勉強会のあれやこれやについてそれなりに経験をつんできた。 その勉強会がもつパワーというかお金に変えられない価値を会社の中に持ち込むという試みが社内勉強会なわけであるが、そもそも勉強会というような形式は、自分の周辺で同じような問題意識、興味を持った人たちが自主的に開催するものだから、自分の半径5メートルが会社しかない人にとっては、必然的に会社の人と勉強会をすることになる。むしろ社

自称勉強会マニアと呼ばれている@hyoshiokです。（それって自称じゃないじゃん。セルフツッコミ） それはともかく、勉強会の達人は「勉強会に勉強しにいくのは素人」とか、勉強会はあくまで手段であって目的ではないとか、勉強会マニア（苦笑）とか、まあいろいろ言っているわけであるが、わたしも勉強会について一言いっておく。 勉強会は主催者発表者参加者それぞれの思いがありそれぞれ渾然一体となって出来上がっているから同じものは世界に二つとないし、同じ主催者の勉強会でも毎回毎回微妙にことなるライブなセッションである。十人十色である。 なので、勉強会はなになにでなければいけないとかなになにであるべきだというものは一切ないし、自分が「これが勉強会だ」というようなことを言うつもりもない。 一方で勉強会に集う人々、主宰する人々、それぞれにある種の共通の価値観みたいなものはあるような気がする。十人十色なので全員が

先日、@tsudaさんが、http://twitter.com/#!/tsuda/status/26536546973 なので、エンジニアの方は、転職を今現在考えてる、考えてないは関係なく、エンジニアが「金銭」以外の条件で職場に求める条件／環境／待遇などを書いていただければありがたいです。もしお手間でなければハッシュタグ #engineerenv を付けていただければ。 なる書き込みをしていて、ハッシュタグでいろいろ議論が炸裂していた。下記にまとめがある。 http://togetter.com/li/57088 今の職場の（１）良いところ（あれやこれや）、（２）悪いところ（あれやこれや）と、仮に転職するとして、その候補となる会社の（３）期待値（あれやこれや）、（４）転職するにあたっての手間暇（あれやこれや）をざっくり天秤にかけて、いまのところにとどまるインセンティブA＝1-2、転職のイン

日時：7月8日(木)18:30開場、19:00時ころ開始 お題：クラウドコンピューティングにおける仮想マシンのセキュリティ 発表者：須崎さん（産業技術総合研究所） 内容：クラウドコンピューティングでは仮想マシンが一つの主要な構成技術になっているが、このセキュリティ課題(I/O Fuzzing, Cross VM Side Channel Attack など)および対処について話します。日経コンピュータ 2010/03/31 の「仮想マシンに潜むセキュリティ問題」の内容を中心に議論したいと思います。 18:30頃　開場、LTないし自己紹介など 19:00頃　お題開始。 20:00頃　懇親会開始。ビアバッシュ。 21:00頃　中締め 場所は楽天タワー（りんかい線品川シーサイド、京急線青物横丁） http://www.rakuten.co.jp/info/map/shinagawa.html 会

昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交

会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識

わたしが学生だったころ（1980年代前半）の就職活動というのを思い返して見ると、高校生のときに漠然と大学の学部を決めて、大学生活を送るうちに希望の業界をイメージしていくという感じだった。 例えば、工学部であれば車が好きな奴は自動車メーカーに、経済学部であれば、商社とか銀行とか。工学部でも電気メーカーを希望するのは電気科とかであり、自動車メーカーを希望するのは機械科を専攻しているやつで、その逆はあまり考えられなかった。電気回路全然だめだよという奴は電気科にはいかないし、熱力学とか製図をとらない奴は機械科にはいかない。（必修がどうだこうだというより、自分の好きな科目とか得意な科目、あるいは苦手な科目を勘案の上、学部や学科を選択していくイメージだ） 高校生ころにざっくりとした学部の選択をし、大学生活を送りつつ、徐々に職業というのをイメージしていく。わたしの場合、2年生を二度やっているので（とほほ

先日、情熱プログラマー読書会が楽天であったので、参加した。LT(Lightning Talks)で発表もした。発表スライド 情熱プログラマー 自分にとっての情熱プログラマーってなんだろうと考えた。 この「情熱プログラマー」という書籍は、ソフトウェア開発者の幸せな生き方という副題がついているのだが、純粋な技術書というよりもプログラマーにとっての自己啓発書みたいな位置づけの書籍だ。 ソフトウェア開発におけるプログラマという役割を取り替え可能な部品のような立場から見れば、プログラマはコストであり、どのようにしてそのコストを削減するかということになる。コストを安くするという考えで行けば年功序列的な賃金体系の中ではベテランより若いひとを使った方が安く上がる。数字でソフトウェア開発を見ていけば人月工数がすべてであり、開発コストは工数＊人月単価になる。 そのような立場で言えば人件費の高い日本で開発するの

丸山先生レクチャーシリーズ2010(以下、丸レクと記す)、第3回2010年4月22日(木)楽天株式会社(http://www.itmedia.co.jp/enterprise/special/dev_marulec/2008.html )でお話をした。題して「楽天インターネットスケーラブルコンピューティング」 丸山先生は並行、並列、分散などを大変わかりやすく説明されていた。首藤さんは、Key-Value-Storeについて基礎知識を解説された。藤本さんはGREEで開発中のFlareなどのお話、古橋さんはお馴染みのkumofsとそのデモ。どれも技術的に素晴らしい発表であった。 でもって、わたしの番なのであるが、特に技術的に目新しいことではなく、楽天のWebサービスのインフラの歴史とか、どんな感じで日々のトラフィックをさばきながら発展していったかという実に地味なお話であった。 楽天インターネッ

社内勉強会だろうが社外で発表する勉強会だろうが資料の作り方にさほど差はない。しかし、社内勉強会の資料を社内のプレゼンと同じ要領で作るといろいろ面倒な事がある。 社内の勉強会の題材が自社のシステムとか業務とか仕事に直結したものであれば、社内の標準的な資料作りのテンプレートでもなんでも流用して作ればいい。 そうではなくて、オープンソースソフトウェアに関する勉強会とか、定番の教科書の読書会のような社外秘は一切ない類の勉強会の資料はできることならば公開したくなるのが人情である。 情報は公開した人のもとに集まるというのが世の常である。情報を公開してそのメリットを甘受した経験のある人はそれを理解しているので、可能であればそのような情報を公開したくなる。わたしもその口である。 社内勉強会なので何も考えずに社内発表用のテンプレートを使うと、脚注にCopyrightとか社外秘とか、その手のマークがデフォルト