未来のいつか/hyoshiokの日記

■ 第１０５回カーネル読書会のお知らせ

日時：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

会場の都合上、18:30より以前には開場しませんので、ご注意ください。またなるべく遅刻のないようにお願いいたします。受付にて、入館証の記入をお願いいたします。ご本人が確認できるもの（名刺、学生証）を提示いただく場合がございますので、ご準備よろしくおねがいいたします。

参加登録 http://schedule.infoseek.co.jp/events/6013ab25b83fdfd92e45419b982554ad

ピザとビールの懇親会（予定価格1500 円） 学生さんは無料なのでそれも社会人に×を記入してください。

会場の都合で80名で締切ます。

■ レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり

社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。

読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。

一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1

今あるレガシーコードとどう向き合うか

新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。

レガシーコードというのはテストのないコードのことをいう。この定義はシンプルであるが力がある。

問題は今あるソフトウェアに機能を追加したり、変更したりする場合だ。もちろんテストなどない。そのテストがない状態で安易な変更をすればバグを埋め込むことになる。したがって、変更は最小限にして、動いている部分については可能な限り手を触れないということになる。

そうすると、本来ならば、もっとすっきりシンプルな実装になるはずなのに、部分的な修正を積み重ねる事によって、どんどん実装が複雑化、巨大化して見通しが悪くなり、ますます変更が難しくなる。どんどん開発のスピードが遅くなり、最終的には、変更ができなくなる。変更をしようにも、思わぬ副作用が出て、新機能の追加のスピードが新たに発生したトラブル修正に追いつかなくなるという事態になる。

レガシーコードの改善には上記のような難しさがある。

レガシーコードは外からテストをしていく。

では、どうすればいいのか。

もちろん、魔法の方法があるわけではない。統合テストを書くのである。今動くものがあるのであるから、それのテストを書けばいいのである。そして、その動作を期待する動作として記録すればいいのである。これがリグレッションテストになる。

データベースへのアクセスなども含めた統合テストを実施する。そのためのテスト環境（テストハーネス）を構築する。これ自体は既存のコードの変更を一切伴わないのでバグを埋め込む危険性はほとんどない。

そして、既存のコードの部分のテストが出来てから機能を変更していく。最初のテストの網羅性や完全性については、今までまったくなかったのだから、それよりははるかにいい状態なので、ここでは問わないことにする。自動的にテストができる環境を構築し、テストを書くということが重要なのである。

新機能については、単体テストを書き機能を確認する。

新機能を作る度に、既存の部分のテスト（外側からテストをする）を書き、新機能の部分のテスト（内側からテストをする）を書く。徐々にその量を増やしていく。

読書会を通じて、レガシーコードは外から、新規開発は内からテストをするというベストプラクティスを共有できた事は大きな成果である。*2

そして、読書会から学んだことを試してみて、今までテストができなかったという状態から、テストが出きるようになったという報告も聞けたことは大変な喜びである。

教科書で学んだことを実際試して、うまくいったこと、いかなかったことを共有し、さらにそれをネタに皆で議論をした。その方法論というのは、読書会の非常にオーソドックスなものであるが、なかなかよい経験であった。何かをネタに仕事に生かす。読書会の価値かなあと実感した次第である。

参加者の皆さん、お疲れさまでした。そしてありがとうございました。とっても、勉強になりました。なにより皆さんとの議論が楽しかったです。

■ 勉強会カンファレンス2010に行ってきた

勉強会カンファレンス2010*1に行ってきた。そこでの感想など。

勉強会のメソッドは勉強会の数だけある。共通の問題もあればその勉強会固有の問題もある。それぞれの問題を出し合って、みんなでその解決策を議論するという方法は大変有効な方式だと再認識した。

最後のセッションで、岩切さんが、自分の困っていることをプレゼンしていて、そこからいろいろな議論が湧き上がってきて、非常に盛り上がったが、あんな感じのセッションがわたしにとって理想的な形だと思った。

岩切さんの困っていることというのは、ざっくり言うと、カンファレンスを開いても一列目、二列目の人たちは、笑いもしないし、ぴくりとも動かないし、隣の人といきなり話を始めて、何かを持ち帰っていこうというような感じの人がほとんどいない。それを聞きにくる人を巻き込んで、何かをしたい、だけど日本人だからそれができないかというと、DevLOVEなんかにいくと、とってもいい感じで盛り上がっている。自分が主催するセミナーでそれをやるにはどうすればいいんだろう、というようなことだと理解した。

わたしが、「細かいことは気にしない」という発言をしたあと、会場を交えていろいろな意見が飛び出し、そのライブ感が非常に素敵だった。人を巻き込むというゴールをいかに達成するかという問題に対しては、気にしないというのは解決でもなんでもないのだが、喧々諤々の議論が始まる導火線のような役割をはたした。

様々なアイデアは、会場に桜を仕込んで、いくつか質問をしてもらう。休憩時間を長めにとって、飲み物、お菓子などをふるまい、そこから横のつながりを広げる。個人名刺を作り、裏には、自分の興味のある分野とか個人史を書いて、ここにいるのは誰だということを示す。ネームプレートに興味のある分野を記す。共通の話題を見つけるために、どのようなことに悩んでいるかを挙手を求める。*2

