ysawa が教える「超プログラマへの爆速勉強法」

人工知能と人類の未来を考えてみた

ysawa (澤良弘) — Wed, 23 Mar 2016 20:00:00 +0900

星新一賞に対して人工知能を使った小説が11作品も投稿されたというのが話題になっております。現時点では、人間の手が若干加わっているとのことですが、見事に人間の想像力というものを脅かしてくれるニュースでありました。

今回は、人工知能に関して僕なりの展望を書いていこうと思います。

人工知能の小説

投稿作品と言われるものをいくつか読んでみたのですが、基本的に星新一の小説のように心が揺さぶられる要素がないことと、若干、文の繋ぎが難しそうというのが感想です。ですが、100%人間が書いたと言っても違和感の少ない文章でした。

そして、将来を想像しながら読むということであれば、十分面白い文章だなと思いました。

文章ということで言うと、人間かロボットかはあまり関係なくなってきているのかなと思います。すでに Twitter では人間なのかボット(自動配信ツール)なのかの区別がつきにくいという現状があります。

そして、人工知能が作ったニュース、書籍を知らず知らずのうちに購読している。そういう世の中はもうすぐそこまで来ています。正直、星新一賞投稿作品レベル以上がキープできれば、問題無いでしょう。

今後、各メディアの編集長は、人工知能を扱う力量が問われて来るでしょう。8割程度のクオリティで人工知能に書かせ、人間が推敲して公開する。そのような手順が基本になるのではないでしょうか。

文章に関しての未来は明るそうです。では、音声や会話に関してはどうでしょうか。

コラボレーションツールとは

若い人の会話は LINE や Twitter などをはじめとするツールによるコミュニケーションがもはや主流といっても過言ではないですね。以前なら電話や会話によって、やっていたコミュニケーションもこういうツールがあると楽にできます。

IT系ベンチャーを中心として、Slack(スラック) とか Hangout(ハングアウト)、Chatwork(チャットワーク)、Backlog(バックログ)と言われるツールが非常によく使われるようになりました。

これは、コラボレーションツールと言って、会話や仕事のやり取りの内容、ファイルの交換履歴などを整理して残しておくための手段です。

これらのツールを使う目的は何かというと、会議を削減・効率化することです。会議は、後でも述べますが、オーラルコミュニケーションの上に成り立つコミュニケーションで、時間や労力といったありとあらゆるものを拘束しなければ成り立たない非常に非効率な手段と言わざるをえません。

ダラダラ会議を終わらせた、ザッカーバーグの2つの会議効率化戦略にあるように、世界中の企業が、会議自体を削減することや、効率化を図るように試みています。

僕は、学生時代、生徒会をやっていたことがありますが、思えば、人生においてダラダラと会議をやる習慣は、あれが最初なのかもしれません。

ちなみに、当時気弱な僕は、生徒会は周りの圧力に屈してやったものであり、選挙活動以外面白いと思ったことは一度もありませんでした。僕は、早く帰って N88 Basic のコードを打ちたくてしょうがなかった気がします。

今の子は、自宅で Jumper やるか Mine Craft やるか YouTube でも撮っていたほうがよっぽどよいでしょう。これらのほうが、よりみんなと協力しあって作品を作り上げる喜びを感じられます。

オーラルコミュニケーションの終焉

オーラルコミュニケーションは、音声を使った会話によるコミュニケーションの手段のことを言います。オーラルコミュニケーションはさらに、バーバルコミュニケーションとノンバーバルコミュニケーションに分けることができ、音声による文字情報の伝達をバーバルコミュニケーション、表情や雰囲気などによる情報の伝達をノンバーバルコミュニケーションと言います。

オーラルコミュニケーションの良い所でもあり、悪いところでもあるのが、コミュニケーションミスが生じやすいところと、時間、労力が拘束されること。あと、仕事上非常に問題なのですが、会議費というのは、意外に請求しにくいものです。

まず、ひとつ目の問題、コミュニケーションミスが生じやすいということですね。がんばって伝えようとしてもなんか伝わらない。議論がそれていってしまったり、雑談化してしまうなどが結果として起こります。これは、現時点では、コラボレーションツールを使って大半の問題は解決できるでしょう。将来的には、人工知能と人類がまさにコラボレーションすることで、解決していくことだと思います。

例えば、恋愛において、ベストな告白のタイミングを教えてくれたり、喧嘩してしまった場合も、仲直りの手段を提示されるようになるでしょう。

そして、時間、労力の拘束、会議費ですが、これらはまとめてコラボレーションツールを使えば解決するでしょう。

このようにして、本当に必要な会話だけに集中することができるようになるでしょう。人工知能はおそらく、水道光熱のようにインフラ化して、月額固定で個人が利用できる段階までいくでしょう。

既に、美人受付嬢アプリなどが販売されていて、仕事上、すでに人間がやるべきコミュニケーションは限らてきている。そう考えても間違いではないでしょう。

オーラルコミュニケーションの終焉という見出しにはしましたが、人間のコミュニケーション自体は大きく進歩を遂げるでしょう。

星新一関連ニュースまとめ

今回は、ここで終わりです。

星新一賞に関して、中でもよくまとまっていた、ニュースのエントリを上げておきます。

http://www3.nhk.or.jp/news/html/20160321/k10010451071000.html

http://pc.watch.impress.co.jp/docs/news/20160322_749364.html

Haskell で覚えるプログラミング

ysawa (澤良弘) — Wed, 16 Mar 2016 20:45:00 +0900

いままで、モデルやモジュールに関して話して参りましたが、今回は、更に応用に入っていきます。理屈っぽい話が続きましたが、全ては、プログラミングができるようになるための下準備でした。

今回は、簡単なプログラミングをしてみます。扱うのは、 Haskell という名前の言語です。 Jumper のデータを保存するサーバにも使われている現在の欠かせない言語です。

例題として、

ベクトル (1, 2, 3, 4) と (4, 3, 2, 1) の内積を求めよ。

を扱ってみます。内積の計算といえば、言語処理などでもよく使われる重要な演算処理となります。内積の値が大きければ大きいほど、2つのベクトルに関連性があるということです。

プログラミング言語を扱ったことがある人は、得意な言語でどのようなコードになるのかを想像してみてください。

ちなみに、上の内積の計算は簡単で、

(1 * 4) + (2 * 3) + (3 * 2) + (4 * 1) = 20

となります。掛け算して足し合わせるだけです。他の言語だと、恐らく、5行前後で表現できるのではないでしょうか。簡単な計算のはずが意外と書くことが多くて大変です。

では、Haskell ではどうなるのか。でも、その前に Haskell に関してさらっと勉強していきましょう。

Haskellとは

まず、Haskell は関数型言語です。関数型言語は、手続き型言語と対となって説明される概念です。関数型言語は、数学で勉強する関数を組み合わせることで要件を満たします。それに対して、手続き型言語は、手続き(一連の処理の流れ、ルーチン(routine)、プロシージャ(procedure))を組み合わせることで、求める動作をします。

Lisp、Scheme、Ocaml、Haskellなどが、関数型言語。C言語、Perl、Basicなどは、手続き型言語です。手続き型言語は、手続きのことを「関数」と読ぶことが多いですが、ほとんどの「関数」は、関数ではありません。今回は、関数か否かの話は割愛します。

次に、Haskell は静的型付け言語です。僕が、Haskell を好む理由は、こちらにあります。静的型付けによって、複雑なプログラムもミスが少ないことを保証することができるのです。こちらも、詳しい話は割愛します。

インストール

https://www.haskell.org/platform/ からインストーラをダウンロードしてください。

ダウンロードが完了したら、ダブルクリックしてインストールしてください。あまり大変な作業は無いかと思います。

ghci

ghci を使うことで簡単に Haskell のプログラミングを触ることができます。

コマンドプロンプトまたは、ターミナルを開いて、以下のコマンドを打って開始です。

ghci

これだけです。ghci> という表示が出てきたと思います。

では、簡単な計算をしてみようと思います。

1 + 1

2 と出てきたら成功です。

では、どんどんやっていきましょう!

リスト操作

Haskell において重要なデータ構造が、リストです。リストを制するものが Haskell を制するといっても過言では無いでしょう。

let a = [1, 2, 3, 4]

これで、リストの定義は完了します。let は、「…を〜させる」という意味の単語ですね。この場合、a を [1, 2, 3, 4] と定義するという意味になります。

[1, 2, 3, 4] というのがリストです。他の言語とほとんど同じですね。

head a

とすると、先頭の 1 が取り出せ、

tail a

とすると、[2, 3, 4] が取り出せます。

last a

の結果は、4 です。

なんか、退屈ですね。。。こういう関数は、使いながら慣れていけばよいので、こういった関数は、今覚える必要はありません。

リストという複数の要素を扱うための型があるということを認識できればそれでよいです。

foldr

foldr (フォールドアールと読みます)は、畳み込みという名前の付いた関数です。先ほどの a を操作してみましょう。foldl(フォールドエル)もありますが、ほとんど同じものだと考えて構いません。

foldr (+) 0 a

としてみてください。結果は 10 になります。この場合は、foldl と foldr と書き換えても結果は同じになります。総和(sum、サム)を計算するロジックだと思ってください。

ここで、他の言語で総和を計算することを考えてみてください。恐らく、数行のコードになるかと思います。それが、学校で習う数式のようにシンプルに1行で表現できてしまいました。

これが、Haskell のリスト操作に対する強力さであります。

上の結果がなぜ 10 になるのかを説明するのは、今回の趣旨からそれますので、fold (+) 0 はリストの総和を求める関数ということを覚えておいてください。

zip, zipWith

zip(ジップと読みます)というと、一番最初に思いつくのは、ジップロックでしょう。または、人によって、チャック(zipper、ジッパー)のことと思うかもしれません。どちらも語源は一緒です。

zip というのは、2つのものを一緒にすることを短い単語で表現しています。

zip [1, 2, 3] [-1, -2, -3]

とすると、

[(1,-1),(2,-2),(3,-3)]

が返ってきます。

(1, -1)などは、タプルと言って、前にやったようにペアのことだと捉えていただければよいです。しかし、これでは、あまり、メリットが感じられません。では、zipWith という強力な関数を使ってみましょう。

zipWith (+) [1, 2, 3] [-1, -2, -3]

zipされた、ペアに対して足し算(+) が適応されると解釈してください。結果は、

[0, 0, 0]

になります。どうですか、ピンときましたか?

いよいよ

やっと、ベクトルの内積を計算する準備ができました。foldr と zipWith を組み合わせることで実現しそうですね。

まずは、ベクトルを Haskell のリストとして表現します。

let b = [1,2,3,4]
let c = [4,3,2,1]

そして、

let dot x y = foldr (+) 0 $ zipWith (*) x y

とします。掛けてから足し合わせる。これで、内積が求められますね。

dot b c

すると

20

できましたね!

手続き型の言語では、ループを最初にイメージして、配列から1つずつ要素を取り出して操作する習慣がありますが、Haskell では、リストを使って要素をまとめて扱うということをします。

こういった習慣や考え方のことをパラダイムと言ったりします。プログラミング言語をマスターするということは、まさにこのパラダイムを頭に馴染ませるということに他なりません。

参考書があるとすると、その参考書を二周三周するか、同様の書籍を数冊読みこなし実践するうちにようやくパラダイムが頭の中にできあがり、プログラミング言語をマスターするということになります。

今回はここまで。皆さんも諦めずに、どんどん自分なりに課題を見つけて取り組んでみてください。

モジュールの実装とユニットテスト

ysawa (澤良弘) — Tue, 08 Mar 2016 20:00:00 +0900

情報処理技術者試験も近くなって参りました。多くの方が必死に勉強されていることと思います。

今回は、モデルから一段階昇華させていきます。ちょっと難しいかもしれませんが、一部、試験の範囲になっているものもあるので、勉強がてら読んでみてください。

モデルのひとつの結晶、塊のことを「モジュール(module)」と呼びます。似た言葉なので、一度聞いただけでは、訳が解らないでしょう。

これは、化学に例えるとわかりやすいかもしれません。原子(atom)が、モデルだとするならば、分子(molecule)がモジュールと言えるでしょう。

ソフトウェアとモジュール

モジュールは、ソフトウェアの大事な構成単位です。モジュールが組み合わさってソフトウェアになります。ソフトウェアを構成するどのモジュールが欠けても、基本的にソフトウェアは動きません。

チームでソフトウェアを作るときに、プログラマごとに作成するモジュールを割り振ります。プログラマは、与えられたモジュールの作成に勤しみます。そして、それぞれ、完成したモジュールを組み合わせてソフトウェアが完成するという流れです。

ソフトウェア構築の詳しい流れは、共通フレーム2013に書かれています。一度目を通しておくとよいでしょう。

ユニットテストは書くべきか

基本的にモジュールでソフトウェアが構成されます。では、「きちーっと設計書通りモジュールを作りましょう」で基本的に議論が終了します。

でも、これで終わってしまったら、読者が怒り出すかもしれないので、もう少し深堀していかなくてはいけませんね。

最近、ブログやツイッターで困った議論が勃発していて、もはや炎上といっても過言ではないでしょう。その議題は、「ユニットテスト(unit test)は書くべきか」です。

ツイッターでの議論は、基本的に長く書けないですし、みんな他人事なので、まともなレトリックを使って書いているわけではないでしょうが、ひどいなと思うことが一つあり、後ほど述べていきます。

ユニットテストとは

ユニットテストとは、作成したモジュールの動作が正しいかどうかを、人間による目視でチェックするのではなく、プログラムによって判定する方法のことを言います。

モジュールへの入力に対して、こうあるべきだという出力をテストとしてプログラムします。そして、実行すると、記述したテストが順番に実行されていきます。テストに通ると緑色、通らないと赤色の点が画面に出力されていきます。

赤い点が、緑色に変わるまでモジュールを改善していきます。ここまでが、ユニットテストを使った開発手法の概要となります。

今のところメリットが多いように感じることでしょう。目視でのチェックがいらないですし、機械的にやってもらえれば工数が減るような気がします。

しかし、デメリットももちろん生じるのですが、これに関しては後述します。

二元論に陥る愚かなプログラマ

ユニットテストに関して勉強した後に、もう一度先ほどの「ユニットテスト書くべきか否か」の議論に戻ります。

世の中の議論には、二元論というのがあります。シンプルの極みである二元論というのはどのようなものでしょうか。

「人工知能によって仕事がなくなるか否か」「成功するにはポジティブであるべきか否か」「今日の昼飯はラーメンか牛丼か」「ラーメンならば、醤油か塩か」

こういう二元論に陥るのは、社会やプログラムを設計する人にとって非常に危険なことです。多様な社会や、プログラミング手法は、無限次元で構成されているはずです。それに対して、二元論というのは、一次元の議論です。二元論に陥るということは、「たったの1次元しか僕らは考えられません」と自分の能力の無さを露呈することになります。

第一線で活躍しているプログラマもこぞって「書くべきか否か」の二元論争に巻き込まれているのを見て、なんだか悲しいなというのが僕の感想です。

どうあるべきか

まず、いきなりユニットテストに目を向けるのでは落とし穴にハマる確率が高いです。もっと、高い視点で物事を見ていかなければいけません。

ソフトウェアは、通常作ってリリースしたら終わりではないので、数年から数十年のマイルストーンにおいてどのような運用をしていくかを考慮した上で、設計していかなくてはいけません。

その中で、ユニットテストがどの程度工数を掛けられ、どのような成果がでるのかを見極めなければいけません。ユニットテストは無償でできるものではなく、かならず工数に上乗せされるものです。そのコストに見合ったものになるかは、数年経たないとわからないかもしれません。きちーっと見積もる必要があるでしょう。

そして、ユニットテスト自体も運用していかなくてはいけないことを忘れてはいけません。仕様変更するたびに、ユニットテストの内容も変わっていくことでしょう。その度に、工数が掛かることを常に忘れてはいけません。

この時点で軽く数次元の考えるべき要素が頭の中で思いつくことでしょう。二元論に陥るとこのような思考はできなくなります。

ドライバとスタブ

ここで、ドライバ(driver)とスタブ(stub)に関して復習してみましょう。どちらもテストにおいて必要になる知識です。

作ったモジュールに対して入力して、出力を受けとるプログラムをドライバと言います。ドライバによってテストしたいモジュールを動かす(ドライブする)のです。ドライバによって入力した値が、モジュールを通じて変換され、適切に出力されるかを見ればよいです。

図式にすると、ちょうど、真ん中にテスト対象のモジュールが来て、周りをドライバが囲んでいるような形になります。このようにして、真ん中のモジュールが周りのモジュールと協調しあって動くことを確認できます。

次にスタブですが、ちょうどドライバと逆の概念になります。先ほどの真ん中のモジュールが仮の動きをスタブとして振る舞い、入出力を行います。

入力側のモジュールと、出力側のモジュールが完成している場合に、それぞれのシステムが協調しあって動くことを確認することができます。

