ホーム > ブログ > 工藤 武久の記事一覧 > 【第87回】あなたは見破れますか?進捗遅延ごまかしのテクニック


【第87回】あなたは見破れますか?進捗遅延ごまかしのテクニック

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

日経コンピュータ:2017年2月16日号の「ITベンダーの能力評価」に関する読者アンケートの記事によると、ITベンダーには「プロジェクトマネジメントの能力」が必要と答えている人が最も多いという結果でした。(※1)

発注側としては、さまざまな角度で能力評価を行ってITベンダーの選定を行いますが、結果としてプロジェクトが暗礁に乗り上げてしまうケースも見受けます。提案書とプレゼンテーションだけで、ITベンダーの真の実力を見破ることが難しいのが実情ではないでしょうか。。。

 

【 珍種目No.1は誰だ!? ピラミッド・ダービー 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
TBS系列で放送されている「珍種目No.1は誰だ!? ピラミッド・ダービー」というバラエティ番組をご存じですか?私は、結構この番組が気に入っていて、良く見ています。たとえば、次のようなコーナーがあります。(※2)

歌声見極めダービー
同じ曲を歌った4つの歌声を細切れにつないだメドレーを聞き、冒頭で紹介される大物歌手本人の歌声が何枠かを当てる(他の3枠はその歌手の大ファン、カラオケが得意な素人、モノマネタレントなどが、当番組のために本人に似せた歌声を披露)。

本当の価値が分かるかダービー・絵画(写真)編
映像で表示された4枚の絵画や写真のうち、1枚は時価数億~数十億する作品、残る3枚は小学生がコンクールで入選した作品(入選当時の年齢、海外の小学生の物の場合もある)となっている。パネラーは4枚の作品を見比べ、どの作品が数十億円かを当てる。

「本物」とか、「本当の価値」というものは何をもって評価するかは難しい話なので、深入りはしませんが、一見するだけではそんなに違いがわからなくても、実際には世の中の評価が大きく異なるということは良くあることです。そのこととシステム開発の委託先ベンダー選定を単純に比較できないことはもちろんですが、ピラミッド・ダービーを見ながら、ベンダー選定のことをついつい連想してしまうのは、やはり職業病なのかもしれませんね。。。

ちなみにベンダー選定のプロセスについては、長尾 清一著『ベンダー・マネジメントの極意』によくまとめられていますので、発注側ご担当の方は一読に値すると思います。(※3)

 

【 大規模プロジェクトにおける進捗状況把握の難しさ 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
今回のブログで取り上げたかったのは、ベンダー選定ではなくプロジェクトの監視・コントロール段階での進捗管理です。当ブログの【第32回】準優勝!と決勝敗退!の微妙な違い では、「進捗状況を把握するポイントは、累積と差分の両方を把握することだ!」としましたが、プロジェクト全体の進捗状況を的確に把握することはなかなか一筋縄ではいかないのが現実です。

特に大規模プロジェクトの場合は、複数チームにより、数多くのタスクが同時並行的に実行され、それぞれの進捗状況が関連する他のタスクにも影響しあったり、さまざまな問題が広範囲の進捗に影響する場合もあることから、プロジェクト全体の進捗状況を的確に把握することは至難の業です。

進捗状況を定量的に表そうとしても、プロジェクトのスコープが知らず知らずに拡大していたり、問題の影響で手戻りなどの追加タスクが発生していることも多く、数字だけでは拾いきれない定性的な情報も踏まえて、全体感を把握することがプロジェクト・マネージャには求められるのです。

前回【第86回】タイタニックに学ぶ大規模プロジェクト・コントロールの勘所 でも触れた通り「大規模プロジェクトをコントロールするためには、コントロール可能なサイズにプロジェクトを分割する」ことになりますが、プロジェクト全体を統括するプロジェクト・マネージャは、分割された個々のプロジェクトの定量的、定性的な進捗状況を吸い上げて、プロジェクト全体の進捗状況を把握して、次のアクションにつなげていく必要があります。

分割された個々のプロジェクトから吸い上げた定量的、定性的な進捗状況を見誤ると、的確なプロジェクトのコントロールができずに、プロジェクトが暗礁に乗り上げ、失敗する確率が高まります。

 

【 進捗遅延ごまかしのテクニック 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
さて、分割された個々のプロジェクトからしてみると、本来はプロジェクト全体のことを考えて、小さな問題もプロジェクト全体に影響するリスクになるかもしれないという意識をもって、プロジェクト・マネージャに報告する義務があります。小さな問題全てを全体プロジェクトのマネジメントチームに上げていては、扱う問題の数が多くなりすぎてコントロール不全に陥るかもしれないということもありますが、問題を放置することでタイタニックの二の舞になることだけは避ける必要があります。

しかし、自分や自組織の問題が原因で、プロジェクト全体の足を引っ張るという事態はできればオープンにしたくないという思考が働いて、責任回避のために情報を隠ぺいしたがるプロジェクトメンバーやITベンダーも存在するのが現実です。プロジェクト・マネージャは、そのような情報隠ぺいや進捗状況のごまかしには騙されないようにする必要があるのです。

