プロジェクトの成功率をあげるためには
コンテンツといっても、その種類は非常に幅広く存在します。映画やアニメ、ゲーム、音楽など、人々の娯楽を彩るものもあれば、教育、ビジネス、医療といった実務に直結する分野のコンテンツもあります。筆者はその中でも主に「Webサイトの制作」を中心に活動してきました。ですので、アニメやゲームといったエンタメ寄りのコンテンツ制作とは少し性格が異なりますが、ここでは主にWebに関わる実体験をもとにお話しすることで、同じ分野に携わる方々の参考になればと思います。
筆者はWeb業界に関わり始めてから、気がつけば25年以上が経ちました。最初はアルバイト感覚で触れたものでしたが、次第に本格的に仕事となり、今では完全に「この世界から抜け出せない」状態です。Web業界と一口にいっても、実際には多様な役割があります。デザインを担当するWebデザイナー、プログラムを組むエンジニア、サーバーを構築・運用するインフラエンジニアなど、数多くの専門家が関わります。そして大前提として、Webサイトは「作って終わり」ではなく、リリース後に継続的な運用が求められるのです。
Webの範囲は非常に広く、ECサイト（オンラインショップ）、ブラウザベースのゲーム、コーポレートサイトや採用サイト、個人ブログ、さらにはSNSのような大規模サービスまで含まれます。ソーシャルゲームも一見するとスマホアプリですが、裏側では必ずサーバーとの通信が発生し、その処理はWebの技術に大きく依存しています。つまり、想像以上に多くの「見えない部分」でWebの知識やノウハウが活用されているのです。
こうした背景の中で筆者はこれまで数多くのプロジェクトに参加してきました。守秘義務の関係上、具体的な社名やプロジェクト名を出すことはできませんが、そこでの経験から「失敗例」をいくつも積み重ねてきました。本稿ではそれらの中から代表的な事例を紹介したいと思います。
タイトルには「成功率を上げる」と書きましたが、成功談よりも失敗談をお伝えする理由はシンプルです。成功体験についてはすでに多くの書籍やノウハウ集が存在し、体系的に学ぶことができます。しかし「失敗」は現場でしか体験できないことが多く、また一度の失敗が大きなダメージにつながることもあります。だからこそ、共有する価値があると考えています。
１．メンバー間の意識共有不足
プロジェクトマネジメントに関する書籍では、必ずといっていいほど「情報共有の重要性」が説かれています。定例会議を開き、議事録をまとめ、タスク管理ツールで進捗を見える化する──こうした取り組みは当然有効です。しかし、相手は「人間」です。いくら仕組みを整えても、理解度や習慣の差によって情報が正しく共有されないことは珍しくありません。
筆者が経験したケースでは、相手の理解度を確認するために「自分の言葉で指示内容を書いてほしい」と依頼しました。しかし、毎回返ってくるのは原文の「引用」ばかり。結果として、期待していた理解には至らず、プロジェクトに支障をきたしました。本人に悪意はなくとも、「理解したつもり」になってしまうのです。
このような状況を防ぐためには、単にツールを導入するだけでなく、メンバーの性格や得意不得意を把握し、時には一対一で確認する姿勢も必要です。テレワークが普及した現代では特に、雑談レベルの会話や非公式な確認の場を意識的に設けることが重要になっています。
２．プロジェクトマネージャーが作業をしてはいけない
近年、「プレイングマネージャー」という言葉が流行しています。管理職でありながら自らも作業を行うスタイルですが、プロジェクトマネージャー（PM）の立場でこれを実行するのは非常に危険です。なぜなら、PMが作業に没頭すると、チーム全体の進捗を俯瞰する余裕が失われてしまうからです。
実際に筆者が直面した問題のひとつは「PMが忙しそうで相談できない」という状況です。メンバーは遠慮して報告を控え、気づけばトラブルが大きくなってから表面化するという悪循環に陥りました。また別の案件では、PMを任されたにもかかわらず、サイトマップや画面設計書を一人で作成させられ、週末まで会社に通って作業し続けたこともありました。結果、心身ともに疲弊し、結局は「交代してほしい」と言われてしまいました。
PMの役割は「自ら手を動かすこと」ではなく「メンバーが円滑に作業できる環境を整えること」です。進捗や課題を把握し、必要に応じて声をかけること。これこそがPMに求められる最も重要な資質だと痛感しました。
３．顧客の希望納期に合わせてスケジュールを短縮しない
納期交渉はプロジェクトにおいて避けて通れないテーマです。顧客の希望は往々にして「最短で、かつ高品質に」という無理難題になりがちです。特に厄介なのは、顧客側の都合でスケジュールが遅れても、リリース日はそのまま据え置かれる場合です。
筆者が経験した例では、顧客の社内稟議が2か月遅れたにもかかわらず、リリース日は変更されず、しかも途中で追加機能まで要求されました。結果、設計書を十分に整備する時間がなく、「頭の中の設計図」を直接エンジニアに伝えながら進めるという異常な体制を強いられました。これは典型的な「人を増やせば早く終わる」という誤解に基づく失敗です。
実際には、新しい人員を加えても習熟に時間がかかり、かえってスケジュールが遅れることも多いのです。この現実を正しく理解してもらうには、PM自身が工数管理やリスク分析について深い知識を持ち、顧客に理論的に説明できる力を養っておく必要があります。
まとめ
以上、いくつかの失敗例を紹介しましたが、裏を返せばどれも「プロジェクトを成功させるために欠かせない学び」でもあります。失敗を経験するたびに、次の案件ではより柔軟に、より冷静に判断できるようになります。だからこそ、失敗談を共有することには大きな価値があるのです。
プロジェクトが無事にリリースを迎えたとき、顧客から「あなたが作ってくれた」と感謝の言葉をいただけるのはPMとして大きな喜びです。実際には筆者自身がデザインやプログラミングをしたわけではありません。しかし、そこで「メンバー全員の努力による成果です」と胸を張って伝えられることこそが、PMの最大の役割だと考えています。
最後に、プロジェクトをスムーズに進めることは決して容易ではありません。しかし失敗を糧にし、一つひとつの経験を積み重ねていくことで、成功の確率を少しずつ高めることは可能です。本稿が、これからプロジェクトに挑む方々にとって小さな道しるべとなれば幸いです。