【問題解決管理】戦略を策定しよう

・問題解決活動
・問題のステータスモデル
・警告の通知
・これらの活動を実施するための責任
・緊急解決戦略

と言った、「これから問題の解決までの流れを管理するための取組み」について、チームメンバーに周知を行うため、"あらかじめ決めておくべき事項"について戦略を策定します。これらを事前に決めておかないと、メンバーはいざ問題が発生した時に、適切な判断や行動を起こすことができません。

そして、こうした管理によって影響を受ける関係者（つまり、メンバーや時にはお客さまを含む）との窓口を定義しておき、その定義内容を推進・維持していくのです。

ここで大事なのは「形骸化」させない仕組みでなくてはならない…ということです。決めることが大事なのではなく、決めたことを関係者全員が遵守していくことが大事なのです。「決めろと言われたから仕方なく決めるマネージャー」「決めたことを守ろうとしないメンバー」「我関せずのユーザー」そしてそういった人たちがいても、「誰も何も感じない組織」と言うのでは、問題解決管理は決してできません。

ステータスモデル

ステータス…すなわち、問題が発生して解決するまでの間、継続的に管理すべき『状態』の遷移を定義します。一般的には、

こんなイメージでしょうか。

「問題」と認識するような事象が発生し、記録化した際に『発生』と言うステータスになります。ここから、管理開始です。この時点では、記録者が問題だと思っただけなので、詳細に分析してみると「実は問題ではなかった」と言うこともあるかも知れません。ですが、そうした経緯も全て記録化しておくのです。そうすることで、今後同じような事象が起きても、記録を参考にすることで無駄に慌てる必要が無くなるからです。

「問題」が記録化されると、必ずその内容を確認し、原因の特定や問題そのものの影響範囲を特定するため調査・分析を行います。この開始と同時に『調査（中）』と言うステータスになります。もしも、問題であると確認できた場合は、その問題を解決しなければなりませんので、

　・既存成果物に対して変更を加える場合は『変更依頼』
　・未提出の成果物に対して修正を加える場合は『対策』

とします。もしも、問題ではない（つまり、対策不要）と確認できた場合は『終結』と言うステータスになります。ステートマシン…状態遷移図にするとこんな感じでしょうか。

周知／展開

発生した問題は、その重要度または影響度合いに従って、報告または警告の周知を行います。記録は誰にでも解放されていていいモノですが、日々の問題解決管理に必要な周知や情報展開は、その問題に対して、影響を受ける人や関係者に絞っておいた方が良いでしょう。

なぜなら、情報過多になってしまうと、人は判断するための基準が増えすぎてパフォーマンスを落としてしまうからです。

一般的に、影響度別で見た場合は

このような影響度によって、「大」「中」「小」と分類してみると良いでしょう。これ以上細かく分けても、管理が煩雑になってしまうだけなのであまりオススメできませんが、明確な切り分けができるなら、５段階くらいｍでなら許容できると思います。

そのうえで、重要度別に次のような周知／展開をおこなう…と言ったルールにしておくのが望ましいのではないでしょうか。

特に重要度：大となった問題は、影響範囲が大きく、緊急性が高い可能性が容易に想像できます。即時に周知を行うのはもちろん、確実に伝わることが喫緊であるはずです。

よくあるのが、「メールで展開しました」「電話で伝えました」と言うだけで、コミュニケーションが成立していると思っているケースです。メールでは、受信者がいつ読むのかわかりませんし、きちんと読んでくれたかどうかもわかりません。読み手依存のコミュニケーション方法となってしまいます。電話や口頭のみの連絡では、記録に残らないため、即時性に長けてはいても、認識齟齬を払しょくできているかどうかが判断できません。

重要な話題は「即時性」と「追跡可能性」の２点は必達条件です。

責任

問題の発生直後に報告を受け、解決するまでの活動について、問題解決管理責任者を設けておくと良いでしょう。リーダーやマネージャーが兼任することが多いと思いますが、おそらくは上手く回りません。予算や人的リソースに余裕があるなら、本当なら先任者を置くのが理想です。

仮に、先任者を設けることが難しい場合は、リーダーやマネージャーが兼任するのでしょうが、その場合は、しっかり管理できる時間を確保するようにしてください。

リーダーは１人分の開発を担いながら、メンバーの技術的、あるいは仕様的なサポートをしつつ、それでいて問題解決管理も実施する…なんてのは到底無理です。できたとしても、100%残業確定コースです。マネージャーにしても、コストやスケジュールの管理をしつつ、お客さまとの打ち合わせに頻繁につかまっていて、日中は現場にいない…というのであれば、問題解決管理をしている暇を作るのも難しいでしょう。

このように、「日中作業を何一つ調整しないのに、追加で仕事を増やす」をしてしまうことが、形骸化へ最短の近道になっていくのです。

先任者を設ける際には、日中の通常業務を50～70%程度にしておくと良いでしょう。理想は50%です（70%だと、自分の担当分で問題が起きた時の対応で、あっという間に100%を超えそうだから）。

プロジェクトマネージャーやチームリーダーは、時として先任者の活動を支援し、速やかに問題が解決するようマネジメントに関する調整およびコントロールを実施してあげる立場についていることが理想となっていくでしょう。

体制と活動

問題解決にあたっては、先述の通り『問題解決管理責任者』を設置し、スムーズな問題解決までの管理手順を遂行できるようにしましょう。問題解決管理責任者は、業務が滞らない限り、他の業務と兼任でもかまいません。もちろん複数人設置し「チーム」とすることによって、負荷分散等、フォローしあっても良いと思います。ただし、複数人設置する場合は、有機的に負荷分散できるように、一人ひとりが問題解決管理の業務を理解していないと、"ただ名前がそこにあるだけ"と言う状態になりかねませんので、注意してください。

問題が発生してから、終結するまでの概要は次の通りとなります（詳細は、いずれ書きますけども）。

こうした流れを、開発の前にあらかじめ決めておき、メンバー一人ひとりの役割を決め、いざという時に動けるようにしておくのが「戦略」であり、その戦略を記したものが「計画」です。

いざという時になって、「何をしていいかわからない」「するべきことができていない」となると、発生した問題はより大きな問題へと派生していきます。そうなってから、後手後手に回って対策していては、いつまで経ってもプロジェクトトラブルを防ぐことはできません。

「戦略」とは「戦」を「略」すと書きます。

余計な戦火に巻き込まれないようにあらかじめ手段を講じておくことが肝要なのです。