そこで、警視庁ホームページの「あなたは見破れますか?振り込め詐欺のテクニック」を模して、進捗報告ごまかしのテクニックをいくつかご紹介しますので、プロジェクト・マネージャの方はこの手口にひっかからないようプロジェクトをコントロールして頂ければと思います。

1.完了予定日の勝手な変更

当初計画を基準にすると進捗遅延になっているはずなのに、進捗報告会のたびに完了予定日が勝手に後ろ倒しになっていて、何食わぬ顔でオンスケの報告が続けられるという事例です。仮に完了予定日の勝手なリスケを指摘しても、予測不能の事態によりリスケを余儀なくされたとの言い訳が用意されています。

⇒ 自責他責にかかわらず、どんな理由であろうとスケジュール変更を行う場合は、進捗報告会を待たずにプロジェクト・マネージャへの報告と承認が必要なことをルール化し、徹底しましょう。

 

2.ゴール(総数)不定な数値に基づく定量報告

当ブログの【第81回】課題管理と進捗管理のビミョーな関係 で示したように、たとえば外部設計工程で設計対象とする機能の数ではなく、設計課題の発生・解消状況だけを定量的に進捗報告を行うなど。課題検討の結果で派生して設計課題の数が増えることもあるので、一見定量的な報告をしているようでも意味の無い数字となっている事例です。工程開始時は機能数がまだ確定していないので、機能数による進捗報告はできないとの言い訳が用意されています。

⇒ 機能数がまだ確定していない場合は、見積り時点の機能数をゴール(総数)として仮置きして進捗状況を定量的に把握できるようルール化しましょう。機能数が確定した段階でゴール(総数)を置き換えます。仮にゴール(総数)が見積り時と大幅にかい離していた場合は、再見積りの上全体計画の見直しが必要です。課題の発生・解消状況はあくまでも補助的な進捗管理指標として活用しましょう。

 

3.不都合な進捗部分の隠ぺい

たとえば解決困難な設計課題があり、一部の機能の設計が止まっている場合など、その部分を除外した進捗状況を報告し、あたかも全体進捗が順調であるかのように見せかける事例。設計課題の状況は別途定性的な報告をしているので定量的な報告からは除外したという言い訳が用意されています。

⇒ 進捗報告はどれだけ作業をやったという実績報告よりも、ゴール(総数)に対してどれだけ近づいたかということを定量的に把握するものという意識を徹底しましょう。たとえ、不可抗力や他責による問題が原因の遅延であったとしても、そのことがプロジェクト全体にどう影響するか、その影響に対してどんなアクションができるかを全体感を持って検討できるようにしましょう。

 

4.他の問題へのすり替え

スコープ外の部分や他のステークフォルダに関係する問題にわざと首を突っ込んで、そもそもの進捗遅延を他の問題と絡めることで焦点をずらそうとする事例です。

⇒ IT構想・企画をしっかり行い、プロジェクトのスコープがブレないようにすることが大切です。プロジェクトが進行していく中でスコープがブレ始めた場合は、一度立ち止まって、プロジェクトの目的・ゴールとスコープを再確認した上で、プロジェクトを仕切り直す必要があります。

「私は大丈夫!」と思っていても、特に大規模プロジェクトは全体状況を的確に把握することは難しいものです。日頃からプロジェクトの全体状況を俯瞰的に把握するような仕組みと意識を持って、知らず知らずに進捗遅延が進行してプロジェクトが暗礁に乗り上げるかもしれないリスクに対する心の準備をしておきましょう!

「大規模プロジェクトの進捗遅延は、知らぬ間に進行しているかもしれないことに留意しよう!」

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 『日経コンピュータ』2017年2月16日号、日経BP社より
・P096 Voices「ITベンダーの能力評価」

※2 「珍種目No.1は誰だ!? ピラミッド・ダービー」『フリー百科事典 ウィキペディア日本語版』2017年2月15日 (水) 12:27 UTC
https://ja.wikipedia.org/wiki/珍種目No.1は誰だ!%3F_ピラミッド・ダービー

※3 長尾 清一著(2009)『ベンダー・マネジメントの極意』日経BP社

※4 警視庁ホームページ「あなたは見破れますか?振り込め詐欺のテクニック」
http://www.keishicho.metro.tokyo.jp/kurashi/tokushu/furikome/furikomesagi.html

Pocket

| 目次

Profileプロフィール

工藤 武久
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事

PMI®公認教育プロバイダー(R.E.P:Registered Education Provider) 株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。
PMI Registered Education ProviderロゴおよびPMBOK®Guideは、PMI®(Project Management Institute, Inc.)の登録商標です。
IIBA®認定教育プロバイダー(E.E.P:Endorsed Education Provider) 株式会社アイ・ティ・イノベーションは、IIBA®(International Institute of Business Analysis)の認定教育プロバイダー(E.E.P:Endorsed Education Provider)です。
IIBA®BABOK®およびBusiness Analysis Body of Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。