仕事のできる人は、「正解探し」から「仮説検証」への思考の転換を20代で終えている人が多い。

希少性があるのは不確実な状況で成果を出せる人であり、「正解探し」の思考に囚われている限りそのレベルに達することができない。

早期に不確実な状況で成果を出すことに慣れ、「仮説検証」の思考に切り替えると、評価、機会、報酬等が段違いに高くなる。 November 11, 2025

20代で仮説検証の力をつけないと、30代以降に、「仮説だけ立てる人」になりがちです。

失敗が怖いので、間違った仮説を立てたくないと思ってしまいます。これ、危険です。

「仮説」は、間違っていて初めて真実が見えるものです。そして、自分の思考との差分を図ることにも繋がります。

一つの仮説、一つの検証を繰り返して思考は育っていきます。 November 11, 2025

＼ 12月に本が出ます📘『リサーチからはじめる仮説ドリブン・マーケティング』（菅原大介） ／
予約スタート👉https://t.co/Pcwr6w4FYh
ブランドマネージャー・プロダクトマーケター向けに、仮説を立てる→確かめる→決めるためのリサーチアクションをまとめた本を書きました。
探索・検証それぞれの用途に活かせるよう、マーケティングの実務に沿ってアンケート・インタビューの質問例・分析例を300ページ超収録。
仮説の構築法と調査の方法論をセットで身につけたい（＝仮説ドリブン）方はぜひ！

＊本の特徴
1.【仮説探索】データから”気づく”ステップを徹底解説
2.【仮説検証】ブランド調査で使う検証指標15点を紹介
3.【質問サンプル】すぐ使えるアンケート質問例を多数収録
4.【資料サンプル】仮説をまとめる成果物イメージ集も充実
5.【事例研究】有名ブランドの仮説モデルからも学べる
6.【用語説明】問い、推論など関連ワードも丁寧に説明

＊本の目次
第1章｜仮説の基本システム
第2章｜仮説の運用モデル
第3章｜情報収集の習慣化
第4章｜デスクリサーチによるインプット法
第5章｜生活者理解の観点と技法
第6章｜データ分析の観点と技法
第7章｜仮説探索調査の設計・実施
第8章｜初期仮説の言語化
第9章｜ブランド仮説の検証調査
第10章｜マーケティング仮説の検証調査
第11章｜デザイン仮説の検証調査
第12章｜意思決定と合意形成

#リサーチハック November 11, 2025

新規事業や新しい商品づくりは、スピード感を持って小さく始めて、大きく育てるのが鉄則。最初から完璧な構想を描こうとすると、企画書が分厚くなるだけで一歩も動けない。大きく始めようとするほど、準備に時間を奪われ、リスクが怖くなり、改善サイクルも遅くなる。本質は逆。まずは小さく出す。雑でいい。未完成でいい。市場に触れさせ、顧客に触れさせ、空気を当てる。そこから得た生のデータをもとに高速で改善する。ここで得られる学びやフィードバックこそが、机上の議論では一生出てこない価値。

事業はつくってから考えるのではなく、つくりながら考え、動かしながら磨くもの。大きく当てる人は例外なく「最初の着手が速い」「改善の手数が圧倒的に多い」「失敗を恐れず仮説検証を繰り返す」この3点を徹底している。

スピードは、競争力であり、差別化であり、最大の資産。完璧よりも、初速。計画よりも、検証。議論よりも、着手。新しい挑戦は、速さがすべて。まず出せ。小さく出せ。そして狂ったように改善し続けよう。 November 11, 2025

失敗に関してさらにお伝えしたかったのは、「失敗できることは“贅沢な権利”である」ということ。

そして、「失敗というものは、そもそも存在しない」ということです。

失敗は挑戦の裏側にあるので、挑戦しなければ失敗にぶつかることはありません。
そして挑戦というのは、誰しもができるものでもない。

「お金がどうしても足りない」
「旦那から許可が降りなかった」
「タイミング悪く他の事情が重なった」

いろんな理由で、挑戦したくてもできない人がいる中で、挑戦と失敗ができることは実は権利であり、贅沢でもあると僕は考えています。

さらにいうと、なぜ僕が失敗をそこまで恐れずに受け入れられるのか？
というと、実は失敗というものは“そもそも存在しない”からなのです。

何かに挑戦してうまくいかなかったことは「失敗」ではありません。

正しくは、その方法ではうまくいかなかった、ということを教えてくれる「フィードバック」なのです。

逆にいうと、このフィードバックなしでいきなり正解に辿り着くことは余程のプロでも無理です。
僕は今でも、日々仮説検証を繰り返しながら、うまくいくパターンとうまくいかないパターンを探っています。

