『NASA Systems Engineering Handbook』に基づいて、自信を持ったロケットの打ち上げを

ウォーターフォール型の開発における「審査会」

三浦政司氏：今日特に紹介したいのは、先ほど申し上げたゲートのことですね。ウォーターフォール型の開発におけるゲート。一般的にはレビューとか審査会などと呼ばれます。あとは、そこでゲートを通るために更新していく設計情報について、一貫していて整合性が取れている設計情報の集まりをコンフィグレーションといいます。審査会とコンフィグレーション、この2つの話をちょっとピックアップして紹介させてください。

まずは審査会の話です。これはまさに『NASA Systems Engineering Handbook』に載っている図を我々で和訳したものです。

（スライドを示して）ここにグラフみたいなものが書いてありますが、横軸がプロジェクトが進んでいく時間です。縦軸にはライフサイクルコストの2本の曲線が引かれていて、どの時間・タイミングで、どこでどれだけのお金が実際に使われていったかを曲線が表しています。

下の曲線は実際にかかったコストです。例えば、製造では一気にものを買うのでポコンと上がったり、ものを運用してシステムの目的を達成して廃棄するというところで100パーセントになるので、こういう上がり方をしたりします。最後には100になるんですが、特に製造／試験のところで一気にボンっと上がるということで、下に凸したグラフになります。

一方で上に凸のグラフも1個あります。これは確定したライフサイクルコストです。「どのタイミングでライフサイクルコストの何パーセントか」が決まっています。実際の設計では、前の段階では15パーセントの予算しか使っていません。ですが、設計が終わった段階で「100パーセントまでいくとどのくらいお金がかかるか」の75パーセントが決まっています。それがこの上に凸のグラフです。

このグラフで何が言いたいかというと、要は初期の設計の段階が非常に重要で、初期の頃にコストの大部分が決まってしまうので、あとからがんばれないということです。最初のところでより慎重にがんばっておくことで、トータルのライフコストをがんばることができる。より良い設計をしてより良いコストマネジメントをすることで、最終的にかかる100パーセントのライフコストを減らすことができるわけです。

逆に、最初のコンセプトデザインとか設計の段階とかでちゃんとコストも含めて調整できていないと、その段階で大きくコストが上がったまま、最終的なコストが高いまま進んでしまいます。そうすると、もう後戻りできない。

そういった現状があるので、初期の頃からゲートを設ける。ここでいうゲートとは、審査会を設けて何回も確認しながら設計を進めていくということです。

（スライドを示して）MCR（Mission Consolidation Review）とかSRR（System Requirements Review）とかSDR（System Design Review）とかについてです。SDRは一般的かもしれません。

MCR、ミッション概念検討審査のあたりは宇宙特有だと思います。まずは「なんでそのミッションをやるんだ」と。「太陽を観測しに行きたいんです」という話の時の、「じゃあ、その太陽を観測することにどれだけの意義があるのか」みたいなところですね。定義されたこのミッションの意義を確認するようなレビューとか、そういったところから始めていきます。

SRRはシステム要求ですね。システム要求がひととおり揃ったところで、その要求がきちんと網羅的で漏れがないものになっているかを確認します。それでその要求に従ってシステムが定義されたら、その定義されたシステムが要求をちゃんと満たしているかをきっちり審査するかたちで、ゲートを設けて進めていきます。

いろいろなゲートがあります。（スライドを示して）ここにたくさん書いてありますが、本当にところどころで審査会を設けて進めていきます。

最初はミッション・コンセプトを決めて、そのコンセプトが意義あるものかどうかを審査します。機能を設計して、ちゃんと機能設計、システム定義ができているかを審査します。機能、設計、製品というかたちで、仕様がだんだんと決まっていくわけです。

宇宙関連のプロジェクトで厳しく管理される「コンフィグレーション」

この時々の設計資料や設計情報を、コンフィグレーションというかたちできちんとまとめておく、管理しておくことが非常に大事です。これはもちろん一般論なんですが、特に宇宙ではここにすごくこだわって厳しく管理されます。