自分も会社で勉強会を開くと、場から質問があんまりでなくて、ちょっと寒い感じがあるし、それをどうにかしたいという思いは一緒なんだけど、「よしおかさんは特別だから…」と、言われちゃったりして、それを松井さん（R社の中の人）に振ったら「わたしも人を増やすにはどうしたらいいんですかねって昔よしおかさんに聞いたら、『そんなことは気にしなくていいんだよ』って言われました」（場内爆笑）

ひとそれぞれレベル感の違いがあるとしても抱えている問題というのはあって、それは勇気を出して表現することによって共有でき、共有することによって様々な解決案を考えられる。その問題を解決するのは結局は一人一人なんだけど、同じ問題で悩んでいる仲間がいるということを知るのは貴重な体験である。自分は孤独ではなかったということを知るのは重要だ。

勉強会カンファレンスという場の価値の一つにこの問題の共有というのがあると思う。

海外のカンファレンスでは、あんなに議論が盛り上がり、質問もいっぱい出るのに日本ではまったくそれが出ないというのはなんでだろう。という問題設定があったとき、「日本人の国民性として」とか、ほげほげだからという人のせいにする、あるいは自分が解決できない問題のせいにする人というのは多いが、それは問題の解決にはなんにもならないし、むしろ有害ですらある。自分が達成したいゴール、この場合、カンファレンスで質問ががしがし出るという状況をどう作るか、という問題をみなでどう解いていくか。それをみんなで議論するという方が生産的だし、なによりも楽しい。

いきなり質問ががんがん出るというのは考えにくいから、小さい勉強会のような場をいっぱいつくり、質問をすることが価値があることだという経験を少しずつしていく、それをひたすら半径5メートルで繰り返す、そのような経験をした人を少しずつ増やしている、というようなことを自分は実践する。そのようなことかと思う。

いきなり見ず知らずの人と話をするのは難しいけど、主催者側として出きることは、休憩時間を増やす、飲み物、お菓子などを振る舞うなどのヒントをもらったので、それを試してみる。そして、それを試行錯誤する。

東京はいいよなあと勉強会がいっぱいあってというスタンスから、じゃあ、自分は何を出来るのだろう、何をしたいのだろう、という問い掛けから、自分に出きることをいろいろ試してみて、やり続ける。それしかないと思う。

世界から東京をみると

1990年代後半、シリコンバレーに行って、その地で働いたとき、至る所でベンチャーが元気にやっていて、いろいろなSIG(Special Interest Group)が定期的に会合をしていて、プロフェッショナルたちがインフォーマルに議論している姿をみて、すげーー、いいなあーーと思ったのだけど、日本には当時そのような自分が求めている場がなかった。日本に帰ってきて、YLUGの人たちとカーネル読書会というのを始めて、自分のできる範囲でできることを続けたきたところ、気がつくと勉強会という形式がごく普通のことになった。

それは、誰かが意図してやったというよりも、同時多発的に自分がしたいことをし続けた人たちがいっぱいいただけだと思う。そのような人たちは、おそらくシリコンバレーはいいよなあ、VCとかいっぱいあるから起業も簡単だし、日本はその点、ほげのげだからだめだよなあ、などというようなことを言って何もしない人ではなく、取りあえずやってみるという人なのだと思う。そして、そのような人たちが世の中を動かしていくのだと思う。

世界から東京をみてみると、しょぼいのだけど、そのしょぼさを評論家的にあーだこーだ言ってもしょうがない。同様に、東京は大都市で、勉強会がいっぱいあっていいよなあと言うだけでは解決にならない。地方に勉強会が成立しないみたいな前提で話をする人がいるが、日本全国津々浦々頑張っている人はいっぱいいるし、自分でできる範囲でいろいろ工夫をして、地方の強みを生かした運営をしている人はいっぱいいいる。そのような工夫をしている主催者の皆さんには「東京が羨ましい」というだけの言葉では届かないと思う。

自分は、こうしているのだけど、こーゆー問題で困っている。という設問には力があると思う。

自分がいるところには、いるところなりの問題点や課題がある。それを自分が変えられないもののせいにするのではなく、自分が出きることによって解決していくという姿勢で乗り越える。

オランダ戦の日の勉強会カンファレンスを終えて

勉強会というメソッドをどう進化させていくか。勉強会主催者の初心者からベテランまで、それぞれのステージの中でどう進化させていくか。企業の中で、コミュニティの中で、地域の中で、それぞれどう進化させていくか。勉強会というメソッドを利用しながら、勉強会共通言語（パターンランゲージ）の開発をより深めていきたいと思った。

勉強会カンファレンス2010で採択した勉強会憲章2010

勉強会をより進化させるためには、言語化（形式知）する必要がある。そこで、懇親会の時、川口さんがアジャイルの話をしていたのを受けて、Agile Manifestの勉強会版を作ろうということで勉強会憲章(Manifest)というのをみんなで考えた。ほんの数分間で、作り上げたもので、いろいろご批判もあると思うし、そもそもマニフェストなんかは必要ないという方もいると思う。そのような思いの方も含めて広く議論したいと考える。*3