そしてそれは、周りのいわゆる「すごい人」たちもみんなそうです。
僕の教わったすごい人の中にも、270回以上挑戦してようやく大当たりを引いたという方がいました。

天才でもない限り、失敗という名のフィードバックを避けることはできません。
だけど、そのフィードバックがあるからこそ、正解に辿り着くことができるのです。

講座に入って学び、フリーランスという生き方を選択している我々には、挑戦し、失敗し、それをフィードバックとして受け止め、着実に成功への道を辿れるという”贅沢な権利”があるんです。

どうせそんな権利があるなら、使っておかないと損した気にもなりません？
きっと最初の決断も怖かったはず。でもそれを乗り越えたなら、ぜひこの先も恐れずチャレンジしてください！ November 11, 2025

これは本当にそう。むしろ年次を重ねるごとに不確実性の高い仕事に移行していくため、自分なりの仮説検証が出来ないと徐々に仕事に詰まっていく。

私も同じように辛い目にあったので早いうちからマインドを変えていくのが必要になる https://t.co/LeOQKPKKNA November 11, 2025

前回の投稿でも少し触れましたが、今アジャイルコミュニティやソフトウェアプロダクト開発コミュニティ全体が優先的に議論すべきテーマのひとつは、AIだと思っています。
AIのインパクト、それをどうやって「多くの人にとって意味があり有益な方向」に進めていくか、そしてこれから起こることに対してどう備えるのか、という話です。

＊＊＊2030年のソフトウェアプロダクト開発について＊＊＊

もし「2030年はこうなる」という正確で網羅的な未来予測を期待していたら、ごめんなさい。ここに書いてあるのはそういうものではありません。
そもそも2030年がどうなっているか、誰にも分かりません。地政学的な不安定さや、これから起こるかもしれない技術的ブレイクスルーなど、不確実性が大きすぎるからです。

とはいえ、かなりはっきり見えてきているトレンドもありますし、「起こりやすいシナリオ」とそうでないものもある程度は見分けられると思います。
ここでは、そのあたりを少し整理してみます。

—----------

＊＊＊起こる可能性がかなり高いこと＊＊＊

👉 ほとんどの開発者（Scrumの意味での「開発者」）が、日常的に高度なAIコーディングツールを使っています。リファクタリング、ドキュメント作成、テストなど、ルーティンなコーディング作業の大半はAIにサポートされている。AIからの提案に対する受け入れ率も非常に高く（おそらく90%以上）、一方で安全クリティカルシステムなど、一部の領域ではAIへの依存が制限されている、という感じです。
👉 テストのかなりの部分がAIで自動化されています。
機能テスト、パフォーマンステストはもちろん、ユーザビリティテストですら、ある程度まではAIが支援・自動化している世界です。
👉 すべてのコードに人間のコードレビューが入るわけではありません。
「人間がボトルネックになるのはやめよう」と判断した結果、どのコードを人間がレビューすべきで、どのコードはレビューなしでもよいのか、チームごとにヒューリスティクス（判断基準）が決まっているような状態になります。
その代わりに、ロールバックやリカバリの仕組み・パイプラインは今よりずっと強力になっています。
👉 AIエージェントが複数ステップにわたるワークフローを自律的に回しています。
たとえば「このレガシーなJavaサービスをサーバーレスのPythonに移行して、十分なテストもつけて」と指示すると、エージェント同士が連携して設計し、コードを書き、テストし、デプロイし、モニタリングまでやる、というような世界です。
👉 プロダクト開発におけるボトルネックは完全にシフトしています。
プロダクト開発はざっくり言うと
① 解決する価値のある問題と、実現可能で成立しそうな解決策（プロダクトやその機能）を見つける
② その解決策を実装し、リリースする
という2つの仕事から成り立っています。
AIによって②のスピードは、業界や技術にもよりますが、おおよそ5〜100倍くらいには加速します。レンジはかなり広いですが、結論を出すにはそれで十分です。
たとえ5倍という低めの見積もりであっても、①（＝プロダクトマネジメントの仕事）が新たなボトルネックになるには十分だからです。
もちろん、プロダクトマネジメントの仕事もAIでかなり加速されます。ただし②ほどではありません。
最終的には、顧客やユーザー（当時でもまだ多くが人間でしょう）から信頼を獲得し、自分たちのプロダクトを実際に使ってもらわなければなりません。
人間は簡単に信念や行動は変わらないので、ここが新しいボトルネックになります。
👉 プロダクトオーナー / プロダクトマネージャー（PO/PM）と開発者（Scrumの意味で、デザイナーやQAを含む）の比率は、大きく変わっています。
これまで多くのプロダクト開発チームでは、PO/PM 1人に対して開発者が5〜10人程度でしたが、今後は1対2、場合によっては2対1に近づいていく可能性があります。
（もちろん、PO/PMと開発者の役割分担が今のまま残ることが前提の話です。この前提自体が怪しくなっていく、という話は後で出てきます。）
👉 ほぼあらゆる市場で競争は今よりずっと激しくなります。
良いアイデアを持っている人ならほとんど誰でも、プロダクトを形にして勝負に出られるようになります。その一方で、成功するプロダクトやアイデアの割合は機械的に大きく低下します。
その結果として、プロダクトマネジメントのスキル（戦略的思考、価値ディスカバリー、仮説検証、コミュニケーション、インフルエンスなど）の価値と需要は、今よりはるかに高くなります。
👉 「QAはテストだけ」「デザイナーはデザインだけ」といった分業は、大きく減っていきます。
多くの組織では、そもそもサイロ構造という発想自体が弱まり、そのことが組織設計にも反映されます。
一方で、昔ながらのモデルに固執し続ける組織もあり、そういった組織は、より速く動ける競合に徐々に置いていかれることになるでしょう。

