Mobile menu

要件管理から学ぶ教訓：単位変換の失敗

Mihajlo Djordjevic

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

At a Glance

3つの単位変換にまつわるエピソードは、数値がエンジニアリング作業の指針となるためには、単なる値以上の情報が必要であることを示しています。

Go Deeper with AI:

ハードウェア製品開発では、エンジニアは日々さまざまな数値をやり取りしています。値はエンジニアから図面へ、仕様書から部品へ、あるいは自分たちのチームからサプライヤーへと受け渡されます。ほとんどの場合、これが問題なく機能するのは、関係者全員がその数値の意味と使われている単位を理解しているからです。

リスクが表面化するのは、その値が引き継ぎの境界をまたぎ、受け渡しの両者が同じように読んでいないときです。一方はポンドで作業しているのに、もう一方はキログラムを想定しているかもしれません。ある文書は古いヤード・ポンド法ベースの設計を使っている一方で、新しいプロジェクトはメートル法かもしれません。数値そのものは双方で正しく見えても、もはや同じ判断を導くものではなくなっています。

以下の3つのエンジニアリング事例は、こうしたことがいかに簡単に起こり得るかを示しています。

3つの事例、1つの共通パターン

3つの時代にまたがる3件のエンジニアリング上の失敗は、それぞれ異なる形で同じ引き継ぎの問題を示しています。いずれのケースでも、ある数値がワークフローの一部から別の部分へ移されました。その数値は利用者には正しく見えましたが、実際には2つの異なる計測単位系が関わっていました。引き継ぎの場面で、その数値がどの単位を使っているのかが明確にされていなかったのです。

エア・カナダ143便：ギムリー・グライダー

最初の例は、1983年のギムリー・グライダーです。これは、航空会社であるエア・カナダがヤード・ポンド法からメートル法へ移行した際に何が起きたかを示しています。モントリオールからエドモントンへ向かっていたボーイング767の143便は、同社初のメートル法対応機でした。

その日、燃料量表示システム（FQIS）が作動していなかったため、乗務員は手作業で燃料を測定しました。補給担当者が使った密度値は1.77で、これは他の機体群で標準だった「ポンド毎リットル」でした。しかし、そのメートル法対応の767が必要としていたのは「キログラム毎リットル」であり、正しい値は約0.8でした。

その結果、機体は乗務員が想定していた半分の燃料しか積まずに離陸し、飛行中に両エンジンが停止しました。幸いにも、パイロットは安全に着陸させることに成功しました。

Mars Climate Orbiter

その16年後、 Mars Climate Orbiterは、ヤード・ポンド法の単位をメートル法に変換し損ねたことによる航法エラーのために失われました。Lockheed Martinのソフトウェアは、スラスターのデータをポンドフォース秒で送信していました。一方、NASAの航法ソフトウェアはニュートン秒を想定しており、これはポンドフォース秒とは4.45倍の差があります。

この探査機は、火星上空150～200キロメートルの軌道に投入される予定でした。しかし実際には約57キロメートルまで降下し、火星の大気圏で燃え尽きてしまいました。

東京ディズニーランドのSpace Mountainローラーコースター

2003年には、東京ディズニーランドのSpace Mountain roller coasterでも、設計図面を通じて同様の問題が表面化しました。このアトラクションは1995年にヤード・ポンド法からメートル法へ図面が引き直され、その際、車軸径が44.14ミリメートルから45ミリメートルに変更されました。しかし古い図面は使用停止にされず、その結果、2種類の設計図面が併存することになりました。

2002年、新しい車軸一式が再発注された際、その注文は1995年以前の設計版に基づいて行われました。その結果、部品は必要寸法より小さい状態で納入されました。この0.86ミリメートルの差によって、ベアリングのクリアランスは意図より大幅に広くなりました。数か月の使用後、車軸は破断しました。

これら3つすべての事例に共通するのは、数値そのものは疑わしく見えなかったという点です。問題が始まったのは、その数値が次のエンジニアリング工程の判断基準になったときに、その単位や出典が十分に明確でなかったことでした。

この図解が示しているのは、ある値が誰にとっても正しく見えても、それでもなお間違っている可能性があるということです。引き継ぎの両者は、本当に同じ単位で合意できていますか。

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

ほとんどのハードウェアチームは、航空機を飛ばしたり宇宙機を打ち上げたりしているわけではありません。しかし、同様の引き継ぎは毎日起きています。値は要求から図面へ、仕様から部品へ、あるいは自分たちのチームからサプライヤーへと移動します。どの引き継ぎにおいても、単位は数値と一緒に維持されなければなりません。これに役立つ実践は3つあります。

