失敗しないプロジェクトマネジメント――Appleやはてな、Googleに学ぶ3つのヒント：デジタルワークスタイルの視点

プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。これらを管理しようとすればするほど悪いスパイラルに落ち込みます。Appleやはてな、Googleなど、注目企業ではどのようなマネジメントを行っているのでしょうか。

　「完璧に管理しようとすればするほど、プロジェクトは失敗する」という悪いスパイラルが存在します（2月21日の記事参照）。そこで今回は、どのようなプロジェクトマネジメントをすれば、プロジェクトを失敗させないようにできるのか考えてみたいと思います。

　プロジェクトが失敗する要因は「計画」「やる気」「変化」の3つ。前回はそれぞれを完璧に管理しようとしていましたが、今回は考え方を180度変えてみましょう。それぞれの要因を最初からなくしてしまうのです。

失敗しないプロジェクトマネジメントの3つのヒント

• 死守すべき計画を決めない
• メンバーのやる気に依存しない
• 変化することを前提にする

死守すべき計画を決めない

　計画を決めないというと極端かもしれませんが、プロジェクトが失敗とみなされる最大のパターンは、プロジェクトが締め切りまでに終わらない場合です。それなら締め切りを守るための方法は簡単。最初から厳密な締め切りをなくしてしまえばいいのです。

　「それが答えか」と思われる方もいるでしょう。極端な事例でいえば、新製品を発表するタイミングを事前に発表せずに、製品が完成してから発表するという手法をとっている企業にAppleがあります。iPodなどの一部新製品では、発表当日から購入できるほど準備を整えています。プロジェクト管理だけでなく、プロモーションやユーザー満足度からも参考になる事例です。

　もちろん、社内的にはカンファレンスや記者発表会の日程調整などがありますから、締め切り日時は当然決まっているはず。ですが、少なくとも外部に締め切りを公開しない限り、その締め切りを守るために、間に合いそうに無いプロジェクトを無理矢理間に合わせる必要はなくなります。実際、珍しく発表日に製品がなかった「Apple TV」は、2月発売と発表したのがあっさりと3月半ばに延期されました（2月27日の記事参照）。

3月半ばに発売が延期された「Apple TV」

　顧客とのプロジェクトを実施する際も同じです。当然、法的な理由等、環境的な要因から、死守しなければいけない締め切りというのもあるでしょうが、多くの締め切りは事前の約束から発生するものです。約束を守ることは重要なことですが、その約束だけを死守するために、プロジェクトの成果物の品質が悪くなっては意味がありません。

　どうせ、最初から完璧な計画をたてられないのであれば、「締め切り＝目標」として設定しておき、目処が見えるギリギリまで確約しないという手もあるわけです。

メンバーのやる気に依存しない

　プロジェクトの開始時に個別のメンバーに細かくタスクを割り振ると、結局メンバーの能力ややる気によって、早く進む人、作業が遅れる人のばらつきが生まれます。それなら最初から、細かくメンバーにタスクをアサインしない方法はどうでしょう。

　「そんな無茶な」と思う人もいるかもしれませんが、この代表例といえるタスク管理を実践している有名な事例が、はてなの「あしか」です（2005年7月の記事参照）。

　あしかでは、「すぐやる」「そのうちやる」「ペンディング」「終わった」という4つの段ボール箱に、やるべきことを書いた紙を放り込んであり、作業をやる人が紙を取っていく形になります。ちなみに、現在はデジタル化されたそうです（2006年5月の記事参照）。

「はてな進行管理」の略で「はしか」。はしかだと語呂が悪いから、「あしか」にしたという（2005年7月当時の写真）

　つまり、誰かがその紙を持っていくまで、その仕事は誰の仕事でもないわけです。メンバーは1つずつ仕事を処理し、終わったら次の仕事に取り掛かります。GTDのリストを、プロジェクトメンバー全員で取り組むイメージですね。

　どちらにしろ、ぞれぞれのメンバーは1つずつタスクをこなしていくことしかできません。何もプロジェクトの最初に、全部のタスクを個別のメンバーに割り振っておかなくても、結果的に全員で総てのタスクを処理できればいいわけです。

　もちろん、仕事をたくさんした人がしただけ損になってしまわないように、適切な評価の仕組みは必須。ですが、もし、今日は仕事をやる気にならないメンバーがいたとしても、他に能力が高いメンバーや、ちょうどやる気がのっているメンバーがカバーできる仕組みがあれば、“あしか的プロジェクト管理”も可能なはずです。

変化することを前提にする

　変化が激しいプロジェクトにおいては、変化することを前提にするというのも重要です。もちろん、最初の予定は重要ですが、早い段階であえて変化させるためのポイントを作ってしまうのです。

　このケースで参考になるのはオンラインサービスのラボやベータ公開の手法でしょう。　例えばGoogleの場合、開発したサービスがいったん完成した段階で、早めにユーザーのフィードバックを得るためにGoogle Labsに公開するという手法を取っています。

Google Labs

　Google Labsを見ると、正式なサービスとして卒業したサービスも多い一方で、かなり昔に公開されたのに相変わらずラボ扱いのサービスも多くあるのに気づくと思います。通常のソフトウェア企業では、ベータ公開というのはそれを製品化する前提での位置づけになりますが、Googleの場合はそのサービスを製品化するかどうかは、フィードバックを元に決めているわけです。しかも、Googleでは一度立ち上げたサービスを終了することもあります（2006年11月の記事参照）。

　極端な事例だと思われるかもしれませんが、同じことは通常のプロジェクトでも適用可能です。締め切りを過ぎてから成果物を出すのではなく、プロジェクト開始後にできるだけ早く「成果物のイメージ」を見せていけばいいのです。

　もちろん、成果物のイメージを伝えることで、プロジェクトの途中で仕様変更があったら困るという思いはあるでしょう。しかし、顧客の思いとかけ離れた成果物を締め切り日に出して、二度と仕事がもらえなくなる方がより深刻です。そもそも、プロジェクトの開始時にすべてを見通すことなど不可能。変化を恐れるよりは、自分から積極的に変化させていく姿勢でプロジェクトに取り組んだ方が、顧客からの発注から始まったプロジェクトでも主導権を握れるのではないでしょうか。

　ここにあげた事例は、どれも極端な事例に見えるかもしれません。ですが、実は変化が激しいプロジェクトの根本的な課題に、発想を転換して取り組んだ事例だともいえます。

　変化が激しいプロジェクトにおいて、固定的なプロジェクト管理手法は必ずしも効果的とはいえません。いっそ、固定的なプロジェクト管理の考え方は全部忘れてください。今までのプロジェクト管理の常識を一度ゼロにして、本当に必要なことをゼロから考えると、意外なところにプロジェクトの失敗のスパイラルから脱出するヒントがあるはずです。

筆者プロフィール　徳力基彦（とくりき・もとひこ）

NTT、ITコンサルを経て、現在はアリエル・ネットワーク株式会社プロダクト・マネジメント室マネージャ。ビジネスパーソンの生産性向上のためのソフトウェアの企画・開発やコンサルティング業務に従事するほか、グループウェアやブログ、仕事術などに関する執筆・講演活動を行っている。ブログは「ワークスタイル・メモ」と「tokuriki.com」