 |
|
「第170回例会」報告 PMAJ 例会部会 原 宣男： 3月号
【データ】
今回は、プロジェクト管理のソフトウェアパッケージを開発し、自社のプロジェクトに適用した事例をシステムインテグレータ社梅田社長に、パッケージのユーザ側の事例をエフ・シー・エス社の藤本社長に、それぞれのお立場からプロジェクト管理を円滑に行うキーポイントについてご講演頂きました。 梅田講師のスピーチ：「PM支援のためのツールの活用と浸透の方法」 自社開発の「SI Object Browser PM」(以降、OBPMと記す。)をベースにプロジェクト管理を徹底された経験をもとに、プロジェクト徹底の要素は、理論とツールと体制であると講師は以下の通り説いています。 組織のプロジェクト管理を徹底するための3要素 組織のプロジェクト管理を徹底するためには何が大切なことは、まずプロジェクト管理に関する知識と意識を高めること、つまり理論が大事です。しかしこれだけではだめで、プロジェクトを管理する仕組み、すなわちツールがないといけません。さらにこれだけでは浸透しないので、組織全体に普及・浸透させる体制が重要です。これら三つのトライアングルが揃うとうまくいきます。 次に実際にプロジェクト管理をうまく行っていくためのポイントを5つ紹介します。 ポイント1：体制および役割の明確化 プロジェクト管理を浸透させるポイントのひとつは体制と役割の明確化です。現在そこそこの企業ではPMOをおいていますが、PMOと部門の力関係、即ち、部門がPMOの言うことにきちんと耳を傾けることが必要で、いかに経営層がPMOをバックアップするかということが重要となります。つまりPMOの位置づけが重要です。 当社(システムインテグレータ社)は従業員120名で、当初PMOは2名でしたが、体制に慣れてきたので、現在は1名とし、各部門にPMO委員を配置しています。これがうまく機能しています。 ここでPMOには三つの役割を課しています。 一つ目はマネジメント方法を標準化することです。各部門のマネジメントを統一しないと、集中管理できないし、管理精度も上がらない。ただ、標準化はPMOがひとりでやるのは大変であり、またPMOだけでは標準は作れない。むしろPMOは標準を作るのではなく、後押しをする役目です。あと、標準を施行して一年経過したらそれを見直しさせる。これがとても重要です。 二つ目は運用推進。プロジェクト管理をまじめにやっていない部門を見つけ、警告すること。警告が無視されたら経営層へ報告する。 三つ目は不採算プロジェクトの早期発見です。PMOがプロジェクトの外側からWATCHし、部門長や経営層に報告、問題解決を全社レベルで検討することです。 組織としてやることは、PMOの活動をWBSにしてそのタスクを明確にすること、PMOの活動をどう管理、フォローするか決めること、そしてPMOの活動成果を何で評価するかを決めることです。 ポイント2：浸透・普及作業のプロジェクト化(普及プロジェクト自体をOBPMで管理) 当社ではPMOの活動をOBPM上ひとつのプロジェクトとして登録し、PMOのWBSをガントチャートに入れて管理しています。WBSの一番下を部門にして、各部門がどこまでやっているかを見えるようにし、これを情報共有する。きちんとビジネスライクでやることが重要です。 ポイント3：運用ルールの明確化と監視 スケジュールを立てるのがルールになっていますが、これがなかなか浸透しない。ルールは「原則行う」ではダメ。行うことを必須とし、違反者に笛を吹けるようにすることが大事です。運用ルールを明確化し、実行できない時は理由を聞くのです。尚、受注金額で運用ルールを決めるようにしないと、現場が納得せずそっぽを向きます。 当社の場合、運用ルールはOBPM上(社内ポータル)で情報共有し、ラーニングシステム上でルールの問題を出題し、リマインドさせています。 それでも浸透しない部門があるので、ルール違反を取り締まる。つまりルール違反を指摘しています。そして違反したプロジェクトリーダに、リストにコメントを記入させ返却させています。それを必要に応じて経営層まで報告しています。 そうすると、濁った水が次第に澄んでくるのですが、実は意外とインチキしていたことがわかりました。WBSの計画工数にすべて「1」を入れていたのです。これではまずいので、「血祭りプロジェクト」として、毎週一回、実行予算の大きなプロジェクトから順番にチェックすることにしました。PMOと社長が報告書をチェックするのですが、その結果を全部門の部長、マネージャに送付し、「他の部門もチェックのこと。」と一言書いておきます。これは効果が大きかった。PMOのタスクにOBPMのメンテナンスを入れ、数値化して報告させるため、ウソが付けないし、進捗も履歴で見ることができるからです。 ポイント4：問題プロジェクトの早期発見、早期対策 問題プロジェクトの早期発見、早期対策には「ツール」＋「運用のしくみ」がうまくいきます。失敗プロジェクトの場合には原因を書く欄があり、これを利用しています。 ポイント5：日々の業務の中で共有する場を持つ 現場が「やらされ」感を持っていたらモチベーションが下がってしまう為、何のためにプロジェクト管理をするかを理解させる必要があります。理解が深まれば、自分が登録しないと意味が無いことが意識されるようになります。全員の負荷状況を情報共有すると、誰が閑かわかるようになります。 藤本講師のスピーチ：「成果のあがるプロジェクトマネジメント」 講師はOBPMを利用してプロジェクト管理を実現した体験を以下に語られています。 私は、プロダクツ、SE、営業、マネジメント、そして社長を経験しています。 入社20年目で先代社長(創業者)から急遽事業を継承しました。社長になって初めて会社に大きな負債があることがわかり、まずはできるだけ早く借金を返そうと思いました。 そこで最初に人材を集めました。そして、採用した社員に未来を与える必要があり、商談に走り回りました。経営危機の時に、借金をしてシステム(OBPM)を導入しました。 プロジェクト管理で成果を上げるためには、いかに運用をうまく回すかが課題です。社員はなかなか言うことを聞きませんが、それぞれの自分のレベルはわかっています。社員に話をするのは、「山火事を消すのに消火器を使ってもしょうがない(埒が明かない)」ということ。設計レベルで解決すべきものを、プログラムレベルで解決しようとすると工数がかかってしまう。営業レベルで解決すべきものを、プログラムレベルで解決しようとすると、その工数は天文学的な数字になってしまう。社員にはレベルの違いがあり、その対処も違うということを認識させる必要があります。 瑕疵対応で予算をオーバーしたことがありました。そこで感じたことはお客様も仕様がわかっていなかったのではないかということ。なぜなら、瑕疵が発見されたのは本番がスタートしてから、かなり時間が経ってからであったからです。 最近、お客様自身がわからないものを一緒に考えていくことが多いです。この場合、開発は従来型(ウォーターフロー型)ではうまくいかず、アジャイル型にする必要があります。 失敗の防止策としてはステアリングコミッティをつくることです。範囲、コスト、納期にどう影響を与えるのか、各層ごとに検証します。特に営業レベルは重要。社員教育を経営者教育として教えており、毎年経営計画を書かせています。適正利益はお客様のため。そうでないとかえってお客様に不利益になります。 また、いかにいろいろなレベルの人が気持ち良く作業できるかがポイントで、それぞれの成績管理をきちんと行うことが重要です。 OBPMは営業管理とSE管理に関してよく出来ています。例えば、SEは計画に対してどうであったかを評価します。利益を出すのは当たり前、併せて新しいものに取り組んだかで評価しています。そうしないと、できる人だけを(自部門に)連れてくる人がいるからです。 情報公開は大事です。BS(バランスシート)とPL(損益計算書)を公開しています。重要なのは日々の積み重ね。成果にフォーカスさせ、報酬とリンクさせることです。 成果を上げるには、4つの報酬、①時間：休暇、②給与：昇給、賞与、③仕事：希望する仕事や職種、④認知：表彰、を与えることです。 あと、職場環境に配慮することも大事です。自社内では全員「さん」付けでオフィスはフリーアドレスにしています。 質疑応答： MSプロジェクトとOBPMはどうちがうか？ →MSプロジェクトは、恐らく素人が作っています。こちらはERPを作ってきた経験を盛り込んでいます。PMBOKやP2Mの要素も入っています。立場により、いろいろな見方ができるようになっています。又、経営者が作っています。(梅田講師) PMOと部門メンバーの間で不平不満でぶつからないか？ →最初はぶつかりましたが、最近のPMOは部門と仲良くやっています。やはり人によるところが大きいようです。(梅田講師) 所感： 比較的規模の小さい企業でのOBPMを利用したプロジェクト管理の要点を、両講師にわかり易くご説明頂きました。時間の関係から失敗談や泥臭いところがあまりお聞きできなかったのですが、ソフトウェアハウスの苦悩が感じられ、又得るものがある良いご講演でした。 以上
|
 |