第4回　実装・テスト工程のITアーキテクト

　ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は実装・テスト工程を対象にします。実装・テスト工程では、主に次の5つの成果物を作成します。

（1）アプリケーションフレームワーク
（2）コーディング規約
（3）機能横断的テストシナリオ
（4）単体テスト完了基準
（5）性能評価レポート

　この工程では多数のメンバーが加わることが多いので、明確な行動規範を策定することがポイントです。アーキテクチャーを「絵に描いた餅」で終わらせないためにプログラマに「道具箱」を提供しますが、道具箱の中の道具の数を可能な限り減らすことが重要です。これにより開発者の学習の負担を減らし、実装の均一性を保ち、道具の誤用を避けることでテスト負荷を軽減します。また、論理的にきれいな構造でも、物理的な制約から性能要件が満たせず、構造が崩れることがよくあります。事前の机上評価（静的検証）が十分されていることが不可欠ですが、実機上でアプリケーションを動かし、静的検証の正しさを動的検証により確認します。

　道具を整備する理由は、不必要な自由を開発者から奪い、設計と実装を近づけ、開発者ごとのバラツキを抑えるためです。開発者から非機能要件の関心事を切り離し、機能要件に集中できるようにします。機能要件の実現において、設計→実装→検証のサイクルをより短く回すことを促進し、品質を担保しながら変化への対応速度引き上げるために「行動規範」を規定します。

（1）アプリケーションフレームワーク
　アプリケーションの実装負荷を軽減するためにITアーキテクトが整備するのが「アプリケーションフレームワーク」です。例えば、機能コンポーネントが複数の永続化コンポーネントを集約する形で成り立っている場合を考えます。この場合、機能コンポーネントで直接SQL文を書くことはできず、機能コンポーネント内で集合演算（配列の連結など）が必要になります。ですが、これを個々の開発者に実装してもらうのは負荷が重くなり過ぎます。こうしたことを防ぐためにアプリケーションフレームワークを整備します。アプリケーションフレームワークは、「アプリケーションの基本構造の維持」と「開発者の実装負荷の軽減」の2つの目的を同時に満たすための汎用的なソフトウエアライブラリ群です。

（2）コーディング規約
　アプリケーションフレームワークで規定できない開発者が守るべきルール、実装基準を規定した文書が「コーディング規約」です。同じ“道具”を使うこと、アプリケーションフレームワークの利用を義務付けるだけでは規定できない開発者のバラツキが出る部分を「規約」で抑えます。また、初期の開発者と保守・改善時の開発者は通常異なります。誰が書いても同じようなコードになり、他人が書いたコードも読めるようにします。

（3）機能横断的テストシナリオ
　詳細設計工程で作成した「機能パッケージをまたがる状態遷移図」の取りうる遷移からテストケースを抽出した文書が「機能横断的テストシナリオ」です。なぜ、ITアーキテクトが機能要件に対してテストシナリオを考える必要があるのでしょうか。それは、個別機能を担当しているエンジニアでは気がつかない視野の広さを持っているのがITアーキテクトだからです。連結テストケースの妥当性を検証する責務を担い、システム全体としての品質の担保に協力します。

（4）単体テスト完了基準
　「C0網羅100％自動テスト」など、開発者がテスト結果として残すべき基準を示した文書が「単体テスト完了基準」です。仕様から抽出したテストケースで十分な品質を担保するには、実装バグが無いことが前提です。単体品質を担保するための担当者が満たすべき基準を決めます。なお、ITアーキテクトはテスト自動化の費用対効果を最大化する責務を担います。その際テストの自動化には、アプリケーションフレームワークとの協調が不可欠です。

（5）性能評価レポート
　アーキテクチャーの分析結果（机上評価）と実機評価との差異を明らかにした文書が「性能評価レポート」です。実装されたアプリケーションを用いたアーキテクチャーの動的検証により、初めて性能面でアーキテクチャーが機能したことを確認できます。その際、性能要件を満たせたかどうかの評価だけでなく、机上評価との差異に留意します。処理にはボトルネックがあります。現在のボトルネックが解消されると、別のどこかに生じます。ボトルネックが理論通りに生じ、負荷分散戦略が機能していることを確認します。