ちょっとだけ、失敗しないプロジェクトに近づくための3つのヒント：デジタルワークスタイルの視点

プロジェクトマネジメントを考える上で、Apple、はてな、Googleという3つの企業の事例を紹介しましたが特殊事例だったかもしれません。今回は、もっと身近な事例を考えてみましょう。

[徳力基彦，ITmedia]

　前回、失敗しないプロジェクトマネジメントを考える上で、Apple、はてな、Googleという3つの企業の事例を考えてみました。はてなブックマークでも、多くの方からコメントを頂きましたが、やはり「そうは言ってもね」というのが正直な反応だと思います。

　そこで今回は、プロジェクト管理の「負のスパイラル」を脱出するために、もう少し身近な事例を参考にしてみたいと思います。

ちょっとだけ、失敗しないプロジェクトに近づくための3つのヒント

• 短期ではなく、長期で考える
• 遅い人ではなく、早い人に注目する
• 大きく始めず、小さく始める

短期ではなく、長期で考える

　通常のプロジェクトでは、前回紹介したAppleのように「締め切りを事前に約束しない」というわけにはいかないかもしれません。ですが、締め切りを「死守すべき締め切り」から、ある程度「緩い締め切り」にさせる方法が1つあります。

　それがプロジェクトを長期で考えるということです。

　この例で参考になるのがソフトウェアの例でしょう。これまでのソフトウェアはパッケージ販売が基本でした。WindowsのようなOSに見られるように、パッケージを購入した後、最新バージョンが出たら新しいバージョンを購入します。このモデルでは、パッケージの発売時に売り上げが最大になりますが、その水準の売り上げを発売以降も維持するのは難しくなります。

　企業は利用者に継続してお金を払ってもらうためには当然、定期的に新しいバージョンを開発する必要があります。従って、次期バージョンのリリースタイミングというのが経営的にも非常に重要な課題――つまり、このタイミングが「死守すべき締め切り」になりやすくなるわけです。

　ですが、サブスクリプション（加入者）モデルのソフトウェアやASPサービスでは、大きく考え方が変わってきます。

　顧客は、ソフトウェア企業とその年間のサービスを契約しており、契約が長期に渡るほど企業にとってはメリットがあることになります。もちろん顧客はそのサービスが日々進化することを期待していますが、期待以上の進化をしていれば、顧客はそのまま契約を継続してくれるでしょう。そうすればサービスをバージョンアップするタイミングは、ある程度余裕を持つことができるようになるのです。

　あなたのプロジェクトも、これと同じ発想の転換ができないでしょうか。システムやWebサイトだけを単体として受託するのではなく、構築後のメンテナンスや運用も合わせて受注することで、納品後の微修正を前提とした開発ができるかもしれません。

　現在のプロジェクトは短期かもしれませんが、事業や企業はそのプロジェクトが終わっても続きます。短期の成果だけを目指すのではなく、長期の成果を重視することで、単純な締め切りに一喜一憂しないプロジェクト運営を行うことも可能なはずです。

遅い人ではなく、早い人に注目する

　一般の企業で前回紹介したような、はてなの「あしか」のようなタスク管理をいきなり導入するのは難しいかもしれません。ですが、コンセプトとして真似できる点があるはずです。

　特に意識して欲しいのは、やる気のある人の能力を最大限活用するという点です。通常のプロジェクト管理では、作業が遅れている人に焦点が当てられます。事前に作業がメンバーに割り振られているわけで、誰かが遅れればチーム全体でフォローしようとします。遅れている人をいかに挽回させるかということにフォーカスするわけです。

　ただ、土木建築などの物理的な作業と異なり、ホワイトカラーやエンジニアの知的労働では、できる人とできない人の生産性というのは極端に差が開くケースが往々にしてあります。そんな作業効率の差がある中で、遅い人にいくら遅れを取り戻そうとがんばってもらっても、実はプロジェクト全体への貢献度は低い場合が多いのです。

　そこで、作業が遅い人の遅れを気にするよりも、作業が早い人が可能な限り多くの仕事をやれるような仕組みを意識してみてください。もちろん作業の早い人が、やっただけ損にならないような仕組みを作ってあげることが最重要になります。

　残業代のように、単純に長い時間仕事をしている人が多くの給料をもらえる仕組みだと、要領の悪い人が結果的に低い生産性で多く給料をもらうことになってしまいますから、作業の早い人が作業の遅い人を助けるようにはならないでしょう。

　遅い人に注目するか、早い人に注目するか――ぜひ会社の仕組みも含めて考え直したいところです。

大きく始めず、小さく始める

　普通の企業では、前回紹介したGoogleのように複数のプロジェクトが並行して実施されることはあまりありませんから、早めに公開していけそうなものだけを選ぶというアプローチは難しいでしょう。ここで参考になるのは「小さく始める」というアプローチです。

　変化が激しいプロジェクトにおいて、最初から巨大なプロジェクトを描いていると、当然ゴールが遠くなります。その分、プロジェクトの最中に変化する要素も増えるわけです。

　そこで、巨大なプロジェクトを複数の小さなプロジェクトに分断してみてください。1つ1つの小さなプロジェクトが終わった段階で、振り返りや反省をする時間をとるようにすることで、自分たちの進んでいる方向が正しいかどうかを確認しながら進むことができるわけです。

　Googleは巨大な企業ですが、1つ1つのサービスは実はそれほど巨大なプロジェクトではありません。マイクロソフトの最新OSである「Windows Vista」のような数年がかりの巨大プロジェクトに比べると、GmailやGoogleカレンダーなどGoogleの各サービスはベンチャー企業のようなものといえそうです。

　ですが、マイクロソフトのプロダクトもGoogleの各サービスも、大事なのはリリース後です。いずれにせよ、リリースした製品やサービスを徐々に改善し、機能追加していくことで、最終的に大きなゴールを達成できるというわけです。

　この考え方は、あなたのプロジェクトでも活用できそうです。プロジェクト全体の締め切りだけを締め切りと捉えずに、短期的にいくつか締め切りを作って、短いプロジェクトの集合体にしてみてください。そうすることで、早い段階に遅れに気付けるようになりますし、方向修正も簡単になるはずです。

---

　前回の記事でも、多くの人にコメントをいただいたように、これらの考え方が合うか合わないかは、そのプロジェクトがどういった性質のものかというのに大きく依存します。しかし、いわゆる普通の「プロジェクト管理」の手法を試してみて上手くいかなかったという方は、今までの常識に捉われず、新しい切り口でプロジェクトマネジメントを試してみるのも問題解決の一助になるのではないでしょうか。

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

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