バット フォン: ホワイト ペーパー

このホワイト ペーパーのタイトルは、ゴッサム・シティが危機に陥ったとき、ゴードン警部補が自由に使いこなすバットフォンを意味しています (1970 年代の TV シリーズ「バットマン」より)。

このホワイト ペーパーは、弊社の「From the trenches (英語)」コレクションの一部です。 ここでは、EPM の実装中に遭遇するバットフォンが欲しくなるようなトラブルについて、架空の "バットマン" の物語になぞらえて説明します。 また、実装中のトラブルを回避する多くの方法についても説明します。

このホワイト ペーパーの Word バージョンをダウンロードするには、「The Batphone (英語)」を参照してください。

その他のホワイト ペーパーについては、「From the Trenches (英語)」のホワイト ペーパーを参照してください。

バットフォン

バットマンの TV シリーズが最初に放映されたのは、1966 年です。 放映されたのは 120 エピソードだけですが、文化を変えるほどの影響があり、それは今日まで続いています。 (アダム・ウェストとバート・ワードが演じる) バットマン & ロビンの世界では、あらゆることをバットマンの道具 (ソリューション) で解決できます。 バットマンには、あらゆる問題を解決するソリューションがあります。 たとえば、バットモバイル、バットボート、バットプレーン、バットケーブなどです。 さまざまな困難な状況で助けが必要な場合、どうやってバットマンを呼べばよいでしょうか? もちろん、バットフォンを使います。 バットフォンで呼べば、すぐに助けがやって来ます。

赤いバットフォンの画像 (テレビ シリーズ「バットマン」から)

毎度のことですが、ゴードン警部補は絶体絶命になるとバットフォンに頼ります。 どんなピンチでも、バットフォンで電話すれば 22 分 (とコマーシャルの時間) で悪党はやっつけられ、ゴッサム・シティは平和を取り戻します。

バットマンの世界では、すべてのソリューションがこうもりをモチーフにデザインされています。 手錠は こうもり形で、 ベルトには こうもりのロゴが付いています。 フックのデザインは もちろん、こうもりの翼です。 驚くべきことに、バットフォンの絵を改めて見ると、その外観は非常にノーマルで、 ダイヤル付きの赤電話です (覚えていますか?)。ダイヤルが必要な理由はわかりません。 電話の相手先はバットケーブだけで、呼べばすぐに助けが飛んで来るためです。

ダイヤル付きの電話やバットマンの昔のエピソードは懐かしいですが、ここでの本題ではありません。 バットマンの引退から 40 年たちますが、EPM コンサルタントへの電話は毎日かかってきます。まるで、バットマン並みの活躍を期待されているかのようです。

その内容はさまざまです。 たとえば、技術的な問題 (バージョン x からバージョン y へのアップグレードなど)、 設計上の問題 (社内の EPM システムで外部のユーザーと会話する必要があるなど)、 文化的な問題 (ユーザーがシステムの利用を拒否するなど)、 手順の問題 (プロセスに従っても期待どおりの結果が出ないなど) です。

問題の内容にかかわらず、コンサルティング会社に対するリクエストは同じで、「すぐに解決できますか?」というものです。

非常に多くの EPM ユーザーがこのような状況に陥っており、すぐに解決するためのサポートを必要としています。 緊急性が高く、経営陣から昨日のうちに解決することを求められる場合もあります。 このような電話をしてくる人 (週に数回あります) は、無能なわけではありません。 非常に知的で能力が高く、仕事に熟練した人たちです。

このような時にバットマンがいてくれればと思いますが、 もちろん来てはくれません (もしいれば、あらゆる個人的な問題に利用するのですが)。 このため、電話してきた人が回答に満足できることはほとんどありません。 そこで、ユーザーが助けを必要とする困難な状況に陥ってしまう理由と、これを回避する方法について考えてみましょう。

トラブルの発生

