システム開発、特に既存システムの改修案件を行う時にありがちなことが現行システムに関するドキュメントがないということです。
プロジェクトマネージャーやシステムエンジニア、プログラマーとしてシステム開発に携わったことがある方であれば誰しも一度はこうした状態に遭遇したことがあると思います。
こうしたシステム開発に関するドキュメントが存在しない時にどう対処すべきかについて、私の経験を踏まえて整理したいと思います。
ドキュメントがないときの対処方法
現行システムに関するドキュメントがない時は、プロジェクトマネジメントの観点で対処することが重要です。その際のポイントは次の２つです。
１．現行システム調査のための工数確保
２．責任分界点の明確化
ドキュメントがないと起きる問題点
そもそもシステム開発をする際ドキュメントがないとどういった問題があるのかを考えます。
一番の問題は、今回のシステム改修による改修範囲や影響範囲を特定することができないということです。
ドキュメントがないということは、現在のシステム構成がどういうもので、どういう設計・仕様かを一目で分かるものがありません。そして、なぜこうしたシステム設計にしたのかもわかりません。
そのため、今回の要求内容をもとにシステム改修を行おうとしても、この改修方法で問題ないのかを判断することが非常に難しくなってしまいます。
こうした問題を解決するために、もし現行システムに関するドキュメントがないプロジェクトを担当することとなったらプロジェクトマネジメントの観点から対応が必要になります。
現行システム調査のための工数確保
１つ目は、現行システム調査のための工数を確保することです。
現行システムについてわからないのであれば、調べるしかありません。しかし、調べるためにはそのための工数、コスト（費用）がかかります。したがって、現行システム調査をするための工数、コスト、時間を顧客と交渉してしっかりと確保することが重要です。
通常、現行システム調査はシステム要件定義工程の中で実施することが多いです。現行システム調査の結果を踏まえて、どのように今回の要求事項を実現していくかを検討し、システム要件としてまとめるためです。
現行システム調査工数は、改修機能の規模にもよりますが、私の場合はシステム要件定義工数を1.25倍した工数を、現行システム調査を含むシステム要件定義工数として見積もることがこれまでの経験上多いです。
責任分界点の明確化
２つ目は、ベンダーと顧客（発注者）側との責任分界点を明確にしておくことです。
現行システム調査をすることで、現在のシステム構成や設計や仕様、挙動というHOWについてはある程度わかるようになります。しかし、なぜこうした構成をとっており、設計・仕様にしたのかというWHYについてはシステム調査からは読み取ることができません。そのため、現行システム調査を実施したからといって完璧な状態にはなりません。
重要なことは、現行システム調査の結果を顧客（発注者）側にも理解してもらい、今回の調査結果の範囲で考えられる最善の設計を検討するということで合意することです。
そもそもドキュメントがないというのは、現行システムを管理している顧客側（発注者側）の問題であることが多いです。そのため、その最終的な責任は顧客側（発注者側）に持ってもらうことが重要です。そのリスクも承知の上で、改修するのだという覚悟をもってもらう必要もあります。
成功のポイントはドキュメントがない状態を正しく抑えること
いかがでしたでしょうか。
システム開発においてドキュメントがないというのは決して珍しいことではありません。しかし、そうしたプロジェクトを成功に導くためには、プロジェクトが始まる段階のマネジメントにすべてかかっていると言ってよいです。
ドキュメントがないという状態がどういう状態であるか、そのことについて顧客（発注者）とどういう取り決めて進めていくべきかを事前に整理して合意しておくこと、これがプロジェクトを成功させるのポイントです。
今回の内容を、ドキュメントが存在しないプロジェクトであってもトラブルにさせることなく成功に導くヒントとしてもらえたらと思います。
コメント