現場を疲弊から解き放つ業務改革・システム導入におけるチェンジマネジメント方法論（実践編）Initiative Vol.26 |
page | 1 | 2 |
前回のコラムで触れたが、最近では変革疲れに陥って、活動エネルギーが枯渇している社内プロジェクトをよく目にする。前回の方法論紹介に引き続き、今回は皆さんがすぐにでも採り入れることができる簡便な工夫・アイデアを中心にご紹介したい。
プロジェクトチーム内の不和や不毛な議論の繰り返しといった内なる問題が疲弊感に拍車を掛けている
いきなりだが皆さんが疲弊感を感じる瞬間はどのような状況であろうか？業務量オーバーで参ってしまう状況が最初に思い浮かぶが、この場合はスケジュールや役割分担の再設定といったプロジェクトマネジメントの梃入れを考えてほしい。但し、プロジェクトマネジメント部分だけを改善すれば万事上手くいくかというとそんな単純な話ではない。
意外にもコンサルティング現場の臨床例でいうとプロジェクトマネジメントのタスク範疇には収まらない些細なことの積み重ね、つまりプロジェクトチーム内部のゴタゴタへのリカバリー対応や時間を掛けているのに一向に成果が見えてこないワークショップを延々と繰り返すといったことで疲弊してしまうことが多い。
元来、業務改革やシステム導入はプロジェクト期間が長く、一般的には2～3年は掛かることが多い。スポーツの世界でいえばマラソンのようなものであり、長期のペース配分や勝負どころを冷静に見極めることが大切である。それゆえ、行き当たりばったりのダッシュや無駄にコースを遠回りしてしまうような非効率なプロジェクトアプローチは極力避けるべきである。マラソンが自分との戦いといわれるように、実は長期プロジェクトを成功に導けるかどうかの鍵は内なる問題、つまり自分達の身近にあることが多いのだ。
チームの内部崩壊を防ぐために、プロジェクトの定期健診を実施し、メンバーの最新動向をつかむ
皆さんの職場でも体調不良や燃え尽き症候群でプロジェクトマネジャーや主力スタッフが突然の離脱（または離脱希望）で混乱に陥ったり、一枚岩になるべきはずのプロジェクトチーム内部がコミュニケーション不全に陥って、反目しあう緊張関係になっているという経験は無いだろうか？ これは典型的なプロジェクト失敗パターンで、自分達の足元から崩れるパターンである。
変革プロジェクトに関わらず、日常の業務トラブルや病気にも当てはまる話だが、事前の予防・ケアをする労力よりも問題が起こってからリカバリーに要する労力の方がはるかに大きいはず。そんな当たり前のことはわかっているにも関わらず、プロジェクトスポンサー（多くは経営陣）やプロジェクトマネジャーにとって、自分の身近なプロジェクトメンバーの動向に気を配ることはほとんどない。これが危ない。遠くにあるプロジェクトのゴールばかりを見つめていると足元をすくわれてしまうのである。
それを防ぐために工夫として、ぜひ取り入れたいのはプロジェクトの節目（例えばフェーズ単位）での定期健診のような仕掛けである。大規模なプロジェクトであれば、プロジェクトメンバー限定のアンケートを実施するのが効果的だ。当たり前のようなことだが意外にも仕組みとして採り入れているケースは少ない。
利害関係者やエンドユーザー相手にチェンジレディネス（変革の受容度・準備度）を測定する調査のような凝った仕掛けにする必要は全くない。単純にプロジェクトメンバーが今後の見通しをどう認識しているのか、何が懸念点なのか、改善提案はあるかということを素直に引き出せるシンプルな設問設計・少ない質問数で十分である。本音を伝えやすいように匿名方式で実施することも効果的だ。小規模のプロジェクトであれば対面インタビューで代替しても問題はない。
このような取り組み自体に懐疑的な人もいるだろう。例えば「そんなことをやらないでも私は全部わかっているよ（達観タイプ）」、「何かわかったからといって、新たに出来ることはない、それならば聞かない方がいい（諦めタイプ）」、「そんなことにプロジェクト活動の労力を割きたくない（タスク集中タイプ）」が挙げられる。
しかし、その取り組みの簡便さ・少ない労力に対して、得られる効果の大きさをここでは強調したい。このような仕掛けを行うことで思わぬプロジェクト推進上の火種（水面下で進行していた遅延リスク要因の発覚やメンバー同士の不仲等）を早期に発見できる。もし不安材料が出てこなかったとしてもフェーズ毎の時点比較で全体傾向・推移がわかることで今後の先読み材料が得られるし、長期間にわたるプロジェクト関与でマンネリを感じるメンバーにとっては日頃の愚痴・不満を吐露するガス抜きの機会にもなる。
対応が後手に回って、崩れかけたチーム体制を立て直す労力を考えたら、このような先を見据えた取り組みに労力を割いておくことがコストパフォーマンスとしても悪くないことは明らかだ。
チームの内部崩壊を防ぐための転ばぬ先の杖として、簡単かつ即効性のあるこの仕掛けをプロジェクトタスクの一項目として新たに組み込んでみてはいかがであろうか？
（次ページへ続く）
page | 1 | 2 |