図式もドライバのものとは逆になるでしょう。真ん中にスタブが来て、周りに作成したモジュールが配置されたような形になります。

テストをするには

ドライバとスタブの話をしたのは、ユニットテストでも使うからです。イメージしていただいた方にはお解りいただけたと思いますが、テストをするには、各モジュールの入力と出力が明確に定義されている必要があるということです。

入力と出力が定義されていないものは、ドライバやスタブによってテストすることができません。なので、テスト不能ということになります。入力に対して出力が曖昧なもの、または、頻繁に変更されるようなものは大変です。

例えば、Rails などのフレームワークでも、テストのための便利なライブラリを入れることができます。そして、関数やメソッドの動作チェックはもちろんのこと、ブラウザ上の UI を操作した時の挙動とかもチェックできます。とても便利ですね。

このように便利なライブラリがあるので、何でもテストに落とし込んでしまいがちです。しかし、UI の操作などの頻繁に変わるものや、ユーザによって表示が切り替わるものに関しては、よく考えてユニットテストを実装しないと後々大変なことになるでしょう。

ソフトウェア開発におけるコスト感

ソフトウェア開発において、一番大切なのはプロジェクトの成功です。ユニットテストを書くのは、あくまで一部でしかないということです。プロジェクトの成功のためにあえて、ユニットテストを書かないというのも一つの選択かもしれません。

期間、納期、予算、工数、人員、技術などあらゆるパラメータを考慮した上で、ユニットテストを書くべきかは考えるべきでしょう。そして、「なるべくユニットテストを書くこと」という曖昧なものであれば、基本的に、後々ユニットテストは運用されなくなるので止めたほうがよいか、仕様を満たすために作ってすぐ捨てる程度のものとして捉えたほうがよいでしょう。

ユニットテストを書く範囲に関して明確な指針をつくることです。設計書やタスクごとにどの範囲でテストを書くべきか・今後も運用するのかをきちーっと明記することです。下手に運用するとユニットテストが仕様変更に追いつかなくてプロジェクトが破綻するという事態に繋がります。

何事もメリットとデメリットのトレードオフによって成り立っています。それをきちーっと理解したうえで生活していきたいものです。

ではまた来週。

型から学ぶプログラミングその2

ysawa (澤良弘) — Wed, 02 Mar 2016 23:00:00 +0900

モデルを作成する前に、必ず通っていかなければいけないのが、型になります。

モデルは、物質の原子(atom)のように最小単位の集まりで構成されています。その最小単位が型になるのです。きちーっと型を選択し、プログラミングしていけなければ、すぐに使えないソフトウェアとなって捨てられるでしょう。

型を適切に選べることと、優れたプログラマであることは、かなり関連性があると思います。では、熟練プログラマと、未熟なプログラマを比較してみることで、型の大切さを考えてみましょう。

熟練プログラマ

熟練プログラマは、モデルの構成が上手なので、そのプログラムやソフトウェアは、バージョンアップがあったとしても修正は最小限となります。

モデルを構成する、適切な型を選択できるので、不正なデータが入る余地がありません。適切にデータを管理できるためにバグが少なく、ハッキングもされにくいでしょう。もし、修正があってもすぐに直すべき場所をみつけることができます。

結果として、仕事上のミスも少なくて、仕事をすればするほど、未熟なプログラマとの差が、クライアントや同僚に感覚として伝わっていきます。感謝や賞賛を受ける機会も多いでしょう。

未熟なプログラマ

未熟なプログラマは、モデルの構成が下手なので、そのプログラムやソフトウェアは、バージョンアップがある度に、大量のソースコードが改変されます。

Webアプリケーションであれば、アップロードのし忘れが生じたり、関係ないファイルを上書きしてしまったりしてクライアントによく怒られます。

モデルを構成する、適切な型を選択できないので、不正なデータが入り乱れるようになります。適切にデータを管理できないので、バグを直す度に新たなバグを呼んでしまいます。ハッキングもされたい放題。適切に直す場所が見つけられないので、回りくどい直し方をしてしまいます。

熟練したプログラマからすると、不快でもはや吐きそうです。熟練プログラマは、一人でやったほうが速いので、できることならプロジェクトから未熟なプログラマを外そうとするでしょう。

未熟なプログラマは、結果的に、仕事上ミスが多く、仕事をすればするほど、熟練プログラマとの差が、クライアントや同僚に感覚的に伝わっていきます。チーム編成を要求されたり、雰囲気が悪くなったりと、あまり褒められたものではないでしょう。

実務経験3年でいけるか

プログラマは、英語や中国語の勉強のように、とにかく身体で覚えることが大事という風潮があります。それは、一理あります。

履歴書に実務経験3年程度あるのとないのとでは、見栄えが違ってくるでしょう。業界的に、手を動かしている人が評価される雰囲気はやはりあります。

どれだけ、一流大学の計算工学科を出ているからといっても、就職する際は、経験や実績が見られるところでしょう。僕が、大学時代、アルバイトに応募した際も、実務経験が問われるところが多かったです。

しかし、アウトプットされるコードは、いつも背景となる知識に基づくものです。きちーっとした基準から生まれた設計やコードかは、ひと目で解るものです。

手を動かしていれば、熟練プログラマになれるかと言われたら、そうでもないというのが、僕の意見です。業務内、業務外関係なく、どれだけ、設計に関する思考を深められたかが重要です。

これを踏まえて、きちーっと勉強していきましょう。今回は、型に関して学んでいきましょう。

リスト (List)

リストは、次に述べる、配列やベクトルとは違って、長さが可変なものを格納しておくための型です。つまり、リストは可変長な構造を持っています。

長さが可変なので、扱うのは非常に便利です。値を追加する際は、末尾に付け加えるだけです。削除も、各言語の仕様や、自分で作成したリストの構造によりますが、基本的には簡単です。

便利さに引き換え、犠牲にしているものは、読込速度です。リストは、基本的に要素を前から順番に読んでいきます。最後の要素を読み取るには、要素数だけの回数検索を掛ける必要があるのです。

まとめます。リストのメリットは、追加、削除が簡単な点。デメリットは、検索にコストが掛かるです。このメリットとデメリットを覚えて次回から使ってみてください。

配列・ベクトル (Array / Vector)

リストの次に勉強するのは、配列、ベクトルです。配列とベクトルは基本的に同じなので、配列と呼ぶことにします。

配列は、基本的に、定義した時点で長さが決まります。すなわち、配列は、固定長ということになります。

リストに比べて、値を新規に追加する際は、配列の長さを伸ばさないといけません。削除は、配列の長さを短くする。これは、結構大変。配列は、定義した長さを変えることが基本的にないようにしなければいけません。

配列の値の操作は、基本的に上書きと読み込みのみになります。どちらも、リストと違って、コストは非常に小さいです。配列の長さによらず一定時間で取り出せるのが配列となります。

まとめます。配列のメリットは、読み書きのコストが掛からない点。デメリットは、配列の長さが変え難いということでした。

連想配列 (Dictionary / Associative Array)

連想配列は、値をキー・バリュー(key / value)で格納するための型です。

{ name: "ysawa", age: 29 }

は、JSON (ジェーソン) と言われる連想配列の一種です。name と age がキーです。 "ysawa" と 29 がバリューです。

連想配列は、辞書と呼ぶこともあります。辞書は、索引に対する定義や内容を調べるためのツールです。索引がキー、定義や内容がバリューということですね。

読み込みは非常に簡単、先ほどの連想配列に、name を投げると、

"ysawa"

が出力されます。

書き込みも簡単ですね。age に 30 を入れると、

{ name: "ysawa", age: 30 }

となります。

前回から扱っている、集合の中ではちょっと特殊な感覚がしますが、よく使う型です。PHP などでは、連想配列は非常によく用いられる型ですね。

連想配列は、キー・バリュー。これだけきちーっと覚えておいてください。

まとめ

まとめです。集合やペアから始まって集合的に値を扱うための型を見てきました。

全て特徴があり、適材適所だということがお解りいただけたのでは無いでしょうか。型というツールをきちーっと使い分けることが熟練プログラマへの第一歩となります。

熟練プログラマになれるように日々努力していただければ、これほど嬉しいことはありません。

型から学ぶプログラミングその1

ysawa (澤良弘) — Wed, 24 Feb 2016 20:00:00 +0900

前回まででモデルに関して勉強してきました。今回は、モデルを構成する最小単位とも言える型に関して勉強していきます。

ソフトウェアは、多くのユーザに対して同等の体験を提供するという役目があります。n次元では、「ユーザ体験は繰り返し」と言ったりします。

ソフトウェアのソースコードを見ていると、複数のユーザやデータを取ってきて、ループ(繰り返し)させるようなコードがよく出てきます。まさにユーザ体験は繰り返しなのです。

なので、プログラミングでは、複数の要素を集合的に扱うことが必要になってきます。集合的な要素を扱うことは、プログラマのスキルの中でも必須項目なのです。

この機会にきちーっと勉強していきましょう。

集合ってなんだったっけ?

集合というと高校時代、数学で出てきてアレルギーになっている人も多いかもしれません。

集合は、あまり受験でも重視されていないようで、「集合が出てきたら捨て問題」のように言われたりしてました。本当は数学の最も根幹となるような概念なのに残念です。

しかし、理解すべきことは実は非常に簡単です。集合というのは、扱う世界の広さを制限します。集合は世界の広さ・狭さだと考えてみてください。

ただ、集合は、広ければ広いほど良いというものではありません。

郡(ぐん・Group)、環(かん・Ring)、体(たい・Field)の様に集合を拡張することがありますが、この拡張は、より優れたものにするということを意味するわけではありません。集合の広さは、制限することで扱いやすくなったり、より面白く世界を開拓していけるものなのです。

例えば、同じ足を使うスポーツでも、サッカーとフットサルがあります。フットサルは、サッカーよりも狭いコートで構成されるスポーツですが、フットサルの方が面白くないとはならないでしょう。

狭いには狭いなりの面白さがあります。人数が少なく、コートが狭ければ一人ひとりの働きがより重要になったり、初心者でもボールに触れやすかったりするメリットもあります。

郡、環、体とある中で一番狭い集合を扱う、郡は、群論(ぐんろん)という数学の分野になって研究されています。また、体の中でも有限集合のみを話題を制限して有限体(ゆうげんたい、ガロア体、Galois Field)とし、こちらも非常に研究されています。

集合は、数学の定義の中の一部で、ルールなるものです。ルールを縛るからその中で楽しむことができる。集合という概念がなければ、数学はそもそもなかったでしょう。

桃太郎で学ぶ「集合」

僕と皆さんで桃太郎の演劇をやるとします。そのときに、まず考えるのが登場人物の整理ですね。桃太郎に出てくる登場人物は、次の6人(匹)です。面倒なので、今後、動物も単位を「人」とします。

A = { 桃太郎, おじいさん, おばあさん, さる, キジ, 犬, オニ }

ここから、オニ退治に出る人を取り出すと、

B = { 桃太郎, さる, キジ, 犬 }

となります。これを部分集合 (Subset) と呼びます。B ⊂ A と書きます。人や動物の全体集合を U とすると、 A ⊂ U, B ⊂ U となります。

ここで、重要なのが、A において、オニは何人かということはどうでもよいということです。実際は、オニは10人いるかもしれませんが、とりあえず、A では登場人物の種類のみに注目したということです。

ここで、数も一緒に考えた方が便利じゃないかと思う人もいるかもしれません。素晴らしい想像力ですね。もちろん、それは可能です。

A' = { { 桃太郎, 1 }, { おじいさん, 1 }, { おばあさん, 1 }, { さる, 1 }, { キジ, 1 }, { 犬, 1 }, { オニ. 10 } }

という形で管理すれば、なんとか人数とペアで、登場人物を管理できるようになりました。一見、こっちの方が便利な気がします。しかし、本当でしょうか。

もし、僕らの作った演劇のクライマックスがあまりにもしょぼかったら、さらにオニを追加したくなるでしょう。では、 A' に { オニ, 5 } を追加してみましょう。

A'' = A' ∪ { オニ, 5 }
= { { 桃太郎, 1 }, { おじいさん, 1 }, { おばあさん, 1 }, { さる, 1 }, { キジ, 1 }, { 犬, 1 }, { オニ. 10 }, { オニ. 5 } }

あれ、求める結果となんだか違うような気がします。これは、{ オニ. 10 } と { オニ. 5 } が異なる要素なので、別々の登場人物として認識されてしまったからです。

ここで、理解したいのは、今回の登場人物と人数の管理の仕方が間違っていたということです。前半は、登場人物の種類が把握できればよかったので、集合はすごく上手く機能してくれました。素晴らしいです。

しかし、登場人物と人数の管理に関しては、別の方法があったのではないでしょうか。経験の浅いプログラマは、概してこのような間違った設計を選びがちです。

知っている道具が少ないので、より適切なものがあっても気付かず、つい使い慣れたもので作業してしまうのです。解決方法は簡単ですね。道具の数を増やせば良いのです。

では、順番にその道具を見ていきましょう。

集合 (Set)

先ほどやりましたね。プログラミング言語として集合を扱う場合、同じものが入らないことを保証します。

A = { 1, 2, 4 }

としたときに、

A に 5 を追加すると、

A = { 1, 2, 4, 5 }

となります。

再度、 A に 5 を追加しようとしても、

A = { 1, 2, 4, 5 }

のままです。複数のユーザに対して、1回ずつ繰り返し体験を届けたいときに使いやすいです。ユーザIDを集合に入れていくことで、同じユーザIDは、集合に2つ以上入れることができないため、重複を防ぐことができます。

集合は非常に便利ですが、プログラミング言語によっては、使える言語は限られています。

ペア (Pair)

次に、ペアです。ペアは簡単で、2つしか要素を入れることができません。

(ysawa, ブロマガ担当)

とか

(Shun, 動画担当)

のように、2つを組み合わせてなにか情報を整理したいときに使います。

シンプル過ぎて、使う場面がないまたは使いにくそうな印象を受けますが、Lisp や Scheme などの関数型言語では、非常に重要な型になります。

Lisp や、Scheme では、基本的にペアを組み合わせて、次の節で述べるリストを構成します。ペアは、集合的な要素を考える基礎となっているわけです。

Lisp や Scheme では、ペアは、以下のように作ります。

(cons 1 2)

=> (1 . 2)

1 と 2をペアにしたわけです。それぞれの要素を取り出すときはこうです。

(car (cons 1 2))

=> 1

(cdr (cons 1 2))

=> 2

となります。car (カー) という関数、cdr (クドゥアー) という関数を使って取り出すわけです。

ペアと、次に述べるリストや配列を組み合わせると連想配列ができあがります。Haskell ではよくこの型を使います。

(Haskell ではペアという用語はなく、タプル (Tuple) というような有限個の要素を代わりに使います。)

続く...

長くなりましたので、また続きは次回!

動物園で学ぶモデル化

ysawa (澤良弘) — Tue, 16 Feb 2016 19:30:00 +0900

プログラミングにおける「モデル」の大切さ、モデル化の難しさを、前回話ました。今回は、モデル化を皆さんにできるようになっていただこうと思います。

もう一度、モデル化とは何か

まずは、おさらいです。

ある事象から、性質、動作、傾向などの特徴を抜き出し、抽象化することを「モデル化する」といいます。そして、事象をモデル化すると「モデル」になります。「ビジネスロジック」と言ったり。単に「ロジック」と言うこともありました。

モデルを考えるときには、物事を俯瞰(ふかん)することが必要となります。上から見下ろす感じです。地図を見たことがある人なら解るでしょうが、地域によって、碁盤目状になっていたり、まばらに民家が存在したりといった、特徴があることが解るでしょう。

このように特徴を掴むことがモデル化するための第一歩となるのですが、好き勝手に特徴を抽出したのでは、役に立つ物は作ることができません。やはり、ある程度トレーニングが必要となります。

モデル化のトレーニングをする上で、プログラミングのオブジェクト指向では、いきなり自動車やポットを持ってくることが多いのですが、最初にやるトレーニングとしては、高度すぎるかと思います。

最初のトレーニングでやると良いのは、パズル感覚でできる分類から初めてみるとよいです。分類をするには、特徴を必ず掴まないとできませんし、モデル化のよいエッセンスが含まれています。

動物園にいってみよう

では、実際に動物園の例で見てみましょう。

僕も先日、動物園にいってきましたが、実に沢山の種類の動物がいます。自然界に、なぜこのように多様性が生まれるのかは実に不思議ですね。

さて、今回は、「動物園で学ぶモデル化」です。動物園で会えるであろう動物をあげてみました。以下の動物をあなたなりに数個に分類してみてください。小学校とかで習うよくある分類でも構いません。

サイ
ニホンザル
白くま
ペンギン
ふくろう
ワニガメ
リス
シーラカンス
イルカ
サメ

このくらいでよいでしょう。用意するものは、紙とペンです。次の文章を読む前に、是非、手を動かしてやってみてください。

さっそく分類してみた

