pixta_11328265_S

 全社システムのリプレイスのような大規模なシステム開発ともなると、全てを1回で終えられることは少ないです。一度本稼働させた後に2次開発、3次開発と続きます。

 

 2次開発には「良い2次開発」と「悪い2次開発」があります。これらを同列に考えてしまうと、システム開発プロジェクトの適切な評価ができません。

 

 「良い2次開発」とはどのようなものか。たとえば、希望する稼働時期とシステム開発の予算と期間を考慮して、1次開発は最低限の主要機能とし、後回しにできる機能を2次開発に回すような場合です。

 

 2次開発に回さずに1次開発で全て作ったほうが、総コストは必ず低くなります。テスト工程が重複しないで済むからです。しかし、「単年度の予算に上限がある」、あるいは「全て開発するには時間が足りない」などの時には、無理せず2次開発に回します。

 

 また、開発すべきかどうか判断がつかない追加機能を2次開発に回すのも良い2次開発です。1次開発でリリースした基本機能を実際に使ってみて、その上で開発するかを判断します。

 

 要件定義の時に「このような追加機能が欲しい」と主張していた人も、1次開発後の新システムを使って見ると、「追加機能は無くても大丈夫」とあっさり前言撤回することがよくあります。

 

 現場担当者は、現行システムの機能や方法に慣れ親しんでいます。従来と異なるものだとイメージしにくいものです。プロジェクトチームが客観的に見て追加機能の必要性を感じられなければ、一度2次開発に回して様子を見るのは良いことです。

 

 では対する「悪い2次開発」とは何か。一言で言えば、1次開発の失敗を尻ぬぐいするケースです。

 

 たとえば、システム稼働後に実務と合っていない部分が判明し、業務がストップする場合は緊急の2次開発です。コスト度外視で対応します。緊急回避の追加修正開発なので、システム全体との整合性がなく、システムがブラックボックス化する要因となります。

 

 また、業務がストップするほどではないが、それを使い続けるのが著しく非効率な場合も同様です。2次開発が終わるまで、現場の業務負荷は相当なものになります。

 

 「良い2次開発」と「悪い2次開発」かの違いは、その内容を事前に意図できていたかどうかです。悪い2次開発は、1次開発時の見通しのあまさに起因しています。2次開発と言うより「1次の修正開発」というのが正しい表現です。

 

 1次の修正開発(悪い2次開発)の発生を防ぐためには、要件定義を正確にやる必要がありますが、局所的な視点だと思い込みが発生し間違います。

 

 上流工程であるシステム構想で、システムの全体像や主要機能の役割をしっかり洗い出しておけば、要件定義で「ここはどういう機能で、何をどこまでしなければならないか」を大局的に理解できます。システム構想の質が高ければ高いほど、悪い2次開発の発生は防げます。