■
問：卒業論文や修士論文に何を書けばいいですか？ - 発声練習
すべては「問題」から始まる
あなたの論文で扱う「問題」を5W1Hを明確にした上で、100字以内で書き出してください。「〜が明らかでない」「〜するのが非常に面倒である」「〜するのにコストがかかりすぎる」などなど。
もし「問題」が100字以内で書き出せないならば、あなたは卒業論文／修士論文を書くことができません。どうにかしてください。
Rubyの言語設計者の講演内容を読んでいてツボにはまった。
「人間様が気分よくプログラミングするための言語」Rubyは何を目指すのか - GIGAZINE
大学が学生に指南しようとしている「問題設定能力」及び「その問題解決の道筋の策定能力」が発揮されている具体的な
事例がこのまつもと氏の講演に凝縮されているような
気がします。
まず、彼がどうやって「問題」を見つけていったのかという
ことを講演の内容から拾い上げてみるのもいいかなと。
そういう新しい概念に出会う度に、最初はbasicで十分だと思っていたのが、世の中には本当にたくさんのプログラミング言語があって、そのひとつひとつが前のものよりも改善した何かを提供している、ということに気がついて「これは面白いな」と思ったわけです。
世の中にたくさんあるプログラミング言語のひとつひとつに、「このようにプログラムしたらもっと面白くなる、もっとよくなる」と考えて設計した人がいるわけです。Pascalの場合はニクラウス・ヴィルトというスイス人、Cの場合はデニス・リッチーやカーニハンというアメリカ人が作ったということを知ると「もしかしたら、それは自分で作ってもいいのかもしれない」と思ったんです。
まつもと氏の
「プログラミング言語って、自作できないかな？」
これなんかは、問題の設定だと思います。
〜〜〜〜〜〜〜
Pascalの本を30過ぎてから読み、言語の勉強ってこういう
ものなのかと思ったことはある。
プログラミング言語Pascalの学習について - book-loverの日記
私がここで書いたことと、まつもと氏の若き日にリンク
するところがあるように思ったので、拙ブログからも
引っ張りますと。
数学で学習する計算をコンピューターにやらせるということは、一番抽象的な作業を、PCに任せる訓練になります。
一番抽象的な作業をする訓練をしておけば、具体的な作業をいざするときには、ある程度の「応用」が利きやすい。
以上が私がPASCAL本読んだ時の思いつき。
そして、まつもと氏のHighSchoolDays
その後学校の数学の授業で「帰納法的定義」というのを勉強した時に「これは再帰だ」と気がついた覚えがあります。つまりbasicという言語で私の思考は制限されていてその概念を理解することはできなかったのですが、Pascalという再帰ができる言語を学ぶことで新しい発想を理解することができるようになったということです。
と、PASCALの話で脱線しましたが、本筋に戻します。
つまり、修士論文の作り方とエンジニアのキャリアパスの
二重写しについて。
「発声練習」からまた引用します。
問題解決の重要性、必要性、新規性を説明せよ
世の中には無限に問題が存在します。その無限にある問題の中であなたがその「問題」を解決しなければならない理由を、読者に納得させる必要があります。理由は必要性、重要性、新規性から構成されます。あなたの「読者」が理解できるぐらいの詳しさ、やさしさで必要性、重要性、新規性を説明してください。
まつもと氏であればこうやって答えるのかもしれません。
実際問題としてどのプログラミング言語を使うかによって結果を得るためのコストや時間は変わってくる。あるいは発想が助けられるということもあります。
そのため、どのプログラミング言語を選ぶかはその人の生産性に直結すると言ってもいい。それによって、「プログラムしている時のストレス」「どれくらいの時間をかけてソフトウェアを開発できるか」「どんな記述量でそれを書くことができるか」ということがずいぶん変わってきます。
だからこそ、自分がRUBYという言語を独自に設計開発することには、プログラマーの生産性をどうやって上げるのかという
問題を解決する意義があるのだと。「新規性」という要件は
満たしていないかもしれません。
また「発声練習」へ。
解決策・緩和策を提示せよ
あなたが定めた問題の解決策・緩和策を提示してください。そして、なぜ、その解決策・緩和策が問題の解決・緩和に有効であるのかを説明してください。どこまで詳しく説明するべきかは、あなたの「読者」と相談してください。
ではまつもと氏はRubyによってプログラマーの生産性を
増進させるということを目的にして、どんなことを実現
させていったのでしょうか。
ソフトウェア開発では、皆さんも経験あるかもしれませんが、調子よくPCのキーボードをたたいて進んでいる時に電話が鳴って呼び出しをされると、頭の中にあったエネルギーみたいなのが抜けていって、5分後に電話が終わってPCの前に戻ってきた時にはもうそのエネルギーがなくて、その後一日中生産性が全然上がらなかったりします。やはり「気分」とか「ノリ」といったものがソフトウェア開発の生産性には非常に重要で「どのようなプログラミング言語を使うか」ということも実は影響を及ぼすことがあるということです。
プログラミングをする人の気分を「快適」にしたいと。
そのために、「コンピュータの都合」でプログラムの
記述をややこしくするようなことがおきることを減らそうと
お考えになったと。
最近はあまり使っていませんが、アルゴリズムの教科書では疑似コードというものがあります。例えばJavaでサンプルプログラムを書くとすると、アルゴリムで説明を書く時にさっきの「public static void」のような本質と関係ないものがいっぱい出てくるので「本質だけに集中して、人工的な言語、仮想的な言語でアルゴリズムを書きましょう」ということです。
でも、そうした簡潔で仮想的な言語でアルゴリズムがかけるなら、それがそのまま動けば最高です。そういう記述にできるだけ近づけたいというのがRubyや最近のLLと呼ばれているプログラムの設計ポリシーになってきています。
「教科書的」に学ぶことと、「実地にやってみる」ことで
学ぶことのGAPを埋めようとする。これは大事な考え方
だと思います。このGAPがプログラマの「万能感」の「妄想」
を痛く傷つけてきたと。であれば少しでもこの「万能感」
を大事にする開発を目指したのだと。
教育機関で学ぶ「数学」が、情報科学の世界では「数値計算」と呼ばれるとき、どうもまつもと氏が指摘する問題が
あるような気がしないでもない。
鉛筆と紙だけで答えを出そうとしたら起こらない問題が
コンピュータに任せようとすると色々と面倒な「誤差」発生みたいな。
私たちの考えている整数は「これ以下」とか「ここまでで整数終わり」という概念ではないので、13の階乗が計算できないというのはコンピュータの都合です。でも、もう21世紀にもなるというのにそういう都合を押しつけられたくない。なのでRubyでは200の階乗を計算したいと言うと、ちゃんと計算してちゃんと出ます。問題はこれがあってるかどうか誰にも分からないということですが、きっと合ってます（笑）。
人間と機械の都合が対立する時は結構ありますが「コンピュータが速く動くために人間がいかなる努力でもいたします」という態度は古いと思います。今や人間が主人なので、できるだけ仕事はコンピュータに押しつけたいわけで、そのためにがんばるのがRubyのポリシーです。
”Computer For The Rest Of US"にも通じるなと。
「発声練習」にもどります。
解決策・緩和策の有効性、妥当性を証明せよ
あなたの提案した解決策・緩和策で本当に問題が解決・緩和できたことを計算（シミュレーション）、実験、デモなどで提示してください。
まつもと氏の設計開発した言語をたくさん人が使っているなら、まつもと氏の企てはひとまず一定の成果を得たと考えてもいいのかなと。
おかげさまで1993年にRubyを開発して以来、認知度はどんどん上がってきました。1993年に作り始めて、95年に一般公開し、99年には最初の本が出て、2000年には最初の英語の本が出ました。この辺りから私の想像をはるかに超えてきました。
またまた「発声練習」
重要なポイントは、必ず問題に対して提案した解決法がどうであったのかを説明しなければならないという点にあります。尻切れトンボではいけません。
次に情報の配置を決めます。説明の基本原則は、大枠を先に示し、その後詳細を説明するというものです。以下のように説明します。
過去から未来
抽象から具体
概略から詳細
全体像から個別像
また、私の個人的な経験から言えば、What, Why, Howを適切な順番で提示しないと理解しづらいように思います。
まつもと氏の講演はこういう「ストーリーの組み立て」のお手本のような部分があるように思います。
ちょっとそれますが、「発声練習」によりますと。
邪道：解決法 or 成果から問題を探す
あんまりやらない方が良いですが、手を動かしたり、行動したりして何かしらの結果を得ているのに、「問題は何か？」「その問題の必要性や重要性は何か？」ではまってしまうときがあります。そんなときは、解決法 or 成果から問題を考えるというのは一つの方法です。
「自分が得た結果によって解決される問題にはどんなものがあるか？」「この方法で解決できる問題はどんなものがあるか」と考えるのです。そのあとに、その問題の新規性、重要性、必要性を考えます。
実は、研究歴の長い人ほどこういうことをやっています。
また拙ブログのエントリーから
研究者のアプローチについて - book-loverの日記
大学に職を得て、業績を残すということはどういうことなのかということが、わかりやすく書かれていると思う。
徹頭徹尾、「いままで知られていなかったこと。」
「間違って理解されていることをタダしていく。」
こういうことに、注力するのが「研究者」という人の
鏡なのだろうと思う。
そこに「問題」があるということさえ知らない。
「目的」も「経路」もそれを認識することが原理的に
できなかったところで、「何か」がみつかる。
以下はまつもと氏講演より。
その研究の一環としてHPC(High Performance Computing)というのがあって、東京大学の学生でこれを研究している方がいますが、これはRubyの型推論を行い、一度Cにコンパイルし、それでRubyを動かすという研究です。
やっぱ、こういう「ブレークスルー」に近い企てって
東大発なんだなと。ふと思う。
結論
何かを書くということも、そこに何らかの「目的」があってのことなのだろうと。
と今、こうやって書いているではないですか。
Connecting The Dot
たしかSteveJobsさんの言葉だそうですが。
個別に存在しているだけでは埋もれてしまうことも、
つなぎ合わせることでお互いの価値が発揮されるという
ことがきっとあるのだろうと。
「発声練習」に書いてあることは「具体性」に欠けるので
今ひとつ、読む人に訴えない部分がある。（あくまで想定は
一般読者。）
まつもと氏の講演には「具体性」はあっても、この講演の
「意義」を客観的に把握するための「抽象的な視点」が
足りない。（あったら気持ち悪いです。別にまつもと氏は
卒論書くことが目的でこの講演はやっていない。）
だから、まつもと氏の講演の「価値」をわかりやすく理解
するには「発声練習」の学生への「訓辞」とセットに
すると見えてくるものがある。
だから、私がこうやって「発声練習」と「GIGAZINE」のまつもと氏の講演スクリプトを並べることで、二つのブログが
個別には持ち得なかったであろう「新しい視点」という
ものが提示できないかなと。
いや、そんなだいそれたこと言っても同意してくれる人は
おるのかいなという話になります。
しかし、こうやって、書いているものの立ち位置を明確に
するというのもこれからBlogを続けていく上で大事な
ことになるのではないかと思うので。
そして、この「視点」を手に入れて、じゃあ具体的に
何を実行するのかというところから、
「起業」というものも見えてくるのではないかなと。
http://www.nhk.or.jp/gendai-blog/200/98241.html
彼がよく言っていた話として「みんな、人は死んだら自分の財産というのは全部国に還して、生まれたときに全部同じ金額をもらって、ゼロスタートでいい」って。人生の中で差がつくのはしょうがないと。これはもう頑張る人頑張らない人、能力ある人ない人、スキルある人ない人、いろいろいるからそれはしょうがないと。けれども、ほんとにフェアな社会っていうのは、ゼロスタートで最後死んだときはもうチャラになるという人生なのだと。そういうふうに世界全体をしていこうとしたときにいちばん大事なのは情報なのだと。情報を知っている人と知らない人がいるのがおかしいのだと。その知っている人と知らない人の差をなくすというのが、パーソナルコンピューターの元々の発想なのだと。「だからマッキントッシュは最初からネットワークがついていたろう？」なのですよね。
追記 Javaを開発したエンジニアはどんな会社に勤めているのか？
Case Study: PacX
In our lifetime, robots have traveled to the moon.
They’ve been to Mars.
They’ve cleaned our pools and they’ve helped perform surgeries.
But no robot has ever crossed the largest ocean on the planet.
That’s about to change.
