Mobile menu

要件管理から得られた教訓：Ariane 5 Flight 501

Mihajlo Djordjevic

| 投稿日 2026/08/3 月曜日

At a Glance

Ariane 5 の事故が、ハードウェア製品開発プロジェクトにおいて、再利用したエンジニアリング成果物・前提条件・検証チェックを見直す必要性をどのように示しているかをご覧ください。

Go Deeper with AI:

Ariane 5 Flight 501の事故は、過去のプロジェクトの要件、エンジニアリング設計、テストをそのまま再利用する前に、必ず立ち止まって再確認すべき理由を示しています。

ハードウェア製品開発では、以前のプロジェクトの要件、ソフトウェアルーチン、テストケース、設計判断を再利用することは一般的です。これは時間の節約になりますが、その選択を正当化していた条件が今も当てはまる場合に限ります。

Ariane 5 Flight 501は、1996年6月4日に行われた欧州のAriane 5ロケットの初飛行でした。このロケットでは、以前の欧州ロケットであるAriane 4で正常に機能していた慣性基準ソフトウェアの一部が再利用されました。しかし、Ariane 5は異なる飛行プロファイルに従っており、ある値がソフトウェアの想定範囲を超えたため、打ち上げから1分足らずでロケットは破壊されました。

教訓は単純ですが、忘れられがちです。過去のプロジェクトの成果を再利用する前に、新しいプロジェクトでも同じ前提条件と動作条件が成り立つかを確認することです。

重要なポイント

実証済みの要件、ソフトウェア、テスト、設計判断を再利用すると時間を節約できますが、以前の文脈は見直す必要があります。
再利用したテストケースを別製品で同じ要件の証明に使う前に、必ず見直してください。
要件、テスト手順、エビデンス、ステータスを関連付けて維持することで、リスクを低減できます。

Ariane 5打ち上げで何が起きたのか

1996年6月4日、Ariane 5はフランス領ギアナのクールーから初飛行を行い、欧州宇宙機関のCluster研究衛星4基を搭載していました。ミッションは1分も続きませんでした。飛行開始から約37秒後、ロケットは予定軌道から外れ、破壊されました。

問題は、姿勢と速度のデータをロケットのオンボードコンピュータに送る慣性基準システムにありました。Ariane 5ではAriane 4のソフトウェアが再利用されており、打ち上げ後約40秒間動作し続けるアライメントルーチンも含まれていました。このルーチンはAriane 4では機能していましたが、Ariane 5は異なる飛行プロファイルに従っていました。

その異なるプロファイルにより、いくつかのことが立て続けに起こりました。

水平速度の値が、ソフトウェアの想定よりも大きくなりました。
ソフトウェアはその値を64ビット浮動小数点数から16ビット符号付き整数に変換しようとしましたが、値が収まりませんでした。
変換はオーバーフローし、慣性基準システムはこれをエラーとして扱って停止しました。
バックアップシステムも同じソフトウェアを実行していたため、同じ理由で停止しました。
有効な飛行データが失われた結果、オンボードコンピュータは代わりに診断データを使用し、誤った飛行指令を出したため、ロケットは破壊されました。

この事例が要件管理にとって有用なのはここです。再利用されたソフトウェアは以前には機能していましたが、先行ロケットから引き継いだ前提を抱えていました。つまり、この値は安全な範囲内に収まるという前提です。Ariane 5ではその前提を取り巻く文脈が変わっていたため、新しいシステムでもその前提を可視化し、あらためて確認する必要がありました。

この例が示しているのは、再利用されたエンジニアリング成果にもなお、1つのシンプルな確認が必要だということです。その背後にある前提は、新しいシステムでも依然として真なのか、という点です。

Ariane 5の事例からハードウェアチームが学べること

ほとんどのハードウェアチームはロケットを作っているわけではありませんが、実証済みの成果を常に再利用しています。たとえば、以前の製品のPCBブロックを新しい設計にコピーすることがあります。ファームウェアルーチンが新しいハードウェアリビジョンに移されることもあります。電源アーキテクチャが変わったあとも、テスト手順がそのまま残ることがあります。

これはごく普通のエンジニアリング業務です。再利用はチームの開発速度を高めます。重要なのは、要件、前提、検証チェックが新しいシステムでも依然として一致していることを確認することです。

再利用する要件を見直す

ある製品で機能した要件を、次の製品でも自動的に有効だとみなすべきではありません。文言自体は正しく見えても、それを取り巻く動作条件は変わっている可能性があります。たとえば、電流制限、熱的な範囲、インターフェース制約などは、ある設計では安全でも、別の設計では見直しが必要になる場合があります。要件を再利用する前に、チームは新製品が引き続き同じ前提条件の範囲内で動作するかを確認すべきです。

