有能なプロジェクトマネージャを育てるには（3）：何かがおかしいIT化の進め方（30）（4/4 ページ）

[公江義隆，＠IT]

終わりに代えて――PERTについて

　IT関係者は、PERT（Program Evaluation and Review Technique：工程計画）が嫌いなようだ。日進月歩している技術を適用することへの思い込みからか、「やってみないと分からない」が言い訳になっているような気がする。

　やってみないと分からないとは、「できることややるべきことはすべてやった終わりに代えて――PERTについて人事を尽くした人」がいう言葉だと思う。事前に十分考え、苦労して準備していれば、うまくいけば強い自信につながる（自信はプロジェクトマネージャにとって大切なコンピテンシーだ）。うまくいかなければ、猛烈な反省や原因解明などを通じて、次の成功への大きな経験・知識につながっていく。

　十分に考えなかったり、準備をしないでやっている人は、うまくいってもいかなくても、結果の評価ができないから経験は将来への有用な蓄積にはならない。毎回毎回ゼロからの出発になってしまう。

　PERTの概念や特徴を、各作業の所要時間の「最早・通常・最遅」の3点見積もりと、プロジェクトの所要期間の統計的な予測とする考え方が昨今あるようだが、基本は各作業の前後関係の論理的表現にあると筆者は思う。

　PERTのネットワークを見れば、各担当者は自分の担当する作業の「全体から見た位置付け」が分かる。その意味で、PERTはコミュニケーションツールになる。スケジュールの管理の問題に対しては、クリティカルパスの明確化がこのツールの特長だ。重点管理対象が明確になっていることが大切なことなのだ。

　システム開発プロジェクトの標準的／一般的なPERT図が、時々書籍で紹介されている。この数十程度の作業（アクティビティ）で表されたネットワークを基に、目前の具体的なプロジェクトのPERT図を描いてみると、恐らくアクティビティが数倍になると思う。しかし、ここまではあまり苦労しないでできるが……。まだ目前のプロジェクトの特徴を表現するレベルに至っていない。

　PERTを役に立つレベルにするには、もう一段階ブレークダウンする必要がある（アクティビティの数はさらに数倍〜十倍にアップする）。

　しかし、ここから先は、例えば、開発するシステムの構成などをある程度具体的に頭に描いてみないとブレークダウンできない。全体を通じてキーとなる問題は、具体的にどの辺りにありそうか、その対策は……、などなど、「やってみないと分からない」としていることの多くに対して、事前にその見通しを立てる、方針として決める……、といったことをしないと図が描けない。

　実はここにポイントがある。マネジメントに携わる幹部社員には、洞察力（感と勘）は必須の能力だ。この能力は、分からないことを考え抜き、これしかない、これでやってみようといった覚悟をして、「マネジメントが先行して方針や枠組みを決める（マネージャがリスクを負う）仕事のやり方」の中でしか育たないのだ。

　もし、「やってみないと分からない」とトランプのカードめくりになっているような方がおられたら、小さなところからでも勇気を持って一歩を踏み出していただければと思う。PERTをこんな“場”を提供するツールとして考えてみるのはどうだろうか。

　前々回、前回に述べてきたPMBOKやプロジェクト構造のモデル作りも、PERTも、自分たちの能力を自ら育成していくための“場”や“土俵”として考えていただければ幸いと思う。プロジェクトをうまく運ぶ鍵は、これらのツールではなく、人の頭と心の中にある。

　この十数年、われわれはシリコンバレーやウォール街的な競争原理や、米国流個人主義の悪しき側面に振り回されてきたのではないだろうか。誰かが得した陰で、その分だけ損した人の出るゼロサムの“量”の競争社会がある。一方で、誰かが優れた考えを出せば、それに負けじとさらに良いアイデアを出そうと努力して“質”を競う、お互いが切磋琢磨（せっさたくま）する協働（コラボレーション）もある。いま、必要なのも、またわれわれ日本人が得意としてきたのも後者のはずだ。

profile

公江 義隆（こうえ よしたか）

情報システムコンサルタント（日本情報システム・ユーザー協会：JUAS）、情報処理技術者（特種）

元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業（経済産業省）、沖縄型産業振興プロジェクト（内閣府沖縄総合事務局経済産業部）、コンサルティング活動などを通じて中小企業のIT課題にかかわる

「何かがおかしいIT化の進め方」バックナンバー

• IT関係者は、原発事故から何を学ぶべきか
• 優れたシステムを作るための“思考力、人間力”とは？
• “影”から目を背けてきた原発とIT
• 他山の石――政治を顧みて学ぶマネジメントの在り方
• 「想定外」から脱却できる、真の対策を
• 失敗は成功のもと、成功は失敗のもと
• いまあらためて確認したい、情シスのイロハ（後編）
• いまあらためて確認したい、情シスのイロハ（前編）
• 持続可能社会とITシステムはどう在るべきか（後編）
• 持続可能社会とITシステムはどう在るべきか（前編）
• 新型インフルエンザ対策に学ぶ組織の在り方
• 変化の中で、自らを制御できるものが生き残る
• “変化”を模索する世界（後編）
• “変化”を模索する世界（前編）
• “変化”は外からやってくる（後編）
• “変化”は外からやってくる（前編）
• その考え、本当にあなた自身のものですか？
• 事の本質を見極めよう
• 適材適所の人材育成をしよう
• コンプライアンスを語る前に考えてみること
• “シックオフィス”で健康を損なっていませんか？
• ゆでガエルになる前に情報子会社は経営の見直しを
• ディスカッションテーマのおもちゃ箱（2）
• ディスカッションテーマのおもちゃ箱（1）
• 有能なプロジェクトマネージャを育てるには（3）
• 有能なプロジェクトマネージャを育てるには（2）
• 有能なプロジェクトマネージャを育てるには（1）
• SOX法とコンプライアンスとIT
• リーダーシップを発揮するにはどうすれば？（後編）
• リーダーシップを発揮するにはどうすれば？（前編）
• 情報システム部は、もう役割を終えてしまったのか？
• 阪神大震災10年目に考えること、するべきこと（後編）
• 阪神大震災10年目に考えること、するべきこと（前編）
• “気付き”のコミュニケーション――機能や仕組みの説明は理解に結び付かない
• JR脱線事故からマネジメントを学ぶ
• 羽田空港の管制はなぜ止まったのか？
• IT徒然草――コストと利便性を追い求めて失うもの
• 理想的な上司と部下の関係とは――部下の育成方法
• 続・いまのIT組織でいつまでやっていきますか？
• いまのIT組織でいつまでやっていきますか？
• ITの動向や他社の状況を、気にし過ぎていませんか？
• IT化と投資の“正しい”関係とは？（後編）
• IT化と投資の“正しい”関係とは？（中編）
• IT化と投資の“正しい”関係とは？（前編）
• ブレークタイムでの話題製品と情報化のコンセプト
• “誰にでもやさしい”ITは良いことなのか？
• ブレークタイムに“設計思想”を語り合おう
• 仕事への取り組み方は最初の数カ月で決まる！
• 優秀なスタッフを育てる職場環境とは
• 全社IT最適化のカギは「データ体系の統一」