—----------

＊＊＊そこまで確実ではないけれど、十分ありえること＊＊＊

👉 ソフトウェアエンジニアリングの仕事が、はっきりと2つの職種に分かれていきます。
コンピュータとプログラミングを深く理解していて、非常に高いスキルを持つ「エリート」あるいは「真の」ソフトウェアエンジニア。
この人たちは、最も難しい問題や、最もクリティカルでリスクの高い問題を扱います。
もちろんAIも使いますが、あくまで自分たちが主導権を握り、AIが何をしているかを十分理解したうえで使いこなします。AIはこの人たちをより強くする道具であって、依存にはなりにくい。
必要であればAIをオフにして、自力だけでゴールに到達することもできますし、むしろAIがハマって身動きが取れなくなっているときほど、それをやることになるでしょう。
こういった人たちは、ソフトウェアエンジニア全体の中では少数派で、その代わり、かなり高い（とてもとても高い？）報酬を得るようになります。
要件・仕様を受け取り、それを「一定水準以上の品質のプロダクト」にするのがとても上手な、新しいタイプの「AIネイティブエンジニア」。
この層の人たちは、ハイレベルなソフトウェアアーキテクチャをある程度理解しており、複数のAIツールを組み合わせて目的を達成するのが得意です。
一方で知識のギャップもあり、より革新的で難易度の高い問題になると太刀打ちできなかったり、ときどき行き詰まったりもします。
バックグラウンドは非常に多様で、コンピュータサイエンス専攻とは限りません。人数としてはかなり多くなり、報酬もそれなりに良いものの、言語の壁が小さくなればなるほど、競争はグローバルになり、生活コストの低い地域の水準に、報酬が収れんしていく役割も一部では出てくるかもしれません。
👉 「プロダクトをマネジメントする人」と「それを開発する人」の境界は、かなり曖昧になっていきます。
開発者が「次に何をつくるべきか」を考える（＝プロダクトオーナー / プロダクトマネージャーのように振る舞う）場面が増えます。
逆に、PO/PMがコードを書いてプロダクションにデプロイする（＝開発者のように振る舞う）場面も、今よりずっと増えます。
組織によっては、この2つのジョブタイトル自体が消えたり、マージされたりするでしょう。
誰もが顧客や市場のデータにアクセスでき、低コストの実験を本番環境で回せるようになり、「間違うこと」「失敗すること」が低リスクで、安全なものになっていきます。
👉 リアルタイム翻訳やツール連携の進化により、リモート / グローバルでのコラボレーションは、今よりずっと簡単になります。
特に、倭国の組織は大きな恩恵を受ける可能性があると思います。これまで大きなハードルだった「言語の壁」が、だいぶ低くなるからです。

—----------

＊＊＊では、どうするのか？＊＊＊

ここからは、少しでも実践的な話に落としてみます。

①ソフトウェアエンジニアとしてキャリアを考えている人・学生へ

