新規開発と保守開発の違い

　そもそも新規開発と保守開発の違いとは何だろうか？　新規開発と保守開発には大きく2つの違いが存在すると考えられる。

　1つは「リスクの違い」である。保守開発では既に稼働しているシステムがその対象となる。そのため、システムを変更することによるデグレードのリスクが発生する。このリスクを回避しつつ、必要な変更や機能の拡張を行うためには、保守開発では「石橋をたたいて渡る」作業を行う必要があるといえる。

　もう1つは「目的やゴールの違い」である。新規開発におけるプロジェクトのゴールは、業務を分析して要件を満たすシステムを開発し、それを納品・稼働させることである。また、そのシステム導入によって企業戦略を実現することが、経営者にとっての最終的なゴールでもある。

　一方、保守開発プロジェクトのゴールは、システム要求を満たすように改修するだけでは十分だとはいえない。保守開発のゴールとは「開発ナレッジの蓄積やプロジェクト実績の分析を行い、後続する保守開発につなげる」ことまでである。こうした違いを認識することが、保守開発を成功させるためには重要だ。

　しかし実際の保守開発では、前述したようにやっつけでまかり通ることが多い。この方法では本来の保守開発のゴールを満たすことは難しいといえる。ここからは、筆者の経験に基づき、“やっつけ保守開発”を改善するポイントを紹介していく。

“やっつけ保守開発”から脱却する改善ポイント

要求と仕様を分離し、改修内容を精査する

　保守開発では、開発側とユーザー側双方に“繰り返しによる慣れ”が生まれる。そのため、開発側とユーザー側との間でスムーズなコミュニケーションや連携が期待できるという利点がある。しかし、保守開発のプロセスである「問題分析および修正の分析」の段階で「要求」と「仕様」が混在してしまうことも多々ある。その結果、不適切な仕様の定義や、本来であれば必要ではない改修が行われることもあり得る。

要求と仕様の分離作業を行うことで、改修内容を精査する

　常に効果的な改修を行うためには「要求と仕様を分離する作業」が必要だ。分離作業とは、開発側とユーザー側が合同で実施し、ユーザー側は「その要求は本当に必要か、その優先度は正しいか」を、開発側は「その仕様で要求を満たせるか」をそれぞれ判断することだ。こうした作業を行うことで、不必要な改修を避け、適切な仕様を制定することができる。

　特に、やっつけ保守開発のトラブルの基となるのは、前述した“潜在的・暗黙的なシステム要求に気が付かない”ことだ。そこで保守開発では「開発側は業務を正確に把握することができないこと」「ユーザー側は真の要求を導き出せないこと」を念頭に、コミュニケーションを行うことが必要だ。

　要求と仕様を分離する作業に、高度なドキュメントやツールは必要ない。極端な話、要求対仕様の二次元表があればそれでよい。改善要求を表にまとめるだけで、驚くほど要求と仕様が混在していたことに気が付くだろう。

改修規模感を共有する

　保守開発の早期段階で「要求に対する改修規模感を共有しておくこと」が大切だ。ここでいう規模感とは、画面・帳票・操作性などで分類された、機能追加や仕様変更に要する“大まかな人月”のことだ。これらを共有することには2つの目的がある。

• ユーザーによる改修項目の優先順位付けを適切にする

　改善してほしい項目でも、慣れてしまえば別段問題ないこともある。ユーザーの「慣れ」よりも早く改修できない項目は、自然とその優先度が低下する。

• 不必要な（ミッションクリティカルでない）改善要求を破棄する

　改修の規模や期間、コストが見えることでユーザーは改善要求に対して慎重になる。この慎重さを生み出すことで、本来必要がない改善要求は破棄されることになる。

　また、保守開発では“必要な改善要求を必要なテンポで満たしていく”ことが重要である。そのためには、まず改修規模感を開発側とユーザー側とで共有して、お互いの「リズム」を知る必要がある。

奇抜な仕様や局所的な便利さよりも“システムの一貫性”を優先する

　保守開発において、ある特定の処理機能だけに“奇抜な仕様”や“便利な機能”を追加することは危険だ。特に、複数のユーザー部門にまたがるシステムを改修する場合、どうしても奇抜な仕様や局所的な便利さを求められる事態に陥る。こうした状況を回避するためには、「奇抜な仕様や局所的な便利さよりも、システムの一貫性を優先する」ことが重要になる。

　奇抜な仕様や局所的な便利さを優先してしまうと、以下の2つの弊害が発生すると予想される。

• 優劣のある機能が2つあった場合、ユーザーは片方を優れているとは判断せずに、もう一方が劣っていると判断することがある