• 勉強よりも学習
• 技術より情熱
• 聞くより喋る
• Ustreamよりリアル
• テーマより人

言語化することによって、議論を精緻にすることができる。議論によって自分たちの理解が深まるし、目指すものが見えてくる。

カンファレンスのような、同じ問題意識をもった違ったバックグラウンドの人たちが集まるという場そのものの価値は実際にリアルにあってフェースツーフェースで議論することだと思う。それは自ら学ぶという姿勢であり、テクニックではなく情熱であり、単に聞くのではなく語ることであり、インターネット中継ではなくリアルに話すということであり、テーマその物よりもそこにいる人と問題や情熱や価値観を共有することだと思う。

憲章というおどろおどろしい（？）言葉に、傲慢さ、傲り、を感じるむきもあると思うが、これをきっかけに何かの議論が始まればうれしい。

いろいろ気づきがあった、勉強会カンファレンス2010であった。

会場を提供していただいた日本工学院、大谷先生、USTでお手伝いいただいた学生さん、そして参加していただいた皆さん、どうもありがとうございました。

■ テストは誰が書くのか

昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1

テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。

ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。

要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交わせられる。開発期間中に仕様の変更はさらなるコストアップになるので、行われない。行うことは悪であるというパラダイムになる。工程を別業者に発注する以上、契約という形で縛らないといけないので、これはある意味、必要悪の世界である。顧客のビジネス上の利益の最大化というのはお題目としてはあっても、構造上それを実行するのは、難しい。

このような構造にあるので、テスト容易なコードを書くというのは、現場のインセンティブとして生じにくい。テストを書く人とコードを書く人が分離されていれば、そのようなことになる。受託開発の場合、かかった工数に人月単価をかけて売上になるので、人月単価がかわらなければ、工数がかかればかかるほど売上がたつので、ここでも、工数削減というインセンティブは生じない。

結局のところ、ウォータフォール型の受託開発モデルでは競争力のあるソフトウェア開発を実践することは非常に難しいことになる。

一方で自社開発の場合は、仮に要求を出す部門と開発する部門が社内的には別々部門であったとしても、同じ会社なので同一の目標に向かって同じ目線で語ることができる。テストを書くことによって生産性が向上するとしたらそれは開発部門だけではなく、事業部門にとっても利益がある。事業部門にとってみれば、テストを書こうが書くまいが、提供されるサービスによって利益が上がればいいわけで、その意味で、必要な機能が提供されさえすれば満足度は高い。

アジャイルな開発方法論は、より素早く、品質の高いソフトウェアを生み出す方法論としてウォーターフォールモデルよりも優れている。少なくとも自社開発の場合は、ウォーターフォールモデルを利用する必然性はないと言ってもいい。

要求分析、設計、実装、テスト、運用など一つの組織が一貫して行うことで競争力を持つ。そのような環境の中ではプログラマの責任範囲は広いし、やりがいもある。

一人が要求分析から、設計、実装、テスト、そして運用についても見通せると、効率のよい実装、テストしやすい実装、運用に負荷がかからない実装というような観点から実装を見直す機会ができる。

テストを書けないのは、テストを書きやすい実装になっていないからである。組込みやリアルタイム系でテストが難しいという話もあるが、それでも、テストしやすさを前提とした実装と言うのは絶対にあるはづである。*1

プログラマにとってテストを書くことが重要なスキルの一つなのである。

■ テストを書くこととテストをすることの違い

会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。

一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。

テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。

参加者の皆さんとその価値観を共有できた事はうれしい。

現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識を得たことの価値は大きい。

システム変更の方法は、大きく２つに分けることができると本書は主張する。ひとつは、「編集して祈る」、もう一つは「保護して変更する」方法である。

編集して祈るというのが残念な事に業界標準になっている。つまり変更作業をして、その機能を何らかの方法で確認して、周辺もざっと調べて特に問題がないことを確認して、結果がうまくいくことを祈るという方法である。祈るのである。

一方の保護して変更するというのは、足場を組んで、転落防止の柵や網をはって、転落しないようにしたり、万が一転落してもセーフティーネットによって保護されるというようなものである。ソフトウェアで言えば、テストで保護するということである。テストプログラムによって、意図しない破壊が起こっていないことを確認するのである。

バグとテストとデバッグ

バグというのはソフトウェアの期待する動作と実際の動作の差分である。期待する動作というのは、通常何かの文書、例えば要求仕様書などに、書かれているものであるが、そのような文書が存在しない場合もあるし、そもそも日本語で明確に書けないような非機能要件というのもある。まあ期待値との差が出たらそれはバグと考えるというのが大雑把な理解である。*1

そのようなバグを発見する作業がテストという作業である。

テストを行うために、テストプログラムを書いて、それを実行し、期待する動作と実際の動作を比較する。入力に対する出力と期待する出力に差分が出ればテストはバグを発見したことになる。

発見したバグを修正する作業をデバッグというが、ここでは詳細に立ち入らない。

修正作業でバグを埋め込まない方法