👉 ソフトウェアエンジニアリングという分野は、これからも面白い分野であり続けるはずですし、多くの人がそこで充実したキャリアを築けると思います。
ただし、これまで以上に「適応力」と「学習の敏捷性」が求められるようになります。また、スキルや報酬の格差はますます大きくなっていくはずです。
AIの使い方を学ぶのは、できるだけ早い方がよいです。表面的・初歩的な使い方だけで満足せず、「かなり使いこなしている」と言えるレベルを目指した方がいい。
「AIを使うべき特別な理由があるときだけ使う」のではなく、「AIを使うのがデフォルトであり、使わないときには理由がある」という発想に切り替えていった方がよいと思います。
👉 同時に、トップレベルのソフトウェアエンジニアになりたいのであれば、基礎もきちんと学ぶべきです。
アルゴリズム、デバッグ、セキュリティなどのファンダメンタルを犠牲にしてはいけません。
AIに丸投げせず、自分の頭で複雑な問題を解く経験も、引き続き積み重ねる必要があります。

—----------

②ソフトウェアエンジニアとしての人へ

👉 まずは当たり前のところからですが、AIをかなり積極的に使えるようになった方がいいです。そうしないと、いずれキャッチアップがかなり苦しくなります。
とはいえ、他の人と同じツールを使う必要もないし、同じレベルでAIに頼る必要もありません。
自分が好きなツール、自分に合った「人間とAIの役割分担」を見つけていく感覚に近いと思います。いろいろなコラボレーションのやり方を試しながら、「自分にとって気持ちよく動けるプロトコル」を見つけていくとよいはずです。
👉 自分が扱っているドメインの知識を深め、プロダクトの価値や成功にももっと意識を向けてみましょう。
PO/PMと話してみる。顧客やユーザーと話してみる。アウトプット（作ったもの）ではなく、アウトカム（どんな成果につながったか）にフォーカスする。
👉 周りの人たち（デザイナー、QA、等）の仕事にも目を向けてみてください。従来の役割分担の結果として、現在では無駄や非効率となっている活動は何でしょうか？皆が同じ目標に集中し、AIを活用すれば、何を中止し、劇的に最適化できるでしょうか？と考えてみるのもおすすめです。
👉 リーダーたちは「現場で何が起きているかを完璧には理解していない」というのは、昔からずっとそうでしたが、AIの登場でそのギャップはさらに広がっている組織は多いでしょう。
もしあなたが、自分の組織がうまく適応していけるように助けたいと思っているのであれば、そして同時に「ソフトウェアエンジニアとして取り残されたくない」と思っているのであれば、自分がAIを採用・活用するうえで何が障害になっているのかを可視化し、意思決定者から見えるようにする必要が出てくるかもしれません。
👉 それでも組織が動かないのであれば、別の場所を検討した方がよい場合もあります。
自分自身は、対立や衝突をそこまで恐れない性格で、仕事を失うことにもあまり不安を感じてこなかったので、こういうことを言うのは簡単なのですが…　それでも、これから数年間は、多くのソフトウェアエンジニアにとって非常に重要な時期になると思っています。
変化の遅い、保守的な組織で働いている人ほど、徐々に大きな機会損失を被ることになりそうです。この激しい変化の時代に、自分はどんな組織にいたいのか、どんな人たちと一緒にいたいのか、一度じっくり考えてみる価値はあると思います。

—----------

③QAやUXなど、特定のロール / スキルセットでプロダクト開発に関わっている人へ

👉 多くの人は、プロダクト開発ライフサイクル全体の、より広い範囲を理解し、ときにはオーナーシップを持つことを求められるようになります。
アイデア出しから、実装、デプロイ、モニタリング、カスタマーサポートに至るまでの一連の流れです。
「自分の現在の仕事をAIで効率化する」のは、良い第一歩です。ただし、それだけでは足りません。
個人としても、より広いエンド・ツー・エンドのプロダクト開発ライフサイクルを理解している人たちと、いずれ採用市場で競うことになりますし、チームや組織としても、もっと速い競合と競争することになります。
あまりのんびり構えすぎない方がよい、という話です。

—----------

④プロダクトオーナー / プロダクトマネージャーの人へ