おそらく皆さんは、以下の様な分類になったのではないでしょうか。

哺乳類: サイ、ニホンザル、白くま、リス、イルカ
鳥類: ペンギン、ふくろう
爬虫類: ワニガメ
魚類: シーラカンス、サメ

このような分類ができた僕らは、学校で非常に優秀な学生だったことでしょう。なぜか、僕ら日本人は、この分類を軽々とできるようにトレーニングされています。しかし、その詳しい理由は不明です。ダーウィンの進化論が大好きな人が多いからでしょうが、この分類が役立つことはクイズ番組意外ではほとんどありません。

その証拠に、大学に入って生物学を勉強すると、上の分類は教科書や講義にほとんど出てきません。よく考えてみてください。生物としての特徴を把握するのに、この分類は不便ではありませんか。

よくあるミスとして、イルカを魚類に入れたくなりそうになります。その感覚のほうがモデル化を勉強する人にとっては正しいのです。彼らの住環境、食生活は、サメなどの魚類とあまり変わりません。

考えれば考えるほど、この分類が機能しないことが解るでしょう。困ったものです。

こういう分類もある

そして、より良く生物の特徴を掴んでいる人の分類は、以下のようになるかもしれません。

水中に住む: シーラカンス、サメ、イルカ
陸上に住む: ニホンザル、白くま、リス
空中に住む: ふくろう
水中、陸上両方に住む: ペンギン、サイ、ワニガメ

このように分類をすることで、より特徴を掴むことができるかもしれません。その他にも、食生活や求愛活動に関する分類もできるかもしれません。

住環境に関して分類してみたわけですが、住環境は、それぞれの生物の持つ「機能」にも、もちろん影響してきます。水中に住むには、「泳ぐ」という機能が必要かもしれませんし、陸上に住むには「歩く」とか「走る」といった前進するための機能が必要になるかもしれません。

このようにして、分類するトレーニングを普段からするようにおすすめしたいです。例えば、電車に乗る人は、時間軸や服装や格好でどのような分類ができるか。一見、全く関係なさそうな2人を同じ分類に入れるにはどのようにしたらよいかなどです。

このように分類しているうちに、自然に特徴や共通点に関して注目するようになっていることでしょう。実は、これが、僕の狙いです。

いきなり目の前のものをモデル化してといっても不可能なのです。全体から考えたら対象物はどのようなものなのかを考えるようにするのです。分類するためには、当然、対象同士の共通点に関して考慮しなくてはいけなくなります。

そのようにしているうちにもう、僕らは、モデル化できるようになってしまっているでしょう。

プログラマがすべきこと

プログラマがやらなければいけないことを簡単にいうと、世の中を便利にすることです。世の中を便利にするということは、将来のことをいっているように思えるかもしれませんが、それでは、今現在の飯代が稼げません。

もちろん、お腹が減っているからといって、ご飯を食べ続けてもいけません。今を生きつつ将来の世界を便利にするのがプログラマとしてのあり方です。

当然問われるべきは、今作っているものは、1年後にも使えるものか、もっというと10年後20年後も使えるかは常に考えるべきなのです。

そこで必要なのが、モデルです。今作っているのは、今必要な機能として、将来も必要とされるためには、最大限の広がりをもってモデルを作成すべきなのです。

将来使うか分からないような変数や関数をダラダラと並べていくのではなく、将来も使いやすいように、きちーっと分類してモデル化しておくことです。

例えば、動物園のチケットを扱うモデル Ticket を考えたとします。子供は200円。大人は500円と仕様が決まっています。僕らは、Ticket を設計する際に、子供なのに500円という値が入らないように保証すべきです。同時に仕様になくても将来的にシニアが入れられるように考えておく必要があります。

将来、キャンペーン・イベントなどをやったときに Ticket はどうなるのかも考えなければいけません。仕様にない場合も、プログラマとして気に掛けなければいけない問題となります。

モデル化はやっぱり難しい

先ほど、分類に関して学んでいただいたのは、分類は1つではないということを学んでいただくためでもあります。複数の分類がありますし、モデル化も1つの方法だけではありません。

哺乳類、鳥類、爬虫類、魚類という分類で、そのままモデル化して安心していると、すぐに、「哺乳類なのに、住環境は水中です」、「鳥類なのに飛べない」などの複雑な要件や仕様が追加・変更がなされていきます。

なにか、きちーっとモデル化が上手く言っているような気がしても、すぐに方向転換が求められることがあります。僕らのモデル化が間違っていたり、根本的に問題解決に繋がりにくいことがよくあるのです。モデル化がやっぱり難しい理由となります。

このような難しい問題には、分類やモデル化に関するトレーニングを積むしかありません。テクニックでは、なんともならない問題となります。

プログラマのよく発する言葉に、「気持ち悪い」「臭い」などの共感覚じみたものがあります。これは、将来も通じるモデルという視点で考えたときに、どう考えてもおかしなコードや設計だということから出る言葉です。なんだと言われても説明不能ですね。

まとめ

さて、プログラマがなぜ稼げるかというところに戻ってきますね。プログラマの仕事は、充実感がありますが、大変難しいものなのです。

モデル化を的確にできるプログラマは、いつの時代も重宝されるでしょう。日々、きちーっと努力していく。モデル化のトレーニングは、プログラマの日々の筋トレのようなものだと捉えてください。

プログラマはなぜ稼ぐのか

ysawa (澤良弘) — Tue, 09 Feb 2016 22:56:00 +0900

プログラマの年収は、平均してしまうと、それでも驚くほどでは無いのですが、知り合いのフリーランスプログラマなどは、驚くべき年収を誇っていたりします。年収1000万は、もはや当たり前なのではないでしょうか。

今回は、プログラマがなぜ稼げるのかを見ていきます。

稼げない日本のトップ大学生

僕は、学生時代のバイト先での時給が2,000円でした。日給にすると16,000円。頑張って月20日働くならば、月収32万円ということになります。実際は、103万円縛りや学業があるので、そうしなかっただけです。実務能力がなかった大学生の僕ですらそれくらい貰えたのです。能力と交渉次第ではいくらでも学生時代に稼げたのでは無いでしょうか。

医学部生、東大や東工大生のアルバイトといえば、基本、塾講師か家庭教師2択なのですが、基本的にあまりもらっていないでしょう。

俺は時給4,000円と声を大にして言っている人がいましたが、普通の学生は基本的に時給計算が苦手です。1コマ(90分)の授業(6,000円)のために3時間程度準備する人がいましたが、その時点であっという間に時給は均されて1,333円になってしまいます。

その後、生徒の質問攻めにあって、彼ら彼女らの時給は限りなく最低賃金に近いでしょう。時給4,000円はどこにいったのでしょうか。

インターンは違法?

お勉強のよくできる学生で、企業にインターンする人もいます。偉いことですが、日本の企業のインターンは、基本的に違法です。インターンというのは、アルバイトでも職業訓練でもないので、成果物を作ってはいけないのです。

成果物を作れないということは、営業活動もしてはいけないし、プログラミングなどで手を動かしてもいけないのです。お金がもらえるインターンがあるそうですが、それは、アルバイトと言うべきです。日本の企業のインターンは、基本アルバイトということが解りました。

では、インターンという名前が付いたアルバイトで、時給が出なかったらどうなるのか。最低賃金は、大体800円前後です。インターンという名前のアルバイトは、時給0円です。これは、完全に違法ですね。学生は、基本的に民法や労働基準法を読んだり勉強したことがないので、こういう話に簡単に騙されてしまうのです。

非常に残念ですが、世の中こういうことがまかり通っています。インターンという名前で企業として社会貢献をしているふりをしていますが、「インターン募集中」ではなく、堂々と「アルバイト募集中」と書くべきだと思います。

大学時代、完全に間違っている友人を説得しようと試みると、「でもさ。大企業もやっていて。インターンやっていると就職活動に有利なんだ」と言われるのですね。

彼らの論理は、法律よりも大企業です。もはや、インターンは、社畜の飼育所と化しています。

できる大学生は、プログラマのアルバイトか、すぐにでも起業して稼いでいってもらいたいものです。

プログラマがなぜ稼げるのか

重たい話を最初にしてしまいましたが、本題のプログラマはなぜ稼げるのかという楽しい話題に転換していきましょう。日本のトップ大学生に比べてプログラマはどうして稼げるのでしょうか。

まず、プログラマという職業を高い視点から俯瞰しなくてはいけません。プログラマというのは、単にプログラミングをしているという見方ではなくもっと高い視点で。

プログラマというと、訳の分からない言語を使ってずーっとパソコンに向かっている冷たい高給取りの様なイメージがするかもしれません。しかし、僕の知るプログラマの皆さんは、どうやったらもっと世界が良くなるのか、便利になるのかを一生懸命に考えています。

そして、現実世界と抽象世界を行き来できるのが、プログラマです。別の言い方をすると、具体化と抽象化が同時にできるということです。

現実世界は、抽象世界から演繹(えんえき)されて生まれてくる世界です。抽象的な世界を、具体化すると何らかの世界が構成されます。僕らが生きている現実世界はその1つです。

現実世界から抽象部分を取り出すこと、後で述べるモデル化が非常に上手なのがプログラマということになります。そして、抽象部分から現実世界に落としこむのをコンピュータにやらせるのです。

具体化と抽象化を同時にできるというのがプログラマの稼げる理由になります。高速に移ろいゆく世の中で、具体化と抽象化を同時にやることは、ほとんど離れ業といっていいと思えます。こういう仕事は非常に評価されるのです。

モデルとは

もっと突っ込んでいきましょう。プログラミングの話をするときに、欠かせないのがモデル化の話になります。

お解りかと思いますが、芸能人としてのモデルではありません。

ある事象から、性質、動作、傾向などの特徴を抜き出し、抽象化することを「モデル化する」といいます。そして、事象をモデル化すると「モデル」になります。別の言い方をすると、「ビジネスロジック」と言ったりします。単に「ロジック」と言うこともあります。

オブジェクト指向において、クラス、クラス化というのは、モデル、モデル化に対応しています。現実世界の構成要素1つ1つをクラス(人間、プログラマ、動物、ポットなど)に分けて考える方法のことをオブジェクト指向といいます。

モデル化に関して例を出してみましょう。古典力学で言うならば、物体を質点や剛体として捉えます。物体や物体の動きや働きが、事象、質点や剛体がモデルとなります。いろんな形の物体を、点や円といった硬い物質として捉えることで扱いが簡単になりました。

球体を斜め上に投げた時、放物線運動を描くというのも、実際の空気抵抗などを除いたからこそであり、これもモデル化の1つですね。

モデル化することのメリットは、より簡潔になるので、計算が楽になったり、より事象をすっきりと考えることができることです。より観察がしやすくなるというメリットも有ります。

もう少し他の例も見てみましょう。

化学では、1つ1つの原子を観察するのではなく、まとまった1mol(モル)の固体、液体や気体としてどのような反応や性質があるのかを観察します。

経済では、株価指標をはじめとする様々なモデル化がなされています。人々や企業を消費者、生産者などと抽象化するのもモデル化の一種です。このように考えることで、労働やお金の流れがより掴みやすくなるのです。

このように、特徴を掴んでより理解しやすい形式にすることをモデル化ということになります。

モデル化は難しい

プログラマは、抽象化と具体化を同時にやるから稼げるという話は先程しました。それに加えて、抽象化のプロセスの1つであるモデル化が意外に難しいというのが、プログラマの給料が高いという理由になります。

なぜ難しいか、どのようにやっていくのかに関しては、今回説明するとまた長文になるために、一旦ここで切ることとします。

モデル化に関して次回に続いて書いていこうと思います。モデル化は、プログラミングの中でも、すごく大事な要素で、単にキーボード叩くのが速いだけではなんともなんともならない部分です。概念をきちーっと掴んでいきましょう。

真の大学受験二次試験対策

ysawa (澤良弘) — Wed, 03 Feb 2016 20:00:00 +0900

2月です。私立大学の試験日が怒涛のようにやってきたり、公立大学の二次試験を控えているような時期ですね。
僕も、東京工業大学の過去問を解きながら、学生時代の自分を思い返しておりました。

受験生であった当時は、不安でいっぱいでした。心臓が張り裂けそうになるのを必死でこらえながら過去問題集を解いていました。おそらくこれを読んでいる受験生の方も同じような心境かと思います。

今回は、ちょっとでも不安が和らぐように試験対策に関して書いていこうと思います。試験対策講座ではありますが、受験対策中の皆様の邪魔をしてはいけないので、今回は、手短にまとめてみました。

受験にうかる思考法

もちろん、今まで一生懸命やったというポジティブシンキングはとても大事です。一方で、問題に関して言うと、今までやった問題は出ないという、ちょっとしたネガティブな思考が大事かなと思います。

中高一貫校で、小さい頃から勉強が好きで部活もやったことありませんというような受験生を除いて、問題の解く量には、やはり限りあります。なので、今までやった問題と同じものが出題される方が少ないです。

なので、出題に対して、いちいち驚いていたのでは、肝がいくつあっても足りません。では、どうするか。基本的に同じ問題が出ないと割り切ることです。

そして、今までやった問題と違うので、問題を見た瞬間にまず、具体例や簡単にして試します。3 の倍数 n と言われたら、3、6、9、12 を入れてみる。これで法則性を確認します。

化学だったら、知らない化学物質名が出てきても、化学で問われているのは、化学反応と物質の性質です。名前は無視して具体的に酸化還元反応なのか、酸塩基反応のなのか、色はどうなったのか。反応や性質だけをくみ取るのです。このようにして5分から10分くらい問題を眺めてみるのも良いでしょう。

ダメな例は、いきなり解こうとしたり、式を展開することです。問題作成者の罠にハマる人の特徴は、素直に解いてしまうのです。暗闇の中を突き進んでいる感じで、やればやるほど解ける気がしなくなってくるでしょう。

理系科目もまとめてみよう

文系科目は記憶力で、理系科目は思考力が問われているというようなことをよくいわれます。しかし、これは、大きく間違えているといわざるを得ません。

文系科目は記憶力というのを百歩譲って認めたとして、理系科目は思考力が問われているとします。すると、記憶が必要なくなるので、試験会場には教科書や参考書を持ち込んで良いということになります。しかし、ほとんどの大学では、持ち物には制限がかかっているでしょう。問題作成者や試験監督と先ほどの認識に矛盾が生じてしまいました。

矛盾を解消する方法はこれです。理系科目も、所詮、暗記科目だということです。化学なら、ベンゼンやエタンから始まる反応系統図を全て暗記していないといけません。数学なら、数列の一般項の求め方を全てマスターしていないといけません。

そこで、一度、理系科目の知識体系もまとめて覚えてみてください。まとめるときには、できるだけ大きなくくりでやるといいです。例えば、3年間で習った数列の一般項の求め方全てとか、平面や立体(図形幾何、三角関数、ベクトル、複素数平面、xy座標、極座標)などのようなくくりが好ましいです。

ダメなくくりも一応お伝えすると、数Ⅲ微分法のまとめ、化学反応式一覧などですね。単体で覚えても使えないので、図形の問題出てきたらどのようなツールで処理するのかというような視点で考えてみてください。

選択式であれば問題数の多い方を選ぶ

選択式であれば、基本的に、問題数の多い方を選ぶと良いというのは、先日お伝えした内容になります。

どうしても、時間が限られている場合や、選択式の大問の場合は、なるべく多くの問題が掲載されているものを選んで解きましょう。

問題が多いと、ミスに対する減点が小さくなったり、1問1問も丁寧で簡単な問題が多くなります。段階的に解く形式の場合が多いので、だいたい前の問題が次の問題のヒントになっているはずなので、ちゃんと流れについていくように考えて解いていきましょう。

大学の特色はやっぱり出る

東京工業大学は、極限や積分が大好きだったり、大阪大学の問題だとやたら計算が面倒だったり、名古屋大学は平凡な問題が多くでるというように、かなり特色がでます。

大学の先生も仕事片手間に問題作成をしているので、面倒はさけたいと思うでしょう。やはり、傾向を変えたりしてリスクを取る様にはあまり考えたがらないでしょう。できれば、同じような問題の量産でいきたいと考えるのが人間です。

過去問と同じ問題はほとんどでませんが、出題される問題の特色はほとんど同じになる。過去問題集を解きながら、問題作成者の意図までしっかりと掴んでいくことです。そして、当日は、しめしめやっぱり同じ特色の問題が出たか思いながら受験することです。

このようにして掴んだ思考法が必ず将来に役立ちます。常に裏を行く、逆張り(ぎゃくばり)思考を受験のうちからできるようになっていってください。

ここで終わります。受験生の皆さんきちーっとがんばってください!

Jumper (ジャンパー) って結局なに?

ysawa (澤良弘) — Tue, 26 Jan 2016 22:00:00 +0900

今までちょっと固めの話が多かったので、今回は、僕らのゲーム Jumper (ジャンパー) が生まれた理由に関して話していこうと思います。では、まずは、遊んでみてください。

