『プロジェクトを絶対に失敗させない！やり切るための100のヒント』とは
本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない！やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。
当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
お問合せはこちらからどうぞ。
※『プロジェクトを絶対に失敗させない！やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます
プロジェクトを進めるうえで必ず起こる問題は、担当者間、チーム間のコンフリクト（対立）です。特にアプリケーションの担当者（チーム）とインフラ担当者（チーム）の間では、どんな現場でもコンフリクトを起こします。最悪の場合、プロジェクトの成否に関わる問題に発展しかねません。主な原因は3つ。それぞれについて、PMOがどう対処すべきかを考えてみましょう。
最近のプロジェクトでは、様々な技術を組み合わせてシステムを開発するため、インフラ部分は技術系の専門チーム、あるいは他の開発ベンダーが担当するケースが多いと思います。PMOとしては当然、アプリチームとインフラチームをうまく調整しながらプロジェクトを進めていかなければなりません。しかし、対立する原因がよく分からなければ、適切な対処はできません。
私の経験上、アプリチームとインフラチームが対立する原因は、以下の3点にあると考えています。
（1）お互いが相手のことを知らない
（2）プロジェクトの成功よりも自分の組織の成功を最優先に考える
（3）「相手が決めてくれないと自分の作業が進まない」という理屈が横行する
なかなか根深い問題です。このような対立が最もよく出る性能問題を例に、PMOとしての対処の仕方を考えてみましょう。
自主性に任せず、仕組みとして整備する
まず（1）について。現在、プロジェクトマネジャーとして活躍されている人の大部分は、アプリかインフラのどちらかのチームで、チームリーダー、プロジェクトリーダーを経てプロジェクトマネジャーになった人ばかりだと思います。アプリとインフラの両方のチームリーダーを経験した人は、最近では少数派です。
IT業界の最近の傾向として、チームリーダーになる頃から、将来アプリのエンジニアを目指すのか、テクニカルなインフラ系エンジニアを目指すのか、キャリアパスを決めてしまいます。また、大きな会社になると、そもそもインフラ系とアプリ系で組織自体が別々になっています。エンジニアとしての専門性を高めるための施策としては当然ですが、アプリチームとインフラチームの間にコンフリクトを生む下地にもなっています。
かなりベテランのプロジェクトマネジャーに話を聞くと、昔はプロジェクトにおいてアプリやインフラという区別そのものがなく、何でも自分でやっていたと言われます。そういう意味で、以前と比べてお互いを理解しづらくなっているのは納得がいきます。
しかし、アプリかインフラの片方だけでシステムを開発することはできません。アプリとインフラがそろって、初めてシステムとしての価値が生まれるのです。それを担当する人と人の間にも、「協働して価値を生む」という意識が必要なわけですが、残念ながら現実はかけ離れた状況にあります。
例えば性能問題が生じた時、どのようなコンフリクトが生じるでしょうか。原因が特定されるまでの間、アプリ側は「データベース（DB）のパラメーター設定など、インフラ側がおかしいのではないか」と考えます。一方のインフラ側は、「アプリ側のSQLやロジックの組み方が悪いのではないか」と考えるでしょう。大抵、双方に問題がある場合が多いのですが、こんな責任転嫁がよく起こります。
理由は単純です。お互いが別々に成果物を作り、それぞれができたところで組み合わせてみて、初めて双方の不整合に気づくからです。
両者とも、単体で見れば決して間違ったものを作ろうとはしていません。業務しか知らないアプリ担当者にしてみれば、アプリを設計書通りに作れば、「あとはインフラ側が性能のよい“ハコ”を作ってくれるはずだ」という勝手な思い込みがあるのかもしれません。逆もまたしかりです。
このような食い違いが発生する原因は、「最初からそれぞれの成果物を見せ合って、話し合いながら一緒に作っていく」という意識や行動が欠けているためです。ひどい場合には、システムテストのフェーズになって初めて性能テストを実施し、設計通りの性能が出なくてプロジェクトが迷走する、といった例もあります。
開発に着手する段階からアプリとインフラの両チームが協力し合えば、このような状況は避けられます。アプリチームが作成した設計書をインフラチームで精査して各種パラメーターを検討するとか、性能が出ないと思われるアプリについて単体テスト段階からインフラチームと検討する、といった協力体制があれば、問題は未然に防げます。PMOはそのような協力体制を仕組みとして作り込んでしまうことが必要なのです。メンバーの自主性だけに任せておくと、いつまでも同じような問題が繰り返し起こります。
プロジェクトの成功が目的になるように仕向ける
次に（2）の問題を考えてみましょう。アプリチームとインフラチームはしばしば、組織が異なります。例えば、アプリチームが所属している部署が顧客からプロジェクトを受注して、インフラ面の支援を別の部署に依頼したとします。始めは両者が協力的に仕事をしていますが、一度プロジェクトに問題が発生すると、インフラチームは自分の組織を守る方向に走りがちです。特に、事業部制などで部署ごとに利益目標が課されている場合は、その傾向が強いと言えそうです。インフラチームにしてみれば、自分の組織の収支を赤字にし、自分の評価を下げてまで、他の部署のプロジェクトを成功させようとは、よほどのインセンティブやプロジェクトマネジャーのリーダーシップがない限り思わないでしょう。そんな時、「うちの部署ではそこまでの責任を持てない」とか、「ここはうちの部署の役割ではない」といった非協力的な話がよく出てきます。
このような場合にPMOは、プロジェクトが1つの方向を向くようにナビゲートしなければなりません。上位組織に呼びかけるなどの対応は不可欠ですが、あくまでも「プロジェクトの成功が最も重要なゴールである」とプロジェクト全体に示す必要があります。その意味において、「プロジェクトとして成功したかどうか」を人事評価項目に含めるのも1つの手だと思います。
タスクのデッドロックを防ぐ、課題のエスカレーション
最後に（3）の問題を取り上げます。計画段階で役割分担を決め、綿密なWBSを作成したとしても、必ずといっていいほど、「ここはアプリ（インフラ）側で決めてくれないと先には進めない」という課題が発生します。
日々のタスクが忙しいなかで、このようなタスクの優先順位は下がってしまいがちです。これがどんどんたまっていくと、必ずどこかで「相手がやってくれないからできない」という問題が相互に起こり、タスクのデッドロックが発生します。例えば、性能評価において、インフラ側は「アプリ側がSQLの発行件数を示してくれないとDBのパラメーター設定ができない」と言い、アプリ側は「DBのパラメーター設定値が分からないと、SQLの発行件数が見積もれない」と言い出します。
対処策は単純です。パラメーターの暫定値を決め、性能評価のなかでチューニングしていけばいいだけの話です。しかし、あるべき論を振りかざして、担当者同士がつまらない意地の張り合いをすると先に進めません。もし、進捗上の課題の発見が遅れると、対応しようにも「時すでに遅し」という事態に陥るケースが多々あります。PMOはこのような課題を早期に発見して、担当者同士の課題からプロジェクトの課題へとエスカレーションできる仕組みを作る必要があります。
アプリとインフラの間で起こるコンフリクトは決してなくならないし、おそらく増えていくと考えられます。将来、プロジェクトマネジャーやPMOを目指す人は、時には自分のキャリアパスを少し寄り道して、専門外のことを経験してみてもよいでしょう。相手側の事情が分かると、その経験はきっと役に立ちます。