ソフトウェアを修正すると残念な事にバグを埋め込むことが多い。非常に多い。経験豊富なプログラマはそれを知っているが、経験が浅いプログラマは根拠なく自分は大丈夫だと信じている。残念な事に痛い目にあってもその信念はなかなか揺らがない。

バグを埋め込まない方法というのは残念ながら知られていないので、修正した後、あれやこれや確認をしてみて、祈るというのが業界標準になっているらしい。

そこで、テストプログラムだ。テストプログラムがあれば、少なくともテストプログラムが確認することに関しては確実に動作が保証できる。もちろんテストプログラムがざるであれば、それ以外のところでぼろぼろ抜けができるが、それは別のはなしである。

テストプログラムによって、埋め込んだバグをすぐに発見する。発見するのは、早ければ早いほど修正は簡単だ。一つ修正して、テストを流して、それで不具合が発見されたとしたら、その修正がなんらかの影響を与えているというのはすぐにわかる。サルにでもわかる。どこを修正したのか知っているので、簡単にバグを直せる。1週間後に発見したとしたら、どこを修正したのか、その変更箇所を探すだけでも簡単な作業ではない。出荷後に発見されたらもっとバグ修正は難しくなる。

修正作業でバグを埋め込まない方法は、バグを埋め込んだらすぐに発見することだ。修正する度にテストプログラムを流してテストをするということだ。そしてバグを発見したらすぐに直すということである。

テストプログラムを作ると言うことは、エクセルのシートにテストケースを書くことではない。

テストをしているかとプログラマに聞くと、もちろんしていると答える。テストプログラムを書いているかと聞くと、言葉を濁す。

テストをするには、ソフトウェアを実行して、その動作を目で確認する手動の方法と、なんらかのテストプログラムを書いて、そのテストプログラムによってソフトウェアの動作を確認する方法とある。

前者と後者には雲泥の差がある。

そして、このレガシーコード改善ガイドがいう、編集して祈るは前者のアプローチで、保護して変更するは後者のアプローチである。テストのないコードというのは前者のことで、それはレガシーコードだと言いきっているのである。いつコードを書いたかが問題ではない。テストプログラムがあるかないかがレガシーかそうでないかを分けるという強烈なメッセージなのである。

いまそこにあるレガシーコード

新規にソフトウェアを作るときに、未だにテストプログラムを書かないプログラマがいるが、そのような輩はここでは取り上げない。テストプログラムを書いてねというしかない。テストドリブンで開発してねというしかない。それでもテストプログラムを書かないプログラマに言うことはない。

そうではなくて、誰かが書いたコード、職場の上司かもしれないし、同僚かもしれないし、辞めてしまった誰かかもしれないし、ともかくテストがないコードをメンテするプロフェッショナルであるあなたが、どうやってこのレガシーなコードをメンテナンスするかという議論である。

テストはない。

おそらく文書もないだろう。あったとしても、メンテされていないまったく何の訳にも立たない文書しかないのだろう。

そのコードをどう改善していくか。

結論から言えばテストを書くのである。

テストがないので、変更ができない。変更をするとテストがないので、修正にバグが含まれていないか祈る以外に確認方法がないので、変更はできない。ここに大きなジレンマがある。

単体テストのようなホワイトボックステストで、コードを変更してテストを埋め込むということがテストがないが故にできない。

それでは、どうやってテストを書くのか。それは、外から攻めるのである。前からいくのである。つまり、受け入れテストないしは統合テストと呼ばれている、ブラックボックステストを行うのである。UIのテストであればSeleniumのようなツールを使って動作を確認していくのである。

そして、まわりを固めて徐々に内側に入っていくという戦略になる。

新規に追加する機能であれば、それはテストによって保護していく。徐々にテストが全くない状況からテストがある状況へ進んでいく。

新規開発は内側から、レガシーコードは外側から攻めるという戦略に落ち着く。

テストがアジリティをあげる

レガシーコードは大きな質量を持っている。テストがないので、変更ができない。動いている部分はなるべくそっとしておこうという思慮が働く。そのために、変更に強い抵抗が生じる。アジリティが非常に低い。

それを徐々にリーンな筋肉質な体質に持っていくには、テストを書くしかない。

テストがあれば変更ができる。変化にも対応できる。アジリティも上がる。

鶏と卵である。

テストがあれば、どんどんリファクタリングして、より変更しやすいようにコードを改良できる。コードというのは放っておくとどんどん重たくなっていく。実装を繰り替えすうちに徐々に全体像の理解が進みよりよい実装が見えてくる。そのためにリファクタリングが必要なのであるが、テストがないとそれができない。

テストとアジリティは表裏一体なのである。

読書会が共通の理解を生む

本書を読み、現場のエンジニアと議論をし、どうすればいいかを語った。テストがないコードはレガシーコードだという共通認識を得た。

ここにあるレガシーコードをどうにかしたいという強烈な危機感を共有した。そしてレガシーコード改善の具体的なヒントを本書で得た。このヒントを実践するもしないもわれわれ自身にかかっている。

テストを書こう。その勇気を与えてくれる一冊だ。