Jumper iOS 版
 Jumper Android 版

Jumper ≠ ゲーム

Jumper はよく周りからゲームとして捉えられています。一応、アプリとしてのジャンルは、アクションゲームに値するのですが、何度かプレイしたユーザは、世界観の広さに気づかれている方も多いようです。

リリース以降数ヶ月のゲームで機能も非常にシンプルなものではありますが、100以上のステージを作成している作者がいたり、ほとんど全てのステージをクリアしている強者もいます。

他人のステージが簡単すぎたり、つまらなかったら自分で作ってしまえば良い。難しすぎれば、簡単なステージを作れば良い。そのようにして、日々、多くのステージが生み出されています。

これぞ、 Jumper のキャパシティの広さといえます。単にゲームとして考えるだけではもったいないです。

Creativity and Communication

Jumper には2つのCが思いとして込められています。まず、1つめは、Creativity (創造性) です。ステージのクリアの方法は1つでないことが多いです。沢山のルートから好きなものを選択できる魅力があります。また、多数の Jumper (キャラクター) の中から、好きな Jumper を選択してステージをクリアしていくのです。

そして、2つめは、 Communication (コミュニケーション) です。ステージを作ること自体も、他のユーザとのコミュニケーションの手段になりますし、コメント機能によってアドバイスしあったりするのも、 Jumper ならではの楽しみ方といえます。

2つのCが1つのアプリに備わっている。そのように考えています。当初から、あまり難しく方向性を定めず、創造性やコミュニケーションが円滑に行えるような設計をしてきました。

ゲームという視点よりも、むしろ SNS (ソーシャル・ネットワーキング・サービス)というような視点で設計や実装するように考えています。

Haskell で書かれた頑健性の高いAPIサーバ

そして、前に述べたようなアプリを作る上で重要なのが、インフラとなるAPIサーバです。APIサーバには、Haskell を採用しました。

Haskell は非常に強い静的型付けの言語です。あくまで傾向の話になりますが、動的型付け言語と静的型付け言語を比べたときに、静的型付け言語の方が開発コストは高くなりますが、運用コストは安くなります。

Haskell は静的型付け言語で、記述する文法もかなり制限の厳しいものとなります。これが幸いして、GHC コンパイラによってビルドが通る時点で、かなりバグの少ないソフトウェアとなります。ビルドができるということが、既に厳しいチェックを終えた後ということになります。

Jumper は、ゲームという性質上、不正を許してはいけません。不正を防ぐためには、暗号化の技術はもちろん、プログラム上のバグを最小限にしなくてはいけません。Haskell はそれに一役買っているといえます。

よくプログラムによっては、1ヶ所直すと、多数のバグが生まれてしまうことがあります。これは、プログラマが、物事の切り分けが上手くできていない場合に起こります。切り分けが下手ですと、これもあれもと、同じ関数に違う値を入れ込みたくなってしまいます。Haskell では、関数に入る型を明示しなくてはいけません。バグを生むような値が関数に適応されることは少ないのです。

ユーザ毎に違うパラメータも、先ほどお話した型を見ることでユーザ毎に異なるパラメータだと認識することができます。型によって、プログラマは注意すべき点をミスなく実装していくことができ、それぞれのユーザに同様のユーザ体験を届けることができるのです。

また、ゲームやアプリは、基本的には同じサービスの繰り返しになります。これを、n次元では、「ユーザ体験は繰り返し」という表現をしております。関数型言語の高階関数とLambda (ラムダ)によって、多数のユーザに同じ体験を届けるということが非常に容易になります。

やることは、ユーザの一覧を取ってきて、適切な高階関数と Lambda に投げるだけです。Jumper のシステムは、以上のように全体として非常にシンプルなものなのです。

Cocos2d-x で書かれた移植性の高いゲームアプリ

Jumper のスマートフォンの実装は、 Cocos2d-x によって行われています。Cocos2d-x のどこがよいかという話を致します。

Cocos2d-x はオープンソースのフレームワークで、世界中のプログラマがフレームワークのバージョンアップに日々貢献しています。そのおかげで、フレームワークとしての設計や実装が年々良くなってきています。

現時点では、Cocos2d-x プログラミングやフレームワークの扱いに習熟した人が、ひと目で理解できる設計になっています。洗練された設計によって、メンテナンスのコストは劇的に下がっていきます。

また、Cocos2d-x は C++ で開発されているので他の言語(C言語とか Objective-C、Javaなど)との親和性は非常に高いです。他の言語による成果を取り入れることが容易になります。これは、開発コストを下げるのに役立ちます。

これらのメリットを鑑みて、バージョンアップを頻繁に行いたい Jumper にとって Cocos2d-x 1択という結果になりました。

そして、なによりも

楽しく開発する。これに尽きるかと思います。創造性を最大限に高めるのには、どんなツールよりも楽しさが一番大事になります。

n次元は、3年目となり、事務所も一転。より快適に働ける環境を実現する工夫を日々取り入れています。受託会社ということで、リソースは100%避けるわけではありませんが、毎日楽しくやっております。

少しでも多くのアップデートを皆さんに届けられるように日々努力していきます。今後とも n次元及び Jumper をよろしくお願いします。

オレオレ詐欺はハッキングの一種? その3

ysawa (澤良弘) — Wed, 13 Jan 2016 20:00:00 +0900

大学入試センター試験が終わりましたね。受験された皆さんお疲れ様でした。結果が振るわなかった人は、ぜひ、東京工業大学を受験してみてください。

センター試験での脚切りはほとんど無いですし、二次試験対センター試験の得点比が他大学と比べて著しく高いのが東京工業大学の特徴となります。ぜひ、候補の1つにあげてみてください。

前回までで、情報処理推進機構(IPA)の情報セキュリティ10大脅威 2015の脅威4まで見てきました。

セキュリティに関してかなり展望良くなっているのではないでしょうか。それでは、続きを順番に見ていきましょう。

脅威5 ウェブサービスからの顧客情報の搾取

こちらは、利用者にはこれで全てと言えるようなセキュリティ対策はありません。SQLインジェクション、ディレクトリ・トラバーサルといった、Webサイトの管理者のミスによって生まれたセキュリティリスクなのです。

まず、Webサイト管理者はなにをすべきでしょうか。ライブラリ、ファイヤーウォール、そして、アプリケーションのフレームワークのバージョンアップを普段から心がけるべきでしょう。セキュリティ対策の基本ですね。

また、JPCERTなどが出しているメーリングリストに登録し、セキュリティに関する情報に常に目を通すことが大事となります。

次に、利用者側はどうすべきでしょうか。Webサイトによっては、閲覧するだけでマルウェアをダウンロードするものや、Flashなどによってマルウェアに感染させられるものがあります。Googleは、マルウェアに感染したサイトを教えてくれるので基本的には大丈夫だと思いますが、リンクやバナーを不用意にクリックしないように心掛けましょう。そして、ブラウザやFlashなどのプラグイン、ブラウザの拡張機能は最新のものを使うべきです。

そして、Webサイトでは、基本的に、メールアドレスとパスワードによる認証方法が多く、二段階認証やキャプチャなどのセキュリティレベルを上げる仕組みを取り入れていなかったりします。

前にもお伝えしたのですが、大手銀行は大体オンラインバンキングのためのスマートフォンアプリを用意しています。スマートフォンアプリは、Webサイトでは実装の難しいゼロ知識証明を取り入れることができます。ゼロ知識証明の中でも、特にチャレンジ・レスポンス認証は有名で、気の利いたエンジニアは、当たり前のように設計に取り入れるでしょう。

例えば、 Google Play に Android の時刻設定を狂わせて、アクセスするとアプリの一覧は表示されないと思います。Jumper のアプリも時刻設定を狂わせると、情報を取ってきたり遊ぶことができなくなります。これらは、チャレンジ・レスポンス認証に端末の時刻を含ませることで、暗号の強度を高め不正にアクセスしにくくしているのです。

結論になりますが、Webサイトとスマートフォンアプリがある場合、なるべく、スマートフォンアプリを利用するようにしましょう。もちろん、スマートフォンのOSバージョンやアプリも常に最新にすることを意識しましょう。

脅威6 ハッカー集団によるサイバーテロ

こちらになると、個人や組織ではなく、世界的な視野で考え、対策することが必要となってきます。

サイバーテロといってもイメージが湧かない人がいると思いますが、米国の SONY Pictures Entertainment(SPE) への攻撃を思い出してみてください。昨今起こっている、サイバーテロは、ハッカーのちょっとした遊びのような感覚を受ける人が多いかと思いますが、それは、まさに平和ボケといえます。

僕らは、日本の1国民として国家の防衛、特に、サイバーテロへの備えをきちーっとしていかなくてはいけません。

これから IoT の時代になり、ありとあらゆる機器がインターネットと繋がれていきます。すでに、エアコンがスマホで操作できるようになりました。今後、電気の使用量を自動的に解析してくれてベストな料金プランを提案してくれたり、電車の遅延の解決にクラウドが用いられるようになっていくでしょう。

ここで、今までの人だったら、どんな情報が抜かれるんだろうと不安になるところです。しかし、n次元チャンネルを読んでいる皆さんは、そこで止まってしまってはいけません。

便利さと引き換えに、日本は、どんどんサイバーテロの危険に犯されるようになっていきます。気をつけないと、知らず知らずのうちに国際テロの手先として、僕らのコンピュータやスマホ、ルータと言った通信機器が扱われて、足跡がついてしまう。

ハイスペックな機器は、更に巧妙なハッキングの手足となり、ロースペックな機器は、DDoS攻撃の手段とされるでしょう。日本が今後なんらかの戦争で敗戦した際には、国際司法裁判所でサイバー空間での戦争の戦犯として扱われるリスクすらあります。

結局、僕らとしてはどうすればよいのか。便利さと引き換えになっているものを常に考えることです。今後は、個人情報が抜かれることに怯えるだけでは足りません。あえて、ハッキングされやすい古い OS を使っている方は、その便利さになにを失っているのかをきちーっと考えるべきです。国家の安全保障も一人ひとりが担っている。そのように意識すべきです。

では、対策方に移りたいと思います。一番簡単な対策は、使っていない通信機器は、電源オフにすること。いちいちオンにする手間がかかりますが、常時オンになっている通信機器があれば、ハッキングされ、僕らが犯人に仕立て上げられる可能性があります。

例えば、僕の話ですが、旅行に行く際は、僕が家からインターネットに接続する可能性はゼロになります。基本的にスマートフォンからか、テザリングしての通信になります。家のルータとモデム、そして、それらを経由して通信するテレビなどの通信機器も不要となります。それらは、きちーっとコンセントを抜くことで電源を切ります。

本日(2016/01/20) JPCERTが、Cisco製のネットワーク機器の脆弱性が発表されました。オフィス用の機器でこれなので、家庭用のルータなどももちろん危険性をはらんでいることでしょう。以下に、JPCERTの発表の一部を掲載しておきます。

【4】複数の Cisco 製品に脆弱性

情報源

US-CERT Current Activity

Cisco Releases Security Updates

https://www.us-cert.gov/ncas/current-activity/2016/01/13/Cisco-Releases-Security-Updates

概要

複数の Cisco 製品には、脆弱性があります。結果として、遠隔の第三者が、

任意の操作を行ったり、サービス運用妨害 (DoS) 攻撃を行ったりするなどの

可能性があります。

ちなみに、Wifiルータは、ハッキングすると通信の有無に関わらず一発で室内に人がいるかいないか解ってしまいます。回折する電磁波の変化をWifiルータは読み取ることができるのです。Wifiルータがハッキングされることは、人の存在の有無をもハッカーに伝えることになるのです。

もし、武器を積んだドローンなどの無人機とこのようなハッキング技術が組み合わさったらどうでしょう。戦争で狙われるのは常に個人です。人工知能を搭載したドローンは、弾薬を節約するために、確実に人が居ることが解っている部屋を優先的に狙っていくことは容易に想像が付きます。

ちょっと怖い話になりましたが、サイバーテロは、もう少し身近に感じて、遊びやゲームとかと一緒にしないことが、セキュリティリスクを回避する第一歩となります。

まとめ

さて、脅威6まで見てきました。いかがだったでしょうか。本当のところ脅威10まで見ていくべきでしょうが、ここまで見てきて、次元の上がっている皆さんには、情報セキュリティ10大脅威 2015は、以前よりもさらに読みやすいものになっているのではないでしょうか。

本ブログや、情報セキュリティ10大脅威をより詳しく見て、セキュリティ対策に関する知識と知恵をつけていっていただけると、この上ない喜びと感じるところでございます。

一人ひとりが、個人の銀行口座を守るという視点から、集団を守る視点へ。集団を守るという視点から、国家を防衛するという視点を持てるようになると嬉しいです。

オレオレ詐欺はハッキングの一種? その2

ysawa (澤良弘) — Wed, 06 Jan 2016 19:00:00 +0900

前回、情報処理推進機構(IPA)の情報セキュリティ10大脅威 2015の脅威2まで見てきました。

基本的に脅威は、ソーシャルエンジニアリングなどのハッキング技術、そして、僕ら自身や所属する集団の甘さが根本的な原因でした。今回は、順番に残りの脅威を見ていく中で、僕らがどのような意識を持って日々を送っていくべきかを見ていきましょう。

脅威3 「標的型攻撃による諜報活動」

次は、「標的型攻撃」です。こちらも、脅威2と同じく、基本的に、個人ではなく企業や組織の話となります。

最近の例では、日本年金機構の個人情報流出事件がこれにあたります。この件は、マイナンバー法が可決する前で、非常に物議を醸し、「.exeファイルが危険」のような誤報に近いようなニュースが流れるなど世間を賑わせました。

同僚や取引先からのEメールを装って添付の実行可能ファイルを開かせる行為や、マルウェア(ウィルスなどの悪意を持ったソフトウェア)を含んだUSBメモリなどをフロアにわざと落として仕事用のPCに挿入させるといった手の込んだものもあります。

また、組織の中の多くの人が利用するWebサイトを改ざんすることで、悪意のある操作を行ったりさせたりするものもあります。

まず、脅威2と同じく、OSやソフトウェアのセキュリティアップデートを済ませているかどうかがポイントとなります。基本的にソフトウェアは最新の状態で利用することです。この対策は、全てのセキュリティ対策の基本となります。何らかのソフトウェアを古いままで使う場合は、どうぞ無断で侵入してくださいと言っているのと同じです。

次に、セキュリティ教育をしっかりと組織全体で行なうことです。そして、誰がいつどこで何をしているかをしっかりと記録に残すことで、組織の作業フローを管理します。その上で、漏洩の危険性を察知したり、より効率的で安全な手法を選択したりします。管理されていないカオスからリスクを取り除くことは、ほとんど不可能なので、教育をきちーっとおこなっていくことです。

話が脱線しますが、僕が学生のころ、授業のレポートなどはUSBメモリに入れて持ち歩いていました。ハエを媒介する細菌のように、USBメモリからコンピュータへ、コンピュータからUSBメモリへと次々と感染していくということが日常でした。ウィルス対策ソフトが検知できないウィルスだったのでしょう。同じコンピュータとUSBメモリを持つ全ての学生が気づかずに凶器を持ち歩いていたことになりますね。見事に標的型攻撃を受けていることになりますね。

脅威4 「ウェブサービスへの不正ログイン」

再び、個人も対象のセキュリティリスクに戻ってきました。不正ログインしてなにか操作をすることは、不正アクセス禁止法によって、法律で罰せられます。皆さん気をつけましょう。

まず、不正ログインを防ぐには、特に、異なるサイトで同じパスワードを使わないということが大事となります。Webサイトの管理者によっては、パスワードを十分な暗号化を施さずに保存している場合があります。悪意のあるWebサイト管理者は、不正にユーザのIDとパスワードを使って、他のサイトにログインすることがあるかもしれません。脅威2と関連しますね。

脅威2や脅威3に犯されやすい企業は、細かい権限の付与、不必要なID/パスワードの削除や、パスワードをこまめに変えることが非常に効果的だといえます。

しかし、企業と違って、個人は、パスワードを変えることで、パスワードの法則性がバレやすかったり、余計な情報を悪意のある第三者に教えてしまう可能性が非常に高いです。パスワードをこまめに変更することは、必ずしもセキュリティの向上に対して効果がないことを覚えておいてください。

そして、サービスによりますが2段階認証できるのであれば、不正ログインはほぼ防げるといっても過言ではないでしょう。ID/パスワードでのログイン方式の他にデバイスなどの情報を紐付けた2段階認証は、不正なログインの試行を検知することにも貢献します。ぜひ活用してみてください。

いずれの方法も、公共Wifiやトラップとして仕掛けらている無料で解放されたWifiなどのほとんど盗聴されているといって過言ではない環境でインターネットに接続することは、パスワードや認証方法を悪人に教えてあげていることと同じになります。

Wifi接続は、使っていないときには切ることと、接続設定をこまめに見直すことが必要となります。特にスマートフォンは、Wifiルータに近づくだけで勝手に接続するので、信頼のおけるネットワーク以外には接続しないように設定してください。

