イージス戦闘システムと弾道ミサイル防衛をめぐる話の締めくくりとして、システム自体のコンセプトと、そのシステム開発についてまとめてみようと思う。まさに「軍事とIT」という連載のテーマに相応しい話になるのではないだろうか。

イージス戦闘システムの何が画期的だったか

現役で、しかもさらなる発展を続けているシステムについて「何が画期的だったか」と過去形で書くのも妙だが、当初のコンセプトを振り返る意味で、あえて過去形で書いてみた。

イージス艦でなくても、指揮管制システムを搭載するのは現代の軍艦における一般的なスタイルである。しかし、そうした中でイージス戦闘システムが今も図抜けた存在でいられるのは、それなりの理由がある。

それは単に能力的な話だけでなく、対空戦(AAW : Anti Air Warfare)・対水上戦(ASuW : Anti Surface Warfare)・対潜戦 (ASW : Anti Submarine Warfare)を包括的にカバーして、各種のセンサーを通じて得た追尾データに基づく脅威判定、そして武器割当と交戦を自動的にこなせる高度なシステムを実現したから、ではないだろうか。

そして、その中核となるのは指揮管制・脅威判定・武器割当の機能を司るソフトウェアである。本連載の第7回(イージス戦闘システムの初回)でも言及したように、このソフトウェアこそがイージス戦闘システムの中核であり、それをどこまで熟成できるか、新たな脅威に対応できる能力を持たせることができるか、が大事である。

すると、運用経験のフィードバック、新たな能力に関する要求仕様の策定と開発・試験・評価・戦力化、不具合の解消といったプロセスを継続的に回すことが必要になるし、それを円滑に実現できるようなアーキテクチャが求められる。レーダーの探知距離に代表されるような、カタログに現れやすいスペックが立派なだけではダメなのだ。

なお、ソフトウェアは開発・試験を経てインストールすれば能力向上や新機能の追加が可能だが、必要とするセンサーなどの欠落やコンピュータの処理能力不足に見舞われることも考えなければならない。すると、ハード/ソフトの両面から、ロードマップを策定して継続的に更新を図る必要がある。

ハード/ソフトの継続的更新と試験の体制

そこで前回に取り上げたオープン・アーキテクチャ化の話とも関わってくるが、現代のイージス戦闘システムは、そうした継続的な改善を前提とした設計になっている。ハード/ソフトを機能別にモジュール化してインタフェースに関する仕様を定めておくことで、個別のモジュールを単位とした能力向上や不具合の解消、あるいは新機能の追加といった作業を容易に進めることができなければ、現代のウェポン・システムは成立し得ない。

また、長期にわたって多数の艦を建造したことから、建造時期によってベースラインが異なり、能力面の不統一や保守管理の困難さという課題につながっている。そこで、入渠整備に合わせてアップグレード改修を行い、この面でも問題解決を図っていこうとしている。

そして、現在は後付けの形で実現している弾道ミサイル防衛関連機能についても、今後はイージス戦闘システム自体のアップグレードに関するロードマップに取り込んで、システム全体の能力向上を図る際に、その一環として弾道ミサイル防衛機能も実現する方向になっているようだ。

そこで重要になる考え方は、「一気に最終完成版を作ろうとしない」ことである。とてつもなく大きな目標を掲げて突っ走るのは、物語としては面白いが、開発担当者は苦労が増える。そしてリスク要因が増えて、スケジュール遅延やコスト上昇につながる原因にもなる。そこで、ハード/ソフトの両方について継続的な改良を図ることを前提として、開発・試験・評価・配備の作業を少しずつ進めていく考え方につながる。

その試験・評価に際しては、できるだけ実運用環境(ウェポン・システムであれば実戦である)に近い環境下でテストして、開発中のシステムをとことん「いじめる」必要がある。もちろん優秀な開発者は必要だが、優秀なテスト担当者も同じように重要である。

ソフトウェアの開発やテストに携わった経験がある方ならお分かりの通り、通り一遍の動作試験を行っているだけでは不具合がいろいろ残る。普通なら起きそうにないこと、本来の手順から外れた操作、仕様の限界、あるいはそれを踏み越えかねない状況。そういったところまで可能な限りテストケースに取り込んで、時間とリソースが許す限り、とことんテストする必要がある。

それでも、いざ現場に出すと不具合が出ることはあるから、それについてフィードバックを受けて、速やかに対処できる体制を作る必要もある。イージス艦も最初に実任務展開を始めた頃はいろいろと不具合が出たが、それを現実的な対処によって乗り越えたからこそ、今の発展や評価があるのだ。

マイヤー少将のシステム・エンジニアリング哲学

軍の装備品に限らず企業の情報システムでも同じだろうが、「必要な機能を持たせる」ことだけでなく、「必要なときに間に合う」ことも重要である。そうなると、必要とする機能・仕様についてすべてを一気に実現しようとするのではなく、優先順位をつけて、優先順位が高いものから順に開発・試験・評価を経て実装する必要があるのではないだろうか。

そうなってくると、システムそのもののコンセプトだけでなく、開発作業のマネージメントや優先度の設定など、開発・試験・評価のあらゆるフェーズにおいて、フラフラしないで腰の据わった取り組みを行えるプログラム・マネージャが必要になるのではないか。

その点、イージス戦闘システムの開発計画が最初に立ち上がったときの米海軍は人材に恵まれていた。それがウェイン E.マイヤー海軍大将(退役)だ。イージス戦闘システムの開発における同少将の多大な貢献を短くまとめるのは困難だが、同少将が掲げたシステム・エンジニアリング哲学を構成する以下の三項目は、注目に値すると思う。

  • 小さく作って、小さくテストして、そこから多くを学ぶ(Build a Little, Test a Little and Learn a Lot)
  • 飽くなき優秀性の追求
  • 費用対効果

こうした人材に恵まれるかどうかも、できあがったシステムの良し悪しに少なからず影響するのではないだろうか。

もっとも米軍のウェポン・システム開発を見ていると、常にこうした原則を適用できているとは限らず、大風呂敷を広げて収拾がつかなくなった挙げ句に計画放棄、といった事例も結構多い。担当者に恵まれたかどうか、周囲の状況に問題がなかったか、余計な横槍が入らなかったか、といったところが大きく影響するのだろうか。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。