ITシステムプロジェクト

ITシステムプロジェクトの成功率は、
「3割程度」という統計結果は有名な話です。

建築業は免許制なので、資格を持っている必要がありますが、
ITシステムプロジェクトのマネージャは、資格が必要ではありません。
プロジェクト管理技法を整理したものに「PMBOK」があり、
また、ITシステムに特化したものでは「ITIL」がありますが、
これらの知識を、マネージャが十分に有しているという保証はありません。

また業界としても未成熟であるためこれといった管理技法が確立されていないためか、
システムの構築に建築業界に見られるような法律の制限が少なく、
品質等の管理方法もプロジェクトのやり方に委ねられている状況です。

したがって業界内では、知識ベースの整理や管理技法の利用を十分に行わない、
KKD(=勘、経験、度胸)に頼り切ったマネージメントが未だに後を絶たない状況にあります。

プロジェクト成功の定義

そもそも、ITシステムプロジェクトの成功とは何でしょうか。

PMBOKではプロジェクトを、
「独自の製品、サービス、所産を創造するために実施される有期性の業務」
と定義しています。

一般的にプロジェクトの成功とは、
先述した、有期性、独自性のある業務において、
「QCD(=品質・コスト・納期)」が超過することなく完了することを意味します。

品質とは、顧客の興味・期待を指します。
顧客の要求は業界・社会的ニーズ・技術など、様々な要因により常に変化します。
人間の意思が品質の定義を決定する以上、全く同じ要件を持つプロジェクトは存在しないと言えます。

意識のズレ、暗黙のニーズ、技術的な実現可能性の見誤り等、品質を脅かす要因は多く、
どこに潜んでいるかも見えにくいのが難点です。

コストとは、お金のことを指します。
ソフトウェアは目に見えないという特性を持っている以上、
顧客はコストの妥当性を評価しにくく、
またエンジニアも必要コストが正確に見積もりにくいのが難点です。

また家などの資産は、作った後の費用対効果を見積もるのは顧客側の責任ですが、
システムの場合はそういう訳にはいかないというのが、
見積りの難易度をさらに高める要因となっています。

納期とは、完成までの期限のことを指します。
ソフトウェアの開発技法やアーキテクチャは未だ変化を繰り返しているため、
十分な見積り精度が得られるほどノウハウが貯まった頃には、
大抵、技術的に時代遅れとなっているでしょう。

作業見積りを誤ったり、慣れないアーキテクチャから未知のバグが発生するなど、
プロジェクトを狂わせ、徹夜作業を強いられる現場は未だ後を絶ちません。

プロジェクトの工程

ITシステムプロジェクトの工程は、以下のように分類できます。

工程名 作業内容
計画工程 体制の整理、目標/要件の分析を行い、スケジュールの作成を行います。
設計工程 業務・機能の分析、ITシステムの設計、試験方法の定義を行います。
構築工程 アプリケーション、ハード、場所、人の調達を行い、ITシステムを構築します。
試験工程 ITシステムが設計通りに動作しサービスを提供できることを確認します。
移行工程 ITシステムが運用可能な環境を整え、移行を行います。
運用保守 ITシステムが問題なく動作できるよう整備したり、故障箇所の修理を行います。

ITシステムの開発方法は、日々変化する技術や社会的要望を反映し様々な手法が発明されましたが、
スタンダードは存在しない状況です。
したがって、ここで定義した工程も非常に大雑把なものなっています。

日々変化する外部要因に対して柔軟さを持つには、
その場その時のプロジェクトの特性に着目し、
過去の成功という枠に捉われない思考(=ゼロベース思考)を駆使し、
漏れ・ダブリなく成功の要件を洗い出すこと(=MECE)を意識する必要があります。

そこで本頁では、特定のドキュメンテーション・作業には着目せず、
各工程で「考慮が必要な点」に焦点を絞り解説を行うことにしました。

前に述べた全工程を真面目に順番に実施したり、
また考慮が必要な点を真面目にドキュメントなどの成果物として残そうとすると、
確実にスピード感は失われます。

したがって実際のプロジェクトでは、
何を平行に実施できるか、何をやらないでいいのか、
こういった点も慎重に検討して進めて下さい。



  • 最終更新:2010-06-03 01:10:47

このWIKIを編集するにはパスワード入力が必要です

認証パスワード