まず、 EPM の実装中にどのようにトラブルが発生するかについて考えてみましょう。 一般的な理由がいくつかあります。

  • 作業の過小評価    これが、EPM 展開で圧倒的に多いエラーです。 すべての展開が大規模で難しいわけではないので、 必ずこれが原因であるとは言いませんが、 おそらくは希望的観測が原因で、EPM 展開からメリットを得るための作業を過小評価してしまうのはよくあることです。 過小評価における最初のエラーは、ターゲットの選択です。 ツールをインストールすればプロジェクトは成功と考える人がいますが、 もちろん違います。 ツールの最初の使用やツールからの最初のレポートをターゲットと考える人もいますが、 これも違います。 EPM ツールによる問題の解決こそ、ターゲットにすべきです。 つまり、文化の変化、トレーニングの完了、システムの本稼働、ツールの稼働、データの生成こそがターゲットです。 大変かもしれませんが、目標達成まで少し足りないだけで、成果がまったく (またはほとんど) 得られなくなります。

  • 技術的プロジェクトにしてしまう    これは、私たちのようなテクノロジ業界の人間にも責任があり、ほとんどの人がこれを認識しています。 でも、どうしてもテクノロジの稼働が問題の解決と考えてしまいがちです。 このため、弊社のお客様の多くの組織で、このように言われます。「でも、Project Server をインストールしたのに、どうして社員の負荷が減らないのでしょう?」 たびたび説明してきたように、エンタープライズ プロジェクト マネジメント業務では、人、テクノロジ、プロセス、多くの変更管理を、適切な方法で投入することが必要です。 これは、ソフトウェアのインストールだけで自動的に実現できるものではありません。

  • 経営陣の不在    これも発生頻度の高い問題です。 結局のところ、エンタープライズ プロジェクト マネジメント システムの利点を最も理解している人が、多くのプロジェクトやリソースが含まれる環境からの膨大なデータの分析に苦労している場合が多いです。 競合する複雑な優先順位や、スキルと経験のさまざまな組み合わせを組織が調整しようとする場合、エンタープライズ プロジェクト マネジメントは最も一般的な方法です。 経営陣はもともとプロジェクトに含まれると思われるかもしれませんが、必ずしもそうではありません。 単一プロジェクトではなくエンタープライズ プロジェクトを意識するように企業の文化を変えることは、経営陣の参加なくしてはほぼ不可能ですが、EPM 展開が完了しても評価されないという懸念から、経営陣を関与させない場合が非常に多くあります。

  • 非現実的なスケジュール設定    EPM 展開はもちろん、短期間で実行できる方が望ましいです。 また、通常の数か月という期間ではなく、数日または数週間でプロジェクトを完了したいという要望が一般的です。 一般的に、クライアント ベースや商用プロジェクトと比べて、EPM のような “社内” プロジェクトにはリソースをかけにくいという問題もあります。 以上やその他の理由により、非常に不十分なリソース要件でプロジェクト スケジュールを立ててしまうことはよくあります。

  • プロジェクト マネジメントをプロジェクト マネジメント システムに適用しない    私の著作物をお読みになったことがあれば、この内容をご理解いただけると思います。 プロジェクト マネージャーは、“紺屋の白袴” 的な状況の影響を受けやすいものです。 この結果、プロジェクト計画書、予算の承認、スケジュールの追跡、専用リソース、その他のプロジェクトに必要なものが慢性的に不足し、この人が管理する他のすべてのプロジェクトでも同様の状態となります。

当初の予定

以上で、 トラブルの原因について説明してきました。 EPM システムの展開によって経営陣が期待する利点は通常、ビジネスの課題に直結するものです。 これらの課題を確実に解決できるのであれば、経営陣がソフトウェア、ハードウェア、インフラストラクチャ、(場合によっては) サービスなどへの出費を承認しやすくなります。 最も一般的な課題については、なじみのあるものかもしれません。

  • リソースに過剰な負荷がかかっている    リソースの対象は明確でないにしろ、リソースの過負荷がわかることは非常によくあります。 より複雑な問題は、リソースによる負荷のばらつき (過剰または過小) がある場合です。これは、利用可能なスキルや経験と、 必要なスキルや経験との不適合を意味する場合があります。

  • 重要なプロジェクトが、タイムリーに完了しない    重要なプロジェクトを予定どおりに終了する必要があることは当然ですが、そうは行かない場合があります。 原因としては、リソース要件の競合、同じスキルを必要とするプロジェクトを多く選択しすぎること、単なる優先順位付けの失敗などがあります。 組織によってはこれがプロジェクト マネージャーのスキル不足のせいにされますが、複数のプロジェクト、複数の部門を網羅する環境では、原因が組織的な問題である可能性が高いです。

  • プロジェクトを予算内で完成できない    スケジュールの問題は、同じくコストにも当てはまります。 他の多くの業界と同様に、ハイテク業界でも、プロジェクトのコストの最大の変動要素は人件費です。 同じメンバーでも時間がかかれば、プロジェクトのコストは上がることになります。 非常に多くのホワイトカラー プロジェクトが、追跡されないままとなっています。 計画はありますが、プロジェクトあたりの実際のコストは記録されていません。

  • 競合他社の方が早くプロジェクトを完成している    競争経済では、市場に一番乗りできるかどうかで勝敗が分かれる場合があります。 このため、多くの組織にとって、プロジェクト マネジメントを少なくとも競合他社と同程度に効率的に実行できていることを確認することは重要です。

  • プロジェクト リソースをかけている対象や、各プロジェクトにかかっている時間がわからない    答えがわからないということは、誤った答えより悪い場合があります。 経営上層部の場合は特にそうです。 結果が悪いことがわかれば、目の前の問題の解決に、自分のスキルとリソースを使うことができます。 何かが悪いことがわかっていても、それを特定できなければ、何もできません。 修正すべき対象を知ることができないのです。

