トラブルプロジェクトのノウハウは、「何故」伝承されないのか？
これまで、「プロジェクトトラブルを防ぐには」という観点で、いろいろな取り組み施策について考察してきました。しかしながら、未だに無くなることなく、「少なくなっている」と言えるのかも疑問な状況ではないでしょうか。そこで、「それは何故なのか」、「何故無くならないのか」ということについて、改めて考察したいと思います。
システム構築プロジェクトは、結局「人（個々人）」の対応であり、人と人の関係で成り立っていること。そして、その人の「知見」が成否に大いに関係すると言えるでしょう。
トラブルプロジェクトを経験した「人」は、間違いなく「トラブル対処・回避ノウハウ」を習得し、事前対処を徹底することでしょう。ただ、中には、例外的（？）に「同じ轍を踏む」人もいることもありますが。（あいつがプロジェクトに入ると、必ずと言ってもいいほど「トラブルよな」という経験があるのでは？）
しかしながら、人は歳を取り（世代交代もあり）、いずれその会社を去り、その人が持っていた「トラブル対処・回避ノウハウ」は消えていきます。
だからこそ、人は後に残そうとして、自身の「背中を見せること」や「記録として残す」などし、「教材」として継承化する努力をしてきました。そうしたノウハウが完全に継承されれば、トラブルは減少し消失していくはずですが、実際そうはなっていないのが現実です。
それは、その人の行動様式までを、完全にコピー（継承）することは出来ませんし、そうは「しない」というのも「人の性」だからかもしれません。
こうした「人の本質（性）」を認識した上での、対策が重要なのではないかと考えています。
１．継承されない、しない要因
過去に失敗した事例があるハズなのに、また同じ様な失敗が繰り返される（無くならない、無くせない）のは、何故でしょうか？
【人の認識、考え方の傾向（言い訳）】
■プロジェクトは、それぞれ「要件も条件も」同じものは一つとしてない。（「単発」「割り切り」意識）
・「前例」や「経験談」を、鵜呑みにしても使えない。
・時代も技術も変わっているので、そのまま当て嵌ることは無い。
■他人の経験を幾ら伝えられても、実感しない。（所詮「他人事」）
・教育や学習は、あくまで机上論という意識。自身が実体験しないと、本気にならない。
・他人の経験に対し、「自分なら違う対応をする、できる」という自尊心（驕り）がある。
■自分の考え以外は、「ない・ダメ」という思い込み。
・２人いれば２つの考え方があり、「自身の常識は他人の常識ではない」ということに気づいていない。
・自身を「過信」する。
（私は正しい。担当は言うことを聞いていれば良い。独りよがりな傾向）
・一度「思い込む」と、周りが見えなくなる、見なくなる。
■目先のことだけに注力してしまいがち。
・プロジェクトは、完了すればそれでいい。それでおしまいだ。
・自分に与えられた範囲を、こなせばそれで良い。
・俯瞰的に物事を観ない、考えない。（周囲や先のことは二の次）
このような傾向に対し、もちろん何もしてこなかった訳ではありません。
【これまでの主な取り組み】
■プロジェクトのトラブル要因を洗い出し、マニュアル化（ハンドブック化）し、伝承教育の実践。
■「失敗から学ぶ」という場の設定。トラブル事象の学習（ロールプレイング、グループ検討など。
■プロジェクト実施時における「チェック機構」の構築。
など
といったことが実践されてきことは、ご承知の通りです。しかしながら、その実態はどうだったのでしょうか。
プロジェクトに取り入れ、活かすということよりも、形式的（アリバイ作り）、その場限りの対応で済ませてきていたのではないでしょうか。その結果が、「トラブルが減らない、なくならない要因」と言っても過言ではないかもしれません。
２．必要となる取り組み
「過去の失敗を自分事として捉えろ」「俯瞰的、多面的にものを見ろ」と言っても、一朝一夕で実践できることではありません。如何に、組織的な仕組みや、フォロー体制を造り、会社として「個々人の性格や考え方、行動様式を変革していくこと」が継続的実践出来るかに掛かっているかと思います。
【トラブル予兆を、発見できる仕組み作り】
トラブル解消は、如何に早く気づき、対応できるかに掛かっているということは言うまでもありません。そのため、それを実践しえる「仕組み、環境造り」が重要であると考えます。
■常に、俯瞰的に物事を見、考えさせる「癖」つくり。（指導面）
■「良い意味でのお節介」意識の醸成。
■報告しやすい「雰囲気、空気、場」造り。（報告者の思惑や忖度不要）
■報告内容に関する「正確性・真実性」の担保。（３現主義の徹底）
【第三者がチェックする仕組みの再整備】
これまでも「第三者検証」という取り組みは行われてきましたが、形式的になる面や、責任追及の場に陥ることが否めなかったのではないでしょうか。その解消に向けた取り組みが必要だと考えます。
■課題対応者へのフォローの徹底。（解消するまでの追跡）
■妥協しない検証プロセスの徹底。（突っ込んだ検証）
■原因責任を追及（糾弾）する場意識の回避。
■課題解消に向けて「会社を活用する仕組みだ」といった認識作り。
【マネジメント力の向上取り組み施策強化】
プロジェクトの成否を「担当個々人の力量に頼る」だけではなく、組織としてのマネジメント力向上施策の拡充が重要と考えます。
■気になることは、些細なことでも発言できる環境作り。「否定しないでまずは、聞く」ことができるマネージャー・リーダーの育成。
■トラブル対応経験を、マネージャー、リーダーの資格要件化。
（トラブル要因を体験、体感したことがあるということ ）
■作成請負型プロジェクト専門部隊の組織化。（組織としての継承）
■社内向き思考（上司対応・忖度）からの脱却。
■顧客キーマンとの信頼獲得のための取り組みの徹底。
＊１：トラブル要因の実体験・実態感
マネージャー（幹部社員）やプロジェクトリーダー資格として、「トラブル経験者または、収斂経験者（トラブルを収めた人）」であることに越したことはありませんが、トラブルに対峙したことが無いという人に資格が無いということではありません。トラブル未経験者を含め、幹部候補者には「これまでの取り組み方」や「トラブル発生要因に対する認識」などについて、レポーティング（教えるだけでなく、自身の考え方を発信）してもらうというような取り組みが必要だと考えています。
以上、プロジェクトトラブルの防止には、「人の本質（性）」に関わる観点からの対応が不可欠であろうと考えます。
システム構築においては、「完全にＡＩ化、ノーコード化、ローコード化」が進展したとしても、その大元には「人」が介在せざるを得ないと考えると、やはり永遠にプロジェクトトラブルは無くならないと考えておくべきなのだと考えています。
何にせよ、「人が介在する以上」、トラブル対応への取り組みは、永遠の課題なのかもしれません。