行動経済学とは？新人エンジニア向けに「人はいつも合理的に判断しない」という前提からUI/UX・開発・ビジネス応用を解説
山崎講師こんにちは。ゆうせいです。
今回は、行動経済学について、新人エンジニア向けに解説します。
行動経済学とは、簡単に言うと「人間はいつも合理的に判断するわけではない」という前提で、人の意思決定や行動を研究する分野です。
たとえば、次のような経験はありませんか？
無料トライアルと書かれると、つい登録してしまう 残り1点と表示されると、急に欲しくなる レビューが多い商品を安心して選ぶ セール価格を見ると、予定になかったものまで買う あと少しでポイントが貯まると、追加で買いたくなる 一度作ったコードを捨てるのがもったいなくて、無理に使い続ける
人は、毎回すべての情報を冷静に比較して、最適な判断をしているわけではありません。
時間がない、情報が多い、疲れている、不安がある、周りの人が気になる。
このような条件の中で、感覚やクセに影響されながら判断しています。
行動経済学は、この「人間らしい判断のクセ」を理解するための道具です。
経済学と行動経済学の違い
まず、従来の経済学と行動経済学の違いをざっくり整理しましょう。
| 項目 | 従来の経済学の考え方 | 行動経済学の考え方 |
|---|---|---|
| 人間像 | 合理的に判断する人 | 感情やクセに影響される人 |
| 判断 | 損得を計算して最適な選択をする | 損得だけでなく、見せ方や状況にも左右される |
| 情報処理 | 必要な情報を正しく処理できる | 情報が多いと迷ったり、簡単な判断に流れたりする |
| 例 | 一番安くて性能が良い商品を選ぶ | レビュー数、人気表示、限定表示に影響される |
従来の経済学では、人はかなり合理的に行動すると仮定されることがあります。
一方、行動経済学では、人間の判断にはズレやクセがあると考えます。
新人エンジニア向けにたとえるなら、従来の経済学は「理想的なアルゴリズム」を想定しているようなものです。
行動経済学は、「実際のユーザーは疲れていたり、勘違いしたり、画面を読み飛ばしたりする」と考える実務寄りの視点です。
新人エンジニアに行動経済学が必要な理由
エンジニアは、システムを作ります。
しかし、システムを使うのは人間です。
どれだけ正しく動くシステムでも、ユーザーが使いにくいと感じたら使われません。
どれだけ便利な機能でも、ユーザーが気づかなければ意味がありません。
どれだけ安全な設定でも、面倒すぎるとユーザーは避けようとします。
だから、エンジニアには「人間はどう判断するのか」という視点が必要です。
| エンジニアの仕事 | 行動経済学が関係する理由 |
|---|---|
| UI設計 | ボタン名、選択肢、初期値でユーザー行動が変わる |
| UX設計 | 不安、面倒、達成感が利用継続に影響する |
| 要件定義 | ユーザーが本当に合理的に使うとは限らない |
| プロジェクト管理 | 見積もり、先延ばし、サンクコストに影響される |
| セキュリティ | 安全でも面倒な仕組みは守られにくい |
| レビュー | 認知バイアスにより、自分のコードの問題に気づきにくい |
エンジニアは、コードだけを見る仕事ではありません。
人間がどう使うかまで考える仕事です。
重要概念1：限定合理性
限定合理性とは、人間は完全に合理的に判断したくても、時間、情報、能力に限界があるため、ほどほどの判断をするという考え方です。
難しく聞こえますが、かなり身近です。
たとえば、ノートPCを買うとき、すべてのメーカー、CPU、メモリ、ストレージ、重量、価格、保証、レビューを完璧に比較するのは大変です。
多くの人は、次のように判断します。
有名メーカーなら安心 レビューが多いから大丈夫そう 予算内だからこれでよい 友人が使っているからこれにしよう ランキング上位だから間違いなさそう
つまり、完璧な比較ではなく、現実的に判断できる範囲で選びます。
システム利用でも同じです。
ユーザーは、画面上の説明を全部読んでから操作するわけではありません。
目立つボタン、慣れた配置、分かりやすい文言を頼りに判断します。
| 限定合理性があるユーザー | UI設計で必要なこと |
|---|---|
| 説明文を全部読まない | 重要情報を短く目立たせる |
| 選択肢が多いと迷う | 選択肢を整理する |
| 初期設定のまま進めがち | デフォルト値を慎重に決める |
| 専門用語で止まる | 初心者向けの言葉に置き換える |
ユーザーに完璧な判断を期待するな！
迷いにくい設計を作ることが大切です。
重要概念2：ヒューリスティック
ヒューリスティックとは、人が素早く判断するための簡便な判断ルールです。
日本語では「経験則」と言われることもあります。
たとえば、次のような判断です。
レビューが多い商品は安心そう 高いものは品質が良さそう 有名企業のサービスなら信頼できそう 赤い表示は危険そう 一番上にある検索結果が重要そう
ヒューリスティックは便利です。
毎回すべてを細かく調べなくても判断できるからです。
ただし、間違いにつながることもあります。
たとえば、「高いから品質が良い」とは限りません。
「レビューが多いから自分に合う」とも限りません。
| ヒューリスティック | 便利な点 | 危険な点 |
|---|---|---|
| 人気があるものを選ぶ | 早く判断できる | 自分に合うとは限らない |
| 有名ブランドを信頼する | 安心しやすい | 中身を見ずに判断しやすい |
| 最初の情報を基準にする | 比較しやすい | 基準が間違っていると判断もズレる |
| 見た目が整っているものを信用する | 使いやすさの判断材料になる | 見た目だけで信頼しすぎる |
UIを作るエンジニアは、ユーザーがヒューリスティックで判断することを前提にしましょう。
ボタンの色、配置、文言、順番は、ユーザーの判断に影響します。
重要概念3：認知バイアス
認知バイアスとは、判断や記憶、解釈に生じる偏りのことです。
人間の脳にはクセがあります。
そのクセによって、合理的とは言えない判断をしてしまうことがあります。
エンジニアに関係しやすい認知バイアスを見てみましょう。
| 認知バイアス | 意味 | エンジニアの例 |
|---|---|---|
| 確証バイアス | 自分の考えに合う情報ばかり集める | 自分の実装が正しい前提でログを見る |
| アンカリング効果 | 最初に見た情報に引っ張られる | 最初の見積もり時間から離れられない |
| 利用可能性ヒューリスティック | 思い出しやすい情報を重視する | 最近起きた障害原因ばかり疑う |
| サンクコスト効果 | すでに使った時間やお金を惜しんでやめられない | 作りかけのコードを捨てられない |
| 現状維持バイアス | 変化を避け、今の状態を選びやすい | 古いツールや手順を変えたがらない |
新人エンジニアが特に注意したいのは、確証バイアスです。
自分が「原因はここだ」と思い込むと、それに合う情報ばかり見てしまいます。
デバッグでは、思い込みを疑いましょう。
ログを見ろ。仮説を疑え！
重要概念4：損失回避
損失回避とは、人は利益を得る喜びよりも、損をする痛みを強く感じやすいという傾向です。
たとえば、1,000円もらえる嬉しさより、1,000円失う悔しさのほうが強く感じられることがあります。
サービス設計では、この傾向がよく現れます。
| 場面 | 損失回避が働く例 |
|---|---|
| 買い物 | 今買わないと割引を逃すと感じる |
| サブスク | 解約すると特典を失うと感じる |
| 学習サービス | 連続学習記録が途切れるのが嫌で続ける |
| 業務システム | 操作ミスでデータを消すのが怖くて保存できない |
エンジニアがUIを作るときは、ユーザーの損失不安に配慮する必要があります。
たとえば、削除ボタンです。
ユーザーは「消したら戻せないかも」と不安になります。
だから、確認ダイアログや復元機能が重要になります。
本当に削除しますか？ 削除したデータは復元できません。
または、より安心できる設計です。
ゴミ箱へ移動します。 30日以内であれば復元できます。
ユーザーは、失うことに敏感です。
重要操作では、安心材料を用意しましょう。
重要概念5：現状維持バイアス
現状維持バイアスとは、人が今の状態を変えることを避けやすい傾向です。
たとえば、新しいツールが便利だと分かっていても、慣れたExcelを使い続けることがあります。
これは、今のやり方を変えることに心理的コストがあるからです。
| 場面 | 現状維持バイアスの例 |
|---|---|
| 社内システム導入 | 新システムより従来の手作業を続けたがる |
| 開発環境 | 新しいIDEやツールを避ける |
| 業務改善 | 非効率でも慣れた手順を続ける |
| セキュリティ | MFA設定を面倒に感じて後回しにする |
新しいシステムを導入するときは、便利さを説明するだけでは足りません。
ユーザーにとっての不安や面倒を減らす必要があります。
移行手順を短くする 最初の設定を簡単にする 従来業務との違いを説明する よくある質問を用意する 最初の成功体験を作る
変化には抵抗がある。
その前提で導入設計を考えましょう。
重要概念6：デフォルト効果
デフォルト効果とは、人は初期設定のまま選びやすいという傾向です。
たとえば、会員登録時にメール通知が最初からオンになっていると、そのまま進める人が多くなります。
逆に、最初からオフなら、わざわざオンにしない人も増えます。
デフォルト値は、ユーザー行動に大きな影響を与えます。
| デフォルト設定 | ユーザー行動への影響 |
|---|---|
| 通知オン | 通知を受け取る人が増えやすい |
| 通知オフ | 通知を受け取らない人が増えやすい |
| 公開設定がオン | 意図せず公開するリスクがある |
| 安全設定がオン | 安全な状態を標準にしやすい |
エンジニアが注意すべきなのは、デフォルト値には責任があるということです。
特に、公開範囲、通知、個人情報、課金、セキュリティに関係するデフォルトは慎重に決める必要があります。
デフォルトは、ただの初期値ではありません。
ユーザーへの提案です。
重要概念7：ナッジ
ナッジとは、人の選択の自由を残しながら、より望ましい行動へそっと後押しする設計です。
英語のnudgeには「軽く肘でつつく」という意味があります。
命令ではありません。
強制でもありません。
選びやすい環境を作ることです。
| ナッジの例 | 目的 |
|---|---|
| 安全なパスワード条件を分かりやすく表示する | 安全な設定を促す |
| フォームの未入力欄をその場で知らせる | 入力ミスを減らす |
| 保存前に確認画面を出す | 誤操作を防ぐ |
| 健康診断の予約候補日を先に提示する | 予約を後押しする |
| 研修課題の進捗を見える化する | 学習継続を助ける |
良いナッジは、ユーザーを助けます。
悪いナッジは、ユーザーを誘導しすぎたり、不利益な選択へ押し込んだりします。
ナッジを使うなら、ユーザーの利益を中心に考えてください。
だますな。助けろ！
重要概念8：フレーミング効果
フレーミング効果とは、同じ内容でも、伝え方によって受け取り方が変わる効果です。
たとえば、次の2つは意味が近いですが、印象が違います。
成功率90% 失敗率10%
どちらも同じ情報に近いですが、「成功率90%」のほうが安心して見えることがあります。
エンジニアの仕事でも、フレーミングは重要です。
| 伝え方 | 受け取られ方 |
|---|---|
| この機能はまだできていません | 遅れている印象 |
| 主要処理は完了し、残りはエラー表示の調整です | 進捗と残課題が分かる |
| バグが多いです | 不安が大きい |
| 重大度高のバグは0件、表示崩れが3件残っています | 状況を判断しやすい |
フレーミングは、事実を歪めることではありません。
相手が判断しやすい形で、正確に伝えることです。
重要概念9：アンカリング効果
アンカリング効果とは、最初に見た数字や情報が、その後の判断に強く影響することです。
たとえば、最初に「この作業は1日で終わる」と聞くと、その後に複雑な問題が分かっても、1日という基準に引っ張られます。
見積もりでよく起きます。
| 場面 | アンカリングの例 |
|---|---|
| 工数見積もり | 最初の「2日くらい」に引っ張られる |
| 価格判断 | 定価10万円、今だけ5万円だと安く感じる |
| レビュー | 最初のコメントに引っ張られて全体評価が偏る |
| 障害調査 | 最初に疑った原因から離れられない |
新人エンジニアが見積もりをするときは、最初の数字を疑いましょう。
次のように分解すると、アンカリングを弱められます。
実装に何時間かかるか テストに何時間かかるか レビュー対応に何時間かかるか 調査にどれくらい不確実性があるか 予備時間をどれくらい見るか
最初の数字に引っ張られるな。
分解して見積もれ！
重要概念10：サンクコスト効果
サンクコスト効果とは、すでに使った時間やお金を惜しんで、合理的にはやめたほうがよいことを続けてしまう傾向です。
エンジニアの仕事では、かなりよくあります。
この実装に3日かけたから、今さら捨てたくない このライブラリを選んだから、問題があっても使い続けたい この設計で進めてきたから、変更したくない ここまで調べたから、別の原因を疑いたくない
しかし、過去に使った時間は戻りません。
大事なのは、今からどうするのが最善かです。
| サンクコストに引っ張られる考え | 切り替えた考え |
|---|---|
| ここまで作ったから使いたい | 今後の保守性を考えると作り直すべきか確認する |
| 調査に時間を使ったからこの原因のはず | 別の仮説も検証する |
| 選んだツールを変えたくない | 要件に合わないなら変更を検討する |
コードを捨てる勇気も、エンジニアのスキルです。
もったいないから残す、は危険です。
UI/UXへの応用
行動経済学は、UI/UX設計ととても相性が良いです。
UIとは、User Interfaceの略で、ボタンや入力欄などユーザーが触る部分です。
UXとは、User Experienceの略で、ユーザーがサービスを使う中で得る体験全体です。
| 行動経済学の考え方 | UI/UXでの応用 |
|---|---|
| 限定合理性 | 情報を整理し、迷わせない画面にする |
| デフォルト効果 | 安全で望ましい初期設定にする |
| 損失回避 | 削除や変更時に確認と復元手段を用意する |
| ゴール勾配効果 | 進捗バーやステップ表示を使う |
| フレーミング効果 | ユーザーが判断しやすい表現にする |
| ナッジ | よりよい行動を自然に選びやすくする |
たとえば、ユーザー登録画面なら、次のように改善できます。
入力項目を最小限にする 現在のステップを表示する パスワード条件を事前に表示する 未入力エラーを入力欄の近くに出す 登録完了画面を表示する 重要な同意項目は分かりやすく書く
ユーザーは合理的なロボットではありません。
迷うし、不安になるし、面倒なら離脱します。
その前提で画面を作りましょう。
プロジェクト管理への応用
行動経済学は、プロジェクト管理にも役立ちます。
なぜなら、プロジェクトは人間の判断の連続だからです。
| 問題 | 関係する行動経済学 | 対策 |
|---|---|---|
| 見積もりが甘くなる | 楽観バイアス、アンカリング効果 | 作業を分解し、過去実績と比較する |
| 作りかけを捨てられない | サンクコスト効果 | 今後のコストで判断する |
| 問題報告が遅れる | 損失回避、評価への不安 | 早期報告を責めない文化を作る |
| 古い手順を変えられない | 現状維持バイアス | 移行コストを下げ、小さく試す |
| レビューで思い込みが起きる | 確証バイアス | 観点表やチェックリストを使う |
プロジェクト管理では、「人は正しく判断するはず」と考えるより、「判断は偏ることがある」と考えたほうが現実的です。
だから、チェックリスト、レビュー、振り返り、見える化が大切になります。
セキュリティへの応用
セキュリティでも、行動経済学は重要です。
どれだけ安全な仕組みでも、ユーザーが面倒に感じて回避すれば意味がありません。
| セキュリティ施策 | ユーザー心理 | 工夫 |
|---|---|---|
| MFA | 面倒に感じる | 必要性と手順を分かりやすくする |
| パスワード変更 | 後回しにしがち | 期限と理由を明確にする |
| 警告画面 | 毎回出ると無視される | 本当に重要な場面に絞る |
| 権限申請 | 複雑だと抜け道を探す | 申請導線を簡単にする |
セキュリティは、正論だけでは守られません。
安全な行動を取りやすい設計にする必要があります。
行動経済学を悪用してはいけない
行動経済学は、人の行動を理解する強力な道具です。
だからこそ、悪用してはいけません。
| 悪い使い方 | 問題点 |
|---|---|
| 解約ボタンをわざと見つけにくくする | ユーザーの自由を妨げる |
| 不安をあおって購入させる | 信頼を失う |
| 勝手に有料オプションを選択済みにする | 不利益なデフォルトになる |
| 残りわずかを偽って表示する | 誤認を招く |
| 通知を大量に出して離脱を防ごうとする | ユーザーを疲れさせる |
良い行動経済学の使い方は、ユーザーの判断を助けることです。
悪い使い方は、ユーザーを操作することです。
エンジニアは、ユーザーをだます仕組みではなく、ユーザーが納得して選べる仕組みを作りましょう。
新人エンジニアが明日から使えるチェックリスト
画面や機能を作るときは、次のチェックリストを使ってみてください。
ユーザーはこの画面で何を判断するのか 選択肢は多すぎないか デフォルト値は安全で妥当か ボタン名は具体的か ユーザーが損を恐れる場面に安心材料があるか 削除や課金など重要操作に確認があるか 進捗や完了が分かるか エラー文は次の行動を示しているか ユーザーを不安で急かしていないか ユーザーにとって本当に利益がある設計か
このチェックリストを使うだけでも、かなり実務的なUIになります。
行動経済学のメリット
行動経済学を学ぶメリットを整理します。
| メリット | 説明 |
|---|---|
| ユーザー理解が深まる | 人がなぜ迷うのか、なぜ行動しないのかを考えられる |
| UI/UXが改善する | 選択肢、初期値、導線を設計しやすくなる |
| プロジェクト管理に役立つ | 見積もりミスやサンクコストに気づきやすくなる |
| セキュリティ設計に使える | 安全な行動を取りやすくできる |
| ビジネス視点が育つ | ユーザー行動とサービス価値をつなげて考えられる |
行動経済学を知ると、単に「機能を作る」だけでなく、「使われる仕組みを作る」視点が育ちます。
行動経済学の注意点
一方で、注意点もあります。
| 注意点 | 説明 |
|---|---|
| すべての人に同じ効果が出るわけではない | ユーザー属性や状況によって反応は変わる |
| 心理効果を万能だと思わない | 性能、価格、品質、サポートも重要 |
| 短期成果だけを追わない | 信頼を失う設計は長期的に損をする |
| 倫理を忘れない | ユーザーの利益を中心に考える |
| 検証が必要 | 実際のユーザー行動を見て改善する |
行動経済学は、正解を暗記する学問ではありません。
仮説を立て、試し、結果を見て改善するための道具です。
エンジニアリングと相性が良いですね。
まとめ
行動経済学とは、人間はいつも合理的に判断するわけではないという前提で、人の意思決定や行動を考える分野です。
新人エンジニアにとっては、UI/UX、プロジェクト管理、セキュリティ、レビュー、要件定義に役立つ実務的な考え方です。
| 概念 | 意味 | エンジニアでの活用 |
|---|---|---|
| 限定合理性 | 人は限られた情報と時間で判断する | 迷わない画面を作る |
| ヒューリスティック | 簡単な判断ルールで選ぶ | 配置や文言を分かりやすくする |
| 認知バイアス | 判断の偏り | レビューや見積もりで思い込みを減らす |
| 損失回避 | 得より損を強く感じる | 削除や変更時に安心材料を出す |
| デフォルト効果 | 初期設定のまま選びやすい | 安全な初期値を設計する |
| ナッジ | 選択の自由を残して望ましい行動を後押しする | ユーザーを助ける導線を作る |
一言でまとめるなら、行動経済学は「人間らしい判断のクセを理解し、より良い選択をしやすくするための考え方」です。
新人エンジニアは、ユーザーを合理的なロボットとして見ないでください。
ユーザーは迷います。
不安になります。
説明を読み飛ばします。
初期値のまま進みます。
損をしたくないと感じます。
だからこそ、エンジニアは人間のクセを前提に設計する必要があります。
ユーザーは何を見て判断するのか
↓
どこで迷うのか
↓
何を不安に感じるのか
↓
どの初期値が安全か
↓
どうすれば納得して選べるか
↓
ユーザーの利益になる設計か
今後の学習では、行動経済学に加えて、認知バイアス、ナッジ、プロスペクト理論、損失回避、フレーミング効果、UI/UX心理学、認知負荷、ユーザビリティテストを順番に学ぶとよいです。まずは明日の画面実装で、「このデフォルト値はユーザーにとって安全か？」「このボタン名は迷わないか？」を確認するところから始めてみましょう！
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
