ソフトウェアの観点から見た将来戦闘機(9)試験・評価は大丈夫？

前回は「どんな要素技術を作るか・使うかという話もさることながら、まず将来の航空戦の様態がどうあるべきかというコンセプトや、そこで戦うためのアーキテクチャ作りが必要」という話を書いた。その話が、今回の話にもつながってくる。

試験・評価を忘れちゃいませんか

戦闘機に限ったことではないが、「技術的に実現可能なのか」「製造できるのか」といった話について語る人は多い。そして、ネット上で口角泡を飛ばし合っている場面もちょいちょい目にする。しかしである。

どんな工業製品でも、いや、工業製品に限ったことではないが、モノを作ったらそれで終わりではない。計画通り、設計通りの機能・性能を発揮できるかどうかを確認しなければならないし、それを実際に運用する環境に放り込んでみて、ちゃんと使えるかどうかも検証しなければならない。

F-35Aの初号機がロールアウトしたのは2008年12月19日のことだが、SDD(System Development and Demonstration、システム開発・実証)フェーズの飛行試験がすべて完了したのは2018年4月12日だった。つまり10年近い月日を費やしている。10年というと長い月日で、生まれた子供が小学校4年生に上がるぐらい長いスパンだが、そんなに時間がかかったのは、なぜか。

それは、テストすべき項目が膨大で、それを一つ一つ消化するにはべらぼうな時間を要したから。途中で、大きなトラブルが生じて試験が足踏みすることもあっただろうが、それがなかったとしても、劇的に時間短縮を図ることができたかというと疑問がある。

その試験も、いろいろな種類がある。最初は「飛行機としての試験」であり、問題なく飛べるかどうか、そこで所定の性能が出ているかどうかの確認が主なものになる。

それをクリアすると次に、ミッション・システムの試験が始まる。各種のセンサー機器が能書き通りに動作して、所定の性能を発揮できているかどうか。それぞれ単品の試験だけでなく、組み合わせた場合の試験も行わなければならない。なにしろF-35の売りの1つには「センサー融合」機能があるのだから。

これらはいずれも「開発試験」に属する分野の話だが、開発試験が完了しても、まだ終わりではない。その後には、実戦的な環境や運用シナリオに放り込んでみて、ちゃんと使えるかどうかを確認する運用評価試験(IOT&E : Initial Operational Test and Evaluation)が待っている。

• 英空母「クイーン・エリザベス」艦上でF-35Bの艦上運用試験を実施した時は、緊急時にしか行わない「逆向き着艦」(機体の向きと艦の向きが逆)もテストしていた 写真 : jsf.mil

大変なのはテストケースを作ること

実際に何かを作って、テストした経験がある方ならお分かりかと思うが、テストの際に何が大変かというと、テストケースを作ることである。つまり、「こういうシナリオの下で、こういう条件を与えてテストすれば、問題ないことを確認できる」という、そのシナリオや条件を定める作業だ。

実際にどんな環境の下で、どんな使われ方をするかが分かっていなければ、テストケースを作ることはできない。当然である。まず、使われ方が分からなければシナリオを書けない。そして、それがどういう環境下で行われるかが分からなければ、条件値の項目やその範囲を定めることもできない。

テストケースの設定に問題があると、テストを終えたブツを実戦部隊に配備した後で、不具合の報告が上がってくることになる。実際にそういういわれ方をするかどうかはともかく、実戦配備後の不具合報告は「テストをちゃんとやっていなかったじゃないか」という無言の叱責だ。

だから、そこでも「運用コンセプトやアーキテクチャを定めること」の重要性が効いてくる。なぜなら、それらが「どんな環境の下で、どんな使われ方をするか」を規定するから。

逆に、「想定しているライバル機よりも性能のいい機体を」ぐらいの了見で開発を始めてしまったら、テストケースを定めるためのベースラインが実質的に存在せず、せいぜい既知のシナリオでやるしかなくなる。それでは、開発試験でも、それ以上に運用評価試験の段階でも、途方に暮れることになりかねない。

自動車やタイヤのメーカーは、いろいろな環境条件、いろいろな路面条件でのテストを行っているが、その中には「日本国内のことだけ考えていると、想像もつかないこと」だって含まれている。わかりやすい例を挙げると、石畳の道は日本だと極めて少ないが、ヨーロッパに行けばたくさんある。

戦闘機も同じだ。決まり切った、通り一遍の運用環境やシナリオだけ考えてテストケースを書くと、往々にして、そこで「漏れ」が生じてしまう。「漏れ」を生じないようにするには、運用環境や運用シナリオに関する、多種多様な経験・知見とを持っている必要があるし、さらに将来予察も求められる。

ことにソフトウェアが絡むと、テストケースの設定は難しくなる。「まさかこんなことが、という操作をしたらバグが出た」「特定の条件が複数セットになった場合に限ってバグが出た」なんていう経験をお持ちの方は少なくないだろう。

• 飛ばすだけがテストではない。低温あるいは高温環境下で、機体が問題なく機能するかどうかをテストするプロセスもある 写真 : USAF

試験で不具合が出るのは当たり前

F-35の開発試験や運用評価試験に時間がかかるのも当然のこと。過去の運用経験(ありていにいえば実戦経験)の蓄積、世界のさまざまな場所で戦闘機を飛ばしてきた経験、そうしたものを反映させてテストケースを作っているはずで、それは確かに時間がかかるはずである。

そして当然ながら、さまざまな厳しい条件下で “いじめる” ことで、不具合がいぶり出される。しかし、実戦配備と実運用を始めてから不具合が露見するよりも、その前のテストの段階で不具合が露見するほうが、よほどいい。テストの段階で何も問題が出ないことは、決して自慢にならない。叩いて叩いて叩きまくって、不具合を見つけ出してはつぶすのがテストなのだから。

そのテストがちゃんとできるのか、次世代戦闘機をテストするための有用なテストケースをそろえるに足る、経験・知見の蓄積は大丈夫なのか。そういう観点の論陣を張っている人は、滅多に見かけないのが実情であろう。