未来のいつか/hyoshiokの日記

■ 英語の本の読書会をやっていると日記に書いたら、それがきっかけで勉強会を開催した

情報を公開するとそれがきっかけでさまざまなことが起こる。そして、その波紋がとってもいい形で自分に戻ってきた。そーゆーことである。

Continuous Deliveryの読書会をしていると日記に書いたのが、「Continuous Deliveryを読む。」id:hyoshiok:20111106#p1 で、その続編が「IT産業には民族誌が必要だ」 id:hyoshiok:20111108#p1 で、それがPublic Key で「開発現場のノウハウをもっと共有して、ハッカー文化を企業に根付かせよう」として取り上げられた。 http://www.publickey1.jp/blog/11/post_190.html 自称プロの酔っ払いとして華々しくPublic Keyでデビューすることになった。そして、わたしの日記を見たJenkins実践入門の編集担当の傳さんがContinuous Deliberyを読んでいるならJenkinsにも興味があるだろうということで、わたしに同書を送付してきたのである。それをぱらぱらめくったところ、これはすごいということで、「Do not convince your boss but do it. (上司を説得しようとするくらいなら、とっととやれ)」 id:hyoshiok:20111115#p1 の最後に紹介した。

Jenkins実践入門を、技術評論社の傳さんからいただいたのだが、若手の迷えるエンジニアには、四の五の言わず、とりあえずこれでも読んでJenkinsをインストールしてCIしちゃえ、話はそれからだ、というようなことをそそのかしておいた。

そんな日記を書いたところ、なんと著書の佐藤さん(@lino_s)から

Jenkins実践入門を紹介していただき、ありがとうございます 未来のいつか/hyoshiokの日記 「若手の迷えるエンジニアには、四の五の言わず、とりあえずこれでも読んでJenkinsをインストールしてCIしちゃえ」@hyoshiok ow.ly/7v8kl

https://twitter.com/#!/lino_s/status/136752888776110080

と思いもかけぬところからのパスが。

そして、Jenkins実践入門をネタに勉強会をしたいと強く思っている自分がいた。CDの読書会で、同書を紹介して、著者にお話をしてもらおうと考えていると言ったところ満場一致で支持され

@lino_s 勉強会を開催していただけませんかー。

https://twitter.com/#!/hyoshiok/status/136925578266812416

というのをTwitterでお願いした。もちろん @lino_s さんとは一切面識がない。Twitterで面識もない人にいきなりお願いするわたしもわたしであるが、だめもとである。断られても、スルーされても、わたしには失うものは一切ない。返事がくればめっけものである。ノーリスク・ハイリターンな状況である。

暮れの忙しい時期であるが、日程を調整して、一昨日、Jenkins実践入門勉強会をして開催した。楽天トラベルのYuさんに事例を紹介していただき、その後佐藤さんに発表してもらった。その事情が「Jenkins実践入門勉強会@楽天さんでお話しました。スライドも公開!」 id:lino:20111222:1324602763 で紹介されている。

たっぷり時間をとっていたので、質疑応答、CIしている経験などについてじっくりできたのがよかった。会場の参加者からのコメントや質問が議論の深みを生み出した。いろいろ素朴な疑問が気づきがあったのが自分にとっての大きな収穫であった。

テスト勉強会（社内勉強会）を昨年実施したので、それの発展形としてCIについての勉強会を来年何度が開催したいと思った。

その後、場所を青物横丁の中華料理屋に移して飲みながら議論を深めた。いろいろリアルなお話を聞け勉強になったとともにとっても楽しかった。来年は会社のなかにCIやCDを広めていきたいと強く思った。わたしの野望としてここに記しておきたい。

英語の本の読書会をやっていると日記に書いたら、それがきっかけで勉強会を開催できた日であった。

佐藤さん、ありがとうございました。そして参加してくれた皆さんにも感謝します。

ツイートする

■Do not convince your boss but do it. (上司を説得しようとするくらいなら、とっととやれ)

今日の読書会は、ちょっと雑務でごたごたしていて、遅れぎみだったら早瀬さんから電話がかかってきて、「ビール足りないすよ」ということなので、近所のコンビニによって、ビールとつまみを調達して参加した。いつのまにかに、参加者が8人になっていて、毎回会を重ねるごとに徐々に増えてきて喜ばしい。

「ビールです」（どや顔）。「お〜〜〜」（一同）。

今日は第4章「Implementing a Test Strategy（テスト戦略の実装）」。るかさんが綺麗なプレゼン資料を用意していて、それをもとに皆であーだこーだと議論を深めた。

テストの類型でBusiness-Facing vs Technology Facingという軸とDevelopment Process vs Critique the Projectの軸というBrian Marickが提唱した4象限のものを使いながら説明して、自動化できるもの手動でやるものなどをあれやこれや話した。

わたしなんかは、テストなんかはほとんど自動化できるのだから手動でやるなんて意味がわからない程度の立場で過激なことを言いまくったのだけど、もちろん様々な大人の事情でそうもいかないということは、頭の上では理解しているつもりである。納得はしていないけど。

若いエンジニアが、Continuous Deliveryに影響され、やっぱ自動化テストですよね、CIですよねー、なんて言ったりするのだけど、「上司にどうやって説明して、CIを導入するのがいいんですか」というような質問を投げかけてきた。

そのわたしの回答が「Do not convince your boss but do it（上司を説得しようとするくらいならとっとやれ）」だ。

ちなみに、この読書会は、英語の本を読んで、英語で議論するというとんでもない読書会である。いやまさかと思うかもしれないが、Jonathanというシニアな人が参加してくれているおかげで、英語の勉強にもなって一石二鳥なのである。

非機能要件のテスト、例えばCapacity Test, Availability Test, Security Testなんかを自動化するにはどうしたらいいんだ、あーだこーだ。ここでCapacity testは性能とかスケーラビリティとか試験することとすると、production systemと同様の構成で同様の負荷をかけないとできないので、実施は難しい、それをどうやって、実施するのか、などということを議論した。