トラブルの回避方法

バットフォンが必要な状況には陥りたくないですよね。 このためには、EPM 環境をどうすればよいでしょうか?

最初のセクションで述べたことは明確です。

  • 見積もりを的確に行う

  • EPM を単なる技術プロジェクトとは考えない

  • 早い段階から経営陣に関与してもらう

  • 現実的なスケジュールを立て、業界の他のプロジェクトと比較して実現性のチェックを行う

  • プロジェクト スケジュールとプロジェクト計画書を作成し、他のプロジェクトで通常実践することはすべて行う

その他の実行すべきこと

まず、いつかバットフォンを使いたくなると予想してプロジェクトを開始します。 実際、そうなります。 これがわかっているならば、現在の計画にはないサポート用の予算を計上します。 弊社のクライアントに対しては、プロジェクト予算の 10% 〜 20% を “未確定の要件” 用に割り当てておくことを推奨しています。 用途について必ず 質問されますが、 「後でわかります。」と答えておきます。 この予算がすべて使われることはあまりありませんが、 ほとんどの場合、一部は使われます。 熟練した専門家を割り当て、プロジェクトの予算を立てておけば、後で大きな違いが出ます。

計画や人員は変更されるという予測のもとに、開始してください。 プロジェクト マネジメントに関する私のお気に入りの格言は、ナポレオン・ボナパルトの「敵に遭遇するまで戦闘計画は続く」というものです。これは、EPM 計画にも当てはまります。 実装に数か月かかる場合、計画にかかわる人事が変更される可能性は非常に高くなります。 このため、冗長性のある計画を立ててください。

EPM システムは進化しています。 最近では、エンタープライズ アプリケーションで “総所有コスト” を考慮することが一般的です。 EPM プロジェクト計画においては、アプリケーション ライフサイクル全体を含めるべきであると思います。 実装しようとしているツールのバージョンを考えたことはありますか? このツールが依存する他のツールを考慮しましたか? これらのツールの定期的な更新/アップグレードについてはどうでしょうか? カスタマイズは行いましたか? カスタマイズしたトレーニングについてはどうでしょうか? 展開する新しいバージョンにこれらを移行する方法について、考えたことはありますか?

専門家の冗長性についても、計画してください。 担当コンサルタントが 1 名しかいない場合、数か月のうちに実装が新しいフェーズに移行したり、チームに新しい主要メンバーが加わったりした場合はどうなるでしょうか? 同じコンサルタントで良いでしょうか? (コンサルタントは次のプロジェクトに移るので、答えは “ノー” の場合があります)。コンサルティング会社を利用している場合、必要に応じたスタッフ間での業務の引き継ぎ方法について、確認したことはありますか?

文書化する

最も一般的で、簡単に解決できる課題の原因は、不十分なドキュメントです。 最も簡単かつ短期間で変更できる要素ですが、このようなドキュメントが存在することで、参考文献を参照するか、バットフォンを探し回るかの違いが出ます。 また、ドキュメントを作成してどこかにしまい込むだけでは、十分ではありません。 ドキュメントは稼働中の記録の一部にして、EPM プロセスにおける定期的なレビュー プロセスの一部として参照できるようにする必要があります。 EPM 環境で最重要と思われるドキュメントの一部を次に挙げます。

  • ビジネス ケース    元のビジネス ケースがあまり魅力的でない理由はわかりませんが、一般的に見過ごされがちです。ただし、ビジネス ケースは多くの点で、EPM 環境を導入する理由の中核となるものです。 ビジネス ケースには、期待できる組織的な利点、つまり EPM システムによって組織が享受できるメリットが記載されています。 私たちがバットフォンからの電話を受けたら、まず「どのようなシステムをお望みですか?」と質問します。管理者だけでなく、 経営陣、ユーザー、ビジネスの受益者にも質問します。 最も一般的な回答は、それぞれの立場によって異なります。 これは、元のビジネスの前提が失われているためです。

  • 役割と責任    最新の役割と責任を個人に割り当てても、EPM システムで個人が果たす役割はすぐに忘れられてしまいます。 役割と責任のドキュメントを保持しておけば、組織の人事異動や組織構造の変更があっても、EPM プロセスでの担当と役割のパラメーターを調整できます。

  • プロセス ガイドとフローチャート    手順ガイドに取りかかる時期については、忘れられがちです。 手順マニュアルの “操作” 手順についてはこだわるのですが、これらの手順が重要な理由や、各手順の結果の処理方法についてはあまり気にしません。 プロセス ガイド、特に視覚的なフローチャートがあれば、将来の管理者がシステムの用途を把握し、 将来的にシステムを適応させるのがずっと簡単になります。

  • システムの選択条件    EPM システムやサード パーティ ツールを選択する場合、これに従って選択し、将来の世代もこの決定の基準を理解できます。 複数のツールが関連するシステムを展開して 5、7、10 年も経つと、「どうしてこうしたの? こうすればもっと簡単だったのに。」と聞かれることがあります。でも、このように決定した理由がわかりません。 クライアントが何年間も非常に複雑な方法で処理していたことが、既存ツールの最新バージョンではずっと簡単に処理できた場合があります。 このようなクライアントは、ツールの変更や最新バージョンの使用という簡単な決定ができません。数年前に、この特定の方法で処理する選択をした理由が不明なためです。

