2014-03-06
はてな日記を10年間書き続けた
最初のはてな日記を書いたのが2004/3/6なのでかれこれ10年書き続けたことになる。なんとまあ、よく続いたもんだ。http://d.hatena.ne.jp/hyoshiok/20040306
はじまり昔シリコンバレー日記というのを書いていた。 http://web.archive.org/web/19990202174122/www.best.com/~yoshioka/diary.html
日記を書いたのが919日で、昨年の12月14日から82日間連続して書いている。はてなエンジニアブロガー祭りに参加して以来毎日書いていることになる。
ページビューは298万。年間30万弱。
ブックマーク総数は15242個。歴代ブックマーク数ランキングは下記。
http://b.hatena.ne.jp/entrylist?url=http://d.hatena.ne.jp/hyoshiok/&sort=count
- 仕事で文書を書く必要がある人は理科系の作文技術を読むべきだ http://d.hatena.ne.jp/hyoshiok/20090601/p1 457
- 世界でもっとも強力な９つのアルゴリズム、読了。 http://d.hatena.ne.jp/hyoshiok/20140209/p1 362
- IT業界で生きる技術者に勧める100冊みたいなもの http://d.hatena.ne.jp/hyoshiok/20130506/p1 335
- 昔DECという会社があった。エンジニアとして必要な事はDECで学んだ。 http://d.hatena.ne.jp/hyoshiok/20110212/p1 315
- 許可を求めるな謝罪せよ。(Don’t ask for permission, beg for forgiveness ) http://d.hatena.ne.jp/hyoshiok/20110205/p1 304
トップ3は本の紹介だ。本の紹介はあたるとあたる感じなのか。はてな記法を今年からかえたので、あらたにブックマークすると新しい形式になる。日付＃p１というのが日付／p１になっている。
ということで、累積ページビューをリセットして、日記の新世紀を迎えたいと思う。
ご愛読ありがとうございます。これからも時々遊びに来てください。
2014-03-05
自作サーバーカンファレンスの同窓会に参加した
若い人は知らないのだけど、昔自作サーバーカンファレンスというのをやった。自作？サーバー？意味わからない。そもそもサーバーって何よ。というのが昨今の若い人の反応だと思う。
そのような時代背景のもと自作サーバーカンファレンスの同窓会に参加した。http://atnd.org/events/47968
クラウドの時代。自前でサーバーを準備するなんて意味わからない。そーゆーことだ。
RubyやPythonでコードを書く時代にアセンブリ言語でしこしこコードを書くという意味が分からない。時間の無駄。という感覚と似ている。
経済的な観点から言うとサーバーを自作するということに意義を見いだすのは難しい。というかない。
ベンダーのサーバーの価格が自作するよりも遥かに高いということであれば、それを自作する意義もあるが、昨今そのようなこともない。
そのようなコスト構造のときに自作サーバーを持つということにどのような意義があるのか。
もちろん、ない。まったくない。まったくないという事実を参加者がほぼ全員共有しているのだけど、それを前提に100人近くの人がいそいそ集まっているのはなんなんだろうか。
面白かった。企画、取りまとめてくれた、はてなの田中さん、そして会場提供フリークアウトのひさもりさんありがとうございました。
おまけ：2009年の自作サーバーカンファレンスの記事を下記に発見した。
http://el.jibun.atmarkit.co.jp/rakuten/2009/12/post-aae3.html
当時の感覚を味わってほしい。
2014-03-03
第2弾「グローバル人材の今を考える」 英語を使って働く・英語を学ぶ
本日開催された、第2弾「グローバル人材の今を考える」 英語を使って働く・英語を学ぶ、というイベントに参加した。
http://atnd.org/event/aikyari03/0
前半は斉藤淳氏による中高生向け英語塾について。斉藤氏の半生が非常に面白かった。日本の英語学習法がだめだめだということ。
後半は谷口恵子氏による「社会人の英語学習継続のコツと本当に効果の出る英語学習法」。英語の学習を続けられない人・効果を出せない人の特徴として、「英語を苦しい勉強だと思っている」、「英語を学習しているつもり」、「英語学習法だけを学び続けている」、「試験対策だけをしている」、「音を聞かない、声を出さない」、「英語で人とコミュニケーションしない」というのがあるそうだ。振返ってみると、英語の勉強をしているつもりはあんまりないし、英語の参考書も持っていないので、自分はあんまり当てはまっていない感じがした。
英語の教材はTedとかいろいろあるので仕事に関係しそうなものしなさそうなもの、あれやこれや事欠かない。
English Centralというのを教えてもらった。英語の教材だ。
http://www.englishcentral.com/videos#!/index/all/all/trending/0
やっぱ、英語を学ぶというより、MOOCのような英語で学ぶという方がわたしのニーズにはあっているような気がした。（http://d.hatena.ne.jp/hyoshiok/20140223/p1）
主催の赤井さん、会場提供の日本オラクルのみなさま、講師の斉藤さん、谷口さん、参加者のみなさま、ありがとうございました。楽しかったです。
追記。英語でショートスピーチ。1000 Speakers Conference in English
英語で話す機会が少ない人みなさん。ないならその機会を作っちゃいましょう。５分程度の英語の発表をするカンファレンスをやります。奮ってご参加ください。怖くない怖くない。やるかやらないかは自分で決める。
2014-03-02
書くことについて スティーヴン・キング読了
書くことについて (小学館文庫)
本書は2010年に米国で出版されたものを翻訳したものだ。これは、2001年に翻訳された「小説作法」の10周年記念版ということらしい。そーいえば、昔、そのような本を読んだことを、本書を読みながら思い出した。
キングの本は、「キャリー」も「ミザリー」も読んだことがない。さすがに名前とあらすじくらいは知っている程度の読者である。先日読んだ、11/22/63が初スティーヴン・キングである。http://d.hatena.ne.jp/hyoshiok/20140127/p1
作家になりたいなら、絶対しなければならないことが二つある。たくさん読み、たくさん書くことだ。 私の知るかぎり、そのかわりになるものはないし、近道もない。
本書は、１）履歴書、２）道具箱、３）書くことについて、４）後書き、生きることについて、５）補遺その１閉じたドア、開いたドア、補遺その２ブックリスト、補遺その３（2001年から2009年にかけて読んだブックリスト）という構成になっている。
受動態は使わない。副詞も危険だ（道具箱）ということや、どのようにして物語を作っていくのか、その魔法（書くことについて）が書かれている。
スティーヴン・キングという作家がどのようにして作品を作っていくかというそのプロセスを記している。非常に興味深い一冊だ。
2014-03-01
OSC 2014 Tokyo/Sprintに行ってきた。
https://www.ospn.jp/osc2014-spring/
法林さんの司会
15時15分の開始前から法林さんとあれやこれや雑談しつつお話をさせていただいた。かなり雑駁なお話で恐縮である。
質疑応答で、企業に属する人がOSSに貢献するときのポイントのようなことを聞かれた。弊社では、その規定があるので、その規定に則って行う。すなわち、知財や法務の確認を前提に、ビジネス上のメリット・デメリットを判断した上でオープンするかどうかを決定する。単純なバグフィックスのような場合は、ビジネス上のデメリットはほとんどないので、公開する。というような判断をする。
OSCは今回約100回目の開催ということで、記念の回に参加できてよかった。講演をしたので、ブースを回る事がほとんどできなかったのが若干残念であった。
2014-03-01 (土) 15時15分 jus研究会東京大会「オープンソースの利用とハッカー文化」 講師：よしおかひろたか 司会：法林 浩之（日本UNIXユーザ会） 担当：日本UNIXユーザ会 レベル：入門編 対象者：企業におけるオープンソース文化の普及に関心のある方。 前提知識：特になし インターネット企業におけるOSSの利用について、企業文化の側面から論じる。 インターネット技術は、ハッカーと呼ばれる優れた技術者によって発展して来た。 OSSは、ハッカーによって開発され普及した。そのハッカーが持つ共通の価値観と 企業文化をどのように融合するかについて、これまでの試みを紹介する。 【カテゴリ】教育
https://www.ospn.jp/osc2014-spring/modules/eguide/event.php?eid=29
OSC girlsとパチリ。
2014-02-28
enPiT第2回ビジネスアプリケーション分野ワークショップに参加した
産業技術大学院大学で開催された第2回ビジネスアプリケーション分野ワークショップに参加した。昨年、enPiTという産学協同の教育プロジェクトで、スクラムによるアジャイル開発手法のコースを永瀬美穂さんと担当した。その成果報告会。われわれのPBL (Project Based Learning) を受講した4チームのうち、琉球大学学生のチーム、Ryupitが参加してポスター発表をした。
http://www.cs.tsukuba.ac.jp/enPiT/html/workshop201302.html
招待講演は上野 新滋 さん(CeFIL 理事，(株)FUJITSUユニバーシティ 産学官連携グループ長 エグゼクティブ・プランナー）で、富士通の取り組み、JMOOCの紹介など。
連携三大学（筑波大学、産業技術大学院大学、公立はこだて未来大学）からの活動報告、PBL参加学生チームからの発表（3分）とポスター発表。
パネルディスカッション
各大学ごとに工夫した点などを共有しつつ、今後どうするかなどを議論した。
われわれのチームは、15コマの事前学習で、スクラムの基礎を講義とワークショップ、利用するツール（git/github/Rails/Travisなど）の講義、ミニPBLでチーム編成（チーム名の決定）、何を作るかの議論、そして10週にわたるPBLという形で行った。
学生は、週3コマのチーム作業、3コマの自主的な作業でウェブサービスを作る。毎週土曜日の午前中に全体ミーティングで、各チームごとに、１）今週やったこと、２）デモ、３）来週やること、４）困っている事、他のチームからのコメントなどを貰う。
1週目の発表で、プロダクトバックログはなんですかというような質問が永瀬さんからでる。プロダクトバックログってなんだろうか？？メンバーは、授業で習った事なんだけど、まったくそれの重要性を意識していなかったことを理解する。
奇麗なパワポを作る事に一生懸命になって、デモを動かすことがおろそかになる。デモが出来なければ何の価値もないという価値観を学ぶ。パワポを作る時間があったら製品を作ろう。そーゆー事である。Demo or Die
2週目の発表。それではそのサービスのURLを教えてください。localhostでは動くんですが…。アクセスできないウェブサービスってなんの冗談なんだ。デプロイする重要性を学ぶ。
何週目か、デモをするがなぜか、うまく行かない、先週まで動いていたんですが、ということでリグレッションテストやCIの重要性を学ぶ。
毎週毎週デモをするので、少しずつデモがうまくなる。プレゼンがうまくなる。プレゼンがつまらないと誰も聞いてくれない。他のチームの人は寝てるかもしれない。いいね、それ使ってみたいよ、というコメントを貰うために、いろいろ工夫をする。つまらないと全くフィードバックが貰えなくて、サービスがよくならない。そしてプレゼンやプロモーションの重要性を学ぶ。
毎週毎週デモをし、それを10回繰り返す。最終成果報告会は特別に何かを準備するというより、たまたま最後の一回にすぎない。
今回発表した琉球大学のチームもその中の1チームだ。10週間で1000回以上コミットをしてサービスを作った。発表するにあたり、gitのログから、週毎のスプリントの振返りをしていた。最初のスプリントで出来た画面、その時貰ったコメント、実装したものなどなどを週毎にまとめていた。そーいえば、最初はこんな画面だったよね、最後のものとは全然ちがうよなーということを思い出す。
PBLによって、知っているけど出来ない事を理解する。出来る事と出来ない事を理解する。自分では出来ると思っていた事が全然出来ないという事を理解する。毎週毎週デモをしながら学んで行く。この製品の価値はなんですかという質問にあなたが答えられないとしたら一体誰が答えられるのか？その価値を15秒で説明できないとしたら、誰がそれを説明するのか、というようなことを学んで行く。
彼らが、いま、全く別のウェブサービスを作るとすると、10週間のPBLの経験によって、もっと上手に、もっと凄いものを作ると思う。それが10週間のPBLの一番重要な成果だ。作ったものではなく、経験によって獲得した暗黙知、ソフトウェアを作るという事の面白さ難しさ、それが一番重要な成果だと思う。
今回発表した中で、琉球大学のRyupitチームは優秀プレゼンテーション賞を受賞した。おめでとう。そして彼らの受賞こそがわれわれが最もほこる成果なのかもしれない。ありがとう。
2014-02-27
「東京ふしぎ探検隊」読んだ。
昨日 id:hyoshiok:20140226:p1 で紹介された東京ふしぎ探検隊 (日経プレミアシリーズ)
- 国道1号が。なぜ「第二京浜」なのか
- 神田に1丁目がない町があった
- 銀座に住所がない場所が……原因は都心の「領土紛争」
- 二重じゃないのに「二重橋」の怪
第2章ニホンとニッポンの真相
第3章鉄道路線、幻の計画を追う
2014-02-26
東京ふしぎ探検隊
日経電子版の人気記事、東京ふしぎ探検隊のツアーがあったので、申し込んだら抽選であたったので、いそいそ参加した。
万世橋からはじまって、都内のふしぎポイントをあれやこれや探検するという実に奇々怪々なツアーである。担当の河尻記者の絶妙な解説でずんずん探検をする素晴らしい企画である。さらに日経新聞の印刷工場まで見学できて満足度は超高い。
日本経済新聞社の本社（大手町）で集合して、ツアーに先だって事前講義。諸注意とか。
貸し切りバスで移動
まんせいばし駅
旧まんせいばし駅のあたりは昔交通博物館があって、いまはエキュートになっていて、お店が入っている。昔の駅があったところは中央線の線路沿いになっていて見学ができる。
新聞を印刷する工程を工場で見学。巻き紙（約1トン）が高速に回転して輪転機に吸い込まれ、1時間に18万部印刷できる。その印刷機が4セットあるらしい。工場の中は安全のため撮影禁止。通常は人はほとんどいなくて、自動的に印刷されるらしい。
どーやって、不思議ポイントを探すかと質問したところ、ともかく歩く、ということらしい。あと、読者から教えてもらう。疑問に思ったらともかく調べる。やってみるのが記者の基本だというようなことを仰っていた。やってみるというのが基本というのはしびれた。
銀座は８丁目までしかないのだけど、銀座ナインというビルは９丁目になりたくて、そのようなビル名をつけているとか、その住所は東京都中央区銀座8-10先なんだけど、銀座８丁目の先。先ってなんだよ先。中央区なのか、港区なのかはっきりしろ。というのが今回のポイントですw
2014-02-25
EGMフォーラムの月例会に行った。
EGM (Employee Generated Media)、社員が作るメディア、社内SNSみたいなものか、それを運営する人たちが集まって、社内SNSの運営のあれやこれやを議論することを目的に始まった勉強会のようなものである。最近ではEGMからちょっと離れて、コミュニティの運営とか組織改革とか、もう少し広いテーマで議論を重ねている。
そのEGMフォーラムの月例会があったので参加した。池袋のサンシャイン60にある某社の会議室で、八田さんのselfquestの話とか杉浦さんの会社で恋するフォーチュンクッキーを撮った話とかがあって、一応チームワークというテーマだったんだけど、あんまり関係ないなーという感じの緩い話をだらだら聞いてあれやこれや議論した。
selfquestというのは、その日に達成したいちょっとした事を宣言し、それを達成するという行動であるとのこと。例えば、階段10階分歩くとか、水を1リットル飲むとか、ハイタッチを5人とするとか、何でもいいらしい。それをやってみた経験談をお話ししていた。
わたしも、どーでもいいことを毎日やっている。やってみて初めて気がつく事とかあるので、行動は嘘をつかない。何事も経験である。自分がちょっと変わる事はあると思うので、このselfquestというのはなかなか面白いアイデアだと思った。
ぐぐってみると自分探しの旅とか書いてあって、八田さんのやっていることとちょっと違う感じがした。
次回のテーマは、組織改革とかそんな感じの事をゆるゆる議論することになった。3月26日の予定。興味をもった人はわたしまでご一報いただければ詳細を案内します。
2014-02-24
Fearless Changeアジャイルに効く アイデアを組織に広めるための48のパターンを熟読中
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
監訳者の川口さんから本書を貰って読んだ。アイデアを組織に広めるための48のパターンが記されている。
あなたのアイデアが組織に受け入れられないのは、単に上司が頑固者で物わかりが悪いからではない。優秀なマネージャでも新しいアイデアを試す事には躊躇がある。どんなに論理的な理論を組み立てても、多くの人は感情で物事を判断したりする。
組織には文脈がある。文化がある。それを理解しない事には、組織の中で生きていく事は難しい。
会社のような営利組織であろうが、コミュニティーのような非営利の組織であろうが、その動作原理には共通性がある。
そのような共通性をパターン言語の形式で紹介したのが本書である。
パターンを読む方法論として、先頭からずんずん読んでいくというのがあるが、それだけだと、アタマを右から左へ素通りするだけなので、一工夫してみたい。
例えば、本書を読みながら、自分が試してみたことがある、パターンを列挙してみよう。そして、それを試してみた時の、状況、問題、試してみた結果などを記してみる。一人ワークショップでもいいし、組織の同僚と話をしながら行うのもいい。
同じパターンなのに、ある人はうまく行ったり、別の人はうまく行かなかったりとか、いろいろな発見があるかもしれない。それを議論することによって新たな発見、気づきがあると思う。
例えば、わたしは会社の中でオープンソースソフトウェア(OSS)を普及推進するためにエバンジェリスト(1)として活動している。情熱をもっていろいろな人に働きかける。
あるいは、自ら学んでいく人を増やすために、社内勉強会(25)を開催したり、仲間を見つけるために、ブラウンバック・ミーティング(7)を行う。
まだ全部のパターンを読通していないので、一つ一つ噛み締めるように熟読したい。そして、この本について、同僚や知人たちとお話をしたいと強く思っている。ぜひあなたも読書会に参加して欲しい。そして議論をしよう。
2014-02-23
ルポMOOC革命、金成隆一著。読了
を読んだ。
大規模公開オンライン講座 MOOC - Massive Open Online Courses ムーク についてまとめた良書だ。朝日新聞社の記者が独自取材を重ねた記事をもとに構成されている。
MOOCとは何か、なぜ重要なのか、どのようなインパクトを教育に与えるのか、そして社会をどのように変えるのか、そのような疑問に答えようとしている。
MOOCは米国の有名大学から2012年頃から始まった。インターネットに大学の講義を無料で公開し、所定の成績を収めれば修了証も発行するという仕組みだ。2001年ころからMITなどで行われているウェブによるオープンエデュケーションとどのように違うのか、違わないのか。
教育機会を広げるオープンエデュケーションについて独自の取材に基づいて構成している。
- MOOC誕生／大歓迎する利用者
- MOOCを提供するシリコンバレー企業
- MOOCを提供する大学
- 利用する教育機関
- 教育の形を変えた男 サルマン・カーン
- 教室をひっくり返せ 自宅だ講義、教室で宿題
- どうする日本の大学
- 日本のオープンエデュケーション
- グーグルのムーク参戦、2014年へ
シリコンバレー企業
MOOCの利用者（サンフランシスコや東京、そしてモンゴル）へインタビューして、その熱気を伝える。
提供する側、シリコンバレーのベンチャー企業、Udacity(ユダシティ)とCoursera(コーセラ)の関係者にもインタビューしている。
MOOCの特徴は良質な講座を無料で提供している点だ。このビジネスは持続可能なのだろうかという著者の問いに対し、ユダシティ創立者のスラン氏は既に持続可能だという。その一つが人材紹介業だ。優良な講座を無料で提供しているので、世界中から優秀な学生が集まってくる。就職希望の学生と人材を求めている企業とのマッチングがビジネスになるという。
コーセラも同様のサービスをはじめている。500万人いる受講生のなかから企業への情報提供を許可している学生の、例えば学習履歴などを企業に提供するサービスをはじめている。
企業ニーズを反映した講座というのは「職業訓練校」みたいだという著者の指摘に対し、スラン氏は「高等教育は壊れている。現代社会の変化は早い。人は在学中だけでなく、卒業後も学び続けないといけない。だから、どこから、いつでも学べる環境が必要だ。大学は社会のニーズに応えていない」
コーセラの創業者コラー氏が言うもう一つのビジネスが有料の修了証だ。講義を受けるのは無料だが、高度な認証を受けると修了証を有償で発行してもらえる。その修了証を履歴書などに添付することも可能だ。高度の認証というのは、なりすましを防ぐために、１）タイピングのパターンを登録する、２）顔写真を登録する、３）運転免許証など公的機関が発行する証明書の写しの提出、４）生年月日など個人情報の登録、５）クレジットカード情報など。
大学
MITとハーバードが2012年５月に設立したのがedX (エデックス)だ。
電子回路を受講した学生のプロフィールが公開されている。受講生は約15万5千人、そのうち修了したのが、約7100人。満点をとったのが340名、その中にはモンゴルの15歳の少年も含まれる。受講生は194カ国から集まった。
大学にとっての大きな利益は、ムークによって、今まで発見できなかった優秀な学生を発見、勧誘する機会を得た事である。
MITは2001年からオープンコースウェア(OCW)を無料で公開している。本来はそれをビジネスにするつもりでコンサル会社に依頼してビジネスモデルを検討したところ、5年で黒字になるが収益は大して伸びないというものだった。そこで苦肉の策としてビジネスは諦め無料で公開する事にしたという。当初は教授陣からの反発や反対もあったらしい。
OCWの名物教授のルーウィン教授（物理学）は「もし君が物理嫌いの学生でも、それは君のせいじゃない。運悪く腕の悪い先生にあたっちまっただけだ。わたしが君を物理大好き人間にしてみせる。君たち全員だ。人生が変わる事請け合いだ」
カーンアカデミー
一人の男が教育のあり方を変えた。
2006年ころYouTubeに10分程度の算数の講義を従姉向けに作ったのが始めだ。それ以来数千に及ぶ授業をYouTubeにアップし続けている。
従来の学校では変えていいものと固定するものが逆になっている。今は学習時間が固定で、理解度が変数になっている。例えば、二次方程式をXコマで教える（固定）、理解度はバラバラだ。それを逆にする。理解できるまで何時間でもかける。教える時間が変数で、理解度を固定する。生徒によって理解するまでの時間がバラバラなのは当たり前という発想である。
生涯学び続ける時代になってきて、シリコンバレーの経営者がもっとも従業員に期待するスキルは「新しいスキルを自分で身につける能力」だという。
日本の大学
ムークによって世界の優秀な学生の獲得競争が始まった。東大は日本では最も優秀な学生が集まるところではあるが世界での存在感は薄い。グローバルコミュニケーションの時代に日本は乗り遅れた。グローバルコミュニケーションの基盤は英語である。国内だけで日本語でやりましょうといってもなかなかこれは通用しない。
日本のオープンエデュケーション
manavee マナビーは大学受験応援サイトだ。無料で様々な受験勉強ができる。
eboard イーボードは小中学生向け勉強サイトだ。算数が不得意だった小学生が算数好きになったりした。
schoo スクー。学校を卒業しても学び続けられる終わらない学校を目指してスクーと名付けた。
課題や今後
著者は確かそうなこととして次の点をあげている
１）良質な教材のウェブ公開は今後も続く
２）学校教育が変わる
４）学びの自発性が重要になる
感想
駆け足で本書を紹介した。熱い。
読む前は、どーせ新聞記者が書いたバズワード満載の新書みたいなものだろうと高をくくっていた。上から目線で斜めに読もうとした。
第1章を読んで、その印象がぶっ飛んだ。いい意味で裏切られた。サンフランシスコでのmeetup （学習会）に乗り込んでインタビューをしている。受講生の一人一人の物語を聞く。そこには学びたい人がいる、そして仲間がいる。ムークによって生まれている何かがある。それを予感させる。
後は一気呵成だ。
ムークを作る人たちも熱い。世界最高峰の授業を今まで受講できなかった人たちに無料で公開する。そんなことがありうるのか。それをどのように行うのか。
インターネットによって高等教育を受けたくても受けられなかった人たちが貪欲に学び始めている。
MITの電子回路の授業の受講生を分析したデータがすごい。15万人を超える受講生というのも凄いが、7000名の合格者、194カ国からの受講生というのも凄い。それを米国の大学が集客している。
この規模感は従来の大学と言う枠組みで理解するのは難しい。活版印刷が発明されたようなインパクトを大学と言う仕組みに与える予感がする。
学校教育はインターネットの教材を得た事で変わらざるをえない。勉強が嫌いになる子が出るのは今の教育方法が悪いからだという主張にはかなりの説得力がある。
「もし君が物理嫌いの学生でも、それは君のせいじゃない。運悪く腕の悪い先生にあたっちまっただけだ。わたしが君を物理大好き人間にしてみせる。君たち全員だ。人生が変わる事請け合いだ」
初等教育が大学受験のためだけにあるとしたらそれは不幸だ。学ぶ事の楽しさ素晴らしさをわたしたちは伝えないといけない。
日本のオープンエデュケーションも熱い。学びたくても田舎で予備校がなくて予備校に物理的に行けない地域の生徒がマナビーを使って勉強をする。自主的に勉強する姿が素敵だ。そして大学生になったマナビーのOB/OGがボランティアとして教える側に回るというのもすごい。
教員の役割が、固定的な知識を教えるという立場から、生徒が自主的に学ぶことを支援するファシリテーター的な役割に変化せざるを得ないだろう。先生ですら正解がわからない時代なのだ。一緒に考える方法を模索する。
「最終学歴」の意味も変わる事になるのか。たまたまブランド校を出た（最終学歴が高い）人と、自ら意思を持って学び続けている人と、企業にとってどちらがより高い価値を持つのか持たないのか。「最終学歴」対「最新学習履歴」
世界ではムークという学びの革命が起こっている。日本においてはそのインパクトがまだ十分には知られていない。多くの人にとって関心のないことなのかもしれない。未来はそこにあるのに。
日本と言う恵まれた地域にたまたま生まれて育ったおかげで、学びに対する飢餓感が自分も含め薄いのかもしれない。世界では高等教育を受けたくても受けられない人がいっぱいいる。その人たちがこのムークと言う武器を手にした時とてつもないことが起こる予感がする。
日本人が勤勉で優秀だというのは、たまたま明治以降、優れた教育システムと社会制度がそれにあっていたに過ぎない。教育システムにとんでもないパラダイムチェンジが起こって、その優位性が崩れるとしたら、日本人の優秀さというのは、今後も維持できるのだろうか。多分、難しい。
われわれは学び方を学び直さないといけない。
2014-02-22
シナリオプランニングと言う未来予測の話を聞いた
infotalkという産業技術大学院大学の小山さんが主催している勉強会みたいなものに参加した。昔infotalkというNTTの高田さんが運営していたメーリングリストがあったのだが、それとは別物である。
http://pk.aiit.ac.jp/index.php?InfoTalk%2F20140221
毎月毎月開催するというのはすごい。わたしも昔、カーネル読書会というのをやっていたんだけど、毎月やるというのはちょっときつい、というか最近まったく開催していないので、そろそろ再開したいと思う。誰か一緒にやってください。閑話休題。
今回は横河電機の古谷さんにシナリオ・プランニングの話を聞いた。
10年後，20年後といった未来の世界を正確に予測することは不可能である。 であるとすると，社会や企業は，何を根拠として来たるべき将来に対する備えを行っていけばよいのだろうか。 シナリオ・プランニングは，将来起こり得る複数の未来を想定することにより， 不確実性の高い未来に対して適切な投資配分の意思決定等を行っていくための手法である。 今回は，シナリオの考え方やシナリオ・プランニングによる戦略策定の方法論について，弊社における実践例の紹介を交えて解説する。
http://www.yokogawa.co.jp/rd/future.htm *1
未来を予測することは出来ない。これを前提に、それでも何がしかの準備が必要である。その未来に備えるという視点で議論をするのは無駄ではない。
石油ショックの前に石油ショックを予測する事はできない。しかし、仮に原油価格が高騰したらどうなるだろうという思考実験は出来るはずである。Shellはそのようにしてシナリオプランニングという手法を使い、石油ショックの前に、そのようなシナリオを想定していたという例を紹介していた。
過去の延長線で考えるのではなく、アタマをリセットして柔軟に考える。イノベーションはそのようにして生まれるような気がする。
2014-02-21
ユーザー企業が開発するということ
ウェブ系のサービスを提供しているところは常識なんだけど、世間ではあまり知られていないことは、サービスは基本的には自社で作るということだ。
日本において、ITシステムはユーザー企業が作るのではなく、それを専業にしているベンダーが作る事が多い。SI (System Integrater)と呼ばれる企業だ。ハードウェアベンダーのSI部隊であったり、独立系と呼ばれるベンダーだったりする。統計では受注ソフトウェアの売上になる。 *1
わたしはSI企業にいた経験がないので、本当の実態を知る立場にはないけど、想像するに、大手ベンダーが受注したシステム開発の案件を、誰かが要求定義して、それを文書にして、その文書をもとに誰かが設計して、その設計書をもとに、誰かが実装をする。テスト仕様書を誰かが作って、誰かがテストをする。発注側とシステムを受注する企業が別の場合は、何をいくらでいつまでに作るかというのを契約で文書化（別紙）せざるおえないので、何かと文書が増えるということは想像に難くない。
ウォーターフォール開発が行われるのは、この受注発注型ソフトウェア開発に適しているからなのではないかと想像する。
自社で開発するとすると、発注側と受注側というのが、事業部と開発部と言うくくりはあるものの、同じ組織なので、いいシステムを作れば、会社が儲かって、みんなの利益になるという意味で利害関係は一致する。何を作るかという問題についても、文書化して契約に落とし込むという作業は必要ないので、開発スピードも向上する。もちろん、双方でプロジェクトのゴールの共有とか、どのような機能を作り込むかという合意はなんらかの方法でとる必要はあるが、契約文書に比べれば遥かに軽いカジュアルなものになる。
SIは納品すれば終わりである。検収を受けて発注側の確認が取れれば終わる。
自社開発のサービスの場合は終わりはない。運用している限り、変更される。ビジネス環境の変化に応じてサービスを日夜改良する。その日夜の改良はもちろん自前でする。そのような作業を外注するということは、スピード的にもコスト的にも見合わないので、通常は行われない。
一方外注して作られたシステムの運用や変更は、同じ会社が受注したとしても別の契約になる。環境の変化に追従するために、要件を定義して、設計して、実装して、テストして、検収を受けてということを、数ヶ月単位でやるので、スピード的も遅いし、コスト的にも高いものになる。
極論するとそーゆーような図式になる。
じゃあ、ユーザー企業が自社開発すればいいじゃないかというと、ベンダーに丸投げしていたユーザー企業のIT部門には、コードを書ける人がいなかったりして、簡単にはいかない。自業自得のような気がしないでもないけど、それが実情だったりする。
昔は、ハードウェアベンダーがITの動向のイニシアチブをとっていたので、ベンダー抜きにシステム設計をするということは難しかったけど、インターネットの時代には、ハードウェアやインフラの調達はクラウドでいけるし、自前で開発できる環境は整ってきている。
システム開発というのが特殊な時代は、自社にシステム部門を丸抱えするのは、コスト的にも人材利用の観点からも経済合理性がなかった。銀行などの大手ユーザー企業は自社のシステム部門を切り離し情報サービス子会社にしたという歴史的な経緯がある。
クラウドの時代になってシステム開発は少人数で素早くできるので、このSIというビジネスそのものが、難しくなるのではないかと、余計なお世話だけど思う。
サービスを自社開発する事が競争力の源泉になるというビジネスモデルである。ウェブの業界では当たり前なんだけど、他の業界ではあまり当たり前ではないようなのであえて記してみた。
2014-02-20
Reading Mac Kernel Panic
会社のMacがしょっちゅう落ちる。1週間に一度くらい落ちる。通常は電源をオフにしないでスリープさせておくだけなので、勝手にリセットをしちゃう感じである。
いろいろぐぐってみるのだけど、Appleの情報が古くて原因究明までたどり着かない。バックトレースをみてもアドレスが出ているだけでシンボル名とかが出ていないのでヒントもない。
Thu Feb 20 15:36:40 2014 panic(cpu 2 caller 0xffffff80002c4794): Kernel trap at 0xffffff80005e8124, type 14=page fault, registers: CR0: 0x0000000080010033, CR2: 0x0000000100000001, CR3: 0x0000000083201093, CR4: 0x00000000000606e0 RAX: 0xffffff80135aec00, RBX: 0xffffff80008df700, RCX: 0x0000000000000000, RDX: 0xffffff800ab05b88 RSP: 0xffffff80b03a3d30, RBP: 0xffffff80b03a3d50, RSI: 0x0000000000020002, RDI: 0x0000000100000001 R8: 0x0000000000000008, R9: 0xffffff80008bfaa0, R10: 0x0000000000000040, R11: 0xffffff80002dad60 R12: 0x0000000000000130, R13: 0xffffff800a571f80, R14: 0xffffff80116ca680, R15: 0x0000000000000013 RFL: 0x0000000000010282, RIP: 0xffffff80005e8124, CS: 0x0000000000000008, SS: 0x0000000000000010 CR2: 0x0000000100000001, Error code: 0x0000000000000000, Faulting CPU: 0x2 Backtrace (CPU 2), Frame : Return Address 0xffffff80b03a39e0 : 0xffffff8000220792 0xffffff80b03a3a60 : 0xffffff80002c4794 0xffffff80b03a3c10 : 0xffffff80002da55d 0xffffff80b03a3c30 : 0xffffff80005e8124 0xffffff80b03a3d50 : 0xffffff80005e85fd 0xffffff80b03a3d80 : 0xffffff80005e8458 0xffffff80b03a3de0 : 0xffffff800062010c 0xffffff80b03a3e00 : 0xffffff80006227bb 0xffffff80b03a3e10 : 0xffffff8000654d7b 0xffffff80b03a3e50 : 0xffffff800029d8a5 0xffffff80b03a3e80 : 0xffffff8000223096 0xffffff80b03a3eb0 : 0xffffff80002148a9 0xffffff80b03a3f10 : 0xffffff800021bbd8 0xffffff80b03a3f70 : 0xffffff80002aef10 0xffffff80b03a3fb0 : 0xffffff80002daec3 BSD process name corresponding to current thread: System Preferenc Mac OS version: 11G63b Kernel version: Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 Kernel UUID: FF3BB088-60A4-349C-92EA-CA649C698CE5 System model name: MacBookAir4,2 (Mac-742912EFDBEE19B3) System uptime in nanoseconds: 324217868157493 last loaded kext at 4975708245448: com.apple.filesystems.smbfs 1.7.2 (addr 0xffffff7f80795000, size 241664) last unloaded kext at 398561999464: com.apple.driver.AppleUSBUHCI 5.1.0 (addr 0xffffff7f80baa000, size 65536) loaded kexts:
Kernel trap at 0xffffff80005e8124とあるので、そこで落ちたというのは分かる。それがどのモジュールなのかを知りたいのだけど、このダンプの情報だけでは、どこにあるのかが分からない。カーネルのシンボルってMacはどこに保存しているのだろう。
コアダンプは /Library/Logs/DiagnosticReports/Kernel_2014-02-20-153640_P17873.panic というようなファイルに格納されている。
トラブルシューティングの方法をご存知の方は教えてください。
2014-02-18
MOOC - Massive Open Online Courses
インターネットを利用したオープンでオンラインで学べるコースが増えている。無料で高品質の教育が受けられる。
http://en.wikipedia.org/wiki/Massive_open_online_course
圧倒的な量がある。私自身は受講の経験はないがリストを斜め見てみると興味を引かれるコースが山のようにある。
http://www.mooc-list.com/university-entity/stanford-university
新しい学びの場が出来つつある。
2014-02-17
大学の社会的役割など
最近、産業技術大学院大学の授業にかかわったこともあり、大学の社会的な役割などをがらにもなく考える機会がある。素人があれやこれや考えたことなので、専門家の皆様の生暖かいコメントご意見などをいただきたく。
大学の主な機能はいうまでもなく、教育と研究だ。研究者を育成するというのは、まあ、研究と言う名の教育みたいなものかと思う。企業のOJTと似ている。教授が弟子の学生に課題を与えて研究手法を学ばせるという意味で教育であり、研究でもある。
それはともかく、多くの学生に取っての大学の価値は、１）教育を受けることと、２）大学卒の資格を得ることである。
今まで知らなかったことを知る。すなわち知識の獲得なのか。出来なかったことが出来るようになる。すなわちスキルの獲得なのか。
学生が教育機関に時間的なコスト（数年間）と金銭的なコスト（授業料その他）を払うのはなぜなのか？
文部科学省が認定する大学資格を獲得するために４年間という時間と数百万円のコストを払う価値があるのかないのか。
ある職業に就くために大学卒の資格がいるとして、その職業に就くことによるリターンと、その職業に就くのに必要な資格を取得するための投資との比率(ROI)が1以上であれば、投資をする価値がある、という風に単純に考えていいのだろうか。
野球の選手になるのに大学卒の資格は必要ない。大卒でなければ野球の選手になれないというわけでもない。
医者になるには医師免許を持っていなければならない。医師免許を取得するためには大学の医学部を卒業しないといけない。よって、医者になるには、医学部を卒業しないといけない。
会社員になるために、会社の応募資格を満たさないといけない。会社によっては、応募資格は大学卒業以上としているものもあるので、その会社に入社するには大学を卒業しないといけない。そーゆーことなんだと思う。
それ以上でもそれ以下でもないのだろうか。
まあ、大卒資格に関しては、その程度のこととして、教育を受けること、そのものの価値について考えるとどうなるか。
知識を得るという意味では、インターネットで無料でいくらでも知識は得られるように見える。
大学ではその知識を体系化し、権威ある人々によってそれが再構成され編集され教えられる。その編集価値が大学という場にある。
ということなのだろうか。
MOOC - Massive Open Online Courses というオンラインの無料の高等教育がインターネット上で公開されている。MITやハーバードのような米国の一流大学の授業が無料で受講でき、ある一定の条件を満たすと単位も取得できるという。
そのような時代の大学卒の資格の価値はどこにあるのか。知識獲得の場としての大学の価値はどこにあるのか。まさにそれが問われている。
大学の価値は研究と教育だけなのだろうか。教育についても、資格と知識獲得という価値だけなのだろうか。
もちろん正解はない。職業人を育成することだけが大学の機能というわけでもない。職業訓練校ではないという人もいることは承知している。
一方で、18歳ー22歳までの高校を卒業してすぐ入学する学生以外にも、いわゆる社会人学生という人たちがいる。いろいろな事情で社会に出た後、学びたいから学ぶという人たちである。産業技術大学院大学の学生の多くはそのような社会人学生である。
その人たちに取っての教育というのは同じ教育という枠組みではあるけど随分違うような気がする。上手に言葉にすることは難しいけど、知識を得たい、学びたいという強い心の叫びによる何かのような気がする。
大学がそのような人たちの要求に十分応えられているか、そのニーズを汲み取っているのかというのがわたしの素朴な疑問なのである。
大学教育にも時代の変化にそったイノベーションが必要でそれには社会人学生への対応というのが強く求められている。それがどのようなものかというのは、厳密に言葉にすることが難しい。
2014-02-16
不格好経営 チームDeNAの挑戦 南場智子。読了。
不格好経営―チームDeNAの挑戦
彼女のキャリアはよく知られている。マッキンゼーでキャリアを積みパートナーになるが、インターネットベンチャーのDeNAを創業し社長になる。そして夫の看病のため社長を退任し現在にいたる。そして本書は、彼女のビジネスに対する考え、DeNAの原点を余すことなく記している。
コンサルタントとして順風満帆だった著書がなぜか起業し、それまでのキャリアが張り子の虎だったことを学ぶ。とんでもない失敗を繰り返し、その度に学んでいく。失敗を成長の糧にしていく過程がこれでもかこれでもかと記されている。
インターネットのオークションサイトを作るというのが創業時のビジネスモデルだ。そして、詳細な仕様書を作りサイト構築を外注する。さすがコンサルあがり、やることにそつがない。システム開発を発注する。そして、「開発が完了したはずのその日に、実際はコードが1行も書かれていないことが発覚したのだった。」
コードが1行もない、つまり開発の成果物ゼロ。つまりシステムがない？…
すごい、自分ならそんな現場にいたくない、超絶なデスマーチの始まりである。丸投げ、コミュニケーションがゼロ、そして何もないことが最後の日に発覚する。
- 諦めるな。その予算規模なら天才が3人いたら1ヶ月でできる。
- 関係者、特にこれから出資しようとしている人たちにありのままの事実を速やかに伝えること。決して過小に伝えるな。
- 「システム詐欺」という言葉をやめろ。社長が最大の責任者、加害者だ。なのにあたかも被害者のような言い方をしていたら誰もついてこないぞ。
この強烈な経験がシステムなんかどっかに外注すればいいよというコンサルタントの作法を徹底的に破壊する。この経験がトラウマになって学んでいく。
そしてどうにか黒字化にこぎつける。時代は携帯のパケット定額制が定着し始める。
そこに登場したのがモバオクだ。ビッダーズとは切り離して開発した。その開発者が川崎（のちに取締役CTO）だ。ひとりで、3ヶ月ほどで感動的に使い易いシステムを開発する。これまでの開発アプローチ、要求定義、設計、コーディング、テストというステップが再度大きく見直された。つくり手（プログラマー）を企画段階から巻き込み、つくり手自身がユーザーにとっての面白さや使いやすさを考えながらプログラミングしていく方式を取り入れていく。
これはある意味、SI的ソフトウェア開発からの決別であり、ウェブサービス開発の王道であるハッカー的ソフトウェア開発を自らの組織で学んだ瞬間だ。経営者が unlearning した瞬間と言ってもいい。
著者は自信の出身である、コンサルタント業界の人々に次のようなアドバイスをする。１）何でも3点にまとめようと頑張らない。物事が３つにまとまる必然性はない、２）重要情報はアタッシュケースではなくアタマに突っ込む、３）自明なことを図にしない、４）人の評価を語りながら酒を飲まない、５）ミーティングに遅刻しない。
ぐははは。コンサルタントをおちょくっている。おちょくっているが人材流動性があり優秀なのでコンサル業界から積極的に雇用しているのも事実である。そして人材採用に関しては社長自ら最も重要な課題として取り組んでいる。
これまでの軌跡を振返りながら特に自らの失敗を面白おかしく誠実に記しているところが素敵だ。もちろん語られていない物語も沢山あるだろう。それを差し置いても失敗を真摯に書き記すことは出来るものではない。
2014-02-15
ビブリオバトル
１）お勧めの本を持ち寄り、２）それを5分で紹介し、３）2〜3分質疑応答をし合い、４）最後にどの本が読みたくなったかを参加者全員で投票で決める、というルールで運営される読書会のようなもの、ビブリオバトルというのを教えてもらった。
そのルールは厳密に定義されていて、その公式ホームページもあれば、入門書もある。その入門書を読んだ。
読書会、輪読会という形式の勉強方法というのは昔からあったが、このビブリオバトルというのは、それにちょっとしたゲーム的な要素を加えてルールを決めた。
読書会同様に１）本の内容を共有できる、２）発表の練習になる、３）いい本が見つかる、４）お互いの理解が深まる、というような機能がある。
５分と言う発表時間の制約から、その本の魅力を凝縮し伝える努力が発表者には求められし、発表時間がそれほど長くないので、10冊程度の本の紹介でも1時間ちょっとで終わるのでお手頃である。また、最後に参加者全員の投票で最も人気のあった「チャンプ本」を選ぶと言うゲーム性も兼ね備えている。
読むべき良書をコミュニティの中で選ぶには適した方法かもしれない。読むべき良書というのはちょっと違うかもしれない、自分が日頃読んだことも読んでみようと思ったこともない本を勧められて読むと言う体験をするのにいい方法かと思う。自分が読みたい本を発見する方法だ。ベストセラーだから読むというのではなく、知り合いが面白かったと勧めてくれたから読む。
本を紹介を聞くことによって、その紹介している人の人となりを知ることにもなる。
感想を聞いて、へー、そんなことを考えていたんだなどと話が膨らむことがある。自分の好きな本を熱く語る人と親近感を感じる。そんな気分である。
2014-02-14
デブサミ2014、2日目
午前中は、竹迫さん司会で、宮川さん、和田裕介さんとの鼎談。Podcastのような緩いしゃべりを二時間近く聞く。隣に座っていた女子がiPadで鼎談をしている3人の似顔絵を描いていた。その似顔絵をチラ見をしながら聞いていたのだが、途中で退席してしまった。ふむ。
オープンジャムで伊藤さんがお話をしていた。Android でCI/CDやATDDなどをした話。アプリ開発はいろいろ自由に出来たというようなことをノリノリで話していた。
大規模イベントの運用ノウハウを学びにきた佐藤さん。ボランティアスタッフ。会場にとけ込んでいた。
午後は、モジラプロジェクトの人のお話や、マイクロソフトのなんちゃってSCRUMのお話を聞いた。
増井さんのエンジニアだからできる自由な生き方というセッションは熱かった。
早速下記のようなまとめを発見した。
http://tchikuba.github.io/blog/2014/02/14/engineers-free-life-style-of-developers-summit-2014/
自由は闘って勝ち取るものというのはまったくその通りなんだけど、日本ではほとんど理解されていないような気がする。ハッカーだな。まさにと思った。
Ask the Speakersで質問に答える川口さん（左）、増井さん（右）
デブサミでいろいろな人と立ち話をした。お久しぶりの皆様の近況を聞きながら、自分もなんとかしないといかんなーなどと漠然と思った。
最後のセッションは「なぜ、システム開発は必ずモメるのか？」と題して、切込隊長の山本一郎さんがIT専門調停員の細川義洋さんと対談をする。これが実にブラックなデスマーチのあれやこれや、裁判所にいくぐらいだから相当揉めた案件について、細川さんが解説をするという形式になっていた。まあ、いろいろあるんだろうなあという印象を持ったセッションだった。
2014-02-13
デブサミ2014（初日）に行った。
http://event.shoeisha.jp/devsumi/20140213/timetable/
午前中は新野さん、玉川さんのセッション。クラウドで世の中変わっているという話で、ショートプレゼンと絡みがあってよかった。ランチタイムはデジタルインク。ラウンジでだらだらしていたら矢萩さんがいたので雑談。未踏をやっているらしい。とっととデモを公開しろーと人ごとながらハッパをかけるなど。新任CTOの大場さんにあったり。移動の最中に川口さんがジャムってた。ジャムおじさんとこれからは呼ぼうと思った。その後、DeNAの新人研修の話を聞いた。新人にKPTでコーチというのが素敵だ。まねしたい。
（ジャムおじさんがんばるの図）
後でコーヒーのみに行こうと思った。最後のセッションは本のお話を聞きにいくことにする。あー明日は図書館によりたい。今日は特別休館日だった。くー。
2014-02-12
まつもとゆきひろのコピーは作れるのか。
「Rubyにみるグローバルソフトウェア開発」というタイトルでの講演だった。 http://aiit.doorkeeper.jp/events/8871
コミュニティの運営とかは言語化できそうだけど、情熱をコピーすることはできない。心に灯をともすにはどうすればいいのだろう。それを１０年間続けるにはどうすればいいのだろう。
OSSを作ることはそれほど難しいことではない。多分、気の利いたプログラマなら誰でも作ることはできる。
githubのようなサービスが開発を支援してくれるし、コミュニティ作りのコストを圧倒的に下げた。twtitterやFacebookやブログなどで開発を告知することも出来る。
にも関わらず、Rubyのように世界中で使われるプロダクトを作った人はまつもとさん以外にほとんど現れていない。OSSを作った人はいっぱいいるが、まつもとさんのようなアイコンになった人が現れていないのはなぜなのか？
技術力か、英語力か、マーケティング力か、コミュニティ力か？その差は何なのか。
Rubyが世界中で使われるようになるまで10年かかった。だけど、クラウドのサービスを使えば、それは1年に短縮できるとまつもとさんは言う。mrubyも成功したので、自分の方法論をまねすれば誰でもできるのになんで後進がいないのだろうか？と彼は問う。
その差は情熱なのではないか。情熱格差がすごいプロダクトとの差を生むのではないのか。
2014-02-10
データベースでもっとも重要な３つのアイデア。（世界でもっとも強力な９つのアルゴリズム）
昨日の日記には山のようにブックマークがついた。( 世界でもっとも強力な9のアルゴリズム
データベースはアルゴリズムじゃないだろうというツッコミもあるけど、偉大なアイデアということだろう。それは多分誰も異論はないと思う。そこで紹介されている３つのアイデアは
トランザクションと言う概念が70年代以降発展してきて、その実装にはログ先行書き込みが多大な貢献をした。
2段階コミットによって分散型データベースが信頼性をもって実装できるようになった。
リレーショナルデータベース（というよりもリレーショナルデータモデル）は全ての基盤になっている。
これらの発展は70年代のSystem Rの先駆的な研究開発から始まったといっても過言ではないが、Oracleをはじめとする商用化によって広く社会にインパクトを与えた。
2014-02-09
世界でもっとも強力な９つのアルゴリズム、読了。
世界でもっとも強力な9のアルゴリズム
コンピュータサイエンスの優れたアイデアを紹介している。それらは私たちの生活を変えた。世界を変えたにもかかわらず広くは知られていない。
偉大なアルゴリズムというものは何なのか？本書はその偉大なアルゴリズムを次の基準で選定した。１）普通のコンピュータユーザが毎日使っているもの。２）現実世界の具体的な問題を解決するもの。３）コンピュータサイエンスの理論に関係のあるもの。
最初の二つのアルゴリズムのおかげでわたしたちは日々検索エンジンで有用な情報を入手できる。公開鍵暗号やデジタル署名のおかげで安全にインターネット上でクレジットカード情報などを交換できる。誤り訂正符号があるから不安定な通信経路を使っても情報の信頼性を担保できる。パターン認識はAI（人工知能）の領域の一つであり、人間が得意とされていた分野を機会機械が解決可能であると示した。データベースによって多量の情報を正確に扱える。そして決定不能性はコンピュータがいかに強力でもコンピュータでは決して解決できない問題があるということを教えてくれる。
コンピュータサイエンスを専攻していない人にも平易で分かり易い入門書になっている。
- Twitter / @oTheRwoRldy
- Twitter / @Miyazaki_Yuma
- Twitter / @thmda
- Twitter / @_yosssi
- Twitter / @aWebprogrammer
- Twitter / @ryuusagi
- Twitter / @itacccchi
- Twitter / @hyoshiok
- Twitter / @yumika__
- Twitter / @7041keda
- Twitter / @testnoda
- Twitter / @hiro2fuji
- Twitter / @Bellickda
- Twitter / @odonobo
- Twitter / @Nackybear
- Twitter / @mimushin72
- Twitter / @hos_tokkk
- Twitter / @pachili
- Twitter / @adaruxu
- Twitter / @sukerutulo
- Twitter / @hyoshiok
- Twitter / @renmoza87
2014-02-07
1000 speakers conference in English, 3rd
早くも第三回の1000 speakers conference in Englishを産業技術大学院大学で開催した。
毎回会場を提供していただく、産業技術大学院大学の上田さん、阿部さんありがとうございます。大変助かります。
三回終わった段階で、会員番号18番まで行った。発表すると会員番号を貰える。特に特典はない。（特典ないのかーー（笑））
今年中には100人の発表者にもっていきたいのだが、なかなか人が集まらない。英語で発表する機会が少ない皆様、お待ちしております。奮って参加して欲しい。
次回は3/14なのでカレンダーに印を付けておいて欲しい。
http://1000.doorkeeper.jp/events/8927
英語の読書会
今回のネタは英語本の読書会をしようという、極めて直球ストレートなもの。５分間で、だだだだとお話しした。
会社の仲間でもいいし、友人でも知人でもいいので、何か英語の本をみんなで読んでお話をする。それだけっちゃーそれだけ。難しくもなんともないのだけど、いくつかのコツらしきものはやっぱりある。
何を読むのかというのと、どんな風に読むのか。
何を読むのかというのは、IT系の場合、定番の教科書的なものを読むというのをお勧めしたい。Joltアワードノミネートされたものは、さほど当たり外れがない感じだ。
英語で本を読むというのは、日本語訳が出るまでに読み終わったりすると、いち早く話題の本の中身を理解していたりして気持ちがいい（自己満足）
本を会社の人たちと読むと、共通の語彙、コンテキストが生まれるので、話が通り易くなるというメリットもある。「レガシーコードというのはテストのないコードのことだ」的なキャッチーな理解が共通に生まれたりして、お得である。
英語の本は一人で読むというのはちょっとしんどいけどみんなで読めば理解も深まるのでお勧めである。
2014-02-06
学習コストってなんだろうな。
http://d.hatena.ne.jp/hyoshiok/20140205/p1 集中型バージョン管理システムと分散型バージョン管理システムってでいろいろコメントをいただく。ありがとうございます。
結局、学習コストの話になる。何事もなれですね、そーですね。では、さすがに何を議論しているかわからなくなる。
前提として、ソフトウェア製品とかサービス開発の現場のエンジニアの素養としてのVCS利用スキルをどう身につけるかということに限定してみたい。プロのプログラマの必須スキルということを考えている。
サンデープログラマが趣味でプログラムを作っているとかではなく、職業としてソフトウェア製品とかサービスを開発する人のことだ。
そのような人を養成する授業を大学が用意するとしたらどのようなカリキュラムになりうるのか？
ソフトウェア開発の現場の経験がないけど、プログラミング経験くらいはある。エディタは使える。くらいのふつーの学生さんを想定してみる。
授業は必修科目ではなくて、好きなら取ればいい科目とする。プログラマになりたくない奴に無理矢理プログラムを教える必要もないし、むいてないこと好きでもないことをやる必要もない。なので、教える側が、全員に理解させようとか、全員合格でオッケーというようなスタンスでいる必要もない。底辺の底上げを目的にはしない。
前置きが長いけど、その前提で言えば、いまさらsubversionでもないでしょう、CVCSでもないでしょう、というのが今日の日記の結論である。
ソフトウェア開発で主流のDVCSを先に学ぶ。そのスキルを身につける訓練をする。そのような課題を作って、演習をする。
全員、git/github/heroku/Rail/Travisなどを使ってプロジェクトを行った。10週間でのcommit数である。ずんずん開発している感じがする。（下記参照）
チームでツールを学んでいけば、ちょっとしたところで躓いても教え合って、理解が深まる。
今回はgit-flowなどの話はしなかったけど、次回は触れてみるかなー。プロダクト開発の感覚を理解するためにも、そのようなパターンを共有することはいいことかもしれない。
学生作品、順不同
| チーム名 | プロダクト | commit数 | 貢献者数 |
| Hacky_and_rocky | http://denka.herokuapp.com | 345 | 4 |
| team puma | http://sorejanai.herokuapp.com | 215 | 4 |
| 5倍返し | http://jshop.herokuapp.com | 112 | 6 |
| RyuPiT | http://sharepla.herokuapp.com | 1111 | 6 |
2014-02-05
集中型バージョン管理システムと分散型バージョン管理システムって
集中型バージョン管理システム（以下CVCSとする）と分散型バージョン管理システム（以下DVCS）って何がどうよかったり嬉しかったりするのだろうか。というようなことをつらつら考えてみた。きっかけは、gitの話とか、そのあたりから。（gitって難しいのかなー http://d.hatena.ne.jp/hyoshiok/20140201/p1 ）
バージョン管理システム（VCS）のキモは複数人での共同開発を支援するということにつきるかと思う。http://d.hatena.ne.jp/hyoshiok/20140204/p1
一人で開発していればコミュニケーションロスはないので、ひたすらズンズン開発するだけである。一方で複数で開発していれば、どのようにしてコードを共有し統合しテストするかという問題があって、その作業を支援するのがVCSやソフトウェア構成管理と呼ばれるものである。ソフトウェア構成管理（SCM）はVCSより広い概念だ。
DVCSの概念を理解するために、CVCSの概念を理解しないといけないということはなくて、VCSのキモを理解していれば、おのづと理解できる。
昔のツールはCVCSを前提に作られていたので、歴史的な経緯としてCVCSを先に知って、その後DVCSを使い始めたという人は多いかもしれない。だけど、CVCSのツールを勉強した後にDVCSを勉強しなければいけないということでもない。
ソフトウェア製品やウェブサービスの開発を考えてみる。どっかのサーバーにリポジトリを置く。それには、ソースコードや、テストなどを置いておく。コードのメインラインをそこで育てていく。実際の開発は、自分の手元のPCとかワークステーションに用意したプライベートなワークスペースで行うことになる。
集中型の場合、コードの管理はすべて中央のリポジトリだけで管理されているというのが通常のスタイルになる。
一方、分散型の場合は、中央のリポジトリとそのコピーを各自のローカルなワークスペースに置いたものとになる。管理の対象はずんずんローカルのリポジトリに開発ブランチを切って行われる。ブランチを作る精神的・文化的なコストは非常に低い。
集中型の場合も中央のリポジトリでブランチを作るわけであるが、マージのコストが高いために、各自が勝手にずんずんブランチを作りまくってずんずんコミットしてずんずんマージするということは行われない。
マージのコストが高いというのはsubversionというツールに起因することなのか、それとも集中型バージョン管理システムそのものの特徴なのかはわからないが、そのような傾向にある。
そのために、ブランチの管理はかなり厳密にされ、実験的な機能の開発をずんずんやって、その成果をチームで共有するというようなことは、文化的、ツールの機能としても難しい。
一方DVCSであれば、リポジトリはそれぞれ独立で親子関係はないので、自分のローカルなリポジトリ上にいろいろな機能ブランチを作って、そのタスクブランチ上で実験的な機能の実装や他のビルドを壊すような実装なども簡単に行える。
またマージのコストが安いので、そのタスクブランチ上でメインラインのコードをマージして、他のコードを壊していないことをローカルに確認できる。そのコストは安い。
そして、ローカルにずんずん開発したものをリモート上の自分の公開レポジトリにコピーしておけばメンバーからも容易に参照できて、他のメンバーが、自立的にマージしたり、あるいは他のメンバーへプルリクエストを出して、取り込んでもらったりできる。
CVCSの場合は、実験的なコードについても、そうじゃないものについても、ブランチ上のマージは簡単ではないし、失敗した場合のコストは非常に高い。
DVCSの場合は、ブランチのマージは、自分のローカルなリポジトリで行って、確認するので、他のメンバーへの影響は少ない。それでも、メインラインを壊す奴やいる。
CVCSに比べれば、DVCSの方が小さい単位でずんずんマージできるので、精神的にも開発者の負担は少ない。
中央レポジトリのコピーを持つか持たないかというだけの違いだが、それが運用上大変大きな違いを生んでいる。
中央レポジトリのコピーを作ることをフォークするとかクローンするとか言う。かつてはフォークするというのが管理対象や複雑さを増やすことなのでよくないことと思われていた。
ところがDVCSによって、その文化的コストも管理コストも下がった。むしろローカルのレポジトリを持つことのメリットの方が大きい。すなわち中央のレポジトリにアクセスできなくても、ローカルにどんどんコードを変更でき、それは開発のスピードを加速する。
CVCSの場合は、中央リポジトリでの作業がボトルネックになり、開発がスケールしにくい。
継続的インテグレーションなどもローカルでずんずんやったり、リグレッションテストをローカルに流して、他のブランチを壊していないことを安く確認できるが、CVCSの場合、他の人のブランチを自分のコードラインにマージすることが簡単ではないので、実験的にマージして確認するなどということが難しく、開発を加速するのが難しい。
歴史的にCVCSを使っていて移行が難しいという事情がある場合を除いて、これからの開発でCVCSを利用すると言うメリットはないと思う。
2014-02-04
パターンによるソフトウェア構成管理
パターンによるソフトウェア構成管理を大学の図書館で見つけて読んでみたところ意外に良書だったので紹介する。
16個のパターンを紹介している。
| Pattern Name | Summary |
| Mainline | マージを最小化する。メインラインで開発することによってアクティブなコードラインの数を管理可能な集合にする。 |
| Active Development Line | Active Development Lineを作ることによって急激に成長するコードラインを安定化する |
| Private Workspace | Private Workspaceによって、統合の問題で集中できない状況から守る、また自分の変更が他の人に影響を及ぼさないようにする |
| Repository | 必要なものを全て持っているRepositoryを設定する |
| Private System Build | Repositoryにコミットする前にPrivate System Buildによって自分の変更がビルドを壊していないか確認する |
| Integration Build | Integration Buildを定期的に行うことによって自分のコードベースが信頼できるビルドができるか確認する |
| Third Party Codeline | Third Party Codelineによってベンダーコードを管理する |
| Task Level Commit | タスク毎にソースコードの変更を整理する |
| Codeline Policy | 開発者がいつコードラインにコードをチェックインするか、各コードラインへチェックインする前に行う手続きについて理解することを助けるCodeline Policyを作る |
| Smoke Test | Smoke Testをすることによって自分の変更がシステムを壊していないことを保証する。 |
| Unit Test | Unit Testを実行することによって自分の変更のあともモジュールが動作することを確認する |
| Regression Test | Regression Testを実行することによって既存のコードが変更に影響を受けていないことを確認する |
| Private Versioning | Private Versioningを使えばローカルに複雑な変更を実験的に行うことが可能になる。それはバージョン管理システムの他の利点を甘受しつつできる |
| Release Line | Release Lineを確立することで、現在の開発に影響することなくリリースバージョンを保守する |
| Release-Prep Codeline | Release-Prep codeline上で安定化作業を行うことで、新しい作業はアクティブなコードライン上で続けながら、リリースに向けての安定化ができる |
| Task Branch | Task Branchでチームの他のメンバーの仕事に影響を与えることなく破壊的なタスクを実行できる |
上記のまとめと、下記の図は http://www.scmpatterns.com/book/pattern-summary.html より引用。
パターンは先人たちのベストプラクティスを表したものなので、智慧がぎゅっと圧縮されている。自分たちの開発のスタイルがどこにいてどんな問題を持っているかの地図になる。迷子になる前に、あるいは迷子になった時、自分の位置を確認するのに使える。
自分のチームが使っているツールによってどのような作業が支援されているのか、どのような作業が難しいのかなどを確認してみよう。
本書は分散型バージョン管理システムが一般化する前に書かれたので分散型のパターンがないようにみえるが、本書の価値は変わらない。手元に置いておきたい一冊である。