一番素朴な方法は本番環境と同じ環境をもう一セット用意して、それで検証するというものだが、プロプラエタリな高価なハードウェアと高価なソフトウェアを利用したシステムだとそれも簡単にはいかない。インターネット時代のベストプラクティスは、そのような高価なハードとソフトを利用するのではなく、コモディティのハードと、オープンソースを利用して、構築する。それによって、本番と同様なシステムを廉価に準備できて検証が行えるというものである。金がうなるようにあるんだったら高価なハードとソフトを使ってもいいんだけどね、みたいな議論をした。

まあ、極度に単純化しているけど、そのようなことである。

でもって、上司の話である。

君が本当にそれが正しいと信じているのならやればいい。それだけである。

上司を説得するのに貴重な時間を費やして双方消耗するくらいなら、Do the Right Thingである。もちろん、間違う場合もあるだろうけど、その場合はやり直せばいい。

許可を求めるな謝罪せよ。*1 *2

そのような価値観である。

今週のヨタ話ということで、自称プロのよっぱらいとして、publickeyで紹介されていた、ハッカー中心の企業文化とは何かについて、お話を続けた。*3

Kent BeckがXPでCIという言葉を初めて使ったのが1999年だそうだが、それよりはるか以前にわたしの日記でもあきらかのようにCIという名前ではないが、同様なプラクティスは大規模ソフトウェア開発の現場では日々普通に行われていた。

Release Early, Release Often（素早くリリース、しょっちゅうリリース）のような標語（？）は標語になる前から、現場では共有される価値観であった。

その価値観は、暗黙知として口伝で伝承されていて、外部に伝わるには民族誌で共有される以外にはほとんどなかったし、それが形式知になって、教科書に記述されるまで何年もかかる。今、この教科書を読んでいるそのエッセンスはわたしが、20数年前に新人としてエンジニアを生きてきた現場にあったがそれが記述されるまでにはそのくらいの時間が必要だということである。

IT産業で生き残る（笑）サバイバルガイドとしての民族誌を書くとすれば、まさにそのような暗黙知を丹念に記述したものにならざるを得ない。

上司を説得しようとするくらいならとっととやれ。

というのは、そのような価値観かと思う。

その方が、環境の変化に素早く対応できるし、失敗したときの痛手も小さい。常に微調整しながら最適化していく方法論であり、環境に適応していく。

上司の役割は、そのようなことを部下にやらせることなんだと思う。言うのは簡単だけど行うのは難しい。

Jenkins実践入門を、技術評論社の傳さんからいただいたのだが、若手の迷えるエンジニアには、四の五の言わず、とりあえずこれでも読んでJenkinsをインストールしてCIしちゃえ、話はそれからだ、というようなことをそそのかしておいた。

ツイートする

■ IT産業には民族誌が必要だ

先日からContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationの読書会をしているというのは、日記にも書いた。*1

本日は第3章Continuous Integration（継続的インテグレーション）だ。早瀬さんが2号館のカフェテリアでやろうというので、近所のコンビニでビールとつまみを買いこんで参加した。（うひひ）

コンビニ袋にビールとポップコーンを突っ込んでカフェテリアに登場したところ、目ざとくビールを発見され、「おっビール」と言われるのだが、「えっビールじゃないんですか」と返す。早瀬さんもわたしのビールにつられてドリンクとつまみをコンビニに買出しに行った。

そんなこんなで、飲みながら第3章は始まったのであるが、その前にわたしのヨタ話を披露した。

Continuous Integrationという言葉はあのKent BeckのExtreme Programming Explainedと言う1999年に出版された本に最初に書かれたと、本書には書いてある。

シリコンバレーにいたころ、デイリービルドとかナイトリービルドとか呼ばれているプロセスは日常だったので、CIの言葉の起源が1999年のKent BeckのXPの教科書というのはちょっと意外な気がした。

本題に入る前の与太話として、シリコンバレー日記 (未来のいつか README http://web.archive.org/web/19981206133243/http://www.best.com/~yoshioka/d/98/ )を見せながら、「デイリービルド(http://web.archive.org/web/19990423132826/http://www.best.com/~yoshioka/d/98/i980218.html)」とか、「ソースコード管理システム(http://web.archive.org/web/19990423140752/http://www.best.com/~yoshioka/d/98/i980221.html)」とか、はたまた「夜中のビルド(http://web.archive.org/web/19990423182344/http://www.best.com/~yoshioka/d/98/i980405.html)」の話をする。「ビルド」(http://web.archive.org/web/19981205210826/http://www.best.com/~yoshioka/d/96/01/p960119.html)。

大規模ソフトウェア開発の現場では普通に行われていることで公然の秘密なんだけど、日本では当時ほとんど知られていなかったので、シリコンバレー日記として日々記すことはあながち無駄なことではないように思っていた。

もちろん、日本にもメインフレーマはあったので、同様な開発現場はあったと思うのだが、そのような現場の肉声は厚い組織の壁の内側にあったので、うかがい知りようがなかった。

デイリービルドやリグレッションテストについて、闘うプログラマーに記されていたので、まったく知られていなかったというわけではないが、現場感を持って語られることはほとんどなかった。

一方で、米国のソフトウェア開発の現場に働くエンジニアの流動性は高いので、Microsoftの出身者がOracleに転職して、そのビルドプロセスについてMSのベストプラクティスやdisciplineを転職先のOracleに輸入するということは日常的に行われていた。業界のpracticeやdisciplineが教科書という形式知になって流通するはるか以前に経験値として、人とともに緩やかに流通するというシステムがそこにあった。

RDBMSのアーキテクチャも、Sybase/Informix/Teradata/IBMなどなどの開発者が転職を繰り返すことによって、徐々に共通の理解が共有されていった。

そのようなものは論文になったり教科書になったりするよりも遥か前に暗黙知として人依存の形式で人とともに流通していた。

わたし自身も1984年に日本ディジタルイクイップメント研究開発センターという米国Digital Equipment Corporation (米DEC)の日本子会社に就職して、見よう見まねでmakefileのようなものを書き、夜中にビルドをするスクリプトをバッチで流して、テスト管理システム(DTM - DEC Test Manager)によって、ビルドしたイメージを自動テストするようなことは、普通に行っていた。

バージョンコントロールシステムはCMS (Code Management System)、モジュール管理システムはMMS (Module Management System)と呼ばれていた。DECのツールは大文字で3文字というのが暗黙のルールだった。

80年代に既に、夜中のビルドやリグレッションテストが普通にあったのだから、おそらくメインフレームの世界では70年代あるいはそれよりもっと昔から行われていたのだと思う。

富士通や日立あるいはNECのかつてのエンジニアたちのノウハウもどこかには絶対あったと思う。人材流動性がないが故に、あるいは彼らが管理職となるとともに、そのノウハウはどこかに死蔵され社会全体として活用される機会は永遠に失われた。

20数年前の新入社員が今年の新入社員と同じ本を今読んでいる。今年の新入社員にとってはCIという概念は非常に新しいリーディングエッジなテクノロジーだ。その今年の新入社員に対し20数年前の新入社員が20数年前の話をすることは老害かと言われるとそうかもしれないけれど、歴史を知ることは必ずしも無駄なことだとは思わない。

当時のVAX-11/730というマシンはVAX-11/780というマシン(1MIPS-1秒間に100万命令を実行)の1/3の処理性能しかなかったので、コンパイルの時間が非常にかかった。そのために、夜中にビルドするという方法を考えついて、テストも自動化した。うんぬんかんぬん。（VAXのコンパイラは1MIPSのマシンで1分間に約1000行コンパイルするので、数万行のプログラムのコンパイルには約1時間かかるとか)

