お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

スコープの変更をメンバーに納得させるには?

2003/06/09 10:00
  • このエントリーをはてなブックマークに追加

ガイドの視点

 開発に入ってからのスコープや仕様の変更は、何かと厄介なものである。今回のテーマは、実際にスコープの変更が発生したとき、どのようにチームを納得させてプロジェクトを進行させるか、ということである。

 スコープ管理については、「突然プロジェクトを頓挫させてしまうものは?」で既に述べられている。ここで重要だったのは、スコープの変更は悪ではないということだ。現実的なシステムを構築するときには、スコープ変更は起きうるものである。役に立たないシステムを構築してもしかたないのだから、スコープ変更は起きうるものとして皆が納得できるような手順をあらかじめ決めておくべきであるということだった。

 しかし、スコープ変更プロセスが決まっていたとしても、プロジェクトチームのメンバーにとってみれば、今までの努力が水泡に帰すかのように感じられることもある。長期間のヒアリングやミーティングで決定した仕様に合わせて、最適に正規化されたDB設計や、練りに練ったユーザーインターフェースを再考しなくてはならない。きれいにコーディングされたプログラムも、例外処理だらけになる。「もうちょっとだったのに、今までの努力と時間は何だったのだ?」とチームの士気が下がるのは、無理もないことだろう。特に、設計やプログラミングを数学的アートと捉えているスキルの高い技術者なら、自分の「作品」を壊されるかのような気持ちになるかもしれない。

 こうしたとき、プロジェクトチームのメンバーのやる気を引き出すことが、プロジェクトマネージャーの腕の見せ所である。ここでは次のような方法が述べられているが、変なテクニックではなく、本当に人間的なことばかりである。

  • まずは事実を説明する
  • 痛みを認める
  • やる気をひきだす
  • 1人ひとりと話す
  • 上層部やスポンサーを巻き込む
  • 「心づけ」を用意する
  • クライアントと苦労を分かち合う
  • メンバーと積極的にコミュニケーションをとる
  • 成功を祝う

 読んでみれば、どれもが良好な対人関係を作るための基本のようなことばかりである。しかし、私たちは、本当にこのような真摯な態度をきちんと取っているだろうか? 「悪いけど決まったことだからがんばってくれ」くらいでは、本当に納得させることなどできない。

 裏表なく事実をきちんと説明し、痛みを共有し、心機一転して新たな目標に向かって再スタートを図る。そのためには、心の通うコミュニケーションが一番大切である。

監訳者(木村)
このコーナーでは米国TechRepublicから日本企業のITマネジメントに役立つ情報を日本人ガイドが厳選してご紹介しています。

 「この世で確実なものは死と税金だけ」というが、変化もまた、避けることのできないもののひとつだろう。細心の注意をはらってプロジェクトを定義し、ビジネス要件をとりまとめても、プロジェクトがはじまってしまえば変更を迫られるときがくる。問題を抱えているプロジェクトの場合は、メンバーが変更に二の足を踏むことも少なくない。プロジェクトを成功させるためには、プロジェクトマネージャーがリーダーシップを発揮し、メンバーに変更を納得させる必要がある。

変更が必要になる理由

 一般に、プロジェクトに変更が求められる原因は2つある。ひとつは、クライアントがプロジェクトチームの思っているほどプロジェクトの詳細やニュアンスを理解していない場合。しかし、これはあたりまえでもある。クライアントならプロジェクトのすべてを把握しているはず、と考えるのは期待のしすぎというものだ。そもそもプロジェクトがはじまる前にすべての要件を定義できるわけではないし、プロジェクトがある程度進んでから見えてくるものもある。

 仕様変更のもう1つの原因は、環境の変化だ。クライアントのビジネスも、それをとりまく業界や世界も常に変化している。スタート時の仕様書がいくら完璧だったとしても、ビジネスが変化すればチームに求めるものも変わってくるだろう。プロジェクトが終結するまで、世界が息をとめているわけではない。

 プロジェクトを成功させるためには、プロジェクトマネージャーとチームが変更をすみやかに察知し、しかるべきプロセスにのっとって、その変更がプロジェクトのコストやスケジュールに与える影響を算定することが必要だ。そうすれば、スポンサーはスコープの変更にふみきるべきかどうかを判断することができる。

 変更そのものは善でも悪でもない。しかし、そのときにプロジェクトがどのような状態にあるかによって、プロジェクトチームの反応は前向きなものにも後ろ向きなものにもなる。変更が発生した場合、たいていのプロジェクトチームは「それがスポンサーの意向なら従うしかない」と考える。これが一般的な反応だ。

