RDT&Eというと業界用語丸出しだが、「研究(Research)」、「開発(Development)」、「試験(Test)」、「評価(Evaluation)」の頭文字をとった略語である。ちょうど2年前に筆者が取材に行った航空自衛隊向けF-35Aのロールアウト式典に限らず、開発中の新しい装備品が完成してお披露目されると、もうそれで完成だと思ってしまう。しかし、実はその先が長い。

テストにかかる手間は膨大

ソフトウェアの開発を考えてみれば、容易に理解できる。コードを書いて、ビルドして、実際に走らせるプログラムが出来上がり。これが、飛行機でいうところの「初号機のロールアウト」みたいなものである。

しかし、書いたコードがいきなり完全無欠ということはあり得ない。運用環境や操作の仕方によっては、想定した通りの動作をしてくれないこともある。そこで、さまざまな場面を想定したテストケースを用意して、1つずつ試して、バグが出たら直す。

防衛装備品も同じである。もちろん、さまざまな研究や検討を重ねて設計・製作するわけだが、それでも、完成したものをテストすれば必ず不具合は出る。不具合が出ることが問題なのではなく、不具合を見落としたまま現場に出すことが問題なのである。

ことに最近では、ソフトウェア制御のものが多くなってきた。このことがさらにテストの負担を増やしている。実際にプログラムを書いた経験がある方ならおわかりの通り、仕様通り・通り一遍の操作をした時にちゃんと動くものを作るだけなら、まだマシ。

そこから外れた条件が発生した時に、ちゃんと動くかどうか。そこで暴走したりハングアップしたりといった問題を起こさないようにコードを書く必要があるし、それを検証する必要がある。

それがいかにしんどい作業であるか。さまざまなソフトウェア製品で毎月のように、セキュリティ上の脆弱性が報告され、修正プログラムがリリースされている現状が、しんどさを物語っているといってよい。セキュリティ上の脆弱性というのは多くの場合、「通常なら発生しないはずの状況」が発生したときに露見するものだから。

そうやって製品の不具合をつぶす「開発試験」に加えて、防衛装備品にはもう1つの試験がある。運用評価試験である。米海軍ではOperational Evaluation、略してOPEVALといっているが、IOT&E(Initial Operational Test and Evaluation)という言葉を使っている組織もある。

これは、実際に運用現場(ありていにいえば戦場)でどういう使われ方をするかを想定して、そのシナリオに沿って実戦に即した使い方を試してみる作業のこと。

それと併せて戦力化の作業も発生する。つまり、長所や短所を把握して、フルに能力を発揮させるとともに弱点をつかまれないようにするための、ノウハウ作りである。

ITによるRDT&Eの負担軽減

ここまでは、モノができた後のテストの話だけを書いたが、もちろん、よりよい製品を送り出すための努力は研究・開発・設計の段階から始まっている。

その、研究・開発・設計から完成後の試験、さらに戦力化に至るまでのプロセスにおいて、ITがどう関わっているか。それを今回のテーマとする。

昔なら紙と手作業でやっていた作業の多くが、今はコンピュータ上で処理できるようになっている。また、試験の際のデータ収集とその後の解析は、情報通信技術の進化による恩恵を大きく受けてきた分野である。

それなら、その辺の話を紹介できるのではないか、というわけだ。そして、RDT&Eのプロセスがいかにしんどいものかを知っていただければ、「ロールアウトすなわち完成」という勘違いから脱却することもできる。

  • 航空自衛隊向けF-35A初号機のロールアウト式典は、2016年9月23日に行われた。機体の前でスピーチしているのは、斉藤航空幕僚長(当時)。だいたい、ロールアウト式典というのはこんな雰囲気である

例えばF-35。この機体、初号機がロールアウトしたのは2006年7月7日のことだが、その後に機体を追加製作しながら開発試験を進めていって、開発試験がすべて完了したのは、なんと2018年4月11日のことである。つまり12年近くかかっている。

その間に実施した飛行試験は、トータルで9,200ソーティ(1機が1回のフライトを実施すると1ソーティと数える)。飛行時間の累計は17,000時間。試験ポイント(試験による検証の対象になった項目)は65,000点あまり。

また、短距離離陸・垂直着陸を行うF-35Bでは1,500回の垂直着陸を実施した。しかし、戦闘機だから武器を積んで、かつ発射や投下を行えなければならない。そこで実施した兵装分離試験は183回、命中精度検証試験(WDA : Weapons Delivery Accuracy)は46回に達する。

その気の遠くなるような試験の過程で、いちいち大量のデータを収集・解析していた。あいにくと、収集したデータが何テラバイトあったのかは明らかにされていないが。そもそも、テラバイト単位なのか、もっと大きいのかもわからない。

情報通信技術を駆使して、試験を効率的に進めようとしてもこれだから、情報通信技術の支援がなかったら、どんなことになっていたか。あまり意味のない想定ではあるが、そんなことも考えてしまう。

というわけで次回からは、RDT&Eの過程でどんなプロセスがあって、そこでコンピュータや通信技術をどんな風に活用しているか、という話をいろいろ取り上げていこうと思う。

著者プロフィール

井上孝司


鉄道・航空といった各種交通機関や軍事分野で、技術分野を中心とする著述活動を展開中のテクニカルライター。
マイクロソフト株式会社を経て1999年春に独立。『戦うコンピュータ(V)3』(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて『軍事研究』『丸』『Jwings』『航空ファン』『世界の艦船』『新幹線EX』などにも寄稿している。