あなたが、レガシーコードと戦わなければいけない職場にいるのであれば、同僚とじっくり読書会をすることをお勧めしたい。その効果がすぐにでないとしても、時間がかかっても何かの変化があるはづだ。

価値観を共有する。それが最初の一歩だ。

■ 第104回カーネル読書会のお知らせ

日時：6月17日(木)19：00開場、19：30時ころ開始（いつもより30分遅いです）
お題：カーネル読書会会議
発表者：みんな
内容：久々にいきなりビアバッシュから始めます。カーネル読書会のこれからについて、風穴さんのMeeGoの話など、あれやこれや。
会費：1500円（ピザとビール代）、学生無料。
 19：00頃　開場、LTないし自己紹介など
 19：30頃　お題開始。ビアバッシュ。
 20：30頃　懇親会開始
 21：30頃　中締め
場所は楽天タワー
http://www.rakuten.co.jp/info/map/shinagawa.html
会場の都合上、19:00より以前には開場しませんので、ご注意ください。またなるべく遅刻のないようにお願いいたします。
受付にて、入館証の記入をお願いいたします。ご本人が確認できるもの（名刺、学生証）を提示いただく場合がございますので、
ご準備よろしくおねがいいたします。
ピザとビールの懇親会（予定価格1500 円）
学生さんは無料なのでそれも社会人に×を記入してください。
会場の都合で80名で締切ます。
参加申し込みは下記より
http://schedule.infoseek.co.jp/events/3a174e63a5cf9fe886e15dd625a14bba

■ 時短な人がいる場合の社内勉強会開催のTips

社内勉強会などは、大抵就業時間後に開催される。産休明けで時短な人は、就業時間後では残念ながら参加できない。そこで考えた、時短な人も参加できる勉強会の時間帯を。

ランチタイムに勉強会をすればいいのである。ぽん（膝を叩く音）。

会議室に弁当でも持ち込んで、昼休みに弁当を食いながらおこなえばいいのである。最初の15分くらいは弁当を食べつつ、緩い感じで行う。後は時間まで、普通に勉強会をすればいい。時短な人も勉強会に参加できるし、いろいろな立場の人が参加するので、主催者、参加者もうれしい。みんながうれしい。うれしいの二乗である。

■ ガラパゴス化する就活

わたしが学生だったころ（1980年代前半）の就職活動というのを思い返して見ると、高校生のときに漠然と大学の学部を決めて、大学生活を送るうちに希望の業界をイメージしていくという感じだった。

例えば、工学部であれば車が好きな奴は自動車メーカーに、経済学部であれば、商社とか銀行とか。工学部でも電気メーカーを希望するのは電気科とかであり、自動車メーカーを希望するのは機械科を専攻しているやつで、その逆はあまり考えられなかった。電気回路全然だめだよという奴は電気科にはいかないし、熱力学とか製図をとらない奴は機械科にはいかない。（必修がどうだこうだというより、自分の好きな科目とか得意な科目、あるいは苦手な科目を勘案の上、学部や学科を選択していくイメージだ）

高校生ころにざっくりとした学部の選択をし、大学生活を送りつつ、徐々に職業というのをイメージしていく。わたしの場合、2年生を二度やっているので（とほほ）、二度目の2年生の時じっくり考える機会があったので、プログラミングのバイトなどをしながら、職業としてのソフトウェアエンジニアというものに漠然としながらも憧れを持ち始めていた。

当時はインターネットも何もない牧歌的な時代だった。パソコンが1977年に登場し、1981年にIBMーPC、そして1984年にMacが登場する。そんな時代である。そして、二度目の2年生のときに、自分はコンピュータというのが好きだし、プログラミングというのが好きかあるいは得意かどうかは判然としないが、それでも、このコンピュータ業界というのはとても魅力的に思え、なんとなく、この業界に就職してみたいと思い始めた。

当時、慶應には計算機科学科というのがなく、湘南藤沢（SFC）もなかった、コンピュータを専門に学べるのは、電気工学科、計測工学科、管理工学科、数理工学科というような学科だった。電気、計測がハードウェアより、管理、数理がソフトウェアよりという感じだった。電気は不得意だったので、電気、計測は希望対象から外れ、数理は数学が超不得意なので、結局管理工学科に進学する事にした。今から思うと、消去法的な学科選択だ。もっとドラマチックな何かがあったはずであるが、当時の自分はそれなりに必死にあれやこれやを考えていたかと思うのであるが30年経ってみると、まあ、その程度の感じである。

学部の研究室は、竹内研究室という統計の研究室で、竹内先生というのが日本でAPLを広めるコミュニティ活動などをしている、不思議な先生であった。統計の研究室にいたので、多変量解析だとか主成分分析とか因子分析、あるいはクラスター分析などを当時の統計パッケージでぱらぱらやるというのは、ふつーにやっていた。すっかり詳細は忘れたが、その手の言葉、統計のほげほげ分析という言葉には、まったく苦手意識がない。データーマイニングつーのは、結局多変量解析ということでいいのか、とか適当なことを言って煙に巻くことぐらいは多分できる。定義の小難しい数式はパターン認識して覚えるしかないけど、その程度ではビビらない。

