PMは業務SE出身者が有利な3つの理由

プロジェクトマネージャ(以降PM)のプロジェクトにおける役割は、顧客との調整・折衝が中心です。

フェーズにより折衝する内容も異なりますが、管理人がプロジェクト全般を通して一番多いと感じているのが、業務仕様に関する調整・折衝ごとです。

そのため、PMに求められるスキルとして、「業務知識を保有することが必要」と考えています。

PMは業務SE出身者が有利な3つの理由について

プロジェクト全般を通した調整・折衝ごとにおいて、「一番多いと感じているのが業務仕様である」とした場合、「PMは業務SE出身者が有利ではないか」という推測ができます。

もちろん、プロジェクトの目的(ゴール)によって違いはありますが、世の中で一番多いシステム開発プロジェクトは、「業務革新がテーマ」のプロジェクトだと思うからです。

そこで管理人の観点で、業務SE出身者がPMをやるべき理由を3つ取り上げます。

理由1:一番多いシステム導入の目的は業務革新であること

「業務を革新するためにシステムを構築する」ということは、「業務をどのように革新させるのか」が最終ゴールです。しかしながら、その最終ゴールのイメージが、あいまいだったり、ちぐはぐな内容だったりすることが多く見受けられます。

一般的なシステム構築プロジェクトでは、上流工程(要件定義)にて、具体的な要件を詰めていきます。この工程では、業務改善・効率化の要件を定義していくことがメインテーマなので、ベンダー側にも「どのような方法で業務を改善できるのか」といった業務寄りの知識が求められる場合があります。

上流工程の打ち合わせでは、顧客側も上位職者の方や、業務責任者が参画する場合が多いため、PMは上位職者向けに対応する必要があります。そのとき、PMが顧客の業務内容をよくわからず、打ち合わせの場でモジモジしているのは、あまり格好良くありませんし、信頼されなくなる可能性が高いと思います。

また、結構多いパターンなのですが、顧客が業務コンサルを雇って業務革新を進めているケースです。そのときでも、ベンダー側に業務知識が不要ということはありません。むしろ、顧客+コンサルのタッグに立ち向かう必要性が出てきます。

顧客の業種に詳しいメンバーを連れて行って、対応することもありますが、最終的な決断を求められるのはPMです。このときに、決断できるだけの知識(特に業務知識)を持っていないと、顧客やコンサルたちから、厳しい状態に追い込まれてしまいます。

以上から、PMも一定レベルの業務知識を保有しておいたほうがよい、ということです。

理由2:顧客は業務以外のIT知識にあまり詳しくないこと

IT知識に詳しくないから、ITベンダーにシステム開発を依頼するということです。それ要望に答えるのが、ITのプロである、われわれITベンダーということでしょう。

すなわち、顧客は「業務視点」で物事を考えているということです。上位職者になればなるほど、それ以外のことはあまり突っ込んできません。

必然的に、話は「業務寄りの話題」になっていきます。その業務寄りの視点に対して答えていかないと、話が続かなくなることが多くなり、PMの信頼が下がっていく可能性があります。

ちなみに、現場よりの方や、情報システムの担当の方などは、テクニカルなところを攻めてきますが、上位職者の方(PMがカウンターとなる)を対応するためには、やはり一定の業務知識が求められます。

理由3:一番多いもめごとは、業務仕様に関すること

裁く

上流工程で、要件・仕様検討時に”もめる”ことが多々あります。予算・納期には制限がつきものです。予算が青天井というプロジェクトにお目にかかったことはありません。(当たり前か?)

その限られた予算・納期の中で、要件・仕様を「加えるのか」、「省くのか」の攻防をしなければならないときがあります。その場合でも、「業務として回ること」が大前提になるので、その前提の中で優先順位を付けて、要・不要を決定していかねばなりません。

その際、顧客と渡り合うのはPMです。ここでひるんでいてはいけません。しかし、渡り合うためには、正当性を主張できるバックボーン(特に業務知識)が必要です。

また、下流工程になると、PMは「仕様変更要件」に対しても裁かなければなりません。それにも業務知識が必要です。何が重要であり、重要でないかを見極めて、顧客と交渉しなければなりません。何が妥当で正しい状態なのかを知らないと、顧客に押されっぱなしになってしまいます。

内部の指導

上流工程、下流工程を問わず、トラブルが発生します。その中で致命的になるのが、「業務仕様のモレ・抜け」など、業務内容に関する問題だと、管理人は考えています。

プロジェクトメンバーである業務リーダたちが中心となって、要件・仕様を検討します。そこで決定された要件・仕様が妥当であるか、矛盾点はないか、実現性はあるか、といった観点でレビューを行いチェックするのは、最終決定者であるPMです。

業務以外の非機能要件の確認も当然ながら必要ですが、やはり中心は、機能要件(業務系)になってきます。

またPMには、要件・仕様決めをしていく段階から、矛盾点・抜け・モレを防いでいくための指導をしていく必要もあります。トラブルを未然に防ぐためです。

PMBOKガイドでは

PMBOKガイドは、IT業界に特化した内容ではありません。そのため、この記事に記載したような話題はありません。しかし、直接つながる内容ではありませんが、気になるくだりはありました。

「3.プロジェクトマネージャの役割」に「知識とスキル」という項目があります。そこで、「プロジェクトすべての役割は求められていないが、プロジェクトマネジメントの知識、技術的知識、理解、経験を有すること」と記載されています。

また、ツールと技法に「専門家の判断」がありますが、あくまでも、“専門家が下した判断を参考にする”というスタイルとなっており、最終決定を下すのはPMです。

まとめ

プロジェクトが業務システム構築を前提としています。インフラのみのプロジェクトであればその限りではないのですが、結局、インフラ増強することも、業務を効率化するなど、顧客の真の要件は業務改善であったりするので、PMはその裏の真因まで見通せる必要があります。

そう考えていくと、業務知識をバックボーンとして持っている、業務SE出身者が有利となっていくのではないでしょうか。インフラSEはどちらかというとスペシャリストの立場としてプロジェクトに参画してくケースが多いと思います。

管理人も業務SEを主としていましたので、機能要件(業務系)と非機能要件(インフラ系)どちらが得意かといえば、機能要件(業務系)です。まあ、一般的なSEとしての非機能要件系の知識も多少持ち合わせていますが、やはり専門家に頼るところが多々あります。

しかしながら、プロジェクトマネージャに求められることは多いものですね。また、少々ベンダー側の内容になってしまったことをご容赦ください。

 

PM

Posted by wpmaster