システム開発プロジェクトにおいて設計仕様を途中で変更するのはよくあることです。もちろん、設計仕様は変更せずにガイドラインに沿った方がプロジェクトは円滑に進むのですが、人と人とがコミュニケーションを取ってプロジェクトを進めている以上、顧客と開発側の相違で戻ることがあったり、開発途中でニーズが変化するということは避けて通れません。
だからといって、都度変更に対応しているだけでは開発後に重大なトラブルを呼び込む可能性があります。本文は仕様設計の変更管理をテーマに、その概要や実施のポイントをご紹介します。
変更管理って何？
変更管理とは文字通りシステム開発途中の変更を適切に管理するための業務です。ちなみになにを管理するかというと、具体的にはハードウェアの変更、ソフトウェアの変更、人の変更を管理します。
ハードウェアの変更
- 新しいハードウェアの追加導入
- 既存のハードウェアの拡張（オプション製品の導入など）
- ハードウェアの買い増し
- 壊れたハードウェアの修理
- 既存のハードウェアを新しいハードウェアに置き換え
- ハードウェアの廃棄
ソフトウェアの変更
- 新しいソフトウェアの導入
- ソフトウェアのバージョンアップ
- ソフトウェアの更新（パッチ当て）
- 既存のソフトウェアへのオプションプログラムの導入
- ソフトウェアの置き換え
- ソフトウェアの廃棄
人の変更
- 新しいプロセス（手順や仕組み）の導入
- 担当者の変更（人そのものの変更）
- 役割の変更（人は変わらず、役割分担だけが変わる）
- プロセスや手順の変更
- ある特定の役割の廃止
- プロセスや手順全体の廃止
このように変更管理には色々な管理項目がありますが、上記の項目はいずれもシステム開発後のものですね。今回ご紹介するのはシステム開発段階での仕様設計の変更管理なので、主に次のような項目を管理します。
仕様設計の変更管理
- 設計変更要求
- 設計変更要件
- 設計変更ワークフロー
- 設計ドキュメント
これらの項目を適切に管理することで、仕様設計の変更管理です。
変更管理ができていなと何が起こる？
仕様設計の変更が起こるプロセスは次の通りです。
1.顧客から仕様設計の変更要求が出る
2.それを受けてシステムエンジニアが顧客と仕様設計を調整する
3.新しい要件定義を固める
4.変更部分を確認しつつ開発を進める
これが大まかなプロセスなのですが、この際に変更管理が無いとどのような問題が起こるのでしょうか？
実は、システム開発段階で問題が起こることはほとんどありません。なぜなら、新しく定義された要件定義に従って開発を進めたり、部分的なドキュメントさえ変更すれば技術者は通常通り開発を進めるからです。
しかしこれが大きな落とし穴になります。変更管理ができていないということは、ドキュメントに至るところで不整合が起きているということです。そのため、開発時は良くても保守運用に入る段階になって初めて問題が顕在化しています。
たとえば、システム開発からシステム運用まで一貫して同じチームが担当することは少ないでしょう。システム開発が完了したらチームはいったん解散して、各々が別のプロジェクトに参画していきます。そのため、システム運用に関しては開発に関わっていなかった人材が当たることも少なくありません。
そうした際にドキュメントに不整合があると当然ながら運用管理に問題が発生します。たとえばシステム障害が発生したり、脆弱性が発生した際にどのドキュメントを参照すればよいのかが分からず対応まで時間がかかります。参照したドキュメントが最新とは限らないので、結果的に間違った対応をしてしまうことも少なくないでしょう。
それによってシステム稼働状況がより悪化してしまったり、パフォーマンスが低下するといった事態に陥ってしまいます。
このように、システム開発段階での仕様設計変更は開発中に問題が生じなくても、運用段階で様々な問題が発生することが難点なのです。
[RELATED_POSTS]変更管理を徹底するためには？
仕様設計の変更管理において最も重視すべきことは“ドキュメント管理”です。ドキュメントには設計書、計画書、提案書、ユーザーマニュアル、報告書等の種類がありますが、やはり設計書のドキュメント管理が最も徹底すべき点です。
ドキュメントの変更管理を徹底するためには、その都度変更が発生した時点でドキュメントを更新することが大切です。しかし、システムエンジニアの中にはドキュメント作成を苦手としてる人が多いことから、どうしても後回しにしがちです。
そのため、ドキュメントの変更管理を「明日やろう」と考えているうちに、いつのまにか変更管理を忘れて整合性の取れていない設計書になってしまいます。
実はドキュメントの整合性が取れないという問題はシステム開発中だけでなく、システム運用段階でも発生しやすい問題です。米国のITメディアである“Medium”のブログエントリ（ 変更管理の目標は何か (1/2)）によれば「システムは生き物。常に変わりゆくものです。そんなシステムを示したドキュメントはしばしば、メンテナンスを後回しにされ、陳腐化してしまいます。」と説明しています。
この経験は誰もがあるでしょう。では、ドキュメントの変更管理を徹底するには他に何が必要か？その答えの一つが設計書作成ツールを活用することです。
設計書作成ツールによるドキュメント管理
設計書作成ツールとは文字通り、ドキュメント作成などを効率良く行うために支援し、その後の管理まで行えるツールです。当社システムインテグレータが提供する“SI Object Browser Designer”はシステム開発の上流工程である基本設計・詳細設計をシステム化し、合理化・標準化を実現します。
さらにSI Object Browser Designerは設計情報を「まとめる」「生み出す」「活かす」の３つのつなげる効果により設計工程の従来の課題を解決できるツールです。もちろん、これまであったドキュメントの変更管理問題が解決します。
SI Object Browser Designerではバラバラだった設計書を企業や部署などの組織単位で統一でき、かつ設計データとフォーマットデータは独立しているため、後からフォーマットを変更して基本設計書/詳細設計書の再出力も可能です。そのため変更管理も行いやすく、運用時点で発生しやすい変更管理問題も回避できます。
簡単なGUI操作やモックアップを作成するフリーツールもありますが、SI Object Browser Designerは大規模なシステム開発において欠かせないレイアウトや項目定義書だけでなく、テーブル定義書やイベント・ロジック定義書やCRUD図などの各種設計ドキュメントの作成などもサポートします。
まとめ
仕様設計の変更管理はドキュメントの整合性を取ることが大切です。そのためにはやはり、SI Object Browser Designerのようなツールが欠かせないでしょう。システム開発途中での仕様設計変更は避けられないので、この機会に変更管理を支援するツールの導入をご検討ください。