７イレブンでバイトをしたことがあったのだが、天気のいい時には弁当が売れるので、多めに仕入れるというのを小難しく分析して、その法則を見つける手法として多変量解析とかクラスター分析などが使えるとか言うことを、後に知った。

修士課程では、浦研究室にお世話になった。浦先生のアセンブリ言語入門で中学生の時アセンブリ言語を学んだものとしては何かの縁を感じた。浦先生のFORTRAN入門ももちろん読んだ。隣の研究室は大駒先生なのだが、大駒先生のCOBOL入門ももちろん読んだ。プログラミング言語の入門書を書くのが大学の先生のお仕事みたいな時代だったのだろうか。

そこで、データベースの勉強をして、RDBMSの理論的な論文とかSystem-Rの論文とか、図書館に行っては大量にコピーをとって、読みまくった。当時Prologという言語が流行っていたので、それでプロトタイプを実装して修論にした。バージョン管理システムの存在を知らないのでとんでもないプログラミングだった、もちろんテストなど十分やっていない。

研究者になるというつもりもなかったので、修士課程でおなかいっぱい勉強したことだし、とっとと就職しようと思った。で、会社訪問とかあれやこれやを始めるわけであるが、コンピュータ業界といえば、日本のメーカー（富士通、日立、NEC、東芝、三菱、沖など）、外資系（IBM、Univac、バロース、NCR、DECなど）などがあった。情報系でいうと富士ゼロックスなど。外資系はIBM以外消えたか、買収されたか、合併したか、名前が残っているところはほとんどない。日本のメーカーも、東芝、三菱、沖などはコンピュータ事業から撤退している。

自分はソフトウェアを作りたかったので、上記のような中から希望の会社を絞って行き、結局DECに就職した。

当時、マイクロソフト株式会社もアップルもサンマイクロの日本法人もなかったので、あったとしても多分就職候補になったかどうかは怪しい。外資系に就職することですら結構チャレンジだった気がする。

しかし、ソフトウェアの勉強をし、コンピュータの会社に就職するというのは、わかりやすい職業選択方法だと思う。

昨今、就職氷河期で、何十もエントリーシートを書いて、御社が第一志望ですといいながら必死に就職活動をしている真っ只中の人たちに時々聞かれることがある。どうすれば採用されるんでしょうか。

例えば、プログラミングをまったくやったことがなくて、プログラマー志望です、と言われるとちょっと困る。学部は理工系でなくても、独学でプログラミングを経験し、オープンソースのプロジェクトでばりばりやっているというような人ならまだしも、それも経験がない。だけど、テンションはとっても高くて、人当たりも良く、営業とかやらせれば結構いいところまで行くのでは思ったりするような人が、プログラマ志望ですと言われても…。

わたしにとって、ぐぐっと来るのは、プログラマーになりたいのであれば、やはり学生時代なにかしらのことをやっていて、それがインターンでもバイトでも、あるいはオープンソースのプロジェクトでもなんでもいいのだけど、それなりにプログラミング経験があって、その実績を持っている人だ。勉強会に参加しているとさらに好感度は増す。積極的にLTとかいろいろ発表しているとさらに増す。githubでコードを公開しているなんていうことになると、もっといい。

プログラミングの基礎は大学時代に身につけていて欲しい。インドや中国の学生は大学時代にその程度の知識は身につけている。彼らは英語も日本語も中国語もできる。

コンピュータを学んだことがなくてソフトウェアの職業につこうという発想はガラパゴス化した日本の就職事情の反映かと思うが、それでは困る。会社も困るし、社会も困るし、何よりも自分自身が困ると思う。

よく、コミュニケーション能力が必要だなんてことを言うが、それ以前に基礎的な知識はちゃんと獲得しておいて欲しい。

プログラマー志願の皆さんは、とりあえず、達人プログラマーなんかを読みつつ人生を考えてほしい。

■ 社内公用語を英語にすること

最近楽天の社内会議を英語でやっているということをおもしろおかしく伝えられているが、中の人として一言ふたこと。http://mainichi.jp/select/biz/news/20100513mog00m300020000c.html

まあ、言うまでもないことだけど、日本のGDPが今後全然増えないなかで企業が成長していくとしたら、海外にでなければいけないことは火を見るよりもあきらかなので、外に出て成長するか、外にでないで成長を放棄するか極端に単純化するとそのようなお話になる。いやいや、日本国内でも十分成長余力はあるという立場ももちろんあるが、それ以上に海外の成長が大きかったとしたら、限りある経営資源を有効活用するために、どっちの方に投資するかということである。

日本のサービス業で海外で成功した事例というのはほとんどない。製造業であれば、SONYやトヨタなどいくらでもあるし、かつての日本のお家芸だったと言っても過言ではない。ユニクロが積極的に海外展開を図ろうとしているのは小売業として日本だけでは限界があると言う問題意識だが、その問題意識はまるっきり同じである。

商売の軸足を、どんどん海外に置いていく。それをするというコミットメントに他ならない。それ以上でもそれ以下でもない。

ちょっとエキセントリックな印象を与えたのは、社内公用語を英語にするというキャッチーなところだろう。しかし、考えてみればSONYも日産も社長は日本人ではない。社内公用語は英語である。会議を英語でやっているのである。

