2014-08-01
第112回カーネル読書会を開催しました。 #ylug_112
第112回カーネル読書会を開催した。場所は恵比寿のレッドハット社。レッドハットさん、平さん、ありがとうございました。（ぱちぱちぱち）
内容は二本立てで、前座がわたしのOSCON 2014参加報告。そして佐々木さん、牧垣さんのOpenStackの話。
https://twitter.com/tetsu_koba/status/495159152591650817/photo/1
OpenStackのハックの話がなかなか漢だった。DBをごりごりいじっちゃったり。
Kernel Code Reading Party 112th; 第112回、カーネル読書会 #ylug_112 - Togetterまとめ まとめがすでにできていた。組み込みの中の人ありがとー。
次回はまだ未定ですが、８月末ころに開催したい。
2014-07-31
BBT大学主催、鈴木寛×松浦貴昌×須子善彦「日本の教育 未来のために今できること 〜 グローバル時代のイノベーターを生み出すために」というイベントに参加した。
鈴木寛さんには直接お目にかかったことがなかったので、どんな人なんだろうという興味で参加した。
7時開始なので、会社を定時で出ていそいそBBT大学がある麹町まで行く。お腹が空いたので、コンビニで飲み物とつまみを購入し、ぽりぽりしながら話をだらだらと聞いていたら、紙が配られていて、左側に未来のやりたいこと、望み、右側にやらないこと、こうなったらいやなことみたいなものを書いて、隣の人と話をしましょー、みたいな感じでいきなりダイアログが始まった。全然、心の準備ができてなくて、あちゃー、まいっちゃったなということで、ご近所の、女子と「じゃあ、お話ししましょうか」みたいな感じで自己紹介からはじまる。
このダイアログ形式は意外と面白い。なんでこのイベントに来ているんですか？どうやってこのイベントをみつけたんですか？とかの会話からいろいろな発見がある。
そんなこんなで、さらに隣とその隣の女子と女子３人とおじさん一人のグループでお話をする。なんで参加したのですかと聞いたところ、「SFCに入学希望なんですよ」（女子１）、「わたしもです」（女子２、３）、「え、君たち高校生なの？」、「はい」（１、２、３）、なんと勉強会的イベントで女子高生とお話しすることになろうとは思ってもいなかった。インパクトが強すぎる。
「須子さんのタイムラインで発見して面白そうだから来ました」（じぶん）、「へー」（１、２、３）、みたいな会話をした。
その後、三者の対談がだらだらと続く感じで、ここは質疑応答とかがあってもっとインタラクティブになっていたらよかったと思った。
最後に、またダイアログがあって、ここは自分が話したいことを紙に書いて、アンカンファレンス形式で行われた。わたしは「どう学ぶか、学び方」みたいなことを提案して、自分を含めて４名で議論した。こちらは全員社会人。
【140731】IT Future Session vol.1「日本の教育 未来のために今できること」 #bbtuit - Togetterまとめ
2014-07-30
読了せず。努力する人間になってはいけない。
努力する人間になってはいけない―学校と仕事と社会の新人論
なかなか面白かったんだけど、最後まで辿り着けずすいませんすいません。
2014-07-29
Linusが2週間でgitを作った話。
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記
Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。
gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。
$ git clone https://github.com/git/git
$ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck-cache to Makefile. 2022211 Add first cut at "fsck-cache" that validates the SHA1 object store. 2ade934 Add "check_sha1_signature()" helper function 24778e3 Factor out "read_sha1_file" into mapping/inflating/unmapping. 19b2860 Use "-Wall -O2" for the compiler to get more warnings. bf0c6e8 Make "cat-file" output the file contents to stdout. e497ea2 Make read-tree actually unpack the whole tree. 8bc9a0c Add copyright notices. e83c516 Initial revision of "git", the information manager from hell
最初の16進数はsha-1ハッシュ値の最初の７桁だ。その後がコミットログを一行で表したもの。
e83c516 Initial revision of "git", the information manager from hell
sha-1は一意にコミットを同定できるので、gitのどんなリポジトリでもe83c5163316f89bfbde7d9ab23ca2e25604af290というハッシュ値を持つコミットはgitソースツリーの中で最初のコミットになる。
このe83c516のログを見ると下記になる。
$ git log e83c516
commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager from hell
$ git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git log --oneline | tail e493073 [PATCH] Fix acl Oops 81ddef7 [PATCH] re-export cancel_rearming_delayed_workqueue 9ffb714 [PATCH] crypto: call zlib end functions on deflate exit path d42ce81 [PATCH] arm: add comment about max_low_pfn/max_pfn 7a228aa [PATCH] arm: add comment about dma_supported() 7aa52f5 [PATCH] arm: fix help text for ixdp465 2d137c2 [PATCH] arm: fix SIGBUS handling baaa2c5 [PATCH] Avoid deadlock in sync_page_io by using GFP_NOIO 8d38ead [PATCH] mmtimer build fix 1da177e Linux-2.6.12-rc2
git管理されている最初のlinuxのコミットは1da177e Linux-2.6.12-rc2だ。
$ git log 1da177e
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
’Re: Trivia: When did git self-host?’ - MARC
によると、
The first version of git was just ~1300 lines of code, and I have reason to believe that I started it at or around April 3rd. The reason: I made the last BK release on that day, and I also remember aiming for having something usable in two weeks.
「最初のgitのバージョンはたった1300行たらずだ。そして、開発を始めたのは4月3日ころだと思う。というのは、最後のBKのリリースをその日にしたからで、そして次の二週間でなにか有益なものを作ろうとしたということを覚えている。」
And hosting git itself was not that important for me - hosting the kernel was. And the first kernel commit was April 16 (with the first merges being a few days later). Which meshes with my "two week goal" recollection.
「gitそれ自体のホスティング（git repositoryに入れること）はそれほど重要ではない、カーネルのホスティングは重要だ。そして最初のカーネルのコミットは4月16日で、数日後に最初のマージをした。これが２週間でやるというゴールという記憶にあっている。」
4月3日から開発を始めて、4月7日にはなんらかのものが動いていて、4月16日にはlinuxカーネルを格納できるまでになる。これが2週間足らずでgitを作ったと言われるゆえんである。
それ以来、延々とlinuxの開発は続いていて、
$ git log --oneline | wc -l 456538
45万回以上のコミットされている。
2014-07-28
星を継ぐもの、読了
星を継ぐもの (創元SF文庫)
”月面調査隊が真紅の宇宙服をまとった死体を発見した。すぐさま地球の研究室で綿密な調査が行われた結果、死体はどの月面基地の所属でもなく、世界のいかなる人間でもない。ほとんど現代人と同じ生物であるにもかかわらず、五万年以上前に死んでいたのだ”
36ページの「エアカーの機首に格納されたDECミニコンピュータはポートランド地域交通管制センターの地下のどこかに設置されているIBMの大型コンピュータを呼び出し、…」というのがあって、未来のそのころにはDECもミニコンピュータという商品カテゴリすっかりなくなっているからと思った。泣ける。
それはともかく、作品そのものは非常によくできている。楽しめた。
2014-07-27
楽観主義者の未来予測、読了
実に楽観的な本を読んだ。未来は我々が思っているよりも明るい。一言で言うとそーゆーことらしい。
世の中には悲観論が渦巻いている。明るいニュースよりも暗いニュースの方が圧倒的に多い。メディアは暗いニュースしか伝えない。それは、我々がそのようなニュースを望んでいるからだと言う。
楽観主義者の未来予測(上): テクノロジーの爆発的進化が世界を豊かにする
楽観主義者の未来予測(下): テクノロジーの爆発的進化が世界を豊かにする
指数関数的なテクノロジーは、想像を超えて進化する。いま出来ないことが未来に出来るようになる。希少性が支配されていた時代から潤沢な世界に変化する。潤沢な世界を実現する力としてDIYイノベーター、テクノフィランソラピスト、ライジングビリオン。
テクノロジーがエネルギー、教育、医療、自由の問題などを解決する。
日経の書評に『若干脳天気ではなかろうか、という印象を与える本だ。そう思うのは私が「悲観主義者」だからというよりは、そもそも物事は予想通りにはいかず、それもたいていは予想よりも悪くなるというのが普通人の日常的実感だからだ。だがまさにこの本は、その普通人の感覚がよって立つ根拠に触れ、悲観的感情のことを、危険に満ち溢（あふ）れていた昔の心理的名残のようなものとして理解する。』と書いてあった。楽観主義者の未来予測（上・下） ピーター・Ｈ・ディアマンディス、スティーヴン・コトラー著 加速する技術で進化する人と社会 ：日本経済新聞
『その中で少しほっとすることもある。というのは、その未来像には、きれいな水の確保、貧困地帯の子どもたちの自律的学習の支援のような、基盤的なものへの眼差（まなざ）しが生きているからだ。ハイテクもいいが、人間の根源的条件はそう簡単には変わらないだろうから、もっと普通で誰もが味わえる快適感を多くの人と分かち合いたい。そんな気持ちがある限り、この楽観主義も、魅力に満ちたものになるはずだ。』
2014-07-26
Linuxとgitを作ったLinus
誰でも知っていることだけど、LinuxというOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。
Linus Torvalds - Wikipedia, the free encyclopedia
1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。
当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出したので自宅のPCにインストールしてみたりした。
1998年はNetscapeが、そのブラウザのソースコードを公開したことで、オープンソースが突如として注目を集め、Eric Raymondの「伽藍とバザール」によってLinuxの開発方法論が明らかになった。
Linuxを作ったLinusは人前に出ることが苦手と言ってはばからないが、それでも1998年ころにはいろいろなところに呼ばれて話をしていたりした。
LinusがLinuxを通して明らかにしたこと、それ以前は当たり前と思われていなかったことは、インターネットを利用したバザールモデル（ソフトウェア開発方法論）が有効でスケーラブルだということだ。オープンソースの開発において普通に行われている、早めのリリース、頻繁なリリースを大規模なプロジェクトで適用し、それが有効だということを示した。
それまでのソフトウェア開発に於いては、十分な計画と明示的な指揮系統が必要だと思われていたものが、計画もなければ、明確なプロジェクトリーダーもいないソフトウェア開発プロジェクトが成功しているという奇跡である。うまく行く筈がないプロジェクトがうまく行っているということが奇跡であった。
そして、Eric Raymondはその奇跡を「伽藍とバザール」というエッセイで記述したのが1997年である。ハッカー界隈では知られていたことを明確に言語化して、ハッカー以外のコミュニティというか一般社会に広く知らしめた。
情報を公開すると進化する。これを実証したのがLinuxのプロジェクトだ。
インターネットを利用して、あったこともなければ見たこともない人から送られてくるパッチをひたすらマージすることによって、すごいスピードですごいソフトウェアを作り上げていく。そのようなことがうまく行く筈がないというのが常識であった。その常識をとてつもない規模で否定したのがLinusでありLinuxであった。
そして2005年にgitを作る。分散コード管理システムだ。世界最大のオープンソースプロジェクトを支援するためにLinus自身が２週間ほどで作り上げた。
gitによって、自由にリポジトリをコピー(fork)して、ずんずん開発するというスタイルが一般化した。後にソーシャルコーディングという概念が生まれてgithubのようなサービスが登場する。コミュニティーによる開発が当たり前になる。
Linuxの開発方法論の発明と実証、そしてその分散開発を支援するツールとしてのgitの発明。Linusがこの20年で世界を変えた２つのすごいことである。
この二つの発明で、世界は変わった。それ以前とは全く違う世界が見えてくる。オープンソースの価値を世界に知らしめた意義は大きい。
- Twitter / @otyoppu
- Twitter / @mironal
- Twitter / @anakamura_fs
- Twitter / @irration
- Twitter / @hyoshiok
- Twitter / @daichi
- Twitter / @atauky
- Twitter / @sleeping_husky
- Twitter / @yutakama
- Twitter / @i_takehiro
- Twitter / @yymm6666
- Twitter / @loAolb
- Twitter / @mizuno0to
- Twitter / @0363849000
- Twitter / @100kouji
- Twitter / @panther_king
- Twitter / @panther_king
- Twitter / @atakig
- Twitter / @naokis
- Twitter / @hyoshiok
- Twitter / @hyoshiok
- Twitter / @hyoshiok
- Twitter / @enogu
- Twitter / @taniyang
- Twitter / @itchyny
- Twitter / @hyoshiok
- Twitter / @ingktds
- Twitter / @JchanKchan
2014-07-25
OSCON 2014、まとめ
OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
OSCON (Opensource Convention) は文字通りオープンソースを主要テーマとした大規模なコンベンションだ。
オープンソースはもはや技術というよりも社会的な営みなので、議論される話題やセッションも多岐にわたる。1997年にEric Raymondが「伽藍とバザール」によって発見したLinuxにおける開発方法論のイノベーションは、ソフトウェア産業のみならず、広くハイテック産業そして社会そのものを大きく変えた。
技術によって社会をよくするという楽観主義がインターネットには満ちている。ハッカー精神といってもいい。オープンソースというのはそのハッカー精神が作り出したムーブメントだ。
OSCONは1999年に初めて開催され、その当時はイノベーターやアーリーアダプターによる会議であった。ガードナーのハイプ曲線によれば、キャズムを超え、マジョリティになった。にもかかわらず、オープンソースにおけるイノベーションが持続しているというのは興味深い。
若い世代が、どんどん参加して、新しい企業が当たり前のようにオープンソースを利用して勃興する。エコシステムがそこにはある。
オープンソースを利用するだけではなく、そのコミュニティに参加するのが当たり前のプログラマーが多数いる。
Facebookの新入社員（中途入社の人々）は6週間のBootcampでFacebookの開発プロセスを学ぶということはよく知られている。新入社員の2/3はなんらかの形でオープンソースの開発に関わったことがあり、そのさらに半分はFacebookのThe Hacker Wayに共感して入社を決めたという。ハッカー精神が単なるドグマというよりも、技術者として専門性を高めていくために必須のコンピテンシーになっていると言っても過言ではない。
企業は優秀な技術者を雇用しなければ生き残れない。そのためにはそのような技術者が求める環境を提供しないとならない。一方で、技術者は自分の能力を継続的に高める、持続的学習を必要とする。その文脈の中でハッカー精神やオープンソースでの経験というものが、明示的に求められているということは興味深い。
DevOpsというムーブメントも開発と運用という対立するものではなく、共感による協調作業であり、それはオープンソースが発見した対立ではなく共感というコンテキストにマッチする。
O'Reillyという技術書を出版する会社がOSCONを主催しているというのも偶然ではない。90年代初頭インターネットの黎明期にPerlの参考書やインターネット関連技術書を多数発行し、現場の技術者たちが、その参考書で学び育っていった。そして、そのような参考書で学んだ技術者たちが社会を変えていった。
Linuxによってその有効性が示されたオープンソースの開発方法論が、ソフトウェア産業を破壊的に変革した。
ソフトウェア産業の覇者であったMicrosoftですら、それへの対応を余儀なくされた。IBMはオープンソースへの対応が早かったことで知られているが、それでも組織文化の変化には大変な困難があった。
変化への対応が生き残るためには必須である。それは大企業だけにはとどまらない。個人も同様である。変化を拒否し消えゆく大企業にしがみついて生きていくのか、変化に対応する能力を身に付け自ら選択し生きていくのか。技術者としての能力を高めるためにオープンソースコミュニティに参加し日々変化に対応していくのか。
オープンソースが当たり前になった今こそ、個人としての生き方についても、明示的に言語化し、行動することが重要だと思った。
2014-07-24
OSCON 2014, 5th day (Last Day)
早いもので日曜日から開催されていたOSCONも本日で最終日。
日曜日から木曜日まで開催というのは、海外渡航者からみると、金曜日に移動日で、土曜日に帰国できるのでカレンダー的には楽である。海外出張帰国日が日曜日で次の日から１週間出勤というのはちとつらい。
最初のキーノートがぶっ飛んでいる。意味が分からない。タイトルはThe Concert Programmerである。
The Concert Programmer: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
すでにYouTubeに動画があがっているので、だまされたと思って観てほしい。
（ライブコーディングとかは知っているけど…）。コードを書くと音が出る（ふーん）。右手の音をこうやって定義する。ピッチはこーだ。ついでに遅れもいれちゃおう（へー）。音が鳴っている。（お？）
2分30秒あたりからはじまる。シンセサイザーで演奏しているのとはまったく違う味わいがある。説明を聞きながらコードを眺めていると、魔法を観ているように感じる。
オープンソースとか一見関係なさそうに思えるこのパフォーマンスもキーノートに組み入れるプログラム委員のアンテナはすごいと思った。
参加者のレーティングは５点中５点（満点）だ。奇跡としかいいようがない。
電気冷蔵庫に主人が殺されて１年経ちましたというようなタイトルのキーノートは、組み込みシステムにおけるセキュリティ脆弱性の問題を指摘している。
発表者のおねーさんがいい味を出していてすごくよくて、そのおねーさんが漫画に出て来て説明をするのだけど、いかんせん、The Concert Progammerの後ではインパクトが弱かった。もったいない。
その次の発表もインパクト（特に胸）のあるおねーさんがやっていた。
プロの漫画家で、絵に味がある。いいよね。プログラマとデザイナーがコラボレーションをするとすごいことができるという話だ。いい話だな。
個別のセッション/Let Them Be Your Heroes
Let Them Be Your Heroes: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
Francesca Krihely (MongoDB)
ヒーローを作ろうというセッションは予想外によかった。このセッションについては別途感想を記したい。
記念に写真を撮らせてもらった。You are my hero. だと伝えた。
International Community Building: Bridging Japan and the Rest of the World
トレジャーデーターがどのようにコミュニティーを巻き取っていったかを説明していた。日本人が作ったオープンソースとしては例外的に世界で使われている。その秘密はなにかということが議論された。英語でドキュメントを書く。英語で議論をする。当たり前のことを当たり前にやる。日本ではあまり、海外発信の重要性をいう人がいないので、このような議論は重要である。
OSCON Town Hall
http://www.oscon.com/oscon2014/public/schedule/detail/36923
OSCON Town Hall
Gina Blaber (O'Reilly Media, Inc.), Matthew McCullough (GitHub, Inc.), Sarah Novotny (NGINX), Simon St. Laurent (O'Reilly Media, Inc.)
タウンミーティングは事務局と参加者が直に話をする機会だ。特にアジェンダはなくアンカンファレンス形式で、サブジェクトがどんどん変わっていく。細かいロジ周りの不都合なども指摘されたりするので、イベントオーガナイザーの目線でも楽しめる。どのような工夫をしているかなどの裏話も出てくる。
いろいろ気づきの多い１週間であった。感想などはまた別途まとめたい。川の向こう側に行ったらビアフェスタをやっていたので、10ドル分ビールを飲んでいい気持ちになった。
2014-07-23
OSCON 2014, 4th day #OSCON
4日目。朝は雨が降っていた。会場についてから降り始めたのでぬれることはなかった。
Schedule Grid: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
司会の３人は昨日と同じだ。
司会のサラ。
イギリスから来ているPerlのレジェンド、Piers Cawleyの歌声を聞く。
Something To Remember: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
Tim O'Reillyのキーノートはテクノロジーではなくて、その使い方で社会が変わってしまったというような話だった（あまりにざっくりなまとめ方）
OSSへ女性の参加を促進する団体Girl Develop Itの話。
http://www.oscon.com/oscon2014/public/schedule/detail/37148
Modernizing CS Education with Open Source
ランチのあとは、時差の関係で睡魔が襲ってくる。一番前に座って、質問でもしないと寝てしまう。
オープンソースを利用してスタンフォード大学のコンピュータサイエンスの授業を近代化するという話。
発表の途中に手をあげて質問をした。
http://www.oscon.com/oscon2014/public/schedule/detail/33994
Rebooting Open Source at Facebook
Facebookでのオープンソースの利用が停滞していたのでそれをリブートしたという話。
展示会場のO'ReillyのブースにGOの専門家のFrancesc Campoy Flores (Google Inc.)がいたので、話を聞いた。明日、発表するそうである。日本でGOコンをやったよと嬉しそうに話していた。GOは中国ではよく利用されているらしい。
http://www.oscon.com/oscon2014/public/schedule/detail/37717
CLA’s: Best Thing Since Sliced Bread or Tool of the Devil… A Panel Discussion
Moderated by: Danese Cooper (PayPal)
Panelists: Brian Behlendorf (Mithril Capital Management LLC), Richard Fontana (Red Hat, Inc.), Bradley Kuhn (Software Freedom Conservancy)
Contributor's License Agreement (CLA) についての議論だった。英語の議論についていけなかった。（睡魔にまけた）
http://www.oscon.com/oscon2014/public/schedule/detail/34705
What is Happening at the CentOS Project?
CentOSは使っていないので、コミュニティーの空気とか、よくわからないが、Red Hatがサポーターになったので、安定して開発が行われそうである。
2014-07-22
OSCON 2014, 3rd day
日曜日からはじまったOSCONは、最初の日と二日目がワークショップやチュートリアルで、３日目からセッションがはじまる。朝一はキーノートだ。
Schedule Grid: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
司会が３人いる。
トップバッターは14歳のShadaj Laddadだ。子供がプログラミングを学ぶことについて話した。すごいな。 The Wonders of Programming: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
そのほか、Google Summer of Codeが10周年という話が印象に残った。 10 Years of Google Summer of Code: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
ポスターがはってあった。
その後、個別のセッションに出て、ランチの後は、展示会場でやっていた、Tim O'Reilly のトークセッションにでた。これはTimに会場から質問をして、それを答えるというラフな感じの雑談会である。
会場からの質問に気さくに答えるTim O'Reillyである。
最初に出た、Facebookの人のお話は、規模がすごいことになっている。
Move Fast and Ship Things : OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
MAU (Monthly Active User月間アクティブユーザ数)/DAU(Daily Active User 日アクティブユーザ数）がすごい。さらにすごいのがPCではなくてモバイルユーザ数の劇的な伸び。
Dockerのコンテナはセキュリティ的にはどーなのよということであるが、VMと違って、明確に環境が分離されている訳ではないので、いろいろとあるよねという当たり前と言えば当たり前のお話である。
英語の書き方のセッションはもっと前のめりになって聞くべきだったかもしれない。最低限Element of Style （未読）くらいは読んでおく必要があると思った。（昔から読まないとと思っているのだけど、そう思っているうちに今に至る。とほほ）
Writing English : OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
コミュニティをイベントで育てるというタイトルのセッションはPuppet LabsでコミュニティマネージャをしているKara Sowles。髪の毛が紫でインパクトがある。その後、展示会場のO'Reillyのブースでお話をする機会があった。マシンガントークと言うかすごいパッションでおじさんは圧倒される。
Grow Your Community with Events: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
Continuous Learning というのはやはりContinuous Integrationとかから始まる一連の「継続的」なんちゃらの名前に乗っかった感じだけど、学習というのは、試験を受けてそれで終わりと言う性質のものではなく、ずっとずっと学び続けると言う宿命みたいなものがあるので、「継続的学習」というのは、当たり前と言えば当たり前のコンセプトである。だけど、あえてそれを強調する必要があるのは、資格試験に対するアンチテーゼ的なスタンスがあるのかもしれない。（邪推ですいません）
CODE CLUBというのを提唱していた。好きな本を読んで感想を語るというのが、BOOK CLUB（読書会）で、それと同様に、コードについて語るというのがCODE CLUBだ。プログラミングを学ぶには良いコードを読まなくてはいけないけど、それをやるきっかけがCODE CLUBである。うひょー。15年前にカーネル読書会を発足したのもまさに同じ動機だったりする。（長くなるので省略するけど）
その後展示会に行ってTシャツとかグッヅをいっぱい貰って来て、ビールとかワインとかをしこたまいただきヘロヘロになる。
OpenStackの4周年記念のパーティーは大盛況であった。NECの柴田さん、高田さんとお目にかかりご挨拶をするなど。
コミュニティまわりのセッションにいろいろ出て見たがイベント開催などについての形式知が議論されているのがよかった。自分の経験とてらしあわせて、貢献できる部分が少なくないと感じた。
パーティーや展示会も気合いが入っていて勉強になった。夜の９時頃からポーカーをやっていた。なかなか面白そうだった。ルールがよくわからないので参加しなかったけど。
2014-07-21
OSCON 2014, 2nd day
二日目。
いろいろなところにO'reillyの動物がいる。グワォー。
Schedule Grid: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
- Git for Teams of One or More: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
- Continuous Delivery: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
前者は分散ソースコード管理システムを利用したワークフローの話。隣の人と、仕事のワークフローについて話す機会があった。未だにCVSとかSVNでソースコードを管理している人がいっぱいいて、いろいろご苦労が多いなあと思った。ちなみに隣の人は米国SONYの人だった。プレステのなんかを作っていると言っていた。
後者は継続的デリバリーの講義。ひたすら話を聞くセミナー形式で、日本では普通の形式なんだけど、OSCONではむしろ珍しい感じだ。
昨日のベストプラクティスは今日のアンチパターン。ピザ２枚のチーム。（チームの最大人数はピザ２枚程度なので、多くても10人前後と言うことか。）わたしの計算式だと、ピザ一枚で３人なので、６名のチームになる。*1
いろいろ印象的なフレーズを聞いたが、明日まで記憶に残っているかかなりアヤシい。
その後、展示会などを観つつ、OSCONのパーティーに参加した後、Puppet Labのパーティーへはしごした。
OSCONのパーティーではHadoop ConferenceでおなじみのNTTデータの濱野さんとばったり。Facebook情報によるとS社のIさんがOSCON参加らしいということでビールでも飲むか（勝手に考えている）と思った。
OSCONはいろいろなコミュニティーが寄り集まっているので面白い。ランチではYAPC:NAのオーガナイザーと同じ席になった。日本ではYAPC:Asiaってのをやっているんだよとか言ったら、YAPC:Asiaでキーノートしたよ、と軽やかに返され、失礼しましたという感じである。
展示会では商用ブースも面白いのだけど、コミュニティーのブースがしょぼい感じ（失礼。褒めています）でよかった。日本のOSC的なノリで、おじさんが一人でブースの店番をしている。FreeBSDのところにいったら、「おお、日本から来たのか、ごとーさんって知っているか」と聞かれたので、知ってる知ってると適当に答えた。日本のオープンソースコミュニティーは狭いので、大抵知っているよ、それよりもWe're hiringなので、日本で働く気はないか、と言ったところ、隣にいたお兄ちゃんが名刺をくれた。日本が大好きなら、うちの会社に来るといいよと宣伝しておいた。
Puppet Labのパーティーは、オフィスでの開催で、ベンチャーのオフィスを見学できてよかった（昨年も行った）。
2014-07-20
OSCON 2014に参加
OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
本日これからチュートリアルなど。適宜、写真を交えて情報をアップする。楽しみだー。（下記、追記した）
Schedule Grid: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
Git and Github
Git and GitHub Essentials: OSCON 2014 - O'Reilly Conferences, July 20 - 24, 2014, Portland, OR
Git and GitHub Essentials 2 - Google ドキュメント
実際にGithubを利用しながらの説明。参加者もリポジトリをforkしてpull requestを投げるというのを体験している。
Docker
あらかじめ用意されていたコンテナにアクセスして、それを利用しながらの説明を聞く。ワークショップ形式のセミナーになっていて、200名前後の参加者が講師の説明に従って、コンテナを利用しながら理解を深めていく。従来のワークショップだと20〜30名程度が現実的な上限かと思うのだけど、コンテナを利用することでスケールしている。
Ignite
20秒毎にスライドが自動的に進んでいく。5分間のショートプレゼンだが、日本で盛んなLTとはちょっと違った味わいがある。
チーズが美味しい。ビール、赤、ビール、白などをいただいて、ヘロヘロ。
5km Run
http://www.oscon.com/oscon2014/public/schedule/detail/35853
ジョギングを日頃していない自分がたまに走る。泣きながら走る。あの電柱まで行こう、あの交差点までがんばろう、あの橋までいけば楽になる、一歩でも前に行くことを自分に課して走る。気がつくと最初の１キロを走っていて、苦しいけれど、もう一歩、前に行こう。気がつくとゴールだ。頑張った自分。
ランの後はビールと軽食でパーティー。楽しかった。
というような感じで、初日は無事に終了。時差の関係でセミナーは睡魔との戦いとなるのではないかと思ったが、ワークショップ形式ということもあり、寝落ちはしなかった。よかったよかった。
2014-07-18
チャック女子
外見は女子の着ぐるみを着ているが、背中のチャックを下ろすと中身はおじさん、というオス化女子のことを指す。女性が視点も思考パターンもおじさんと同一化してしまう現象のことだ。
http://womantype.jp/mag/archives/25240
女性の管理職というのが、チャック女子によって占められている、ということらしい。
日本の大手企業の場合、新卒採用、終身雇用、企業内組合という労働慣行があると言われている。さすがに終身雇用や企業内組合などの制度は徐々に崩壊しつつあるとしても、そのような傾向はまだ残っている。
新卒で入社して、その会社に長いこといると、その会社の文化にどっぷり浸かってしまって、金太郎あめのような価値観になる。そして、そのようななかで管理職になれば、チャック女子になるということなのだろうか。
スタートアップの場合、そもそも終身雇用でもないし、新卒の一括採用でもないので、金太郎あめになりにくい。会社の歴史も新しいので、そのようなしがらみも少ない。
家庭を顧みないで、会社の仕事を優先するという価値観を持たないと管理職が勤まらないという企業であれば、女性管理職もチャック女子にならざるを得ないが、さすがにそのような時代でもないと思う。
いろいろな価値観を認め、いろいろな人生を認めるというのは簡単なようでいて簡単ではない。男性と女性の生き方にも社会的な非対称性が認められる。社会が暗黙的にもとめる性別による役割分担というのがなくはない。
チャック女子という言葉に込められた意味をぼんやりと考えてみた。（結論はない）
今企業で“アクセサリー女子”と“チャック女子”が増えている！ 女性が陥るキャリア上の“10大疾病” - Woman type [ウーマンタイプ]
2014-07-17
読了せずw
図書館で本を借りていると読み終わらない本が出てくる。貸出期限までに読了しない。
返却しなければいけないので、後ろ髪を引かれつつ、あー読めなかったなあ、と思うのだけど、それはそれとして縁がなかったと諦める。人生に諦めは時には必要である。
土曜日から出張なので、今日明日に借りている本を返却しないと。
経営戦略全史 (ディスカヴァー・レボリューションズ)
前者は近代マネジメントの源流から21世紀の戦略緒論までを概説したもので、様々な名著を紹介している。わたしのような素人には、全体像を俯瞰できるので便利な一冊になっている。
後者はウィキノミクスからマクロウィキノミクスへの、あらゆる知がつながる時代について記している。
また借りるかどうかは後で考えることにする。
2014-07-16
システム管理者、感謝の日イベントに参加した。
講演とパネルディスカッションに参加した。
第8回システム管理者 感謝の日イベント システム管理者のための夏期講習2014 すべての企業がITを武器にする時代のエンジニア魂を考える
大成建設の田辺さんのお話はお話がすごかった。建設業の場合、多くの協力会社と案件毎にプロジェクトを作っていくわけだが、大成建設では5700社ほどの会社とASPを利用して情報の共有をしている。
約50％の契約書が電子化されているそうである。直接的なメリットとして印紙を貼る必要がないので、協力会社のコストは年間約２億円のコスト削減になるそうである。
請負契約に係る注文請書を電磁的記録に変換して電子メールで送信した場合の印紙税の課税関係について｜福岡国税局｜国税庁
No.7102 請負に関する契約書｜印紙税その他国税｜国税庁
建設業では、紙を利用して図面などを共有しているという印象があったが、IT業界よりよっぽど電子化が進行している。電子署名を利用した契約書の電子化ってどのくらい進んでいるのだろうか？印紙を貼る必要がないというのがすごい。
よくIT業界を揶揄する言葉としてITゼネコンという言葉を使うが、ゼネコンに失礼だと思った。
どんなプロジェクトも工期通りに終了する。工期が遅延して品質もぼろぼろといういわゆる「デスマーチ」のようなものは建設業ではほとんど起きないそうである。それはやっぱり工事現場だとものが出来ていくのが見えているので、ヤバい問題はわりと早く発見できるかららしい。結局、問題を可視化して、早期に問題を発見し、早め早めに手を打つということらしい。
ゼネコンではプロジェクト毎に協力会社も違うし、多数の利害関係者がいる。プロジェクトマネージメントのノウハウがそこにある。すごい。
2014-07-15
2014-07-14
ロードムービーが好きだ
ロードムービーというのは主人公がなにかのきっかけで旅に出ることになって、その道中でいろいろな事件に巻き込まれながらも、どうにかこうにかそれを解決していって、様々な困難に打ち勝つことによって成長していくと言う物語だ。
人生なんて言うものはロードムービーみたいなもので、いまは平和な時を過ごしているとしても、次の日には、いきなり追いはぎに身ぐるみを剥がされてしまうかもしれないし、身に覚えのない犯罪の嫌疑をかけられてしまうかもしれない。あるいは、余命幾ばくかもない不治の病にかかってしまう。
そのような様々な困難に向き合うのがロードムービーで、主人公は挫折しそうになりながらも、どうにかその困難と折り合いをつけていく。
U.S. Route 66 - Wikipedia, the free encyclopedia
旅というのは、そのようなロードムービ的な非日常を追体験するもので、ハプニングこそが旅の醍醐味である。旅が終われば帰るところがある。
東海道をてくてく歩くのも、自分にとってはちっちゃなロードムービみたいなもので、散歩の中に非日常を見いだそうとするのもロードムービ的な何かを求めているからに他ならない。
いつか、アメリカの東海岸、ボストンあたりからニューヨークを経由して、西海岸まで車で横断してみたいと思う。ハイウェイをひたすら西に向かう。夕方、場末のモーテルにチェックインして、その街のしょぼいハンバーガーショップでとんでもない量のフレンチフライにケチャップをどばどばかけながら、グラマラスなウエイトレスと与太話をする。
ラジオのDJが今日の天気とトラフィックジャムの情報を流している。なんちゃらブリッジは工事中なので迂回した方がいい。
ヒッチハイクをしている若いおねーちゃんを拾ったことによって、わたしの旅はあらぬ方向へ走り出した。
というような感じの旅をしてみたい。
2014-07-13
闇の中の男、ポール・オースター著、読了
闇の中の男
夜、眠りがやってこない時に、男は物語を作る。男は、娘と孫娘と同居している。孫娘と夜、家族の秘密について語ることもある。
男が創ったもう一つの世界は米国が内戦をしている。そして、その世界に突然放り込まれたオーエン・ブリックという若者は、その元凶の書評家オーガスト・ブリルを殺せば、内戦が終わり元の世界に戻れる。二つのパラレルな世界が交互に進んでいく。ブリックのいる世界は貿易センタービルはあるが内戦をしている。ブリルを殺して内戦を止めることが出来るのだろうか。
2014-07-12
Done（完了）の定義とリリースブランチ
Doneだ。終わったよという宣言をするのは心地よい。しかしながらこの「完了」という言葉ほどソフトウェア開発現場では曖昧に使われているものはない。
わたしも新人の頃、いいかげんに使っていた。
よ「〜の機能の実装完了です」先輩「ビルドした？」よ「コーディングしただけです」先輩「ばかやろ、それは実装完了とは言わねーよ」よ「すいません」、（あれやこれや作業）…、よ「ビルドしました。コンパイルエラー、ビルドエラーとかないっすよ」先輩「で、テストした？」よ「てへ」先輩「お前あほか」、（あれやこれや作業）…、よ「テストしましたーー。ばっちりっす」先輩「あれ、こっちでは確認できないなー。ソースコードをチェックインしたの？」よ「あ、自分のローカルな環境でしか試してません」先輩「おい首締めるぞ。チェックインしてから言えよ」、（あれやこれや作業）…、よ「チェックインもしました」先輩「やっとか。どれどれ。あれー、〜の機能が動かないなあ。〜はどう実装したの？」よ「あ、〜の実装はまだでした」（振り出しに戻る）
上記会話は実話に基づく創作です。
結局、コーディングして、ビルドして、リグレッションテストにかけて、出荷できる品質まで持っていって、それで完了ということになる。ソフトウェア製品の場合は、プログラマが自分の作業が完了というのは、自分の担当のところが出荷できる品質になったことをさす。毎日毎日全ビルドしているので常に動くものがある。その動くものの品質は時には不安定になることもあれば安定してバグ（不具合）が少ないこともあるが、常に毎日動くものが存在する。
自分の担当の部分のテストはすべて問題がないということを毎日確認する。時には誰かの変更の影響で自分の担当のテストが壊れることもあるが、そーゆー場合は朝会社に来て、その壊れた原因を分析するのがトッププライオリティになる。そして、壊れた原因が自分の問題であれば、それを修復するし、変更した誰かの責任であれば、その人に修正を依頼する。常に動くものを維持しておく。それがディリービルドを利用した開発のリズムである。
ビルドを壊さないで開発をすると、毎日少しずつ機能が追加されていく。毎日、品質にばらつきがあるとしても動くものが存在する。実装が完了した機能リストをみながらリリースマネージャーが、いつのタイミングで出荷するか決定する。ある時点で、ほぼ実装すべき機能がそろったとしたら、そこから安定化プロセスにはいる。それは、機能フリーズと言って、新規機能は一切追加しない出荷用ブランチを作って、ひたすらバグだけを直していくフェーズになる。例えば現状で1000個の不具合がバグデーターベースに登録されていたとしたら、そのバグに優先順位をつけて、新機能の開発をとめてバグだけを直していく。修正が簡単なバグも難しいバグもあるが、ひたすら直していく。そうするとみるみるうちにバグが収束していって、出荷規準を満たすまで続く。
データーベース製品の場合、メジャーバージョンアップが２−３年毎くらいの周期なので、出荷されるまで、毎日のビルドが数百とか1000を超えることがある。その特定のビルドを選んで、そこから安定化プロセス（リリース版の開発）が始まり、出荷されることになる。リリース版はサポートが終了するまで維持管理される。通常、出荷されてサポートされるバージョンは複数あるので、リリースのブランチは複数存在することになる。
Streamed Lines: Branching Patterns for Parallel Software Development
ウェブ開発だと、複数のリリースを同時並行的に長期間維持するということはまれなので、Github flowのようなシンプルなバージョン管理、リリース管理になる。
2014-07-11
1000 Speakers conference in Englsih #1000eng開催
会を重ねること8回。英語での発表の機会を提供しようということで、毎月一回開催している。言葉は使わないと使えるようにならない。なので、発表する機会を用意して、練習をしようということである。
第８回時点で発表者の総数が52名（52番まで会員番号をふった）。あと、948名。参加者が1000人を超えるまで続けるよ。
今回は、飯尾さんがつれて来た中央大学の学生さん3名（そのうち1名が初参加）が元気に発表していた。パチパチパチ。素晴らしいっす。若い人は（おじさんもだけど）、どんどんチャレンジしてほしい。
1000 Speakers Conference in English | Doorkeeper
今回は20名近くの参加者を集め地味に開催。参加者はビールを飲みつつお気楽に発表を聞いている。ビールつまみ付きで1000円。英語の練習になる飲み会だと思えば超お得。コストパフォーマンスがめちゃくちゃいい。おじさんは、適度に酔っぱらいつつ、英語の練習になって満足度が高い。
次回は8/7（木）開催予定なので、奮って参加してほしい。できれば、今年中に発表者のべ100名を超えたい。そのためには48名の新規参加が欲しい。
英語で、自己紹介を出来るように準備、練習してきてほしい。怖くないよ。1000 Speakers Conference in English 9 #1000eng - 1000 Speakers Conference in English | Doorkeeper
毎度、会場を提供していただいている産業技術大学院大学(AIIT)そして会場係でお世話になっている上田助教、いつもありがとうございます。大変助かります。
2014-07-10
シェルスクリプト高速開発手法入門、読書中。第２章を読んだ。
シェルスクリプト高速開発手法入門を上田さんから貰った - 未来のいつか/hyoshiokの日記の続き。
日記を書いた時はまえがきしか読んでいなかったのだけど、第１章はじめに、第２章環境の準備を読んだ。久々の横書きの本なので時間がかかる。というか、いちいちコマンドを打って確認しながら読むと亀の歩みという感じ。このペースだと、読了は三年後になりそうなので、せっかくいつもお世話になっている上田さんから貰った本なので、速攻で紹介して、少しでも売上に貢献しようと言う余計なお世話感で、（全部を）読んでもいない本を紹介した。
本の紹介というのは、わざわざ日記で書くという時間的コストを払う以上、読んでなにかを得た本じゃないと本を紹介するというインセンティブはない。読んだ本に難癖をつけることを芸風にしている人がいるが、読んでつまらなかった本は紹介しないだけである。わざわざ時間をかけてまで日記に書くというモチベーションがわかない。わざわざ罵倒というか文句を言うこともない。
第２章では本書が扱う諸処のツールについてMacやPCサーバー(Ubuntuを想定）にインストールする方法が書いてある。Macというのがいいね。
ということでさっそくあれやこれやわたしも入れて見た。この春にMacbookAirを変えてからツール類の整備は放置していたのでMacにcoreutilsを入れてみる。その他あれやこれや。
GNU系のツールはUbuntuでは標準なのだけど、MacのUnix系のツールとGNU系のそれとはいろいろ微妙に動作が違っていたりして、それがシェルを動かすときの差となるので、なるべくポータブルな解を求めたいところであるが、本書はGNUを使う。この割り切りが特徴とも言える。
55ページにOSと環境選びをもう少しこだわりたいがと題する後藤さんのコラムがあって、「Ubuntuをエッジサーバーに採用する利点はほかにある。運用やトラブルシューティングに関する情報を日本語で得やすい。日本のエンジニアは問題の根本解決を目指すよりもGoogleで検索してすでに提示されている方法を模倣することで解決する傾向があるため、日本語でこうした情報が得られるかどうかが重要になる。」
うひょ辛口、すいませんすいません。
2014-07-09
社内勉強会とパートナーエンジニア
社内勉強会は参加者の利便性を考えて昼休みに開催することが多い。昼休みならば、時短勤務のお母さんも参加できるし、夜学に通っている人でも参加できる。
とは言え、社外の人を講師として呼ぶ場合は、必ずしも昼休みにお願いするということが可能とは限らない。その場合は、夜7時ごろから開催になる。
今回たまたま開催した勉強会では、参加者が少なかったこともあって、各自自己紹介をした。そうすると意外と協力会社のパートナー（常駐）エンジニアの方が多かった。
今まで気がつかなかったのだけど（人数が多いときは自己紹介をしないので）、パートナーさんの勉強会に対するニーズというのは潜在的には大きいのではないのだろうか。勤務時間中の勉強会の出席は契約にもよるだろうけど、勉強会は業務ではないのでパートナーさんが参加することは難しい。勤務時間外であれば、問題はない。
職場での勉強会のメリットは移動時間がゼロというところもあるが、社内勉強会であれば、業務にかかわる議論が出来て実務に結びつくというメリットがある。
社員（エンジニア）の成長を会社として支援することは経済合理的であるので教育に対する投資というのは多かれ少なかれ行われている。様々な形でのトレーニングや、自主的な勉強会である。しかし、パートナーさんへの教育というのは業務に直接関わるもの以外は通常は行われない。スキルは持っているという建前だからである。
継続的な学習というのは社員だろうがパートナーさんだろうが必要であるが、パートナーさんに対する学習支援というのはほとんど議論されていないような気がする。
2014-07-08
という
2014-07-07
システムインテグレーション崩壊、斎藤昌義著、読了
システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?
編集の傳さんから直々の献本。ありがとうございます。
先日読んだ、倉貫さんの「納品」をなくせばうまくいく
刺激的なタイトルである。副題が「これからのSIerはどう生き残ればいいか？」である。このままでいいのか、いやいいわけはない、という問題意識の本である。
わたしは、SIerでもないし、SIerに勤めた経験もないので、あくまで部外者の感想にしかすぎないのだけど、本書で述べられていることはいちいちその通り、おっしゃる通りである。
IPAの「IT人材白書2014」からの引用があるが、それが衝撃的で、ユーザー企業が今後新規／拡大をしていく分野（SaaSやPaaSなど）、IDCサービスへのSIerの関心は低く、SIerの今後の新規／拡大を予定している事業についてはユーザー企業の関心は低い。
斎藤さんは、「ユーザー企業に置ける情報システムが、”IT企業（SIerのこと）に発注して開発するもの”から”サービスを選択して利用するもの”へと変化しているのに対して、IT企業（SIerのこと）が必ずしもこの変化に対応していない」と推測している。
絶望的なSIerへ警鐘をならし、一方でその処方箋を記している。倉貫さんの「納品をやめれば」が各論の解決策だとすると、この「システムインテグレーション崩壊」はSIerの問題点の総論という形になる。
対応するSIerは生き残るし、対応しないところは生き残れない。身も蓋もないが、そーゆーことなんだと思う。外野がなんやかやいっても、生き残るかどうかは当事者次第ということである。
誤植と思われるところ
46ページ。2019年のIT部門と非IT部門の予算比率は逆なのではないか？
2014-07-06
MADE IN JAPAN、盛田昭夫著、読了
［新版］MADE IN JAPAN
本書は、ソニーの創業者の盛田昭夫が1980年代に英語で記し、それを下村満子が日本語に翻訳し1986年に出版したものの新版である。当時、世界中で出版され、日本でもベストセラーになった。それを読んでみた。
若い人はあまりなじみがないかもしれないが、盛田昭夫はソニーを井深大とともに1946年に創業し、一代で世界規模の企業に育て上げた。盛田昭夫 - Wikipedia
50年代にアメリカにわたってトランジスタラジオを売りまくる、1960年にソニーアメリカを設立し代表に就任する、日本企業として初めて米国でADRを発行、ニューヨーク５番街にソニーショールームを開設、1968年トリニトロン・カラーテレビを発売、1970年米国ニューヨーク証券取引所上場、1979年ウォークマン発売など。
本書が発行された1986年ころは、日本の経済的な成功が絶頂で今では考えられないが米国と経済摩擦が発生していた。日本から米国へ自動車、家電などが集中豪雨的に輸出され、その貿易不均衡が日米の懸案となっていた。
日本は不公正なことをやっているという米国の世論に対して、真っ向から反論を試みたのが本書である。前半は盛田とソニーの歩み、後半はソニーの経営哲学、アメリカ式と日本式のビジネスの方法、競争、テクノロジーとイノベーションなどが忌憚のない議論がされている。
トランジスタは米国ベル研究所で開発された。しかしそれをラジオにして売り出したのはソニーである。新しい技術を研究開発し顧客が求めるもの商品を企画し販売する。
今日、エレクトロニクス産業は、日々急速に変化している。たった一つわかっていることは、このビジネスが決して停滞しないということだ。中略
この技術革新の敵はほかならぬ自社の販売組織であることがある。販売組織が力を持ちすぎては技術革新に水を差すことがよくあるのだ。新技術を使った新製品を作ると、セールスマンの再教育をしなくてはならない。それには莫大な費用がかかる。つまり新製品を開発するということには、研究開発、新設備、宣伝広告、販売促進の費用が必要になるということだ．また、今よく売れていて収益のよう商品を、流行おくれにしてしまうことである。しかもそれらの商品はセールスマンにとっては売りやすい品物なのだ。225ページ
これはまさに、後にクリステンセンが言う「イノベーションのジレンマ」そのものである。盛田は、後にイノベーションのジレンマと呼ばれるようなことに対して明確に問題を認識していた。そして、常に新しい製品を市場に提供する以外に生き残るすべはない。
また米国のCEOが四半期の売上、利益など短期的な視点で経営をすることをたしなめている。企業は長期的な視点で研究開発などに投資をしなければ、未来の利益を損なってしまう、それが競争力をなくしていると主張する。
しかし利益しか頭にないと、将来の好機を見失うことになる。見返りを利益でしか考えないアメリカの経営者がよく口にする言葉がある。「これから数年先に、わたしの後釜に座る人間のために、なぜ私が今、目の前にある私の利益を犠牲にしなくちゃならないのだ？」225ページ
「日本の企業は、市場占有率を目先の収益性よりもはるかに重大視する。287ページ」
盛田の先見性とビジョン、技術に対する確かな目。日本にもすごい起業家がいたのである。
皮肉なことに、日本の経営者は90年代から米国流の短期的な視点を取り入れそれ以降、長期的に経営が低迷している。ソニーも21世紀に入って元気がない。
いまこそ先人の智恵に学びたいと思った。
2014-07-05
2014-07-04
大手町からとことこ歩く
大手町の日経ホールで勉強会に出て、そこからとことこ歩いてみた。日本で一番長い地下街が東京の大手町から繋がるっている。（と、日経の東京ふしぎ探検隊に書いてあった（笑））日本一の地下道、逆さスカイツリー…東京ふしぎ旅行 ：日本経済新聞
大手町の地下通路には千代田線、半蔵門線、丸ノ内線、東西線、三田線が連絡している。そしてそのままJRの東京駅、有楽町駅、さらには銀座線の銀座駅をつっきって、浅草線、日比谷線の東銀座まで行く。
写真は大手町界隈の地下通路図。
ここを通って、東京駅方面に抜ける。そして有楽町へ地下で行ける。
日比谷公園のあたりまで来た。
地上に出て、日比谷通りを南へ歩いていく。
最近出来た虎ノ門ヒルズ。
東京タワーも見えた。
2014-07-03
を読んだ。
2014-07-02
JR大崎駅の看板（山手線徒歩で一周）
山手線徒歩一周、約13時間。 - 未来のいつか/hyoshiokの日記で山手線一周を徒歩でしたわけだけど、駅毎に写真を撮っていって、通過したことの証拠にした。どうせとるなら、JRの駅名がちゃんと入った写真にしたい。ところが大きめの駅だと意外と駅名の看板が見当たらない。東京駅なんかもそのタイプの駅だ。丸の内口とかの看板はあるが、JR東京駅の看板はなかなか見つからない。池袋も西武の看板はあるけどJRは簡単には見つからない。
いろいろ探したところ東口というのがあって、そこの写真を山手線一周徒歩では撮った。
てなわけで、もう一度よってみたところ、南口の改札のところには立派な看板があった。
