キミの設計に「トレーサビリティ」はあるか：保守性・拡張性に優れたシステムを作る（11）（1/2 ページ）

システム開発は5つのステップ（工程）に分けられる。全体の流れを可視化し、それぞれの工程で発生する影響範囲を追跡する。それにより、構築後の保守・拡張性をも視野に入れた作業を行うことが可能となる。

[野村佳弘，＠IT]

システム開発の流れを俯瞰（ふかん）する

1.1　「ビジネス要求」から「実装・テスト」までステップは5段階

　システム開発の工程は5つに分けることができます。すなわち、

• ビジネス要求（の分析）
• システム要求（の分析）
• 機能（の設計）
• メソッド（の設計）
• 実装・テスト（の実施）

です（図1）。

図1 システム開発は5つの工程に分けられる

　「ビジネス要求（の分析）」から「機能（の設計）」までを開発工程の前半とします。前半段階では、構築すべきシステムに対するビジネス・サイドの要求を明らかにします。つまり、業務を見える化（モデル化）し、誰にでもわかる形に仕立てます。

　「メソッド（の設計）」から「実装・テスト（の実施）」までを開発工程の後半とします。後半段階では主に、システムに対するビジネス要求を実現するための機能（メソッド）を設計します。設計作業が終了すると、実装、テストを行い、機能が正しく実装されているか、ビジネス要求が満たされているかを検証します。

1.2　各ステップの概説

1.2.1　ビジネス要求（の分析）

　ビジネス要求のステップでは、ビジネスのAs-isモデル（現状）やTo-beモデル（未来）を検討することから始めます。そして、どのようなビジネスモデルを実現すればビジネス上最も効果があるか、そのために必要なこと（要求事項）は何かを分析します。

　通常、ビジネス要求の分析は、階層的・段階的に行います。全社的なビジネス要求から、個々の業務に関するビジネス要求まで段階的に分析していくわけです。その際、ポイントとなるのは、情報の流れです。情報がどのように処理されていくのかを観察し、業務プロセスを定義していきます。同時に、（情報に関連する）利害関係者や社外システムの存在も明確化します。その結果、システムに必要なインターフェイス（情報の出入り口）が幾つあるのか、それらはどんなものなのかも明らかになります。

1.2.2　システム要求（の分析）

　ビジネス要求の分析結果を基に、システムに対する要求を分析します。1.2.1で分析した業務フローを基に、システムが備えるべきサービス群を定義します。そして、システム化すべきサービスの範囲（ユースケース：システムのコンテキストと、外部機能との関係を示した図のこと）を決めることで、システム化の範囲を明確にし、外部システムとのインターフェイスの存在も明確にします。プロセス内部の機能の結合度を高めるようにプロセスを定義し、プロセス間の依存関係が「疎」 になるようインターフェイスを定義することで、プロセス間の影響度を低くするよう注意します。これにより、保守性・拡張性の高い分析モデルを得ることができます。

1.2.3　機能（の設計）

　1.2.2の作業を経て、ユースケースが明確になると、システムが備えるべきサービスが明確になります。そして、そのサービスをどのように実現すればよいかを、ユースケースに基づくクラスを検討しながら設計します。その結果得られるのが「分析モデル」です。機能（の設計）のステップでは、さらに、業務コンポーネントの設計も行います。

---

▼UML（情報マネジメント用語事典）

---

1.2.4　メソッド（の設計）

　1.2.3の作業では、業務クラスの構造やコンポーネント構造を分析モデルとして定義しました。メソッド（の設計）段階では、これらの「分析モデル」（クラス）や「コンポーネント」を実装可能な状態としてさらに詳細に設計します。具体的には、アーキテクチャ設計（階層化アーキテクチャの設計、永続性・分散性・セキュリティの確保）の結果などを実装可能にするため、クラスやコンポーネントを修正したり、機能追加を行ったりします。

---

▼クラス図（情報マネジメント用語事典）

---

1.2.5　実装・テスト（の実施）

　メソッド設計の次は実装作業とテストを行います。テストは、今までに分析・設計してきた内容が正しいか検証する作業です。テストが正しく、漏れなく行われることは、設計品質を確保する上で大変重要です。

　テストは大きく分けて、「単体テスト」「組み合わせテスト」「総合テスト」があります。テストケースを洗い出し、テストを実行し、結果を評価するという基本アクションは、すべてのテストに共通しています。

　テストを行う上で重要なのは「何を基にテストケースを作成していくか」ということです。テストケースを作成するには、仕様が理解できなければいけません。テストケースが誤っていては、テストの意味がありません。ゆえに、きちんとした仕様書を作成することは大変重要なのです。

　例えば「総合テスト」では、ビジネス要求（の分析）で作成したプロセスフローや業務フローなどが必要です。「組み合わせテスト」では、システム要求（の分析）で作成したユースケース定義書でテストケースを作成します。

　通常、分析や設計の結果は、ドキュメントにまとめますが、テストケースが作成できるような内容を盛り込んでおかなければ、仕様をドキュメント化する意味が大きく薄れます。つまり、テストシナリオを考えることができるドキュメントであることが、設計品質の目安となります。

1.2.6　追跡可能性（トレーサビリティ）により変更の影響を可視化する

　分析・設計作業というのは、ある作業の結果を基に、新たな目的に沿った変換を行い、新しい結果を作り出す作業の連続だと定義できます。

　例えば、機能（の設計）段階では、システム要求の結果であるユースケース定義書などを“入力”とし、機能の設計という変換作業を経て、分析モデルという“結果”を導き出します。このとき、入力される要求や機能が、出力される要求や機能にどのように対応するのかを追跡できると、修正の影響範囲を特定する時に役立ちます。また、追跡可能性が局所化されるよう設計することも重要なポイントといえるでしょう。1つの要求が多岐にわたる機能に変換される場合、保守性や拡張性が低くなります（図2）。

図2 トレーサビリティの例