計算論的アプローチが、最短の問題解決手法である

認知バイアスにより問題解決が阻害されている場合が多くあります。ここでは、計算論的アプローチを使って、何が問題かという問題意識を共有して、認知バイアスを補正し、問題解決を図る課題管理手法（CTPM；Computational Thinking of Problem Management）を提案します。

みずほ銀行のシステム問題で、頭取の交代が延期されるようです。経営の問題に対しては、トップが交代して、経営をやり直します。システム問題は、経営の問題ではないという判断なのでしょう。現状は、システムの問題解決の手順を組み立てている最中と推測します。問題解決の手順が進んでいれば、人事の延期はないからです。

問題解決の手順がすぐに立てられない理由は、今まで、大きなレガシーシステムに問題があるという認識がなかったためと思われます。経済産業省は、「2025年の崖」のレポートを書きました。これは、みずほ銀行のタイプの問題解決に寄与するでしょうか。このレポートを読んだある企業の社員は、「2025年の崖」は、みずほ銀行の問題で、わが社には関係がないと考えます。これは、関係がある考えると、膨大な作業が必要になるからです。さらに、ブラックな組織では、問題を提示した人に解決を強要する場合もあります。つまり、レガシーシステム問題を認めたくないという認知バイアスがあれば、レポートは「2025年の崖」問題の解決には繋がりません。

認知バイアスは、問題解決を阻害します。最初に、何が問題かという問題意識を共有化して、認知バイアスを補正すべきです。

計算論的なアプローチを使った問題解決の例を考えます。大きなシステム開発は、グループ作業になります。全体のシステム概要を設計して、その後、パーツに分けて開発を分担してもらいます。モジュール毎のパラメータの引き渡しをどうするか、保守を考えて、モジュールの仕様をどのレベルまで共有できるかをすり合わせます。個別のモジュールができたら、全体を組み立てて、動作確認をします。組み立てた時の問題点を整理して、各モジュールの開発部隊に、改善をもとめます。個別モジュールの作りやすさを考えて、全体の仕様を調整することもあります。（注1）

以上のシステム開発手順を図１に、概念化しています。ただし、図1は、システム開発ではなく、同じ手法を実社会で、問題解決の課題管理に使う場合です。緑の矢印は、リアクション、または、情報の参照です。

大問題は、戦略レベルの課題です。気候変動、少子化、男女平等などが例です。

小問題は、戦術レベルの課題です。電気自動車の開発などが例です。

小問題は、実施計画（コーディングに相当）を立てる時点で、内容が精査され、調整されます。多くの認知バイアス（先入観）はこの時点で、取り除かれます。

大問題は、いったん、小問題に分解され、次に、小問題を再合成して大問題を作る時点で、改善されます。大問題に、大きな認知バイアスがあって、再合成が困難になる時には、大課題は改造されます。つまり、ここでも、認知バイアスは修正されます。

図1のシステム開発手法は非常に洗練されています。この手法は、コンピュータが広まって、50年の淘汰を潜り抜けてきました。システム開発では、製品の出る時期が半年遅れれば、致命傷になるので、月以下の短い時間で、開発管理を行います。このスピード感は、他の分野には例をみません。この手法は、最短の問題解決手法です。

この手法を応用すれば、現在の社会問題の解決が容易になると思います。

この手法は、問題を大問題と小問題に分けて、その間の分割と統合を繰り返して、解決に近づく方法です。この場合、問題は解決可能なものに限定されます。ポイントは、適切な問題設定です。問題設定の手順で、問題点が判り、認知バイアスが解消されます。認知科学から見れば、こうした問題を認識するレベルを無視して、解決策は提示できません。

例えば、CO２をゼロにするという大問題は、解決可能な小問題が整理された時点で、初めて、検討問題にあげられます。小問題の解決可能性のチェックを通じて、認知バイアスの修正がなされます。

コロナ対策でも、オリンピックの開催問題でも、大問題と小問題のリストと分担者を明示して、各グループに協力してもらうという、この手法は有効と思われます。ネットを通じて、課題間の調整を随時行う必要があります。

図2は、現状の課題管理手法です。大企業、大学、官庁などは、このスタイルになっています。このスタイルには、次の問題点があります。