最も重要なエンジニアリング上の前提の中には、正式な要件として一度も書かれないものがあります。それらは設計メモ、古いテスト計画、あるいは誰かの記憶の中に存在します。こうした前提は、成果物が再利用されるときにリスクになります。前提が設計判断に影響するなら、チームはそれを検証チェックに結び付ける方法を持つ必要があります。そうでなければ、その判断がなぜ最初に安全だといえたのかという理由を見落としたまま、判断だけを再利用してしまいがちです。

要件が変わったらテストを見直す

前のプロジェクトで合格したテストケースが、次のプロジェクトでも同じことを証明するとは限りません。要件が変わった場合、あるいは要件を取り巻くシステムが変わった場合には、関連するテスト手順も変更が必要になることがあります。これは、チームがテストケース、受け入れ基準、コンプライアンスのエビデンスを再利用する場合に特に重要です。

つながった要件ワークフローが役立つ理由

より良い要件ワークフローでは、要件を独立したテキスト行として扱いません。その要件の背景にある理由、影響を受ける設計作業、そしてそれが今も有効かを示す検証作業と要件を関連付けて維持します。

何かが変わったときに最も重要なのは、まさにこの点です。再利用された要件は見た目には依然として正しくても、その背後にある前提が新製品と一致しなくなっている可能性があります。テストが存在していても、もはや正しい条件を確認していないかもしれません。

つながったワークフローでは、チームは重要な要素を近くに保つことができます。要件、その背景にある文脈、検証方法、手順、結果、エビデンス、現在のステータスです。古い文書やテストレポートを探し回る代わりに、エンジニアは何が関連付けられていて、何に追加の見直しが必要かを把握できます。

Altium Requirements Portalは、要件、トレーサビリティ、担当、検証作業を1つの共有環境で管理することで、この種のワークフローを支援します。これにより、要件とそれを取り巻くチェックがつながったまま維持されるため、チームは実証済みの成果をより確信を持って再利用できます。

あなたのプロジェクトで、昔の前提は今も正しいですか。

どのハードウェアチームも、実証済みの成果を再利用しています。これは避けるべき近道ではなく、より速く構築し、優れたエンジニアリング判断を次へ引き継ぐための実践的な方法です。

有用なのは、その再利用された成果の周囲で何が変わったのかを問うことです。

動作範囲は変わったか。
テストは改訂が必要か。
元の判断の背後にある前提は今も当てはまるか。

チームがこうした問いに答えられるようになると、再利用はより信頼しやすくなります。要件は単独で存在するのではありません。その背後にある理由、検証チェック、エビデンスが、製品の文脈が変わったときにチームが見直せるだけの近さで保たれます。

これが、Ariane 5が今日のハードウェアチームにもなお与えている教訓です。再利用は、その背後にある文脈がつながったままであるときに最もうまく機能します。

チーム全体がアクセスできる要件管理ツールで、再利用に関する判断をより確認しやすく、信頼しやすいものにしましょう。

Requirements Portalを始める →

よくある質問

エンジニアリング成果の再利用はリスクになることがありますか。

エンジニアリング成果の再利用は、製品の文脈が変わっているのに、元の前提、動作限界、検証チェックが再確認されない場合にリスクとなりえます。成果物は依然として正しく見えても、前のプロジェクトでそれを有効にしていた条件が、もはや当てはまらない可能性があります。

要件、テスト、設計判断を再利用する前に、エンジニアは何を確認すべきですか。

チームは、新製品が元のプロジェクトと同じ動作条件、インターフェース、制限値、受け入れ基準を使っているかを確認すべきです。また、関連する検証方法が新しいシステムでも依然として正しいことを証明しているかも確認する必要があります。

要件が再利用されるとき、トレーサビリティはどのように役立ちますか。

トレーサビリティにより、チームは要件が設計判断、前提、テスト手順、エビデンス、ステータスとどのようにつながっているかを把握できます。再利用された成果が新しいプロジェクトに移されたとき、こうしたリンクによって、何がまだ有効で、何に見直しが必要かを見極めやすくなります。

Altium's Requirements Solutions Explore Requirements Portal Guide to Requirements Portal Requirements Documentation

筆者について

Mihajlo Djordjevic is an expert in requirements management and systems engineering workflows. He brings over six years of experience in hardware, embedded systems, and technical content creation, with a background in writing educational and product-focused content for embedded development tools, PCB design workflows, and electronics engineering audiences. He is passionate about making complex engineering topics easier to understand and turning them into clear, practical content that helps technical teams improve the way they develop products.

その他のコンテンツ Mihajlo Djordjevic