変更はアトミックであるべきで、なんでもかんでも一つの変更に詰め込むことは良くないということを学んだとか、うんぬんかんぬん。

このようなことは、教科書にはあまり書いていないし、仮に書かれたとしても書かれるまでに何年もかかるので、それをビールを飲みながらあーだこーだ話すということは、若い人にとっては何かの参考になると思う。(例えば1分間に何行のプログラムをコンパイルできるかとかは簡単なベンチマークになるが学校では教えてくれない。大規模ソフトウェア開発の現場ではそーゆーどーでもいい知識というか相場観が役に立つ)

そして、そのようなベストプラクティスは人とともに伝わっていく。誰かが陽に伝えようとしない限り伝わらない。

楽天を卒業してGREEやDeNAやあるいは別の企業に転職するエンジニアがいたとして、彼らも、楽天で学んだ様々なことを暗黙知として、新しい会社に持っていく。もちろん、そこでは、楽天で学んだアンチパターン（失敗のパターン）は持っていかないから、どんどん、よいプラクティスが転職することによって流通していくというエコシステムが発生する。

後発の企業が有利なのは、その点である。

ソフトウェア開発の現場というのは伏魔殿で、外からは何が起こっているかさっぱりわからない。その中に入ってみない限り、わからない。IT産業にいるものであっても、やはり、Googleで何が行われているか、Appleで、Facedbook、TwitterあるいはLinkedInで何が行われているかは、そこに勤めたことがなければよくわからないのである。

結局のところ一人のエンジニアとしてはいろいろな現場を渡り歩き実際のpracticeやdisciplineを経験することによって少しずつトレーニングをつんでスキルをつけていくしかない。

組織としては、転職者という人を媒体にして、組織として学ぶしかない。

そして、そのような現場の諸行を記述する方法論こそが民族誌である。IT産業の現場の民族誌を自ら記すことによって、そのノウハウを広く知らしめ、社会の財産にする。

Continuous Deliveryという教科書をきっかけに、IT産業ほど民族誌が必要だということを思い至り、おじさんが若い人と読書会をすることの意義についても考えるきっかけにもなった。

社内勉強会として閉じてやるのもいいが、こーゆーヨタ話こそいろいろな経験値を持っている人と酒でも飲みながらやるのもいいなと思った。IT産業には民族誌が必要だ。

オープンソースの黎明期の話もしたのだけど、話が長くなるのでその話はまたいつか（笑）。

ツイートする

■ Continuous Deliveryを読む。

同僚とContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))の読書会をやっている。

英語の本なので、一人で読むにはちょっと敷居が高くても何人かで読めばどうにかこうにか読了できるような気がする。きっかけとして読書会というのはいいメソッドである。

読書会のメリットは、わたしのようなものぐさでもある種のプレッシャーがかかるので、どうにかこうにか続けられるというのがあるが、それ以外でもいろいろある。

何といっても読書会のメンバー間では、言葉の定義というか概念について共通の理解が深まる。

前回レガシーコード改善ガイドを読んだとき、レガシーコードというのは、テストのないコードのことを言うという非常に明確な定義を読書会メンバーで共有できたのは大きな成果であった。細かいレガシーコードの改善のメソッドは忘却の彼方であるが、その定義を深く理解できたことは大きな喜びであった。*1

Continuous Delivery(継続的デリバリー)というのは、ソフトウェアのリリースを継続的に行う方法論である。ソフトウェアを修正してからそれがリリースされるまでの各種プロセスを高品質でコストを安く、安全にリリースするには、どのようにすればよいのかを本書では議論している。

ビルドのプロセスを自動化する方法論としてContinuous Integration(CI-継続的インテグレーション)が知られている。プログラムを修正しビルドをする部分を自動化したものである。通常はビルドの後にテストの自動実行も含む。CIによって修正のコストは劇的に下がった。

デプロイするプロセスを手動でやるとどうなるか。

• ソフトウェアを修正する。
• ビルドする。
• テストをする。
• テストに問題があれば上記を繰り返す。
• 開発環境からステージング環境へインストールする。
• ステージング環境で問題がないか確認する。問題があれば上記を繰り返す。
• ステージング環境から本番環境へインストールする。
• 問題がないことを祈る。
• 問題があればお祭り騒ぎ。

