DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

長年（ってほどではないですが．．．）ＩＴ系のプロジェクトに参画して必ずどこかにＰＭＯがいるっていうくらい、組織やプロジェクトにＰＭＯを設置することが多くなりました。
ＩＴ組織の５０％以上という話もあるくらいです。

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

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

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

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

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

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

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

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

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

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

＜　前回　｜　目次　｜　次回　＞