未来のいつか/hyoshiokの日記

■ Macの電源コードのしまい方。

電源アダプターですね。コードはじゃまなので、ぐるぐる本体に巻くとこんな感じです。

不思議な羽みたいなのがついています。ぱかっと開ける。

そこにコードをぐるぐるまけば、ちょっとスッキリ。

なるほどー、こーなっていたのか。先週の金曜日に知りました。アップル製品は奥が深いなーー。

ツイートする

■ 武雄市の図書館問題を個人情報保護法で議論するのはスジが悪い

武雄市図書館、ＴＳＵＴＡＹＡが運営へ

佐賀県武雄市は４日、レンタルビデオ店「ＴＳＵＴＡＹＡ」を展開する「カルチュア・コンビニエンス・クラブ」（ＣＣＣ）に市図書館の運営を任せることで同社と合意したと発表した。市は６月定例会に同社を指定管理者とする議案を提出。認められれば来年４月に年中無休でカフェや雑誌、文具の販売コーナーを設置した図書館が誕生する。ＣＣＣが公立図書館の運営を行うのは初めて。

http://kyushu.yomiuri.co.jp/news/national/20120506-OYS1T00146.htm

ネットでも早速いろいろな議論が巻き起こっている。

まづ当事者の武雄市長のブログ

武雄市長物語

http://hiwa1118.exblog.jp/15827483/

当日の記者会見の映像

http://www.ustream.tv/recorded/22339926

当日の映像Video streaming by Ustream

Twitterまとめ

http://togetter.com/li/298081

高木浩光＠自宅の日記

武雄市長、会見で怒り露に「なんでこれが個人情報なんだ！」と吐き捨て

http://takagi-hiromitsu.jp/diary/20120504.html

図書館の自由に関する宣言

http://www.jla.or.jp/ibrary/gudeline/tabid/232/Default.aspx

T会員規約

https://tsite.jp/tm/pc/register/STKIp0108001.do

　わたしの意見

図書館というのは、図書館の自由に関する宣言でもうたわれているとおり、『基本的人権のひとつとして知る自由をもつ国民に、資料と施設を提供することをもっとも重要な任務とする』という機能がある。そして、その利用に関しては、思想信条の自由にのとって、プライバシーとして保護されるべきものだと考える。

その意味で、個人情報保護法は、個人情報をどのように利用するか（保護するか）という観点からの法律なので今回の議論にはなじまない。

図書館業務を民間に委託すること自体が問題ではなく、その利用履歴の保護が問題になっている。

T会員規約を読む限り、利用履歴はカルチュア･コンビニエンス・クラブ株式会社およびポイントプログラム参加企業によって共有される。利用目的のなかに「会員のライフスタイル分析」というのがある。ライフスタイル分析というのが具体的に何をさすのかは不明だが、利用者の読書履歴より、お勧めの情報を抽出したりすることは容易に推測できる。

わたしが、図書館のどのような本を読もうが読むまいがわたしの自由であり、誰かにその履歴を保存され分析され何かを売りつけるために利用されるというのは、よけいなおせっかいと感じるし、そもそもそんなことはしてほしくない。

それこそが、憲法が保証している、思想信条の自由なのではないだろうか。わたしが図書館で何を読もうが自由。誰にも干渉されない。その情報をどんな形にしろ利用するというのは、その権利の侵害にあたるとわたしは考える。

ツイートする

■ 日本IBMの売上推移

先日、日本IBMの社長交代のニュースがあって、それを聞いて驚いたのが、社長が日本人ではなくなるということではなく、この10年で売上が半分近くに下がったという業績であった。*1

わたしの世代ではIBMという企業はコンピュータ業界の超エクセレントカンパニーで仰ぎ見る遠い存在、憧れの存在でいわばロックスターである。コンピュータ興亡史でいえば、IBMが先頭にいて、DECがそれを追撃するもかなわず、Sunが80年代華々しくデビューして、90年代一世を風靡する。90年代にはいると時代はMicrosoftとIntelが支配していた。90年代前半に巨像IBMは泥沼に足をすくわれもがき苦しむが、ガースナーによって復活する。メインフレーム・ハードウェアを主軸とした事業構造から、ハードウェア、ソフトウェア製品、サービスという3本柱に見事に転換させた。

若い人達には実感がないかもしれないが、GoogleやFacebookのような存在感、むしろそれ以上の存在感があったのである。

日本IBMのホームページの資料からわかる範囲で売上推移を調べてみた。