👉 自分の現在の役割について、一度よく考えてみてください。
もし、あなたの仕事が「何をつくるべきかを、分かっている（あるいは分かっているつもりの）人たち」と「開発者」の間の、単なるインターフェースでしかないのであれば、数か月〜数年のうちに、組織として「この役割はあまり価値を生んでいないどころか、価値創造のスピードを落としているのではないか」という結論に至る可能性があります。
👉 AIの可能性・限界・方向性を理解することに時間を投資しましょう。
リサーチ、プロダクトバックログのリファインメント、ドキュメント作成など、日々の仕事の中にAIを組み込んでいきましょう。
👉 リーダーシップスキルやコミュニケーションスキルも磨いていきましょう。
特に大企業では、これらのスキルがステークホルダーをマネジメントし、物事を前に進めるうえで大きな力になります。顧客やユーザーに向き合うときにも同様です。
多くのケースで、開発そのものはもはやボトルネックではなくなります。代わりに、別のプロセス（データ収集、社内の合意形成、ユーザーへの浸透、利用促進など）がボトルネックになります。
そういった部分の流れをどれだけ加速できるかが、PO/PMとしての価値に直結していきます。
👉 もっと「全体」を見る時間を取りましょう。より戦略的になりましょう。一度スピードを落として、一歩引いて考えてみる時間を意図的につくりましょう。 PO/PMとしての価値は、「大量の決断をする能力」ではなく、「少数だが質の高い意思決定を行う能力」と強く相関していくはずです。

—----------

⑤経営者・役員・リーダーの人へ

👉 サバイバーシップバイアスはあるかもしれませんが、ここ数年もっとも勢いのある企業の多くは、AIをかなり本気で取り入れています。
Anthropic、Cursor、Shopify、Googleなどは一例ですが、彼らはAIの恩恵を最大限に享受できるよう、組織構造や働き方そのものを設計し直しています。
ここで、いくつか質問です。
この3年間で、あなたの組織構造やソフトウェア開発ライフサイクル（SDLC）は、どのように変わったでしょうか。
「ほとんど変わっていない」としたら、おそらくまだ古いモデルにとどまっています。
では、これからの3年間で、突然うまく適応できるようになると思える根拠は何でしょうか。
👉 もしあなた自身が技術者ではなく、AIのヘビーユーザーでもないのであれば、AIについての思い込みやブラインドスポットをたくさん抱えている可能性があります。 なので、チームと対話しながら、組織構造、ガバナンス、採用戦略、コンプライアンスプロセスなどを一緒につくっていくことを恐れないでほしいと思います。
👉 AIに関する予算を人に渡し、ツールを買うのに何か月も承認を待たなくていいようにしましょう。
👉 「今やっているタスクをこなせる人」だけを採用するのはやめましょう。
好奇心、適応力、AIと効果的に協働する能力を持った人を採用しましょう。
👉 それぞれのロールに対する期待値を更新しましょう。
もし2年前と同じジョブディスクリプションをそのまま使っているのであれば、おそらく動きが遅すぎます。

—----------

⑥すべての人へ

👉 共感力、倫理観、良質な判断力といった「人間ならではの強み」を、大事に育てていきましょう。
おそらくこれらの価値が失われることは、当分ないはずです。
👉 これから不確実性の高い時代に入っていく中で、そして私たち人間が不完全で、繊細で、ときに簡単に傷ついてしまう存在であることを考えると、自分自身にも、周りの人たちにも、少しでも優しくありたいですね。

—----------

まだまだ書きたいことはたくさんありますし、ちょっとずれていることを書いてしまった可能性もあると認識していますが、ひとまずこのあたりで！
誰かのヒントになればうれしいです。 November 11, 2025

「仕事が好きな人」って、
ああでもないこうでもないと延々と仮説検証を続ける。
その過程で、自然と多角的な視点で仕事を捉えられるようになる。

一方、「目の前の成功だけを求める人」は、小手先ノウハウに頼るから、その通りにやる以外の選択肢を持てない。

だから状況が変わった瞬間、前者は柔軟に対応できるのに、後者は固まってしまう。

「仕事好きな人」は試行錯誤が長いぶん成果が出るのが遅いけれど、時間をかけて積んだ思考の厚みは、
結局いちばん長く残る。 November 11, 2025

Coinbaseの創業者兼CEOのBrianのツイートはたしかにその通り。新しい事業を始める時のプロセスに似てる。デスクトップリサーチは程々で、色々試す、話すことで仮説検証のスピードが100倍くらいあがる📖

> 行動は情報を生み出す。どうしたらいいか分からないなら、なんでもやってみればいい、たとえそれが間違ったことだとしても。これによって、本当にやるべきことが何なのかについての情報が得られる。 表面上はシンプルに聞こえる - 難しいのは、これを毎日の仕事のプロセスに取り入れることだ。 November 11, 2025

7/21にnoteのメンバーシップを開始しまして、加入者数は以下のように推移しています。

7月末：57名
8月末：241名
9月末：498名
10月末：1,044名
11月現在：1,274名

10月までは毎月倍以上の伸びでしたが、ひと月の新規加入数には天井があり、私の場合は今のままだと600-700名くらいが上限値ですので、1,000名を超えてくると伸び率が鈍化します。

