鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）：The Rational Edge（3/4 ページ）

[Scott W. Ambler, Per Kroll，IBM]

評価IT資産

　「IT資産」とは、組織がITエキスパートらに対して日常業務での利用を望むあらゆるソフトウェアコンポーネント、サービス、テンプレート、エンタープライズモデル、リファレンスアーキテクチャ、例、パターン、指標、あるいは基準を指す。「評価IT資産」とは、一般的に十分な品質があり、当面の作業に関連することからITエキスパートが実際に応用したいと考えるものを指す。つまり、ITエキスパートが手元にあるIT資産を利用するのは、これらの資産が実際に生産性向上を可能にするからだ。彼らがエンタープライズアーキテクチャと適切なリファレンスアーキテクチャに従うのは、これらの資産が時間を節約し、これらのシステムが既存のサービスを呼び出すものであるからだ。また、これらが既存の技術インフラを活用するのは、再構築するよりも再利用する方が簡単だからという理由だけだ。

　理論的にいえば、ITエキスパートが自社の基準や指標に従うのは、これらが自分たちの作業の合理化に役立つためであり、監査に引っ掛かることを恐れてそうすることを余儀なくされているからではない。確かに、一部の基準は法律で義務付けられているもので、それに関してITエキスパートに選択の余地はない。幸いにも、制定されている基準の大半は自由度が高く、組織には、ITエキスパートにとっての価値を最大限に活用する（あるいは適合に関する問題を最小限に抑える）形でこれらを施行する機会も与えられる。

メリット

　評価IT資産をサポートすると以下のような複数のメリットがある。

1.　一貫性の向上。コーディング基準やモデリング指標などの共通の指針に従って共通のパターンを適用すると、ITによって作り出された成果物全体の一貫性が向上する。これが、サポートの低下や保守費用の減少へとつながっていく。積極的に従ってもらえる指針が適用されるようになる。

2.　効率の向上。技術資産の再利用が増えることで、共通機能の標準化を通じて全体の効率が向上する。首尾一貫した指針に従うと、付加価値のない活動が標準化できるようになり、それによって新しいチャンスに集中できるようになる。

3.　製品化に要する時間の短縮。再利用率、一貫性、そして効率が高まると、製品化に要する時間が短縮され、それにより組織の競争力が高まる。

4.　コミュニケーションの向上。成果物の一貫性向上、パターンによって実現される共通の表現形式、そして共通のエンタープライズアーキテクチャは、ITエキスパート間のコミュニケーション推進に役立つ。そして、これが全体のIT関連活動の合理化に役立ち、コミュニケーションのミスによって生じる欠陥を削減する。

5.　ガバナンスコストの削減。ITエキスパートが評価IT資産を進んで定期的に応用すれば、これら資産の利用を強制および認証するのに必要な資金が減少するため、全体のガバナンスコストが低下する。

トレードオフ

この手法には次のようないくつかの代償が伴う。

　品質への投資。品質が高く、達成しようとしていることに何でも応用可能であるため、IT資産は大切にされる。高い品質は偶然の産物ではなく、重労働や効率的な購買活動への投資によって実現される。

　品質維持にはコストが掛かる。再利用可能な資産を作ったり、簡潔な指針を書く方が、プロジェクトに特化した資産を作り出すよりもコストが掛かる。これらの資産を作成してもチームが打撃を受けない資金調達戦略を取り入れる必要がある。

　資産サポートへの投資。IT資産を効果的に応用するには支援が必要だ。資産は見つけやすくしておくことが必要で、その資産の理解と応用を助けるための窓口も必要だ。

　資産の進化に対する投資。継続的な投資を行わないと、どのIT資産も時間の経過に伴い古くなる。例えば、開発者が現在Java 5を使用している場合、Java 1.1のコーディング基準はほとんど価値がない。本当に必要なものがシンプルかつ軽量のユースケース用テンプレートである場合、正式で詳細なユースケースのテンプレートは、開発チームの作業を遅らせるか、無視されることになる。

　自由度の低下。IT資産があり、これをITエキスパートが簡単に利用できれば、開発者が会社の方向性から逸脱することは難しくなる。多くの開発者は、自分たちのシステム向けに最も適切な継続戦略を選べる自由を望んでいる。彼らは、既存のどのデータベースを使うのか指示されることは望んでいない。

　合意の必要性。IT資産が貴重であるとの全体の総意が必要になる。例えば、Javaのコーディング基準は、社内で評価の高いリーダーらによって書かれ、サポートされていなくてはならない。これらはまた、ほかの人々による審査と批評を受けてさらなる改善を行う必要もある。Javaコーディング基準の勧告には全員が同意しないかもしれないが、コードの一貫性に対する重要性は認識し、それには進んで従うはずだ。

アンチパターン

　強制指針。ITエキスパートは共通の基準と指標に従い、準拠しなくてはならない、とITの上級幹部が宣言すると、コンプライアンスを保証するために融通の利かない審査プロセスが導入される。これは前述の多くのメリットにもつながるが、強制が強まることが多い。

　再利用の申告。コンポーネント、サービス、あるいはIT全体のインフラまで、技術資産がそれらのオーナーによって再利用可能だとして申告される。再利用可能だといわれても、うまく再利用されなければ再利用可能とはいえない。品質が高く、当座の作業に応用できない限り、開発者が資産を進んで再利用することはない。

　現実と懸け離れた資産。「現実と懸け離れた資産」は、IT部門で利用を開始するまでは完ぺき、もしくはほぼ完ぺきなものだ。例としては、数カ月がかりで完成させた非常に詳細なエンタープライズデータモデル、開発チームにとって必要なセキュリティで考え得るすべての側面に対応したセキュリティフレームワーク、あるいは非常に洗練された要件定義やデザイン成果物関連の一連の書類用テンプレートなどがある。現実と懸け離れた資産は、それが意図したユーザー層が価値を見いだすにはタイミングがあまりに遅過ぎる、あるいは実際に役立てるには余計なものが多過ぎることが多い。

　再利用抑制計画。ITエキスパートに既存の資産を再利用させないようにする方法は数多くある。例えば、これらを命令行数（LOC）で計算すると、既存のコードを再利用するよりも新しいコードを書きたくなる。保守やサポートに資金を回すために資産を再利用させるようにすれば、コストが大幅に抑えられ、彼らが自分たちのニーズに合った具体的なものを書くようになる。

推奨デフォルト

　IT部門に対しては、自分たちの主要開発言語のコーディング基準、システム内で推進したい共通パターンのライブラリ、重要な技術インフラの側面に対応したリファレンスアーキテクチャ、そして自分たちが描くエンタープライズアーキテクチャのビジョンの説明を保存しておくことを推奨する。また、これらの評価IT資産のサポート、展開、購入、あるいは導入のための要員も用意しておきたい。特に、自分のニーズを簡単に満たせるならば、可能な限りIT資産は構築せずに購入し、保守はほかに負担させることを推奨する。