未踏プロジェクトは2010年事業仕分けによる影響もはねのけ、めでたく公募がスタートしました。
僕のまわりにも早速応募しようという動きがちらほら見受けられます。たまに未踏プロジェクトに関して相談を受けます。エンジニア的には並のスキルしか持っていないので、技術的なアドバイスはサブカルパジャマトークで述べているようなアイディア、コンセプトベースのものしかできませんが、そんな僕でもいくつか役に立つことは言えるかと思い、「必勝!未踏プロジェクト・スーパークリエイタ奪取マニュアル」と題して原稿を書いてみました。本当はこの原稿はサブカルパジャマトーク同人誌として発表する予定だったのですが、諸事情によりストップしているうちに未踏の公募が始まってしまったので、旬が切れないまさにいまのうちに発表しておこうと思います。
僕は特に優秀なエンジニアというわけではありませんが、いくつかのポイントを守って、スーパークリエイタに選ばれました。どうも他の人の未踏プロジェクトへの取り組みを振り返ってみると、自分は他の人とは違うポイントに力を入れており、そのあたりを含めて未踏プロジェクトへの応募からスーパークリエイタ取得までのフローのまとめてみようという企画です。そんなわけで、スーパーエンジニアじゃないけどスーパークリエイタになってみたい人、未踏プロジェクトに応募したいと考えている人などは読んで損はないのではないかと思います。
スーパークリエイタになるとこんないいことがあります
アドバイスを始める前に最初に僕がスーパークリエイタになって良かったと感じた点をいくつか紹介しましょう。
まず、スーパークリエイタになるとそれをネタにポッドキャストをすることができます。だいたい、スーパークリエイタなんていう称号を仮にも国が認可した独立行政法人であるIPAが送っているわけですから、これをネタにしないで何をネタにするという感じです。スーパークリエイタを取得したら、ぜひポッドキャストやUstreamを開始することをおすすめします。
また、スーパークリエイタになると会社で「スーパークリエイタ」とからかわれます。特に大企業に就職して、まだたいした成果を上げていない新入社員がにスーパークリエイタになってしまうと若干微妙な空気が流れますので、気を付けましょう。対策として、スーパークリエイタがひしめくGoogleなどに就職、転職することで自分をスーパークリエイタの集団の中に埋没させる、などを検討しましょう。
最後にスーパークリエイタになると必ず仲の良い友達から「ハイパーメディアクリエイタ」とからかわれます。特に今は沢尻エリカの騒動でハイパーメディアクリエイタがHotであるため、まず間違いなくからかわれると考えてよいでしょう。その場合は、開き直って、自分のことをスーパークリエイタではなくハイパーメディアクリエイタと名乗ることで事態を打開することが可能です。
では、スーパークリエイタになる圧倒的なメリットもご理解いただいたところでさっそく本題に入りましょう。
スーパーエンジニアじゃないとスーパークリエイタにはなれないのか
これは明確にNOでしょう。
「自分がスーバーエンジニアではないので未踏プロジェクトには応募できない」と思っている人がいたら考えを改めるべきです。ソフトウェア開発において、必ずしもスーパーエンジニアは必要ありません。もちろんソフトウェアの最終的な到達点とエンジニアの技術的な力量は強い相関があると思いますが、Web系の技術に関してはすでに学習の高速道路とでも呼ぶことができるものが存在しており、Webアプリを作るということであれば人並以上程度のエンジニアとしてのスキルがあれば作れないというモノは基本的にはありません。もちろんそれがどのくらいスケールするかや、実用的なスピードで動くか、という点ではエンジニアのスキルの差が如実に出ます。ただ、言語やOSの拡張、高速なライブラリの作成などがテーマの場合は、これまでの学習、スキルの積み重ねがものをいうので、それらのテーマはスーパーエンジニア以外は選んではいけません。無謀ですし、あなたが取り組まなくてもエンジニアリング的におもしろそうな問題は勝手にスーパーエンジニアが解決してくれます。
ではスクリプト言語、JSのような高速道路系スキルだけで、Webサービスを作り未踏プロジェクトに採用されるかというと、それもまたかなり厳しいです。というのも、ウケのいい現実社会の問題解決という視点が未踏プロジェクトには必要だからです。このあたりは、プロジェクトマネージャーの募集テーマにも関わってくるので、一概にどのようなテーマが必要かを判断するのは難しいのですが、まず何よりスーパーエンジニアが採用しそうなテーマは避ける必要があります。もし、他のスーパーエンジニアが同じテーマを採用したら不利な勝負になります。世の中にはまれにものすごい集中力でそれこそ24時間プログラミングを集中して行えるスーパーエンジニアが存在します。漫画の中の話ではありません。スーパーエンジニアとのテーマの衝突事故を避け(ほとんど交通事故みたいなもので遭遇したらまずどうしようもありません)、知見の不足等で参入障壁がある分野にこそ活路があります。例えば、グリーンITなどの誕生間近な分野が該当します。
エコとは恐ろしい分野で、まずエコな状態とは何なのかを自分で定義する必要があります。アル・ゴアを思い出してください。あれだけ二酸化炭素排出で金を荒稼ぎした男が、二酸化炭素はそもそも北極海の氷の融解と科学的に関係があるという根拠はないという見解が一般的になるやいなや、新たなエコの定義を探し始めています。このような、曖昧な問題設定をスーバーエンジニアは嫌います。というか、エンジニアならだれでも嫌いです。自分のスキルに自信があるならばエンジニアリング的パフォーマンスで成果を出すことに注力したほうが効率がいいですし、評価も安定するはずです。しかし、そのようなテーマを普通のエンジニアは選んではいけません。むしろ、まだ問題さえうまく設定されていない荒野のような領域に入り込み、自分で、問題を見つけて、その問題が社会にとって大きな課題であることをPMに説得し、世の中で認知されていない問題の最初のパイオニアになることを目指すべきです。おそらく、無難なテーマを設定するよりもそちらの方がずっと良い結果に結びつきます。
応募プロジェクトのテーマを決める
世の中のプロジェクトにおいて、問題発見と設定のプロセスは重要です。未踏プロジェクトにおける最初の正念場と言っても良いでしょう。出来たら、このタイミングでこそ多くの人の意見を聞くべきですし、時間も割くべきです。ここで、方向性を間違えると、応募したプロジェクトは採択されずスタートラインにも立てません。
テーマ決めの最初のタイミングでプロジェクトマネージャー(以下PM)の傾向を掴むのが先決です。PMの研究、事業領域において興味はありそうだが、まだ事業化されておらず、資本が投下されていなそうな分野が良いです。今は、そのようなPMが個人的に興味を持っていそうな分野を調べるのに最適な方法があります。twitterです。未踏のプロジェクトマネージャーの多くはtwitterアカウントを保持しています。軽くネットストーキングな匂いもしますが、PMの興味にこれほど手っ取り早くアクセスする方法はありません。
例えば、2009年にPMをした夏野剛さんなら「非効率な日本の大企業を批判すること」が彼のメインテーマであることが簡単にわかると思います。特にボトムアップに決定を行うことができないその硬直した意思決定システムにはたくさん不満があるようです。さて、その部分を効率的に解決するソフトウェアというのは世の中にそれほど存在しません。TracやBugzillaなどのバグトラッキングシステム(BTS)が該当するかもしれませんが、それらはあくまで問題、不具合解決の方法であり、意思決定手段ではないでしょう。しかし、今は新たなコミュニケーション方法がたくさん提案されています。たとえばgoogle waveによって、大企業特有の非効率なコミュニケーションを改善するソフトウェアはどうでしょう。使うスキルは基本的にスクリプト言語やJSです。むしろ必要なのは問題設定能力と多くの関係者にヒアリングを行って回るフットワークの軽さとなるでしょう。どのような分野でどのような問題があるのか、ヒアリングし分析することは一般的なエンジニアにとってなかなか腰の重いことですが、だからこそコストをかける価値があります。
このように、プロジェクトマネージャーを分析し、ネットワークストーキング的手法も活用して、問題設定を正しく行うことが出来れば、かなり有利に選考を運ぶことができるはずです。さすがに必勝というわけにはいきませんが。
プロトタイプ作成の重要性
ここまでで何らかの形でテーマが決まっているとします。次にやるべきこと実現可能なプロトタイプの作成です。これは最近に限った話ではありませんが、応募者の半数程度は現在大学、大学院で取り組んでいるテーマをそのまま応募してきます。特に東大暦本研や五十嵐研は未踏プロジェクトが学生、大学院生にとって重要な研究の資金源になっています。正直、これはどうなんだと思うかもしれませんが、これはどうしようもない現実です。昔のようにPMとエンジニアが結託して2年間そのPMの研究領域に資金を供給し続けるような例が無くなった分、健全化されています。
さて、大学での研究領域をそのまま未踏プロジェクトに持ってきた例を覗き、新規にプロジェクトを提案している場合、提案するソフトウェア、システムのプロトタイプ作成は非常に重要です。どのPMもプログラミングが根本的にあまり出来ない人、言葉だけで実装能力のない人のプロジェクトを採用したくはないですし、だいたいのソフトウェアはプレゼンで多くの言葉を尽くすより、実際に動くモノを見せた方が、何倍も説得力があります。
なお、プロトタイプ作りを他の人に手伝ってもらうのはおすすめしません。PMとの面接ではかなり細かい部分まで、突っ込まれますので、自分でプロトタイプ作りを行っていない場合、発表のディテールの不足は得てして致命傷になります。逆にいうと設定するテーマは自分でプロトタイプ作成を行える程度の難しさに設定する必要があります。自分にとってコア技術が明らかに理解不能である場合は、課題を見直す必要があるでしょう。
ここではあまりデザインやユーザビリティにこだわる必要はありません。後述しますが、それらの課題はできるだけ外部化し、プロとタイムではそもそも提案しているテーマがソフトウェアで解決可能なのかどうかを説明する、という部分に注力すべきです。
未踏プロジェクトの応募書を作成する
プロトタイプの作成と並行して、未踏プロジェクトの応募書の作成にとりかかりましょう。基本的なフォーマットをPMが提示しているはずですので、そちらに必ず準拠してください。ここで細かくフォーマットを守れない人は実務能力を疑われるので、フォーマットは気を付けましょう。
プロジェクト採択の倍率はPMによってかなり大きく異なるのですが、だいたい5倍から10倍程度であることが一般的です。応募書の作成では、最初に定めた課題をしっかり説明することを意識する必要があります。各PMの傾向を調べ、設定した問題に基づく応募書を作成しましょう。作成した応募書は可能であれば、未踏経験者にレビューしてもらうことをおすすめします。
もし、この原稿を読んでいることをお伝えいただければ、僕もレビューに協力させていただくので、是非ご連絡ください。可能であれば、レビューは複数人にお願いし、多角的な意見を反映したほうが良いでしょう。レビューでチェックしてもらうべき箇所は、問題設定の甘さや論理破綻が応募書内に存在しないかです。誤字脱字などは、最低限のチェックで十分です。
レビューしてもらう人にも、問題設定の部分を重点的にレビューするようにお願いしましょう。ただし、テーマ自体を否定された場合は、すでにプロトタイプ作成も完了していたら、なかなか見直す時間がないでしょう。その場合は、応募書内の今後の課題などに指摘されたテーマの甘さ自体をリストアップし、自分が課題を客観的に捉えることができていることをアピールする道具にしましょう。
さて、レビューが完了し、応募書が完成したらあとは運だけです。どんなに優れた企画であっても、全てはPMの気分で決まります。だいたい一ヶ月程度で面接の連絡がきます。応募したあとは心配しても仕方がないので、プロトタイプでもいじりながら気楽に待ちましょう。
PMへのプレゼン、面接を勝ち抜け
応募したプロジェクトをPMに気に入られた場合、PMに対するプレゼン、面接の連絡がきます。連絡がきたらすぐにプレゼン作りに入りましょう。
ここで覚えておいて欲しいのですが、世の中の大半の人はまともなプレゼンなどできないのです。というのも、プレゼンを練習する機会なんてほとんどないですし、あったとしても自分のプロジェクトが採用されるかどうかをかけたプレゼンなど、社会人になっても、そこそこのポジションにならなければ体験できません。ここで認識しておくべきポイントは、何か結果を発表するプレゼンと、プロジェクトマネージャーから予算をゲットし、自分のプロジェクトを採用してもらうプレゼンは全く別ものだということです。
そのことを端的に示した本がガー・レイノルズの「プレゼンテーションZen」です。このプレゼンで行うべきことは、大学の授業の最終週で行っていたような、原因、実験、結果、考察の手順にのっとったプレゼンではなく、プロジェクトの予算をゲットするいわば勝負事です。他の人より優れたプレゼンをすることがまず大事であり、その点を追及する必要があります。
| プレゼンテーション Zen | |
 | Garr Reynolds ガー・レイノルズ 熊谷 小百合 おすすめ平均   頭ではわかっていることができないことがよくわかる日本人にとって当たり前の感性の再確認 全国のMSPPオペレータに告ぐ他とはちょっと違う。禅の侘び寂びの思想を生かしたアメリカンチックなプレゼン思想書Amazonで詳しく見る by G-Tools |
