できるプロジェクトマネージャのノウハウとは？：有能プロジェクトマネージャ育成術（2）（3/3 ページ）

[大上建（株式会社プライド），＠IT]

できるPMへのインタビュー：H氏の場合

　「仮説と事実に基づく検証による障害特定」というPMノウハウを持っていたアウトソーシング事業部のH氏へのインタビューもあらためて行った。

　H氏のプロジェクトは、あるパッケージソフトのユーザー向けサポート窓口業務を受託し行っている。

　このパッケージソフトは、もともとメインフレームで稼働していたが、ユーザーからUNIX系のプラットフォームへの対応を求められ、UNIX環境への移植が行われた。その後、さらに多くの環境への対応が求められ、Windows版やWeb版などもリリースされている。使用しているDBMSの製品やバージョンの組み合わせを含めると、相当な数の世代が世に送り出されている。

　このパッケージソフトの開発・保守は、コンピュータメーカーから第1 SI事業部が受託している。かつては開発・保守を行っている第1 SI事業部がユーザーサポートも行っていた。しかし複数環境への対応に追われていることとユーザー数が急激に増えたことにより、サポートができなくなったことで、新たにサポート窓口業務をH氏のプロジェクトが受け持つことになった。

　H氏によると、ユーザーからの問い合わせ内容は、主に顧客側の設定や使用方法に関して回答すれば解決のつくものと、ソフトウェアのトラブルを原因とするソフト入れ替えやパッチ発行、回避策の回答などが必要なものに分かれるそうである。

　当初は、前者は窓口業務としてH氏のプロジェクトが、後者は開発・保守側の責任として第1 SI事業部が分担していた。しかし、開発・保守側が次第に対応できなくなり、E社に対して委託元のコンピュータメーカーが強く対応強化を迫ったそうである。

　開発・保守側プロジェクトが対応できなくなった原因は、度重なる移植や機能追加を繰り返したことによる、ソフトウェアの複雑化（構造やインターフェイスのゆがみ、ドキュメント不整合）であった。

　そこでH氏は、重大な問い合わせや障害があった場合は、開発・保守側プロジェクトも含めた主要メンバーを招集して集中検討を行うようにした。H氏はそこで行うことを「推理」と称している。「推理」とは障害原因や問題の影響範囲の仮説作りである。

　上記の経緯に始まるインタビューによってH氏から抽出されたPMノウハウは次のものである。

PMノウハウ：仮説と事実に基づく検証による障害特定
概要	障害報告の第1報を受けた時点で問題の重要性を判断し、必要な場合は障害原因に関する仮説構築と検証方法を決定する会議を開催する。仮説構築では、仮説を1つではなく考えられる限り立てる。仮説の検証方法では、最も可能性の高い仮説を裏付ける、あるいは可能性の低いいくつかの仮説を消去できるものを優先して実施するように指示している。仮説の検証に当たっては厳格に事実に基づいてのみ行い、担当者の裏付けのない報告や予測での絞り込みは行わない。このようにして早期に手戻りなく仮説の絞り込みを行う。
背景と価値	本PMノウハウを持たない一般PMでは、以下の対応しかできず問題解決に時間がかかる。 ・ 障害報告の重要性の判断が甘いため、どの障害に対してもやみくもな資源投入を行い、市場の求める優先順位での解決が図れない。またコンピュータメーカーから優先順位変更の指示を受けることになり、自プロジェクトの資源計画が狂う ・ 障害に対して原因の仮説を想定しないため、効率的に仮説数を絞り込むためのポイントとなる事実収集を指示できない。またメンバーが見当違いな調査にのめり込んでいても止められない。 ・ 担当者の思い込みによる報告を確認せずに方向性を判断するため、手戻りが多い
成功要因	（1） 障害の重要性判断の基準に関する知識充実 （2） 障害原因の仮説構築のための知識充実 （3） 検証方法の知識充実
技術・知識	（1） ユーザーの視点による本パッケージソフトの理解 （2） 障害原因の仮説構築技術 （3） 仮説を検証する優先順位を決定する技術 （4） 検証法の知識
プロセス	（1） ユーザーの適用対象業務と本パッケージソフトの価値を、ユーザーの視点で徹底的に理解し、メンバーにも周知する （2） ユーザーの価値から、本パッケージソフトに本来求められる機能構成や体系、自然な操作、期待される動作や出力を想定する （3） 本パッケージソフトの機能について、リリースされている世代の差異と共通点を整理する （4） 上記3項について、法制度や環境の変化、世代の追加や機能変更に目を配り、理解を新たにし続ける （5） 障害報告を受けた際、重要性の判断や現象の特定に必要な情報を漏らさず確認する。またユーザーの利用世代や環境設定などの情報も漏らさず確認する （6） 第1次の事実情報として、再現テストを実施させる （7） 上記2項の情報を、（1）〜（3）の事前知識に照らし合わせて障害原因の仮説を作る。仮説構築に当たっては、ソフトウェア体系や世代による機能差、ユーザーの設定環境情報、現象から考えられるだけの仮説を構築する （8） 構築された仮説を効率的に絞り込むための検証手順を設計し、事実情報収集の指示を出す （9） メンバーからの報告を、事実に基づいて確認し原因を特定する （10） 回避策があればユーザーにそれを伝え、原因を開発・保守側プロジェクトに伝達するとともに解決スケジュールの回答を求める （11） 影響する世代について、重大なものは自プロジェクトでも現象的に再現テストを行い、把握する。把握内容は上記原因と併せて開発・保守側プロジェクトに伝達する

　H氏は、本PMノウハウのほかにも、「未解決複数障害対応への最適資源配分」というPMノウハウも持っていた。

---

　できるPMへのPMノウハウの抽出に続いて、一般のPMからのPMノウハウ抽出のためのインタビューも実施した。狙いは「できるPM」と「一般PM」との差の特定のためである。単純にPMノウハウの差だけではなく多くの違いがあった。達成への執念、触発された先輩やPMノウハウを生み出した環境などさまざまである。

　次回は、一般PMと有能PMの差について解説する。

この記事に対するご意見をお寄せください

[e-mail]

著者紹介

▼大上 建（だいじょう たける）

株式会社プライド 取締役 チーフ・システム・コンサルタント

前職で上流工程を担当する中、顧客の利用部門は必ずしも「開発すること」を望んでおらず、それを前提としないスタンスの方が良いコミュニケーションを得られることに気付き、「情報の経営への最適化」を模索することのできる場を求めてプライドに入社。株式会社プライドは、1975年に米国より社名と同名のシステム開発方法論の日本企業への導入を開始して以来、これまで140社余りの企業への導入支援を通じて、情報システム部門の独立自尊の努力を間近に見てきた。

http://www.naska.co.jp/

「有能プロジェクトマネージャ育成術」バックナンバー

• 組織的、総合的に“できるPM”を育成する方法
• できるPMのノウハウを形式知化する“メソドロジ”
• 「できるPM」と「それなりPM」との差とは？
• できるプロジェクトマネージャのノウハウとは？
• ハイ・パフォーマーの“知”は、移転・共有できるか？