みんな未踏に応募しよー。IPA的にも応募件数を増やしたいらしいよ。
僕はオペレーティングシステムで応募したのですが、一般的なことも書くつもりです。
ここに書いてあることは、あくまで僕が気をつけたことであり、採択理由ではありません。この中には逆効果な点もあるかと思います。ご了解ください。
準備が大切です。
応募までにやっといた方がいいことです。
一番なことは、アイディアの核を決めることと、書類をきちんと書くことです。
担当のPMの専門分野であれば、それ相応の内容を概要にも記述できるようになります。逆に専門外であれば、詳細な実践的な内容を削る必要があります。
万人に良い文章は存在しません。良い文章は、読み手を考えて書かれるものです。
あと、（普通は注意するのかな、）PMによって採択可能な金額の上限が結構ばらついてるんですね。お金を目的に申請する方は気をつけましょう。僕は何より自由に開発したかったので、金額にはあまり拘りませんでした。
綺麗で読みやすい文章を心がけました。
概要は、次のポイントについて分かりやすくまとめましょう。
次の引用は、実際の僕が提出した「提案テーマ概要」です。
現在のOSは、OS自体とアプリケーションの双方が基本的にCやC++を利用して開発されています。しかしC/C++言語は、オブジェクト指向への対応やメモリ管理の複雑さ、エラートラップ機構などが不十分であり、バグの原因となってしまっています。もちろんこれらの弱点を補った処理系は存在しますが、最終的にOSと対話する部分ではC++的な処理が必要です。さらにOS自体もCやC++などで記述されているために、バッファオーバーランなどの問題を抱えやすくなってしまっています。
これら課題の解決するため、Microsoftが提唱したILという中間言語を核にし、ILの実行環境であるCLIを実装したOSを開発します。
ILはC#言語などをコンパイルして得ることができますので、OSのライブラリをC#で記述することでOOPLと親和性の高いAPIを用意することができます。また、CLIのガーベジコレクションによって低レベルメモリ管理を行う必要が無くなります。さらに、現在はAPIのエラーチェックは戻り値によるものが主ですが、CLIの例外機構によって、APIのエラーをシームレスにトラップできるようになります。
アーキテクチャの側面からみた場合にも有利な点があります。現在はアプリケーションの機械語命令の動作を制限するためにプロセッサの保護機能を利用していますが、プロセス切り替えなどは重い処理でありボトルネックになっています。またプロセス保護のせいでプロセス間通信などの処理は非常に高コストです。提案するOSは、これらの保護機能の利用を最小限に抑えることができますので、従来OSよりも有利であるといえます。
長期的な視点では、WindowsがCLIベースに移行するなか他にそのようなOSが開発されていないことを憂慮しています。いまはLinuxがWindowsの対抗馬ですが、中間言語方式が普及してからLinuxを作り直すことは非現実的です。将来的に、中間言語ベースのWindows以外のOSが必要になる時が必ず来ます。
本プロジェクトでは、ILのような中間言語を基本にしたOSの試作を目的とします。試作するOSは、マルチタスク・マルチスレッドをサポートし、ファイルシステムを有し、WindowsやLinuxで作成した簡単なアプリケーションが動作することを目標とします。
もっとも重要な記述はその企画のアピールポイントです。これは単なる機能や性能の説明ではないことに注意してください。
アピールポイントの書き方によって、読み手（この場合はPM）が提案テーマ詳細説明を読み始めるときの受け取り方が異なります。アピールポイントには PM の好奇心を喚起するような言葉を選ぶべきであり、たとえば長々と機能を列挙するなどは最悪だと思います。
次の引用は、提案テーマ詳細説明の第一ページに記述を求められた、詳細説明の概要です。
本プロジェクトは、新しいオペレーティングシステムを試作することによって、その有効性を示し、将来同様のコンセプトに基づいて開発された後続のオペレーティングシステムの基礎となることを目指しています。
本OSの最大の特徴は、実行できるアプリケーションの命令形式をIL （Intermediate Language）に限定していることです。ILとはJavaのバイトコードと似た中間コードの一種であり、C#などをコンパイルすることで得られ、CLR（Common Language Runtime）という実行環境で実行することを想定しています。掲題のCLI（Common Language Infrastructure）は、ILやCLRを含むより大きな規格を指します。
ILはオブジェクト指向であり、型に基づくプログラミングが可能で、例外やガベージコレクタによる強力な支援を受けられ、例外機構によるエラートラップをサポートします。これらはバグの減少などの効果がありますし、OSの大部分をILで記述することによってアプリケーションだけでなくOSとしてもこれらの利点を生かすことができます。
また、別の特徴として完全に共有されたフラットなメモリ空間が挙げられます。CLIのソフトウェアは原則的には"検証されたコード"で成り立つため、OSを含むそのほかのタスクの動作を阻害するような命令は実行できません。そのため、全てのプロセスが同じアドレス空間を共有してもタスク同士が干渉することはできなくなっています。このことは、メモリ管理のためのオーバーヘッドの減少だけではなくプロセス境界を越える処理が非常に効率的になる可能性を示唆しています。
一方、中間コード方式の欠点はあまり目立ったものはないと考えています。この方式の一番のネックは速度だと言われており、確かに本プロジェクト計画ではリリースにJITコンパイラは含まないのでパフォーマンスが悪いでしょう。しかしJITは現在、従来のコンパイラを超える性能を出すまでに至っています。速度問題については単にJITがないというだけであり、本プロジェクトの目標である"後続OSの基礎となる"ということを妨げるものではありません。
CLIのように中間コードを念頭に置いた実行環境は、今後時代が要求するソフトウェアになります。そのような時代の流れも鑑みたとき、本プロジェクトは大きな意義があると考えます。
この文章にはA4一ページが割り当てられていますが、この文章量では明らかに足りません。足りない文は何を以て補ったのでしょうか。
僕は、空白を以て空く部分を埋めることにしました。書くことが無くて空白にしたのではなく、敢えて空白部分を多くしました。
このページは、第一ページです。多くの情報を不必要に詰め込むのはどうかと思います。
次の引用はたまたまディスクに残っていたボツになった原稿です。参考までに読み比べてみてください。
本プロジェクトは、新しい基盤OSを開発することによって、その有効性を示し、将来同様のコンセプトに基づいて開発された後続のOSの基礎となることを目指しています。
本OSの基本的なコンセプト自体は目新しいものではなく、1998年にJavaOSという形ですでに発表されたものです。JavaOSでは、OSが実装するものは基本的なカーネルと仮想マシン（VM）だけであり、OSとして要求される基本的な機能までJava言語で記述してしまうという特徴がありました。しかし、JavaOSのメインターゲットは組み込み向けであり、動作はするもののPCに主眼を置いてはいません。また、2000年以降は目新しい報告もされなくなってしまい、現在ではウェブを検索してもあまり新しい報告は見つからなくなっています。
JavaOSの最大の特徴は、アプリケーションを機械語命令ではなくバイトコード（中間コード）で構成させることで、これによって後述する様々な利点を得ることが出来ます。
ところで、近年、Javaと同じような実行環境を持つ全く別の基盤が登場しました。それが本プロジェクトと密接な関係にある、Microsoft.NETとCLIです。（.NETの方が名称として有名ですが、厳密にはCLIなので以後CLIとします。）本プロジェクトでは文書中で述べるいくつかの客観的な理由によって、JavaではなくCLIを基本技術として採用しています。
次にCLIをOSの基盤とした場合の利点について説明します。
CLIも（Javaと同様に）、オブジェクト指向の厳密な型に基づくプログラミングが可能で、例外やガベージコレクタによる強力な支援を受けることが出来ます。これらは通常はアプリケーションプログラムに対してバグの減少などの恩恵をもたらしていますが、当然OSのカーネルなどにも同様の効果が期待できます。
また、完全に共有されたフラットなメモリ空間も重要です。CLIのソフトウェアは基本的に”検証されたコード”であり、OSを含むそのほかのタスクの動作を阻害するような命令は実行できません。そのため、全てのプロセスが同じアドレス空間を共有してもタスク同士が干渉することはできなくなっています。このことは、プロセス境界を越えることが非常に効率的になる可能性を示唆しています。
他にも一般的なモデルのOSでは実現不可能な利点がいくつかあります。一方、欠点はあまり目立ったものはないと考えています。ただ、本OSの最初のリリースにJITコンパイラは含まないので、当初はパフォーマンスが恐ろしく悪いでしょう。しかしそれはCLI-OSの限界を示すものではなくて単にJITがないというだけであり、本プロジェクトの目標である”後続OSの基礎となる”ということを妨げるものではありません。
CLIのような、中間コードを念頭に置いたOSというのは、今後時代が要求するソフトウェアになります。事実、Microsoft社のLonghornから.NETが基礎になっていくことがすでに示されています。このような時代の流れも鑑み、現時点で本OSのようなソフトウェアを開発することは意義のあるプロジェクトであると考えます。
なお、僕が提出した「提案テーマ詳細説明」書類は、冒頭の一ページを含み全部で７ページでした。
応募書類には、どうしても大きなことを書いてしまいたくなります。たとえばOSですと、Windowsを超えるとか超えないとか、普及するとかしないとかといったことです。
PMの記述要点に展望といった項目がある以上、期間内では実現不可能なことも書くのは大言壮語ではなくて絶対に必要なことだと言えます。しかし、「未踏での達成目標」とそれら「将来的な展開」を混同させるような曖昧な表記は避けるべきです。
僕のの場合では、「完成は不可能」であることをはっきりを申し上げた上で、「試作」などといった言葉を用いました。また実用化や普及についても、面接の段階で「期間内では不可能だ」と明言しました。（ですから、ネットなどで普及や実用的なポイントを指摘されても、実は全然痛くもかゆくもないのです。） 次の引用は詳細説明文書と面接プレゼン資料における該当箇所です。
性能や見た目、信頼性などの点で本当に"勝負"できるOSを期間内に実現することは難しいと思いますが、ILをそれなりに実行できるようになるのはそれほど困難ではないと考えています。
客観的に述べて、本OSが将来にわたり存続する可能性は小さいと思いますが、そのようなCLI型OS開発の基礎となることができれば計り知れない効果があると考えます。
「え？ なんか実現不可能ポイントって印象じゃないんだけど？」 そりゃそうです。都合悪いことだけを書いて文を切ってはいけません。
提出書類は、PMの興味を引くことを最優先に、目的と、目標と、展望を書きます。この場合の目的とは、なぜそのソフトウェアが必要とされるのか、なぜ"未踏"なほど困難なのか、開発動機といったものです。また目標とは、成果物のソフトウェアによって、利用者が何を実現できるのか、および何が出来ないのかということです。展望は、そのソフトウェア単独では為しえないが、普及したと仮定すれば達成されることなどです。
普通のパソコンユーザに、上述の３点を説明して、何らかの期待を抱いてもらえるような表現を心がけましょう。
提出書類は後々までプロジェクトを"縛り"ます。（申請後にあっさり内容変えちゃう人ってどうなんですかね…。） これを未然に防ぐためにも、もっとも基本となるアイディアを中心に据えた文章を書きます。あれもこれも、というのは良くありません。
未踏では申請時にソフトウェアがなくても採択されてしまうのがすごいところです。
しかし、ひな型でも何でも良いので、動くものが作れそうなら作っておくといいと思います。僕の場合は OS という極めつけに「動いてなんぼ」の品物でしたので、面接までに死ぬ気で作ってました。「しょぼぃデモなんてしたら逆効果じゃない？」 それは一理ありますが、どんな道具でも使いようです。
もっとも避けるべきなのは、PMにあまりよく理解してもらえないまま不採択になることです。
僕のPMの場合は採択までに一度面接がありました。全員なのかは定かではありませんが、他にも面接するPMは結構いるようです。
面接は一般的なプレゼンテーション形式でした。２０分ほど好きに発表し、そのあと質疑応答でした。僕はパワポにデモという至極普通な方法でのプレゼンでした。
これについては一般のプレゼンテーション技法のドキュメントでもあたってください。未踏への批判の中に「プレゼンでうまいこと話して採択…」というものがありますが、どこだって選考とか採択ってそんなもんです。現状の条件下で、プレゼンや面接に頼らず審査する方法をお持ちでしたら教えて頂きたいです。
また、採択者にはIPA主催の発表会への参加が義務づけられていますので、プレゼンが上手いのは必要条件だという見方もできます。
（章節の組がちょっと変になってしまった。）
応募して、面接も終わったら、祈ってましょう。最後は運ですかね。