変更=悪と受け取られることもある

 しかし、チームが厄介な反応をみせることもある。たとえば、メンバーがもう変更はたくさんだと思っている場合。すでに多くの問題を抱えているプロジェクトではこうしたことが起こりやすい。理由はさまざまだが、次のような状況が考えられるだろう。

  • 長いプロジェクトで、残業も多く、だれもが早くプロジェクトを終わらせたいと考えている。
  • 膨大な作業が発生するにも関わらず、クライアントが納期の延長を認めない。変更を受け入れれば、残業が増えるかもしれない。
  • チームとクライアントの関係がぎくしゃくしている。クライアントに協力的でないメンバーや、プロジェクトを早く終わらせたいと考えているメンバーがいる。
  • 変更を実現するためには、ソリューションを根本から考え直さなければならない。設計を見直し、最初からテストをやり直す必要がある。

 どのケースでも、プロジェクトチームはスコープの変更に応じる気にならないだろう。こうなると、プロジェクトマネージャーは厳しい立場に立たされる。本音をいえば、マネージャー自身もプロジェクトを終わらせたいと思っているかもしれないが、立場上不平をいうわけにもいかない(不平をいうなら相手は自分の上司かプロジェクトのスポンサーにすること。チームのメンバーに泣き言をいうのは反則だ)。プロジェクトマネージャーとしては、メンバーを説得し、プロジェクトを前に進める方法を考える必要がある。

スコープの変更をメンバーに納得してもらうには?

 正直にいって、これは難しい任務だ。メンバーは疲れはて、やる気を失っているかもしれない。チームの士気そのものが低い場合もある。しかし、このようなときこそプロジェクトマネージャーはリーダーシップを発揮するべきだ。計画通りのソリューションではクライアントの問題を解決できないなら、メンバーを鼓舞してでも必要な変更を取り入れる必要がある。うまくいっていないプロジェクトでは問題が複雑化していることが多いので、メンバーを説得するときも多面的なアプローチをとるとよい。ヒントをいくつか紹介しよう。

  • まずは事実を説明する
いきなりチアリーダーの物まねをしても効果はない。まずはチームを集め、問題の背景と現状を説明すること。必要な変更点をざっとなぞった上で、なぜそれが重要なのかをビジネスの視点から説明する。現在の問題点と今後の課題を、チームのメンバーが同じように理解していることが重要だ。
  • 痛みを認める
私も過去にプロジェクトマネージャーからプロジェクトの変更を告げられたことがある。マネージャーは事情を説明し、それぞれのメンバーに作業を指示したが、私はいつもなにかが欠けていると感じていた。プロジェクトマネージャーはチームが問題に直面していること――メンバーが変更に後ろ向きで、チームの士気が下がっていること――を認めるべきだ。お茶をにごしている場合ではない。
  • やる気をひきだす
そろそろ動機づけにとりかかろう。まずはメンバーのチーム意識にうったえてみる。チームが一丸とならなければ、スコープの変更という難局を切り抜けることはできない。また、このプロジェクトがどれほど会社の役に立つかを説明することも重要だ。
  • 1人ひとりと話す
チームの会議とは別にメンバーと個別に話をする機会を設け、メンバーの精神状態を理解するようにつとめる。メンバーの懸念に耳を傾け、1人ひとりからプロジェクトへの忠誠と、前に進む決意をひきだすこと。
  • 上層部やスポンサーを巻き込む
上司やスポンサーに頼んでチームに話をしてもらうのも効果的だ。チームのこれまでの仕事に感謝し、プロジェクトを成功させるためにはメンバーの協力が不可欠であると伝えてもらう。
  • 「心づけ」を用意する
ちょっとした心遣いがメンバーのやる気を維持し、士気の低下を防いでくれる。朝食代わりにドーナツを配ったり、残業中のメンバーにピザを差し入れたりするだけでも十分だ。
  • クライアントと苦労を分かち合う
プロジェクトチームが残業を強いられているときは、クライアントも遅くまで働いているものだが、残念ながらそうでないケースもある。チームとクライアントの距離に目を配ることもプロジェクトマネージャーのつとめだ。
  • メンバーと積極的にコミュニケーションをとる
プロジェクトがどんな状態にあるのか、あとどのくらいの時間と作業が必要なのかをこまめにメンバーに伝える。プロジェクトマネージャーがドアを閉め、秘密主義を採用するようになれば、チームの士気はますます低下するだろう。
  • 成功を祝う
プロジェクトが完了するまで成功を口にしてはならないという法はない。プロジェクトの節目節目で成功を祝い、メンバーの苦労をねぎらおう。

最後に

 このコラムを読んで、メンバーを甘やかしすぎだと感じた人もいるだろう。給料をもらっている分際で文句をいうなというわけだ。

 たしかに、それも1つの考え方だが、今回想定したのはすでに問題を抱えているプロジェクトチームである。プロジェクトマネージャーが「だまって働け」という態度をとれば、メンバーは仕事から手を抜き、テストもそこそこに、最小限の労力でプロジェクトを終わらせることばかりを考えるようになるかもしれない。長い目でみれば燃え尽き症候群にかかる者が増え、今後のプロジェクトの生産性にも悪影響がでるだろう。離職率も高まるかもしれない。これでは泣き面に蜂である。

 「仕事をしろ」と言うだけならだれでもできる。プロジェクトマネージャーなら、もっと別の管理・リーダーシップツールを持っているはずだ。すぐれた人事管理スキルなくして、スコープの変更という難しい局面を乗り切ることはできない。この世に成功が約束されたプロジェクトなどない。しかし、今回紹介したようなヒントを取り入れることができれば、途中でスコープの変更を余儀なくされた場合も、プロジェクトを頓挫させることなく、成功に1歩近づくことができるはずだ。

  • このエントリーをはてなブックマークに追加
個人情報保護方針
利用規約
訂正
広告について
運営会社