　例えば、開発側が「ユーザーのために良かれ」と思って便利な機能を新しく追加したとしよう。残念なことに、ユーザーがこれらの機能を「便利だ」と喜んでくれるのは一瞬だけである。すぐさま「システムのほかの個所にも、この機能がないと不便だ」と言われてしまうだろう。

• 奇抜な仕様は改修コストを増加させる

　ある処理機能に、従来とは異なる“斬新奇抜な仕様”を採用すると、それ以降の改修でその奇抜さを考慮した作業を行う必要がある。奇抜な仕様は、その奇抜さ故に特別に対応しなければならない作業が発生する。そのため、長い目で見ると「必ず改修コストを増加させる」要因になる。

　こうした事態を改善するためには、開発側ではシステムの一貫性を損なうことに対するリスクを分析し、ユーザー側を説得するアプローチが必要だ。また、ユーザー側も長期的なシステムの利用を念頭に置き、システムの一貫性を維持することへの理解を示していかなければならない。

ドキュメント管理にも一工夫を

　開発側、ユーザー側を問わず、保守開発に携わる関係者にとって「ドキュメントは“最も重要な情報源”」である。そのため、常に最新の情報が記載された“信頼できるドキュメントを維持する”工夫が求められる。

• 「ドキュメント修正後にソースコードを修正する」手順を徹底する

　ドキュメントを先に改修することで、ユーザー側は「次の改善要求を検討する」ことや「システム利用者の教育項目や計画、ユーザーマニュアルなどを効率よく作成する」ことができる。また、開発側は先に資料が修正されることによって、後々のドキュメントの修正漏れなどを防ぐことができる。

• ドキュメントレビューの機会を定期的に設ける

　開発側がユーザーとの対話の中で、要件ヒアリングだけでなくドキュメントのレビューの機会を定期的に設けることも重要だ。改修が繰り返される保守開発では、今回の改修が「要求された機能を満たして稼働するか」だけでなく、「その後のシステム運用や次の改修を見据えた保守開発となるかを判断する」ことも重要だ。そういった意味でも、最も重要な情報源であるドキュメントのレビューを定期的に設けた方がよい。

• ドキュメントのリファクタリングを定期的に行う

　繰り返される保守開発では、システムの仕様書や設計書は散在してしまう。これらの資料の散在化を抑えることも大事だが、散在化を“リファクタリング（再構成）”によってメンテナンスすることも大事である。

　リファクタリングとは、主に「ソフトウェアの保守性や再利用性を高めることを目的として、それが提供する機能仕様を変えることなく、内部構造を再構築するプログラミング技術」のことを指す。

　この言葉をドキュメントに適用することに違和感を覚えるかもしれない。しかし、ドキュメントはシステムを運用していくために必要な「ソースコード」なのである。プログラムに対するリファクタリングと同様に、不要な重複やつたない構成を整理・整頓し、最適化することが必要だ。

人手による運用回避の積み重ねを避ける

　保守開発ではコストや納期、または不具合の関係で、ユーザーの改修要求を運用によって回避が発生することがある。また、仕様制定のタイミングで既に“運用回避”が組み込まれていることもある。

　運用回避とは文字通り、現場のシステムの運用担当者および管理者が人手によって、システムの不具合をカバーすることを指す。例えば、システムの不具合を定期的なデータ修正や、その処理機能を使用しないなどの「運用」で「回避」する手段を用いる。運用回避された要件の多くは、後続する保守開発でも優先度は低めに設定されがちになる。また最悪の場合、優先度が低いまま改修されずに蓄積した結果、最終的には膨大な運用コストを生み出すこともあるかもしれない。

　こういった事態を避けるためには、なるべく「運用回避を積み重ねない」ことが大事だ。具体的には、運用で回避している内容を一覧化して、そこに費やすコストを算出するのだ。運用回避の手段がコストとして見えてくることで、その要件の改修時期や優先度を正しく制定することができる。

成功の秘策は“良い連鎖”を生むこと

　繰り返しになるが、保守開発は繰り返されるプロセスである。やっつけ体制・姿勢で挑んだ保守開発は、必ずその次の保守開発におけるリスクやコストなどの増加につながる。逆にその特性や問題点を踏まえた効果的な改修を目指した保守開発では、必ずその次の保守開発でコストの低下や改修効果の向上が見込めるだろう。

　開発側とユーザー側が協力して長期的なシステム利用を見据え、経験と信頼を礎とした保守開発を行う。そういった“良い連鎖”を生み出すことが、保守開発の成功の秘策だといえる。