延命改修(7)形態管理

会社で「IT部門責任者」みたいなポジションにいる方なら理解していただきやすいと思うが、社内で使っているコンピュータ機器の機種・仕様・ソフトウェアの種類がバラバラだと、運用管理も保守も面倒になる。実はウェポン・システムの世界も同じである。

長く作っているといじりたくなる

最近はウェポン・システムの高度化・高コスト化が進んでいるため、「短期間で一気に作ってしまう」のではなく「長期間にわたってチビチビ作る」傾向が強い。

ことに軍艦は、モノが大きくコストが高いので、数をそろえようとするとどうしても、建造期間は長期にわたる。米海軍のアーレイ・バーク級イージス駆逐艦のごときは、四半世紀にわたって建造が続いている。

筆者が大学生の時に「アーレイ・バーク級はこんなフネになる!」という記事を見たことがあるが、その筆者が齢50を迎えても、まだアーレイ・バーク級の建造が続いている。これだけ長期にわたって建造していれば、製作・運用の経験を反映させた改良を盛り込みたくなるのは当然の話で、造っているうちに仕様が少しずつ変わってくる。

よって当然のことながら、初期の艦と最新の艦は「見た目は似ていても中身は別物」である。イージス戦闘システムは、ハードウェアやソフトウェアの違いによって複数の「ベースライン」に分かれているが、大きく分けただけでもベースライン4、同5、同6、同7、同7.1、同9がある。

駆逐艦と比べると数は少ないが、ニミッツ級空母だって同じだ。同型艦としてひとくくりにしていても、フネごとに細かい違いがあるのは、よくある話である。その昔のフォレスタル級空母なんかひどいもので、1隻ごとにレーダーを載せる位置が違っていた。

戦闘機にしても事情は同じで、長いこと造っていれば改良を取り入れたくなる。第166回で取り上げた航空自衛隊のF-15Jが「Pre-MSIP」と「J-MSIP」に分かれているのが典型例。

実は延命改修についても事情は同じで、改修を短期間に一挙に行うのであればまだしも、毎年のように少しずつ予算をつけて少しずつ改修していくと、ここでもまた「長くやっているといじりたくなる」法則が発動する。だから、延命改修後の車両・機体・艦を並べてみると、改修時期によって少しずつ仕様が変わるようなことが起きる。

形態の標準化を目指すべき

すると、冒頭で触れた社内のパソコンと同じような問題が、より大規模かつ高コストな形で露見する。

例えば、コンピュータやその他の電子機器の機種が違えば、保守部品を別々に用意しなければならない。機種が2倍になれば在庫も2倍である…　とは限らないが、増えるのは確か。

ソフトウェアで動くものなら、ソフトウェアの保守管理やバグフィックスやアップデートも必要になるが、コンピュータの機種やオペレーティング・システムの種類が違うと、別々にソフトウェアを用意しなければならない。ソースコードを同じにしてビルドし直すだけで済むようになっていればいいが、そうはいかないことも少なくないだろう。

運用する側からいっても、ハードウェアやソフトウェアが変われば機能的な差異が生じるし、マン・マシン・インタフェースの部分が変わるから、操作方法を覚え直す手間がかかる。覚え直すためにはマニュアルが必要だから、そのマニュアルを製作したりメンテナンスしたりする手間も上積みされる。

といった具合なので、複数の形態・仕様が入り乱れていると、雪だるま式にコストが膨らむ要因になる。しかも能力的な差異や操作性の差異があれば運用の効率を引き下げるから、それも見えないコストとしてのしかかってくる。

したがって、できるだけ形態を標準化する努力をしなければならない。米海軍はそのことをよく分かっているから、イージス戦闘システムのうち旧いベースライン4やベースライン5を搭載している艦について、ドック入りに合わせてシステムをごっそり入れ替える作業を進めている。第114回で触れたACB(Advanced Capability Build)とTI(Technical Insertion)の話がそれだ。

ソフトウェア制御化の利点

といっても、「すべて同一形態にそろえるべき」は理想であるものの、実現しようとすると難しい面もある。

そもそも、同一形態にそろえようとすれば調達費の支出が集中的に発生するので、短期的には出費がかさむ。まずこれが最初のハードルになる。実はそれだけでなく、短期間に一気に調達して同一仕様にそろえると、それが陳腐化・老朽化したときの代替もまた、短期間に一斉に発生することになるという問題が出てくる。

つまり何年間かのスパンを置いて、機材の調達や、それを更新するためのコストが間欠的に、かつ多額に発生することになる。できればコストは平準化したいところだが、そうすると調達や更新が長期に渡り、仕様をそろえるのが難しくなる。

その問題をいくらかでも緩和したいところだが、それにはソフトウェア制御化がひとつの助けになるかもしれない。つまり、同じハードウェアのままでも、ソフトウェアの改良によって問題を解決できないか、という話だ。

例えば、計器やボタンやスイッチを並べる代わりに、その部分を大画面のタッチスクリーンにしておけば、マン・マシン・インターフェイスをどう構成するかはソフトウェアだけで決定できる。

物理的なスイッチを配置する場合、ハードウェアを替えないと仕様を統一できないが、物理的なスイッチがなければ事情が変わる。マン・マシン・インタフェースの出来が悪いから改良したいという話が出た時も、ソフトウェアの改良だけで済む。

電子回路を物理的な回路として作り込むと、それを改良したり新しい機能を追加したりする時は、回路基板を取り換えるか追加するか、という話になる。でも、ソフトウェアの変更だけで済むならハードウェアは変えずに済む。新しいソフトウェアをインストールしたからといって機器が大きくなるわけではないし、重量が増えるわけでもない。

その典型例がソフトウェア無線機。同じハードウェアのままでソフトウェアを追加することで、新しいウェーブフォームに対応できる。最初に苦労してソフトウェア無線機という基盤を作っておくことで、後の機能追加や改良や不具合対処が楽になるかもしれない。