売上は、90年代前半低迷し、1993年には赤字に転落する。その後徐々に回復し、97年に1兆5330億ほどになり、2001年は1兆7075億と過去最大、経常利益は2000年に1820億円となる。

ところがその後、売上は右肩下がり。2011では、約半分の8631億円である。その間IBM本体は順調に売上を伸ばしているので、日本IBMの一人負け状態である。（例えば、1999年の売上は87,548百万ドル、利益は11,757百万ドルから2011年106,916百万ドル、16,318百万ドル）

日本IBMはまったく成長をしていなかったのである。日本経済よりも。

かつての日本IBMは人材の宝庫、先端技術の宝庫であった。日本IBMのOBたちが、外資系IT企業のトップや経営陣になって日本のITを引っ張ってきた。あこがれの企業はどこに行ってしまったのだろうか。

year	従業員（人）	売上（百万円）	国内売上（百万円）	純利益（百万円）	当期利益（百万円）	reference	notes
1989	23019	1312640	951484	194884	102033	*2
1990	24407	1326517	969816	154384	82822	*3
1991	24855	1272144	903825	103516	56484	*4
1992	25033	1254583	894098	26766	31205	*5	北城、ガスナー体制
1993	23216	1157805	823532	10112	-18428	*6
1994	21792	1200413	877885	74381	10448	*7
1995	20777	1308734	1019712	88187	39443	*8
1996	20369	1425069	1152211	112111	55613	*9
1997	20593	1533069	1227211	127079	68657	*10
1998	21108	1474095	1173581	90101	39054	*11
1999	20924	1477082	1175850	119043	109839	*12	大歳
2000	20905	1643828	1331537	182003	106297	*13	linux
2001	21671	1707535	1460888	172890	106078	*14
2002	28581	1583434	1469113	166593	95077	*15	従業員数は連結対象会社との合計
2003	28231	1497982	1432797	149895	79276	*16
2004	27719	1460921	1401593	151194	84986	*17
2005		1245343		115547		*18	レノボ・ジャパン
2006		1193287		139043
2007		1192611		154048
2008		1132932		154331	96797	*19
2009		954568		112813	73059		橋本社長就任
2010		937773		124272	77316
2011		868134		94026	27274

ツイートする

■ グーグル、ネット覇者の真実を読んだ

グーグルのことを知っているようでいて、よく知らなかったということがよくわかる一冊である。恥ずかしながらインターネットの会社に勤めていて毎日毎日グーグルのことを使っているのに不勉強のそしりを逃れられない。

著者はハッカー倫理を紹介した書籍『ハッカーズ』のスティーブン・レヴィ。

秘密主義で知られるグーグルに内部取材を許可され内部の人間にしか知りえないインサイダーとしてのドキュメントをものにしている。その意味でこれはグーグルにとっても、外部のもの（われわれ）にとっても貴重なエスノグラフィー（民族誌）となっている。

『わたしのインサイダーとしての視点は、グーグルの二つのブラックボックスー検索エンジンと広告システムーを開けるカギとなり、これまえ知られていなかった多くの事実を明らかにすることができた』019ページ

そして、著者が言うようにこの二つのブラックボックスに関して極めてわかりやすく明快に説明することに成功している。同社の価値観、行動原理が明示的に示されている。

ページとブリンという若者が作ったこの革新的な会社、世界をテクノロジーで変えることを文字通り希求している若者が、様々な困難、社会的なコンフリクトとの葛藤のなかで、グーグルをどうしていくのかをいきいきと描写している。28歳の若者には老練なCEOエリック・シュミットを必要とした。

グーグルを秘密主義にしたのは、広告（AdWordsとAdSense）という金の成る木を同業他社（マイクロソフト他）にIPOまで知られたくなかった。

そして、快進撃のインターネットの覇者も、中国進出では挫折し、様々なサービスではプライバシー保護団体からの非難をうけ、米国独禁法で政府の調査も受けている。邪悪にならないというのをモットーに掲げているが、一企業が多大な情報を管理することに関する懸念を持つ人は少なくない。

アルゴリズムによる情報の整理をとことん追い求めたグーグルが、Facebook/Twitterを始めとするSNSによって挑戦を受けている。グーグルにはオーカット(Orkut)というSNSが存在していたにも関わらず、その重要性を見抜けなかった。イノベーションのジレンマの典型例なのかもしれない。

インターネットのこれからを考える上での貴重な一冊である。

ツイートする

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

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

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の不等式が成立した。残念ながらいまの会社では４のコストが高くなっている。

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

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

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

ツイートする