SONYでも日産でも出席者がたまたま全員日本人であったら、例外的に日本語を使うことはあるだろうが、基本的には資料、文書は英語だろうし、外国人がいれば当然英語になるだろう。それ以上でもそれ以下でもない。

社長が出席する会議（取締役会とか経営会議）は、ほとんど英語になったが、下々の日々の会議までが英語というわけではない。

細かいことを言えばキリがない。英語にアレルギーがあって、わたしは日本だけでいいです、というマインドの人は、別に楽天に入社しなくていいのである。そのようにはっきり白黒を言うというのは伝統的な日本的な企業ではなかなかないが、明示的に会社がそれを宣言するというのはフェアだと思う。いろいろ議論はあると思う。だけど、それを外野があれやこれやというのは、お門違いかとも思う。わたしは、このような、ある種極端な実験をする会社は、リスクをとるが故に先行者利益を得る可能性が高いと思う。

まあ、TOEICがどうだとか、そーゆー話が一人歩きする危険性があるけど、そのくらいのショック療法がこのぬるま湯の日本には必要だと三木谷さんは判断したんだと思う。わたしは、その判断は正しいと思うがそれは誰にもわからない。わたしは黒船で夜も眠れぬ人々である。

Asianux

Miracle Linux時代、2004年に中国のRed Flag社とAsianuxのプロジェクトを始めたときのことを思い出した。北京で共同開発をしたのだが、技術的な議論をするときの言葉をどうするかというとき、一つは、通訳を置いて、日本語中国語が堪能なブリッジエンジニアを駐在させて行う案と、もう一つは、片言だけど、双方にとっての外国語の英語で会話をする案とがあった。

正直行って、日本から行った某エンジニアも英語はぼろぼろで何度も日本語通訳をつけてくれと泣きつかれたが、英語で押し通した。中国側のエンジニアも英語はボロボロでぼろぼろ同士どうやって意思疎通を図るのだというと、通訳がいない分、相手が自分の言っていることを理解していないということは、はっきりわかるので、極めて単純に物事を伝えようと努力するし、分かるまで、いろいろな角度から何度となく説明し、何度となく確認をするくせがついた。

時間はかかったが、必要なことはしつこく確認する。そのようなくせがついた。

ソフトウェア開発において、自分の伝えたことが正しく伝わっているかということをしつこく確認することは基本中の基本である。しかし、その基本中の基本ができないので、ソフトウェアプロジェクトは失敗するのである。はじめっから、双方の理解に差があるという危機感をもっているので、極めて単純なことから、これはイエスなのかノーなのかをなんどとなくしつこく確認するくせがついてそれが結果として相互理解につながり、何度も飲み会に行ったりしながら、技術的なところ以外のところでも、腹を割って話ができた。同じ釜の飯を食ったという一体感ができあがった。

逆説的になるが、双方にとって母国語ではないが故に、誤解や曲解もあったと思うが、それが生じることが前提で、自分の言っていることを相手はどのように理解したかを相手に語ってもらうことで、その理解を共通のものにするという手間暇がかかることをやったおかげで、双方の距離は縮まり、相互理解は深まったと思う。

通訳をつけていれば、最初のハードルは低いが、通訳がどのように伝えたか確認しようがないが故に、誤解は誤解として訂正されないままプロジェクトは進行し、あるとき、取り返しのつかない時点でそれが発覚するというようなリスクがあったのではないかと想像する。

英語はわれわれにとって母国語ではない。同様に世界の多くの人にとっても母国語ではない。それが故に共通語として育って行っているではないだろうか。

おそらく、日本企業がオフショアとして中国、インドのソフトウェアハウスを使うことが今後増えてくるだろうが、日本語を公用語にすることはやめたほうがいいと思う。

われわれ自身が変わらない限り、世界との競争に打ち勝つことはできない。というかわれわれ自身が変わらない限り、そのスタートラインにも立てないような気がする。

英語くらいでビビることはない。世界を相手にする。楽しいではないか。おもしろいではないか。外資系に勤めなくても世界の企業と競争できるおもしろい時代になった。*1

■ 第103回カーネル読書会のお知らせ

下記のようにカーネル読書会を開催します。

日時：5月18日(火)、18時半開場、19時ころ開始

お題：Linux Collaboration Summit 2010 出張報告あれやこれや

発表者：加藤（楽天）さん、安井（楽天）さん、杉田(Linux Foundation Japan、日立製作所)、

よしおか（楽天）（順不同）

内容：4月に開催された、Linux Collaboration Summit2010に参加された皆さんによる出張報告です。

* 18:30頃、開場、LTないし自己紹介など

* 19:00頃、お題開始

* 20:00頃、懇親会開始

* 21:00頃、中締め、お開きへ

場所は楽天タワー

http://www.rakuten.co.jp/info/map/shinagawa.html

●りんかい線「品川シーサイド駅」出口Cより徒歩1分

(1-minute walk from SHINAGAWA SEASIDE Station, RINKAI LINE)

【ローソンの前を通りすぎて、突き当たりのエスカレーターに乗って、そのまま直進した所に入り口があります】