また、テーマ、問題設定の重要性が未踏プロジェクトのプレゼンにおける肝になります。この部分でテーマ、課題設定の根拠が弱いと、それだけでプレゼンにとっては致命傷になります。テーマに関連する人たちに対してインタビューを行い、その動画をうまく活用するなど、より説得力のある構成を考えましょう。例えば、先ほどの大企業内でのコラボレーションを課題とするならば、このような問題に直面している人は世の中に多く存在しますし、違う手段でそのテーマにチャレンジしている人も多いでしょう。可能であれば、それらの問題に関わる人のヒアリングをすすめておき、プレゼンにうまく活用することを検討してください。
まあ、ここまでやってもプロジェクトは落ちるときは落ちるものです。だいたいほとんどプロジェクトマネージャーの気分で決まるものなので、あまり深く考えてもしょうがありません。プレゼンが終わったら、あとはどうしようもないので、結果を待ちましょう。
プロジェクトが採択されたらまずスケジュール作成
もしこのあとPMからメールで連絡がきて、応募テーマが未踏プロジェクトとして採択されたならば、一番最初にやるべきことは具体的なスケジュールの作成です。
リリースレベルのソフトウェアを作成したことがない人は特に陥りがちなのですが、たとえば6月にプロジェクトが採用された場合、おそらく以下のようなスケジュールになります。
- 6月 未踏プロジェクト採択
- 7月 キックオフミーティング
- 12月 中間発表
- 2月 最終発表
今年はだいぶ時期がずれているので、プラス3ヶ月くらいで考える必要があるでしょう。上記スケジュールだった場合、少なくとも1月までには全機能が実装済みであるようにスケジュールを立てるようにすることをおすすめします。
多くの人は知っているかとおもいますが、ソフトウェアの1stリリースで完成度の高いソフトウェアを作成するということは、非常に奇跡的なことです。ほぼ不可能と言っても良いでしょう。特にこれを読んでいる人は、一応目標はスーパークリエイタということになっているので、最低でも一回、可能であれば、2回くらいのパブリックリリースを行ない、リリースから評価までのイテレーションを回すことが望ましいです。
なぜなら、リリースして評価してもらうというのが、結局一番効率が良いソフトウェアのブラッシュアップのプロセスだからです。例えば、作ってみないとわからない事がユーザビリティの点では多々あります。また、自分が作っているものを客観的に評価すろことは難しく、さらにそのソフトウェアに半年集中していればなおさらです。
スーパークリエイタを目指している以上、当然ソフトウェアの完成度は重要なファクターであり、他のソフトウェアが2月の完成を目指すなか、イテレーションを回すことが出来ればそれだけで大きなアドバンテージになります。
デザインやユーザビリティをどのように担保するか
未踏のソフトウェアでは、そのコア技術のみが注目され、ユーザビリティがおろそかになりがちだが、デザインとユーザビリティは最初から考慮するに値する要素です。デザインが良い出来であれば、最終プレゼンでの良いアピールポイントになりますし、ユーザビリティテストを行ったりして、関係者からのフィードバックを得ることが出来ていれば、それらは客観的な評価としてうまく活用することができます。
ただし、未踏プロジェクトで最も重要なのはやはりコア技術であり、デザインやユーザビリティもコア技術と比較した場合、どうしてもおろそかになると思います。ここで、僕はデザインとユーザビリティは、開発初期から詳しいメンバーを開発者に加えることをおすすめします。未踏プロジェクトでは、最初に申請したメンバーから他のメンバーを加えるのはなかなか難しいので、後から参加してくれるデザイナーやユーザビリティに詳しい開発者への謝金は最初は開発者からの持ち出しになる可能性があります。
それでも、デザインやユーザビリティを他のメンバーに任せきることができれば、それはとても価値があります。フロントエンド全般を優秀な開発者にまかすことが出来れば、安心して自分はコア技術の開発に専念出来るため最高ですが、なかなかそこまで準備すろことは難しいかもしれません。ただ、トライする価値はあると思います。
PM対策は忘れずに
当たり前の話ですが、最終的な評価を受けるのはあくまでPMからです。未踏プロジェクトにおけるPMは最近は海千山千のビジネスマン的な人物がアサインされていますが、きちんとした評価をしてもらうためにはプレゼンだけではなく、きちんとコミュニケーションを取り続け自分たちの狙いや進捗がきちんと伝わる体制を構築しましょう。
PMの進捗確認方法は、かなりまちまちらしく１ヶ月に一度e-mailで進捗確認があるだけのPMもいれば、２週間に一度はミーティングを行ってくれるPMもあるようです。ただ、ここで重要なのは言い訳せずに自分たちの労力をすべてプロジェクトに費やしていること、プロジェクトが進捗していることをきちんとアピールすることです。たまに、アピールしなくてもプレゼンなどでのアウトプットがしっかりしていればプロジェクトの価値がわかってもらえると考えたりする人がいるのですが、PMはそこまで暇ではありません。きちんとアピールしないと基本的には評価してもらえないと考えた方が無難です。そんなわけで、レポートやミーティングもアピールの手段と考え積極的に利用しましょう。
どのようなアピール方法が好まれるかは、各PMによって異なると思われるため、ここでは詳細に書けませんが、設定した課題にどのように真摯に取り組んでいるかを説明することが重要なのは間違いありません。
中間発表対策！
さて、いろいろ開発を進めて行くと中間発表会があります。中間発表をどのように捉えるかは結構難しい問題です。というのも、スケジュールを早めに組んでいれば、だいたい11月、12月の中間発表の時点で、ほとんどの基本機能は揃っていることになるからです。このときに、全ての機能を中間発表で見せてしまうと、最終発表までの追い込みの時期の見かけ上の進展があまりなくなってしまうんじゃないか、と心配するかもしれません。まぁ、しかし、そこは出し惜しみせずに中間発表ではここまで作ったものをすべて余すことなく見せましょう。なぜなら最終発表では、中間発表で発表したものも含めて、未踏プロジェクトを通して開発したものすべてを発表するからです。むしろ中間発表で、計画以上のソフトウェアを提出することができ、最終発表までにそこから追加で開発を行うことができれば、高い評価が期待できます。
さて、中間発表対策ですが、ここで達成できる事というのは、プロジェクト開始時のテーマ設定にだいぶ影響を受けると思います。というのもテーマとして壮大な青写真を描いた場合は、どうやっても中間発表までではモノになっていない可能性があるからです。しかし、中間発表でソフトウェアがまだほとんど動いていない、プロトタイプの時から進歩していないというのは非常にバツの悪いものです。正直、中間発表でまだソフトウェアが動いていない、プロトタイプからほとんど進展がない場合、本件の主題であるスーパークリエイタの獲得はかなり厳しいと思います。しかし、未踏の中間発表会を見ると、実際はプロトタイプの状態から毛が生えた程度しか進化していないソフトウェアがたくさんありました。
この状況を見て、なぜこのような事態が起きるのかを考えて見たのですが、一つにアウトプットではなく技術を重視してしまっているというタイプの人がこの状況にはまりやすいのかなーっと思いました。というのも未踏プロジェクトは基本的には新規性のある技術の開発なのですが、そのコア技術を従来手法からさらに良くするというテーマだったりした場合、プロトタイプでは従来手法とそれが実現する結果を見せ、中間発表までにその従来手法を改善したりして、なんとか形にしようと頑張ったりします。しかし、これが結構罠が多くて、従来手法がどうしてオーソドックスな手法だったかを考えると、境界条件が結構うまく処理できたり、突飛なデータに対しても結構ロバストだったり、ある程度予測がつきやすく扱い易い手法だったりするので、従来手法だったりするわけです。これを刷新しようとする場合、そもそも従来手法との比較がメインテーマになるのですが、中間発表までにこの比較を行うっと言うのが、単純に時間が不足して結構難しいんですよね。なので、アウトプットを重視してスケジュールを組んでいないと、中間発表では結局アピールすることもなく、ただここまで必死で実装を行っていました、という発表になりがちになるのではないかと思います。そんなわけでアウトプット指向は中間発表対策を考えても重要です。
中間発表後の追い込みをどのようにかけるか
最初に述べた方法に従うなら、中間発表後くらいにはなんとか開発したソフトウェアのパブリックリリースを行いたいものです。Twitterなりブログなりを駆使して、可能な限り多くの人にソフトウェアを触ってもらうのがいいでしょう。といっても、なかなかパッケージ系のソフトウェアをトライしてくれるという人は珍しいですから、このようなケースではWebで動作するサービスが強みを発揮します。フィードバックは非常に貴重ですからクックパッドのサイトのように最もフィードバックを送りやすい箇所にフォームを作成してしまうのも良いかもしれません。
フィードバックはたくさん集めれば集めるほど良いです。この部分をおろそかにすると次の最終発表で自分のソフトウェアの評価を自分でおこなうというかなり寒いことが起こります。しかし、パフォーマンスを計測して発表する類のソフトウェアではない限り、基本的に関係者に利用してもらわないかぎり、自分の設定した課題が克服されたのか、適切にテーマは成し遂げられたのかを評価するということは難しいものです。
そんなわけで、中間発表後の追い込みはフィードバックをどのように集めるかとセットにして考えましょう。この部分は予めPMに相談しておくというのも良いかと思います。「どのようにフィードバックを集めたら良いでしょう」という相談に対して、ノってこないPMはたぶんいません。特にビジネス系のPMはこの部分がどれくらい重要かを知り尽くしているからです。あらゆるつてを使ってフィードバックをかき集めることをおすすめします。
最終発表で何を発表すべきか
さて、ここまで必死で開発を行ってきたかと思いますが最終発表がやってきます。ここで今までの発表成果を充分にアピールできればスーパークリエイタへ選出されるわけですが、アピールの仕方をいくつか考えてみたいと思います。
まず、デモは非常に重要です。「デモをきちんと会場で動かせる環境を用意する」ということにはかなり労力を割いて良いと思います。最初の採択時のプレゼンの時にも述べましたが、結局この未踏プロジェクトを通してあなたが成し遂げたことを客観的に見てもらう方法はデモしかないのです。もしデモができないようなソフトウェアならばその時点でスーパークリエイタのようなほぼ相対評価で与えられる資格を取得する競争力はないと考えてよいでしょう。なので、デモは可能な限り見栄えがして、誰が見ても理解することができ、興味をひくようなものにすることを心がけてください。
また、もう一点、最終発表はここまで集めてきたフィードバックを有効に活用する最大のチャンスです。たとえば、印象的な感想やフィードバックはそのままプレゼンをアピールする材料として利用可能ですし、それが難しい場合も何人の人にテストしてもらい、どのような評価をもらったかということに対する客観的な事実はPMがあなたのプロジェクトに対して良い点をつける強い動機づけになります。
ここで見てわかるとおり、あなたはPMに対してPMがこのプロジェクトに良い点をつける理由を作る必要があるのです。というのも、基本的にはPMは自分が監督した未踏プロジェクトに対して良い点を付けたいと考えています。それは、自分がここまでコストを割いて監督してきたソフトウェアでもありますし、評価の高いソフトウェアがリリースされればそれはイコールの自分の業績にもつながるからです。なので、最終発表ではPMがこのプロジェクトに対しては良い点をつけても良いな、と考えるだけの理由をきちんと用意するようにしてください。その中でもデモとフィードバックがキーになるのではないかと思います。
そんなわけでスーパークリエイタになったら
最終発表も終わり、報告書も出した後はいよいよスーパークリエイタの選出が待っています。
ただ、ここまで努力して労力を割いたとしてもスーパークリエイタになれるかどうかは結局運次第なのがなんともいえないところなのですが、最終発表で良い評価をもらうことができた人はきっとスーパークリエイタに選ばれることになると思います。
運良くスーパークリエイタを見事に取得できた場合は、是非@gamellaにTwitterなどで一報いただけると非常にうれしいです。