ちょっと話変わりますが、東京工業大学のコンピュータリテラシの一番最初の授業で、僕らが教官にさらっと言われたことを載せておきます。

「ハッキングなどをして出席履歴を改ざんしたり、他人のレポートを盗用するなどの不正行為は、現実の法律に則って処理させていただきます。」(記憶なので若干内容は異なる場合があります。)

つまり、東京工業大学の学生が、授業中に不正を犯した場合、逮捕される可能性もあるということをほのめかされたのでした。確かにこれぞ、コンピュータリテラシだなと思ったものでした。これから展開される授業への期待が高まった瞬間でした。

まとめ

長くなってしまったので、次回に続きます!

オレオレ詐欺はハッキングの一種?

ysawa (澤良弘) — Tue, 05 Jan 2016 20:00:00 +0900

SNSの発展によって個人情報の取り扱いに関して興味を持つ人も多くなってきたような気がします。

セキュリティに関する質問も徐々にn次元にも寄せられるようになってきましたが、何事も本質をきちーと掴んだ上でバランスよく施策を練っていかなければ意味がありません。クライアントの相談は、親身になって聞くものですが、つい「御社の現状だと無理です」などと言ってしまいそうになることも少なくありません。

セキュリティと聞くと、ウィルス対策ソフトやファイヤーウォールなどのツールの設定や構築をイメージする人が多いような気がしますが、本当に気をつけるべきは、そういうツールではないということを今回は理解していきましょう。

情報処理推進機構(IPA)の情報セキュリティ10大脅威 2015というのがあります。今回の話題はこれを読めば終わりというものです。

セキュリティリスクの最大の原因

上記の、情報セキュリティ10大脅威を読んでいただいた皆さんは解るかもしれません。セキュリティといえば、ウイルス対策をどうしたら良いとか、ハッキングされないためにサーバのセキュリティを強化するとか外部からの攻撃に対処することを思いつきがちです。

しかし、外部からの攻撃に対処するまえにもっと対処すべきことがあります。それは、自分を律すること。相手からの攻撃の前に、必ず、まず自分の弱さがあります。弱いから狙われるという様に考えないといけません。

組織に関しても同じことがいえます。セキュリティリスクを低減しようということであれば、組織全体のセキュリティに対する意識を高め、実践していかなくては意味がないのです。

オレオレ詐欺はハッキングの一種?

オレオレ詐欺(最近では「振り込め詐欺」といいますね)は、実は、セキュリティリスクを利用した詐欺、つまり、ハッキングの一種です。人の善意を悪用した詐欺などと説明されるのですが、実は、これでは、説明不足なのです。

オレオレ詐欺の本質を掴めないどうなるか。「皆さん十分に気をつけましょう」などのお茶を濁す程度になるか、具体的な詐欺の手法に対して、一対一の対応策を教わるだけになります。すると、詐欺の手法が進化したときに、更なる対応策を考えなくてはならず、結局イタチごっこになってしまいます。

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

まず、僕らの次元を上げていくところから始まります。オレオレ詐欺をソーシャルエンジニアリングの一種として次元を高くもっと広い分野として考えるのです。ソーシャルエンジニアリングとは、人間の表情の変化、行動の変化、ミスといったものを利用して、人の嫌がることをしたり、通常では得られない情報を得たりするハッキング行為です。

そして、オレオレ詐欺は基本的に人間の弱いところを利用して、銀行の口座内の預金残高を盗み取るという、ソーシャルエンジニアリングということになります。そして、実は、セキュリティリスクのほとんどは、ソーシャルエンジニアリングされやすさと密接な関係を持っています。

オレオレ詐欺の対策を1つ1つするよりかは、ハッキング、特にソーシャルエンジニアリングの対応をしていくのが実は近道ということになります。

ですが、今回は、ソーシャルエンジニアリングに関する議論は少なめです。あくまで興味を持っていただくために身近な例をあげました。さらに、広いハッキングに関してざっと眺めていきます。

では、実際の例を見ながら、ソーシャルエンジニアリングを含めたハッキングの対応を見ていきます。世の中には、どのような脅威が存在するのかを確認していきましょう。

脅威1 「インターネットバンキングやクレジットカード情報の不正利用」

まず、脅威の1ですが、問題を抽象化することが大事です。問題は、不正な人や組織に、個人情報が渡ってしまったり、必要以上の情報が第三者に渡ってしまっていることが問題となります。対策方法は、ズバリ、お尻の穴をきちーっと閉める。これだけです。

漏れそうなツールを極力使わないこと。そして、漏れたときにどこから漏れたかが把握できるのがベストです。

はじめに、インターネットバンキングです。お金をやりくりするのは、基本的に各銀行のバンキングに対応したスマートフォンアプリを使用しましょう。Webブラウザではなくて、アプリにログインして利用することをおすすめします。

銀行のスマートフォンアプリには、独自の暗号方式が用いられていたり、Webブラウザに存在するセキュリティリスクが無いことから、Webブラウザよりもセキュリティリスクが遥かに低いです。

やむなくWebブラウザを利用する際は、パスワードや暗証番号などが保存されない設定にすることと、URLを必ず確認することです。左上の鍵マーク(SSL認証の有効性)が緑色になっていることもついでに確認しましょう。

さらに、OSやブラウザなどのソフトウェアは、常に最新のものを利用するようにしてください。ウィルス対策ソフトを入れるよりも先にソフトウェアのバージョンアップをしてください。未だにWindows XPなどの古いOSをドヤ顔で使っている人が5万といるようですが、有事には国家的なリスクになるので、本当にやめていただきたいです。脱線しましたが、基本的に当たり前のことをきちーっとやっているかどうかが重要になります。

次に、クレジットカード番号の漏洩防止ですが、基本的に決まったサイト以外では、買い物や決済を行わないことです。もし、海外のサイトを利用する際も、必ず、 Paypal(ペイパル) などの名の知れたクレジットカード決済会社を利用しましょう。

僕は、中小零細企業の代表なので社会的信用が異常に低いです。クレジットカードを作ることが難しいですが、皆さんは恐らく、容易に新しくクレジットカードを作ることができるでしょう。永久年会費無料の限度額10万円程度の少額のカードを一枚持っておくと、不安なサイトでの決済もリスクを最低限にした上で行なうことができるでしょう。

ですが、いずれの対策も公共Wifiや、信用のできないネットワークを利用している場合、十分に注意して行わなければいけません。公共Wifiでの通信は、基本的に盗聴されているという意識を持つことが重要です。

つねにお尻から変なものが漏れないように、きちーっと閉めていくことが大事なのです。

脅威2 「内部不正による情報漏えい」

大企業になればなるほど、これは不可避になっていくでしょう。これの対策はかなり難しいと言わざるを得ません。就業規則を厳しくするとかえって悪さをする従業員が出てきたりするのが難しいところです。組織によって、対策や対応策が異なるので、一般的な議論のみで終わらせようと思います。

まず、具体亭は、ベネッセの個人情報流出事件です。数千万件の個人情報が漏えいしたことが話題になりました。ベネッセは、補償額として200億円を用意したといわれています。本当に気をつけたいですね。

対策方法としては、基本的に組織作りから始まります。情報のやりとりのしやすさと、セキュリティリスク軽減が常にトレードオフの関係になるので、上手に組織を構築していかないといけません。

具体的には、アカウント(カードキーやサービスへのログイン情報)毎に細かく制限を掛けることや、不必要なアカウントは削除するなどの対策が必要となります。また、どこで誰がなにをしていたかに関してをできるだけ細かく記録に残せるのが好ましいです。

次に、個人として、企業の内部不正による情報漏えいを防ぐ方法はあるのでしょうか。これに関しては、ないと断言できます。近年は、大学病院などを信頼の置けそうな(?)機関を中心に情報漏えいの事件がバンバン報告されています。しかし、漏れたときにきちーっとどこから漏れたのかを把握することができないかはいつも考えておきましょう。

僕がいつもやる方法ですが、住所の一文字を業と間違えて書くというものです。例えば、住所の建物名が、「エヌジゲンハイツ」だとします。信用のおけない企業に対して個人情報を提供する際は、「エヌジゲンハーツ」などと記入しておけばよいです。もちろん、誤例集はどこかに控えておいてください。

次回に続く

長くなってしまったので、次回に続きます。

n次元をなぜ設立したか

ysawa (澤良弘) — Wed, 30 Dec 2015 21:00:00 +0900

年末です。

「n次元をなぜ設立したか。」今日は、それに関して書いていこうと思います。

n次元の設立は西暦2014年1月24日です。決算は12月ということになります。つまり、年の瀬と会計の締めが同じということです。ここで、きちーっと気持ちの整理をして来年に向けての準備をしなくてはいけません。

n次元をなぜ設立したか

もちろん、「人類の次元を高める」ためということになります。偉そうに聞こえるかもしれませんが、ほとんどの問題は、次元が低いことから始まります。

例えば、資本主義では、資本の流れを社会の営みの中心として捉えて議論していきます。パラメータはあくまで1つ。お金です。他のパラメータを持ってくることは許されません。他のパラメータはお金との関係として表現されます。たった1つのパラメータから、人類は、カール・マルクスの資本論をはじめとする多様で複雑な議論をすすめることができましたが、ふとした時に、その複雑性、関係として表現された多数のパラメータの存在を忘れがちです。

裕福・貧困、(経済的)成功・失敗といったことに対して、一喜一憂するのは、やはり、次元が1。お金しかイメージできていないからです。シンプルでよいですが、他のパラメータとのバランスが非常に重要なのは、21世紀に生きる皆さんには、常識レベルで理解が進んでいることかと思います。

宗教?

また、もう一つ例を挙げましょう。これは、ある詐欺まがいの教育商材に掴まされている人とあった時の話です。

「澤さんは、世の中を何次元で捉えていますか? 3次元とか4次元とか応えるでしょう。4次元時空。そう、一般的には4次元ですね。しかし、私の師匠は、5次元目の値があることに気がついたのです。それがすごいんです。」と。

その話を聞いて、僕は、開いた口がふさがらなく、しばらく放心状態になりました。当時の僕では、彼を救うすべもなく、縁を切ることにしました。大学では数といえば常に無限次元に拡張するように考えさせられますし、符号理論ではガロア体上の値を数十次元で1つのまとまりの情報として扱います。たったの5次元でよければなんと楽な哲学(宗教?)だと感心したものでした。

4次元時空に暮らす人は、正直、先ほど述べたようなビジネスマン向けのセミナーで騙されたり、不便を余儀なくされることも多いでしょう。危険なので、できれば、4次元時空を越えた世界に生活するようにしていきたいです。

低い次元の仕事は見事になくなっていく

足が速いという1次元の存在である飛脚はトラックに仕事を奪われましたし、忍者も飛脚よりは次元の高い存在でしょうが、ソーシャルエンジニアリングをはじめとする様々なハッキング技術によって仕事を奪われました。

味が美味しいと言われるラーメン屋もラーメン次郎のような苦しい体験を伴うような次元の高い飲食店には敵わないでしょう。電話ができると言われていた携帯電話は、スマートフォンにほとんど置き換わっています。スマートフォンは、PCでできることのほぼ全てをこなし、携帯電話を凌駕しました。

それぞれの事象を眺めると、最初に生まれた商品は皆、シンプルな設計のもとに作られているということが解ると思います。シンプルな設計を極めている。しかし、次に生まれるシンプルでない下位互換の商品に残念ながら負けてしまっているのです。

こう考えると、なにかを極めるというのは、実は、現代の世の中で非常にリスクのある選択といえます。何かを極めるというのは、たいてい、低い次元のパラメータの中での値を上げていくということになるからです。自分よりも他人やロボットやその他技術が勝る可能性があるスキルを高めるというのは、本当に人生の中でやりたいのかをもう一度考える必要があるかと思います。

ミニマリスト、断捨離といった言葉が、昨今大変流行っておりますが、実際、世の中どのような商品が流行っているか、または、生き残っているかはもう一度よく考えたほうが良いと思います。

我々エンジニアやプログラマの世界を考えても、数学のできないエンジニアや、何か特定のフレームワークや言語しか使いこなせないプログラマは、今後、生き残ることはできないと思います。ひと目どういう人が重宝されるのかを考えてみてください。

次元を高めるために

次元を高めるために、一番簡単なのは、数学を勉強することかと思います。大学で勉強する線形代数を勉強すれば強制的に無限次元の思考ができるようになります。残念ながら、高校までの教育課程では、精々3次元までしか扱わないので、勉強すること自体、あまり意味がないかと思います。東京工業大学の生協に行って数学の教科書をお買い求めください。

そして、あと言うならば、英語を読めるようになると楽です。これには、理由があって、日本の電子書籍化が非常に遅い点が挙げられます。EPUBやテキスト形式以外の読みにくいフォーマットが強要されることが多いのもいただけません。日本語だけでは、得られる情報量に制限が掛かってしまいます。最近出版された英語の本は、ほぼ全てと言っても過言ではない程、電子書籍化されています。英語の読解が身につくでしょう。電車やトイレの中といった細切れの時間を有効に活用して世界中のソースを読解することができるようになります。

また、東京五輪、TPPによって英語力の必要性は年々高まる一方でしょう。なので、しばらくの間英語のできるひとは凌ぐことができます。しかしながら、安心してばかりはいられません。東京五輪が落ち着く頃には、機械翻訳の精度が上がって、また、翻訳者への需要がまた下がっていく一方かと思います。やはり、英語プラスアルファ。次元を高めていく必要があります。

n次元として

受託開発会社としての n次元は、今後、動画制作事業、教育事業も、別の次元として捉えて大事に扱っていきます。1つの会社として、どれだけ多様な次元をお見せできるかに挑戦して参ります。

受託開発事業は、まず主力の事業で、こちらが無いとお話になりません。僕らの生命力は受託するからこそ成り立っています。売上をきちーっと確保してまいります。

そして、動画制作事業ですが、Shun が一生懸命やっているものです。こちらも欠かせられません。Jumper そして、 n次元の次元の高さをいかに効率的に配信していけるかが焦点になります。

最後に、教育事業です。このブロマガを含めて次元を高めていくためのレクチャーを来年も引き続きやって参ります。多忙にかまけてなかなかなすことのできなかった、プログラミング講座を始めることがまず第一歩だと考えております。

来年もきちーっとやっていくために年末年始もしっかりと知識・知恵の蓄えをして参ります。

どうか、来年も引き続きよろしくお願いします。

受験対策法「験担ぎはダメ。ゼッタイ?」

ysawa (澤良弘) — Tue, 22 Dec 2015 20:00:00 +0900

平成27年度の情報セキュリティスペシャリスト試験に受験しました。この試験は年2回、春期と秋期があるのですが、春期は忙しすぎてほとんど対策できず、残念な結果になってしまいました。2度めの挑戦でようやく勝利を勝ち取りました!!

ああ、清々しい!!

さて、受験のシーズンもやってきたので、過去を振り返ってみて、受験前または試験中はどのように過ごしたら良いのかを考えていこうと思います。今日は、特番で、非会員の方もほぼ全てのコンテンツが読めるようになっています。

中学、高校、大学受験、そして各種資格試験を受験予定の方は是非、参考にしてみてください。

1. 直前対策講座は危険

各予備校や塾、学校でやっているような直前対策講座と名をつけた授業は一切受ける必要はないです。必要がないばかりか有害なので棄権することをオススメ致します。

直前に知らない知識がでてきたりすると不安になるだけなので、家で過去問を解くか、今までやったことの復習をしていくことでしょう。

また、前日から一週間は、風邪を防ぐためにも、多くの人が出入りする環境からはできれば身を遠ざけたいところです。マスクをするとか、予防注射を受けるとか納得できるかたちでの健康の対策も合わせて行っていきましょう。

2. 試験前日の過去問対策は危険

直前にするのは、基本的な知識の確認。それくらいしかありえません。あくまで自分の今までの努力を確認するようにざっと知識を整理する程度にしていきましょう。

過去問は少なくとも前の週くらいにやるべきです。計画的に時間を作って1ヶ月くらい掛けてじっくりと対策をしてください。過去問を直前に解くというのは脳の使い方がかなり下手な人かと思います。

こちらも、前日に知らない知識がでてくると不安になるだけなので、今までやった問題や知識の復習をきちーっとおこなっていくことです。前日にやれることは限られていますので、貴重な時間を過去問で潰すことのないように気をつけてください。

3. 験担ぎは危険

験担ぎ(げんかつぎ)はやってはいけないものの最たるもの。弁当にカツ、れんこんを入れたり、某チョコレートを食べるというような種類のもの。あと、栄養ドリンクを飲んだりするのもほぼこれに含まれます。

いつも通りの力を発揮することが試験では重要です。普段と同じものを食べて、正常な精神状態で試験には取り組むことが勝利への近道となります。普段とは異なる験担ぎは絶対にやってはいけません。

