提案書を読んでもったいないと思った部分を紹介します。採択はぶっちゃけ運です。

未踏ジュニアメンターの寺本です。今年もたくさんのご応募をいただきまして、ありがとうございます。

今年は丸三日ほどかけて、全 115 件の提案に目を通しました。測ってみたら大体一件あたり 15~30 分ほどかかっていたので、それなりにちゃんと読んでいます。自分の知らないテーマが来るとググって調べたり、提案者のポートフォリオサイトを覗いたり、既存のものがあるか独自に調べたりもしているため、新鮮な知識が得られるのはありがたいです。

未踏ジュニアの審査は各メンターが採択を決定する権利を持っているので、百点満点のテストのような減点法とは対照的に、ひとつの特徴がズバ抜けて秀でている（とメンターが思った）人は、一点突破で採択が決まる可能性があります。逆に、提案自体は面白いのに、タイミングが悪いせいで不合格になってしまうこともあります。正直言って、そこは運です。すみません。

一方、今年は提案書全体のクオリティが一段上がったようにも感じました。過去の採択者の提案書をダウンロード出来るようにしたことや休校になって思ったより長く時間が取れたことも関係しているのかも知れません。これは喜ぶべきことなのでしょうが、僕個人としては、実は面白いのに提案書として上手く表現できていない “もったいない提案書” もあるのではないか、いやあるだろう、と勝手に思ってしまうのです。

そこで今年は、提案書を読みながら「こういう所がもったいない」と思ったポイントをメモすることにしました。115 件から抽出したので結構な量になってしまいましたが、この記事にまとめたいと思います。

注意事項

これは未踏ジュニアの公式見解ではありませんので、あくまで１つのものの見方として、「ヘ〜こう思う人もいるんだな〜」くらいに思ってください。

この記事は「これさえ抑えれば受かります」的なチェックリストではありません。いくらかはマイナス要素を減らせるかも知れない、というものです。

本記事で紹介する内容はそれなりの数が観測された特徴であり、特定の個人（N=1）の内容は含まれません。もしも本記事が自分のことを言われているように感じてしまったら、ごめんなさい。あなたのことではありません。

前置きが長くなりました。では、もったいないとポイントを紹介します。

すでにプロトタイプやモックを作り始めているのに、上手くアピールできていない

No. 1 もったいないで賞を選ぶなら、間違いなくコレです。具体的には下記のような事例が存在します。

プロトタイプのキャプチャ画像（ハードウェアなら写真）を貼っていない
文章だけで提案のスゴさがアピールできたら、逆にスゴいと思いませんか。特にゲームの提案で画像を貼らないのは、縛りプレイも同然です。そんなハンデを負う必要はないのです。画像を貼って楽をしましょう（お互いに）。

画像または “何らかのリンク” を貼っただけで、言葉で説明していない
画像は大事と言いましたが、かと言って文章が全く無いのも良くないです。喩えるなら、相手の眼前に無言でスマホの画面を突きつけて「伝われ〜〜」と念じているようなものです。テレパシー能力者じゃないので厳しいです。
リンクを貼るときも、それが何のリンクなのか説明しないと開いてもらえません。例えば「映像の方が分かりやすいので、デモ動画を YouTube にアップしました」と一言書き添えてくれたら、喜んで観させていただきます。

ソフトウェアの実行ファイルやソースコード（リポジトリ）だけ送る
プロトタイプがあるのは素晴らしいし、ぜひどんなものか見てみたいです。でも、知らない人が送ってきた実行ファイルを片っ端から実行する審査ってちょっと怖くないですか。応募者は素性が知れてるから大丈夫だと言う人もいるかも知れませんが、キャプチャか YouTube のリンクを添えていただけると安心します。メンターの趣向をハックするのは構いませんが、メンターのマシンをハックするのは NG ですのでご了承下さい。
ソースコード（リポジトリ）を貼ってくれるのも嬉しいですが、ビルドして実行までしてくれるメンターはあまりいないので、それだけではアピールになりづらいので、やはりキャプチャも以下略。

太字や文字色を使い過ぎて、どこが重要なのか分からない

伝えたい思いが溢れているせいでしょうか。太字、斜体、文字色などの書式設定を多用してしまっている提案書があります。１つの段落に３つも４つも太字があると、「結局何を強調したいの？」と思ってしまいます。

伝わるかどうか心配なのは分かりますが、我々メンターは、皆さんが書いてくれた文章をきちんと読んでいます。ここぞ！と言う所にだけ太字を使ってくれれば十分です。太字＝必殺技と思ってください。外すと隙が大きい技。

アイデアを全部並べただけで、優先順位を付けていない

たくさんあるアイデアをすべて同時に試すことは出来ないので、優先順位を付けて順番に取り組むことになると思います。その優先順位を提案書の方にも書いておくと、実現可能性が高く感じられてプラスに評価されます。

優先順位のないアイデアの羅列はハッキリ言って、ただのメモです。メモのまま送るということは、あまり時間を掛けられなかったのかな？と僕はそうします。提案者があまり時間を掛けられないプロジェクトというのは、少し心配になってしまいます。ぜひ優先順位を付けてプロジェクトに取り組み、「私はすでにこれだけのことをやっているぞ！」とアピールしてください。

