COTS化以前の装備品開発の基本的な流れ

いきなり「COTS化による影響」といっても、それ以前のやり方を理解していないと、どこにどういう影響が生じるのかわからないだろう。そこで、COTS化が普及する前の基本的なやり方について、簡単に解説しておこう。

軍隊とは国家戦略を遂行するための手段であり、その国家戦略は個々の国が置かれている状況や周辺諸国との関係、地政学的な状況に影響される。そうした状況を検討したうえで、「どのような戦力や装備が必要か」、「どのような任務を想定するか」という話が決まり、そこから「どのような装備を用意するか」という話につながる。

そうやって要求仕様がまとまったところで研究・開発・生産と話を進めるわけだが、最初に行うのは、キモとなる技術の開発と熟成だ。弾道ミサイル防衛システムを例にとると、飛来する弾道ミサイルを探知するためのレーダーをはじめとするセンサーが必要になる。

また、それを迎撃するミサイルについても、迎撃に必要な性能を備えたミサイル本体や目標を捕捉するためのセンサーが必要になる。そして、これらの仕組みを有効に機能させるための指揮管制システムや通信網も必要になる。

こうした重要な要素技術を開発・熟成したら、次にそれらを組み合わせて、1つの「システム」を構築していく。さらに、試験を重ねながら問題点を燻り出して修正し、最初に要求した条件が満たされたところで完成ということになる。

こうした基本的な流れはCOTS化以前も以後も大きく変わらないが、COTS品には「製品のライフサイクルが短い」という特徴がある。軍隊の装備品は十数年から数十年にわたって使われるものだし、生産が何年にもわたって続くのは普通だ。艦艇のごときは5年線表といって、1隻完成するまでに5年ぐらいかかるのが普通だ。

では、IT業界における5年間はどうだろう? ドッグイヤーと呼ばれるネット業界はいうまでもなく、ハードウェアでもソフトウェアでも、5年前の製品は骨董品扱いされかねない。

COTS化が導くスパイラル開発の利用

だから、「最初に要求仕様通りのものを完成させて、それをそのまま使い続ける」という発想は、COTS化と相性が悪い。常に民間の新技術や製品の動向に対してアンテナを張り、新たな製品や技術をどんどん取り入れていく必要がある。

またすでに完成・納入した製品についても、用いているCOTS品が陳腐化したら、順次、更新していく必要がある。もちろん、それに合わせて運用現場からのフィードバックを得て、能力向上や不具合の修正も図っていく。

航空機でも車両でも艦艇でも定期的に整備を行うのだが、何年かに1度は大掛かりなオーバーホールや整備を行うため、それに合わせて中身の入れ替えを図ることが多い。

こうして外見は同じままでも中身がどんどん新しくなっていくというのが、COTS化した装備品のライフサイクルになる。ハードウェアだけでなく、コンピュータで動作するソフトウェアも同様で、不具合の修正や新機能の追加を継続的に行っていく必要がある。

そのため、最初に装備品を開発する時点で後々のことを考慮に入れて、将来の換装・アップグレード・機能追加を容易に行えるようにする必要もある。いわゆる、オープンアーキテクチャ化だ。

それには、プロトコルやインタフェースの仕様を独自仕様でガチガチに固めるのではなく、民間でも一般的に用いられているような仕様にするほうが都合がいい(といっても、要求されている条件を満たせるような仕様があればの話だが)。

こうした、段階的な改良を継続的に進めていくやり方のことを、業界ではスパイラル開発(spiral development)と呼んでいる。能力向上の様態が、螺旋を描きながら上昇する様に似ているからだ。

スパイラル開発の過程を概念図にまとめたもの(Picture : USAF)

そうなると、メーカーの開発体制、それを運用する軍側の体制いずれも、継続的に能力向上や中身の代替を進めていくことを前提にして構築する必要がある。さらには、開発・製造・納入後のサポートをカバーする契約の内容も、従来と同じで済むとは限らない。継続的なメンテナンスやアップグレードを行う前提で契約や支払いの条件を整備しておかなければ、軍あるいはメーカーが損を抱え込むことになりかねない。

実際、ノースロップ・グラマン社のように、オープンアーキテクチャ化やCOTS化を効率よく推進するための社内システムを構築している事例がある。