ちなみに僕は、今回の試験でいつも食べ慣れているハンバーガーを選択しました。あと、人混みがあまり得意ではないので、混んだ店をなるべくさけ、歩いてでも受験生の少ない店を選択しました。試験会場の周りは、受験生だらけでどの店も混んでいるので注意です。

栄養ドリンクは、カフェインが含まれているのと、クエン酸回路を回すためのビタミンB系と大量の糖が含まれているので一時的に集中力が高まった気になります。しかし、飲用する習慣がない人は、急に高まった集中力を活かすことができないでしょう。カフェインの利尿作用によって、トイレが近くなるのも受験では問題になります。

お守りも普段から所持して眺めているような状態であればよいですが、普段からお守りに縁のない人が当日だけ握り締めるのは、かえって試験が始まることを意識して要らぬ緊張が芽生えるので止めたほうがよいです。また、受験会場の狭い机の上においたり、筆箱のなかに入れるのはかさばるし、落とすリスクや怒られるリスクもあるので本当にオススメできません。

あと、大学受験などでは、校門前で応援と題して、将来の先輩、塾の先生、不動産屋がチョコレートなどのお菓子とビラを配っている場合があります。親しい人のものだったらよいですが、もらっても絶対に口をつけてはいけません。受験の大事な日になにかあっては困るので、自分のお腹のセキュリティもしっかりと保守してください。受験の日は、持ち込んだ弁当または学食での食事のみにして余分なものは摂取しないように心掛けましょう。

4. 問題数が少ない大問は危険

次に、試験中の話になります。試験中になったら完全に自分との戦いになりますね。問題を解く優先度を試験以前に決められば一番良いのですが、傾向が変わったり、得意だと思っていた問題が急に解けなくなったりと困ったことが起こるのが試験。ある程度の臨機応変さが必要となります。

解く問題を自分で選択できる形式の試験(大学入試センター試験数学、情報処理技術者試験など)において、問題数が少ない大問を選ぶのはあまりオススメしません。問題数が多いと解くのに疲れるし、効率も悪いような気がします。でも、よほどのメリットが無い限り、問題数の多い方を選ぶようにするとよいです。

まず、問題数が少ないということは、1問に対する難易度が高く配点も大きいです。1度のミスが大きなダメージとなります。問題数が少ないということは、直前のミスに気づくチャンスも少ないということ。

それに引き換え、問題数が多いということは、1問に対する難易度は相対的に低くなることが多いです。(これは、試験時間を平等にするための問題作成者の善意があればの話ですが。)また、問題を解くなかで、途中でのミスにも気付きやすくなります。マーク試験の場合3桁のはずが2桁になってしまっているなどの計算ミスに気づける可能性が大いにあります。

最後に、点数調整の話をします。これは、採点官の心理も入ってくる場合もあるので、あまり全ての試験に通用する話ではありませんが、試験には多かれ少なかれ含まれているということを知っておいてください。ぱっと見で、簡単そうな問題を選択する受験生はどうしても統計上多くなりますね。そして、記述式の試験の場合、マーク式と違って、ある程度採点した後に、部分点の基準を調整することがあります。採点する数が多ければ多いほど裁かなければいけない量が多いので、部分点の基準もやはり厳しくなる傾向がどうしてもでてきます。比べられる人が多いので厳しくなるのは当然ですね。

大学受験の小論文では、クレーム、ワラント、データをちゃんと組み立てられるかどうかはもちろん問われますが、他の受験生が解答しない方向性の主張を組み立てることができれば最高です。同じ様な主張は、やはり、採点する側も飽きてくるのでどうしても厳しくなりがちなのです。

ちなみに、僕は、今回の試験にて、問題数の多い方を選んだのですが、答えられない問題もあったのですが、ダメージを最低限にすることに成功しました。試験時間的には厳しい戦いになるかと思いましたが、良い選択だったと確信しております。

5. 得意だと思う分野ほど実は危険

情報技術者試験では、プログラミングを使う問題を多く含む大問が存在します。受験者には実務経験のある人が多いと思うので、やはり、プログラミングを使った問題を選択しがちです。ですが、盲目的になってしまっていないかに注意してみてください。

ぱっと見である分野の問題だと思って解いていったら、問題作成者が聞いていることは実は違うということが多々あります。盲信しているとドツボにはまって絶対に解けないということがあるのです。方針が決まっているということが無い限りあまり得意不得意を考え過ぎないほうがうまくいくことが多いです。

例えば、情報試験の場合、60点が合格点です。得意分野が30点分しかなかったときに残り30点分取る自信があるかという話になってきます。そして、その30点がきちーっと取れればまだよいですが、得意だと思っていたが、あまり振るわなかったときのショックは大きいですね。

まとめ

情報技術者試験を受けた感想としては、山を張らずに参考書を一通り覚えている必要があるという印象を受けました。試験としての完成度は非常に高いと感じます。今までは、正直、この手の試験を敬遠しておりました。しかし、今では、自らの知識・技量の再確認、そしてそれらを磨き直す良い機会かなと捉えております。

資格不要論が世の中を覆っているような状況ではありますが、受験や資格の勉強は、ある一定以上に知識レベルを上げていくのには、手っ取り早い方法かと思います。そして、努力して合格を勝ち取ったときの充実感は本人にしかわからないものがありますね。本当にいいものです。

ここまでになります。では、受験生のみなさんきちーっと実力を出していってください!!! そして、験担ぎはダメでしたが、終わった後に美味しいものをいただきましょう。

ありがとうございました。

東工大の女子学生の生態系

ysawa (澤良弘) — Wed, 16 Dec 2015 23:00:00 +0900

前回、2つの要素が等しいか否かということに関して議論してきました。今日は、等しくない場合の話、2つの要素がどれくらい異なるのかに関して議論していこうと思います。

誰かに近づきたい、何かを達成したいという目標があるとき、その目標と自分との違いを知ることが非常に重要になってきます。前に、人生の生命時間を計算しましたが、目標に対しては、きちーっとした計画を立てて最短時間で達成できるのが一番よいです。

いきなり議論を進めていく前に、僕の学生時代の話をしようと思います。

東工大の女子学生の生態系

学生時代を思い返すと、東工大生(東京工業大学の学生)の特に女子学生は、目標を定めたときの努力の最適化が半端ではないほど上手かったです。まず、前提として、東工大の男女比(pdf)がここから見られます。ご参照ください。学生のうち、約1割強が女子学生ということになります。(注: 東工大は男子校ではありません。)

約1割しかいない男女比は、男子学生のもて悩み種。しかし、女子学生はどうか。女子学生は、いつも学年3番以内の勉強のできるイケメン男子学生の周りにいて、だいたいみんなよくできる。僕を含める一部の男子学生のように、女子学生は落ちこぼれない。口癖はいつも「(テスト勉強が)やばい。やばい。」で、勉強のできる男子学生ホイホイのできあがりですね。

やっぱり、理系大学の生態系のなかで、培った地位、まさに、ニッチ(niche)。

世の中ポジティブシンキングとか言われていますけど、彼女たちには当てはまりませんね。彼女たちは、ちょっとネガティブ、「ちょいネガ」とでもいいましょうか。「やばい」ということが生きる目的関数の最大化です。

上の例では、女子学生が、勉強のできるイケメンというわらじを吐いて、よく勉強ができるようになっています。自分だけで勉強していると「やばい」ということが解っている。目標と現在地の違いがよく解っているんですね。そして、目標と現在地の違いが解っているからこそ、戦略を練ることができる。僕のようにポジティブシンキングでいって華々しく散るか、女子学生のようにちょいネガで行って成功するかです。

では、目標と自分との違い、つまり2つの要素の違いはどのように測っていくのかです。結論から言ってしまうと、基本的に用いるツールは2つ覚えておけばよくて、距離関数を使うか、内積を求めるかです。後者に関しては、長くなってしまうので、また今度。今回は、前者の距離関数で2つの要素の違いを求めていきます。

距離関数

距離関数といっても様々な関数を作ることができます。適切な関数を構成するか選択できるかでないと、当然、僕らの目標までの距離を求めることはできないわけです。周り見回してみてください。結構、変な距離関数持っちゃっている人いると思います。

きちーっと定義を知ってから距離関数を見ていくことにしましょう。

まず、距離関数は、2つの引数 x, y ∈ X(ある集合のなかの任意の2つの要素) を取る関数で、 d(x, y) と書きます。関数を評価すると実数が返ってきます。つまり、距離を実数として評価するのが距離感数です。

次に、細かい定義が4つ続き

1. 非負性: d(x, y) ≧ 0
2. x = y と d(x, y) = 0 は同値
3. 対称性: d(x, y) = d(y, x)
4. 三角不等式: d(x, y) + d(y, z) ≧ d(x, z)

(ただし、x, y, z ∈ X)

が成り立つことが d(x, y) が距離関数であるために必要です。順番に説明すると、まず1です。非負性というもので、距離はマイナスになることはありません。2は、当然同じだったら距離も0というもの。距離が0だったら、当然同じですよね。3は、ひっくり返しても同じだよね。4は、中学と高校でやるはずです。三角形を書いて考えてみてください。

3に関しては、当たり前と思う人多いと思いますが、注意が必要です。例えば、恋愛に関していうと、自分から相手を見て距離は小さいと思っていたとしても、相手から自分は距離無限大という時があります。僕らの考えている恋愛に関する距離は必ずしも距離関数を構成しないのです。

マンハッタン距離

大学受験の塾講師が生徒に対して受かりそうか否かを判定する簡単な質問がいくつかあるのですが、「絶対値とは結局何?」というのがその1つです。

絶対値ってなんでしょうか。考えてみてください。

答えられない生徒は論外として、受からない生徒は「マイナスをプラスにした」と答えます。では、どう応えるべきなのか?

「(与えられた値の)数直線上における原点からの距離」というのが模範解答になります。絶対値は距離を求める関数という感覚が無いとこの世の中はもちろん受験でも生きていけません。距離を求める最も簡単な関数が絶対値です。

そして、マンハッタン距離というのは、絶対値(||)を利用した距離関数です。定義(2次元空間の場合)は簡単です。

を2次元空間の中の点として、マンハッタン距離は

となる。

これは、碁盤目状の道路を歩いて家から職場に行くときの距離というイメージができるかと思います。横に何マス歩いて縦に何マス歩くのかという話です。簡単ですね。こちらは、何次元でも使うことができます。

プログラミングの世界では、演算のコストが低いので、よく用いられる方法です。この点では、次のユークリッド距離よりも優れています。今後とも使ってあげてください。

ユークリッド距離

距離と言ったら、これでしょう。ユークリッド距離は皆さんが親しんでいるものです。地図座標における直線距離とか言うのがこれですね。

見難くてすみませんが、ピタゴラスの定理を使った p1 から p2 の求め方になります。こちらも、何次元でも使うことができます。

ゲームなどで、厳密に距離を図りたいときは、これを使います。ですが、単に距離の比較の場合、二乗根(ルート)の計算は無駄な場合が多いので、二乗和を用いることも多いです。この場合、三角不等式が成り立たなくなるので、距離関数ではなくなりますが、テクニックとして知っておいてください。

もちろん、計算を楽にするためには、ユークリッド距離ではなくて、マンハッタン距離を採用できるのであれば、その方が良いです。ユークリッド距離はいつでも万能ということはありえません。距離と言われると何でもかんでもユークリッド距離を思いつく人は注意してください。

ハミング距離

ハミング(Hamming)距離というのも重要な距離です。書き言葉、話し言葉において差分の大きさを取るための簡単な方法がハミング距離となります。

例えば、

「あいうえお」と「あいうえお」のハミング距離は 0
「あいうえお」と「かいうえお」のハミング距離は 1
「あいうえお」と「えぬじげん」のハミング距離は 5

のようにハミング距離は簡単に求められます。ハミング距離が1の情報は、ハミング距離が2の情報よりも間違いが少ない正確な情報ということになります。間違いが少なければ、ひょっとすると元の情報に戻せるかもしれません。

これを応用したのが符号理論で、通信における多少のハミング距離を情報の誤りの程度として、誤りを検出したり訂正できるようになったのが今の世の中であります。符号理論は、n次元の得意とする分野でもあります。

グラフ距離

人同士の距離を測るのに便利なのがグラフ理論におけるグラフ距離ですね。中学高校で勉強したxy座標を図示するためのグラフではなく、ノード(点)と点をエッジ(線)で結んだものをグラフと言います。

ノード間のエッジの数を数えたものがグラフ距離となります。距離が小さいと関連性が非常に高く、近いということになります。

SNSでは、人同士をグラフのノード、友達関係をエッジとして管理しています。自分の友だちを検索するときは、距離1のノードを検索し、友達の友達は距離2のノードを検索することになります。自動車のナビも有向グラフというものを使って、最短経路問題の部分最適解を求めるように作られています。

グラフ理論におけるグラフ距離は、現代の世の中に無くてはならないものだということがお解りいただけたのではないでしょうか。

まとめ

いくつかの距離関数を順番に見てきました。これで、目標までの距離を測るツールを教えることができました。ここに上げたものは、現在の世の中を構成する距離として重要なものばかりです。なので、しっかりとマスターして使えるようになっていただければ幸いです。

数学ができないと損する

ysawa (澤良弘) — Tue, 08 Dec 2015 18:00:00 +0900

中学校から高校、大学で数学を勉強した方々は、おそらく数学が理解できることの恩恵を得ていることでしょう。もし、ないとしたら相当ネガティブシンキングか、今までの時間的投資を回収しようとする意志のない人ということができるでしょう。非常にもったいないことです。

こういった、時代錯誤のテストもあるので、数学とは何かをきちーっと捉えていかないとドツボにハマってしまいます。計算問題は、計算機にやらせればよく、研究者に計算問題を解かせてはいけません。なぜなら、間違えるから。研究者の脳のなかは、計算問題を解くために最適化はされていません。計算問題は素直に計算機に任せて、もう少し、資源を有効に活用した方がよいのではないでしょうか。

同じか否か

数学を定義しようと思うと大変ですが、基本的に次のようにまとめればよいのではないでしょうか。

『定義から、導かれる定理を探求する学問』

です。決して、計算問題だけが数学ではありませんし、高校までの数学は、ユークリッド幾何学を前提とした話が進んでいきますが、本来なら天下り式に与えられるものではなく、定義は自分で選ぶべきものなのです。定義を選んだ先に広がる世界を探求するのです。

自然数Nは何たるかを定義した時に、Nの中で成り立つ定理を探します。また、Nを拡張した整数Zでは、どのような定理が成り立つのかを考えていきます。

探求する定理の中でも重要なのが、何か2つのものを持ってきたときに同じか否か。違うのであれば、どのくらい違うのかということです。2つのものを比較するということです。数学は、比較するためのツールを豊富に用意してくれています。

恋愛・結婚における数学

では、例を交えて見ていきましょう。

女性が男性を判断するときにATMか否か(Yahoo!知恵袋)で判断するようです。女性が男性を判断するときに、使用する評価関数 f があるようです。この f はどれだけ、男性がATMかどうかを評価する関数です。

f(a) ＞ f(b)

但し、a, b ∈ 男性の集合

が成立するときに、aは、bより優れている。より恋愛したい結婚したいと判断するわけです。

実際に、なぜこのようなことをするのかが大事です。a, b は、男性の集合の要素なので、直接、

a > b

のように比較することはできません。男性同士は直接比べることはできないので、男性の要素から実数を導く評価関数 f を作って、導かれた値同士を比べるようなことをします。

好む好まざる、意識するしないに関わらず、人々は、このような演算処理を脳内で瞬時におこなっていることでしょう。また、年齢と共に、学習をすることで、評価関数 f は大きくなったり小さくなったりします。この時点で評価関数は、2変数関数 f(x, t) と言えます。実際は、人が人を評価するときには、多次元ベクトルを扱う関数または、多変数関数となるでしょう。

今の株価は適切なものかは様々な株価指標をもって知ることができるでしょう。転職をしたことがある人は、自分の年収は適切かを割とよく理解できているかと思います。つまり、自分自身を年収で評価することができる。原油の値段に関心がある方は、時系列の中で世の中への影響を評価することができる。

評価関数がない、または、誤った評価関数をもっていると大変です。世の中の情報に流されたり適切な判断は到底できないでしょう。

同値性の判定

数学を勉強するとは、このような比較のためのツールを勉強することとなります。比較の前に、まずは同じか否かの判定ができるようになっておきたいです。それが、同値性の判定です。

プログラミングにおいて、同値性の判定は、一番重要だといっても過言ではないでしょう。2つの値が与えられた時に、同じか否かを判断する能力がなければ、適切な設計ができません。プログラマやエンジニアを目指す人は、同値性の判定に関するトレーニングを日々積んでいく必要があるでしょう。

実数や複素数における等式の証明は、簡単です。(同値性で議論すると大変なので、等式に関して記述します。)

1. a - b = 0
2. b = 0 のとき a = 0, b ≠ 0のとき a / b = 1
3. その他

