カスタマーオンボーディングチームの溝川 晃央です。
今回は、「失敗プロジェクトから学ぶ、プロジェクト成功の要諦」と題して、どのような要素がプロジェクトの失敗に繋がるのか、また逆を言えば失敗から何を学ぶべきかについてお話したいと思います。
まず、こちらのお題目に入る前に私の略歴を簡単にご説明させていただきますと、2007年にWEBメディアで広告営業や大手企業とのアライアンス事業の統括を行った後に、2011年頃にその当時に潮流になりかけていたプログラマティック広告のほうに軸足を移して、DSP事業のゼロからの立ち上げ（営業から機能開発、入札ロジック改善、果ては海外からDMPの輸入→Go-to-market）などを行っていました。
その後、2015年にデータ活用のほうに軸足を移し、DMPのデータ活用に軸足を移してからはや6年近く、ということで過去のアライアンス事業でのプロジェクト立ち上げなども考慮すると「プロジェクト」と名のつく業務に従事してかれこれ10数年経過しています。（プロジェクトの大小や進め方に差異はあれど、プロジェクトに参加していなかった時期がない、と言っても過言ではないと思います）
世の中には成功した事例は数多転がっていますが、失敗の事例は「恥ずかしい」という気持ちもあり、あまり表には出てきません。そこで、皆さんがプロジェクトで失敗しないように、私の過去の恥も晒しながら、プロジェクトの成功の要諦（大別して5つ）についてお話したいと思います。
1.「プロジェクト」という言葉の意味を理解していない
みなさんが当たり前のように耳にする「プロジェクト」という言葉について「厳密な意味はなんですか？」と問われると答えられない方が殆どだと思います。とある人は「計画を立てて、それを実行する」、また別の人は「多人数で集まってゴールを達成する業務」、といった感じに人によって定義はまちまちです。私もかつてはプロジェクトという言葉の持つ意味、重さについて意識することなくプロジェクトを立ち上げては失敗する、ということを繰り返してきました。
では、「プロジェクト」の正しい定義とは何なのでしょうか？
プロジェクトマネジメントの国際標準とされるPMBOKにおいて「プロジェクト」とは以下のように定義されています。PMIが制定しているPMBOK（第3版）の定義では、「プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。」とされている。つまり、会社などの通常業務や、継続的な運用管理、あるいは改善活動などは、特に開始と終了が定義されていないため、「プロジェクト」とは呼ばない。ただし、特定の期限までに特定の建築を行う、製品を開発する、システムを構築する、などは個々のプロジェクトになりうる。
ここで大事なのは、
- 独自の製品、サービス、所産を創造するために実施される = 明確な目的がある
- 有期性の業務である = 期限やマイルストンが明確に決まっている
という2点です。また、この定義では触れられていませんが「プロジェクトは将来に向けて実施される不確定要素を含んだ業務である」という点も重要なポイントです。
プロジェクトは、
- 明確な目的がある
- 明確な期限、マイルストンがある
- 不確定要素を含む
という点を理解していないと、断言しますが確実にプロジェクトは破綻します。プロジェクトを始めると「こんな予定ではなかった」とか「メンバー間で目的がずれてくる」「期限内にAという作業が完了しない」ということは頻発します。その時点で「プロジェクトはそもそも、そのような性格を持つものである。だから都度やりくりしながら進めよう」というマインドで臨めるクライアントと「こんなはずじゃなかった！ベンダーさん、どうしてくれるんだ、なんとかしろー！（怒）」となるクライアントでは、プロジェクトの成功度合いも大きく変わってきます。
ベンダー側は最後は物量勝負で人を張り付けてなんとかしますが、一方的にプレッシャーをかけられデスマーチで仕上げた成果物が当然優れているはずがありません。（そして、そのようなプレッシャーをかけられると、優秀な成果物を出すモチベーション自体も出てきません）
繰り返しますが、プロジェクトは不確定要素があり、その不確定な中でなんとかやりくりするものであり、決して当初の理想像でキレイに進められるものではありません。ということで、話が遠回りになりましたが、「プロジェクトとは思い通りにいかないものなんですよ（思い通りにいけばHappy）」という心構えでプロジェクトを進めるのが成功の要諦の1点目です。
2.プロジェクトオーナーの意思が薄弱/社内での権限が弱い
2番目の要諦は「プロジェクトオーナー」についてです。プロジェクトには必ず、プロジェクトオーナーがいます。ただ、プロジェクトオーナーが単なるお飾りであったり、裏で社長が操っていて実質「オーナー」の権限がないプロジェクトオーナーがいたりします。そのようなプロジェクトで往々にして起きがちなのが、プロジェクトオーナーの意思が薄弱（極端に言えば意思がない！）ということです。そういったプロジェクトオーナーがプロジェクトを統括すると、
- 社内の空気に敏感で直ぐに方針を変える
- 要件が定まらない
- 要件が定まらないので、現場が混乱する
という事象が往々にして起こります。（意思が弱いのに社内の意思に対しては強く反応してしまう、というのはプロジェクトオーナー以前にそもそも人間としてどうかと思いますが・・実質、そんな人は多いわけで。）こんな時にどうするのか。綺麗事だけを言うと「そんなプロジェクトオーナーはいらない」ということになります。プロジェクトオーナーが本来すべきことは（時には社内と戦いながらも）意思決定を行い、不測の事態が発生した時には（これまた、時には社内と戦いながらも）追加予算や人員を確保することです。
前述の通り、プロジェクトというのは将来に向けて行う業務の為、不確定要素が盛りだくさんです。その中で、意思決定もできない、追加予算/人員確保などの社内ネゴもできない（ましてや、社長の腰巾着で都度意見が変わるような）プロジェクトオーナーがいるプロジェクトは確実に破綻します。
「でも、プロジェクトオーナーは変えられないんです」、というのが実態かと思います。そんな際には、本当に必要な時だけ自分の利になる決裁をして頂くに足る情報だけを与えるという「プロジェクトオーナーのお飾り化」をしていただく以外無いと思います。
但し、これはプロジェクトオーナーとプロジェクトマネージャーの（表向きでも）強固な信頼関係があって初めて成立することですので、プロジェクトマネージャーの方には（嫌かもしれませんが）プロジェクトオーナーと仲良くなるためにタバコ部屋通いやお酒の席での裏工作を都度実施いただければと思います。（私も嫌々やっていたことがありますが、案外効果てきめんです）
3.チームメンバーの役割/責任分界点が曖昧
これは非常にイメージが湧きやすいポイントかと思います。プロジェクトに限らず、社内外のメンバーと業務をする時に、「あれ、これって自分がやること？」「あの人がやることじゃないの？」ということは頻繁にあるかと思います。ただ、単発の業務の場合には、誰がやるというのを決めるだけで物事は解決するのですが、プロジェクトの場合には「Aという業務が終わってからBという業務が開始され、結果としてマイルストンCが期日までに達成される」という形で、業務間の関連性が発生し、その関連性の繋がりがマイルストンを期日内に達成できるかに大きく左右される為、役割が不明瞭のまま誰も拾わないボールがあったりすると、結果としてスケジュールに大きな影響を及ぼします。
特に、役割/責任分界点が不明瞭なケースはパートナーベンダーを巻き込んだプロジェクトの際に頻発しがちで、そこで思わぬコストの肥大化や、プロジェクトの最中に発注側とベンダー間で責任のなすりつけ合いというのが起きがちです。そういった点で、プロジェクト開始時には、普段の業務よりも相当明確に、かつ言語化された形でチームメンバーの役割/責任分界点を明瞭にしておきましょう。
4.プロジェクトマネジメントができていない
今更、当たり前のことを書くな、と怒られるかもしれませんが、意外とプロジェクト “マネジメント”ができていないケースが多く見受けられます。単にロードマップやマイルストン、WBS、課題管理表を準備して、じゃあプロジェクトを開始しましょう、といった形でプロジェクト管理ができた風になっている会社も非常に多いです。
しかしながら、ここで非常に大事なのは事前に「ビジネステーマを言語化すること」。言い換えると、そもそも何の為にプロジェクトをやるのかを明確にしてプロジェクトメンバーに周知徹底させたうえで、ロードマップやマイルストン、WBS、課題管理表を作成、管理することです。
とはいっても、「みんな何の為にプロジェクトやるかぐらい分かってるでしょ」、と思われがちですが、当初はメンバー全員が目的を分かっていても実際に各メンバーにタスクを割り振ると、WBSの一端しか見ずにプロジェクトタスクを遂行することも非常に多くなってきます。そうすると、途中で部署間で解釈の多様性が出てきて、部署Aは「売上向上の為だと思ってた」、に対して部署Bは「コスト削減の為だと思ってた」と解釈がブレがちになります。
実際に私もビジネステーマを言語化して摺合せをしなかったが故に、プロジェクト中の予期せぬ要件変更時に部署間で利害関係が一致せずにプロジェクトが頓挫したケースを経験しています。そういった悲劇を起こさないためにも「そもそものビジネステーマは何なのか？」すなわち、「我々は何の為にプロジェクトをやっているのか」をプロジェクトマネージャーが切々と説いて更には明文化したうえでプロジェクトを管理するようにしましょう。
5.プロジェクト目的が網羅的すぎる
これはやや概念めいた話、かつ上述の「ビジネステーマ」と一部重複する話ですが、プロジェクトを遂行するにあたり、そのプロジェクトの遂行目的を一言で言い表せるかということです。例えば「我社のプロジェクト目的は店舗での売上単価を引き上げるとともに、販売数量を上げることである」といったビジネステーマを掲げたとします。これ自体、外の人から見たら何も違和感のない文章かと思います。然しながらプロジェクトに直接関与している人からすると非常に悩ましい問題を2つ抱えています。
- 具体的にどうやってそれを実現するのか？
- 売上単価増と販売数量増の優先順位は？
目的が網羅的すぎると戦力が分散して、結果としてどれも成功に至らないといったケースに陥ります。
上記の記載している内容は目新しいものでもなく、すべて一見当たり前のように感じてしまいます。しかしながら、私が今まで数多の失敗を繰り返してきた中で、ほぼすべての失敗が上記の5つに集約されます。皆様も一度、胸に手を当てて、現状のプロジェクトが、もしくはこれから開始するプロジェクトが同じ病気を抱えていないかを公正な目でチェックしてみてください。
