新年明けましておめでとうございます！
ADWAYS DEEEで開発・運用業務を行っているリードアプリケーションエンジニアのまっちゃん（@honyanyas）です。
2026年最初の記事になります。2026年もADWAYSエンジニアブログをよろしくお願いいたします！

本日はツキイチで開催されている部署の全体定例において、プロダクトチームを率いるエンジニアリングマネージャーりょーまさんから、『仮説思考』に関する発表がありましたので、そちらについてまとめました。

プロダクト領域には幅広く関わっているりょーまさんの記事・事例を一部紹介します。ぜひそちらもご覧ください！

発表内容
感想

発表内容

1. はじめに仮説検証とチームのズレ

はじめに「仮説検証とチームのズレ」というテーマで、課題の提示がありました。

プロダクト開発での「ズレ」の例

プロダクト開発を”仮説”検証サイクルで回しているが、こんな経験はないか？

「 AさんとBさんの言ってること（目指してるもの）が微妙に違う 」
「 良かれと思って作った 機能が、リリースしてみたら 全然使われなかった 」
「議論が堂々巡りになり、 結局何が課題だったのか 分からない」

これらはチームや関係者との「認識や価値基準のズレ」からくる事象。

「ズレ」による影響

「ズレ」が発生することで……

手戻りが発生する
リソースが無駄になる
コミュニケーションコストが増加する

と総じて生産性の低下につながってしまう。

マネージャーは10年以上の経験の中で「認識が合わない」という相談を数多く受けており、認識ズレは必然的に発生するものだと認識しています。
完全な撲滅は難しいため、認識のズレを減らしていく必要があります。

2. 仮説思考の基本

ここでは基本的な考え方を整理しました。

そもそも「仮説」とは何か？

仮説（かせつ、英: hypothesis）とは、真偽はともかくとして、何らかの現象や法則性を説明するのに役立つ命題のこと。引用元: 仮説 - Wikipedia

あてずっぽう：根拠なく、検証プロセスなく走る
仮説検証：「おおよそこうだろう」という根拠に基づいて、小さく検証していく

なぜプロダクト開発に「仮説」が必要か？

リスクを減らすため（不確実性と正しく向き合うため）

プロダクト開発において、最初から100%の正解（ユーザーが本当に欲しがっているもの、技術的に可能なもの、市場で勝てるもの）を知ることは不可能。とはいえ、むやみやたらにあてずっぽうにやれば良いというわけにもいかない。 ”おおよそこうだろう”という仮説を立て、小さく検証することで、リスクを最小限にして進めていく必要がある。

「アジャイルだからとりあえずやろう」は大きな誤りで、小さく検証していくことでリスクを減らしていく必要があります。

3. 仮説の「階層」と「前提」を理解する

仮説における階層についての説明がありました。

仮説を正しく設計するために、まずは土台となる「前提」と仮説の階層を揃える必要がある。前提がなかったり、知らなかったりすると、以降の仮説の捉え方や立て方がメンバーによって大きなばらつきが発生してしまうため。

前提 (Fact / Strategy)

仮説を立てるための土台となる「揺るぎない事実」や「合意事項」

私たちが向き合っている「ターゲットは誰か？」（例：首都圏在住の30代ビジネスパーソン）
「市場環境は？」（例：競合A社は、まだXXのシェアを取れていない）
「すでに自明となっているユーザー体験にまつわるメトリクスは？」：(例：初回訪問での離脱率が90%)

この「前提」を共有した上で、私たちはプロダクト開発における仮説を、いくつかの「階層」で捉える必要がある。

課題仮説 (Why/What)

前提に基づき、ユーザーが抱えているであろう悩みや欲求

「ユーザーAは〇〇という課題を持っているだろう」
- （例：「多忙なビジネスパーソンは、毎日のニュースを要約して読む時間すらないはずだ」）

ソリューション仮説 (How)

その課題を解決するための具体的な手段（機能・UI）

「その課題は、△△という方法（機能）で解決できるはずだ」
- （例：「AIが主要ニュースを3行で要約する機能があれば、彼らの課題を解決できるはずだ」）

※”XX仮説”の切り方は諸説あるので参考までに

前提を作った上で、課題仮説→ソリューション仮説の順序で仮説を立てて絞り込んでいく必要があります。

4. なぜチームの認識はズレるのか？

先ほど説明があった階層構造を踏まえ、なぜチームの認識がズレるのかについて説明がありました。

「認識のズレ」が起こる最大の原因は、「見ている仮説の階層や、共有している前提が揃っていないから」(これも仮説)

よくある「ズレ」の例

テーマ: 「新機能Aの利用率が低い」

