できるプロジェクトマネージャのノウハウとは？：有能プロジェクトマネージャ育成術（2）（3/3 ページ）
ITプロジェクト推進などで最も普遍的な課題に「有能者の不足」がある。通常、移転・共有できないと思われている有能者の知恵・能力も記述可能だ。今回は、独立系SI企業“E社”を舞台に、有能者から抽出されたPMノウハウがどのようなものか、見ていこう。
できるPMへのインタビュー：H氏の場合
「仮説と事実に基づく検証による障害特定」というPMノウハウを持っていたアウトソーシング事業部のH氏へのインタビューもあらためて行った。
H氏のプロジェクトは、あるパッケージソフトのユーザー向けサポート窓口業務を受託し行っている。
このパッケージソフトは、もともとメインフレームで稼働していたが、ユーザーからUNIX系のプラットフォームへの対応を求められ、UNIX環境への移植が行われた。その後、さらに多くの環境への対応が求められ、Windows版やWeb版などもリリースされている。使用しているDBMSの製品やバージョンの組み合わせを含めると、相当な数の世代が世に送り出されている。
このパッケージソフトの開発・保守は、コンピュータメーカーから第1 SI事業部が受託している。かつては開発・保守を行っている第1 SI事業部がユーザーサポートも行っていた。しかし複数環境への対応に追われていることとユーザー数が急激に増えたことにより、サポートができなくなったことで、新たにサポート窓口業務をH氏のプロジェクトが受け持つことになった。
H氏によると、ユーザーからの問い合わせ内容は、主に顧客側の設定や使用方法に関して回答すれば解決のつくものと、ソフトウェアのトラブルを原因とするソフト入れ替えやパッチ発行、回避策の回答などが必要なものに分かれるそうである。
当初は、前者は窓口業務としてH氏のプロジェクトが、後者は開発・保守側の責任として第1 SI事業部が分担していた。しかし、開発・保守側が次第に対応できなくなり、E社に対して委託元のコンピュータメーカーが強く対応強化を迫ったそうである。
開発・保守側プロジェクトが対応できなくなった原因は、度重なる移植や機能追加を繰り返したことによる、ソフトウェアの複雑化（構造やインターフェイスのゆがみ、ドキュメント不整合）であった。
そこでH氏は、重大な問い合わせや障害があった場合は、開発・保守側プロジェクトも含めた主要メンバーを招集して集中検討を行うようにした。H氏はそこで行うことを「推理」と称している。「推理」とは障害原因や問題の影響範囲の仮説作りである。
上記の経緯に始まるインタビューによってH氏から抽出されたPMノウハウは次のものである。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
H氏は、本PMノウハウのほかにも、「未解決複数障害対応への最適資源配分」というPMノウハウも持っていた。
できるPMへのPMノウハウの抽出に続いて、一般のPMからのPMノウハウ抽出のためのインタビューも実施した。狙いは「できるPM」と「一般PM」との差の特定のためである。単純にPMノウハウの差だけではなく多くの違いがあった。達成への執念、触発された先輩やPMノウハウを生み出した環境などさまざまである。
次回は、一般PMと有能PMの差について解説する。
この記事に対するご意見をお寄せください
managemail@atmarkit.co.jp
著者紹介
▼大上 建（だいじょう たける）
株式会社プライド 取締役 チーフ・システム・コンサルタント
前職で上流工程を担当する中、顧客の利用部門は必ずしも「開発すること」を望んでおらず、それを前提としないスタンスの方が良いコミュニケーションを得られることに気付き、「情報の経営への最適化」を模索することのできる場を求めてプライドに入社。株式会社プライドは、1975年に米国より社名と同名のシステム開発方法論の日本企業への導入を開始して以来、これまで140社余りの企業への導入支援を通じて、情報システム部門の独立自尊の努力を間近に見てきた。
Copyright © ITmedia, Inc. All Rights Reserved.