の中で基本的に1 or 2を証明すればよいです。

気をつけなければいけないのは、 a = b を仮定して、証明を進めてはいけません。循環論法といって0点になります。日常でもよくやってしまいがちな間違いで、「AさんとBさんって同じ考えの持ち主だよね。だから、2人ともロリコンだよね。ほら、やっぱり、AさんとBさんって一緒の考え方だよね。」みたいな論証をよく耳にします。これは気をつけたいです。

比較

これで、同じかどうかを判定することができるようになりました。同じだと良いのですが、世の中イコールってあまりない。2つ何かを持ってきた時には、やはり、比較することになります。

実数 a, bにおいて、a ≧ b を証明するときには以下の証明から選べばよいです。

1. a - b ≧ 0
2. b = 0 のとき a ≧ 0, b ≠ 0 のとき a / b ≧ 1
3. 相加平均 ≧ 相乗平均
4. a ≧ c, c ≧ b となる c が存在する
5. その他

基本 1 で良いのですが、場合によって、様々な証明のパターンがありえます。3が解らない方は、高校の数学の参考書を参照してください。4 は、間の値を持ってきます。直接比べるのが難しい時に、間の値をもってくると比べやすい場合があります。

評価関数は計算機が最適化する

実際は、前も述べたように、実数や複素数同士を比べられることの方が少ないので、評価関数を用いることになります。では、評価関数を設計できるように教えていきますといいたいところですが、その努力は、徒労に終わるでしょう。

現在の計算機はどのくらいの演算処理能力があるかご存知でしょうか。スーパーコンピュータの演算処理能力は、PFLOPS(ペタフロップス、京(けい)フロップス) の大台に乗ってきていると言われています。P(ペタ)という単位は10の15乗を示します。K(キロ)、M(メガ)、G(ギガ)、T(テラ)の次、P(ペタ)です。

浮動小数点の計算は、人間なら、1回の掛け算や割り算でもヒイヒイ言いながらやるところでしょう。これを、秒間ペタの大台で計算できる計算機が世の中にあるということです。人間は正確な演算処理では足元にも及ばないのです。

そして、世の中を見てください。n次元という会社名の由来でもありますが、もはやデータ、数次元ということはありえず、数万とか数億の次元があるベクトルで構成されているはずです。これらを適切にさばいて評価関数を構成できるのは計算機以外にありえません。

計算機を利用して、評価関数を最適化するような回は後ほどして参りますが、適切な評価関数を世の中のデータから計算機を使って導ける頭脳と、比較の証明この2つがあれば、正直どこでも生きていけると思います。時流から導いた自分自身の評価で足りない部分適切に補って、柳のような柔軟さを持って厳しい世界を渡り歩いていけるでしょう。

今回は、ここまで。次回も一緒に勉強していきましょう。

考えることをやめろ。その二

ysawa (澤良弘) — Wed, 02 Dec 2015 18:00:00 +0900

前回のおさらい。

練習とは、繰り返し同じことを繰り返すことでした。練習の意味を考えるためには、サブスレッドという概念が必要になってきたわけです。バリデーションの重要性も説明しました。まだ、よく理解できていない人は、非常に重要な概念なので、前回に戻って復習をすることをおすすめします。

練習は無心になってやる

実は、練習に関する議論が、「その一」では宙ぶらりんでした。練習は、一度やると決めたら無心になってやることが大事です。計算問題にしろ、暗記にしろ、とにかく問題に関すること以外思考してはいけません。小学生からの知育大百科2016完全保存版(プレジデントファミリー)には、東大に合格する子供ほど、宿題を手短に片付けるというデータが掲載されています。

今や、小学校や中学校といった義務教育の中で課される宿題よりも、塾の宿題が優先されがちな世の中で、このようなデータは注目されるべきでしょう。僕が受験勉強のときもそうですし、塾で数百人もの生徒を指導する中での話として、学校の宿題だから、試験だからといって馬鹿にするような人はやはり、基本的に成績が頭打ちになります。帰納法的な話になって恐縮ですが、なぜかそのようになるようです。

どうせやらなければいけないのであれば、早く終わらせればよい。ただそれだけなのです。無心にやって、きちーっとやる。最初はそれをこころがける。

練習を積み重ねてサブスレッド化する

練習が熟達してくると、サブスレッドで物事をこなすことができるようになります。すると、メインスレッドでやっていた作業を、サブスレッドとして切り離し自動化することができます。魔法のような話ですが、これは、皆さんやっていることです。

例えば、毎朝、通勤や学校に出かけるとき、いちいち靴の履き方を意識して着用することはないでしょう。シャツを切るのもネクタイするのも自動化されているかと思います。サブスレッドで衣類を着用しながら、メインスレッドでは、違うことを考えていることでしょう。

もし、ネクタイするのが初めての人だと、これは、大変です。メインスレッドをフルに使っているので、なかなか終わらず、出勤や通学までの時間の間、他のタスクがスタックとして溜まっていくでしょう。パンが焼ける、親に話しかけられるなどの割り込みがあるかもしれません。スタックや、割り込みに対処するには、練習によって、通常のルーチンをサブスレッドによってこなしていくのです。

練習と本番の関係

練習は、練習と同じ動きを本番でもやるためにあるのではありません。本番は、練習とは必ず違う環境ですし、課題はその時々で変わるでしょう。むしろ、違う状況に適応することに注力すべきです。練習した基本的なルーチンを実行しながら、メインスレッドでの作業に全神経を集中させる。

勝手に体が動いてしまうというところまで無心になって練習していくことが必要です。特に、基礎基本の練習は大事なものになります。もし馬鹿にしている人がいるとすれば、見直すチャンスかもしれません。

仕事ができる人の定義

人それぞれの定義があると思います。(ここから先に、僕の定義を述べます。良い記事なのでぜひ読購読してみてください。)

ここで、僕なりの定義をここであげようと思います。うちの役員は、いつも聞かされていて耳にたこができている話であります。

「病気になっても、酒に酔っ払っても、平常通りパフォーマンスができる人。」です。

炎上しそうな話題ではあります。実際、病気になったら休むべきだし、酒に溺れているような人は仕事をしてはいけません。これは、一種のメタファー(暗喩)です。

仕事人として重要な要素は、自分の仕事が、サブスレッドでできるくらいのところまで落ちていることが必要です。そうでなければ、安心して頼むことはできません。サブスレッドでできるところまで、徹底的に練習することでようやく安定感のある仕事ができるようになります。

案件の受け方

新しい仕事では、知らない知識、言語やフレームワークの使用を要求されることがあります。こういう案件も自信を持って受けることです。全く問題ありません。

知識体系を形作るために、5冊以上の同じ分野の書籍を買いましょう。よく、厳選して1冊だけ買う人がいますが、全くだめです。知識体系がない人は、正直、書籍を選ぶ能力もない人です。ほとんど意味のない基準で書籍を選んでしまうことでしょう。5冊買っても日本の書籍であれば、1万円前後。英語の書籍でもせいぜい数万円程度です。どんどん投資しましょう。

買った本はひと通りざっと目を通す。頭の中に知識体系の地図をつくり上げるのです。これで、基本的にOK。あとは、数冊の本を丁寧に読み込んでいく。社会人として必要とされる知識体系は、せいぜいこの程度で完成します。

大事なのは、サブスレッドを全面的に信頼することです。サブスレッドで読むような方法は、速読法とか、フォトリーディングなどと言われ、解説されているものなので、検索してみてください。

プログラミングの練習

チーム開発をするプログラミングにおいて、大きな要素の2つが、コーディングとソースコードリーディングです。コーディングは書くこと。ソースコードリーディングは読むことです。コーディングは簡単です。習うより慣れろというくらい、書きなぐることが重要です。

そして、忘れていけないのはソースコードリーディングです。他人のコードを読むことは、正直面倒な作業と思うでしょう。しかし、ソースコードリーディングができなければ、既存のコードを修正したり、僕らのコードのリファクタリングをすることはできないです。

ソースコードリーディングにおいて重要なのは、読んでいるコードをサブスレッド上になるべく置いていくということが大事です。読んでいるコードがきもちいい。臭い。きれい。きたない。といった感覚に置き換えてみるのがよい練習になります。最近は、エディタやIDEが進化して、シンタックスハイライトがよく効くようになっているので、こういう感覚は呼び起こすのは非常に楽でしょう。

ソースコードリーディングの練習が熟達してくると、修正箇所がすぐに見つかったり、リファクタリングもできるようになります。脳内のサブスレッドがバグや修正箇所を勝手に見つけてくれるようになるでしょう。

音読のすすめ

頭の中を無にして練習するためのツールとして、音読や朗読は非常によいでしょう。音読は、語感をサブスレッドに叩きこむことを強制的に行うことができます。語感は、言語の習得に必要なだけでなく、筆者の思考法にも繋がります。

音読や朗読は、中学以来やったことがないという人がほとんどでしょうが、日々、読んでいる文章を声に出して読んでみる。大人になってやってみると非常に多くの気付きが得られるでしょう。まずは、やってみてください。

まとめ

お解りいただけましたか。練習は、メインスレッドでの作業をサブスレッド化する際に非常に重要な活動ということです。練習するということは、会社で働くようになると、ほとんどやらなくなります。しかし、生命時間を上手に活用するためにも非常に重要な活動となりますので、日々の生活に組み込む。すなわち、習慣化するように心がけるとよいでしょう。

おしまい。

考えることをやめろ。その一

ysawa (澤良弘) — Wed, 25 Nov 2015 18:00:00 +0900

練習はなぜするのか。

基礎的な動きをある一定時間やったり、基本問題を続けて解くといった行動を「練習」といいます。不安なので一応、新明解国語辞典で調べておくと、

技術や芸術などが上達するように、同じ事を難度も繰り返して習うこと。

とあります。今日は、練習の大切さを書いていこうと思います。初学者や初心者は、とにかく、このプロセスを省いてはいけないのです。

同じ事を何度もやることが練習です。これが、非常にわかりにくかったりします。無駄なことをやっているような気がしてくるからです。場合によっては、退屈な時間が流れて、どうしようもない思いになります。

そのように、練習を無駄に感じてしまうような人は、安心してください。基本的には、あなたのやっていることは80%くらいは必要ないです。練習は必要ありません。正確にいうならば、必要なくなります。

質の悪いアドバイス

話題変えて、先輩・上司の悪いアドバイスに、「もっと頭を使えよ」というものがあります。代替の人が言われたことあるのではないかと思います。これを言わされているように感じている先輩・上司と、聞かされていると思っている下の人、どっちも残念ですね。

まず、先輩・上司は、ひどいことに自分が頭を使っていないこと。どうやったら相手ができるようになるのかを全然考えていない。人の頭の使い方を解っていないことが丸解りなアドバイスですね。こういう人は一生気づかないでしょう。可哀想な人です。

そして、当然、下に付く人は、そういう先輩・上司の下ですから、成長するべくもなく。同じく、可哀想な人です。今すぐ、その先輩・上司の下を今すぐ離れるべきでしょう。

「頭を使いすぎ。もっと頭を使うな」と。先輩・上司は、こういうべきでした。

人間の脳はMIMD

基本的に人間の頭脳は、MIMD (Multiple Instruction Multiple Data、ミムディー) 型のプロセッサです。並列の情報(Data)を並列の命令(Instruction)で処理することができます。なので、食事中に口を動かしながら新聞を読んだり n次元ちゃんねるを観たりできるわけです。これができないと、FPSで、逃げながら敵を撃ち落としたり、戦いながら隠れ場所を探すことができないことになります。

この頭脳の働きを上手く利用していくことが、人生を有利に進めていく上で非常に重要になります。僕の母校に入る人は、この働きを上手く活用している人はすごく多い気がします。

ここまでが、無料分です。有料会員は、全て読むことができます。とてもいい内容なので、是非購読してください。

並列に情報を扱えるのが、頭脳の基本的な働きでした。ですが、実際に、2つ3つのことを同時にやってみると解るのですが、意外と難しいということが解ってきます。

例えば、数学を勉強しながら国語を勉強したり、本を2冊同時に読んだり、複数の株価指標を同時に読み解いたりといった課題です。

メインスレッドとサブスレッド

実際に、メインスレッド(顕在意識)が同時に複数現れるわけではないです。同時に複数の意識が現れているような人は居るのかもしれませんが、ちょっと信用できないかもしれません。どうしてもサイコパスのようなものを感じてしまいます。

プログラミングを行う場合、メインスレッドとサブスレッドという概念が必要となります。メインスレッドは、メインルーチンを動かします。メインルーチン内でOSとシステムコールによって対話を行ったり、サブスレッドの管理をしたりします。

重たい演算などは、サブスレッドで行います。サブスレッドでの演算結果をメインスレッドに投げることで、メインスレッドだけでやっていた演算処理を結果的に軽くするということを行います。

人間にも、メインスレッド(顕在意識)とサブスレッド(無意識)があり、メインスレッドだけではなく、サブスレッドを如何に活用するかをポイントとなります。メインスレッドは、生命時間や物理空間と同期して行わなければいけない処理を担当しています。サブスレッドは、メインスレッドから切り出して並列で行う処理を担当します。

例えば、新聞を読みながら、ご飯を食べているシチュエーションでは、新聞を読むことがメインスレッドで、ご飯を食べるために口や箸を動かすことがサブスレッドになります。ひょっとすると、人によっては逆かもしれませんが。

サブスレッドで処理する

サブスレッド上で処理がなされるとき、無意識で行うことになります。無意識でおこなうために処理を翻訳して上げないといけません。そのために必要なプロセスが、今回のメインテーマである「練習」ということになります。

練習というのは、処理をサブスレッドに載せられるだけ、量をこなすためにあります。量をこなすことで、呼吸をするようにいつでも同じ動作をできるようになります。「習うとは慣れること」という言葉がありますが、習うというのは練習のことです。練習することで慣れていき、当たり前の動作、思考法になっていきます。

サブスレッドに処理を任せることで、メインスレッドに本当にやりたいこと、やらなければいけないことを集中させるのです。他の仕事と並列させたり、酒を飲みながら何かをしたり、寝ながら何かを想像したりといったときには、必ず処理がサブスレッドで動いています。

例えば、僕は、複数の案件を回しながらどうしようもなくなったときに、あえて睡眠を取ったりします。そのときに大事なのが、「A案件のBコントローラの設計が思いつかないから教えて」のように祈って眠りに付きます。祈りの強さは、サブスレッド上で処理を走らせるときには非常に重要なようです。

サブスレッドが上手く活用できないと、メインスレッドを酷使することになり、いつも一生懸命やらなければいけなくなります。慣れた作業は極力サブスレッドに回してしまうことです。

サブスレッドは間違える

では、全部サブスレッドで行えば良いのでしょうか。そういう訳にはいかなそうです。サブスレッドに落とした仕事は、どうも質が下がるようです。間違えたり、プロダクトの質(そして量も)に影響してきたりします。

どうするのか。バリデーション(検査)が必要となります。確認、テスト、検算、そして調査などに置き換えてもよいでしょう。メインスレッドで必ずバリデーションを行なうことで、質を担保しましょう。

バリデーションの手法に関しては、後々書いていきますが、継続することが大事で習慣づけといつもブラッシュアップしていくことを心がけてください。こまめにチェックするなど、自分なりに方法を模索していくことです。

サブスレッドによって得られた結果は恐らく、求めるものの 90% くらいでしょう。その 90% を100% にしていくのは、メインスレッドの仕事です。バリデーションによってきちーっとしたプロダクトに仕上げていきましょう。

ここでこの記事は終わりですが、「考えることをやめろ。」は非常に難しくて解りにくいテーマです。もう少し深く考察しようと思います。

勉強することと稼ぐことその二

ysawa (澤良弘) — Wed, 18 Nov 2015 16:45:00 +0900

ちょりっす。n次元チャンネルの ysawa です。

今日は、「勉強することと稼ぐことその二」の2回目。

今回も引き続き勉強することと稼ぐことの関係について書いていきます。

起業、食事、読書、映画鑑賞、旅行、スポーツ、不動産運用、アプリ制作。基本お金があると、または、お金を使うと便利だという活動が人生にはあふれています。お金は人生の豊かさの最低限のレベルを保証するものとも言えるのではないでしょうか。何かをしようと思ったときに、同時並行、または事前にお金を稼ぐという活動が必要になってくるわけです。

お金を稼ぐのは、時間が拘束されますし、本当にやりたいことをやる時間がなくなったり、肉体的・精神的に厳しいものもあります。どうしても、お金と対価にネガティブなものがつきまとう。どうしても、お金となにか不幸なものとを結びつけて考えがちです。考えだすと明日の生活が不安になったり、できもしない遠くの将来の闇を追ってしまうような感じになるかもしれません。

では、ここで一旦リセットして考えましょう。お金は単なる数値です。情報空間における数値に過ぎません。この数値をいかに上手く解釈し操ることができるかが人生の質を左右する。そのように考えてみてはいかがでしょうか。

