投稿コーナー
先号　　次号

「きぼう」日本実験棟開発を振り返って (26)
―Lessons Learnedは手間がかかるが役立つ―

宇宙航空研究開発機構客員／PMマイスター　長谷川　義幸　[プロフィール]　：1月号
○ 不具合は前兆があるので見逃さないように
2020年11月16日日本時間9時半に、野口宇宙飛行士が搭乗するISS 行きアメリカ民間会社SPACE-Xの新型有人宇宙船が無事打ち上がりました。同社の別のミッションでロケットエンジンに気になることがみつかったため当初の打ち上げ予定が延期になりました。延期のニュースを聞いて、現役時代に打ち上げに際していつも不安であったことを思い出しました。不具合がでないように設計し製造するのは当然ですが、複雑なシステムが相手であり設計での想定はあくまで想定にすぎないので、宇宙に上げて動かして確認するまでシステムとして確証は得られません。宇宙で不具合が見つかってもほとんど対処できません。打上げ前にロケットや宇宙船に何らかの不具合や気がかりが見つかったとき、その周辺も十分点検するので他の隠れていた不具合もみつかる事があります。地上で発見できれば分解修理も可能なので、気がかりが見つかることは、私にとってうれしいことでした。SPACE-Xの慎重なやり方は好感がもてます。そして打ち上げは成功し、無事野口さんはISSに到着し、活動を開始しました。「きぼう」プロジェクト開始の時、先達が経験した失敗に至るプロセスをできる限り取り込むようにすべきだと思い、過去のプロジェクトや類似のプロジェクトが経験した失敗や不具合をチームメンバー皆で調査しわが身の教訓として設計や製造、試験、運用などにとり入れていった草創期を思い出しました。

○ NASAもJAXAもLessons Learnedはあまり活用されていなかった？
　ナレッジマネジメントの先進国であるNASAでもノウハウの伝達はあまりうまくいっていないようです。1995年くらいから、NASAはリスクマネジメントのツールの中にLessons Learnedデータベースを構築し始めました。過去の成功と失敗を共有して同じミスを防ぎ学習時間を短くする目的で、LLIS (Lessons Learned Information System) データベースシステムを構築し、NASA内部に利用促進をする方針で始めました。チーフエンジニアの下で、各フィールドセンター運営委員会がプロジェクトの教訓を集め編集する作業を担当しています。ところが、米国会計検査院が調査をしたところ、利用がはかばかしくないことが分かり、改善勧告をだしました。プロマネは、自分のプロジェクトの経験や技術は固有のもので、他のプロジェクトに貢献するとは思っていません。ところが、工場での衛星試験中に装置をシムにとりつけるとき、回転台車から衛星が床に滑り落ちるという作業ミスは、他のプロジェクトでも何回も起きていたのです。作業するのは、別会社の作業員だったり、初めての経験する作業員です。利用が進まない理由は、LLISに自分に関係のない情報が沢山あったり、使いやすい編集になっていないなどです。さらに打上げ後はプロジェクト体制が縮小になるので、プロマネは日々起きる出来事をこなすので精一杯、経験をまとめ登録を行える状態にないことが分かりました。それでも米国の会計検査院は、「過去に優れた努力があり成功したとしても、将来においても同様の高いレベルの努力が維持されることを保証するものではない。」と指摘。NASAに改善を勧告したのです。

○ NASAの国際宇宙ステーションでの不具合情報共有
　ISSでは、巨大な有人宇宙施設を40回以上打ち上げて宇宙で組み立てるという挑戦をNASAがインテグレーターとしてプログラムをリードすることになりました。初めて付き合う日本や欧州、ロシアを仲間にいれたこの大規模な開発を経験したことがなかったので、非常に慎重なアプローチを手探りでやり始めました。設計手法も、モノを開発するアプローチも、異なっており、技術レベルも、品質管理レベルも、NASAは把握していなかったので、米国の企業を管理して開発するのとはわけが違っていました。ロシアが参加してISSの開発が本格化したISSの開発は、5つの国際機関がそれぞれ別々の設計思想で行っているので、米国で経験したと同じような不具合や作業ミス(NCマシンの設定、フライト品試験時の試験台への取り付け不備)などを国際パートナーがダブって経験することはスケジュール遅延につながるので避けたい。1995年くらいから、米国開発企業とNASAが経験した不具合の事象、原因、対処などの不具合報告書を電子化したデータベースを構築し始めました。新しい仕事を身に着けるのは時間がかかります。時間と効果が正比例の関係にあるのですが、できるだけ学習時間を短くして、類似の作業ミス発生を防ぎ開発スケジュールの短縮を狙いました。本当にスケジュールを管理できるのか、相当不安だったようです。NASAは、ISS開発中、不具合対処状況をプログラムのトップレベルの管理項目として厳しく管理しました。私が「きぼう」開発プロジェクトに従事し始めたとき、このNASAのデータベースを活用するとともに、JAXAの衛星やロケットや海外の教訓をできるだけ集めてわが身に関係するものはないか、開発企業と協力して細部にわたるまで点検していきました。

○ 「きぼう」開発でのLessons Learnedデータベースの活用
Lessons & Learnedの点検は、フェーズ審査で行う 　JAXAでもプロジェクト間の経験伝承は、NASAと類似の傾向があります。例えば、2011年、日本初の金星探査衛機が軌道投入に失敗。原因は細い配管の弁の作動不良。1998年に火星探査機も弁の動作不良で火星軌道失敗で原因は、安全のために追加した別の型の弁の動作不良でした。両方とも米国製の弁だったのですが、機微な技術情報を理由に設計図などの詳しいデータは開示されないし分解も禁じられていました。JAXAでもプロジェクト間の経験伝承は、NASAと類似の傾向があります。例えば、2011年、日本初の金星探査衛機が軌道投入に失敗。原因は細い配管の弁の作動不良。1998年に火星探査機も弁の動作不良で火星軌道失敗で原因は、安全のために追加した別の型の弁の動作不良でした。両方とも米国製の弁だったのですが、機微な技術情報を理由に設計図などの詳しいデータは開示されないし分解も禁じられていました。宇宙部品は少量生産のため国産ではできずに米国頼み。輸入部品を使う場合、自前で信頼性を確保する対策が必要でしたが、プロジェクト間の情報伝達は、どうしてもセクショナリズムとなりうまくいきません。過去どういう問題があったか調査するよりは、新規の技術課題の解決にエネルギーを投下する傾向にあるのです。対策として当初は、独立評価チームの経験者たちから、審査会などでプロジェクトに過去の経験や技術を伝えるようにしましたが、多岐にわたる経験者を配置することはできないので、プロジェクトメンバーの努力によることになっていました。そこで、JAXAでは、どのプロジェクトもミッション定義審査までのフェーズに「審査事項⑤：レッスンズラーンドの取り込み状況」、開発段階の計画変更審査の場合には、「変更に係る機構横断的に継承すべき教訓・知見が識別されており、かつ妥当であること」と規定しましたので、必ず関係する教訓を点検しなければいけないようになりました。(1)その際、チェックすべき教訓が必要なので、遂行中のプロジェクトでは教訓集をこまめにまとめていくともに、チーフエンジニアリング室がプロジェクトのキーマンに直接インタビューをしてプロジェクト実施による組織・技術の蓄積(原因、是正処置、背後要因など)として書類として編集し、JAXAの経験データベースとして整備してきています。
　やはり、物事を十分取り入れて本当の技術として昇華するには長い時間が必要なようです。

＜参考文献＞
(1) JAXAフェーズ移行審査ガイドライン(その1)、BDB-08013C

ページトップに戻る