2020年2月10日

【失敗しないシステム導入】

～タイトなスケジュールのプロジェクトへの対策とは？～

システム開発プロジェクトを進めるにあたり、適切なスケジュールを立てることはプロジェクト成功への第一歩です。そのために企画フェーズで目的、スコープ、体制、マスタスケジュールを明確にし、企画に基づいてスケジュールを詳細化するといったプロセスを踏んでいきます。とは言え、発注側の都合でタイトなスケジュールになってしまうことも多々あります。例えば、当初は想定していなかった制約、要件が判明し、ベンダ選定をやり直したため、プロジェクト開始が遅れたが、システムリリース時期は変えられない等の理由です。

タイトなスケジュールのプロジェクトでは以下のようなことが起こります。

〇ベンダ側がシステム開発するのに手一杯になり、進捗会議が省略される、スケジュール、課題一覧が適宜更新されないなどプロジェクト管理が疎かになる。

〇発注側の都合でタイトなスケジュールになっているので、プロジェクト管理が疎かになっていたり、遅延が発生していたりしても対等な関係でベンダに指摘できない（下手に出ざるを得ない、もしくは馴れ合いになってしまう）。

〇発注側のタスク（資料提供、要件決定、レビュ、ユーザテスト）をこなしきれず、発注側がボトルネックとなり、スケジュールが遅延する。もしくはスケジュールを守ることだけが優先され、発注側の作業品質が低下する。

これらに対応するために、発注側では以下の対応が必要になります。

▶どんなにスケジュールがタイトでも進捗会議は必ず開催し、スケジュール、課題一覧など最低限の資料に絞ってプロジェクト管理を実施する。設計・開発とプロジェクト管理は必ず別の人に担当してもらうようベンダに依頼する。

▶発注側のタスクがボトルネックにならないよう、発注側の体制を強化する。

▶社内もしくは社外の第三者に発注側のプロジェクトコントローラーとして入ってもらい、ベンダとの対等な関係を維持する。下手に出たり、馴れ合いになることを防ぐ。

どれも通常のプロジェクトでは当たり前のことですが、当たり前のことができなくなるのがタイトなスケジュールのプロジェクトです。

社内にタイトなスケジュールであることを宣言し、それに応じた対策を講じなければなりません。発注側のプロジェクトマネージャーとしては、タイトなスケジュールになった原因は自分にあることが多いので、なかなか宣言しづらいものです。原因分析は重要ですが、個人が責められることがあってはなりません。早めのアラートを出すことが評価され、犯人探しではなく、対策を講じることに注力できるような企業文化が望まれます。

2020年2月