定量的な報告
研究室の打ち合わせで定量的な報告について話したので、補足を含めてまとめておきます。
1.スタート地点と目標の定量化
科学技術の進歩というのは段階的になされるものです。現在の状態があって、それに問題が有るから、ある目標に近づく必要があり、そのための解決策を考えました。というのが、工学における、研究や技術検討のステップになります。(以下、単に研究、と記載しますが、技術検討でも同様です。)
ということで、自分の研究の状況を報告する際は、先ずは研究のスタート地点を定量化して、聞いている人と共有しましょう。最初のスタート地点で共感を得られないと、その後の話を聞いてもわかりません。
次に目標を定量化しましょう。研究をした後に、どういう状態になるとこが望ましいのか、それも聞いている人と共有します。そうすることで、この研究をやる価値がどこにあるのか、判断できます。また、間違った目標に対して進んでいないかをチェックできます。
定量化の方法は研究テーマによって異なります。例えばシミュレーション時間を短縮したいのであれば、現在シミュレーションにどの位時間がかかっているのかを明確にするとこです。そして、どこまで短縮すれば良いか、というのを目標として定めます。ここで、何でその目標を定めたのか、という疑問に答えられるように説明する必要があります。
また、ソフトウェアシステムの機能を改善したいのであれば、現在の機能をリストアップして明確化します。そして、ある機能を追加する事で、この様に良い事がある、という事を説明して、それが目標である、と定めます。
研究でも会社での仕事でも同じなのですが、自分のやっていることの価値を、常に周りに説明して理解してもらわないと、評価してもらえません。
2.進み具合(進捗)の報告
進み具合の報告は、スタート地点を0%、目標を100%とした時に、現状を定量化して、何%、とするのが分かりやすいです。ただし、スタート地点と目標を定めただけでは、現在地点がどこなのか、把握する事は困難です。そのため、進捗報告は曖昧になりがちです。
簡易的な方法としては、目標をいくつかのサブ目標に分解して、例えば、「10項目中の6項目が達成できたので、進捗60%です。」という事でも良いでしょう。しかし、研究は単純作業ではありませんから、各項目が同じ様な困難さではありません。残りの4項目が期間内に終わるのか、わからないわけです。が、この様な簡易的な方法であっても、やらないよりはやった方が良いと思います。
より正確に現在地点を定量化するためには、計画、が必要です。計画に対して、現在地点を示す事で明確な進捗報告が可能になります。
複雑なものを作る時に、全部を一気に作る事は出来ないので、順番に少しずつ作っていくわけです。研究も一気に進むわけではなくて、目標に向けて部分部分の研究を進めざるを得ません。
という事で、スタート地点と目標を決めた後は、それを実現するための手段を考えて、細かい部分に分解するという作業が必要です。これが、計画、です。
計画の基本は、分解です。目標をサブ目標に分解します。さらに、サブ目標を、タスク(作業項目)に分解します。なお、制作系のテーマであれば、目標は「作るもの」と考えると、分かりやすいです。その上で、サブ目標の達成時期を考えます。これをマイルストーンと言います。マイルストーン達成のため、いつ何をやるか、タスクをスケジュールします。
目標を達成するために何をしないといけないのか、よく考えないと計画を立てる事は出来ません。機材やソフトウェアが必要かもしれませんし、書籍等の情報や、訓練教育が必要かもしれません。また、ここでは一人で研究を進める前提ですが、研究によっては人員の計画も必要です。人を使う場合は大変深遠な考慮が必要ですのでここではこれ以上書きません。
計画を立てている段階で、実は目標が達成困難である事に気付く事もあります。その際は、サブ目標がいくつか達成されれば良しとするか、目標の変更をするか、ですが、この辺の扱いはまだ良く分かりません。卒業研究ではサブ目標を達成すれば良しとする、かもしれません。
企業の開発案件であれば、顧客との約束が目標ですので、計画を練り直して何とかするしかないのです。「そもそも目標がおかしい」という事をあとになって言ってもしょうがないので、デスマーチに突入です。
計画は、いわゆるプロジェクトマネジメントや、ソフトウェア工学の重要なテーマでもあります。大変難しいものですが、不完全であっても、やらないよりはやった方が良いと思います。
もう一つ。計画を立てても計画通りに行く事はまずない、という事は認識しておいた方が良いです。特に研究ではその傾向が強いです。年に数回は計画の練り直しは必要です。
長くなりましたが、最後に。
卒業研究、大学院での研究では、目標は教員が選定したものから選ぶのが普通だと思います。また、サブ目標ぐらいまでは教員と話して決めていると思います。しかし、あまり細かい計画には立ち入らないでしょう。これを放置と見なすかどうか。学生の研究の計画を立ててあげるのは、あまりに時間を取られますし、学生が自分で計画を立てる学習の機会を奪ってしまいます。学生が自分で計画を立てて、それを教員が見て意見を言う、というぐらいが良いバランスかと思います。学生が計画を決めかねていたら、時には教員が決めてあげても良いでしょう。一般に自分で決めた事の方が頑張れるものですが、経験が浅いと自分で決めるのが困難な場合もあります。
ある程度の計画がないと、現在地点を見失い、時間だけが進んでしまい、終わる気がしない、とか、やる気をなくす、といった原因になります。
あと、教員側の注意点としては、あまりに計画を完璧にしようとすると、実際の研究がスタート出来ないので、学生にいらいらがたまります。計画にかけていい時間は数日でしょうか。この辺の感覚も、まだよくわからないので、今後修正していくかもしれません。
ちなみにこの辺のスキルは前の会社で学んだことです。大学での研究に上手く適合するか、まだ余り自信は無いですが、デキるエンジニアへの一歩である事は間違えないと思います。
科研費応募と授業準備
科研費研究活動スタート支援というのに応募資格があるので、応募することになっています。アカデミックな雰囲気で書きたいのだけど、しばらく（数年間）ビジネスになりそうな提案ばかり考えていたせいか、アカデミックな雰囲気にならない・・・まあ、なんとか頑張ります。
授業の準備で、今年度向けのレポート課題を考えました。過去レポを丸写しする学生が出てこないように。まあ、本来は丸写しではなく自分で考えよう、という気にさせるのが教育としては良いのでしょうが、色々な学生がいることを想定しないといけません。過去レポが役に立たない部分を作っておけば、少しは技術的な問題に対して考える時間もできるでしょう。自分で考えるのが大事なのだと思います。
問題を発見する→自分で正解を考える→これが正解かなと思い浮かべる→他の人がどのように考えているか調べる
私の経験だと、こういう手順を踏んで覚えた事項というのは記憶に定着しますし、もっと調べてみようという気にもなる。そういう成功体験を積み重ねるひとが、スキルを伸ばしていくのだと思います。なんとなく
enchant.js
4月16日 enchant.jsのチュートリアルを実施し自習した。以前、「androidはHTML5対応である事がポイント」というコメントに対して「そりゃ勘違い」というツッコミを見たのがきっかけで、なぜそんな勘違いになったのかに興味を持った。WEBアプリに関しては詳しく知らないので調べて見たが、HTML5自体は、それまでのHTMLの要らないタグを整理して動画とか文書構造を扱いやすくするタグを足したものらしい。今風のWEBアプリは、クライアント側ではそれプラスCSSとJAVAスクリプトで、動的なUIを作っているようである。androidはHTML5対応のブラウザを装備している。加えてiphoneなど現代の主要なWEBブラウザもHTML5対応している。ということで、プラットフォームに依存しないWEBアプリを作って普及させるならHTML5でしょ、という事らしい。そうなると、HTML5がプラットフォーム非依存の目的なのだから、androidのポイントはHTML5対応、というのはおかしいという事になる。納得。
さて、でenchant.jsなのだが、これもやはり学生時代に友達がjava scriptで簡単なゲーム(だるまさんが転んだ)を作っていたことがあって、その時に「java scriptは開発環境が貧困だから楽しい。マゾ環境タマラン」と言っていた。その時は、彼が私と同じ趣味で8bitパソコンのプログラム開発が好きだったのを知っていたので、ふーん、ぐらいしか思わなかった。しかし、google mapなどでajaxの名前でjava scriptが再び脚光を浴び始めたのを見て、なんでマゾ環境なのに流行っているのかと疑問に思っていた。そんな気持ちをずっと放っておいたのだが、件のANDROIDはHTML5が…の事を考えていたら思い出して、ちょうどandroid絡みでの研究テーマを考えていたためと、プログラミング演習でC言語の習得が難しそうな学生を見ていて他の言語を学ぶことでプログラミングに対する不得意感を減じることは出来ないかと思索していたため、最近流行りのjava scriptを勉強してみようと思ったのでした。
長くなりましたが、enchant.jsはすごく面白かった。20〜30行程度のプログラミングで、絵が動いてマウスクリックで操作できるのだから。しかも、そのままスマートフォンで動くということで、プログラミングの導入にはイイね！と思う。オブジェクト指向で書けるしね。
enchant.js を使ってゲームを作ろう!!
http://tmlife.net/programming/javascript/enchant-js-game-create.html
感想文
以前勤めていたベンチャー企業から、約3年間の在職中の、プロジェクトにかかわった感想を教えてほしいとの依頼が来た。実際は、もう一度やるとしたらどのようなポイントを改善したいか、という依頼内容だったが、既に記憶があいまいなので、一度記憶を掘り起こしてトレースし、出てきた問題点について改善ポイントを考える、という方向で作文することにした。
こういう感想文の依頼で、自分自身を反省してもあまり意味がないかなと思い、なるべく他責的に書いてみた。やり始めてみると、辛い気持ちや怒りとともに、忘れていた記憶をかなり思い出すことができた。どうやら1年目は概ね希望にあふれていたが終わりごろに不穏な空気が流れ始め、2年目の後半には不信感が確信に変わり、3年目は絶望の中で不平不満を言いながら過ごしていたことが分かった。
ベンチャー企業は自分で興すのであれば良いが、ベンチャー企業に就職するというのは結構大変（お勧めできない）、というのは就職時点である方にアドバイスいただいたことなのだが、結果としてはその通りになってしまった。就職時点の希望にあふれている時には、そういうアドバイスは耳に入らないんだなあ、と改めて思った。
そして、私は学生にどういう企業を勧めたらよいのか、ということに思いを巡らせている。もちろん最終的に決めるのは学生自身なのだけれど、アドバイス・情報をどのように与えたらよいのだろうか。何が幸せにつながるのか、実際のところわからない。まだまだ未熟だな、と思う。
研究室の環境整備
例年、3年生の後期に研究室仮配属が行われ、そのあと半年間は研究活動の立ち上げにあて、4年生から本格的に卒業研究が開始する、という流れなのだそうです。
ただ、3年生用の研究スペース(机およびPC)が無いので、研究室に3年生の居場所が無いらしい。。。
その為、共通の打ち合わせスペース（大きいテレビが置いてある）で、プログラミングの課題等の作業を出来るようにしたらどうかな、と考えています。
とりあえず今日は大きいテレビにPC（Linux/Centos）をつないで、Youtubeが見れたり、Eclipseが動いたりできるようにしておいた。数人でコードレビューをしたり、プレゼンやYoutubeを見てアイディアだしをしたりとか、そんなことが出来そうなスペースになるとよいなと。
あとは、打ち合わせテーブルの上にノートPCを置いてテンポラリな作業ができるようにすればよいかな・・・
ATLYSボード（Spartan-6）のAC97デモを動かす
DigilentのATLYSボードで、サウンド入出力（AC97）のデモを動かしてみました。
Atlys Spartan-6 FPGA Trainer Board (LIMITED TIME) - Digilent
DSD-0000325 12/13/11 This zip file contains an EDK demo project that illustrates how to use the AC97 codec on the Atlys board with Microblaze.
EDKのプロジェクトがあるので、ExportSDKをしてハードウェア（BitstreamおよびXML記述）をつくり、SDKにてC言語のプロジェクトを作成してソースファイルをコピーしてビルド。それだけで動きました。
ボード上のボタンを押すと1秒ぐらいメモリに録音して、また別のボタンを押すと再生する、それだけですが、まともな音質で録音再生できるので、結構楽しいです。
ソフトをちょっといじって、音声データを変化させて音量を2倍にしたり2分の1にしたり、簡単にできました。
趣味全開でやっていいのだったら、ギター用のエフェクタとか作ってみると楽しそうですね。
同じくDigilentで配っているHDMIのデモは、動きませんでした。
よく読むとGenesysボード用、と書いてありますが・・・ピン配置とか書き換えれば動くんでしょうかね？
DSD-0000326 12/13/11 This zip file contains an EDK demo project that demonstrates using HDMI on the Genesys board. It accepts an HDMI input, buffers the input frames into memory, and then outputs the buffer to another HDMI port. This is implemented using PLB bus.
プログラミング演習について考える
プログラムを書ける学生と書けない学生がいて、かなりはっきり分かれる、ということがいわれています。
見分けるためにはFizzBuzz問題を解かせてみれば良い、とか言います。企業の採用試験としてはそれでも良いのかもしれませんが、教員としては書けない学生を書けるようにするのが使命なのかなと思ってしまいます。
今期の２年生向けと３年生向けのプログラミング演習（の一部）を担当していまして、昨年度までのものを踏襲すれば良いかなと思っていたのですが、授業イメージトレーニングをしていると、やはり色々思うところがあります。
３年生向けのC＋＋に関して言えば、C言語との違いとクラスの作り方を学んだところで、自分でクラスを設計してみるというのが必要ではないか、と思っています。その後に継承を学ぶ前に、一度クラスを設計して、何をPublicにして何をPrivateにするか、自分で考えてみるという経験があった方が、継承についての理解も深まるというもの。
設計したクラスが良いのか悪いのか、判断が難しいという問題はあります。ただ、良い悪いの観点として何があるのか、というのは知っておいた方が良いでしょう。できれば、評価軸も自分で考えるのが良いと思います。
この先エンジニアとして生きていくためには、評価というものを避けては通れません。自分が作ったプログラムが／技術が良いのか悪いのか、世の中にある技術／製品が良いのか悪いのか、自分の価値観で判断して、その判断結果を他人に伝えて、説得していく、、そういうことが出来るようになることで、自分のエンジニアとしての価値（評価）が上がっていくものだと思います。
クラスを設計する、お題は何が良いでしょうか。「オブ脳」の本だと「社員起立」となっていますが、むしろオブジェクト指向に対して嫌悪感情が生まれてしまう可能性があります。銀行口座ぐらいがちょうど良いかもしれません。もちろん、クラスをテストする方のプログラムも併せて作るようにします。テストファースト、です。
２年生向けは、C言語でのソートなのですが、これもあまりいたずらに難解な問題にするとプログラミングに対する苦手意識ができてしまう危険があり、あきらめてレポートをコピー／同級生に頼るしかない、という状況を作ってしまいます。
研究室の学生に聞いてみたところ、やはり例年プログラミング演習では出来る学生と出来ない学生の格差が大きく、出来る学生は暇にしていて、出来ない学生は全く出来ない、という状況らしいです。結構単位を落とす人も多くて、必修のため留年に直結するという危険もあります。
出来れば、すべての受講生に自分自身の成長を感じてもらえるようにして、最低ラインを全員が通過できるような、そんな授業が準備できれば良いのですが。難しいんでしょうかね？
