プロジェクトにおいて、最初にクライアントと「目的」や「目標」を設定・共有し、プロジェクトを遂行する流れが一般的です。
しかし、当初の計画通りに完遂するプロジェクトはかなり少ないものです。 プロジェクトの最中に、想定外の事態やトラブルを経験したことがある方も多いのではないのでしょうか。
しかしこのような大きなトラブルが生じたときには、【一度設定した目標を変更する】ことによってプロジェクトの軌道修正を図れる場合があります。本記事では、目標変更の方法やその際に気を付けるべき点について確認していきます。
目的と目標の違いとは
まず、目標変更の方法について述べる前に、「目標」の定義について確認していきます。
皆さんは、「目的」と「目標」の明確な違いをご存知でしょうか。この２つが曖昧なままプロジェクトを進めた場合、チーム内の混乱を招く恐れがあるので、しっかりと確認しておきましょう。
まず、分かりやすく「船」の例を使って目標と目的の違いを説明してみます。太平洋を進む一艘の船。この船が運行する【目的】は、遠くの島の城に到着することです。しかしこの遠くの島まの道のりは長く迷う可能性があるので、船はルート上で通過すべき小さな島々を目印にして進みます。この「目印」「指標」となる島々に到着することが【目標】にあたります。
ここから、実際のプロジェクトにおける「目的」と「目標」は、それぞれ次のように説明することができます。
- 【目的】＝ プロジェクトでどのような課題を解決したいのか
- 【目標】＝ 目的を達成するための明確な指標 、手段
例えばサイトのPV数に伸び悩んでいる場合、「サイトの認知度を上げ、PV数を向上させること」が目的、「Twitterで1000インプレッションを達成すること」が目標になります。 ただし目標を達成すれば必ずしも目的が果たされるとは限りません。目標の達成ばかりを意識して、目的が置いてけぼりにならないように、両者に気を配ることが必要とされています。
目標を変更するときの注意点
では、ここからはプロジェクトで問題が発生した際の対処法について見ていきましょう。
長期・短期問わずプロジェクトを進める際には、スケジュールの遅延や取引先の変更など、予期しないトラブルが起こることも少なくありません。このようなトラブルに見舞われた場合、まずは現状の目標を達成するのは現実的に可能であるのかを見極めましょう。そして、達成するのが厳しいと判断した場合は、迷わず目標の変更に踏み切ることをお勧めします。
「一度決めた目標を変更する」という行為に躊躇いを感じる方もいらっしゃるでしょう。しかし、上記で説明した通り、「目標」は本来「目的」の手段にすぎないということを忘れないでください。 実はプロジェクト全体を通してみると、目標を変更することが全体を最適化するきっかけになりうるのです。目標の変更を悪と決めつけずに、広い視野を持って、時と場合に応じて柔軟に対応する姿勢が大切といえます。
しかし、だからといって闇雲に目標をコロコロ変更しても良いというわけではありません。実際に目標を変更することになった場合どのようなところを注意するべきなのか、一つずつ確認していきましょう。
①変更後の目標は具体的に
新たな目標を設定する際、それが本来の目的に見合ったものかどうかを確認することは言うまでもなく必要です。このときに、プロジェクト全体で目標だけがひとり歩きしてしまうことがないように、以下のようなことを意識する必要があります。
- 目標変更の理由
- 新たな目標を達成するための手段
- 目標変更によって影響を受ける箇所やその度合い
- 新たな目標の具体的な指標値
- プロジェクト全体で評価を共有する仕組みづくり
これらの点を見誤るとプロジェクトの方向性を見失ってしまうので、チーム全体でじっくり考えるようにしましょう。
②プロジェクトチーム全体で情報を共有する
目標の解決だけに意識を集中しすぎてしまうと、進捗やプロジェクト全体の遅延の原因になりえます。 目標を変更する場合はひとつのチームに固執するのではなく、プロジェクト全体で常に情報を共有し、目標変更時には業務やシステム側を含めて何ができるか、ベストな方向性を検討することが重要です。 情報を共有することによって、さまざまなメンバーから多様な意見が集まるでしょう。
③影響が及ぶ範囲を明確化する
目標の変更を見直した結果、影響範囲が該当チームだけではなく、他のチームや外部のステークホルダーにも及ぶ場合も考えられます。 プロジェクトの規模が大きくなればなるほど、ひとりのメンバーだけでは影響度を把握しきれないものです。 一チームだけで判断するのではなく、クライアントや他チームと十分に情報連携を行った上で、影響が及ぶ範囲を明確にして目標を検討する必要があります。
④プロジェクトの体制も考慮に入れる
設定する目標は、プロジェクトの進め方やチーム体制にも左右されます。ここでは、システム開発などで利用される【ウォーターフォール型】と【アジャイル型】の２つの例を用いて、各プロジェクト体制に設定される目標の違いについて考えます。
まず、【ウォーターフォール型】とは工程の段階ごとにトップダウン式に移行していく手法のことです。これを上図のようにホールケーキ作りで例えると、ケーキ全体のサイズを想定して「レシピの確認→スポンジ→クリーム→イチゴ」の順に完成させていく方法だといえます。
原則的に前の工程が終わらなければ次に進めない「ウォーターフォール型」のプロジェクトは、当初クライアントと設定した目的や目標を変更しない、という意識で進行されることが多いです。しかし後半の工程でトラブルが生じた際に、その工程だけで対処しようとしても上手くいかないことも大いにありえまず。そのような場合、結果的にプロジェクト全体の目標を変更したほうが上手くいくことも多いのです。
一方【アジャイル開発型】は、あとで仕様や設計を変更することを前提に、短期間を1単位として必要性の高い機能から順番に成果物を作っていくという手法のことです。ホールケーキで例えるならば、小さなカットケーキを1スライスずつ作って、クライアントに味見してもらう方法に似ています。このように成果物の機能ごとに納品を繰り返していくアジャイル開発型は、より柔軟に目標を見直すことができるうえにリスクを最小に抑えられるため、近年注目されています。
このように、プロジェクトの規模やシステムの特性に応じて、ウォーターフォール型やアジャイル開発型などの開発手法を十分に検討することも目標設定に関係します。
～アジャイル・ウォーターフォール型についての関連記事～
まとめ
「目的」や「目標」を常に意識しながらプロジェクトを進めることは、大変重要です。しかしながら、「目標」とは「目的」を達成するための手段であり、目の前の「目標」にあまりに囚われすぎると本来の目的を見失ってしまう恐れがあります。 問題が発生したときなど、さまざまな局面において、目標を見直すといった柔軟な判断も重要になるのです。本記事で述べたように従来の「目的」を見失わなければ、結果的に最善のルートを導き出せるのではないのでしょうか。
