ソフトウェア開発に役立つ　心理学的現象、行動経済学の概念など　15題

ソフトウェア開発の様々な局面で役に立つ、心理学的現象や行動経済学についての知識です。

経験則で把握済の事柄もあるかもしれませんが、

言語化して名前を与えることで何かのときにスッと出せたり、周囲の方々と議論しやすくなったりすると思います。

以下の3つの分類で記載いたします。

• 打ち合わせやチームワークに役立つ知識
• 設計やプログラミングに役立つ知識
• メンタルヘルスケアに役立つ知識

打ち合わせやチームワークに役立つ知識

自己効力感

自己効力感とは、自分には何かを達成する能力がある、と信じる感覚です。

自己効力感が形成されていると、仕事の意欲が増したり、効率が上がったりします。

「この仕事は絶対ムリ～(>_<)！」と感じている仕事についてやる気がわかなかったり進捗が出なかったりするのは、自己効力感の欠如が原因であることがあります。一旦やる気を出すと案外簡単に進められたとか、真剣に取り組むと思ったより楽で「あの息苦しさは何だったんだろう……」と拍子抜けした経験をお持ちではないでしょうか。

• ソフトウェア開発への役立て方：
  • チームリーダーはメンバーに自己効力感を形成させることも重要な仕事です。その方法は成功体験を積ませることです。そのためにはメンバーに適切な難易度の仕事を与えたり、困っていることを早期に察知してサポートするといった行動が有効といえます。さらにメンバーの行動に適切な内容のフィードバックを速やかに与えることも重要です
  • 「チーム効力感」や「集団効力感」という概念もあります。これはチームや集団にとっての自己効力感です。チーム効力感も仕事の意欲や生産性に影響します。チーム効力感の形成のためには、失敗事項や要改善点のみを議論するのではなく、成功要因を分析したりより上位の立場（マネージャーなど）から褒めてもらえるようチームリーダーが働きかけたりすると良いでしょう

また、関連する概念として「学習性無力感」があります。

ひとは、自分の行動と無関係に罰が与えられると、自分は罰を避けることができないと学習してしまいます。「何をやってもどうせうまくいかない」という感覚です。この無力感が学習性無力感です。

学習性無力感があると、自己効力感の形成が阻害されてしまいます。

• ソフトウェア開発への役立て方：
  • 適切な理由があるときにしか、何かを問い詰めたりしてはいけません。つまり、不必要なあら探しをすると学習性無力感を生み出してしまい、ひいては自己効力感の形成の遅れを引き起こしてしまいます。チームメンバーがあら探しを始めたら話題を変えるよう誘導するのが合理的行動といえます

社会的手抜き

一緒に仕事をする仲間が多すぎるとひとりひとりの生産性が低下する現象です。

たとえば参加者が多すぎる会議では、ほぼ発言しない参加者や一生懸命内職している参加者があらわれてしまいます。

そうした参加者があらわれると割れ窓効果で本来やる気があるメンバーの意欲まで低下してしまいかねません。

このように社会的手抜きの放置は割れ窓効果を引き起こしてさらなる状況の悪化を招くことがあります。

つまり社会的手抜きを放置しても大抵ろくな結果につながりません。

原因は次の2点といわれています。

• 責任感が分散して希薄になること
• 人が多すぎて個々人の貢献が適切に評価されづらくなるので生産性を上げるインセンティブが低下すること

これらの原因を除去することでも対処可能です。具体的には、たとえば全員に何らかの情報発信を義務付けるというルールを課します。これは教育現場でよく使わるルールです。授業後のアンケートや課題の提出を単位認定の条件として挙げてある授業はどこの大学でも見つけられることでしょう。アンケートや課題の提出という責任を与え、さらにそれらをもとに個々人の適切な評価を行う仕組みです。