ここからはD2Cビジネスのように解約率を如何に下げるかがポイントになってきますが、「何をすると解約率が下がるのか」「特定の施策によって本当に解約率が下がったのか」は現在のnoteでは詳細に分析が難しく、しばらく仮説検証に時間が掛かりそうだと感じています。

解約率を下げる施策以外にも、実は伸び率を上げる施策も沢山存在していて、どれも普通に思いつくものなのですが、本業の隙間時間でやれることが限られ、PDCAサイクルを全力で回しきれないのが難しい所です。 November 11, 2025

＃1日1ページメモ

久しぶりになぜなぜ分析という言葉を見たので、
自分なりに簡単にまとめておこうと思う。

◆トヨタ式「なぜなぜ分析」は、そもそも何のための道具なのか

トヨタ式のなぜなぜ分析は、
「同じ失敗を繰り返さないために、真因（根本原因）を見つけて、仕組みを改善する」ための道具です。

ポイントは、

犯人探しではなく、再発防止のための仕組み作りであること。
「感情論」ではなく、現場で起きた事実に基づいて絞り込むこと。

つまり、「人が悪い」のではなく、
しくみや環境に原因を探すという発想が前提になります。

「どうすれば、次はもっと上手くいくか」を見つけるために使う分析ツールという捉え方が大切ですね。

◆正しい「なぜなぜ分析」の使い方

① 最初の「問題」を一文でハッキリ書く

例：
「今日の配信の同接数が、いつもの半分だった」

始まりとなるテーマがぼんやりしていると、
なぜをいくら重ねても、ズレた結論にたどり着いてしまいます。

② 「なぜ？」は事実ベースで、感情ではなく現象を見る

悪い例：

「なぜ同接が少なかった？」
　→「自分に魅力がないから」

これは「感情」であって、「事実」ではありません。

良い例：

「なぜ同接が少なかった？」

→「いつもより開始時間の告知が遅かったから」
→「他の大型配信と時間が丸かぶりしていたから」
→「サムネとタイトルが、内容の魅力を伝え切れていなかったから」

など、その時に観測できる事実・行動・条件に落としていくのがコツです。

③ 「人」ではなく「仕組み」に原因を寄せていく

・「自分が悪い」で締める

・「あの人が悪い」で締める

この2つは、なぜなぜ分析の“罠”です。

正しい使い方は、

・告知フローの仕組み

・配信時間の決め方

・ネタ・企画の検証方法

・サムネやタイトルの作り方

・タスク管理や体調管理のしくみ

・配信時間の設計

・トラブル対応フロー

・会話トークの準備

など、「やり方」や「仕組み」を細かく分解し、改善ポイントに落とし込んでいきます。

④ 3〜5回で十分。無理に「5回」やらなくていい

よくある誤解が、
「とにかく5回『なぜ』を繰り返さないといけない」という思い込みです。

実際には、

・3回くらいで十分深くなっているケースもある（これ以上深掘りできない場合など）

・逆に、5回を超えても枝分かれしていくケースもある

大事なのは「回数」ではなく、

「再発防止につながる根本原因まで掘れているか？」

ここが一番重要です。

⑤ 最後は「今から変えられる行動」で止める

良くない終わり方：

「VTuber界隈が飽和だから」

「時代が悪いから」

「運がないから」

このあたりで終わると、
次に何をすればいいか分からなくなってしまいます。

良い終わり方：

「配信前日までに告知を出す仕組みがなかった」→「告知用チェックリストを作る」

「大型イベントと被っているか事前に調べていなかった」→「スケジュール確認のフローを決める」

このように、

「明日から自分が変えられるレベル」で終わるのが、正しいなぜなぜ分析です。

【補足】

1. 始めにあげた問題のテーマ→根本原因へと深掘りをしていくこと。

2. 根本原因→始めにあげた問題のテーマに戻っても、しっかりと意味がつながっていること。
　この往復で矛盾がない状態が、本来望ましい形（仮説と根拠の一致）だと思います。

◆間違った「なぜなぜ分析」の使い方

1. 「自分責め・他人責め」に使ってしまう

例（VTuberあるあるな誤用）：

Q. なぜ同接が少なかった？→ 私のトークが下手だから

Q. なぜトークが下手？→ 元々コミュ力が低いから

Q. なぜコミュ力が低い？→ 子供の頃から会話が苦手だから

これでは、最後に残るのは「自己嫌悪」だけで、
行動に落とせる対策は何も出てきません。

これは なぜなぜ分析ではなく、「自分いじめ分析」になっています。

2. 結論ありきで「なぜ」を逆算してしまう