CIは最初の3つのステップを自動化する。開発環境からステージング環境へのインストールが手動だと、様々な設定、操作を逐一ドキュメントする必要があり、作業は細心の注意が必要になる。時には、何百というステップを手で行う。そのような作業は緊張を伴うし多くの場合、コストも高く、エラーが起こりやすく、再現可能ではない。ステージング環境から本番環境へのインストールはそれ以上にコストがかかる作業になる。問題が発生した場合のコストはそれ以前のコストよりはるかに高くなる。

リリースは予測不可能（うまく行くこともあれば、うまく行かないこともある）だし、再現可能ではない。

本書は、リリースまでのプロセスをどのようにして自動化するかということを示している。Continuous Deliveryはまさに、そのようなプロセスを自動化することをいう。

どの原理原則も極めてシンプルである。そして強力だ。

例えば、すべての変更は記録する。当たり前すぎる。だけど、実践はどうだ。あなたは、本番環境のコンフィグファイルをviで変更していないか。オブジェクトファイルにパッチを当てて、ソースには変更を反映しないことはないか。本番環境でビルドして、それをインストールしていないか。その一つにでもイエスならば、すべての変更を記録するという大原則から既に逸脱している。

フィードバックは可能な限り素早く受け取れなければならない(The Feedback Must be Received as Soon as Possible)。素早いフィードバックのポイントは自動化である。自動化されていないと、手動でビルドして、テストしないといけない。そのプロセスは人手を必要として、エラーが入りやすく、楽しくない。もっとも貴重な資源である人々を浪費する。

本書を肴に議論するのが楽しい。

読書会でいろいろなグループのエンジニアと議論するのが楽しい。ビルドプロセスは自動化されているか。テストは自動化されているか。されていないとしたらそれはなぜなのか。プロセスは再現可能かなどなど、あーだこーだ議論をする。それを自動化するには、どうしたらいいのか。グループによって、うまく行っているところ、うまく行っていないところいろいろあって様々な発見がある。

デリバリーのプロセスが十分自動化されていないグループのエンジニアが、「自動化するにはそれなりのコストがかかるわけで、それを事業側に説明するのがうまくいっていないから、なかなかそれが進まない」というコメントをしたところ、別のエンジニアが、「それって事業側に説明することなのかなー」という発言が出た。その真意は、開発のプロセスを自動化するのは、当たり前の話で、ソフトウェアをどのように開発するかということをいちいち詳細にわたって、そこまで説明する必要はないし、事業側もそれを求めているわけではない、そうじゃなくて、我々の仕事は、低コストで高品質なサービスをタイムリーに提供することなのではないか。そのために手動なプロセスはありえなくて、自動化する以外にはないのじゃないのか、などという議論が出て非常におもしろかった。

まあ、自動化についてそのメリット、方法論を自分たち自身も十分言語化できていないという反省もあるが、自動化したことがない開発者に向かって、どのようにそれを達成するか逐一説明し、方法をしめしている本書は多くのエンジニアにおすすめである。そして、日々トラブルに悩まされている中間管理職（課長とかGMとか呼ばれている人々）の人々にこそ読んでほしい一冊である。

おまけ

本書は、「この1年の優れたIT系書籍はどれか？「Jolt Awards 2011」が6冊を発表http://www.publickey1.jp/blog/11/1itjolt_awards_20116.html 」で紹介されていたのをみて、社内SNS(Yammer)に書き込んだところ、読書会をやろうという話になって、巻き込まれた。わたし自身は、他の本を読みたいと思っていたのだけど、本書は予想以上におもしろくて、巻き込まれてよかったよかったと思っている。

あと、翻訳されているのを待っている人がいるけど、良書を原書で読むというのは時間節約以上に、自分の知的体力向上に役に立つのではなんていらんお節介を言ってみたりして。というか、会社の公用語が英語になるので、日本語の本を読むモチベーションが沸かないという事情もある。

ツイートする

■ 3年前の未来。

9/13/10の日記より

2年後の未来がどうなっているかは、想像がつかないけど、そのヒントを今得ることはできる。

何かを作っている人を観察すればいいのである。何かを作っている人が、2年後の未来を今作っている。

となりにいるのに、それが見えていないだけである。

AndroidやiPhoneなんてのは2年前に確実にあったのだけど、それを多くの人は見えていなかった。見えていなければ当然対応することもできない。

Twitterも2年前に、今の隆盛を予見した人は少ないと思う。だけど、2年前にTwitterアプリを作っていた人はいた。

2年後の未来を見たかったら、今何かを作っている人を観測すればいいのである。

先週土曜日にあったTwitter Developers Meetupに参加して、そんな感想を持った。

4/24/08

六本木で開催されたGoogle Developers Dayに参加していた人たちと飲み会して、それがきっかけで、日本Androidの会ができあがって、人生変わっちゃった人もいて、わたしは転職して、いまにいたるｗ

たかが飲み会に3年後の未来があったw

ツイートする

■ カーネル読書会のこと

カーネル読書会の運営で困ったので、ここで相談してみる。

カーネル読書会に限らず、勉強会一般に言えることだと思うので、勉強会の運営を一般化していうと、（１）ネタの選定？とお題提供者との各種調整（スケジュールや、内容のすり合わせ）、（２）会場の確保、（３）告知その他、（４）当日の運営あれやこれや、（５）それ以外のあれやこれや。というのがあると思う。規模が大きくなって有償イベントになると、それ以外のあれやこれやが大きくなるのだけど、無償の数十人規模の勉強会ではそれは発生しない。あえていえば、ビアバッシュや懇親会をどうするかという話があるのだけど、本日のメインポイントはそこではない。

カーネル読書会というのは1999年4月からやっているオープンソース系の勉強会で、主にLinuxのことについて取り上げて2009年10月の第100回にはLinuxを作ったLinusも参加してくれた。今年の5月には第107回のカーネル読書会を開催した。

