ビジネスにおける IT成功するプロジェクト管理

Alessandro Muti

現在のテクノロジ環境によって IT 組織にもたらされる課題は、増加の一途をたどり、急速に変化する課題であることは疑いの余地がありません。ソーシャル メディア、スマートフォン、イントラネット、エクストラネットなど、数々のテクノロジの普及により、IT プロフェッショナルの仕事は、単にデータ センターに配置されているサーバーとインフラストラクチャを管理することから、ひとかどの製品ソフトウェア開発者の仕事に近いものへと進化しています。

そのうえ、現在の不況のために、多くの企業は経費削減や人員削減を実施せざるを得ず、IT 部門にはかつてないほどのプレッシャーがかかっています。このような数々の課題にもかかわらず、サーバーとインフラストラクチャの管理は行う必要があり、かつてないほど多くのプロジェクトを少ないリソースでやり遂げる必要があります。このような課題を前にした場合、プロジェクト管理手法と管理力の向上は、プロジェクトを成功に導くうえで欠かせません。これなしには、プロジェクトは失敗に終わる可能性があります。

私が、これまでのキャリアの中で何度も経験している問題の 1 つは、高い技術力を持っている人は、経営陣をはじめとする管理者に対して生理的に不信感を持っている場合が多くあるということです。通常、この問題は、管理者が同じような経歴の持ち主であることがまれで、開発者と管理者の間でプロジェクトの開発と遂行の複雑さに対する予想が異なることに原因があります。そのため、開発チームはフラストレーションを感じ、多くの場合は冷たい態度をとるか、「そう言ったじゃないですか」的な態度を取ることさえあります。しかし、最終的に、プロジェクトが失敗に終わった場合、その責任は開発者自身に跳ね返ってきます。問題の本質は、考え方が同じであるとは言えない管理者と、有効な意思疎通を図れないことにあります。残念ながら、これはよくある話です。リスクをきちんと伝えたと思い込み、理解されていなかったことに気付くのは、とき既に遅しとなってからです。残念ながら、我関せずという態度のために、技術的に非常に充実したプロジェクトであっても、失敗に終わる場合があります。

ご存じのことと思いますが、プロジェクトの中には、最初から絶望的に思えるものもあります。たとえ経験豊富な開発者が、何日も遅くまで働いて、技術的な専門知識を駆使してお粗末な管理者による決定に対応しようとしても、残念ながら、多くの場合はどうしようもありません。こうなった場合、我関せずという態度をとるよりも、作業を中断して、プロジェクトの本当の問題はどこにあるのかを探し出し、それを解決した方が、プロジェクトの成功を期待しながら英雄的な努力をするよりも、はるかに有効です。そうでないと、自分の仕事においていくら有能であっても、そのプロジェクトの失敗が自分の経歴に付きまとうことになります。

私の経験上、一番良い対応は、プロジェクトの最初から目を配ることです。通常、プロジェクトの開始時は、だれもが不満なくやる気にあふれており、プロジェクトの方向性、コスト、成果物などについて同意し、理解できているように思えます。しかし、時間の経過と共に、問題は必ず忍び込んできます。データベースのパフォーマンスが予想どおりでないとか、トラフィックを処理できないなど、ちょっとした技術的な配信上の問題が発生しているかもしれません。そして突然、プロジェクトの失敗を示すサインに気付いていたら、容易に対処できていたはずのものが、解決不可能に思える大きな問題に発展しています。

では、このサインとはどのようなもので、プロジェクトを予定どおり進めるにはどうしたらよいでしょうか。

なんといっても、プロジェクトの構想と範囲を維持することが不可欠です。構想と範囲については、その構想を実現するために何が必要かということと併せて、プロジェクトの開始時に合意が得られている必要があります。それなしには、期待している成果物と、チームが実際に作り上げるものの間に、どうしても食い違いが生じます。現実が構想から逸脱し始めた場合は、必ず仕切りなおして軌道を修正し、管理者の期待するもの、ユーザーが期待するもの、および最終的な成果物とが、極力一致するようにします。

これを実現するには、全体的な事業目的についてのドキュメントを常に最新の状態に保つことが有用です。このドキュメントには、全関係者のニーズと要件、および関係者間で交わされた話の内容を細かく書き留めます。このドキュメントを常に最新の状態に保ち、これを共有して、関係者全員の合意と承認を得ることで、少なくとも管理者や他の関係者の要求とユーザーが期待することの間に食い違いが生じるリスクを、最小限に抑えることができます。また、プロジェクトの構想を表面的に理解しただけで、プロジェクトが開始されるのを防ぐこともできます。1 つ注意して欲しいのは、構想についてのドキュメントは、範囲についてのドキュメントではないということです。範囲についてのドキュメントは、プログラム マネージャやチームによって作成され、構想に沿って特定のプロジェクトの詳細を規定するものです。