例：

最初から「VTuber界隈が飽和状態だから」と決めてかかり、なぜを全部そこに寄せてしまう。

これは、「答え合わせ」に使っているだけで、
仮説検証ではなく「自己正当化」になっています。

3. 愚痴・感情のガス抜きにすり替わる

「なぜ？」のたびに、運営・視聴者・界隈・プラットフォームに怒りを向ける。

この使い方も、気持ちは分かりますが、
なぜなぜ分析本来の目的からはズレてしまいます。

感情の整理は別の場で行い、
なぜなぜ分析では、「事実」と「しくみ」にのみライトを当てるのが大切です。 November 11, 2025

そして何より大事なのは医学を学ぶ事は思考力を上げるというメリット

これは制度や市場価値よりも本質的なメリット。

医学を学ぶことで得られるのは
「人間の構造を抽象化する力」 そのもの。

具体的には：

生理学 → システム思考
薬理学 → 因果の理解
病態生理 → 多因子モデルの読解
解剖 → 構造と機能の対応
疫学 → 統計・再現性の理解
心理・脳科学 → 行動の予測
臨床推論 → 不確実性の処理
鑑別診断 → 排除法・仮説検証

これ全部、医師が普段から使っている構造的思考の土台と一致している。

医学を真面目に6年学ぶと、
思考のレイヤーが一段上がる。
判断の精度、データの扱い方、人間理解、倫理、統計、因果…。
どの分野でも役に立つ。

これは医師になる／ならないに関係なく、人生の地頭を底上げする学問。

そして他の学問より強いのは、
「人間」という最も複雑な対象を体系的に理解できる点。

これは経営・投資・心理・子育て・交渉、あらゆる場面で一生武器になる。

結論としは

医師の人数は今より減る。
一次診療はAIが奪い、
専門領域だけが残るから競争は厳しくなる。

ただし医師免許の権利価値はなくならない。制度が守っている領域はAIでは奪えない。

そして何より大きいのは、
医師を目指すプロセス自体が思考力を圧倒的に伸ばす という点。
医学という学問は、人間理解と構造思考を鍛える最強の土台になる。

だから僕は
「医者にさせるべきか？」ではなく、

①医学という武器を持たせる意味があるか
②その子が専門を身につけて戦えるか
③思考力を引き上げる教育として医学が合うか

この3軸で判断すると良いと思います。 November 11, 2025

石川涼さんの記事を読んで感じたこと。
コミュニティをつくること・参加すること自体に価値が生まれ、その中で購買行動が生まれていくという視点は、ブランドや事業運営において非常に参考になる。

①コミュニティが「価値」になる時代。
　誰を集めるかを戦略化する必要がある。
②体験の設計力が競争優位を生む。
③業界の常識を疑い、顧客視点で仮説検証を重ねる。

情報社会のいまだからこそ、
便利の反動として生まれる所属欲求に着目する姿勢に感銘。

この「顧客視点」は、前職から一貫して大切にしてきた考え方です。

来月、直接公演でお話聞けるのが今から楽しみ。 November 11, 2025

ｺﾐｬが論文書くとしたらなんだろう
「陸上短距離選手の怪我からの回復過程における、心理的調整と自己受容の変容に関する研究」
とか…？
純粋に、一人で100走るのと、誰かと競って100走るので記録に違いはあるのか、見たいな研究とか
一人で走るよりも誰かと競う方が速いという仮説検証型研究とか… November 11, 2025

独立後たった90日で繁盛店にする方法

コンセプトをいろいろ変えて反応がいいものをSNSで調べます。要はテストです。ガンガン発信しながら地域でウケるコンセプトを発掘していきます。それがわかったらそのコンセプトに見合う投稿を毎日しましょう。1〜3投稿はマストです。当然ですが投稿数よりエンゲージメントが大切なので仮説検証。3〜5投稿して1〜3投稿残すくらいになります。ここからLPをつくります。外注したら20〜30万かかります。しかも外注先でコピーライティングできるLPデザイン会社なんて1%あればいいくらいに思っててください。つまり完成しても予約の入らないクソLPが完成します。最悪です。だからライティングは学ぶ必要があります。1ヶ月そこらで学べるわけがありません。3ヶ月で最低限のポイントを理解して6ヶ月も経てばそこそこ書けるし外注に「ここおかしいから変えろ」と指摘もできるでしょう。え？ライティングも外注？なら追加で20〜50万円はあった方がいいですね。5〜10万ならそこそこのものができるのであとから改善することになります。自分のスキルがないとダメってことです。ええとさらにチラシですが...