最近の人工知能はすごい→このプロジェクトもすごい、という論理的でない主張

「人工知能を使えば夢のようなことが簡単に実現できる」と思っている方が一定数いるようです。アイデアコンテストであれば「人工知能でチョチョイのチョイ！」で入選する可能性もありますが、未踏ジュニアでは実現可能性をしっかり主張してください。

それは単に実現可能かどうかを判断するだけでなく、提案者にその実力が（またはのびしろが）あるかどうかを見ているからという理由もあります。今は実現方法が分からなかったとしても、調べたところまで書きましょう。

誰がいつどこで利用するのか不明なツールやサービス

これは提案内容にもよるのですが、「誰かが使うもの」を作るのであれば、ユーザーがそれを使っている情景がありありと目に浮かぶことが理想です。よく分からない方は、ユーザー視点で 5W1H にまとめてみましょう。

ポイントは「ユーザー視点で」考えることです。「私がこうなって欲しい」という主張はユーザー視点ではありませんので、きちんと分けて書く必要があります。提案者の思いは、専用の項目があるのでそこに書くと良いです。

誰かが直接使うものではない（アート、基礎研究 etc）場合、ユーザー視点というものがありませんよね。そういう時は無理に書く必要はありません。

また、SNS のような特に目的もなく幅広い層が使うサービスの場合は、無理にユーザーを決めつけて書く必要はありません。「暇な人が暇な時に使う」というのも立派な１シーンですから、胸を張って書きましょう。

ユーザーというのは「自分」でももちろん良いです。自作のツールを自分で使うことを Dogfooding (Eating your own dog food) と呼びます。必要な機能とそうでない機能を自分で判断できるので、質の高いツールを高速に作れる可能性があります。胸を張って「ユーザーは自分です！」と言いましょう。

ライブラリを作る提案なのにサンプルコードがない

まだ実際に動くコードでなかったり、関数名が変わる可能性があったりしても構わないので、ぜひサンプルコードを載せて欲しいです。
メンターはプロなので、説明してもらえれば大抵の言語が読めます。

低価格をアピールしているのに、コストの見積もりがない

先に断っておくと、全員に「コストを書け」と言う話ではありません。主にハードウェア開発の提案で、かつ既存の製品に比べて安価であることを強くアピールしたい方は、せめて原価を書いて欲しいのです。と言うのも、僕はハードウェアの相場感を持っていないので、どうして既存の製品に比べて安くなるのか、具体的な数字を示して貰わないと分からないからです。

そもそも、未踏ジュニアに提案するようなハードウェアなら、最初から安価に作れる必要はないと思います。製品の販売価格は生産するロットの大きさに影響を受けるので、価格で競争すると不利な戦いを強いられるからです。むしろ未踏ジュニアでは、１個作るのに５０万かかってしまったとしても、結果がスゴければ良いのです。低価格版はその後でも作れるはずです。

「多くの人が求めているのにも関わらず、このようなものは存在しません」という主張

これはプロダクトやサービスを開発する提案に対するアドバイスです。基礎研究や実装そのものを目的とするプロジェクトには当てはまりません。

「多くの人が求めている」または「まだ存在しない」のどちらか一方だけが当てはまることはありますが、両方を満たす事は極めて稀です。ほとんどの場合は調査不足か、解釈が違うだけです。

調査不足の意味はわかると思いますが、「解釈が違うだけ」は意味を説明しておきます。
既存のプロダクトやサービスを調査する際は、「その問題を解決するためにユーザーがとりうる全ての手段」を調べて、比較すべきです。これは単に「似ている製品」を調べるのとは違います。極端な例を言うと、電子署名のサービスを作る場合、競合サービスにはハンコも含むべきです。電子署名とハンコは全く別物ですね。しかし電子署名サービスを採用する人はそれまでハンコを使っていた人ですから、ハンコと比べてどう良いのかを考える必要があるのです。このように「〇〇したい人」の〇〇が似ているものを探して比較することが重要です。

上記のアドバイスは、新規性をアピールしたい人向けのアドバイスですが、そもそも新規性なんてなくたって良いのです。Google も Apple も Facebook も Amazon も、めちゃくちゃスゴいけど、世界初だった訳ではありません。世界にまだないものを作ることと、多くの人が求めているものを作ることはどちらもスゴいですが、全く別物だと僕は思います。

提案者にもできないことを、誰もが出来るようにする提案（それ自体は悪くない）

これも主にサービスを開発する提案に向けたアドバイスです。
「〇〇は一般の人には難しいが、出来たらスゴい。だから誰でも〇〇ができるサービスを作る」という提案が結構あります。

そのモチベーションは素晴らしいと思うので、応援したいのは山々ですが、「じゃあどうやって？」を考えてもらわないとサポートのしようがありません。提案者にも出来ないことをサービス化するための方法は２つあります。１つは出来る人に協力してもらうこと、もう１つは頑張って出来るようになることです。当たり前のようですが、世の中のサービスもみんなそうやって「自分ごと」に考えている人がいるお陰でサービス化できているのです。

以上です。参考になれば光栄です。