10年で100回開催したので、年間約10回のペースで開催していた。ざっくりいって不定期ながらも毎月毎月あれやこれや開催しているという感じであった。一方で100回以降は2年で7回とペースがががっと下がってしまった。

http://www.ylug.jp/modules/pukiwiki/?history

2010年に6回、2011年にいたっては1回しか開催していない。あきらかに開催頻度が下がっている。

なんでこうも極端に開催頻度が下がったかというと、わたしのモチベーションが下がったというのもあるのだが（まあ、それが唯一の原因であるのだけど）、個人でやっている勉強会の問題の典型例であるので、あえてケーススタディとして皆さんの知恵と協力を拝借したい。

勉強会というのは、（A）勉強会を開催するコスト、（B）勉強会を開催するメリットとしたとき、A＜Bならば開催されるし、A＞Bならば開催されない（よしおかの勉強会の第一法則）、という法則が知られていて、A＜Bにするのが勉強会主催者の力量になる。

カーネル読書会の場合について考えてみると、運営コストAについては、１の話題提供者とのすり合わせは、2009年前後で大きく変わったということもないし、３の告知のコスト等についても特に大きな変化はない。むしろ、twitterやfacebookのようなソーシャルなメディアのおかげで告知のコストは下がっているし、ATNDのような参加登録システムの普及で多くの人に参加を促すプラットフォームは整備されてそのコストは下がったと言ってもいい。また、IT勉強会カレンダーの登場(2008年)、その後の勉強会ブームということで、勉強会にまつわる環境はいろいろな意味でよくなってきている。すなわち、まわりの理解が深まって、Bの価値の部分が増えたり、Aの有形無形のコストが減ったと言える。

自分にとっての変化は2009年8月の転職である。それが、２の会場の確保、４の当日の運営あれやこれやに大変な影響を持った。Aのコストが上がった。

具体的に言うと、ミラクル・リナックスに勤務していたころは、会場は会社の会議室予約システムであいている日時を抑えて、総務に何日にカーネル読書会をしますと知らせるだけであったが、今の会社では、空き時間を調べて会議室を確保するだけでなく、エレベータ、空調、鍵の解錠、GUESTカードの申請、イベントの申請、ケータリングがあればその申請など、様々な手続き系がある。何を申請するかはマニュアル化してあるので、考えなくてもいいのだけど、やはり手間暇はかかる。

さらに当日の運営である。セキュリティの関係で1階ロビーに受付を設置し、入館証を自筆で記入いただき、GUESTカードを首からぶら下げてもらい、専用エレベータで会場階まで連れて行って会場に誘導する。受付に2名、エレベータに1名、1階エレベータホールに1名、会場階ホールに1名、会場に1名、全体統括に1名と最低でも7名運営スタッフが必要になる。

それだけではない。登録したけれど、当日ドタキャンをする人、受付時間が終わってから遅刻をする人が必ずいる。遅刻対応のために、受付、エレベータ係などを配置するコストも発生する。遅刻だけではなく、懇親会に出なくて早退する人がいれば、入場のフローとは逆に、1階ロビーまでエスコートしてGUESTカードを回収するコストが発生する。さらに、退場時にもフロアーの誘導、エレベータ、1階ロビーでのGUESTカード回収のコストが発生する。

２の申請系のコストは定数なので極小化、アウトソースできるが、４の運営コストについては、それも難しい。つまり、勉強会をするたびに、この運営ボランティアをどう確保するかが大きな課題になる。

結局開催コスト（A）が開催メリット（B）を上回る（A＞B）という状況のため、カーネル読書会の軽やかな開催が阻害されているのである。

この問題は、カーネル読書会に限らず、社外勉強会を社内に誘致する場合常につきまとう普遍的な問題である。

われわれはイベント屋でも貸し会議室屋でもないので、それをビジネスにして金で解決することはできない。例えば、参加者から金を取って、会議室代を捻出したり、受付の人件費を回収したりはできない。

わたしが、ミラクル・リナックスにいたころには、２のコストも４のコストもないに等しいくらい低かったのでA＜Bの不等式が成立した。残念ながらいまの会社では４のコストが高くなっている。

そこで皆様に相談である。

２ないし４について低コストで提供いただける場所、ボランティアを募集する。あるいは、そのアイデアを募集する。どんなアイデアでも、クレージーな提案でも結構である。

カーネル読書会を続けたいというわたしの思いをコミュニティに投げる。解決策は必ずあると信じている。

ツイートする

■ 自分のhistoryを分析する。DevLoveターミナル勉強会に行ってきた

CUI(Command User Interface)というのはGUI(Graphical User Interface)と異なってコマンドを覚えなくちゃいけないし、コマンドをタイプしなくちゃいけないので、初心者にはちょっととっつきにくい。

コンピュータとの操作をGUIの時代からやっている人にとっては面倒な使いにくいものなのかもしれないが、CUIにはCUIのよさがある。それを伝えてみたい。

CUIのコマンドは自分の意志をコンピュータに伝える言葉である。CUIはそのコマンドを記録することが簡単にできる。なんといっても文字だから簡単に分析できる。

自分はコンピュータに何を語っているか。自分は日々何をしているのかを知ることが自分の作業を知る第一歩となる。

例えば、プログラムを作るということを生業にしているのであれば、コードを書いて、コンパイルして、テストをして、デバッグをして、という作業を繰り返すことになる。それは、エディターを開いて、コードを書いて、ファイルに保存して、makeしてなどなどをコマンドとしてコンピュータに伝えることになる。

Unix系のOSであれば、$ emacs; $ make; $ make test; みたいなコマンド列になるかもしれない。このようなコマンド列を分析していけば、自分の作業をマクロに観測することができて、自分の作業を理解し、言語化して、ひょっとしたら誰かにその作業知識を伝えられるようになるかもしれない。

実際、一日の作業をemacsのshellモードで行い、最後にそのログをコピペして作業日誌とするなどということは気の利いたプログラマなら普通にやっている。作業手順書を作るのも、同様に行える。

