航空機というと、空を飛ぶ「ハードウェア」との認識が色濃い製品ではないかと思われる。しかしこれも他の分野と同様、コンピュータ制御で機能する部分が増えてきたため、ソフトウェアなしでは動作しない状況になっているのが実情だ。

ソフト屋さんの仕事が増えている

すでに本連載でいろいろ取り上げてきている通り、いまどきの航空機は操縦でもエンジンでもその他の部分でも、コンピュータ制御になっている部分が非常に多い。

よくいわれるように「コンピュータ、ソフトなければただの箱」だから、コンピュータ制御で動作する部分が増えれば、それだけソフトウェアを記述しなければならない部分も増える。つまりソフト屋さんの仕事が増える。

その典型例がF-35で、F-35のために記述しなければならないソフトウェア・コードのソースコードは1800万行分だとか2200万行分だとか2400万行分だとか、さまざまな数字が出回っている。昔よりも最近の方が、出回る数字が大きくなってきているように思える。

ことにF-35の場合、機体やエンジンはいうまでもなく、レーダーを初めとする各種センサー、そのセンサー群からの情報をとりまとめるデータ融合機能、通信・航法・識別(CNI : Communication, Navigation and Identification)、搭載する各種の武器、そして地上で使用する任務計画立案や保守・整備・兵站支援関連の機能など、幅広い分野でさまざまなソフトウェアを記述しなければならない。

そして、それぞれの機能ごとに別々のメーカーが関わっている以上、ソフトウェアの開発に関わるメーカーも複数存在することになる。また、センサーとCNIと兵装は互いに連接して連携動作しなければならないから、「すり合わせ」という問題も生じる。民航機でも似たような話はあるだろう。

すでに連載「軍事とIT」で言及したことがあるので御存知の方も多いだろうが、F-35で使用するソフトウェアは、これまでアメリカの軍用コンピュータで多用していたAda言語ではなく、C++言語で記述している。そちらの方が開発者を確保しやすいという理由ではないかと思われるが、ただ頭数だけいればよいという問題ではない。

むしろ、頭数が多くなれば、違った種類の問題が出てくる。

多数の開発者が関わる際の課題

なにも航空機やウェポン・システムで使用するソフトウェアを開発するときだけの問題ではないが、多数の開発者が参加してひとつの大プロジェクトを推進しようということになると、開発体制、開発のためのインフラ、という課題が生じる。

たとえば、すべての開発者をひとつところに集めて作業させるわけではないから、各地に分散した開発者と、それらのとりまとめを担当するシステム・インテグレーターを結ぶ、安全で信頼性の高いネットワークを確保しなければならない。

また、多数の開発者が記述したソースコードを受け入れて、管理するためのインフラやシステムも必要になるのはいうまでもない。当然、バージョン管理の機能だって必要である。

また、長期に渡って使用するソフトウェアだから、担当の開発者が途中で交代することを前提にしなければならない。そこで、誰が見ても意味を理解できるコードを書けるように、ソフトウェア開発者向けのガイドラインを作って配布している。コードの書き方だけでなくコメントの書き方まで指示している、念の入った代物だ。

そして、開発者がどんなに頑張ってもバグは出るものだから、バグ情報の管理・レポーティングを司るシステムも整備しなければならない。開発者が各所に分散していれば、その分散した開発者の誰もがアクセスできる環境を構築しなければならないが、これはネットワーク・インフラの問題と一体といって良いかも知れない。

なお、バグ管理ということになると、開発者だけでなく、試験担当者も関わってくる。しかも、F-35では飛行試験を実施している場所が一ヶ所ではなくて、エドワーズ空軍基地(カリフォルニア州)だったり、パタクセントリバー海軍航空基地(メリーランド州)だったり、ときには洋上の揚陸艦や空母だったりするのだ。

そして前回に取り上げたように、一回の飛行試験でもべらぼうな量のデータが集まるから、それらを蓄積するリポジトリや、解析するためのツール、解析結果をソフトウェア開発に反映させるためのワークフロー、といった課題も出てくるだろう。

なんにしても、こういったシステムを構築する際に専用のツールやソフトウェアを開発すれば、今度はそちらの開発やテストにかかる手間が膨大なものになってしまい、開発のための開発という無限ループが起きてしまう。だから、F-35計画では既製品のソフトウェアを活用して開発環境を整備しているという。

たまたま情報がいろいろとあったのでF-35計画を引き合いに出したが、当節、ソフトウェアのお世話にならないで飛べる航空機というものは存在しないから、軍用機だろうが民航機だろうが、程度や規模の差はあっても、ソフトウェア開発のための環境整備・体制整備といった苦労はついて回る。

そして、そのソフトウェアが開発計画全体の動向を左右したり、足を引っ張ったりする場面が日常化している。ソフトウェア制御化によって便利になったことはいろいろあるのだが、開発やテストが大変になったとはいえるかも知れない。

執筆者紹介

井上孝司

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