• ソフトウェア開発への役立て方：
  • 参加者が多すぎる会議は参加者の数を6人程度に抑えます。もしくは小グループに分割したうえでそれぞれ議論させます
  • ひとつのチームの人数を必要以上に多くしてはいけません。これは「ピザ2枚ルール」という名前でも知られています。このルールは、チームはピザ2枚を分け合える程度の人数とすべき、というAmazon CEOのジェフ・べゾスのルールです

行為者-観察者バイアス

ひとは、

• 自分自身の行動は周囲の環境によって引き起こされていると考えがちです
  • 例：　私がダメな設計をしてしまったのはリーダーの指示が曖昧だったからだ
• 他のひとの行動はそのひと自身によって引き起こされていると考えがちです
  • 例：　あのひとがダメな設計をしてしまったのはあのひとの能力が低いからだ

以上のように、行為者-観察者の立場の違いにより、行動を引き起こしている要因のとらえかたにバイアスがかかります。

• ソフトウェア開発への役立て方：
  • このバイアスのせいで、他のひとのタスクが失敗したときにはそのひと自身に要因があるととらえてしまいがちです。このことを踏まえ、問い詰める前にまずは周囲の環境（自分自身を含む）に疑いの目を向けましょう
  • ひとを問い詰めた場合、その相手は「自分のせいじゃなくて周囲の環境のせいなのに……」と不本意に感じる可能性が高いといえます。不本意な気持ちは不信感につながるので、この場合には丁寧な説明が必要です。また、不本意なままだと自己効力感を損なう場合もあります（＝「ooさんは俺のことを分かってくれない。こんな状況では効率的な仕事はできない」という考え）。データを用いたりしながら、そのひとが周囲に与えてしまった悪影響を誠実に説明しましょう

間違った4つの行動パターン

史上最強の人生戦略マニュアルという書籍で紹介されているパターンです。

問題に直面したときに取ってしまいがちな、間違った行動のパターンです。

1. 問題が起きたときに「こんなことが起こるはずがない」と問題を認めない。問題を放っておくうちにさらに状況が複雑化していってしまう
2. 最初の固定観念にこだわってしまい、本当かどうかを調べない。結果、時間を無駄にする
3. 現実を認める苦痛や恐怖を直視せず無気力状態になる。結果、問題のエスカレーションを招く
4. 周囲に助けを求めない。それどころか自分だけでなんとか解決することにだわる。結果、問題を解決できずさらに追い詰められる

史上最強の人生戦略マニュアルはタイトルこそ才走った感じでちょっと印象が悪いと私は感じてしまうのですが、内容はたとえば「自分の人生は自分自身で責任を持つ」「問題は素直に認める」といった地に足ついたものになっており、おすすめできる書籍です。

• ソフトウェア開発への役立て方：
  • 問題が起きたときには上記の4パターンに陥っていないかを自己点検します。陥っていたら早期に脱却して前向きな行動に移行しましょう
  • 周囲のメンバーが4パターンに陥っているときにはサポートしましょう。例：　問題が起きているのに周囲の助けを妙に遠ざけているひとは、4つ目のパターンに陥っているおそれがあります。積極的な状況確認と手助けが必要かもしれません

コンコルド効果

過去大きな投資を行ってきた場合に、それ以上の投資を行っても利益が出ないと薄々分かっているのにもかかわらず投資をやめられなくなる心理現象です。

例：　「これまでものすごい時間を使ってきたんだから、いまさらやめられないよ。メリットは薄いけど、やり切ってしまおうよ」という誰かの発言

• 由来：
  • イギリスとフランスは、利益が出ないとわかっているにもかかわらず、コンコルドという旅客機の開発をやめられませんでした。なぜなら、それまでに巨額の投資をしており今さら開発中止はできなかったためです

コンコルドは完成しいくつかの航空会社に販売されましたが、採算が取れず、最終的に製造中止となりました。

• ソフトウェア開発への役立て方：
  • 過去どのような投資をしていても、ダメなソフトウェアはダメなソフトウェアです。このことを認めて、破棄や作り直しを視野に入れて今後の処置を検討しましょう

最初に発言した人がリーダーになる

タイトルのとおりです。

