問題解決管理とは
みなさんは、ＩＴ業界の人もそうでない人もいらっしゃると思いますが、ＩＴ業界におけるいわゆる『ソフトウェア開発』において、その成功率（失敗率）がどのくらいあるかご存知でしょうか。
ここでは、３ヶ月未満の小規模プロジェクトなら８割の成功率を出していますね。逆に１年以上の大規模プロジェクトでは７割に満たないそうです。
これがおよそ１０年ほど前はどうだったかと言うと、なんと30%程度しかなかったのです。今よりもシステム一つひとつの規模は小さく、難易度は低かったにもかかわらず、です。
ただ、所詮アンケートですし、全プロジェクトを対象にしたわけでもありませんし、各社のプライドみたいなものも左右していますから、この数字が本当に正しいかどうかはわかりません。それでも、まぁあながち的外れと言うわけでもないのでしょう。７割…と言うのが眉唾だとしても、昔に比べれば多少なりとも成功率は向上しているのだと思います。
それでも、ＩＴ市場における『失敗』と、その失敗にかかったコストは、おそらく年間数百億～１兆円規模で大きな損失を出していると思います。
このように、「この1年間で、顧客や取引先などの社外に影響を与えた重大なシステム障害は何回あったか」と言う問いに対しても３割以上が２～３回以上起こしているという実態もあります。
事実、私が関与したことのあるトラブルプロジェクトだけでも、開発当初のプロジェクト予算が
100億以上：３件
10億以上 ：12件
を見てきました。そういえば、これらのほとんどがこの10年内のプロジェクトばかりですね。そう、たった一人の中堅SIerに所属するＱＡだけでも、平均すれば１年で50～100億程度のトラブルプロジェクトにお目にかかっているのですから、業界全体での損失を合算すれば、1兆規模になってもおかしくありません（というか、いい加減そういう問題プロジェクトから解放して欲しい）。
私は、これは１つのビジネス市場だと思っています。
実際、そう思ってビジネス展開されている企業もあるのではないでしょうか。実際、こういうトラブルプロジェクトを「早期解決のご支援をします！」と言えば、大量に仕事が来るんじゃないですかね。…と言っても、価格設定難しいでしょうけど。そもそも早期解決しなかったら、どれだけの損失が出ていたか…？なんて仮説でしか出ませんしね。でも、変に価格の固定化してしまうと、10億の改善価値がある支援をしても、1人月100万とか200万程度にしかならないってんじゃ、やってらんないって気持ちになっても仕方ありませんね。
ただまぁ、そういう世知辛い課題は置いておくとして、たまたまそういったことに慣れている私に言わせると…トラブルプロジェクトってやつに対するアプローチは、
・トラブルを未然に防ぐ
・起きたトラブルを鎮火させる
の２種類しかないのですが、いかんせん前者は難しいんです。なぜなら、自らがマネジメントするプロジェクトでもないのに、トラブルになる気配すらまだない状況から、マネージャーのやり方に口をはさんでも、たいていの場合、どのSIer、どのマネージャーからも受け入れられないからです。プライド高いんですよね、この業界の人って…。
ですから、まずはトラブルや問題を起こしてもらって、少しプライドの鼻をへし折ってからでないと、なかなか改善できません。ＰＤＣＡフレームワークで言えば、
Doから始めて、色々失敗してもらい、Check、Actを経て
次のプロジェクトにつなげていく
と言う感じになるでしょうか。問題を起こしたくないのに、起こしてからでないとなかなか加われないジレンマ、悲しい…。
ですが、そうやって改善していくにしても、常日頃から起きた「問題」を管理し、記録し続けていかなければ、あとでまとめて評価（Check）することもできません。評価ができなければ対策（Act）することも、次のプロジェクトにつなげることも不可能です。
そう、「問題」の発生と解決について常に管理し続けることがとても大切なのです。
問題解決管理の意味
先述の通り、『事業』と言うマクロな観点からも、自分たちが行っている活動の見直しを日々行っていくうえで、問題解決管理とはとても重要なものです。
ですが、それと同時に『プロジェクト』というミクロな観点からも、問題解決管理は重要なポイントとなってきます。
プロジェクトマネジメントのなかで、「問題解決管理」が重要になってくる理由、それは
残件の把握
です。問題は常に一つずつ湧いてくるものではありません。各工程ごとに、各工程の安定期に入るまで、都度噴出します。特に上流工程は、色々と決めごとの多いターンですので、決めごとが「決定」と言うステータスになるまでの間、様々な問題／課題に襲われます。
そんな時、たった１つの取りこぼしでもあると、後々「管理が杜撰だった」と言われることになりかねません。また、問題の原因分析や対策内容などについても、不適切であった場合に、いったいどういう対策をしたのか確認しなくてはならないことがあります。こうした時に、記録管理されていないと、「いったい、何を管理していたんだ？」と言われ、周囲の蔑視はマネージャーに集中することになります。
そうした状況を起こさないようにするためには、常に『情報』を統治管理する必要があるのです。Information Techologyを取り扱うプロであれば、この程度の『Information（情報）』を管理することなんて雑作もないはずです。
それに、こうして問題の一つひとつ、その対策の一つひとつを記録化…ひいてはデータ化しておくと、今後同じような問題にぶつかったプロジェクトが現れたとしても、解決で悩む必要が無くなるかも知れません。
「失敗の経験こそが一番人を成長させる」
のは、何も自分自身に限った話ではありません。その失敗の経験情報を共有できれば、組織としても成長することは可能なのです。
問題解決管理の目的
「問題解決管理」と言う特殊なマネジメントの目的は、簡単に言えば
問題が識別され、分析され、管理され、
解決まで制御されることを確実にすること
です。一意に識別されれば、「参照」あるいは「引用」する際に、決して間違えることがありませんよね。分析されて、問題までの経緯や、問題の原因そのものが判明していれば、今後のアクションの「見直し」につながります。情報として適切に管理されていれば、起きた問題そのものの取りこぼしが無く、そのステータスが把握できているため、必ず解決まで導くことが可能になります。
この「識別」「分析」「管理」のうち、どれか１つでも疎かになっていると、問題は正しく解決されない可能性、あるいは問題の再発防止に貢献できない可能性が出てきます。
たとえば、あるたった１つの問題で１億円の損害が出たとしましょう。
でも、当事者は自分の責任でそんな問題が起きたと言う事実をできれば早々に無かったことにしてしまいたいので、「きちんと解決したけど、記録からは抹消した」とします。
たしかに目の前の問題そのものは解決できたかもしれません。ですが、その情報は適切に管理されていないがために、来年も、再来年も、続々と同じような失敗を引き起こす企業のままで、いつまで経っても組織的な成長ができない可能性があります。
もし、みなさんが上司であったり、社長であったりしたらどうですか？
毎年毎年、似たようなことが原因でプロジェクトごとに１億ずつ損失を出し続ける組織のままで良しとしていたいですか？
問題解決管理に求められる成果
問題解決管理では、次の事項を確実にする、または確実にできる手順を構築することにあります。ただ解決すればいいわけではありません。ただ記録に書けばいいと言うわけでもありません。あくまでも『目的』を果たすために管理するのだと言うことを忘れないようにしましょう。
1) 問題解決管理戦略が策定されている。
2) 問題が記録され、一意に識別され、分類されている。
3) 問題が適切な解決策を識別するために分析され、評価されている。
4) 問題解決に着手されている。
5) 問題が終結まで追跡されている。
6) 問題のステータスおよび問題の傾向が把握されている。
難しく書いていますけど、言いたいことは至ってシンプルです。
1) 問題解決管理戦略が策定されている。
実際に行動を開始する前に、「具体的にどうするのか決めておきましょう」「決めた通りにできるように準備をしておきましょう」「予想外のことが起きても対応できるようにしておきましょう」と言っているだけです。
2) 問題が記録され、一意に識別され、分類されている。
「問題が起きたら、まずは記録しましょう」「一つひとつの問題が識別できるようにしましょう（間違って取り扱うことが無いようにしましょう）」と言っているだけです。
3) 問題が適切な解決策を識別するために分析され、評価されている。
「間違った対策を取らなくてもいいようにしましょう」「問題の原因は、必ず特定しましょう」「問題原因が、正しく特定できているか、思い込みにならないようにしましょう」と言っているだけですね。
4) 問題解決に着手されている。
「分析のままで終わらず、『どう対策するのか』『どう再発防止に役立てるのか』に紐づけましょう」と言っているだけです。
5) 問題が終結まで追跡されている。
「状況（ステータス）管理がなされていて、未対策のままにならないようにしましょう」と言っているだけです。
6) 問題のステータスおよび問題の傾向が把握されている。
よく見落としがちなのですが、問題解決管理は「問題そのものの管理」でもあり、また「問題データの傾向管理」でもあります。
たとえば、『作りこんだエンジニア』と言う軸で傾向分析した場合、ある人物に問題が集中している場合があったりします。またさらに、問題原因の傾向まで分析してみれば、「ウッカリミスが多い」とか「途中の高低から引き継いだために過去経緯の情報が不足している」とか理由が見えてきます。
そうした分析から、次のプロジェクトに活かしていくべきポイントが見えてくるのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。