もしかしたら、この「コンフィグレーション」という言葉は一般的には使われないかもしれません。少なくとも宇宙開発だと、プロダクト開発に関わるすべての人の拠り所になる、合意されて管理されている設計情報の集合（のこと）です。これをちゃんと管理していないと、要は「どれが最新の要求リストなんだ!?」とか「今、この情報で最新の仕様変更が反映されているのか」とかが起きます。

このあたり（のようなこと）になると宇宙以外のところでもけっこう（同じようなことが）起きているんじゃないかと思うんですが、宇宙も非常に文章の量が多かったり要求の数が多かったりするので、こういうことはすごくよくあります。

コンフィグレーションを管理するための組織と本審査会

今言ったようなことが起きないようにコンフィグレーションをちゃんと管理するために、Change Control Board、変更管理委員会を組織します。仕様書をどこか一部でも改訂する場合は、その改訂箇所を変更管理委員会、CCBのメンバーに説明して、他の文章や他の仕様への影響がないかどうかをチェックします。そして改訂の可否を判断して、「OKですよ」と相手側に認められたら、やっとA版がB版になります。

この時、改訂理由も一緒にドキュメントとして加わっていきます。そういった厳密なChange Controlをやっています。そんなかたちで文章がどんどんできていくわけですが、CCBでは文章が不用意に変えられないところだけを審査しています。ですが、実際にはそもそもその設計が妥当かどうかもチェックしていかなければいけません。

一方で、宇宙機は非常に多岐にわたる専門分野が必要です。材料・構造・電気・通信などのいろいろな技術が必要なので、すべての技術がわかって、すべての分野に対して「OK」「OKじゃない」と言える人はいません。なので、たくさんの分野でそれぞれの第一人者・専門家を集めて、その人たちに全部コンフィグレーションの文書を見せて設計が妥当かどうかを、それぞれの専門家の観点からチェックしてもらいます。

そういった専門家をたくさん集めて行う審査会を開きます。（スライドを示して）1つのゲートでもその審査会を何回かやって、ここに書いた文書の確認会をやって、説明会をして、実際にそこで出てきた指摘や議論をちゃんとまとめて、最終的な本審査会をやる。これが1つのゲートなんです。

（スライドを示して）これが、（前のスライドに）書いたところの、基本設計審査会です。設計から開発へ進むためのフェーズを移動することができるかを判断するための審査会みたいなものですね。こんな感じでかなり厳密にやっています。なので、とても大変です。

非常に大変な過程を繰り返すことで、自信を持ってロケットを打ち上げられる状態になる

実際にやっているほうとしては、専門家の方たちにメチャクチャ説明しなきゃいけないし、専門家の方たちからはかなり厳しい意見がいっぱいバーッと出てきます。そのすべてに対して明確にちゃんと答えを提示しなければいけないので、非常に大変なんです。

ですが、そういったことを繰り返すことで、はじめて複雑なシステムとしてのロケットとか探査機が、ちゃんと自信を持って打ち上げることができる状態になるのです。大変なんですが、必要なことというかたちで我々はふだん取り組んでいます。

私はちょうど1年ぐらい前にJAXAに来たんですが、先ほどのような仕事に今は取り組んでいます。メインでやっているプロジェクトは2024年のけっこう後ろのほうにあるんですが、来年度末に打ち上げるDESTINY+という探査機の打上げに使うキックステージというシステムの開発を担当しています。プロジェクトマネジメントというか、DESTINY+のこのプロジェクトでこういった審査会を、そのための資料作りとかを日々やっているというのが、今、取り組んでいることです。

長くなってしまったんですが、「こういうことをこんな感じで厳しくやっていて大変だよ」ということをお話ししました。他にもレヴィ、会社の話になってしまうのですが、レヴィ自身が実はJAXAで一緒にやっている仲間たちで立ち上げた会社なので、今日話した内容などに関連する参考資料なども配布しているので、もしご興味があれば見てもらえればと思います。