プロジェクト運営を妨げるプロスペクト理論のワナ

開発プロジェクトを進めるにあたり、プロジェクト計画書を作ることは基本中の基本です。

プロジェクト計画書には、プロジェクトの目的、スケジュール、開発体制、開発プロセス、コミュニケーションの取り方、会議体など、開発を進める上に必要な情報を盛り込みます。

プロジェクト計画を行わないでプロジェクトが失敗するのはよくある話ですが、プロジェクト計画書をしっかり作り、それに沿ってプロジェクトを進めてもうまくいかないことが多いのも、残念ながら事実です。

そこには「プロスペクト理論」という、PMや開発リーダーの判断を誤らせる論理が働いていることがよくあります。

この「プロスペクト理論」を理解することで、プロジェクト運営を妨害するワナにかかりにくくなると思いますので、ご紹介したいと思います。

プロスペクト理論とは

プロスペクト理論を一言で言うなら「人間は損をするのが大嫌い」理論と言えるでしょう。

この理論では、損失発生が明らかな状況下において、人間は合理的な判断が行えないことを実証しています。

有名な実験があります。

次の選択肢のうち、あなたならどちらを選びますか？

どちらも期待値は同じ100万円ですが、多くの人はAを選ぶのではないでしょうか。

しかしこれが、あなたが200万円の借金をしているとして、次の2つの選択肢が提示された場合はどうでしょう？

どちらの選択肢も期待値は-100万円で変わらないのは、質問1と同じです。しかし、この実験では質問1で選択肢Aを選んだほぼ全ての人が、質問2ではギャンブル性の高い選択肢Bを選んだそうです。

質問1は50%の確率で何ももらえないというリスクを回避しようとし、質問2では100%の確率でお金を支払うという損失を回避しようとしたわけです。

これは確率が50%の確率の質問ですが、質問2のBの選択肢を「30%の確率で借金全額免除」とした場合も結果は変わらなかったそうです。

この場合の期待値は、選択肢Aは-100万円、選択肢Bは-60万円となるため、選択肢Aを選んだほうが得する確率が高いということになります。

しかし多くの人は選択肢Bを選んだという実験結果からも分かる通り、多くの人がこのような合理的判断をしていないことが分かります。

パチンコなどのギャンブルが分かりやすいですね。負けている状況でも「次は勝てるかもしれない」「次で巻き返そう」という心理状態で泥沼にハマッていくやつです。

これをプロスペクト理論の「損失回避性」と呼びます。

では、この「プロスペクト理論」はプロジェクト運営にどう関わっているのでしょうか？

IT業界で働いているみなさんは、プロジェクトがスケジュール通りに進まないことはよくご存じだと思います。（他の業界もそうかもしれませんが）

メンバーから開発が遅れているという報告を受けたとき、チームリーダーはどのような判断をするでしょうか？

とりあえずすぐ実行できるのはこんなところだと思います。または後半の巻き返しに期待して、様子見の判断をするかもしれません。

しかし、遅れがより顕著になってきてどうにも選択肢A、Bでは吸収できそうにもない状態になったらどうでしょう？

遅れの原因やプロジェクトの置かれている立場によって取れる選択肢は限られると思いますが、多くの場合、選択肢C～Eのどれか（または全部）を選ぶことになると思います。

しかし、これらの選択肢はクライアントや上司などと交渉し許可を得る必要があります。そこで、クライアントや上司に頼らず、自分たちだけで解決したいPMやリーダーが取る全く別の選択肢があることをご存じでしょうか。

はい、これです。スケジュールの遅れは作りこみの段階で顕在化することが多いため、スキップされるのはだいたいテスト工程です。

さて、作ったプログラムをテストしないとどうなるでしょう？

バグが見つけられませんね。バグが見つからないとどうなるでしょう？

納品前検査など後工程でバグが大量発生し、会社から帰れなくなりますね。最悪、納品後にバグが見つかりクライアントから怒られます。

論理的に考えれば、良い結果にならない確率が高いことは分かると思います。

これが開発プロジェクトにおける「プロスペクト理論」です。

クライアントに怒られたくないという単なる保身でこのような判断をする人もいると思いますが、私は技術者だからこそ、このような判断をしやすいのではないかと考えています。

私もそうですが、技術者は自分で難しい問題（特に技術的な問題）を解決することに喜びを感じます。特に優秀な技術者ほど「俺なら解決できるはずだ」というプライドもあり、その傾向は強いように感じます。

その特性が災いして、プロジェクトを自分たちでどうにかしようという意識が強くなり、むしろ合理的な判断が下せないことが多いようにも思います。

システム開発は論理的思考（ロジカル・シンキング）が強く求められる仕事です。

しかし論理的思考（ロジカル・シンキング）が得意なはずのSEが、実はプロジェクト運営において合理的判断を下せないことがある、という事実を認識することが重要だと思います。

このことを認識し、自分が本当に合理的な判断が下せているかを自問自答することで、ワナにはまらず、プロジェクトの回し方も上達していくのではないでしょうか。