「サクセスクライテリア（成功基準）とは？ 4つの宇宙開発事例で考える技術開発における成功と失敗」では、宇宙開発における成功基準（サクセスクライテリア）について、JAXAのガイドラインや実例を解説しました。

サクセスクライテリアに関連するものとして、より宇宙開発における健全な技術的進歩の考え方を学ぶために、失敗学を紹介したいと思います。具体的な品質管理、信頼性管理の考え方については、様々な良書が出ていますから、本記事ではその導入として、失敗の必要性と考え方の紹介だけしたいと思います。

1.失敗から学ぶ、失敗学の紹介

誰しも失敗は避けて通りたいものでしょう。しかしながら、難しい課題へ挑戦すればするほど、失敗と向き合う必要が出てきます。時には新しい課題へ挑戦していなくても、今まで通りのことをしているだけで大きな事故が発生することもあります。

失敗の原因を究明し、同じ失敗を繰り返さないためにはどうすればよいか、そして、この知識を社会に広げるにはどうするかを考える学問が「失敗学」で、東大教授であった畑村洋太郎が提唱しました。「技術の創造と設計」という書籍を参考に、失敗をどのように活用して次の成功につなげるかを考えていきます。

この記事では、失敗からナレッジを抽出し、その知識を生かしていくための流れを紹介します。大まかな流れとして、失敗はまず原因を究明し、科学的に理解し、そこから得られた知識を伝達することが要素となります。失敗原因を究明する手法は様々な方法が提案されていますが、大切なのは表面的な理解にとどまらず、背景要因を探り、類似の失敗を防ぐこと、そのために知識を伝達することです。

1.1 失敗の種類：良い失敗と悪い失敗

失敗には「良い失敗」と「悪い失敗」があります。良い失敗とは、これまで誰も経験したことのない、人類が新たな知見を得る際に付随して発生する失敗で、これを避けることは難しく、またそこから得られた知見は人類の知識を進歩させるものであり、非難されるようなものではありません。

一方で、過去に発生した事故を再現したような失敗というのは悪い失敗です。悪い失敗を繰り返さないために、最初の「良い失敗」の段階で知識を共有し、以後の失敗を防ぐことが重要です。どうせ失敗するなら、まだだれもやったことない新しいことで失敗すべきなのです。

1.2 失敗の原因分析の目的

失敗の原因分析とは、「誰が悪かったのか」ではなく、「なぜこうなったのか」を考えることです。心理としては「お前（あいつ）のせいだ」と誰かに責任を求めて責め立てたくなるものですが、大切なのは、何が起きたのかを知ることです。

その過程で、作業者のミスも挙げられることがあっても、さらに深堀して、なぜ作業者がミスしてしまったのか、という背景まで掘り下げ、徹底して原因を究明することが、将来の失敗を防ぐことにつながります。

1.3 失敗知識の伝達

失敗した経験や失敗に関する情報を、そのまま伝えたとしても、他人にはうまく伝達されず、次に繋がりません。正しく伝達し、共有するためには、失敗に関する情報を知識化することが大切です。

例えば、ある事故が発生したという情報自体は「事故が起きた」という情報でしかありません。どこで、誰が、何をして、どのような経緯で事態が進行したのか。その背景に何があったか、という情報まで言及しなければ、ニュースを聞いた人も「事故が起きた」という情報だけを受け取って終わりとなってしまいます。この情報だけから対策を立てようにも、見当違いの対策になりかねません。

さらに、失敗情報は、やみくもに収集しても活かす工夫が無ければ活用されません。失敗のデータベースは、必要な人が必要な知識にアクセスしやすいよう、整理されている必要があります。

また、あまりにも数が多いと全ての知識に目を通すことが困難であり、重要な情報にアクセスすることができないでしょう。数を絞るためにも、より少ない実例から全体像がとらえられる典型的な実例を集めることが重要です。

活用しやすいように知識化された失敗情報とは、以下のような項目を含む情報であると「技術の創造と設計」には記されています。

・事象
・経過
・推定原因（そのときの推定される原因はどんなものか）
・対処（どんな対応をしたか）
・原因（後から調べて分かった、失敗が発現するまでの種々のレベルの原因の脈絡）
・対策
・背景
・後日談
・よもやま話

興味深いのは、原因や背景だけではなく、後日談や関連するよもやま話など、失敗情報を読んだ人間がその失敗の情景を想像できるような関連情報を入れるべきであるとしていることです。失敗を防ぐためには、失敗を自分で体験し、理解を得ることが重要であり、その失敗を「追体験」できるような情報も重要になるのです。

2.失敗を生かすためのツール

続いて、失敗を生かすために一般的によく用いられるツール（手法）を紹介します。

2.1 原因究明の資料によく出てくるFTAとは？

不具合事象や事故が発生した際、報告書にFTA（Fault Tree Analysis）という言葉が記されているのを見たことがあるという方も多いのではないでしょうか。

FTAとは、発生事象から始め、それを引き起こす可能性のある要因を網羅的に深堀りしていく解析手法です。関連する因果関係を全て記述し、その一つ一つの事象に対して、製造記録やフライト記録から原因可能性を排除していくことで、最終的な原因の究明に貢献します。必ずしも失敗が起きてから使うものではなく、失敗を想定してそこに至る原因を推定し、クリティカルなアイテムを特定するためや設計の重要なポイントを特定するためにも使われたりします。

