2021年の未踏ジュニアの応募書類を読んでで出てきた思考の断片
-
- これを書いた時は「問題解決の方が大事」と暗黙に仮定していたが「どちらを大事だと考えているのか」は質問すべきかもしれない
-
nishio: 「こういうことをやりたい、やろうと思ってる」という話に対して「それは難しい」とコメントするのは老害的であるか否か
-
過去の記事の発掘、編集
---未整理時系列
仮説の検証
-
仮説の検証と一言にいっても「顧客価値があるという仮説の検証」と「技術的に可能かどうかの検証」は別だよな、と書類審査をしながら思った
- 「ある技術Xを使って、ある問題Yを解決します、解決したらZさんは嬉しいはず」のYZ間とXY間の違いか
- 「技術Xで問題Yを解決できるか？」と「問題Yを解決したら顧客Zは嬉しいのか？」の二つの疑問がある
- 多くのプロジェクトは、世間的にはそれほど難しくない手段によって問題を解決し、顧客を幸せにする。だからXYの仮説はメンターから見ると「問題なく実現可能」「このクリエータが半年の開発期間内に実現可能か？」となる。YZの仮説はしばしば実際にものを作らないと検証できない。なので最小限の実装で検証しよう(MVP)となる。
- 一方で、難しい技術手段に挑戦するタイプの提案もある。
- 期間中に顧客に届くかどうかは無視し、解決すべき問題にフォーカスする
- その問題は解決すべきものだが、世の中でまだ解決方法が見つかってない、だから新しい解決方法を作るのだ、という提案
- ほとんどは調査不足(解決方法は既にあって提案者が気づいてないだけor解決すべき問題とされてる問題を解決して幸せになる顧客が存在しない)
- だが稀に、本物の問題と解決を見つけて提案するクリエータがいる(少なくともメンターに提案の瑕疵を見つけることができない)
- どこが難しいところなのかを理解しているかどうか
- そのソフトウェアを作ること自体は難しくないがユーザを集めるのが難しいのでは、というタイプ
- なのにどうやってユーザを集めるかの考察がなく作る話ばかり書いていると理解してなさそうだとなる
- その解決方法が成立するかどうかの検証が必要なタイプ
- それが最優先なのに別のことをやろうとしていると…
- そのソフトウェアを作ること自体は難しくないがユーザを集めるのが難しいのでは、というタイプ
- 「難しい」は主観なので間違ってるかもしれない
-
「既存の製品の調査」ってやっぱり難しいね。寺本さんが言ってたみたいなことがもっと伝わるといいのだが。
-
既存のプロダクトやサービスを調査する際は、「その問題を解決するためにユーザーがとりうる全ての手段」を調べて、比較すべきです。これは単に「似ている製品」を調べるのとは違います。極端な例を言うと、電子署名のサービスを作る場合、競合サービスにはハンコも含むべきです。電子署名とハンコは全く別物ですね。しかし電子署名サービスを採用する人はそれまでハンコを使っていた人ですから、ハンコと比べてどう良いのかを考える必要があるのです。このように「〇〇したい人」の〇〇が似ているものを探して比較することが重要です。
- 「手段Xで問題Yを解決すると顧客Zがハッピーになる」という提案において、類似のものとして「手段Xみたいなもので問題Yみたいなものを解決するもの」を挙げるけど、「問題Yを解決して顧客Zをハッピーにしてる、全然別の手段Wのメジャーなやつがあるよね」ってなるやつ
-
-
整理した: 似てる問題の違う解決手段を調べる
-
nishio: > 友人、知人に「俺はこういうことをしている/したい」と話しておくのは重要。
-
仕事としてOSS開発者をやってきた話 - 覚書 satoru-takeuchi.hatenablog.com/entry/2021/04/…
賞味期限の長いアウトプットをした方が良い
-
nishio: 単位時間あたりのアウトプットの速度が大差なくても、Aさんが1日で賞味期限切れるアウトプットをやってる時間でBさんが3年賞味期限があるアウトプットをやった場合、Bさんの方が1000倍程度アウトプットが多いかのように見える
-
nishio: 人は他人の内面を見ることができないので、内面がいかに良くてもアウトプットされなければ評価されない 人の評価とアウトプット能力
-
-
nishio: 「情報は発信する人のところに集まる」は、たぶん条件が不足している
-
nishio: 中高の先生が情報化社会に取り残された人だった事例: - > @cyanolupus: 中高と「こんな汚い字じゃ大学でレポート読んでもらえないぞ〜」って言われてきたけど、大学入ったら全部PDF許可されててLaTeXで記述してる
- 周囲の大人の意見がまともかどうかわからない問題
- 意見が検証されているかどうか
- 意見は解釈、事実ではない
- 提案者を書く能力の格差があるって話に関連してて、提案書を見てそこで聞かれていることについて考えることで「考えてほしいこと」をしっかり考えられるように質問を明確にして行った方が良いのではないかという仮説
- 「考えるべきことを考えたあと、変形してフォームを埋める」ではなく「フォームを埋めることが考えるべきことを考えることになる」という感じ
- 「こういう質問文を足した方が良いのでは」とか「質問の聞き方をこう変えたら良いのでは」みたいな情報を集めたりとか、今年や過去の採択者に答えづらかった質問はどれかとか聞いたりすると良いのではと思った
提案者の所属が母校であることにポジティブにもネガティブにもバイアスかけたくない気持ち
あとちょっとなのだけど「あとちょっとだから今日中に終わらせるぞ！」という気持ちで読むと雑に数をこなすことになりそうだから続きはまた明日にする
- メンタルの状態をキープするの大事
お金はあんまり掛からないけど時間がめっちゃ掛かる系のプロジェクトをうまいこと支援する方法がないものか
- 事業の期間が半年と決まっていると、半年で成果につながりそうなものを選ぶバイアスが生まれてしまうのは良くない気がした
- 未踏ジュニアとは別にたっぷり時間をかけて社会問題を解決する未踏ジュニアXをやるか(ジャスト思いつき)
- 未踏ジュニアに対する応募の中で未踏ジュニア自体にはミスマッチだけど、未踏社団が支援することで社会に良い効果をもたらせそうなものがあるなら別プロジェクトを立ち上げるのは一つの手だとは思うな。
- プロジェクトの継続性
- 公益性高いので未踏ジュニアを踏み台にして知名度獲得して寄付などで継続的に回るようにするとか彼一人が抱え込まなくても回るサービスにするとかを支援してあげたい気持ち
- 基本的に中高生のプロジェクトは3年以内に本人の進学や就職に伴う生活環境の変化が訪れる可能性が高く、継続性を疑われがち
nishio: 「方法Xで問題Yを解決して顧客Zが幸せになる」という場合、YZの「顧客価値の仮説」とXYの「技術の仮説」の二つが抱き合わせになっている。この二つのどちらが重要なのか、どうやって検証するのか、検証して否定された時にどうするのか。
nishio: あー、そうか、わかったぞ、自分以外の他者からリソースを引き出すことはすべて顧客価値の提供の対価なんだ。顧客が無数にいる場合もあれば1人の場合もあるし、顧客を奪い合う競合が多い場合もあれば少ない場合もあるが、構図としては価値の交換なんだ。
- 関連: メンターを顧客にする
チーム応募をネガティブに評価するかどうかに関しては、以前はネガティブだと考えてたけど、今はそうでもない。 ただしチーム開発の方が個人開発よりも難しいプロジェクトだという認識は昔と変わっていない 。 チームで応募したこととの整合性の観点から「チームメンバーの各個人がこのプロジェクトにどう寄与するのか」「チームメンバー各個人のやりたいことにシナジーはあるか」「チームリーダーはチームをまとめていくことができそうか」を確認すると思う。
不採択フィードバックで不採択の理由を書こうとしない 早い失敗は有益
やったことない人にやりたいことを相談するとできない理由を教えられる
nishio:#未踏ジュニア質問箱 Q: 一次審査通過の人数は？ 一昨年まではメンター1人当たり3件の通過でしたが、昨年通過数を増やしたメンターがいて、それが良さそうだったので今年は通過を増やしたメンターが多かったです。今年の書類審査通過は45件2.7倍で、面接フェーズの倍率は3.8倍になります
teramotodaiki: メールに返信するときは「全員に返信」、地味だけどすごく大事なことです。 マナーとかじゃなくて必須です。 Twitterに例えると、 ツイートにリプライする→全員に返信 ツイート主に個別 DM する→普通の返信 みたいなイメージです。 普通の返信の方が特殊ケースなので、なるべく全員に返信します。 twitter.com/mitoujr/status…
-
teramotodaiki: 補足① 「全員に返信すると自分のアドレスがバレてしまう」と思った方へ。 メールでは一切気にしなくて大丈夫です。 あなたのアドレスをバレないようにするのは送信者の役目です。具体的にいうと「Bcc」を使います。
-
teramotodaiki: 補足② 「他の人に無駄な通知が飛んでしまうのでは？」と思った方へ。 こういうSNS仕草もメール（特に重要な連絡）では一切気にしなくていいです。 送られすぎることより、送られないことの方がはるかに問題です。 CcやBccを発言ごとに巧みに使い分けるのは徒労です。そういう時はSlackを使います。
-
nishio: 図解もあります CCが付いているメールにはReply Allが必要
teramotodaiki: ユーザー投稿型サービスの提案、既存ツール＋既存メディアで試してから提案書を書くと良さそう。サービス作るより圧倒的に短時間で立ち上がるし、滑っても学べること多いし、お金もかからない。 例えば、 画像なら Notion + Instagram 文字なら Scrapbox + Twitter 動画なら Vimeo + TikTok とか。
nishio: プロトタイプの作り方の一つとして紹介したい… twitter.com/teramotodaiki/…
nishio: これ今思ったのだけども「プロトタイプを作る」って言葉は「ゼロから自分でコードを書いて何かを作ること」と誤解されてしまいがちで、本当にして欲しいことは「仮説を検証すること」仮説検証のための最小限のプロダクト(MVP)を作る上では当然「実装しないで試す」もアリってことね
nishio: ユーザ投稿型サービスの場合、どんな仮説を検証してほしいと思ってるのかがもっと言語化されると良さそう
nishio: 「こういうものがあればいいと思う」というアイデアだけの状態よりは実装してみたプロトタイプがあるといいけど、重要なのは「プロトタイプがあること」ではなくて「アイデアだけではなく、検証が行われていること」なのだよな
nishio: 先日のこの話と絡んでくるのか 仮説の検証に繋がらない部分を作ってもあまり意味がなくて、それよりは何も作ってなくても仮説が検証される行動をした方が良い。
nishio: そういう意味ではアンケート調査をしてる提案がいくつかあったけど「これは良い」ってどこかに明示的に書いた方が良いのかな。
- 提案フォーマットの「これまでにやったこと」の例に追加すると良いのでは
nishio: プロトタイプを作るのは手段、目的は仮説を検証すること。仮説とは具体的に何か？仮説を検証すると何が嬉しいのか？「Xを作ると問題Yが解決して顧客Zが幸せになります」系の提案において「提案者はXを作れる」「Xを作ると問題Yが解決する」「問題Yが解決すると顧客Zは嬉しい」は全部仮説。
nishio: 作れると思ってたものが作れないと困るし、作ったけど問題が解決しなかったら作った意味がなくて困るし、問題を解決したけどそもそも誰もその問題を解決して欲しいと思ってなかった場合も作った意味がなくて困る。だから早めに確認する必要がある
nishio: もちろんこの仮説は提案前に検証済みである必要はなくて、それどころか成果報告のタイミングでもまだ完全に検証された状態にはならない可能性もあるもの。だけども検証を繰り返して少しずつ確実なものにしていくことが有益で、提案の時点でゼロ歩なのと一歩踏み出してるのだったら踏み出してる方がいい
もしかして僕のやりたいことは「中高生にMOT教育」なのかもしれない なぜ顧客価値を考えるのか、顧客価値があることをやると世の中の役に立つことができている実感があってよい？ 続けていく気になる？