キャメロン・アンダーソンとギャビン・キルダフが2009年に行った実験では、グループの中で最初に発言した人物がリーダーとして認識されやすいと分かったそうです。

• ソフトウェア開発への役立て方：
  • 主導権を握りたい打ち合わせでは最初に発言することが有効です。なお、私の経験則からくるテクニックでは、他のひとに取られてしまった主導権を奪うには、おもむろに立ち上がってホワイトボードに何かを書き始めるという方法が役に立ちます。何かを書き始めると注目されるし、その内容について説明を開始するのが必ず自分になるからです

段階的開示

UIやドキュメントについて、その時々に必要な情報のみを提供するという手法です。

私たちが日常の仕事でよく目にするパターンには、概略を説明してから詳細を説明する、正常系のフローを説明してから異常系を説明する、といったものがあります。

段階的開示により、情報の受け手は理解度が向上します。

• ソフトウェア開発への役立て方：
  • プレゼンではいきなり大量の情報を提示すると聴衆を圧倒してしまいます。段階的開示を用いることで、聴衆に私たちの意図をスムーズに理解してもらいましょう

内集団バイアス、外集団バイアス

• 内集団（＝自分が所属する集団）の成員のことは、個性的で能力が高いと錯覚してしまいがちです
  • 例：　「ooさんはとてつもない技術を持っているからなあ」←実際は世の中には想像を超える技術の持ち主が多数存在しており、「とてつもない」という形容は大げさなことがある
• 外集団（＝内集団以外の集団）の成員のことは、没個性で能力が低いと錯覚してしまいがち
  • 例：　「oo社は能力が低いからこの技術をマネできるはずがない！」

内集団バイアス、外集団バイアスは様々なレベルの集団で見られます。

たとえばチーム内の派閥は互いに外集団バイアスを持つので、互いに見下し合うことがあります。結果として非協力的な関係が形成されてしまうことがよくあります。

また、自社の商品力を内集団バイアスで過大評価してしまい、他社に遅れを取っていることを察知するのが遅れてしまうこともあります。

• ソフトウェア開発への役立て方：
  • 内集団や外集団について語るときはデータで説明しましょう
  • この2つのバイアスのせいで複数の集団同士は協力しづらい傾向があります。協力関係を形成させるには次の3つのアプローチが有効です：　(1) 集団（派閥等）の壁を崩す (2) 協力を推進する役割を誰かに課す (3) 集団同士での協力が必須となるような大きなミッションやタスクを与え、複数の集団を包含する大きな1つの集団の中へとメンバーを回収してしまう

設計やプログラミングに役立つ知識

欠如の不認知

ここでいう「欠如」の具体例は、「レビューの指摘漏れ」「デプロイ手順の実施漏れ」といった「漏れ」です。

欠如の認知は、しばしば困難です。たとえば忙しかったり実施中の作業に不慣れだったりすると、必要な仕事が欠如していることを見逃してしまいがちです。

• ソフトウェア開発への役立て方：
  • 業務の漏れを防ぐためにはチェックリストが効果的です（例：レビューのチェックリスト）。さらには、自動化も効果的といえます（例：デプロイの自動化）

時間割引

ひとは将来の利益を割り引いて評価します。

結果、将来の利益を小さく、目先の利益を大きく評価する傾向があります。

卑近な例では、ダイエットがうまくいかないのには時間割引が影響していることがあります。将来健康的に痩せる利益がわかっていてもその利益を割り引いて過小評価してしまい、目の前の食べ物をついつい口にしてしまいがちだというわけです。

• ソフトウェア開発への役立て方：
  • リファクタリングするかどうか迷ったときには、実施する方が良いケースが多いと考えられます。なぜなら、時間割引がはたらいている場合には、リファクタリングによる将来の利益を割り引いて評価した上で今リファクタリングしないことの利益（＝手間が発生しないことなど）と比較してどちらを選択するべきか迷っているからです。時間割引のバイアスを外して判断すれば、将来の利益のほうが大きいケースも多いのではないでしょうか