現実ではバットフォンは存在しない

つまり、イースターのウサギやサンタクロースも実際にはいません。 残念ながら、 現実世界にはバットフォンはないのです。 ただし、このような魔法の電話がなくても、新しく登場するゴッサム・シティの悪党をやっつけてほしいという電話は明日もかかってきます。 トラブルが発生して専門家の助けが必要な場合は、次の内容を実行することをお勧めします。

  1. アドバイスを聞く。 専門家にお金を払ってアドバイスを求めているのに、自分の方が良く知っていると判断するのはばかげています。 アドバイスを求めて専門家に相談するのであれば、アドバイスを聞くか、少なくとも考慮するようにしてください。 バットマンが登場するたびに、ゴードン警部補に「やあ来たね、バットマン。他の警官と同じように、私の指示に従って行動してくれたまえ。」と言われたら、バットマンは現れなくなってしまうでしょう。

  2. バットマンは 22 分で解決できますが、現実ではそうはいきません。 専門家に相談する場合は、問題の修正にかかる時間について、意見を聞いてください。 その後で修正しないことを選択することもできますが、EPM の問題は、技術的なものであっても数分で解決できる場合はほとんどありません。 結局、バットマンは 22 分で処理する必要があります。8 分間は必ずコマーシャルが入るためです。

  3. ゴードン警部補はバットマンにソリューションを教えたりはしません。問題があることを告げるだけです。 混乱した EPM 管理者から電話を受けることはしょっちゅうです。彼らは私がパッチを適用したり、レポートを書いたり、2 人をトレーニングしたりする必要があることを知っています。 私は必ず彼らの話を辛抱強く聞き、クライアントに対して、たった今ソリューションを説明したように問題点も説明してくださいとお願いします。 専門家に電話で相談する前に、まずは目の前の解決したい問題が何であるかを考えてください。

結論

本当に困ったときは、 多方面に相談してください。 1 人のコンサルティングの専門家に聞いて、1 つの可能性のあるソリューションを見つけるのではなく、 同僚や、同じようなトラブルを経験した業界内の人など、2 人以上に相談してください。 1 人の専門家に頼るのと、 別の人にも相談するのと、どちらが実際の問題解決に役立つかがわかります。 バットマンは確かにすごいですが、他にもスーパー ヒーローはたくさんいることをお忘れなく。

著者について

Chris Vandersluis 氏は、カナダのモントリオールに本社がある、Microsoft 認定パートナーである HMS Software の社長であり、創立者です。 マギル大学で経済学の学位を取得しており、プロジェクト管理システムの自動化の分野で、30 年以上の経験があります。 Vandersluis 氏はプロジェクト マネジメント協会 (PMI) の長年のメンバーであり、Microsoft Project Users Group (MPUG) のモントリオール、トロント、ケベック支部の創設に尽力しました。 また、Fortune、Heavy Construction News、Computing Canada magazine、PMI の PMNetwork などに寄稿しており、Project Times のレギュラー コラムニストでもあります。 また、マギル大学の Advanced Project Management で教鞭を取っており、 北米や世界中のプロジェクト マネジメント協会の組織でもよく講演を行っています。 HMS Software は、TimeControl プロジェクト指向の時間管理システムの発行元であり、1995 年から Microsoft Project Solution Partner となっています。

Chris Vandersluis 氏の連絡先: chris.vandersluis@hms.ca

Chris Vandersluis 氏の EPM 関連の記事については、HMS の EPM Guidance サイト (http://www.epmguidance.com/?page_id=39) を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×