↑
結論いいます。

90日で儲かる店をつくりたいなら
1日18時間労働で予算1,000万円くらい
用意してください。

これでなんとかなります。

無理なら1〜2年は腰据えて
50万円くらいは自己投資して
学ぶ⇄仮説検証をくりかえしましょう😌

これがリアル。 November 11, 2025

失敗を避けるべきものと捉える倭国企業が多い中、シリコンバレーは失敗を原材料にイノベーションを生み出す装置を作り上げてきました

フェイルファストは単なる精神論ではありません

失敗の検知を自動化し、影響範囲を限定し、高速に仮説検証を繰り返す

この30年間で確実に文化となり理論となりテクノロジーとなって結晶化した手法です

Amazonでは1時間に数千回のソフトウェアリリースが行われ、その背後で大量の失敗が製造されています

カオスエンジニアリングのように、わざと失敗を注入することで隠れた修正ポイントを発見する技術も生まれました

デジタルツインや計算創薬も同じ原理

物理的にはコストのかかる挑戦を計算機上で何万回も実行し、最良の候補を絞り込む

失敗を恐れる感覚は人間の本能ですが、それ以上に失敗を生み出しやすい組織を創り出そうとする意図的な取り組みが重要

心理的安全性や1on1も、効率よく失敗を早期発見し学習するための手段として発展してきました

技術、組織文化、プロセス、経営のあらゆる側面で高速な仮説検証装置を構築すること

これが現代企業に求められる文化資本であり、DXの本質に迫る鍵だと考えています

#NewsPicksトピックス
https://t.co/giQ8Q7NRHP
--
新著『AIエージェント　人類と協働する機械』販売中
https://t.co/ID5r1mMgPT November 11, 2025

前者はテストの点は取れそうだけど仕事では指示待ちで融通も利かなそう。後者は自分で課題を見つけて仮説検証を行っていく自ら仕事を作り出していけるタイプなのかな、と。 https://t.co/tpBN7ofpW1 November 11, 2025

営業代行の価値は売れるスピードの可視化

半年かけて内製するより1〜2ヶ月で仮説検証してしまった方がいいこともある

売れるかどうかを早く知りたい会社は絶対に代行を使うべきです November 11, 2025

"サラリーマンでも1日3時間「SNS運用代行」をすれば月50万円は余裕で稼げます。

初心者にも分かりやすく丁寧に解説するので、必ずブクマしといてください。

・1ヶ月目で180万マネタイズ
・未経験から6ヶ月で月200万
・たった1日30分の作業で月10万安定
・コンサル初月から月30万の案件獲得

弊社が教えた生徒の実績は↑
それでは解説✍️

❶TikTokで10投稿未満/1,000フォロワー以上を基準に上手いアカを20個リスト化

❷TikTokで「この人うまいな」と直感的に感じるアカウントを20個リスト化

❸何が面白いのか？なぜバズっているのか？を言語化

❹XやYouTubeで「なぜバズったのか？」を更に深ぼる

❺自分の特技や人より少し優れているものをピックアップ

❻何を教えるのか？なぜ自分が教えるのか？相手は何を学ぶのか？を言語化

❼実際に動画を撮影し発信

❽毎日仮説検証を行い、数値の改善をしていく。

❾自分のアカウントがある程度伸びてきたら、数字が改善した理由やポイントを資料に書き込む

⑩自分が代行できそうな市場を探す

⓫初月無料で契約

⓬満足いただけた方には2ヶ月目から有料でご案内

⓭コンセプトやKPI.KGI設定/フォロワー増加の仮説を立てる

⓮営業リストを外注→営業

⓯受注したら初回MTGを組み、コンセプトや運用目的、目標などの確認

⓰企画立案、動画の撮影、動画の編集

⓱動画の編集が難しい場合はXで編集者に外注

⓲PDCAを回す/毎月の数字をまとめる

⑲満足度を高め紹介を増やす/口コミを集める

⓴口コミや実績をnoteにまとめ、Xなどで発信

あとはこれを継続するだけ。毎日毎日、クライアントの運用アカに向き合って、仮説検証を繰り返す。

これができれば、ある程度の案件は獲得できるようになります！

まぁ、細かい戦略や施策は沢山ありますが、もっと詳しく知りたい人は私のポストを追ってください！" November 11, 2025

PDCAどれがすき？って聞かれて「え、どれもキライ、何もやりたくない」って言う怠惰な人間なんですけど、あえて何が動機になるかというと「仮説検証結果を見てる時が一番楽しい」ので私はCが好きです。 November 11, 2025