編集部からのお知らせ
「半導体動向」記事まとめ
「リスキリング」に関する記事まとめ
「プロジェクトマネジメント」の解き方

プロジェクトを「丸投げ」できない理由(後編)--企業とSIの理想の関係 - (page 3)

小室貴史(シグマクシス)

2016-01-21 07:00

PMOの活用は、なるべく早期から

 では、PMOはプロジェクトのどのタイミングから起動させればいいのだろうか。われわれがPMOを担う場合には、遅くとも要件定義工程の後半か、設計工程の前半には参画している状態でいる必要がある、とクライアントには伝えている。その理由は、大きくは以下の2つだ。

理由(1)下流で顕在化するトラブルの多くは、上流で仕込まれている

 プロジェクトにおける問題は、開発やテストなど下流工程で一気に噴出することが多いが、その原因の多くは要件定義や設計工程にある。検討スコープが漏れていた、要件定義が甘かった、ユーザー企業のキーマンの認識ギャップなどである。

 よって、上流工程でそれらのリスクの芽が摘まれている必要がある。

理由(2)プロジェクト体制や契約形態が固まってからの軌道修正は困難

 詳細設計・内部設計が始まり、開発工程まで進んでしまうと、SI側の体制変更や調整が難しくなり、顕在化した問題を解決するための労力が倍増する。たとえば、要件定義の甘さが原因で下流の問題が発覚したケースを想定して考えてみよう。

 上流にさかのぼってのリカバリーも含めると、体制の強化やスケジュールの調整が必要となるわけだが、開発工程は、開発ボリュームや納期が契約上明記された請負契約になっていることが多く、単純にその変更だけで時間と工数が費やされていく。

 また、ボリュームが大きいプロジェクトの開発では、投入人数がピークを迎える時期にあたり、参加している開発会社の数が最も多くなる。ここで計画と体制を調整することは、元締め側のSIとしても相当タフな作業になると同時に、リカバリーのための適材を見つけようにも空いていないという問題も起きやすい。

 そもそも、プロジェクトの体制構築にあたっても、特定領域に強みを持つSIには、無理やり広い範囲の作業を担当してもらうよりも、得意作業に集中してもらった方がプロジェクトの成功につながる。PMOならばプロジェクトの本格稼働を前に、適材適所のアサインメントを、全体を見渡しながら実施できる。SIから一部管理業務や作業を巻き取ることで、各社に自身の強みに集中してもらうことも可能だ。

システム構築プロジェクト、トラブルの芽は前工程にある
システム構築プロジェクト、トラブルの芽は前工程にある

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

ホワイトペーパー

新着

ランキング

  1. クラウド基盤

    あまり知られていない“クラウド導入の現情”─業界人が本音で語る!

  2. セキュリティ

    サイバーセキュリティ施策の鍵を握る制御システム(OT)とITの統合、そのポイントと対策を解説

  3. 運用管理

    ダッシュボードは時代遅れ、最新クラウド分析で誰にでもパーソナライズされたインサイトを提供する方法

  4. 開発

    日本のコンテナ/Kubernetes環境の本番活用が遅れる理由を2つの調査結果分析から考察

  5. 経営

    いまさら聞けないクラウドインフラの基本ー初級技術書の定番 IaaS for dummies公開中

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]