そのような作業日誌をとっておけば、〜する作業なんていう頻繁にはないけど、時々発生する作業について、前回やった作業を参考にパタパタ同じコマンドを叩けば実行できたりして、再度調べ直す手間を省けて便利である。GUIだと、同じ作業を繰り返す場合、同じ回数クリックしなくちゃいけないが、CUIだとコマンドをコピペしたり、あるいはコマンドを組み合わせてスクリプトを作ったりすることが簡単にできる。

定型的な作業を一まとめにしたものがshell scriptであったり、makefileであったりする。

日々の作業についてhistoryをみてみよう。historyコマンドは文字通りUnixコマンドの履歴を表示する。これを読めば過去自分がどのような作業をしたか一目瞭然である。

個人持ちのネットブック(Ubuntu 10.04)で自分のコマンドを分析してみた。会社のマシンだと若干傾向が違ったりする。

$ history|tail
 1998  cd memo/
 1999  ls
 2000  gedit d110919
 2001  gedit d110919 2>/dev/null &
 2002  uname -a
 2003  ls /etc
 2004  less /etc/issue
 2005  emacs&
 2006  history|head
 2007  history|tail

まず、コマンドを取り出す。

$ history|cut -d' ' -f 4|tail
ls
gedit
gedit
uname
ls
less
emacs&
history|head
history|tail
history|cut

というような感じになる。ここでcutコマンドを利用して空白区切り(-d' ')で4欄目(-f 4)を取り出している。OSによっては-fの値が異なるかもしれない。

自分が利用しているコマンドの利用頻度を測ってみよう。

$ history|cut -d' ' -f 4|sort|uniq -c|head
      1 ./configure
     17 acroread
      3 alias
      3 ascii
      1 bash
      6 cat
    115 cd
      1 cd..
      1 chmod
      5 cp

コマンド名でソートして頻度をuniq -cで測る。

多い順にソートしてみる。

$ history|cut -d' ' -f 4|sort|uniq -c|sort -nr|head
    313 ls
    115 cd
     72 history|cut
     64 time
     43 soffice
     39 git
     38 ping
     33 man
     26 mv
     17 acroread

わたしはlsとcdを多用していることがよくわかる。history|cutが多いのはこのネタを仕込むためにあれやこれややったからであるw

timeが多いのは何か作業をするときの実行時間を計測するためである。timeで何を計測しているかは、$ history|grep timeして同様に分析すればいい。

ここまでやってきて、普通パイプ(|)を使ってコマンドを組み合わせるだろう、そのコマンドについて分析していないではないかと思う。そのとおりだ。

$ history|cut -d' ' -f 4-|sed -e "s/|/\n/g"|cut -d' ' -f 1|sort|uniq -c|sort -nr|head
    313 ls
    113 cd
    108 history
    107 cut
     94 head
     76 sort
     64 time
     63 less
     43 soffice
     42 grep

これでみると、cut, head, sort, less, grepなどのコマンドをパイプの後で使っているのがよくわかる。

sed -e でパイプ(|)を改行(\n)に変換して、A｜BをAとBに分割している。

実際、わたしは、$ ls -lt|headというコマンドをよく使う。

Unix系OSのすごいところはこのパイプをつなぎ合わせる事で、プログラムすることなく、あれやこれや処理ができることだ。Unixの達人はプログラムを書かない。コマンド(プログラム)を組み合わせる。

自分がよく使うコマンドについて公開して、いろいろ議論をすることは、自分の知らないもっといい方法を学ぶきっかけになると思う。このような形で緩やかに情報を共有することは初心者のみならず、エキスパートの人々にとっても自分のスキルをチェックするいい機会となる。

みなさんもどーぞどーぞ。

ツイートする

■ 情報爆発時代のgmailの使い方

個人メールをgmailにしている人は多いと思う。gmailのサービスが始まったとき、1GBの容量というのも驚いたが、その検索の速度にも驚いた。さすがに、Googleが提供するサービスであると感心したものである。もちろん無料というのもうれしかった。

すでに、サービスを開始してから7年以上たっている。自分なりにgmailの使い方を考えてみた。というか、様々な情報ツールが登場したにもかかわらず、相変わらずメールを使っているというのも、あれだとは思うが、もうしばらくメールのお世話にはなるような気がする。情報爆発時代メールというツールの限界について考えてみた。

分類するな検索しろ

gmail以前は、メーリングリストにしろ、個別メールにしろ、フォルダーを作って、どうにか分類して、情報整理につとめていた。整理するときのヒントはSubjectであり、Fromであった。コンテンツでの検索はその遅さが故に、情報爆発した場合、ほとんど使い物にならなかった。誰かが、いつごろ発言したかをヒントに昔の議論を引っ張り出すのが常であったが、それは、既に破綻していた。結果として、情報は重複し、似たような議論が繰り替えされ、時間は浪費されていた。

情報を整理するのは、自分であった。インターネット強者は自前でサーバを用意して、メールのアーカイブを持っていたりしたが、情報の量を持つことが資産ではなく、負債になりつつあった。自分でサーバを管理して情報を整理するコストが指数関数的に増大していった。

gmailによって、メールの意味が変わった。メールは自分が管理するものではなく、インターネットの向こう側におくものというふうに変わった。メールの情報はGoogleが整理してくれる。そして、整理するコストは向こう側にある。つまりタダである。自分がメールを管理するコスト（A）と向こう側に整理してもらうコスト（B）を比較したとき、gmail以前のWebメールはお世辞にも使い易いとは言えないユーザインタフェースと、貧弱なメール容量せいぜいMB単位、そして極めつけはないに等しい検索機能、仮にあったとしても、何十秒も待たされる検索で、おそらく真面目に使おうという気にはなれなかった。つまりA＜＜B、あるいはそれが提供するメリットはA＞＞B。それがgmailによって管理コストA>>Bになったのである。メリットがA<<B、つまり自前でメールを管理する必然性がほとんどなくなったのである。

