投稿コーナー
先号　　次号

「きぼう」日本実験棟開発を振り返って (36)
―Adaではなくメーカー調整が問題だった！―

宇宙航空研究開発機構客員／PMマイスター　長谷川　義幸　[プロフィール]　：11月号
　1995年に「きぼう」開発プロジェクトのアビオニクスマネジャーに配属されて、驚いたのは搭載ソフトウエアに関するNASAの縛りがあちこちあることでした。何をさておき宇宙飛行士の命を守ることが最優先。そのため宇宙船のハードウエアはもとよりソフトウエアに関しても厳しい安全開発保証を参加国に要求していました。その範囲は宇宙に搭載される部分に限るのかと思っていたら、ソフトウエアを開発するソフトウエアも、検証ツール(コンパイラ、デバッガー)のソフトウエアも対象にしていました。このため、使用前にそれらもコンフィギュレーション管理下に置き、ツールの修正や更新がなされた場合、変更後の確認や変更記録が確実になされなければならないのです。ソフトウエアは、特に設計者の設計誤り、条件分岐の多様性によるすべての検証には困難さがあるため、重要なソフトウエアに関しては、関係者とは独立した者による妥当性、正当性の評価が重要になっていました。当時、パソコンでwindowsが使い勝手がよく実験の制御監視にと考えていたグループは、“windowsは医療や生命にかかわるものには使用しないでくれ。保証しない。”とメーカーの注意書きがあったので使用しないことにしました。そんな状況の中で、“「きぼう」の統合制御コンピュータのソフトウエアはエイダ(Ada)で、オブジェクト指向ですよ。”と担当から言われたが聞いたことのない名前だったので、“そんな言語があるの？”コンピュータの専門でない自分がこれと付き合わなければならないのか、先行き思いやられるとの思いが頭の中を走り回り嫌な感じがしました。以下は、筆者のその件に関する経験談です。

　NASAは、AdaをISS管理ソフトウエアの標準言語として採用、その理由は、「15年以上の長い運用期間で重要なのは保守が容易なこと」、「大規模なソフトウエアの改修や変更が発生するのでこれに対処するには読みやすく、保守し易い、信頼性の高いもの」、かつ「宇宙実験のテーマが多種多様で続々とテーマが変わっていくのでそのテーマに対応する頻繁な追加や変更に容易に対処できる必要がある」でした。要は、Adaは保守が容易、プログラム並行開発が容易、移植が容易、アッセンブラ言語の代替になる。ことが特徴でした。また、米国ではDODの軍用プログラムにAdaを使用しており、F-15、F-4Jなどで採用されていました。時代の最先端のものを規格として取り込むのがアメリカのやり方でした。

