2014-04-20
グーグル、アップルに負けない著作権法、角川歴彦著。読了
グーグル、アップルに負けない著作権法 (角川EPUB選書)
角川書店（株式会社KADOKAWA）の会長の角川歴彦が、クラウド時代のビジネスの現場を赤裸々に綴った。現場のビジネスの当事者がIT時代の本質を語る訳だから面白くないはずがない。
タイトルに「著作権法」というのが入っているので法律論かと誤解する人もいるかもしれないが、本書の肝は、IT業界の三国志である。主人公はグーグル、アップル、そしてアマゾンである。
彼らのビジネスの本質は何か。それに著作権がどのような役割を持っているのか。著作権を縦糸に企業経営者の三国志を横糸に織りなしていく。
角川が直接交渉した相手などとのエピソードを織り交ぜながら、クラウドベンダーの戦略を探っていく。角川書店という日本の老舗出版社の会長が自らのビジネスの土俵の上でグーグル、アップル、アマゾンと対峙したのか興味は尽きない。
第２章スマートテレビと著作権
第４章著作権の現状と将来を語る（対談）
アマゾン、アップル、グーグル、フェースブックの４社をギャング４と呼ぶ。そのギャング４が著作権者たちとクラウドプラットフォームでどのような対立をしているのか、どのようなエコシステムを構築しているのか、角川の交渉の当事者として綴っている。
「伊藤穰一。著作権をいくら強くしても、著作権者は儲からない。間違ったところに集中しちゃっているんだ。今の世の中というのは、いかにプラットフォームを作るか、ディストリビューションを持つか、ユーザーを持つか、そういうところに力が移っちゃっている。」52ページ
著作権法の第一条には、「文化的所産の公正な利用に留意しつつ、著作者等の権利の保護を図り、もつて文化の発展に寄与することを目的とする」とある。
私は第一条の文章が無性に好きだ。302ページ
著作者、事業者、ユーザー、この三者のバランスが重要だ。日本の事業者は主に著作者との濃密な関係のもと出版文化を創造して来た。一方でクラウドベンダーはむしろユーザーの利便性に比重を置くことで発展して来た。
「著作権法も時代の背景にある理念と社会実態そして加速化する技術変化に対応することは必須だ」303ページ。
わたしは角川の上記の主張に同意する。
2014-04-19
エンジニア適職フェアで講演をした
今回の講演は、パワポを利用したお話ではなく、司会の伊藤さんとの対談というような感じで行った。
ざっくりいって、プログラマ視点からのIT業界のこの30年みたいな感じの与太話である。
昔は、ソフトウェアを作りたければハードウェアベンダーに就職するのが当たり前で、その後、ソフトウェアベンダーが台頭して来たので、そこで働いて、90年代中頃以降インターネットの出現によって、IT業界のソフトウェアを作るところもごろっと変わった。
ソフトウェアを作るのがごろっと変わったというのはどういうことですかという伊藤さんの質問。ソフトウェア製品を作ることとウェブサービスの作り方は全然違う。例えば、OSでもRDBMSでもソフトウェア製品は出荷してインストールしてもらって使ってもらう訳で、出荷後に変更することはできない。組み込みソフトウェアも同じだ。一方でウェブサービスは出荷しない。インターネットの向こう側にあるので、AがいいのかBがいいのか、試すことができる。変更がすぐできる。ソフトウェア製品の変更は年の単位。一方ウェブサービスは月とか週の単位でどんどん変更できる。
プログラマとしてどこに軸足をおくのか。
世界第二位のコンピュータベンダーだっていとも簡単につぶれちゃう業界なんだから、それにそなえるということはどういうことなのかとか。
イノベーションのジレンマというのはこれは避けられない必然なので、破壊的なイノベーションを受けて沈む側にいるのか、それともそれをしかける側にいるのか。正解はないけど、そーゆーことを考えた方がいいかもしれない。
だけど、中にいると破壊的なイノベーションで自分の会社のビジネスが破壊されているということは残念ながらなかなか気がつかない。気がついたときにはもう遅い。
DECはIBMが作った汎用大型機（メインフレーム）の世界をミニコンピュータという破壊的なイノベーションで破壊する立場だった。80年代飛ぶ鳥を落とす勢いであった。
それが、PCやUnixワークステーションという次の破壊的イノベーションに破壊されてしまった。
成功体験をアンラーニングすることが非常に難しい。
OSSもソフトウェア業界にとっての破壊的イノベーションだ。Oracleという会社にいて、製品を無償公開するというのはありえないし、クレージーだと思った。どう考えてもうまく行く訳がないと思った。無償公開するだけではなく、一番重要な価値の源泉のソースコードを公開するというのも意味が分からなかった。だけど、一方でその動きにとてもわくわくしている自分がいたことを覚えている。
1998年3月31日（日付も鮮明に覚えている）にNetscapeのソースコードをダウンロードして、モデムでピコピコして、昼は会社でRDBMSのカーネルをいじって、夜は自宅でNetscapeのソースコードをいじっている。どう考えてもおかしい、クレージーだと思う。
インターネットはOSSによってできている。LinuxやApacheやらみんなOSSだ。
自分はアンラーニングすることが難しいということを知っているし、時々、破壊的イノベーションが起こるということも知っている。なので、どう考えてもだめだろうというアイデアも大抵はだめなんだけど、ひょっとしたら破壊的なイノベーションなんじゃないかと思って無条件に否定しないように気をつけている。
自分はいったい何者になりたかったんだろうか。
IT業界のこの30年間は、本当に変化に富んでいて面白かった。DEC時代の憧れのエンジニアにわたしはなれただろうか。そんなことを思ったりする。自分にとってのロックスター。自分は誰かにとってのロックスターになれただろうか。
2014-04-18
そして、星の輝く夜が来る 真山仁著、読了。
そして、星の輝く夜がくる
そして、星の輝く夜がくる
様々な問題を抱える、子供、親、教師、地元の人、ボランティア、それぞれのおりなす人間模様が面白い。
「ハゲタカ」で描いた強欲な人々ではなく、市井の人たちの姿が等身大で描かれている。ひたむきな小野寺のキャラクターがいい感じだ。
「小さな親切、大きな…」は、災害ボランティが起こしたトラブルと、なんでも厳密に管理することをよしとするボランティア代表の相原さつきと地元のあんちゃん、小野寺らが夏祭りの件で一悶着するお話だ。
津波で担任の子供を失った教師や、家族を失った人々が、それぞれの問題を抱えながら生きていく。
みんなそれぞれ一生懸命に生きているのが素敵だ。
小野寺はいろいろ物議をかもしながらもクラスにとけ込んでいく姿がいい。なんでもお見通しの校長、官僚的で杓子定規な教頭。けんかっ早い、漁師の松井などなど個性的なキャラクターがいる。
2014-04-17
質問を引っ張りだす方法
勉強会などに行って、ふむふむ勉強になったと満足して帰る人は多い。だけど、質問する人は少ない。圧倒的に少ない。
話を聞いていれば疑問に思うことや不思議なことや理解できないことがいっぱい出てくると思う。もし一つもなかったとしたら、それは知っていることを報告する会だったり、そもそもなんでそこにいるのだという類いなもので、まあ、そんなことはほとんどない。
だけど質問をする人は少ない。
質問することが悪いことだという訓練を人生においてしてきたのではないかというくらい質問をしない。
質問をするということは、説明している人が説明していることを自分なりに理解して再構築して、その上で疑問点を表現するという、能動的な作業が必要になる。
ぼーっと聞いているだけでは質問できない。
質問が出ると、質問者は自分の疑問が解消されるだけではなく、発表者の発表方法や内容そのものに対するフィードバックになるし、発表者にとってもメリットがある。
質問を促さない発表者はそれだけで損をしていることになる。
そこで勉強会をやる側として質問を発生させる仕組みを考えたいところである。
一つは紙を配って、そこに質問をなんでもいいので書いてくださいというのがある。
あるいは対話を周りの人としてもらうワールドカフェ形式もある。
カーネル読書会みたいなのはワールドカフェにはあんまり適さないけど、紙を配って質問を書いてもらうというのはいいかもしれない。今度やってみたい。
2014-04-16
再利用できる画像の検索方法
インターネットで検索して適当にコピペするというのは、その画像の著作権を持っている人の権利を侵害する可能性が高いので、よろしくない。
2) Usage rightsをクリック。そのなかで権利関係で選ぶ。ライセンスでフィルターしない。再利用、変更可能。再利用可能。非商用、再利用、変更可能。非商用、再利用可能。のなかから選ぶ。
再利用可能な画像はいっぱいあるので、そこから選んで利用しよう。くれぐれも、自分が著作権を持たない、画像をぺたぺたはるのはやめよう。よく、マンガのキャラクタなどを分別なしに使っている人がいるが、おすすめできない。多くの場合は引用の範囲を超えているので、やめたほうがいい。
http://search.creativecommons.org/
- Twitter / @yomoyomo
- Twitter / @tareneko_72
- Twitter / @hyoshiok
- Twitter / @shenie_ch
- Twitter / @hyoshiok
- Twitter / @submoodle
- Twitter / @ryuu_11111
- Twitter / @SassaHero
- Twitter / @hyg_de_haizi
- Twitter / @hyoshiok
- Twitter / @kuronzero
- Twitter / @yugere
- Twitter / @guriko_
- Twitter / @hyoshiok
- Twitter / @tkuchiki
2014-04-15
この30年くらいでほとんどなくなってしまったもの
この30年くらいで（ほとんど）なくなってしまったもの。ワープロ。牛乳の配達。フィルムとフィルム式カメラ。駅の改札で切符を切る人。銀行の窓口での入金出金。駅の伝言板。 #なくなったもの
2014-04-15 19:11:20 via web
会社のビジネスがイノベーションによって劇的に変わるというのは30年くらいのレンジでみれば普通にあるけど、中にいる人はほとんど気がつかないことが多い。
真空管ラジオを作っていたメーカーが、トランジスタの登場によって、SONYに駆逐されたようなことが何度も何度もおこっている。
コンビニによって街の小さな本屋さんはなくなったし、牛乳の宅配というのもなくなってしまった。
プログラマという職業は30年前にはあったが、ウェブプログラマというのはなかった。そもそもウェブというのがなかったし、インターネットの商業化もされていなかった。10年のレンジでみても、スマフォはなかったし、Twitterもなかった。5年後に何がなくなってしまうのか。それは世界のどっかで今芽が出ているものに駆逐される運命にある。
2014-04-14
2014-04-13
創作の極意と掟、読了
を読んだ。凄味。色気。揺蕩。破綻。濫觴。表題。迫力。展開。会話。語尾。省略。遅延。実験。意識。異化。薬物。逸脱。品格。電話。羅列。形容。細部。蘊蓄。連作。文体。人物。視点。妄想。諧謔。反復。幸福。
漢字二文字の表題で、その項目についての筒井康隆の考えが述べられている。
凄味。「小説を書こう、あるいは小説家になろうと決めた時から、その人の書くものには凄味が生じる筈である。」
色気。「色気と言っても、強ち（あながち）男女の愛欲などのことには限らない。」
揺蕩。「今までの小説に飽き足りない。」
破綻。「ここで破綻というのは、小説の登場人物が破綻することではなく、あくまで作品の破綻である。」
濫觴。「濫觴というのは、小説に於いて言うなら冒頭、つまり書き出しのことである。」
…
索引。本書には索引があるので、ヘミングウェイが8回言及されているということを知ることができる。
筒井康隆の作品だけではなく、広く小説を題材に解説しているので、様々な書籍の読書ノートとしても読める。本書を読んで、紹介されている本を読むというのも楽しいと思う。
2014-04-12
2014-04-11
1000 Speakers Conference in English, 5thを開催した #1000eng
なんやかんやで５回目になった。今回は今までで最多の28名の参加を得た。わざわざ参加いただいたみなさまありがとうございます（ぺこり）
http://1000.doorkeeper.jp/events/9598
また、英語でショートプレゼン(LT - Lightning Talks)をしてくれたひとも13名ほどいて、すごかった。面白かった。どんどん、この輪が広がっていくとうれしい。
月に一度、金曜日の夜に、つまみとビールを飲みながら英語でうだうだ発表を聞き、英語で雑談をする。非常に緩い感じでやっている。
わたし自身としては、LTの司会などを英語でやる経験値を増やしたいというもくろみがあって、何度も場数を踏むうちにだんだん、英語によるファシリテーションが出来てくるのではないかと思っている。やってみないとわからないので、ともかく失敗しながら経験値をあげている。
前説は、ほぼ毎回同じなのだけど、それも、何度もやって行くうちになれる。語学はスポーツと同じで、何度も何度も素振りを繰り返すしか上達の道はない。水泳の教本をいくら読んでも泳げるようにならないので、最初はちょっと冷たくてもプールに飛び込む。プールなので足は届くので、みんながいれば安心だ。何度も何度も発表をして、司会をすれば徐々にだけど上手になってくる。
ビールを飲みながら開催するというのは、自分がビールを飲みたいからで、別にお茶を飲みながらの開催でもいい。会社や友達と上記のような形式でやるのは楽しいと思う。どんどん東京以外の地域でもやるといいと思う。
今回も初めて参加の方がいっぱい来てくれて主催者としてもうれしかった。遠くは京都から来てくれた方がいた。（感涙）
京都でも開催しちゃってくださいw
わたしの日記（英語のお話）を読んで連絡をくれた方も参加してくれて、おおおあなたですか、とすごく嬉しかった。
英語に苦労している人、勉強したい人、人それぞれなんだけど英語縛りの飲み会みたいな感じで楽しんでいただければと思う。
インターネットを使って多拠点同時開催とかやっちゃったら、それはそれですごいかもしれない。
次回は5/9に開催予定である。今回参加できなかった人は連休の中日という感じではあるけど、ぜひ、参加してほしい。
http://1000.doorkeeper.jp/events/10421
発表者が1000人になるまで続けるつもりなので、発表はお早めに。今回で27番まで行った。今年中には100人発表までいくとうれしいな。
2014-04-10
破壊的イノベーション(disruptive innovation)ってなんだろう
新経済サミットに出てみて、いろいろな人の発表を聞いた。
登壇した起業家たちは、起業家予備軍とでもいうべき参加者に対し、失敗を恐れるなとか、リスクを取れとかを勧める。それを聞いてほいほい起業をする人が日本でボコボコ増えるというようなことはないとは思うが、自分なりに破壊的イノベーションってなんだろうということを考えてみた。
破壊的という位だから、従来の発想の延長にあってはいけない。従来の常識をまっこうから否定するような何かでないといけない。どう考えてもクレージーなアイデアでないといけない。誰もが納得するようなアイデアであれば、それは定義により破壊的ではない。
従来のものより「劣っている」ものとか、明らかに「欠点」のあるものとかは破壊的である可能性はある。多くの人がクレージーと考えるもの、うまく行く訳がないと考えるものが、破壊的だ。
誰もがクレージーと考えるものは、１）本当にクレージーでどうしようもない、２）破壊的なイノベーション、どちらかである。
PCは大型汎用機（メインフレーム）より、圧倒的に安かったが、機能や性能は劣っていた。そして、それが故に破壊的なイノベーションだったのである。
インターネットでものを買うなんてクレージーだ。誰がインターネットでものなんかを買いたいと思うか。そのような常識に挑戦したのがアマゾンや楽天だ。
インターネットの時代になって、従来の常識を打ち破るサービスが出て来ている。それは大いなるチャンスだ。
電話代がただになると何がおこるのか。SkypeやLINEやWhatsAppやViberなどなど破壊的なサービスが出て来ている。
そして、それは既にどこかで生まれているのであるが、残念ながらわたしにはまだ見えていない。
新経済サミットに出てそんなことを思った。
2014-04-09
新経済サミット2014に参加した
新経済サミット2014に参加した。
http://www.jane.or.jp/event/summit/2014/
昨年に続いて２度目の新経済サミット。今回の目玉はオラクルCEOのラリーエリソンだと思う。Oracle Open Worldですらドタキャンするラリーが果たして来日するか、そんなことがIT系のウォッチャーの主な関心事だったと言っても過言でない。
それはともかく、来賓あいさつが内閣総理大臣安倍晋三だったり、元駐日米国大使のジョンVルースだったり、大物感が半端ではない。
ラリーエリソンのキーノートはデータとプライバシーの問題に真正面から切り込んだ意欲的なものだった。オラクルオープンワールドでは聞けないような切り口のキーノートであった。スライドを一切使わないで話だけで聴衆を魅了するプレゼンテーションは素晴らしかった。
IT業界のなか、70年代から生き残っている唯一のカリスマ、現役経営者である。ビルゲイツも現役を引退したし、スティーブジョブスも今はいない。
三木谷さんとのQ&Aセッションも面白かった。スティーブジョブスとのやりとりを紹介していたが、90年代アップルのCEOに復帰したジョブスはマイクロソフトとの競争にほとほと疲れていて、ソフトではなくハードのビジネスに軸足を移したい、ソニーのような会社になりたいというようなことを言っていたらしい。
内閣総理大臣の挨拶
ドタキャンしなかったラリーエリソン
教育のセッションも印象に残った。テクノロジーが教育を革新するという予感があるが、未だに教育のイノベーションがおこっていない。大学などの高等教育機関にまったくイノベーションがおこっていないというのは注目にあたいする。MOOCのようなものが今後市民権を得ていくとしてそのときの教育の方法はどのようになるのだろうか。興味がつきない。
2014-04-08
英語で学ぶ方法、英語の教科書を読む
ソフトウェア技術の定番の教科書は英語で書かれている。世界で最初に日本語で書かれることはまずない。
そこで、英語の定番の教科書を読書会するのをお勧めする。英語の本を一人で読むのは最初はちょっと敷居が高くて難しく感じる。読書会ならば少しずつ読めるし、理解を確認できるし、ちょっと分からないことがあっても参加者に聞くことができる。
何人か仲間を募って、定期的に集まって、章ごとに担当を決め、発表するという定番の方式でもいいし、本の感想を皆で言い合うという緩い形式でもいい。
参加者には、その技術についての共通の理解、語彙が出来るので、仕事にでも応用できる。
英語の本を英語で要約するのは意外と難しくない。章は節からなっていて、節をつなげると章の主張になる。節はさらに小節になっているので、小節をつなげると節になる。小節は段落からできているので、それぞれの段落で何を主張しているかを理解できれば、小節、節、章の構造があきらかになる。
小説と違って技術系の文書はこのように構造が明確なので理解は難しくない。
英語は必要になったとき学べばいいという人がいる。技術系の仕事をしていて技術を学ぶとき英語が必要ではないという状況はない。
機械翻訳が発達すれば英語を学ばなくても日本語で読めるようになるという人がいる。まあその可能性はゼロではないにしろ、それを言い訳に英語を学ばない戦略というのは危険だと思う。人それぞれなので、そういう人生をおくりたければおくればいいと思うけど。
ある技術が明確に言語化されて定番の教科書になるまでには時間がかかる。そしてその教科書が日本語に翻訳されるまでさらに数ヶ月から数年かかる。
それを日本語になるまで待つという戦略は時間的にリスクのある方法になる。すでにそれだけのハンディキャップをおっていることになる。到底おすすめできない。
英語化戦略を日本語で書いても説得力がないのではないかという指摘は、英語で書いた場合、英語を読まない人が読まないという状況がある。
ちなみに最近、プレゼンをするときには、日本語でお話をする場合でも、資料は英語で作っている。その方がいろいろ再利用しやすので。問題は英語だと文字ばっかりになってしまって、ライブなプレゼンになりにくい。修行が必要なところである。
2014-04-07
エンジニアの英語化戦略
あなたが現役のエンジニアならば英語から逃れることは出来ない。エンジニアというプロフェッショナルな職業を選択した以上、自分の職業に誠実になるならば、学び続けなくてはならないし、その場合、英語を避けて通ることはできない。
まあ、50代以上で、もう引退だとか言う人であれば、ぎりぎり逃げ切るということは不可能ではないかもしれないが、それは現役エンジニアというカテゴリではないので、除外する。もちろん、50代だろうが60代だろうが現役であるならば英語から逃れることはできない。
少なくともインターネットの業界とかIT業界とかそーゆーところで飯を食っている人であれば、ほとんどすべての情報は英語でやり取りされていて、一次情報の質と量については英語のそれは日本語それを圧倒している。もし、そのような認識を持っていないとしたら、それはそれで相当ヤバいと思う。
もちろん英語を学ぶとか学ばないとかは余計なお世話である。人それぞれ。わたしがあなたの人生になにか口出しをする筋合いのものでもない。
しかし、50過ぎのおっさんの戯言として聞いていただきたいのであるが、あなたが20代や30代の若手プログラマであるなら、遅くはない、今のうちに英語で学ぶ方法を学んでおいた方が絶対いい。
某社の社内公用語を英語にするという話がおもしろおかしく取り上げられていたのは2010年だ。2012年から社内公用語を英語にしている。そして中途のエンジニアも新卒のエンジニアもどんどん日本人以外の比率が高まって来ている。
入社するまでにTOEICが最低でも800点ないと入社出来なくなって来ている。エンジニアとして優秀なだけではスタートラインにすらのれない。
英語で情報収集、情報発信が出来ないと、長い目で見て学習能力が劣っているとみなされる。現時点で同じ位のスキルがあったとして、一方が英語が全く出来なくて、インターネットで一次情報にあたれない人と、英語に苦手意識を持たないで、どんどん一次情報へあたれる人がいたら、学習速度は後者の方が高いと考えられる。
日本語で学ぶのと英語で学ぶのでは、後者の方が情報の質と量とスピードが圧倒的だからである。
海外からの講演者が日本の勉強会などのイベントにくることがあったとき、コミュニティレベルのイベントでは通訳者を確保することはコスト的にもできないし、そのような場合、英語が片言でも話せるか話せないかで理解力には雲泥の差が出る。
日本の業界はガラパゴスだなんだと揶揄されるが、自分自身がガラパゴスになっていないか、点検した方がいい。英語が全然出来なくてと自嘲気味語る暇があったら、英語力を少しでも磨いた方が、自分のエンジニア人生を長くすることになる。
世界はフラットだ。
- Twitter / @teruyasu33
- Twitter / @taniyang
- Twitter / @hyoshiok
- Twitter / @nosodar
- Twitter / @nosodar
- Twitter / @yoshiki_shibata
- Twitter / @hyoshiok
- Twitter / @bori_so1
- Twitter / @giapkim
- Twitter / @murayama333
- Twitter / @taketomato
- Twitter / @satonaoki
- Twitter / @hyoshiok
- Twitter / @hyoshiok
- Twitter / @hyoshiok
- Twitter / @rinoue888
- Twitter / @xga
- Twitter / @hyoshiok
- Twitter / @rewtheblow
- Twitter / @hyoshiok
- Twitter / @enumorish
- Twitter / @joe_hrmn
- Twitter / @yoshisukek
- Twitter / @huiping192
- Twitter / @hyoshiok
- Twitter / @1k_fm
- Twitter / @kimuraya
- Twitter / @hyoshiok
- Twitter / @Ray_TomoKi
- Twitter / @mako_limone
- Twitter / @shmorimo
- Twitter / @cafe_de_tdog
- Twitter / @liktastar
- Twitter / @hyoshiok
- Twitter / @guniuni
- Twitter / @rin2_
- Twitter / @tahiro86J
- Twitter / @shaun418
- Twitter / @t_d_m_s_e
- Twitter / @snomura1950
2014-04-05
英語を社内公用語にしてはいけない３つの理由。読了
英語社内公用語化は、１）日本語・日本文化の軽視、２）社会的格差・不平等の助長と固定化、３）言語権の侵害、なので、著者は反対という立場をとっている。
あらかじめお断りしておくが、わたしは、この著者の立場を取らない。また、ここでのわたしの意見は所属会社のそれを表すものではなく、あくまで個人としてのものである。
まず、簡単に本書を紹介し、その後、自分の意見を述べたいと思う。
「英語を社内公用語にしてはいけない３つの理由」
本書の構成は、序文「楽天、ユニクロへの手紙」、第１章英語社内公用語化の実態、第２章英語公用語論の歴史、第３章英語を社内公用語にしてはいけない理由１、日本語の衰退を招く、第４章英語を社内公用語にしてはいけない理由２、格差を生み、拡大する、第５章英語を社内公用語にしてはいけない理由３、言語権を侵害する、第６章もしあなたの会社が英語を社内公用語したらどうするべきか？、第７章日本語優先主義のすすめ、終章経済至上主義から文化至上主義へ、となっている。
2011年7月に出版されたものなので、楽天やユニクロの英語社内公用語化が2010年ころ話題になったので、それをきっかけに出版されたため、若干記述が古い部分がある。
第１章で、英語社内公用語化の実態を取材している。当該企業へ電話取材を試みたりしているが、多くはウェブ情報などをソースに論じている。
『「英語にこだわること」が本当に会社をよくすることなのか、社員のためになるのか、ひいては日本のためになるのか。経営者は真剣に考えなければなりません』39ページ。
第２章で、英語公用語論の歴史を森有礼の「英語採用論」から紹介している。志賀直哉の「フランス語採用論」、2000年の「英語第二公用語論」などを紹介している。
公用語というのは政府が使用を約束する言語であり、国民が使用を強制される言語ではないという主張をしている。
第３章で、英語を社内公用語にしてはいけない理由として「日本語の衰退を招く」と主張する。
日本は英語偏重社会で、１）大学教育が実用英語に傾斜、２）英語教育の早期化、３）「英語力」が人生を左右する、４）文科省「英語が使える日本人」育成政策、となっている。
英語偏重は日本語の衰退をまねく理由として、１）深まる「英語信仰」、広がる「日本語軽視」、２）英語が「上位言語」、日本語が「下位言語」、３）英語への「乗り換え」が起きるをあげている。
100年後、日本人は日本語を話しているだろうか？（88ページ）
第４章で英語を社内公用語にしてはいけない理由２、格差を生み、拡大する、と主張する。
英語が格差を生み出す理由として、１）英語力が高収入、高地位につながる、２）「英語を使う人」と「英語を使わない人」の収入格差、３）「英語が出来る階層」と「英語が出来ない階層」への分離、４）「日本語の出来ない外国人」の増加、４）日本企業に就職できない日本人の増加、をあげている。
格差を拡大している現実として、１）「英語偏重社会」から「英語格差社会」へ、２）「二重言語社会」が日本を分断する、３）日本が「ガイジン天国」になる。
第５章で英語を社内公用語にしてはいけない理由３、言語権を侵害する、と主張する。
英語の強制は、「基本的人権」、「人格権」、「精神の自由権」、「自己決定権」の侵害である。
第６章、もしあなたの会社が英語を社内公用語したらどうするべきか？ということで、積極的順応、消極的順応、闘争的抵抗、平和的抵抗、分離の方法を紹介している。「英語公用語化」が日本のためになるか考えよと言う。
第７章、日本語優先主義のすすめで、１）日本人の英語信仰が日本語を亡ぼす、２）日本人は日本語人である、３）日本語は日本の基盤であり共有財産である、４）国際主義ではなく日本回帰を、５）世界の平和のために、と記す。最後に「英語優先」から「日本語優先」に軌道修正せよと主張する。
終章で、経済至上主義から文化至上主義へ、『今まで西洋文化を真似して日本人はここまでやってきましたが、もうそれは通用しません。今こそ日本人は日本の「伝統文化」に回帰し、そのすばらしさに気づき、そしてそれを世界に発信していかなければなりません。日本人が自分たちの「伝統文化」に誇りを持つこと。これが最も必要なことなのです』（200ページ）
感想
英語が経済圏での普遍語になっている以上、企業はそれを好むと好まざるをに関わらず利用せざるを得ない。もし、その前提を否定するとすると、日本は鎖国をしなくてはならず、それは現実ではないし、あり得ない。
問題は、その利用によって、どのような問題が発生し、その問題の影響をどのように最小化すべきかということだと思う。
しかしながら、本書は、英語化を否定することを前提に議論しているので、参考になる主張はほとんどない。
また、本書の構成は、要約するのが困難だった。それは、各章毎の構成が、本来ならば、その章の主張を補強する小見出しからなっていて、それを組み合わせれば、その章の主張が正確に再現されるべきなのであるが、小見出しを引用しても、その主張を補強する材料にならない、あるいは理解するのが困難な構成になっていた。
例えば、英語化が格差を拡大するという主張をしている。その主張の根拠は、英語が出来る人、出来ない人という層別に年収を比較している研究を引用している。（96ページ）
ある現象１と２に因果関係があると主張する場合、最低でもそれ以外の条件を同一にしないと、比較できない。英語が出来る人は高学歴の人が多くて、結果として年収に差があったのかというようなことはないのかなどなど。
英語化に反対するのも結構であるが、説得力のある主張を展開するためには、最低限、理科系の作文技術 (中公新書 (624))
面白い主張を学べるかと思って、英語を社内公用語にしてはいけない３つの理由
ひとつひとつ主張に自分の意見を記そうと思ったのだけど、要約を作っているうちにそのエネルギーもつきた感じである。かえすがえす残念だ。
おまけで、下記、ハーバード大教授も認める「楽天の英語公用化は大成功だ！」【特別対談】ツェーダル・ニーリー米ハーバード大学経営大学院教授に聞く、というリンクを貼っておく。
http://business.nikkeibp.co.jp/article/opinion/20140328/261944/?rt=nocnt
2014-04-04
金曜日はタモリ倶楽部
32年間続いた笑っていいともが3月末で終わってしまったが、タモリ倶楽部はまだ終わる気配もない。終わらないでほしい。
http://ja.wikipedia.org/wiki/%E3%82%BF%E3%83%A2%E3%83%AA%E5%80%B6%E6%A5%BD%E9%83%A8
金曜日の夜、酔っぱらいって帰って来て観るというのが一週間の締めみたいなものだ。酔っぱらっているから、途中で寝ちゃったり、そもそも番組が始まる前に寝落ちをすることも少なくない。土曜日の朝に、昨晩タモリ倶楽部を見過ごしたことなどを思い出し、微妙に悔しかったりする。
とはいうものの録画までして観ることはしない。金曜日の深夜にへべれけになりながら観るというのが正しいタモリ倶楽部の楽しみ方である。寝ちゃったらそれはそれでしょうがないのである。
ここだけの話なのだが、いつかタモリ倶楽部に出るのがわたしの夢である。本当は、笑っていいとものテレホンショッキングにも出たかったのであるが、番組が終わっちゃったので、かなわぬ夢になってしまった。
タモリ倶楽部に出るために、どうでもいいことに精通する必要があるのだけど、そのような専門性を持っていないのが痛い。
空耳アワーからデビューするというのが王道だけど、全然思いつかない。
道は遠いが、頑張らない。
2014-04-03
英語での勉強会
社内勉強会はほぼ英語でまわしている。社外の人に講演をお願いする場合が、最近の悩みは、日本において英語で講演することをカジュアルにできる人が少ないことである。多分どこかにいるのだろうとは思うのだけど、自分の知り合いで、ちょっと勉強会でお話ししてよと頼める人となるとググッと少なくなる。（先日はMickさん、ありがとーございました）
英語で発表するよーーという奇特な方はぜひご連絡ください。お願いします。
日記の日付を間違えてアップしてしまった。本文は http://d.hatena.ne.jp/hyoshiok/20140402/p1 を参照してください。ブックマークとかもあるので、エントリはそのまま保存する。 id:hyoshiok:20140402:p1
日記の書き直しなど。
4/2のネタを4/3の日付でアップしちゃったので、 id:hyoshiok:20140402:p1 でアップし直して4/3の日付で訂正する。
2014-04-02
英語での勉強会
社内勉強会はほぼ英語でまわしている。社外の人に講演をお願いする場合が、最近の悩みは、日本において英語で講演することをカジュアルにできる人が少ないことである。多分どこかにいるのだろうとは思うのだけど、自分の知り合いで、ちょっと勉強会でお話ししてよと頼める人となるとググッと少なくなる。（先日はMickさん、ありがとーございました）
英語で発表するよーーという奇特な方はぜひご連絡ください。お願いします。
そんなこんなで、1000 speakers conferenceに来ていた津田さんに英語で発表をお願いした。ネタは下記。（スライドは昔、XP祭りでやったやつ）。スライドは日本語になっているけど、もちろん英語のスライドを利用した。（公開はちょっと先になるそうです）
英語での発表は、大変は大変だけど、練習を繰り返すことでどーにかなる。一番大変なのは質疑応答で、これは場数を踏むしかない。
質疑応答の質問する側は自分の聞きたいことを聞けばいいので、意外と敷居は高くない。だけど、答える方は、１）質問を正しく理解する。２）英語で回答する。という二段階があって、これは難易度が高い。
勉強会の司会なんかもアドリブでちょっと気の利いたことなんかを言いたいのだけど、言えない。これも場数を踏むしかない。
今回のお話は、ソフトウェア開発におけるバッグログの管理をしていただいた。日本語で聞いてもいろいろ議論が出来るネタで、それを英語でやるわけなので、非常に大変だったと思う。発表を快く受けていただき、津田さん、ありがとうございました。
ということで、実践的な英語の発表の場を求めている人、緩募中です。
2014-04-01
新入社員のみなさん、入社おめでとう
思い起こせば30年前の自分だ。希望と不安で臨んだ入社式。合宿の集合研修。
当時はIT産業という言葉は一般的ではなかった。コンピュータ産業だった。そしてコンピュータ産業はハードウェアベンダーが支配していた。ソフトウェア産業が生まれるかうまれないかの時代だ。
自分は大学でソフトウェアを学んだので、ソフトウェアを作ることを仕事にしたいと考えていた。そして、そのころはソフトウェア専業ベンダーというのがまた生まれて間もない頃なので、就職先としては自分の中には候補になっていなかった。ソフトウェアを作りたいのならハードウェアベンダーに行く。そのような時代だった。
IBMがコンピュータ産業を支配していた。メインフレームと呼ばれる、汎用大型コンピュータを作るのがハードウェアベンダのビジネスモデルだった。そして、そのようなベンダーはIBM以外残っていない。すべて時代によって淘汰された。*1
わたしはDECという米国のコンピュータベンダーの日本法人に就職した。当時、マイクロソフトもオラクルも日本法人はなかったので、ソフトウェア開発をやりたければ、国産ベンダーか外資のコンピュータベンダーに就職するほかなかった。
ハードウェアの新機種の発売にあわせて、オペレーティングシステムやミドルウェアのバージョンがアップして行くことが多く、それが製品ロードマップとしてマーケティングされて行く。
ハードウェアの製品開発サイクルは数年単位なので、ビジネスのサイクルも長い。
80年代はPCの登場、Unixワークステーションの登場などがあり、従来のメインフレーム中心のコンピューティングスタイルが全く変わろうとしていた。そしてDECはその波に飲まれあっというまにビジネスのメインストリームから脱落し、1998年コンパックに買収され市場から撤退をした。
80年後半から90年代、マイクロソフトとインテルの時代であった。インテルがマイクロプロセッサのロードマップをNDA（秘密保持契約）ベースでハードウェアベンダーに公開し、それをもとにハードウェアベンダーはPCを製造する。インテルのロードマップにそうような形でマイクロソフトもWindowsのロードマップを作って、各種ベンダーにNDAで公開していた。
DECは奇妙なことにハードウェアベンダでもあり、PCベンダーでもあるような立ち位置にいた。
Windows NTの話は社内でも情報は共有されていたし、DEC Alphaというマイクロプロセッサへの移植作業も行われていた。
ベンダーは、誰かが作ったロードマップをベースに製品開発のスケジュールを引いていた。このロードマップを作る人のことをDECではアーキテクトと呼んでいた。
製品ベンダーは自社製品の戦略をロードマップというポンチ絵で表現し、まだ影も形もないものを顧客に売りつけるというビジネスモデルを取っていた。
インテルは創業者のムーアが60年代に提唱した、ムーアの法則によって、マイクロプロセッサの集積度についてきわめてシンプルだが強力なロードマップを手にしていた。二年後の新世代のCPUではクロックが倍になりますとか、集積度が倍になりますとかいうことを前提にビジネスをしていた。
インテルやマイクロソフトは自社のビジネスがプラットフォームビジネスだということを理解していたので、自社のプラットフォーム上で動くアプリケーションなどを作る企業を上手に囲い込もうとしていた。
NDAをベースに詳細な情報を事前に提供し、様々なアプリケーションを構築することを支援していた。
ロードマップはごく一部のプラットフォームベンダーが作って業界全体がその流れに乗るというのが典型的なビジネスモデルであった。
かつては、それがIBMであり、90年代は、マイクロソフトとインテルだった。
だれかが圧倒的な支配力を持って業界を引っ張るという構図がなくなった。
AmazonもAppleもGoogleもFacebookも大きな影響力を持つことは持つが、ロードマップを示して業界の行く末を定義するという力はない。
インターネットの時代のテクノロジーは製品ベンダーが提供するのではなく、オープンソースになってしまった。
オープンソースにはコミュニティーはあるが製品ロードマップを作る人はいない。そのようなものはない。
Linuxの作者のLinusはスピーチをするのが嫌いだと公言してはばからないが、かれが辟易としているのは、Linuxの将来像はとかLinuxのロードマップはどうなっているんですか、という類いの質問をされまくって、ほとほと疲れたというようなことを言っている。ロードマップはない。
よく、これからの技術トレンドはどうなるか、みたいなありがちな未来予測があるが、そのような陳腐な問いかけに納得してはいけない。そんなものはない。そんなものを求めてはいけない。
30年前、コンピュータ業界に身を投じた若き日の自分に言うことがあるとすれば、この業界は仕事にするに足る素晴らしい業界で、君の選択に間違いなかった。めちゃくちゃエキサイティングな30年間だった。そしてこれからの30年間（？）も同じようなエキサイティングな未来がまっていると思う。
ただし、誰かが書いたようなロードマップというのはない。それを作って行くのは自分たちだ。
未来はすでにここにある。ただ、みんなに等しく見えていないだけだ。Willam Gibsonの言葉を30年前の自分と今年入社した新人のみなさんに贈りたい。おめでとう。
2014-03-30
図書館に行こう
今日は雨が降っていたので本でも読んで過ごそう。そんな朝だった。ちょうど、貸出期限が切れた本があったし、雨脚も弱くなってきたので、図書館に返却に行った。
予約していた本もついでに借りてきた。
最近の図書館は、インターネットで検索もできるし、予約もできる。わざわざ図書館にいかなくてもネットで大抵のことができて便利だ。
カーリルで検索。http://calil.jp/ よく使う地域の図書館を登録しておけば、蔵書があるかないか一発でわかる。そして、インターネット経由で予約も出来る。
本を読むという行為はとても個人的な行為だ。誰かにいわれてやるものではない。好きだから本を読む。面白いと思ったから本を読む。話題になっているから本を読む。仕事に必要なので本を読む。人に勧められたから本を読む。密かに憧れているあの子が読んでいたから読んでみる。そして、本は金輪際一切読まないという人もいる。人それぞれだ。
本の正しい読み方というのもない。正解がないのは人生と一緒だ。一人一人の読み方がある。毎日一冊本を読む人もいれば、この一年まったく読んでいない人もいる。
本を読まなくても死にはしない。生きて行く上で特に困るということもない。
乱読、熟読、積ん読、会読、色読、体読、再読、句読、味読、回読、多読、拝読、朗読、査読、楽読、流読、濫読、略読、白読、範読、精読、素読、耽読、
2014-03-29
意外と会社は合理的、読了
意外と会社は合理的 組織にはびこる理不尽のメカニズム
組織に焦点をあてた本で、様々な組織を例に、そのメカニズムを解説している。登場する組織には、営利企業もあれば、非営利組織もあれば、宗教団体、警察、軍隊、テロリスト、正義のヒーローなどなど。あ、正義のヒーローは組織じゃないけど、それが戦う悪者は統率のとれた組織だ。
経営学の研究成果をもとに、これでもかといろいろな事例を出してくる。
プリンシパルとエージェント問題というのは、どうやって従業員に期待した仕事をやらせるかという問題である。どのようにインセンティブを設計してそれを運用して行くか。経営者は、従業一人一人が期待通り働いているかいちいち監視することはできない。さぼらないように監視したり、ずるをしないように監視することを完璧に行うにはコストがかかりすぎる。そこで中間管理職をもうけたり、様々なルールをもうけたりする。
これは営利企業だけではなく、宗教団体も同様な問題を持っている。信者を増やすにはどのような方法があるのか。
あるいは警察はどうか。軍隊はどうなのか。テロリストと戦うための組織はどうあるべきなのか。
軍隊は絶対服従のルールがある一方で、テロリストと戦うためには、イノベーションを必要としている。そのバランスはどこにあるのか。
正解はないのだけど、そのバランスについて考えるきっかけになる一冊だった。
2014-03-28
カーネル読書会（第109回）をやった
久しぶりにカーネル読書会を開催した。あまりに久しぶりすぎて段取りをすっかり忘れてしまいばたばたしてしまった。どたばた。
http://kernel.doorkeeper.jp/events/9547
19:30開始まで、19時頃から集まってきた人たちでだらだら自己紹介などをしながら時間をつぶす。三浦さんが飛び入りでなにか発表してくれたのだけど受付していたので、ちゃんときいていなくてごめんなさい。
近所のイオンのネットスーパーでビールと乾きものを発注したのだがなかなか到着せず残念な思いにかられつつ、19:30定刻通り開始した。
開催の挨拶をしているうちに、配達の人が来たので、挨拶を伊藤さんに丸投げして、ビールを受け取り、飲みながらお話を聞く。
ビールは4ケース。発泡酒じゃないよ。プレモルだよ（ドヤ顔
乾きものなどつまみも少々。
小笠原さんのOpen Printingのお話。英語での資料というのが素晴らしい。お話そのものは日本語。徐々にカーネル読書会でも英語のコンテンツを増やしていきたい。
小山さんの日本でのLinux黎明期のお話。興味深い。https://speakerdeck.com/koyama0612/xi-falselinuxfalsehua-our-memories-of-linux
ピザも到着して、大変よろしいかんじだった。
わたしの野望としては、今年10回開催する。毎月一回のペースで年末まで。
運営など
今回の参加者登録その他はdoorkeeperを使った。オンラインでのチェックイン機能などがあるのだけど、登録者リストをプリントしてそこにボールペンで印をつけるというアナログな受付方式をとった。参加者はわりとばらばらくるので、特に並ぶということもなく、スムーズに受付ができた。
受付は八巻さんがやってくれた。名前をチェックして1000円を受け取る。みなさん、おつりが出ないように1000円札を持ってきてくれてうれしい。
当日は63名登録だったのだけど、歩留まりとか久しぶりすぎてわからなかったので、ざっくり50名程度で考えて準備した。ビールとお酒は多目、ピザは控えめ。乾きもの少々。ふたをあけてみれば58名の参加だった。驚異的な参加率。若干名の当日参加の人もいた。
飲み物、乾きものはネットスーパー。ピザは、ナポリの窯、南品川店で発注。イオンのネットスーパーの配達時間がちょっと遅かったので、事前に確認すべきだったと反省。
会場は伊藤さんのご紹介で今回初めてビットアイルをお借りした。素晴らしい場所だった。目の前にはコンビニがあるので、つまみが足りなくなったら、買い出しにいける。実際ビール１箱、ワイン４本を追加で買いに行った。
会場係はビットアイルの杉野さん。素敵なおもてなしありがとうございます。毎回毎回お世話になるのも気が引ける感じがするのだけど、社内でお手伝いいただく人を緩やかに増やさないと負荷が集中してしまう。どーしたらいいんだろう。
次回もあるよ。
5/2に同じ形式で開催する。メインのお題は未定である。誰かお話してくれないかな。
を読んだ。
2014-03-26
EGM Forumの月例会に行った
今回の場所は、はじめての丸の内、富士ビルにある「3x3 Labo（さんさんらぼ）」。いい場所っすね。
http://www.ecozzeria.jp/fujibldg33/
今回のお題は「組織改革」。神垣さん、佐藤さん、杉浦さん、わたしが発表。
神垣さんは、この３年会社でやってきたことをお話ししてくれた。ワールドカフェに影響をうけ、会議の中で付箋をつかったり、模造紙を使ったりしながら、自分の部門の会議を変えた。それをやった経験についてお話をしてくれた。
付箋を使うと、みんななにがしかの意見を書く。通常の会議では決して発言しないような人も、付箋には必ずなにがしかを書く。今まで吸い上げられなかった意見、気持ち、空気が可視化される。人々が話をするようになる。
会議が単なる情報を流すだけの場になっていたりするのを、この方式にすると活発な議論が生まれる。そして活発な議論のなかから、人が変わり、新しい行動が出てくる。
アジャイル開発技法のなかにプランニングポーカーというのがある。トランプに数字が２、３、５、８、１３とか書かれていて、開発工数をグループで見積もるときに使う。この機能を開発するのにどのくらいかかるかというのをグループで考え、それぞれがいっせーのせで、自分がかかると思う工数の数字に近いものを見せ合う。あるひとは２をだし、あるひとは１３を出す。そして、それぞれのひとが、なぜその数字を選んだかを説明する。そうすると、２を出した人の考え、１３を出した人の考えが顕在化して、えーー、そーゆー考えもあるのか、と自分が見えていなかった見え方が見えるようになる。強制的に会話を促進し、当たり前だと思っていることを言語化させる効果がある。
スクラムのデーリーハドルもそれだ。毎朝毎朝、チームのメンバーで、昨日やったこと、今日やること、いま困っていること（問題点）などを全員で話す。強制的に話すということが重要である。メールで共有すればいいじゃんということではなく、実際話すことが重要だ。ソフトウェア開発プロジェクトのメンバーなんかはほっておくと誰とも一言も話さないで一日が終わることがあったりする。問題点を問題点と認識しないで放置される可能性がある。というかしょっちゅうである。それを毎日10分とかの会話で発見したり、自分が思ってもいない同僚の問題などが顕在化する。
付箋を利用した会議もそれににている。
わたしは、ビブリオバトルを紹介しつつ、Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
パワポを用意しないで、本を持って、この本はね、アイデアを組織に広めるためのいろいろなパターンを紹介しています、例えば、エバンジェリスト、これは神垣さんのことですね、みたいな感じでお話した。
早速、前田さんが購入していたので、ビブリオバトル的には読みたい本を紹介できたので、よしよしである。
次回の定例会はビブリオバトルをやろうということになったので、二重の意味で組織を変えた事例になった。
今回、米国ピッツバーグからFacetimeで智恵さん参加した。時差13時間（？）早朝6時ころからの参加だ。意外と音質、画質もよくて、Facetime飲み会もできそうだということを発見した。何事もやってみることが大切だね。
帰りに軽くビルの地階で飲んだのだけど、どうもそこで傘をなくしてしまった。とほほ。
2014-03-25
GitHub勉強に行ってきたにゃん
ともちゃんがGitHubを勉強したいにゃん、ということなので、勉強会に行ってきた。みんな猫耳つけて発表するというわけのわからない勉強会であった。
のれんがかかっていた。
これらはすべて手作り
沢田さんの説明
LTもあった
わたしのお話は、GitがLinusの自分の問題を解決することから始まったというような歴史の話からあれやこれや。Linuxのソースコードを管理するためには分散型、高速、高信頼性などが必要。
Linusは自分のPCのバックアップをとっていなくてもコミットしたものをインターネットにおいておけば誰かがコピーして、そのコピーは改竄することが非常に難しいので安全に複数のバックアップをもつことが出来る、というようなことを言っている。
Gitのレポジトリはどれが親とか子とかなくて、forkしたものをどんどん変更してcommitすることができる。これが分散型の特徴。特に、元のレポジトリにアクセス権を持つ必要がない。昔のOSSの開発スタイルだと、ごく少数のすごい人たちだけがコミット権を持っていて、その人たちがボトルネックになっていた。それが分散型だと、だれもが自分がコピーしたレポジトリにどんどんコミットができるので、バグを入れちゃって壊すこともあるし、すごい機能が出来ちゃうこともある。すごいものが出来たら、それをpull requestして本家本元に取り込んで貰うように頼む。このようなワークフローのおかげで、コミッターと呼ばれる人たちの文化的な役割がかなりかわってきた。
コミットの粒度は、論理的な一塊、例えば、バグ修正とか機能追加とか。そして、コミットのコメントは命令形で書く。Fix bug-1234とか。こーゆーことはドキュメントに書いてあるので、読む。
GitHub flowというのがあって、標準的なワークフローになっている。ブランチを作って、そこで何か作業をしてコミットして、プルリクエストをして、レビューして、マージしてデプロイする。シンプルなワークフローである。
GitHubにはパンチカードという機能があって、作業が可視化できる。
https://github.com/RyuPiT/SharePla/graphs/punch-card
OSSを自由にフォークして開発し、プルリクエストを行うというソーシャルコーディングがGitHubを中心に広がってきた。元のレポジトリに対してコミット権を必要としていないのが集中型のレポジトリをもとにした運用、ワークフローとの決定的な違いである。
OSSのコラボレーションを加速するためにも、ソフトウェアのライセンスは明示しよう。デフォルトでは、MIT/Apache/GPLから選ぶといい。
ハッカー倫理は、情報の共有、公開、分散、コンピュータに対する自由なアクセス、世界をよくすることなどからなる。インターネットはそのような価値観で発展してきた。FacebookのHackerwayなどは有名だ。
Be Hacker ハッカーになろう。
- Twitter / @yuya_q
- Twitter / @hyoshiok
- Twitter / @mana_cat
- Twitter / @grethlen
- Twitter / @SaintUCK
- Twitter / @kim_identity
- Twitter / @shokolateday
- Twitter / @hyoshiok
- Twitter / @hyoshiok
- Twitter / @mhiramat
- Twitter / @mhiramat
- Twitter / @IDaisukewith
- Twitter / @tacky0612
- Twitter / @hyoshiok
- Twitter / @yutakama
- Twitter / @nobiinu_and
- Twitter / @starocker
- Twitter / @am192835
- Twitter / @hyoshiok
- Twitter / @hyoshiok
2014-03-24
社会人学生のための大学
産業技術大学院大学で昨年開設したenPiTという教育プログラムの紹介記事が出た。わたしも永瀬さんと一緒に写真で登場。
http://wired.jp/2014/03/20/enpit/
日本においては、社会人が大学を卒業した後、再び学校に戻って教育を受けるということはあまり一般的ではない。社会人学生の国際比較によれば、日本における社会人学生はOECD諸国に比べ著しく低い。（社会人大学生の国際比較 id:hyoshiok:20140317:p1）
産業技術大学院大学がユニークなところはその学生の多くが社会人学生だということである。
日本において、社会人学生が増えないのは、受け入れ側の大学の問題もあれば、社会人学生を支援するべき社会の制度的な問題もある。
後者でいうと、日本の多くの企業は、最終学歴を重視はするが、（どこどこ大学出身とか）、最新学習履歴（いま何を学んでいて、どのようなスキルがあるのかないのか）については、それほど重視していないように見受けられる。
自分の時間的コストを払って大学に通ったところで、会社でそのことがまったく評価されないとしたら、多くの人は、そのような時間的な投資を躊躇することだろう。
医師や弁護士になるために、医学部を卒業しないといけないとか、法科大学を卒業しないといけないというようなことがなければ、ちょっと大学に戻って、勉強し直すかということを手軽に行うような制度的な環境もない。
一方で、IT系の勉強会の隆盛に象徴されるように、何かを学びたいという人は一定以上いる。別にお金のためとか、誰かに評価されるために行うというよりも、自らの知的好奇心、あるいは、技術者としての危機感から、自発的に学ぶ人たちである。
そのような人たちは、自分の時間を使って、夕方や休日に開催されている勉強会のようなイベントを発見し、参加する。
彼らのニーズと大学が提供している教育（サービス）は必ずしもマッチしていない。
多くの大学は、社会人を受け入れる。科目等履修生という制度で講義を受講することはできる。モグリで受講しなくても、正々堂々と履修できる制度である。
しかしながら、社会人のニーズ大きい、夜間や土曜日の時間帯に授業を提供している大学は少ない。
産業技術大学院大学は、平日の授業は18時30分開始だし、土曜日も開講している。仕事帰りでも授業がとれる。
社会人学生を増やすことは活力ある社会を作るためには必要だと思う。その意味で、最低限でも、夜間や休日にサービスを提供する大学が増えてくるとうれしい。
社会人にとって魅力的なコンテンツ（授業）を提供しているか、今回のenPiTの講座はそのような問題意識のなかで行った。ウェブプログラマになりたい人向けにチューニングした授業になっている。
来年度の募集ももうすぐ開始される。多くの参加をお待ちしている。
関連日記
社会人大学生の国際比較 id:hyoshiok:20140317:p1
enPiT第2回ビジネスアプリケーション分野ワークショップに参加した id:hyoshiok:20140228:p1
大学の社会的役割など id:hyoshiok:20140217:p1
Demo or Die. id:hyoshiok:20140130:p1
2014-03-23
環状二号線の工事現場に行ってきた。
新橋から虎ノ門方面にいく環状２号線の工事現場の見学会があって、それに参加した。
開通前の道路をてくてく歩くというだけといえばだけのイベントなのだけど、開通したら絶対歩けないところなので、見学に行ってきた。インターネットから申し込んで抽選で参加資格をゲットしていったのだけど、知り合いは抽選で当選しなかったみたいなのでラッキーな感じがした。
通称マッカーサー通りと言われているらしいのだけど、最初の構想が昭和21年ということなので、戦後、づっと新橋・汐留から虎ノ門方面への道路が企画されていて、平成になって、やっと具体化したということらしい。
ミニチュアの模型があった。工事区域の立体模型。そのしたを環状２号線が走っている。
虎ノ門ヒルズのしたから道路が出てくる。大きな建物の下を道路が走っているというのがすごい。東京の工事現場は熱い。
約1キロちょっとの見学会だったけど、面白かった。途中江戸時代の古地図とかが展示されていたり、文化遺産が発掘されたりというよなパネル展示もあり、勉強になった。
自家発電装置もあり災害対策もばっちりらしい。チラシというか工事の概要のパンフレットを貰ってきたので、じっくり読んでみたい。耳年増になるのだーー（笑い
2014-03-22
GitHub実践入門を読んでGitとかGitHubについて考えた
みんなでGitHubを勉強するにゃんっ！に参加するのでいろいろGitとかGitHubについて再勉強ちう。
そしたらGitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
目次をみるとなかなかよさげだったので、期待しながら読んだ。素晴らしい。
http://gihyo.jp/magazine/wdpress/plus/978-4-7741-6366-6/0001
第2章Gitの導入
第3章GitHubを利用するための準備
第6章はじめてのPull Request
第7章Pull Requestが送られてきたら
Appendix A、GitHubをサポートするGUIクライアント
本書の特徴はGitの基本的なコマンドなどの説明などは可能な限り省略して、GitHubを利用したワークフローに焦点をあてているところである。
Gitが難しいという人は多い。わたしはそんなことはないと考えているのだけど、なんで難しいと感じるのかな？id:hyoshiok:20140201:p1 id:hyoshiok:20140205:p1
Gitの利用の基本はブランチを作ってそこで何かの作業をしてコミットする。そしてリモートのレポジトリへプッシュなりプルリクエストをする。
集中型のバージョンコントロールシステム（VCS）との通常での作業の違いは、ブランチを手軽に作ってそのブランチ上で作業を行うというところかと思う。最初のVCSがgitから入った人は、ブランチを作ってそこで作業をするというのが当たり前だと感じるが古来の集中型に慣れている人はそこにとまどうのかもしれない。
これからバージョン管理のスキルを身に付ける場合、一見シンプルである集中型を身に付けてから分散型を学ぶべきと考える人がいます。ですが、今後集中型を使うケースが少ないため、わざわざ遠回りをする必要はないと著者は考えています。21ページ
コードを変更するのは、１）新機能の実装、２）既存機能の変更拡張、３）バグ修正などになるが、ブランチを切るという作業は、自分の中で意識して、上記のどれかをやるということを明示的に宣言することに他ならない。単にワーキングディレクトリでなんとなくごにょごにょやって、一区切りがついたからコミットでもするかということではない。
集中型の場合、ブランチを手軽に作って、ずんずんそこにコミットして開発の歴史を作っていくということはマージのコストが高いので推奨はされない。というか、お手軽にそのようなことは出来ない。
Gitの場合、ブランチを作るときに上記のどの作業をやるのかということをブランチ名で分かるようにして行う。コミットログも明示的にそれを宣言する。例えばFix bug-1234とかAdd feature-Xとか。
本書はgitおよびGitHubの基本的な操作について５章までで解説し、５章でGitHubの主な機能について詳細に解説している。
そして、６章、７章でPull Requestの送り方、受け取り方を説明している。この６章、７章は本書の白眉だと思う。下記のGitHubのレポジトリを用意して、読者が実際にPull requestを試せるようにしている。
https://github.com/github-book/first-pr
わたしも早速、本書を読んで発見した誤植をpull requestしてみた。
https://github.com/github-book/first-pr/pull/2
なにこれすごい。紙の本とのコラボレーション企画。GitHubを利用してGitHubの機能を学ぶ。従来の本でも掲示板などを作って、そこで著者とやりとりできるというのはなくもなかったが、本書ではGitHubを利用して、その機能の実際をためせるようになっている。イノベーションだと思う。
９章のGitHubを利用したワークフローの解説もわかりやすい。非常に具体的だ。gitの使い方は知っているのだけど、どうも仕事でうまく使いこなせていないと感じている人は、この９章をじっくり読むことをおすすめする。GitHub FlowとGit Flowは名前が似ているが別のワークフローである。前者の方がシンプルなワークフローだ。
GitやGitHubを利用する人にはおすすめの一冊になっている。
とりあえづ、本書を読んだ後に、マニュアルや実用Git
LinusがGitについてなんか言っている
彼はCVSやその改良版のSubversionを頭おかしいんじゃないのというような感じで批判していて、まあ、もうちょっと穏便な言い方もあるんじゃないかと思うのだけど、基本的には、大規模で開発する場合は、分散型しかあり得ないと断言している。
分散型であれば、常にインターネットに接続していなくてもいいし、仮に接続していたとしても超高速のネットワークを必要としないで、どんどん各自が独立して作業ができ、しかも信頼性は高いし、高速である。
何らかの作業をするということはブランチを作ることにほかならなくて、何らかの作業はブランチの上で行われる。それは原理的には分散開発でしかあり得なくて、大規模な開発の場合、分散型のツールに必然的にならざるを得ない。
対等なコピーがインターネット上のどこかに存在するので、信頼性も高い。誰かが悪意を持ってコードを改ざんしようにもそれをすることは難しい（事実上不可能）。従来のファイルをもととしたバージョン管理システムだと、ソースコードが破壊されていても自動的に検出されないが、gitの場合、ハッシュ値によって保証する。
そのほか、あれやこれや2007年ころの映像なので、gitを利用してLinuxのソースコードを管理し始めて2年くらいの経験を語っているので、実に興味深い。あわせて見てみるといいと思う。
2014-03-21
ビジネスブレークスルー大学卒業式
ビジネスブレークスルー大学の第一期生の卒業式が本日あった。学生の皆さん、おめでとうございます。
ビジネスブレークスルー大学というのは、インターネットを利用した通信制の大学で2010年度に開講し、本年が最初の卒業の年にあたる。
わたしも教員として「オープンソース概論」という講座を持っている。
通信制の大学ということで、学生さんの多くは社会人である。昼間は仕事をしながら夜間に授業を聴講するというひとが多い。仕事と勉強の両立を４年間してきたわけだ。
日本において、社会人の大学生というのは諸外国に比べても非常に少ない。一般的な大学においては社会人学生を受け入れるという仕組みはほとんど整備されていない。例えば、夜間に授業をするとか、授業をオンラインで受講できるとかいうようなことをしている大学は例外的である。社会もそのような人を支援するという仕組みもすくない。例えば、大学に行くことを奨励するというような制度を持っている会社はほとんどない。
ビジネスブレークスルー大学は、昼間に仕事を持っていても、授業をインターネット経由で受講できるので通常の大学に比べれば遥かに講義を受講しやすいがそれでも毎日何時間か勉強を４年間続けるというのはすごいと思う。
そのような人たちが本日卒業式を迎えた。４年で修了するというのは本当にすごいことだと思う。おめでとうございます。これからのご活躍を期待します。