●京浜急行線「青物横丁駅」より徒歩7分

(7-minute walk from AOMONO-YOKOCHO Station, KEIHIN-KYUKO LINE)

会場の都合上、18:30より以前には開場しませんので、ご注意ください。また受付の都合のため、なるべく遅刻のないようにお願いいたします。受付にて、入館証の記入をお願いいたします。ご本人が確認できるもの（名刺、学生証）を提示いただく場合がございますので、ご準備よろしくおねがいいたします。

また、懇親会参加の皆様は1500円（予定価格）をお釣りのないようにご準備ください。

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

下記から参加登録をお願いいたします。（宴会君ではなく、みんなの調整を利用しています）

幹事名: よしおかひろたか

イベント名: 第103回カーネル読書会(Linux Collaboration Summmit出張報告）

イベントURL(PC): http://schedule.infoseek.co.jp/events/87071e323e4bf64283bfca10583d5de6

イベントURL(携帯): http://schedule.m.infoseek.co.jp/events/87071e323e4bf64283bfca10583d5de6

会場で、ピザとビールの懇親会つき。（予定価格1500 円）

懇親会参加希望の方は、懇親会参加に○を記入してください。学生さんは無料なのでそれも社会人に×を記入してください。

会場の都合で80名で締切ます。

なおセミナー内容につきましては、にこにこ動画などで配信予定です。ustream.tvでのインターネット中継も可能であれば実施します。チャンネル名は未定です。

ＹＬＵＧ年表 http://www.ylug.jp/modules/pukiwiki/index.php?history

ＹＬＵＧ会合、読書会資料 http://www.ylug.jp/modules/pukiwiki/index.php?reading

■ 達人プログラマーの思考法と学習法

無理してベストセラーを読む必要はない。自分にあった本を自分にあったペースで読んでいけばいい。GW中に昔（1年くらい前）献本された「リファクタリング・ウェットウェア」を読んだ。

達人プログラマでお馴染みのAndy Huntの著書である。正直言って、この本のタイトルにぐっとこなかったので、本書を1年近く寝かせておいたのであるが（献本いただいた宮川さんすいません）、ふと思いたち、読んだ。面白かった。副題の「達人プログラマーの思考法と学習法」が本書の内容を的確に表現している。

情熱プログラマーを読みながらも感じたことなんだけど、プログラマーとして、どのように学ぶかという問題にはもちろん正解はない。だけど、人間は弱いものなので、そのような正解を求めて本を読む。様々な自己啓発書が本屋にあふれているのがその証拠だ。私自身、そのような自己啓発書の類の書籍にはあまり興味がないので、買うことも読むこともほとんどないのであるが、読んだら読んだで面白い発見をするのではないだろうかと思ったりもする。

学ぶという行為は、人生を豊に生きるために人間に与えられた宝物だと思っている。わたしは効率のよい学習法とかに実は興味がない。それは効率のよい人生という問いが無意味と同じくらい興味がない。

むしろ会社の中で、ほげほげの資格がないと肩身が狭いのでその資格を取らなくてはいけなくなっていやいや試験勉強をしているという人がいたとして、その資格を効率的に取りたいので勉強法を勉強しているという人がいたとしたら（そちらの方が多いとは思う）、それはそれで同情する。

なんちゃらの資格を最小の労力で取得するということは会社での所々の立場から考えてどうにかしなくてはいけないという状況について理解はしているが自分はそんなことにはまったく興味がないのでどーでもいいちゃっどーでもいい。

そうではなくて、心を豊にするために学ぶという自学自習の精神をどのように実践していくか、そのような実践についてのヒントが実は本書には満ちているように思う。

勉強会とかカーネル読書会とかをやっているのは、効率的になにかの技術を取得したいという動機よりも、楽しいからという動機の方がわたしには強い。そしてそれを続けることが自分の人生をいろいろな意味で豊にすると信じているのでそれを続けている。そしておまけとして、ちょっとした知識を得たり、かけがえのない人と知り合ったり、意図しない喜びを見出したりする。

本書では、初心者、中級者、上級者、熟練者、達人という5つのレベルわけをしていてそれぞれのレベルにおける学習方法のようなことを記している。

初心者はルールに従い、達人は直感に従う。ある意味、形式知は達人の直感を文字にしたものである。しかし、言葉にできない価値もあり、それは暗黙知と言われたりする。

初心者から中級者、上級者、熟練者、そして達人になりたければ、本書は何かしかのヒントに満ちている。読むだけでは達人にはならない、本書に載っていることを実際に試してみないといけない。そして、自分流の学習方法を身につけることが達人になる第一歩である。

わたしは、初心者に、「勉強会で一つでもいいから質問をすること」を勧めている。何百人にも勧めた。しかし実践するのは、ホンの数人くらいか、1%位か、そんなものである。アイデアを思いつく人はいっぱいいる、だけどそれをやってみる人は驚くほど少ない。そしてそれをやり通した人はもっと少ない。そして、そのような人が成功者とか達人とか呼ばれたりする。そういうものである。言うのは簡単だけどやるのは難しい。

人生なかなかうまくいかないものである。