｢子ども1人生んだら1000万円支給｣ひろゆきが少子化対策で超大胆提言！！！

※本稿は、西村博之『ひろゆき流　ずるい問題解決の技術』（プレジデント社）の一部を再編集したものです。

■子ども1人生んだら1000万円支給

ふだんニュースを見ていると、さまざまな問題やトラブルを目にします。僕の場合、気になることがあると、「これはどういう問題なんだろう」「こうしたら解決できるんじゃね？」と考えるクセがあります。

とくに、そうした問題の解決策を考えるときに、僕があえてやっているのは、「極端な発想をする」ことです。

僕が極端な意見を言うと、ふざけているように思われがちなのですが、別にそういうときも冗談で提案しているわけではありません。

たとえば、日本の少子化問題に対して、僕は以前から「子どもを1人生んだら1000万円支給」という解決策を提案しています。

この提案に賛成する人も多いのですが、なかには「子どもを生むと1000万円もらえるようになったら、育児放棄する人が増える」「子どもが20歳になるまで毎年50万円支給のほうがよくない？」という意見もありました。

でも僕は、「お金を一括で支給したほうがいい」と考えています。なぜなら、一括と分割では、インパクトがまったく異なるからです。

■問題解決はインパクトが10割

分割で年に50万円の支給となると、ひと月あたり約4万円になります。ですが、現在でも出産育児一時金で42万円もらえますし、児童手当が月に1万～1万5000円、さらに高校無償化など、いろいろな支援制度があるので、月に数万円の支給だと既存の仕組みとあまり変わらないんです。

でも、「1人生んだら1000万円支給」が実施されたら、間違いなく翌年から出生数は急増しますよね。

子どもを生むための準備を始める人も増えますし、下手に働くよりも「子どもをたくさん生んだほうがトクじゃね？」と考える人もあらわれるでしょう。ムリして働く必要がなくなるので、生き方を変える人が出てくるんです。

子どもが増えたら、電車やバス、商業施設などで親子連れのサービスが充実して、子育てをすることが当たり前の社会になります。保育園や塾などの教育事業や、子ども関連の商品やサービスを扱う企業の株価も上がりますし、社会に変化が起きるんです。

もちろん育児放棄が増えるのはよくないので、養育義務に違反したら給付金を回収するなどの対策を立てる必要はあります。

■既存の仕組みを変えるなら劇的に

「1000万円支給」と言うと、必ず「財源はどうするんだ？」といった反論が出てきます。でも、すでに社会保障費は膨れ上がって、年金を今後どうやって払うのかも見えないまま国の借金を増やし続けているのだから、国債を刷って支給してしまえばいいと思います。

子どもへの投資は結果的に国を豊かにします。

日本人1人あたりの生涯賃金は2.7億円（大卒の場合）、生涯納税額は約4000万円とも言われています。こう考えると、1人に1000万円配っても、子どもが増えたら国としてはしっかり元がとれるんですよね。

このように、既存の仕組みを改善したいときには、インパクトのある解決策が必要なんです。劇的に変わるようなインパクトがないと、社会システムなどの仕組みは変わりません。

何かを劇的に変えると、人も社会もそれまでとはまったく違う道に進む可能性が出てきます。なので、解決策は、インパクトが大きいほうが効果的です。

■極端な発想が「別の答え」を生む

このように、問題を解決するうえで、仮説を立てる作業は欠かせません。

仮説というと難しく感じるかもしれませんが、要は「こうしたら、うまくいくんじゃね？」という仮の答えを出すことです。

解決策を出すためにいろいろと調べていくと、仮説が見つかったりします。仮説は、何もゼロから自分で考える必要はありません。海外や他者の成功例をパクったりアレンジするのも立派な仮説なので、似たような問題がないかググってみればいいのです。

そして、成功確率が高そうな仮説を立てたら、必ずやることがあります。

それは、検証です。

仮説は立てただけでは意味がありません。それが正しいのか間違っているのかを検証して、問題点が見つかったら軌道修正する。それによって、仮説の精度を高めていきます。

そして、仮説を検証する際にも、「極端な発想」は、とても大切です。

たとえば、日本の財政問題に対して、「政府が日本円を刷っているから、国債をいくら発行しても財政破綻しない」という意見があります。本当にそうなのであれば、「5000兆円刷ったらどうなるのか？」を一度シミュレーションしてみればいいんです。そうすれば、「成立しないよね」という結論になるでしょう。

IT系のシステム設計ではよくやるのですが、仮説を立てたときに、極端な値を入れてみるんです。それで成立するのなら、その仮説は正しいとわかります。仮に100万人が使うシステムを設計するときであれば、その10倍の1000万人がアクセスしたらどうなるかを試してみるんです。

IDを管理するサーバーが1台なら、ユーザーがログインするときは必ずそのサーバーにログインします。でも、そのサーバーが1秒間に1000人分しか処理できない場合、1時間で最大360万人しか入れません。つまり、1時間に1000万人を処理するのはムリだとわかります。

さらに、ボトルネックになっているログインサーバーが落ちたら、このシステム自体が動かなくなります。ということは、最初からログインサーバーを増やせるように設計しておけば、ログインサーバーの一つが落ちても、ほかのサーバーが動くので安心ということになりますよね。

このように、極端な数字でシミュレーションしてみると、どこがトラブルの元になるかがわかるし、逆に成立したらその設計は正しいと確認できます。

極端な数字を入れるということを続けていると、たまに成立するときもあるんです。たとえば、予算のやりくりで困っているときに、人件費をゼロにして計算してみたら、まったく別の答えが出てくることもあります。

■検証は本番環境で試せ

仮説を検証するときにもう一つ大切なのは、「本番環境で検証する」です。

先ほどの例のように、仮説と検証はセットでするべきなのですが、僕はシステムなどの検証は本番環境でやるようにしています。というのも、「テスト環境でうまくいったから本番環境でやってみたら、うまくいかなかった」というケースはよくあるんです。検証は本番環境でしたほうが問題点が早く見つかるので、僕は本番環境で試すようにしています。

最近のサイトはあまりやっていないようですが、僕は2ちゃんねるのときから、一時的にサイトを利用できないようにして本番環境で検証していました。その間、ユーザーはサイトを利用できなくなるのですが、そういうときに運営側は「お客を困らせてはいけない」と考えがちです。

でも、その考え方は間違っていると思います。

問題を本当に解決できるのなら、たとえ一時的にお客さんが困っても、長期的にはそちらのほうが正解というケースは、よくあるんですよね。システムが一時的に使えなくなることがマイナスだという捉え方自体が間違っていると思います。

■お客は待たせてもかまわない

実際、メンテナンスを全然しないサイトよりも、システムを止めてでも小まめにメンテナンスをしているサイトのほうが、きちんとしていたりします。メンテナンスやアップグレードを定期的にしていると、ユーザーも「ちゃんとしたサイトなんだ」という評価をしてくれますからね。

なので、たとえ一時的にお客さんに不便をかけても、検証は本番環境で試したほうが、その仮説が正しいかどうかの答えも早く出ます。

もちろん、医療従事者が使うサイトなどは人の命に関わるのであてはまりませんが、エンタメ系のサイトが止まったとしても、本当の意味で困る人はいないでしょう。

仮説は、どれだけ多く思いついても、検証をしなければ意味がありません。なので、うまくいきそうな仮説を思いついたら、まず検証するクセをつけると、より精度の高い仮説が立てられるようになります。

———-

———-