イケア効果

ひとは自分が手間をかけたものに高い自己評価を与えます。さらに周囲から高い評価を得られると期待してしまう傾向があります。

• 由来：
  • 家具屋のイケアは、購入者自身で組み立てるタイプの商品がラインナップの多くを占めます。購入者が自分で商品を組み立てると、労力をかけたので、他店の家具よりもその商品に高い評価を与えます
• ソフトウェア開発への役立て方：
  • 誰でも、自分で書いたコードには愛着を持ってしまうしそのコードが優れていると判断してしまいがちです。しかし実際は、世の中の標準やライブラリがあればそちらを利用したり周囲の意見に従ったりする方が品質が向上することが多々あります。なのでうっかりクソコードを書いてしまったときにはそのことを素直に認め、周囲の知見を利用することが賢明といえます
  • 他人はその人自身の設計やコードを優れたものと過大評価しがちです。なのでコードレビューで指摘を行うときには、イケア効果による過大評価を覆すために、指摘の理由を明確に伝える必要があります。また、その人にとっては優れているといえるはずの設計やコードを（場合によっては）否定することになるので、その人の自尊心を傷つけないように誠実な態度でコメントをつけると良いと考えられます

認知的負荷

ひとが何かを行うときに注意を払ったりいろいろ考えたりすることの負荷です。

たとえば不慣れな作業はいろいろと注意を払う必要があるので認知的負荷が高いといえます。

上達の法則によれば、ものごとの上達には次の4ステップがあります。

1. 知識の収集
2. 知識の記憶
3. 知識へのインデックスの付与
4. 知識を楽に使えるようにする

この4つ目のステップにかかわるのが認知的負荷です。知識を楽に使える = 低い認知的負荷で知識を使える　といえるからです。

認知的負荷を低減する有力な手段に反復練習がありますが、私たちはソフトウェア開発者らしく別の方法を考えましょう。

• ソフトウェア開発への役立て方：
  • 2つのコードやテキストの違いのチェックは、目視で行わず、Diffツールを使いましょう。Diffツールなら違いを一目瞭然にできるため認知的負荷を低く抑えられます。適切なツールを使うのも上達の方法の一つというわけです

新聞のルール、孫のルール

Personal MBAという書籍で紹介されている、短絡的な意思決定を防止するテクニックです。

何かの意思決定で迷ったら、

• 自分の意思決定が仮に翌朝の新聞で報じられたら世間がどのように受け止めるかを想像します
• 自分の意思決定が仮に将来の孫に知られたら孫がどう受け止めるかを想像します

この2つのテクニックにより、

• 客観的な視点で意思決定を評価できます
• 長期スパンの視点で意思決定を評価できます

以上の通り視点の切り替えに役立ちます。

• ソフトウェア開発への役立て方：
  • UIの設計で迷ったら新聞のルールを使います。新聞でUIが発表されても恥ずかしくないかを見直します
  • 悪い設計を見直す勇気がないときは孫のルールを思い出します。孫に胸を張れる仕事がどのようなものか、考え直す意欲がわいてくるのではないでしょうか

メンタルヘルスケアに役立つ知識

デイリーハッスル

デイリーハッスル（daily hassles）とは心理学者のLazarus, R. Sが提唱した概念です。これは日常的ないらだちごとのことで、たとえば長時間の通勤、対人関係、仕事内容といった長期的に蓄積されていくストレスを発生させます。

デイリーハッスルはメンタルヘルスに悪影響を与えます。

たとえば長時間の通勤はそれが一度だけなら大きな負担ではありませんが毎日のこととなるとメンタルを疲弊させます。不便な開発環境、意義を感じられない業務プロセス等でも同様のことがいえるでしょう。

デイリーハッスルはそれが単発であれば問題ありませんが、単発を乗り越えられるからといって長期化させることは考えものです。アメリカ心理学会は、急性ストレスは誰でも乗り越えられるし治療や管理が容易な一方で慢性ストレスは心身や命に破壊をもたらすと述べています。つまりストレスがメンタルに与える影響を考えるときには、そのストレスの強度だけではなく頻度や持続期間も考慮しなければなりません。