gmailには、フォルダーという概念がない。そもそも、フォルダーによって整理する必要がない。（ラベルというのがフォルダーに似ているが、タグ付け機能に近い）

何か、必要な情報があれば、あらかじめフォルダー分けするのではなく、必要になったとき、その時に検索すればいいのである。もちろんあらかじめタグをつけたりすることはできるし、重要だと思う情報には星印をつけたりすることはできるが、基本は検索である。

そして、その検索の速度がストレスなく十分速いので、あらかじめ手間暇かけて分類する必要がないのである。

分類の欠点は、一度分類したら、それ以外の視点で検索するコストが極めて高くなるのである。

例えば、あるプロジェクト専用のフォルダーを作って、そこにあるメールを入れたとする。後になって、横串を通して何かを検索しようとすることは簡単ではない。プロジェクトA、B、C、…、の使った予算を調べたい、問題点をみたい、…、などに対応するには、あらかじめ、固定的な分類で整理してあると簡単にはいかない。むしろ、その整理が有害ですらある。

gmailでinboxに入っている最初の100通がもっとも目立つ位置にいて、それ以外のところにいる未読のメールは検索によって発見される。そのように使うのがgmail的な使い方ではないかと思う。

読んで、あるいは読まないでarchiveにいれ、未読メールの数をそれほど多くしない。メーリングリストのメールなどは、重要度が高くなければ、そのままアーカイブ行きである。読まないメールをなんで購読するかというと、後で検索するかもしれないからである。メールの容量が十分でかいので、削除しないでアーカイブしておいて後に検索するかもしれないという使い方である。

gmailにおける検索キーワード

gmailの検索窓には下記のようなキーワードを指定できる。

in:inbox inboxにあるものだけを検索する

from: 差出人

subject: 件名

to: 宛先

before: 日付より前のメール yyyy/mm/dd の形式で書く

after: 日付より後のメール

ASCII以外の文字が入っている場合()で囲む。たとえば(日本語の件名とか　空白とか)

ある語が含まれていないものを検索する場合は - を使う。 -hyosihok で hyoshiokが含まれていないものを示す。

is:starred　★がついている

is:unread　未読

is:read　既読

OR　検索語1 OR 検索語2 でどちらか含まれる

例： in:inbox from:facebook subject:added before:2011/4/1

inboxにある、facebookからの、件名にaddedと入った、2011/4/1以前に到着したメールを表示する。

より詳細は下記を参照のこと。

https://mail.google.com/support/bin/answer.py?answer=7190

メールの未来

正直言えばメールの整理が追いつかない。今後は徐々にグループでの議論はSNSのようなものに移行していって欲しいと思う。メールと言うのは、ゴミメールも重要メールも読むまでその重要性が分からないというのが問題だ。まあ、それはいつの時代かに誰かが解決してくれるのではないかと期待したい。

ツイートする

■ 社内SNSを活性化するたった一つの方法

があれば苦労しないよね。

昨日EGM Summitなるものに参加した。ここでEGMとはEmployee Generated Mediaのことで、社内ブログ、掲示板、SNSのようなものらしい。

弊社はYammerというTwitterのようなものを社内SNSとして利用している。全社的に春頃から導入しているのだが、無償版を随分前から有志が勝手に導入して利用していた。

社内Twitter的なものとしてSalesforceのChatterというのを試験導入したのだが、まったく普及しなかった。閑古鳥がないていた。営業でSalesforceを日常的に使用している人ならともかく、つぶやくためにわざわざログインするということの敷居の高さを越えられなかった。

一方でYammerは、Twitter的な機能だけではなく、Facebook的にスレッドがまとまって表示されたり、likeボタンがついていたり、写真やファイルもアップロードできるので、社内SNSとしての機能は十分だった。

アーリーアダプターが雑談したり技術的な議論をしたり、あるいは質疑応答などに緩く使っていた。利用者も徐々に増えてきたのが昨年の今頃である。

今年に入ってから、それをなぜか社長が発見して、投稿を始めた。そして311があって、在宅勤務者への連絡手段としてYammerを利用することが緊急避難的に行われ、4月以降、有償版を利用するにあたって全社員にアカウントを用意した。

アカウントはあるのだが、ログインすらしていない人が相当数いる。仕事のワークフローのなかに組み込まれていないので、その優先順位が低いのは致し方ないのだが、社内マイクロブログを上手に使いこなして仕事を効率化する人もいて、社内デジタルデバイドが発生しているのはよろしくない。上手に使いこなす人はどんどん使いこなすし、使いこなせない人はまったくもって使いこなせていない。

20年前は電子メールを全社的に導入している会社はあんまりなかったので、メールを仕事で使うというリテラシーがなかったし、営業の人なんかでも、電子メールなんてのは仕事で使えないなどと言っていたものであるが、さすがに今、そんなことを言う人はいないし、どうにかこうにか皆メールを使って仕事をしている。

社内SNSも同じで、導入当初は使い方もよくわからなくて、その使い方を試行錯誤しながら構築していくフェーズであることは間違いないのだけど、インターネットの会社なんだから、もっと先進的な使い方を社内で発明、実験、試行錯誤していかないと、3年後のTwitterやFacebookを作っていないといけない立場の人たちが、それじゃあ困るというものである。

弊社の場合、さらに社内英語化という社会実験（？）をやっているので、英語化プロジェクトとYammer推進というダブルで来ていて七転八倒である。

仮説、実証、検証、仕組み化というプロセスを回すのが弊社の現場のアプローチで、Yammerの活性化も同様にやっている。

正式導入する前は、アーリーアダプターによるタグ付け隊とかQ＆Aをボランティアで起こしたりしたのだが、正式導入後には、社内委員会を発足させ導入推進をはかっている。この委員会を作るというアイデアは、社内広報を担当している小泉さんのもので、気がついたらわたしがリーダーになっていた。魔法をみるようだった。（社内委員会を発足するとYammerの利用が推進されるという仮説である）