Aさん: 「UIが分かりにくいのでは？ ソリューション仮説 レベルで考えている」
- (心の声: ボタンの配置を変えれば解決するはずだ)
Bさん: 「ビジネスパーソンなら要約ではなくて本文読みたいんじゃないの。 課題仮説 レベルで考えている」
- (心の声: 機能Bにピボットすべきだ)
Cさん: 「そもそもビジネスパーソンはもう取り切っていて開発コストの割にあわなくない？。前提レベルで考えている」
- (心の声: まずはターゲットの再定義が必要だ)

全員が「利用率を上げたい」という最終目的は同じでも、見ている「階層」がバラバラ。
このまま議論しても、AさんはUI改修の話をし、Bさんは機能廃止の話をし、Cさんはマーケティングの話をすることになり、永遠に話が噛み合わない。

目的は同じでも、見ている階層がバラバラにより議論が平行線になってしまいます。

前提となる情報が全員に伝わっているか確認する
どの階層について議論しているのかを明確にする
必要に応じて前提そのものを疑う姿勢

ということが大切になります。

5. ワーク：仮説を立ててみる

仮説を立て、ズレを体験するワークが行われました。

ワークの実施内容

お題1(業務編): 「顧客が弊社サービスについてアンケートになかなか回答してくれません。どうしたら良いでしょうか。」
お題2:(ライフ編) 「あなたの友人がダイエットが続かないと嘆いています。どうしたら良いでしょうか。」
ワーク (3分): 「前提(仮定でOK)」「課題仮説」「ソリューション仮説」を、各自で付箋に書き出してください。

※正解はなく、同じお題でも立てる仮説が大きく異なることを体感してもらう

留意点

実際の業務だと

前提がわからないなら、前提をリサーチする
課題がわからないまま、ソリューションは検証しない
前提：課題：ソリューションは1：1：1にならない、基本的には後ろに行くほど膨れる

実際にワークを体験しましたが、前提から異なり、ズレていることが体感できました。

前提を共有していない状態では、前提レベルから大きく異なる回答が生まれる
実務では情報伝達を通じ、ある程度の前提合意がされているが、完全に揃っていないことが多い
ダイエット例から「そもそも本当にダイエットしたいのか」という前提の疑問も重要（健康になりたいだけで減らすことが目的ではない）

6. チームで同じベクトルに向くために

実際のプロダクト開発ではどうしていくのがよいか、というお話がありました。

共通言語

仮説(思考)は、チームの 「共通言語」 になる。 「前提が何で、どの階層の仮説について話しているか？」 をチーム全員で揃えることが重要。

揃える方法や仕組みもみんなで考え、改善をしていくこと。

明日からすぐにできることの例

1: PBI（プロダクトバックログアイテム）やチケット作成時のルール
- 必ず以下を明記する
  - 「どの階層の仮説を検証したいのか（課題/ソリューション/実行）」
  - 「その前提は何か」
2: ミーティングでの「指差し確認」
- 議論が噛み合わないと感じたら、「ちょっと待ってください。Aさんの意見は『ソリューション仮説』の話ですね。Bさんの意見は『課題仮説』そのものへの疑問ですね」と、交通整理する。
- 「今、私たちはどの階層の仮説を議論していますか？」と確認し合う癖をつける。
3: それでもズレる、そんな時には
- どこでズレているかを明らかにする
  - “なんか話が合わない人”で終わらせないこと
- 設定や戦略構造そのものがわかりづらいことも疑う
  - 受け取り手の問題もあるし、伝え手の問題もある

実践的な取り組み例が紹介されました。少しでも疑問に思ったり、違和感を感じたら、まずは立ち止まって確認することが大切ですね！

7. さいごに・まとめ

発表の締めとして、この仮説思考はプロダクト開発以外にも使えることが紹介されました。

仮説思考は、最強のポータブルスキル

この「仮説思考」は、プロダクト開発だけのテクニックではない。

ピープルマネジメント
- （例：「Aさんのモチベーションが低いように見える」→「（仮説）タスクが簡単すぎるのではないか？」→「（検証）少し難易度の高い仕事を任せてみよう」）
キャリア、私生活
- （例：「最近疲れが取れない」→「（仮説）睡眠時間が不足しているからだ」→「（検証）1週間、7時間睡眠を徹底してみよう」）

あらゆる問題解決の基本であり、どこに行っても通用する最強のポータブルスキルです。

まとめ

仮説とは　”おおよそこうだろう”という仮説を立て、小さく検証することで、 リスクを最小限 にして進めていくための、考え方(プロダクト開発において)
仮説の考え方や捉え方が合わないと”認識がズレる”が起きる
- 原因は、「仮説の階層（課題・ソリューション）」と「前提」が揃っていないこと
仮説思考は、ポータブルスキル。便利だから身につけよう