検索
連載

できるPMのノウハウを形式知化する“メソドロジ”有能プロジェクトマネージャ育成術(4)(2/2 ページ)

E社で進められている、有能なプロジェクトマネージャ(PM)からPMノウハウを移植するプロジェクト(以下、プロジェクトHK)では、有能PM、一般PMへのインタビューを経て、PMノウハウが抽出され、いよいよこれをメソドロジ化していくことになった

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

メソドロジ化されたPMノウハウのレビュー

 コンサルタントは「仮説と事実に基づく検証による障害特定」のメソドロジ(プロトタイプ)を作成すると、各事業部の会議の場を借りて、全PMを対象にそのレビューを行った。

コンサルタント 「いまお配りした資料(全ページ図1〜3)は、貴社のあるPMの方が実践されているPMノウハウをメソドロジの形にしたものです。メソドロジは日本語で方法論と呼ばれますが、単なる方法とは違います。メソドロジとは、ある目的や狙いを達成するために、それをうまくやるためのコンセプト(概念)、メソッド(方法)、プロセス(手順)、ツールの一連のシステム(関連する組み合わせ)のことです」

 とコンサルタントは、詳しくメソドロジの説明(「差の正体はメソドロジ」連載第1回)をしてから、レビューを始めた。

コンサルタント 「本メソドロジの説明は以上ですが、本日皆さんに評価いただきたいのは、仮に皆さんが同様の状況のPMの立場に置かれた場合を想定して、このメソドロジが使えるものなのかどうかです。いかがでしょうか」

P氏 「私はPといいます。私のプロジェクトは、パッケージソフトではありませんが、ある生命保険会社の営業員向けモバイルPCソフトの保守を担当しています。ハードウェアの世代に制約されてソフトにもいくつかの世代があり、営業員の訪問先でいろいろなトラブルが起きています。このPMノウハウの背景の状況と比較的似ていると思います。自分たちなりにやり方を改善してきましたが、顧客からも一層の改善を要求されています。このメソドロジはかなりの部分でそのまま私のプロジェクトに適用できると思います」

コンサルタント 「このメソドロジのどこの部分があなたのプロジェクトに参考になりますか」

P氏 「全体的に参考になりますが、特に原因特定と障害の解決を分けて考えて、それぞれ実施の計画を立てていたところです」

コンサルタント 「そうですね。何らかのトラブルに対応する必要があり、かつトラブル対応を行うプロジェクト資源を振り向ける優先順位付けをうまく行う必要のある場合には、このメソドロジはかなり参考になると思います」「逆に参考にできないとか、このままではうまく使えないと思われる部分はありませんでしたか」

P氏 「拝見した各作業TASK説明書(図3)ですが、一部はやはりこのPMノウハウ固有のものか、あるいは私のプロジェクトの固有性とは異なるように感じました。具体的には、障害原因仮説の検証手順を検討するワークシートですが、私のプロジェクトではこれほど複雑なものはいりません」

コンサルタント 「なるほど。メソドロジのコンセプトは合っており、プロセスである作業手順も概ね合っているが、一部のワークシートなどのツールが適合していない、ということですね」

P氏 「そのとおりです」

ALT
メソドロジの構造

コンサルタント 「メソドロジの構造を思い出していただきたいのですが、コンセプトはメソッド(方法)やツールを規定するものではありません」

「ご指摘のワークシートは、メソドロジの上位に位置するコンセプト、メソッド、プロセスから、あなたのプロジェクトに最適な形に再展開、つまり作り直せばよいということです。このような部分はほかにも障害情報の収集のための視点とか、障害仮説の構築方法などの詳細な部分とかがあります」

「また、同じプロジェクトであっても常に環境は変化しているので、目的や狙いを達成するためには常に適合させ続けることが必要です。このような場合にやり方をどのようにすればよいのかを考える上で、メソドロジの構造は私たちに大きな示唆を与えてくれるのです」

P氏 「よく分かりました。そう考えるとほかにも、障害状況を最初に十分聞きだす部分や、立てた仮説の検証を事実に基づいて行う部分について、その徹底度合いが私のプロジェクトとは随分違うなあと感じました。決して私たちもいい加減にやっているつもりはないのですが、このPMノウハウとは水準の違いを感じました」

コンサルタント 「このPMノウハウの持ち主の方にインタビューしていた中で聞いた話ですが、もともとはここまで徹底して事実に基づいた検証をしていた訳ではなかったそうです。しかし滞留している障害件数が60件を超えた段階で、本質的な対策を打たなくてはならないと決意し、このPMノウハウを生み出したそうです」

「やはり優れたPMノウハウは、自らが矢面に立ってギリギリの状況の中で、それを打破しようとする執着心があって始めて生み出されるのでしょうね」

 P氏との質疑応答に続いて、ほかの一般PMともやりとりが行われた。彼らの反応はおおむね良好であり、これがあれば有能PMと同等レベルは困難であっても、ある程度は手を動かせると答えた。

 そこでプロジェクトKHでは、続けていくつかのPMノウハウをメソドロジの形にし、一般PMを含めたリーダー層までを対象にメソドロジの教育を行うことにした。

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

managemail@atmarkit.co.jp


著者紹介

▼大上 建(だいじょう たける)

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

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

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


前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る