この範囲についてのドキュメントは、プロジェクトを成功に導くための次の非常に重要な段階につながります。つまり、プロジェクトの範囲を理解し、他のすべての関係者もこれを理解するようにします。すべての関係者が参加する一連の会議を開き、プロジェクトの範囲について合意が得られるようにします。範囲を見積もる方法にはさまざまな方法があるため、ここでは詳細は省きますが、よくある間違いとして、複雑な技術上の課題を解決するために必要な労力が低く見積もられることを指摘しておきます。私たちの多くは生来楽観的です。ソリューションの構築に必要な労力を見積もるときは、この点に留意してください。

もちろん、プロジェクトのこの段階では不明なことが多いため、ある程度の推測は必要です。このような推測については文書化し、プロジェクトに対する影響について見解が一致していることが非常に重要です。また、詳細を話し合うことで、関係者間で構想のドキュメントの解釈についての食い違いが起きている可能性を早期に把握できる場合もあります。たとえば、必要な時間と作業について 2 人の人間の意見が一致しない場合、構想のドキュメントをまったく違う形で解釈している可能性が非常に高いと言えます。これは、構想が明確であることを確認し、同じ項目に対する関係者全員の理解の一致を図る必要がある可能性を示しています。

このような推測事項の文書化は非常に重要です。これは、管理上層部と関係者の両方と技術的でない多くの課題について話し合う足場になります。また、プロジェクトを成功させるため、作業時に遵守する必要がある制約を全員が理解するうえでも役立ちます。管理者と範囲についての意思疎通を図るのは困難であっても必要な作業です。概して、このドキュメントは、このコミュニケーションを促進するツールとして利用してください。また、範囲を設定できるように、初期段階での検討事項の答えを出すために使用してください。それなしには、意思疎通の多くは図れないでしょう。

これが片付いたら、プロジェクトを進める適切な方法を選択する必要があります。さまざまなモデルがありますが、どのモデルにも利点と欠点があります。常に成功するモデルなどなく、誤ったモデルを選択した場合、プロジェクトの失敗につながる可能性があります。多くの企業には承認された方法があり、これに従うことが期待されますが、あまりに制約が多すぎたり、当該プロジェクトには最適でないために、抵抗に遭うことが多くあります。しかし、このモデルは重要です。適切に調整した場合、このモデルによって、全関係者間の合意を維持する一連のチェック機構を用意できるためです。管理者を常に巻き込むことができ、管理者はフィードバックを提供する時間が用意されているプロセスに参加していると感じられるため、同意のないまま管理側が決定を下すことを防げます。

実際、関係者全員が、プロジェクトに対するそれぞれの予想と、実際の成果物とを比較する機会が得られるように、よく練られた定期的な見直しをプロセスに組み込む必要があります。こうすることで、逸脱を抑えながら、定期的に問題を特定して解決することができます。

この段階では、透明性も非常に重要です。生み出された成果物はすべて共有し、だれもが参照できるようにすることで、関係者全員に各自の都合のよいタイミングで作業がどのように進んでいるかを理解する機会を与え、自由に進捗状況を確認できるようにします。透明性により信頼が築かれます。信頼があれば、チームの現状を確認する手段がないからといって、プロジェクトを事細かに管理しようとはだれもしません。確認手段がない場合、疑念が生まれます。そして、翌日に何が起きるかがわからないという状態を多くの人は嫌うため、この情報を自分で見つけようとします。この情報が容易に入手できれば、そう何度もあなたのところにやってくる必要はなくなります。

どんなプロジェクトでも、途中で軌道修正が必要になります。これは、早めに対応してください。誤った推測を基に作業を進めれば進めるほど、後で修正が必要な作業が増え、修正も難しくなります。このような変更を行う場合は、ここで説明したのと同じプロセスに従うようにしてください。まず、関係者全員に、プロジェクトの構想が同じであるか、変更されているかを確認し、作成したドキュメントを修正して、予測を修正し、以前推測した事項を調整します。決定事項や軌道修正が小さいものであっても、このプロセスから外れないようにしてください。細かい変更が積み重なることで、最終的にはまったく別の状態に行き着きます。変更を文書化せず、全関係者間の情報伝達を怠った場合、技術的には正確であっても、成功とは認められない結果を生むことになるでしょう。

Alessandro Muti は、包括的なサービスを提供するインタラクティブ エージェンシーでテクノロジ コンサルティング企業である Ascentium の CTO を務めています。マイクロソフトの Windows チームを皮切りに、この 20 年間、ソフトウェア業界で仕事をしてきました。現在は、Ascentium の技術戦略の指揮をとっています。また、Web プレゼンス、プライバシー、ソーシャル メディア、モビリティ、セキュリティ、オンライン メディア配信、デジタル ブランド管理のほか、テクノロジとはかけ離れているように見えるものまで、顧客のテクノロジ戦略の策定を支援しています。