 |
|
「専門家の判断」 イデオ・アクト株式会社 代表取締役 葉山 博昭 ： 12月号
――― PMマイスター ――― 今年からPMAJでは、PMマイスターを認定する制度を始めました。認定されたPMマイスターはPMAJにて「私の経験則」という講演を行い、講演は参加者からの質問を主として行われ、PMマイスターの経験・スキル・ノウハウをPMの推進へのヒントとなるように進められます。来年度も引き続き同様の活動を行う予定としています。又個別の相談にも応じることを考えています。筆者もオンラインジャーナルの読者、PMAJのご関係者の推薦により、このPMマイスターの末席に加えていただきました。 筆者はPMAJではPM研究・研修部会で、PMBOK®試験対応講座、PMBOK®基礎講座を長らく担当させていただいてきましたが、今回PMマイスターに認定されたこともあり、PMBOK®教育からPMマスターの活動を通して、PMの経験を後進に語ることに活動の軸足を移すこととしました。PMに関係することで最近気になっていることを今回書かせていただき、PM研究・研修部会員としての最後の活動といたします。 ――― 専門家、第三者に・・・を委ねる ――― 最近何か問題が発生すると、その評価を第三者の専門家に委ねるということがよくマスコミに載ります。例えば今揉めている東京都の新市場問題でも、なぜあのような状態になってしまったのか、第三者により原因を探るというようなことです。第三者に評価を委ねると、「当事者によらずその利害に関係しない第三者に委ねると、公正で正しい判断が出てくる」とマスコミの発信者、読者も簡単に思い込んでいるようです。第三者の専門家が判断すれば正しい結論が得られるのでしょうか？筆者がプロジェクトの現場でプロジェクト・マネジメントの指導を行ってきた経験からすると、何か不都合なことが起きた場合、その原因を短時間で判断出来るのは現場のプロジェクト・マネジャーであって、第三者の専門家であったことはなかったように思います。しっかりしたプロジェクト・マネジャーとは、第三者の専門家などに頼らなくても原因が究明出来、対応が出来るべきものと思ってきました。又そのように行動出来るよう、IT業界では業務知識、技術知識、プロジェクト・マネジメント知識がプロフェッショナルなレベルになっていることが常に要求され、そのようになるよう努力してきたように思います。 ――― 専門家は予知出来るか？ ――― 自然災害、人為的災害が発生したりすると、なぜ専門家は予知できなかったのか、原因は何かとマスコミは拙速に答えを求めます。何か不都合なことが起きると、すぐ原因が分かり、発生することが予知出来るものと思いこんでいる科学的センスの無いマスコミ登場者が数多く偉そうに跋扈しています。特に自然災害ではその発生は予知出来ないにも関わらず、マスコミのインタビューを受ける専門家はその分野の研究費を予算化している関係者が多く、予知出来ないとはっきり言う専門家は少ない。予知と観測は異なり現状の観測を精緻に行ったから正確に予知出来るとは言えず、予知出来ないから現状の観測の予算を減らすのは間違いだが、予知への期待が萎むと観測の予算も減らしてしまうことは多い、火山の噴火などでは、発生するとなぜ予知できなかったのかと言う割に、観測に対する予算は少なく、観測対象の少なさには驚かされる。人智が及ばない自然の摂理が存在することに畏敬の念を持ち、真摯に自然の摂理を徐々に解明し、災害が発生した場合の対応を研究する必要があります。簡単に、原因は？予知は？と問う人間は、なんでも何か発生すると、簡単に原因が分かり、必ず予知が出来ると思いこんでいるのだろう、そのような人間は科学技術を研究する難しさを理解出来ていないのであろう。簡単に原因、予知が出来ないと認識して初めて科学技術を深く研究出来るのではないだろうか。簡単に原因、予知が出来ると思っていては深い研究は出来ない。科学的センスが良いか悪いかはこのへんの感覚の違いではないだろうか、理系、文系の出身ではなくこの科学的センスの違いが重要で、最近のマスコミを見ているとこの科学的センスが悪い発言が非常に多くなっているように思える。簡単に原因、予知はという人間の増加は、科学技術に携わる人間の質の低下と減少を招くのではないかと非常に危惧している。科学技術の探求の難しさを認識する人間を増やすことが科学技術の進歩では重要ではないでしょうか。 ――― PMBOK®での「専門家の判断」 ――― 一般的な話ではなく、PMBOK®のツールと技法では「専門家の判断」はどのようになっているでしょうか？ 第3版 14か所(42か所) 第5版 28か所(47か所) と第3版から第5版になり間にほぼ倍増しているのです。プロセス数自体も増えていることもその原因の一つですが、「プロジェクト・マネジメント計画書作成」のように3版ではツールと技法の中で3個中3位にあったものが5版では2個中の1番目になるという変化もあります。PMBOK®ではツールと技法の上位に書いてあるから重要とは言っていないのですが、一般的には箇条書きの上位は重要というのが作文上のルールとは思います。数とその位置から「専門家の判断」がPMBOK®ではより重要さを増してきたと筆者は感じています。又筆者もプロジェクト・マネジメントのコンサルティングの現場では、専門的に明るくないことで問題が発生することがよくあり、その都度専門家の判断を得るようにと指導した経験がありました。そういう意味ではPMBOK®はPMの現場を着実に反映し、PMBOK®は現場で発生していることとは遊離していない良いものだと思ってきました。しかしPMBOK®が3版から5版となった結果を改めて見ると、そうなんでも専門家の判断を頼りにしたのでは、プロジェクト・マネジャーさん、もう少し気概を持ってしっかりしてくれよと言いたくなってしまいます。またPMBOK®の記述に忠実にプロジェクト・マネジメントを行おうとするとあまりにも多く専門家の判断を仰ぐことがあり、専門家が常日頃プロジェクトに居るわけではないので、そう度々専門家の判断を仰ぐのは現実的ではないようにも思います。ツールと技法に個別に専門家の判断を埋め込むよりも、専門家の判断が必要な状況とその必要性をツールと技法ではない方法で記述することは考えられないものでしょうか？ ――― PMBOK®の状況、昨今の第三者の専門家を求める風潮 ――― このPMBOK®の状況と、昨今ニュース等で第三者の専門家に云々が増えていることになんらかの関係はないでしょうか？どうも当事者能力が低下しているか、専門的に難しいことが増えていることが原因となっていることもあるかも知れません。専門家の意見を聞くべき時に聞かず、不具合が発生してから、責任逃れの為か、専門家の判断を求めているようにも見えます。特に技術的に難しい問題解決では、技術的専門程度の高い当事者とマネジメント層との間で良好なコミュニケーションを取ることが非常に難しく、技術的専門家の言うことが正確に評価出来ずマネジメント層が誤った判断をしてしまうことは昔からよく目にしました。特に行政では行政判断をする高級事務官は数年おきに担当部署が変わり、専門的知識が醸成出来ない環境があるため、技術的専門性が高く求められる行政判断では祖専門家と行政官とのコミュニケーションは難しかった。だからこそ技術的専門家はマネジメント層が判断を誤らないよう、マネジメント層の代行を行える位に業務に精通するよう努力したものです。一方専門的技術のないトップマネジメントも技術的重要性を認識できるよう努力したものです。最近ではこのように振る舞うことが出来る技術的専門家やトップマネジメント層が減ってしまったように思います。何か問題が発生すると、簡単に第三者の専門家に判断を求めたり、PMBOK®での専門家の判断が増えたことに繋がっているのではないでしょうか。東京の新市場問題でも跡地利用で2mの土で全体を覆ってしまったら、その上に構造物は建設出来ないではないでしょうか。何を建設するにも基礎を打たなければならず、覆った土をいじることになり2mの土で被覆することは困難になってしまいます。2mの被覆で覆うことは構造物の建設を不可とする判断であり、そこに新市場を建設すると決めたこととは全く相矛盾した判断で両立しないのです。空洞を作ったり、小手先のことで解決しようとしても解決はしないものでしょう。2mで被覆すると決めた専門家と新市場を建設すると決めた行政官とに全くコミュニケーションが成り立っていなかった証左ではないでしょうか？建設してしまってから専門家に意見を求めても無駄なことは言うまでもありません。2mの被覆が必要と決めた専門家と、新市場建設を決めた行政官が直接対話し、都政を預かる政治家がどう対応するか決めるべきことで、いまさら第三者の専門家に何かを託しても全く無駄です、筆者は最近このようなことがよく発生するので、何かが発生してから第三者の専門家に何かを託すことに疑いを持っています。 ――― システム開発の現場では？ ――― システム開発の現場では、顧客からのヒアリングのまま実現したので、設計者側の責任ではないという発言を最近はよく耳にします。昔はよかったみたいな発言はしたくないのですが、顧客側の言うことをSEとして咀嚼しシステム・エンジニアの判断を加えシステム化するのがプロの行う設計であって、顧客の言うままにシステムを作るのは、本来あるべきシステム・エンジニアの仕事ではないと言われています。このような話をすると若い方からは昔ほどシステムは簡単ではないのですよと言われてしまい、反論できない上司が多いのですが、そんなことはないのです。現実のコンサル先で設計書を見ることがよくありますが、箇条書きがせいぜいで、表現力が稚拙で顧客を説得も出来ず、次工程のSEの設計の役にもたたない、何を書いてあるのか分からない設計書だかなんだか分からないものが溢れています。年長者、マネジメント層はもう少し現場の設計書を読み、適切に指導すれば設計者の意思を顧客に分からせお互い納得の行く仕事が出来るものです。しかしこのような指導が出来る社内のマネジメント層、PMO、PMの支援を依頼しているコンサルが極めて少ないことも事実です、これがITのプロジェクトのトラブルが減らない原因の一つではあるとは思います。 話は若干それてしまいましたが、まったく専門家の判断を得ずに自己中心的にプロジェクトを進めるよりは適切に専門家の判断を得ることは必要ですが、あまりにもプロジェクトに携わる者としてのプロ意識を欠如した状態でプロジェクトをマネジメントするのは問題ではないでしょうか？ ――― システム開発の現場での専門家活用例？ ――― これは専門家の意見を聞かないで大事になりそうになった例ですが、あるシステム開発でExcelのグラフ表示機能をし、円グラフを表示しようとすると、色がExcelの標準機能で自動的に選ばれてしまい、使用者の好きには出来ないということが発生した。顧客からの要望はリスクの高いものを赤から順に安全なものを青にして欲しいと要望されたものであった。現場ではその標準機能から変更出来るかの可能性を評価出来ず、顧客の要望を聞きそうになってしまった。そこで専門家であるメーカーにその可能性を問い合わせたところ、そのように変更することは現状でも先行きで可能性はないと返事があり、顧客に対してその旨を伝えると、変えるための費用は負担するのでなんとかして欲しいとの要望が出されたが、またしてもメーカーから拒絶された。費用は負担するので請け負ったプロジェクトでなんとかして欲しいと要望が出されたが、Excelの一部を開発するようなもので、請負プロジェクトでは開発の可否を判断することは出来ない旨本社技術部門が回答した。変更委員会で否決され事なきを得たが、現場で顧客の要望だからと安易に要望を受け入れてはならない例であった。(標準機能の代替ソフト作成は何億も費用を要することになるものであったが、このようにして本体の開発より多額の費用を発生させてしまう例はシステム開発ではままある。) ――― 最後に ―――
以上
|
 |