ホーム > ブログ > 関和美の記事一覧 > 【第20回】 PMOを設置してみませんか?


【第20回】 PMOを設置してみませんか?

Pocket

< 前回 | 目次 | 次回 >

長年(ってほどではないですが...)IT系のプロジェクトに参画して必ずどこかにPMOがいるっていうくらい、組織やプロジェクトにPMOを設置することが多くなりました。
IT組織の50%以上という話もあるくらいです。

自分の会社の同じ組織にPMOができた。
お客様先にPMOがある。
隣のプロジェクトにPMOがいる。
等々

弊社のお客様は多くが大企業です。組織が大きい、プロジェクトが大きいということがほとんどです。ですので、直接関わらないまでもどこかでPMOがいるって聞きます。大きなプロジェクトでは何等か問題を抱えPMOを設置しなければならない状況に追い込まれたのでしょう。

ただ、中小の組織やプロジェクトではPMOがないことは多いと思います。
ある会社の幹部の方から聞いたお話です。
その会社は社員50名の中小企業で、SaaS型でお客様にサービスを提供しているIT企業です。SaaSのアプリケーションソフトウェアは当初2、3名で作り基本機能でサービス提供を開始したそうです。

その後、契約ユーザ数が増えるにつれ、
「○○機能が欲しい」
「△△検索は使いにくいためXX検索も出来るようにしてほしい」
「□□機能があったら契約するのになぁ」
とお客様にいわれその度に機能追加や改修を行ったそうです。

そのような開発を数年続けた結果。沢山の問題が表面化したそうです。

  • 機能追加をすると不具合が多発する。既存部分の不具合も見つかる。
    設計書がなく、初期開発担当も外れ、追加開発・改修の影響がわからなくなっているようです。 また、コーディング規約等ないまま好き勝手に開発したためソースはぐじゃぐじゃだそうです。
  • ユーザ数が増えるにつれ性能が著しく劣化する。
    データベースに詳しいメンバーがいなかったため、SQLがぐちゃぐちゃになっていたそうです。
  • リリースした後「使えない」とのクレームが毎回発生する。
    これはリリース手順書を作っていない、リリースのリハーサルを実施していないためだそうです。

おー、大変な事態です。
でも同じようなプロジェクトはあるのではないでしょうか?
特に自社で開発したものというのは、「とりあえず作ってみよう」と1人もしくは数人で開発し、それが売れたので機能拡張するということってありますよね。
でもシステムが大きくなるにつれ問題が表面化してくるのです。

この企業は2段階で対応を考えていくそうです。
まずは、現システムの不具合を洗い出すために、試験のやり直し、ボトルネックになっているデータベースアクセス部分を出来る範囲で見直し、システムリソースの増強、リリース手順書の作成・レビュー・リハーサルの定着を行いました。

そして、近い将来アプリケーションソフトウェアのリプレースを行うため、アーキテクチャ検討、プロジェクト・開発標準の作成が出来るメンバーを集めていらっしゃいます。
まさにPMOに要求されることですね。
同じような悩みに直面している方の是非参考にしてくださいね。

*****
自分に合ったもの、似合うものを見つけるのは難しいですね。今でも買い物するときちょっとした色の違いでう~んって悩んじゃいます。
そういえば先日無人の車が走っていたのでギョってしたのですが、小さいオジサマが大きな車を運転していたので座高が足りず...頭しか見えませんでした。アブナイなぁ。
それも結構なお年のオジサマ。自分に合ったものを見つけることができるようになるって年齢じゃないのね。

< 前回 | 目次 | 次回 >

Pocket

| 目次

Profileプロフィール

関和美
関和美
奈良女子大学 理学部 物理学科(現 物理科学科)卒業 日本電信電話株式会社に入社(NTT分社化によりエヌ・ティ・ティ・コミュニケーションズ株式会社に転籍)。主に金融系のSEとしてNWシステム 構築の設計、アプリケーション開発の要件定義、設計工程を経験し、その後プロジェクトマネジャーとしてプロジェクトに携わる。 2007年より現職。大規模プロジェクトにおけるPMO(Project Management Office)の運営およびプロジェクトマネジメント支援や、IT構想企画の支援を行っている。PMP。

Recent Entries最近の記事

このページのトップへ