週次で、ログイン数、ポスト数、ユニーク投稿者数などを計測している。ログイン数を増やすために、アクティベーションでドロップしないように、簡単なマニュアルを作成したりした。（計測するのは仮説が正しい、あるいは間違っているということを検証するためである）

ログインをさらに増やすために、全社朝会で広報をして、ログインキャンペーンとして社内フォトコンテストをYammer上で開催している。参加賞としてYammer TシャツをYammer社から提供いただいた。（ログインを増やすことが社内SNSを活性化させるという仮説である。そのための打ち手を実施した）

さらに、アカウントのアイコンをペットの写真とかマンガのキャラクタではなく実写真にしてもらうようにしたり、プロフィールの経歴などもなるべく記述してもらうようにお願いしている。

SNSというのはまさにネットワーク効果そのもので、利用する人が増えれば増えるほど価値が相乗効果で向上していく。そのために鶏と卵というか呼び水が必要でそれが社内フォトコンテストとかアイコンの実写真化という打ち手である。

多くの人がアイコンに顔写真を載せれば、社内ミーティングのときに初対面の人でも分かるし、プロフィールをちゃんと記述していれば（ある種履歴書みたいなものなので）、人となりを知ることが出来て仕事をスムーズにするきっかけになる。

中途入社が多い環境においては、そのような情報の価値は非常に高い。

一方でそのような価値を理解していない人も多い。社内SNSが何を書いてもいいという前提がゆえに戸惑っている。何を書いていいのか分からない。そーゆー人にとっては社内SNSの利用は苦痛でしかない。

社内SNSの機能は社員をエンパワーするのだというお題目はよく聞くが、戸惑っている人にはその言葉は届かない。残念ながら「意味わからないよーー」というのが本音だと思う。

社内SNSによって、社員の活性化をして、それによって、新しいアイデアが生まれ、イノベーションが起こり、サービスなり製品なりに反映され、売上が向上し、収益が増え、ボーナスをいっぱいもらえてハッピー、というようなシナリオが描けないと辛い。

この風が吹いて桶屋が儲かるというストーリーにリアリティを持たせ、それを実証するというのがもっかのわたしの課題なのだけど、道は遠い。

ポスト数は計測できるけどイノベーションは計測できない。社内活性化度なんていう指標はないので、何かで近似値をもって推定するしかないのだけど直感以上に確からしいものはない。

さらにいうと、アーリーアダプターほど、例えばアイコンを写真にしてねーーーとかいうガイドラインに脊髄反射的に過剰反応して、ありゃりゃとなったりする。

ROIなんてものには馴染まないというのは百も承知なんだけど、それをあえてベンチマークして言語化してパターンランゲージとして明示的に表現する努力をし続けることによって、自分の理解を深め、移転可能なノウハウに昇華するのがわたし自身の課題である。

1984年にDECという米国のコンピュータベンダーに就職してVAX Notesという社内SNSのさきがけを利用したものにとって社内SNSを使いこなす事が企業価値を高めるということを本能的に理解している。言葉で説明することができない位自明なことなのであるが、自明でない人たちにそれを説明することがわたしの使命でもある。

仮説、実証、検証、仕組み化、これをひたすら回して行って社内SNSを根付かせるのが当面のわたしのミッションである。

仮説として、利用者数を増やせば、イノベーションが加速するというのをおいたとして、利用者数を増やす打ち手をいくつか実験しているのが現状だ。

最終的にはハッカー中心の企業文化を作ることなんだけど、道は遠い。

試行錯誤は続く。

ツイートする

■ Twitterはバカ発見機か

TwitterとかFacebook最近ではGoogle+のようなつぶやき系のSNSが流行ってくると、日記やブログのようなちょっとした意見の塊を書き下ろすのがちょっと億劫になってくる。わざわざ日記に書くことでもないあーだこーだを記す気力も残っていない。

それでも、セキュリティ＆プログラミングキャンプのような相当エネルギーを使ったイベントに関しては何か書いておかないと損な気がして気力を振り絞って書いたりする。だけど、日記なんてものはそもそも個人的なものだからそんなに無理をする必要もないと思ったりもする。自然体で書きたければ書けばいい。

とはいうものの、Twitterはつぶやきは流れて行くのでやっぱりちょっとはストック系の考えをまとめておきたいというのも人情だったりする。

Twitterはフローで日記はストック。書く内容も異なる。書く時の心構え（？）も異なる。前者は今やっていることを書き、後者はちょっと前にやったことを書く。前者は反射神経、後者はちょっとは推敲をしたりする。それがフローでありストックである。

自分は一人しかいないのでフローの積み重ねがストックになる。日々の泣き笑いが自分を作っていく。怒ることも笑うこともある。喜怒哀楽の積み重ねが自分である。

Twitterで飲酒運転をしたとか、カンニングをしたとか、違法行為あるいは違法とは言えなくてもちょっとどーなのよということをつぶやいている人がいる。@sonodamはTwitterはバカ発見機だと言っていたけど、人は多かれ少なかれおばかな存在であって、いいこともするが悪いこともする、人を信じることもあれば、裏切ることもある。

できれば誠実に生きたいと思うし、人からは裏切られたくはない。だけど、人は不誠実なものでもあり、嘘をつく存在でもある。

結局、バカ発見機に発見されないためには、Twitterで日々の行動をつぶやかないようにすることではなく、自分が自分に対して誠実に生きることしかない。時として、自分の発言から意図をしないで、人を傷つけることがある。意図しなかったからといって免責されるわけではない。その行為について自分の落ち度を認め、それを繰り返さないために何かをする。未来に向かって何かを行動する。その積み重ねなのかなーと思ったりする。

自分がバカであれば、不誠実で鼻持ちならない存在であれば、おおかれすくなかれそのような存在であるということは知られていく。今まではTwitterみたいなインターネットにおける拡声器がなかったので、会社の同僚とかごく一部の限られた人にしか、自分のバカさ加減は知られなかっただけの話である。

Twitterというバカ発見機に発見されないためには、自分が誠実に生きるしかないのかなーと思った日曜日の午後である。

ツイートする