なお、FTAは発生事象から解析を始めますが、逆の考え方で、製造プロセスに潜むリスク要因から最終的に起こりうる事象を解析するのがFMEA(Failure Mode and Effects Analysis、故障モード・影響解析)と呼ばれるものです。故障が発生したときに生じる事象から、影響を解析するために使われるツールで、主に設計段階で用いられます。FTAとFMEAはペアで使うことでより効果的に設計の品質を高めることができます。

宇宙開発では、FTAによって原因を絞り込んだ後、実際にその事象が発生しうることを地上の実験によって確かめることがあります。また、実験が不可能であっても、製造記録やシミュレーションを駆使して確認を行うことで、原因を究明し、重大事故の再発を防ぐことができているのです。膨大な量の製造記録や検査記録を残すのはこのためです。

自動車業界では、トヨタ生産方式における問題の原因分析手法として、「なぜなぜ分析」が有名です。提示されたある問題に対して、問題を引き起こした事象を「なぜ？」と分解し、さらにその事象に「なぜ」至ったのか、なぜ？を５回程度繰り返すことで、物事の本質に到達するという手法です。FTAと類似の手法で、どちらも提示された問題の真因を見つけ出すことが目的です。

2.2 知識の伝達・共有する方法

分析した失敗原因やそこに至った背景要因を、何らかの手段で後世に伝える必要があります。失敗学会では、過去に重大事故を起こし、社会的に大きな影響のあった事例から、重要な事故を抜き出した「失敗知識データベース」を運用しています。これを見るだけでも色々な事故の例が見えて勉強になります。

品質管理の世界標準であるISO9001では、不具合が生じた際に「①その不適合をレビューし、分析する」「②その不適合の原因を明確にする」「③類似の不適合の有無、またはそれが発生する可能性を明確にする」という３つのアクションを要求しています。

③は、不具合に関する情報を共有し、水平展開することを指しています。そして、設計開発へのインプット事項としても、「以前の類似の設計・開発活動から得られた情報」を明確に要求しています。

宇宙開発では、Lessons Learnedという表現で、教訓、ノウハウを収集し、データベース化している場合が多いようです。

JAXAは過去の研究開発で起きた知見や教訓を「Lessons Learned 作成ガイドライン」(BDB-12003)という内部文書に基づき、Lessons learned （以下、LL）として収集し、内部で管理しているようです。残念ながらLLは公開されていませんが、プロジェクトの開始時点で過去のLLに基づいて対応をプロジェクトマネジメントに反映しているようです。

NASAは、LLを一部公開（https://llis.nasa.gov/）しており、その内容を確認することができます。優に1000を超える知見は、テーマや年代によって分類され、検索もできるため、いくつか参考にご覧になることをお勧めします。

ここでのLLとは、特定の技術要素の失敗をさらに深堀りし、プロジェクトを遂行する中で誰かが気づいた組織運営レベルの知見や、打上げ前に実施しておくべきであった試験について後世への申し送りなどが多く含まれています。宇宙開発に関わらない業界の方でも、共通的に生かせる情報もあるかと思います。

これだけの教訓を公開する背景には、米国では税金で得た成果は国民のものとして公開・共有されることが前提である考え方があるものと思われます。これによって民間企業や新規参入者もNASAの膨大な知識を利用することができるため、産業育成にもつながっていることでしょう。

JAXAでは、技術的な知見については、LL以外にも「不具合情報システム」としてまとめられています。また、宇宙機の開発現場、地上設備の試験・運用現場、宇宙での運用中トラブル等、長年にわたる様々な不具合情報を蓄積し、共通的に得られた知見は共通技術文書としてまとめられています。不具合情報は公開されていませんが、共通技術文書は公開されていますので、宇宙機開発に携わりたい方は一度目を通してみてください。

2.3 対策をしたアリバイ作りに利用しない

ここに紹介したどのような手法を用いる場合も、原因分析結果としては容易に「作業者が悪い（能力不足である）」という答えに至ってしまいがちです。判明した問題の本質的な原因を究明しないまま、解決策として「教育を強化する」「管理を強化する」といった対策が積み重なると、問題の再発を引き起こすどころか、作業効率を下げ、作業者のモチベーションを下げるという弊害も指摘されており、適切な運用が求められます。

一見すると問題を解決したように見える安直な管理強化は、「対策した感」を出す非常に強力な演出装置になってしまいます。技術基準、管理ルール、教育方針などは、定期的に見直しを行い、実態に見合った適切な運用を心がける必要があります。

3.さいごに

筆者はかつて、尊敬する先輩エンジニアから「失敗をしたくないと思っているなら、挑戦しないことだ。失敗したくなければ何もしないのが一番だ」と言われたことがあります。そのくらい、新しいことに挑戦することと失敗というのは密接に関係するものです。過去の失敗を活かし、いかに創造的であるかを考えることは良いエンジニアにとって重要です。

本記事で示した失敗を活かす仕組みというのは、品質管理やプロジェクトマネジメントのほんの一面に過ぎません。読者の皆様が少しでも興味を持って良いエンジニアになるための一助になれば幸いです。