　ところが、日本ではこれを扱える会社が少なく、(1) 当時電話交換機や衛星通信、移動体通信の分野でこれを扱ってAda言語に精通していたNTTデータとNECが、「きぼう」統合制御ソフトウエアのOSとアプリケーションをサポートするOSのドライバーソフトウエアの開発担当になりました。また、三菱重工は、防衛省の戦闘機や魚雷などの開発分野でこの言語を扱っており、「きぼう」船内実験室のプライムメーカーであったので、アプリケーションソフトウエア開発担当になっていました。幸い私が心配していたAdaを用いた「きぼう」のプログラム開発は、開発3社と個別打ち合わせをしてインタフェース仕様をきめてゆくことで開発ツールの整備も解決していくことができました。また、心配していたAdaという言語の技術的な問題はなく、それより人間臭いメーカー間の作業調整が問題でした。私が驚いたのは、この3社の開発担当者との初顔合わせの中で、沢山の課題が山積しているとの先方の状況説明がありました。「では一つ一つ課題を解決していくために、定期的に課題解決会議をしませんか？　今までもやっていたかもしれませんが、膝をつめてじっくり決めていきましょう。いかがですか？」と提案したら、「ぜひ、お願いします。他社さんとの関係があり、今までの調整では、仕様を決められず開発を前に進めることができないで困っていました。是非ともお願いします。」と言われたことでした。JAXAの開発担当に、「仕様が決められないのはどうして？」と聞くと、「2社以上にまたがった課題が残っていて、両者の主張があわず、また、NASAがらみのインタフェースが絡んでいて、決められなかったのです。」「誰かが決めないと先に進まないのだから発注元のJAXAが決めていけばいいよ。責任者は私だから、合理的と判断できるものはその場で決めていけばいい。そして、プロジェクト全体に関わるものは、「きぼう」プロジェクトの設計会議で決めてもらえばいいから。」といったら、開発会社の方もJAXAのメンバーもほっとしたような顔をしました。そこで “今まできめられなかったのは調整する人がいなかったのか。”と原因が分かった気がしました。その後、NTTへは一か月に一回、ほかの2社は毎週出かけて行って朝から夕方まで1件1件課題を説明してもらい解決策をきめていきました。半年経過しても課題が沢山残っており、一体いつまで続くのかと思われたのですが、辛抱して毎週打ち合わせを続けていくと、案件が次第に減っていきました。途中から担当者同士が事前に調整するようになっていたのです。約1年間続けたところ案件が少なくなってきたので、2週間に一度の打ち合わせにし、やがて定例の月例会議の中で打ち合わせすれば足りるようになっていきました。(2)

　私は、コンピュータソフトウエアの専門家ではないし、「きぼう」のシステムのこともほとんど分かっていない状態で毎回打ち合わせの時心配でしたが、関係者の説明を理解して、自分の尺度で解決策のどれがいいのか、合理的に決めていけば何とかなるだろうと思ってやっていきました。私が理解できないものは、判断をオフィースに持ち帰ってから、メンバーに再度説明を求め内容を詰めるとともに、他のグループでこの件に通じているベテランと相談して判断をするようにしました。この作業で分かったことは、「誰かが決めればいいことを先延ばしに来たマネジメントのまずさ。」と「複数社にまたがる案件の調整方法をチームメンバーが知らなかったこと。」でした。関係者の間を“御用聞き”のように、動き回って話をしていくと解決策が見つかるのに、自分から動いていかないだけではないか、“ステークホルダーマネジメントなのだから、気軽に関係者のところに足繁く通い話をしにいきなさい。”とメンバーに何回も言ってました。今振り返ってみると、「きぼう」プロジェクトの大変さは、技術的な問題ではなく、沢山いるステークホルダーとのギクシャクした状況を改善して本来の軌道にのせるPMに問題があったためだと思っています。その証拠に、ISS無人貨物機「こうのとり」プロジェクトの本格始動段階では、「きぼう」のPM教訓が反映され、シャトル退役の追い風も吹いて非常にスムーズに開発と運用が進みました。

　Adaの歴史に少し触れます。1970年代アメリカ国防総省が組み込み系システムに使える信頼性と保守性に優れたプログラミング言語の国際入札を行いました。4件の提案の中からフランスのチームが採用され、整備されて、1983年にMIL-STD-1815として規格化されました。西洋諸国での軍事装置開発でスタンダードになりましたが、現在はボーイング社の旅客機などになお使われています。陳腐化しているとの意見もあります。ちなみに、世界で初めてのプログラマとされているイギリス貴族エイダ・ラブレスの名前にちなんでAdaと命名されているそうです。また、MIL-STD-1815の番号は、エイダ・ラブレスの誕生日(1815年)にちなんだものだそうです。(3)

参考文献：
(1) Ada(プログラミング言語)の歴史を紐解く | テクフリ (techcareer.jp)
(2) 長谷川　義幸著、「きぼうのつくりかたー国際宇宙ステーションのプロジェクトマネジメント」、地人書館、2018年
(3) エイダ・ラブレス - Wikipedia

ページトップに戻る