すべての要求値に単位を明記する

数値だけでは不十分です。「45」だけでは、次の担当者は何を作るべきか、何を試験すべきか分かりません。「45 mm」であれば、その数値に意味が生まれます。単位は常に値のすぐそばに置いてください。これは単なる書式上の細部ではなく、要求の一部です。

エンジニアリングの引き継ぎに責任者を割り当てる

単位の取り違えは、情報があるチームから別のチームへ移るときによく発生します。一方はある基準を前提にしている一方で、もう一方は別の基準を想定していることがあります。こうした引き継ぎには、明確な責任者が必要です。値が下流工程で使われる前に、誰かが単位系、データ形式、元文書を確認すべきです。

要求とエビデンスのトレーサビリティを維持する

ある値が変更されたとき、チームは何がその値に依存しているかを把握できなければなりません。つまり、要求、図面、部品、試験、エビデンスは、互いに切り離された断片として存在していてはならないのです。 Traceabilityによって、チームはその値がどこから来たのか、何がそれを使用しているのか、変更時に何を見直す必要があるのかを把握できます。

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

より良い要求ワークフローでは、数値、その単位、責任者、元文書が互いに近い関係のまま保たれます。値を、表計算、図面、仕様書の中にある単なる孤立した数字として扱いません。

これは特に引き継ぎ時に重要です。ある値が要求から設計作業や検証へ移るとき、次の担当者はその値が何を意味するのか、どの単位を使っているのか、どこから来たのかを確認できます。値が変更された場合も、チームは何をレビューすべきかを把握できます。

Altium Requirements Portalは、要求、責任範囲、トレーサビリティ、検証作業を1つの共有環境に保つことで、この種のワークフローを支援します。これはエンジニアとしての判断を置き換えるものではありません。値が下流工程で使用される前に、その単位、責任者、および関連するエンジニアリング上の文脈を見える形で維持するのに役立ちます。

重要なポイント

単位の取り違えは、多くの場合、値が別のチーム、文書、またはシステムへ移される引き継ぎ時に始まります。そしてその単位が明確にされていないのです。
数値が次のエンジニアリング工程の判断を導く前に、チームはその値がどこから来たのか、誰が責任を持っているのかを把握しているべきです。
トレーサビリティは、値が変更されたり下流工程へ渡されたりする前に、何がその値に依存しているのかをチームが把握するのに役立ちます。

プロジェクト内のすべての数値は完全ですか？

これらのインシデントは、いずれも防ぐことができたはずです。より優れたエンジニアリングが必要だったのではなく、引き継ぎ時に明確な問いを立てることが必要だったのです。

要求内のすべての値に単位は付いていますか。
チーム間のすべてのインターフェースに責任者はいますか。
どの版の仕様書が現行版なのか明確ですか。
もし明日何かが変わった場合、何をレビューすべきかをあなたのプロセスは示せますか。

では、同じ質問を自分のプロジェクトに対して投げかけてみてください。これらのどれかに対する答えが「たぶん」なら、どこから始めるべきかはすでに見えているはずです。

チーム全体で使える要求管理ツールを活用して、重要なエンジニアリング情報をあらゆる引き継ぎで明確かつ容易に確認できる状態に保ちましょう。

Requirements Portalを使い始める →

よくある質問

なぜエンジニアリングプロジェクトで単位変換エラーが起こるのですか？

こうした取り違えは、計算ミスが原因であることはほとんどありません。問題は引き継ぎで起こります。つまり、値がチーム間、ツール間、文書間を移動するときです。一方はその値をある単位だと思い込み、もう一方は別の単位として読み取っている場合があります。値自体は正しくても、前提が誤っていれば間違った使われ方をしてしまいます。

完全な要求値には何を含めるべきですか？

完全な要求値には、その数値、単位、そして正しく使用するために必要な文脈が含まれるべきです。たとえば「45」では不十分で、「45ミリメートル」である必要があります。加えて、その値が適用される条件、元文書、そしてその要求の責任者についてもチームが把握する必要がある場合があります。

トレーサビリティはどのように引き継ぎミスの低減に役立ちますか？

トレーサビリティは、ある値を、それに依存するあらゆるものへ結び付けます。最上位の要求から、その背後にある部品、試験、責任者に至るまでです。値が変更されたとき、こうしたつながりがあれば、ほかに何をレビューすべきかを見つけやすくなります。これにより、古い仕様、不明確な単位、または古くなった試験が誤って使われ続ける可能性を減らせます。

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