プロローグ - 解釈は十人十色

「販売システムでは、結合テストに関する課題はありません」――各システムの進捗を報告するプロジェクト定例会議における、販売システムのマネジメント担当Aさんの発言である。

このコメントを受けて、販売システムと連携する会計システムのマネジメント担当Bさんは、すかさず次のようにコメントした。

「エラー時の差し戻し方法とか、決めなくてはいけないことがまだあると思うのですが」。

それに対し、Aさんは「確かに、システム間結合テストは未検討ですね」と悪びれる様子もない。どうやら、「業務システム間インタフェースが仕様通り動作するか確認する」ために行う行為の呼び名がお互い異なるようである。

さまざまな人が集まるプロジェクトでは、呼称や解釈の違いで混乱が生じることも

プロジェクトは、場合によっては異なる会社、少なくとも異なる経験を積んだ人々、更には異なる国籍の人々で構成されることがある。読者貴兄が取り組むプロジェクトでもこのようなケースが発生しないとは言い切れないだろう。人の解釈とは、まさに十人十色である。

このケースでは、会議の場で認識の違いに気づき、是正することができたのでヒヤリで済んだ。しかし、もし放置されていたら、スケジュール遅延や手戻りが生じたかもしれない。プロジェクトマネジャーとしてはゾッとすることだろう。

さて、そこで、今回の『"PM力"向上に効く、6つのケーススタディ』では、本ケースを分析して、その対策のヒントを述べたいと思う。コミュニケーション管理に少々工夫を加えることで、ヒヤリ防止に貢献するはずなので是非ご一読願いたい。

2つの失敗要因

では、上述のケースの問題を分析してみよう。

先ず、プロジェクトで用いる用語の定義が統一されていないことが原因の1つであることはお気付きだと思う。Aさんのいう結合テストと、Bさんのいう結合テストとは目的や範囲が異なるのである。AさんやBさんは自身の経験則に基づきこれら用語を用いており、プロジェクトから特段の指定がなかったのであれば、AさんやBさんの非ではなく、プロジェクトマネジメントすなわちコミュニケーション管理の失敗といえるだろう。

そして、もう1つ。こちらは、失敗というよりは改善ポイントになる。Aさんは「課題はありません」と純粋に思っていたわけであるが、課題がないという状態が、プロジェクトの状況において適切なのか否か判定できれば、違う観点でこのヒヤリを防止できたかもしれない。

「課題がないなんてありえない。ヒアリングしてこい！」ではあまりに乱暴なので、ここは定量的かつスマートに「販売システムのこれまでの期間や、会計システムと比較すると課題検出率が著しく低くなったようだけど工程の改善があったの？」とフォローしたい。つまり、プロジェクトマネジメント自体の定量的な可視化ができていればこういったフォローも可能となるのである。

以上のように、このケースのコミュニケーション管理においては、以下2つの失敗があったといえる。そして、以降の章では、これらへの対策案を解説していきたい。

  • プロジェクトにおける共通用語が定義されていない
  • プロジェクトマネジメント自体が可視化できていない

共通用語を定義しよう

コミュニケーション管理は、会議体、レポートライン、報告手段やフォーマット等プロジェクトの実績情報の報告方法を定義し、運営をモニタリングし、必要に応じ是正するとともに、ステークホルダーの満足度を管理するプロセスであるが、これらに加えて、弊社では共通用語の定義も重要ポイントとし、各プロジェクトマネジャーに喚起している。

プロジェクトを安全に進めるうえでは用語の定義も重要なポイント

以下、共通用語の定義時におけるポイントを4つ例示するので参考にして頂けると幸いである。

1. 用語辞典を作成し、共有・更新する仕組みを作る

プロジェクト始動時に網羅的な用語辞典を作成することは不可能なので、先ずは仕組みを作ることである。プロジェクト関係者が参照可能なWebサイトやファイルサーバーに用語辞典ファイルを用意し、更改の担当とプロセスを決めよう。

2. 「行為」は5W1Hと目的を明確にする

失敗ケースで取り上げた○○テストに加え、「レビュー」なども解釈に差異が生じやすい。また挙げればきりがないが、英字略語も独自文化やベンダー語が存在することに留意したい(例えば、ユーザーによる受入のためのテストを意味する英字略語がベンダーによっては「UT※1」であったり「UAT※2」であったりする)。

※1 User Test
※2 User Acceptance Test

3. 「状態」はその閾値を定義する

「安定」とか「不安定」、「負荷が高い」など主観は誤解のもとである。例えば「CPUの負荷」は、使用率75%以上を「高い」という等定義するとよい。

4. 「環境」はその構成と目的を定義する

「検証機」「開発機」などは解釈に差異が生じやすいので、搭載するソフトウェアや設定等の定義、エンドユーザー開放前の最終確認なのかプログラムのデバックもするのか等目的を明確にすると誤解が少ない。

さて、共通用語の定義の重要性と定義にあたってのポイントを説明させて頂いたところで、今回は筆を置かせていただくこととしたい。次回は、もう1つの失敗要因であったプロジェクトマネジメント自身の可視化方法について解説をしたいと考えている。

プロジェクトマネジメント自身を可視化することは、プロジェクト進行中であればマネジメントの改善箇所の検出と是正に繋がるとともに、プロジェクト終結時に行うべきプロジェクトマネジメントの実績と効果に関する総括も可能となる。そしてその総括の結果を、次のプロジェクトにフィードバックしていくことで、読者貴兄自身や所属する組織のスキル底上げにも繋がる。これぞ一石三鳥(場合によってはそれ以上)の取組みともいえるので、次回を楽しみにお待ちいただきたい。

執筆者紹介

荒浪篤史(ARANAMI Atsushi) - 日立コンサルティング マネージャー


大手ネットワークベンダーを経て、ITコンサルティング会社の立上げに参画、同社のITアーキテクトとして様々な業種、官公庁におけるオープンシステムの設計、プロジェクトマネジメントをリーディング。その後、役員として新会社を立ち上げる。2008年に日立コンサルティングへ入社、現在に至る。


監修者紹介

篠昌孝(SHINO Masataka) - 日立コンサルティング ディレクター


国内最大手のファイナンシャルグループで、BPRプロジェクトや、数多くのEコマース構築プロジェクトにて、PMを歴任。2001年に外資系大手コンサルティングファームに入社、主にERP導入や、SOA技術を駆使した大規模SIプロジェクトを成功に導いた。同社のパートナー職を経て、2007年より現職。