生命時間について

必ず、お金とついにして人生の方程式に組み込まなければいけない要素があります。それは、人生における「生命時間」です。生命時間はもちろん有限です。実際に生命時間を体感している人は意外に少ないのではないでしょうか。

しかし、それでは、僕らなりに人生を上手くやるための方程式を導くことは到底できません。では、どうするのか。計算してみましょう。便宜上、1年を365日、寿命を80年として、生命時間は、

365日/年 × 80年 = 29,200日

たったのこれだけしか無いわけです。僕らは、もし、財布や貯金の残高が、29,200円しかなく、ある一定期間生活することを余儀なくされた場合、節約したり充実したお金の使い方をするでしょう。

例えば、どうしてもある漫画が欲しいとして、友達Aと共有したら2倍お得だなとか。酒好きが、どうしても英語を勉強しないといけないという状況だったら、外国人の多いバーにでかけたりするようになるかもしれません。

生命時間も同様に、節約するとか、充実した生活をおくるようにしないといけないですね。稼ぐ手段として労働(頭脳労働、肉体労働)を考えたときに、単にお金だけ稼ぐのではなく、何かもっとプラスアルファを求めていきたいですね。

そこで出てくるのが次の考え方です。労働の観点からみた勉強に話がシフトしています。柔軟に頭の中を切り替えて読んでいただければ幸いです。

n次元式勉強の分類

n次元では、勉強法を3つに分類しています。

(ここから先は、有料になります。でも、すごくいい内容なので是非購読してみてください。)

ただで勉強する
お金を払いながら勉強する
お金をもらいながら勉強する

これを、「n次元式勉強の分類」といいます。では、あなただったらどれを選びますか。考えてみてください。

「ただで勉強する」はやってはいけない

まず、1はどうでしょう。結論から述べますと、これは、一番やってはいけないことです。「見習いとして(ただで)やらせてください」のようなことは実際世の中でよくありそうなことです。それだけ、昔の僕や、一般的に陥りやすい誤りなのでしょう。

なぜ、ただで勉強してはいけないのでしょうか。まず、労働と勉強の交換で ±0 です。つまり、お得感はゼロです。最初、ある程度成果は得られるかもしれませんが、やっていくうちにだんだんモチベーションもわかなくなっていきます。ただでやっているのにも関わらずクレームを付けられたりして、押し付けられているような感じがしてくるかもしれません。自らの成長とともにその状況に価値を感じなくなってくるかもしれません。

僕も、実際これで失敗したことがありますが、やってみるとネガティブな感情しか生まれないです。自分自身のモチベーションの問題もそうですし、相手も味を締めたように、ただまたは安い価格で案件を頼んで来るようになります。相手も何かにつけて足元を見るような悪い人になってしまうことがあるのです。そういった人を引き離すのは大変な苦労となります。正直、ただで働くのは、止めたほうが良いと思います。

やってはいけない本当の理由

しかし、ただで勉強することでもっと罪深いと感じることがあります。それは、稼ぐことが覚えられないということ。言い換えるなら、人からお金をもらうことが、気づかないうちにだんだんできなくなります。雇用契約の交渉が苦手になる、見積をどうしても低く見積もってしまう、請求書を発行できないといった結果に繋がってしまいます。今回のテーマでもある、「勉強することと稼ぐこと」は当然達成できない人間になってしまうでしょう。

僕らの最終的な目標は、限られた生命時間を豊かに過ごすことです。豊かに過ごすには、お金は切っても切れないものとなります。僕らの勉強も大事ですが、衣食住、家族との時間に対してもきちーっと投資していかなければいけません。勉強だけして、お金が得られないそれでは、豊かな人生は絶対に歩めないのです。

「お金を払いながら勉強する」は条件付きでOK

n次元式勉強の分類の2はどうでしょうか。大学、英会話教室、学習塾、ビジネスセミナーなどを代表とした有料の講座や訓練を受ける方法です。こちらは、条件付きでOKだと思います。

まず、お金を払うことがモチベーションになるという人はよいと思います。お金を払うというのは、刺激になり、なにかやり遂げるためのエネルギーが湧いてくるでしょう。ただ、バネの様なもので、だんだん萎えてくるということがあるので、なるべく短期間でやることをおすすめします。

また、書籍に関してもこちらに分類されるかと思いますが、どんどん購入するとよいと思います。最近は、電子書籍も充実してきたので、通勤時間を充実させるものとしても非常に有効です。通勤時間は、電子書籍を読むか、 Jumper をやるとよいでしょう。書籍に関しては、別の回で書いていきます。

「お金をもらいながら勉強する」が正解

n次元式勉強の分類の3ですが、「労働しながら勉強する」という言い換えができます。今までの文脈を追えている人は解ると思いますが、これが正解です。

お金は、前で述べましたが、単なる数値です。数値は、大きいか小さいか比較可能ということです。お金と共に、仕事の価値を再確認することを是非実践していただきたいです。

勉強してから仕事がもらえるのではなくて、仕事しながら勉強するのです。この思考法の転換が非常に重要です。同時通訳の人の中には、辞書を引きながら通訳をする人がいるようです。最初に、知識や情報がなくても仕事はできるのです。

仕事をもらってから必死に勉強して、絶対に達成するのです。そして、信用をつけて、さらにハイレベルな仕事をもらうのです。基本、これができれば、従業員としては十分ですし、起業したとしても上手くいくと思います。

弊社では、新規の案件とともに、10冊前後の書籍を購入することがあります。10冊前後を同時並行で読みこなし、案件をこなせばよいのです。

単価を上げる

既に、お金をもらいながら勉強している方は、上司や、人事担当者に賃金を上げる交渉をしていきましょう。一度ではダメです、難度も難度も交渉を積み重ねるのです。ここで、大事なのが、周りに隠れて交渉をしてください。周りの基準に合わせて仕事をしていては、仕事も人生も豊かにはなりません。一切、周りの賃金を気にせずに、または気にされずにことを起こすことが重要なのです。

事業主の人は、既にやられているかとは思いますが、取引先に単価を上げてもらうにはどうしたらよいかを常に考えるようにすべきです。そして、単価を下げることは、絶対にやってはいけません。

まとめ

そして、お金をもらうことでモチベーションを高め、更に質の良い仕事をしていきましょう。それが、僕らのお客様、そして、所属する会社のためにもなります。生命時間の効率を十分に上げて、豊かな人生を過ごしましょう。

「勉強することと稼ぐこと」の回はこれで終了になります。次回もよろしくお願いします。

勉強することと稼ぐことその一

ysawa (澤良弘) — Wed, 11 Nov 2015 00:00:00 +0900

ちょりっす。n次元チャンネルの ysawa です。

気づいたのですが、
『ysawa が教える「超プログラマへの爆速勉強法」』なんて名前をつけてしまったので大変だということ。

最初から気づけよという話ですが、人と違うことをする指向が昔からあるようです。
業務中は常に奇声を発しているようです。プログラマの性(さが)なのかもしれませんが。
最初の回なので、触りやすい簡単な話から入ろうかと思います!!!!!

まず結論から、「勉強する」ことと「稼ぐこと」はあまり関係が無いことが多いです。

。。。

ただ、多少は関係すると思います。

高校で習ったベクトルで考えれば簡単です。2つの方向性を持ったベクトルは、内積が0以下でなければ、一方のベクトルをもう一方のベクトルに正射影した時に、正射影ベクトルは、もう一方のベクトルと同じ方向を向いています。

意味解らないという人のために説明を加えると、多少違う方向を向いていても、あらぬ方向を向いていなければ、少なからず同じ成分を持っているということです。勉強することは、多少は、稼ぐことの成分を必ず持っているということです。

多少ですね。

しかし、ほとんどは、あまり「稼ぐこと」には役に立たない。「高校・大学で勉強したことのほとんどは約に立たない。」「数年間英語勉強したが全く喋られない。」という人が多いように。

では、なんで勉強するのか。

これは、経営者の方々(僕の知り合いだけかもしれない)の多くが、新聞を読んでいるのはなぜかというのに通じるかと思います。

「これは、周りがやっているから」「知っていないと恥ずかしいから」「常識だから」

に近いんだと思うんですね。
21世紀にもなって●●を知らないのはちょっとまずいという。
社会人にもなって○○を知らないのは恥ずかしいと思ったり。

僕の好きな、新明解国語辞典によると
勉強とは、

物事についての知識や見識を深めたり特定の資格を取得したりするために、今まで持っていなかった、学力・能力を身に付けること。

とあります。

ここで言っている中で重要なのが、

「知識や見識を深めたり」というところですね。探究心を刺激するような活動が勉強の正体です。

そして、勉強は、人生を豊かにする。

勉強は明らかに好きだからやることでなければいけないと思います。単に、知って「へー」だけでは、かなりもったいないですね。役に立つからだけで勉強するというのは、豊かな思考法ではない。

先ほどのベクトルの話でいけば、思いっきり違った方向性でも、思いっきりぐんと、勉強ベクトル伸ばす。そうすると、後から、稼ぐ方法が思いついたり、金持ちの理解者から声が掛かったり、研究費が工面できたり。そういう話になっていくかもしれません。でも、あくまでおまけ的に。

21世紀になってすでに15年も経ちました。
知的探求で、自分自身の知的欲求を満たす。
20世紀まででやってきたことからいよいよ翼を解き放す時ではないでしょうか。

勉強とは、人類一人一人に平等に与えられた快楽ですし、
勉強とは、人から与えられるものではなくて自分で掴むもの。

ただ、稼ぐだけではなく、勉強して知的好奇心を満たす。
他人やロボットからコンテンツを与えられて満足するのではなく、自分で掴みにいく。
そういう人々で構成された世界にできたら良いなと思います。

そのためには、勉強に必要な時間を捻出しなければいけません。

(あ、ここから、真面目な文体になるので注意してください。。。)

つまり、生命時間の最適化を行っていく必要があるのです。各々、やっていくべきことは異なると思いますが、現代人においては以下の行動が非常に無駄を多く含む活動ではないかと思っています。

1. 公式ドキュメント(一次ソース)でない情報から読む

2. ニュースキュレーションメディア・アプリ・新聞・雑誌(読み方によっては)

3. 有名人の話

順番に説明していこうと思います。

1. 公式ドキュメント(一次ソース)でない情報から読む

情報を検索するときに、どうしてもわかりやすく説明しているソースから辿ってしまうという癖がどうも染み付いている人がいます。

常に、なるべく一次ソースらしい情報から辿っていき、理解できない場合は、仕方なく、わかりやすく解説したものを発見するようにするようにすることが大事です。

二次ソース以上の情報には、往々にして筆者の解釈や、感想が含まれています。もし、間違った解釈や感想の二次ソース以上の情報を読んだ後に、一次ソースを読んだ時には、僕らは、一次ソースを「そうだそうだ」と誤って解釈することになりかねません。

間違った解釈をしてしまったときに、修正するのには、莫大な時間を費やすことになります。残念ながら、非常に無駄な時間となってしまいますね。それを防ぐためにも、一次ソースから深掘りしていく読み方をおすすめします。

n次元でも企業向けに開講しているプログラミング講座でも、口を酸っぱくして言っていることですが、プログラミング初心者はもっと公式ドキュメントを読むようにしたほうが良いですね。特に英語の原文がよいです。慣れの問題で、公式ドキュメントの読み方をマスターすればかなりプログラミングはうまくなると思います。

ちなみに、英語で書かれたドキュメントを読むのに必要な英語力は、英検２級レベルあれば良いのではないでしょうか。あとは、語彙力ですが、こちらは、本講座でも伝えていこうと思います。

2. ニュースキュレーションメディア・アプリ・新聞・雑誌(読み方によっては)

こちらも似ているのですが、他の人の解釈や感想を読むことはあくまで娯楽の一つとして考えるべきです。それをあたかも自分の糧になったかのように考えるのは非常に危険です。他の人の意見を受け入れているだけで、自分の能力値の向上(勉強)になっていないことに気づかないといけません。

娯楽としてのめり込みながらも、やはり、筆者の意図に流されないことが重要になってくるのですが、そのためには、ある程度の訓練が必要です。

1つの訓練法が、文章を読んだときに、ファクト(事実)と解釈・感想をバイナリのように捉え、2つを明確に分けることです。これは、ファクトだな、これは解釈・感想だなと瞬時に判断して読解していく方法です。訓練が熟達してくると、解釈・感想を見つけた時には、「本当かな?」「なぜ?」「どのように?」と疑うようにする。5W1Hというもので、Who(誰が)、What(何を)、When(いつ)、Where(どこで)、Why(なぜ)、How(どのように)を考えるようにするのです。

ファクトだと思われる情報でも、まだまだ注意は必要です。著者が持ってくる数字やグラフ、統計情報(アンケート結果など)には、結論を導くための値を含めることで、読者を意図のまま操るようなことはよく日常で行われています。非常に由々しき問題ではありますが、読者はきちっとした読解力を身につけるべきです。

3. 有名人の話

有名人の話を聞くときに、特に成功体験談は注意が必要ですね。成功当時の時流、生まれた環境、性格、体格など、僕らにどれだけ一致しているか。そして、異なるものはどれだけ僕らに適応できるかが重要になってきます。

また、ありがちなのは表面上の話しかしていないこと。8:2の法則といわれるもので、成功の要因は実は、2割の努力なのにも関わらず、8割の努力の話をしてしまっている場合があります。僕らは人の話を聞きながら、背後にある2割の話を汲み取らなければいけません。話されない2割に本質が隠されているのです。

話を聞いた後に、しっかりと抽象化・一般化したうえで、適応できる事項を僕らなりに発見していく。そういう活動が必要になってきます。

結局、受験勉強でもそうでしたが、要領の良い人、頭のいい人、稼いでいる人、コンサルタントの話を聞いても、結局最終的にやるのは僕らなわけです。こういう方々のエッセンスをどれだけものにできるかが重要です。

以上の3点は、特に気をつけたいものをいれました。これらを気をつけるだけで、勉強の時間が捻出できるようになるはずですし、勉強の質も高められるようになっていくと思います。

無駄な時間を削りつつ、探求する活動「勉強」の時間をきちーっと作っていきたいものです。

まだ、言いたいことの半分も語れてないので、
次回に続きます!!!

(自分でハードルageているのも知らずに。。。)

おしまい。

ysawa が教える「超プログラマへの爆速勉強法」

人工知能と人類の未来を考えてみた

人工知能の小説

コラボレーションツールとは

オーラルコミュニケーションの終焉

星新一関連ニュースまとめ

Haskell で覚えるプログラミング

Haskellとは

インストール

ghci

リスト操作

foldr

zip, zipWith

いよいよ

モジュールの実装とユニットテスト

ソフトウェアとモジュール

ユニットテストは書くべきか

ユニットテストとは

二元論に陥る愚かなプログラマ

どうあるべきか

ドライバとスタブ

テストをするには

ソフトウェア開発におけるコスト感

型から学ぶプログラミング その2

熟練プログラマ

未熟なプログラマ

実務経験3年でいけるか

リスト (List)

配列・ベクトル (Array / Vector)

連想配列 (Dictionary / Associative Array)

まとめ

型から学ぶプログラミング その1

集合ってなんだったっけ?

桃太郎で学ぶ「集合」

集合 (Set)

ペア (Pair)

続く...

動物園で学ぶモデル化

もう一度、モデル化とは何か

動物園にいってみよう

さっそく分類してみた

こういう分類もある

プログラマがすべきこと

モデル化はやっぱり難しい

まとめ

プログラマはなぜ稼ぐのか

稼げない日本のトップ大学生

インターンは違法?

プログラマがなぜ稼げるのか

モデルとは

モデル化は難しい

真の大学受験二次試験対策

受験にうかる思考法

理系科目もまとめてみよう

選択式であれば問題数の多い方を選ぶ

大学の特色はやっぱり出る

Jumper (ジャンパー) って結局なに?

Jumper ≠ ゲーム

Creativity and Communication

Haskell で書かれた頑健性の高いAPIサーバ

Cocos2d-x で書かれた移植性の高いゲームアプリ

そして、なによりも

オレオレ詐欺はハッキングの一種? その3

脅威5 ウェブサービスからの顧客情報の搾取

脅威6 ハッカー集団によるサイバーテロ

まとめ

オレオレ詐欺はハッキングの一種? その2

脅威3 「標的型攻撃による諜報活動」

脅威4 「ウェブサービスへの不正ログイン」

まとめ

オレオレ詐欺はハッキングの一種?

セキュリティリスクの最大の原因

オレオレ詐欺はハッキングの一種?

脅威1 「インターネットバンキングやクレジットカード情報の不正利用」

脅威2 「内部不正による情報漏えい」

次回に続く

n次元をなぜ設立したか

n次元をなぜ設立したか

宗教?

低い次元の仕事は見事になくなっていく

型から学ぶプログラミングその2

型から学ぶプログラミングその1

勉強することと稼ぐことその二

勉強することと稼ぐことその一