• ソフトウェア開発への役立て方：
  • デイリーハッスルを軽視してはいけません。一回ごとの強度は低いですが長期間頻発するとチームメンバーの満足度が低下してしまいす。デイリーハッスルを積極的に防止しましょう

相対的剥奪感

他人と自分を比較して抱く、「自分は何かを剥奪されている」という感覚のことです。

相対的剥奪感には2パターンあり、それぞれ具体例は次のとおりです。

• 利己的な相対的剥奪感：　自分と似ている他者と比較して感じる剥奪感
  • 例：　「俺とあいつは同じくらいの能力なのにあいつの方が優遇されている。ムカつく！」
  • 個人的な不満をもたらします
• 友愛的な相対的剥奪感：　自分と異なる他者と比較して感じる剥奪感。
  • 例：　「あちらのチームの方が評価が高いせいか、あちらのチームばかり新しい機材を購入してもらっている。こちらのチームみんなで上司に直談判しよう」
  • 集団に不満をもたらします。集団の反発的行動に発展するおそれがあります

相対的剥奪感にとらわれて精神的エネルギーを消耗していると、メンタルヘルスが徐々に悪化します。

なので対処が必要です。有効なアプローチは2つあります。相対的剥奪感が勘違いである場合はそれを明らかにすることと、そもそも人生は不公平なので諦めて受け入れることです。

• ソフトウェア開発への役立て方：
  • 勘違いからくる利己的な相対的剥奪感をなくす方法：　前提を疑います。つまり自分と似ている他者との比較で利己的な相対的剥奪感を抱いているはずなので、その他者が本当に自分と似ているのかを省みましょう。対人能力、プログラミング能力、キャリアの方向性の希望といった観点で省みましょう
  • 勘違いからくる友愛的な相対的剥奪感をなくす方法：　剥奪の事実関係を疑います。つまり自分たちが実際に不利な待遇を受けているのか確認します。発言力、業務環境、金銭、業務内容といった観点で省みましょう。また、違いがあって当然、という状況でないかを疑いましょう

まとめ

• 打ち合わせやチームワーク：
  • 自己効力感を自分やチームメンバーに形成させる。成功体験を積んで形成させる。意欲と効率を確保できる
  • 社会的手抜きの回避のために打ち合わせやチームの人数を抑える。一人ひとりの生産性が高まる
  • 行為者-観察者バイアスを踏まえて、他人ではなく周囲の環境に失敗の要因があるのではないかと最初に疑う
  • 間違った4つの行動パターンから早期に脱却。問題を認めて原因を特定する。問題を放置しても改善しないので重い腰を上げる。周囲に助けを求める。これらにより前向きな行動に移行する
  • コンコルド効果を踏まえて、ダメなものはダメと認める。無駄な投資を回避できる
  • 会議では最初に発言して主導権を握る
  • 段階的開示で効果的に情報を伝達する。プレゼンの説明順序はちゃんと工夫が必要
  • 内集団バイアス、外集団バイアスを踏まえて考えると、複数の集団同士にうまく協力させるには工夫が必要
• 設計やプログラミング：
  • 欠如の不認知の予防のためにチェックリストを作成したり自動化したりする。作業漏れを減らせる
  • 時間割引を踏まえて、将来の利益を高めに評価する。目先の利益に釣られた手抜きや間違った判断を防止できる
  • イケア効果を踏まえて、自分が手間をかけた設計やコード等にこだわりすぎないようにする。品質が上がる
  • 認知的負荷を低減することで物事が上達する。反復練習や適切なツールの利用がその手段
  • 新聞のルール、孫のルールで短絡的な意思決定を防止できる
• メンタルヘルスケア：
  • 弱い苦痛も早期に取り除くことが、幸福感の維持には大切
  • 相対的剥奪感は、勘違いならそれを明らかにする。もしくは受け入れる