取材対象者

酒井 一美 様

インターステラテクノロジズ株式会社 開発部 アビオニクスグループ エンジニア

髙橋 良寿

株式会社ベリサーブ モビリティ事業本部 モビリティ第七事業部 ソリューション第一課

全コンポーネントを自社開発する独自の開発体制

──まず御社の事業内容と酒井様の役割について教えてください。

酒井： 当社は民間ロケット開発を手がけており、現在は小型人工衛星打ち上げロケット「ZERO」の開発に注力しています。その中で私自身はアビオニクスを担当しています。また、2025年12月に開設した東北支社では立ち上げに関する取りまとめをしています。

──御社の開発体制にはどのような特徴がありますか？

酒井： 大きく三つの特徴があります。一つ目は、主要なコンポーネントを自社で開発していることです。従来の宇宙産業では、一つのコンポーネントを1社が担当するのが一般的ですが、当社はロケットに搭載されるエンジン制御ユニットや各種センサー、データ収集装置、無線通信機器などを自社で担っています。ちなみに、ZERO 1機には多くのアビオニクスのコンポーネントが搭載されています。

二つ目は、設計の内製化率が高いことです。これは将来、ロケットの低価格化を実現する上で重要な要素です。設計を外部に依存していると、コスト削減の際に柔軟な判断ができなくなってしまいます。例えば、あるセンサーを省きたいと思っても、メーカーに問い合わせると「必要だと思います」という回答しか得られず、本当に省けるかどうか分からないし、時間もかかります。設計を内製化することで、こうした判断を迅速に行えるようになります。

そして三つ目として、アビオニクス周りでは国のロケットの経験者が多いという特徴があります。私も2021年3月に入社する以前はそのような企業で働いていました。

ただし、この最後の部分はこれまでの開発体制および経験領域に起因する制約にもなっています。というのも、基本的に一つのコンポーネントに対して一人か二人という少人数でコーディングしてきた経験が多く、開発がガラパゴス化して”独自仕様“になりがちでした。大人数での開発における標準化やベストプラクティス、品質向上のための議論が不足していたのです。

ソフトウェア品質の標準化が急務に

──ベリサーブに支援を依頼する以前、具体的にどのような課題を抱えていたのでしょうか？

酒井： 広い範囲の多くのコンポーネントを社内で開発しようとしたとき、「ソフトウェアの品質をどう確保するのか」という課題が顕在化していました。それぞれの開発者が独自のやり方で開発を進めており、品質に対するアプローチも異なる状況でした。

私の理想としては、W字モデル^※1で開発を進めたいと考えていました。最初の設計段階からテスト担当者が入って、どのようにテストを実施していくかを一緒に考えていくというアプローチです。従来の宇宙開発ではV字モデル^※2が一般的ですが、私たちはより早い段階から品質を作り込んでいきたかったのです。

具体的には、当初はコーディング規約もソフトウェアレビュー観点リストもなく、ユニットテストや統合テスト、システムテストをどう実施すべきかという共通ルールを設ける必要がありました。構成管理や不具合管理の仕組みも、ベリサーブさんのようなプロフェッショナルから見れば改善の余地が多かったと思います。

従って、これらの課題を一つ一つ解決していく必要がありました。ソフトウェア品質には“銀の弾丸（複雑な問題を一発で解決する万能な解決策）”はないと考えています。さまざまな施策を積み重ねることで、初めて「ここは疑わなくてもいい」という心理的安全性が生まれるはずです。

※1 開発の上流工程からテスト設計を開始し、開発プロセスとテストプロセスを同時並行に進めるプロセスモデルのこと。

※2 開発の各工程に対するテストを計画的に実施する開発モデルのこと。

──なぜベリサーブをパートナーに選ばれたのでしょうか？

酒井： 社内メンバーの中に自動車業界出身者がおり、その社員から「自動車の世界ではベリサーブさんが広く使われている」という情報を得ました。

自動車と宇宙は一見異なる分野に見えますが、ソフトウェア品質という観点では共通点が多いです。ベリサーブさんは組み込みソフトウェアの品質管理で豊富な実績があり、自動車メーカーとの付き合いも長いという実績を踏まえ、ぜひお願いしたいと考えました。

基本的なプロセスから一つずつ構築

──2023年4月にベリサーブの支援が始まり、どのような取り組みを進めてきたのでしょうか？

酒井： 最初は燃焼試験用ソフトウェアの設計レビューやテスト項目のチェック、受け入れ試験などを担当していただきました。それと並行してコーディング規約の策定と、その内容の静的解析ツールへの反映やツールの使い方マニュアルを作ってもらいました。

高橋： サポートに入って感じたのは、当時はまだスタートアップ企業ということもあり、開発プロセスを作り込んでいるような段階でした。テストといっても、人によってやり方が違う状況でしたので、まずは標準的なプロセスを一つずつ整備していきました。

例えば、レビュー観点リストを作成して、「こういう視点でレビューしましょう」という基準を設けました。また、レビューの手順自体も整備し、全員の承認が終わったら次のステップに進むというプロセスを確立しました。いわゆる「普通のことを普通にやる」ための仕組み作りです。

──コーディング規約の策定では、どのような点に注力されましたか？

酒井： 単純な書き方のルールだけでなく、コードに対するメトリクス規約を重視して、例えばサイクロマティック複雑度をどのくらいにするかといった指標を決めました。先ほどお話ししたように、従来の宇宙業界出身のエンジニアは少人数での開発が当たり前で、複雑なコードでも問題無いと考えがちですが、ここでは誰が見ても理解できて、実装者以外でも保守が可能なコードを書くための基準が必要でした。

ただし、基準を厳格にし過ぎても問題です。そういった点も含めて、高橋さんと一緒に適切なバランスを検討していきました。

──トレーサビリティ管理ツール「ConTrack」も活用されているそうですね。

酒井： はい。複数のツールを使い分けるのは管理が大変なので、一つのツールで多くのことができるものを探していました。ConTrackは、構成管理や不具合管理などを統合的に扱えますし、直感的に使える点が魅力でした。導入のハードルを下げることは、そのツールを組織全体に浸透させる点で非常に重要です。

また、当初はExcelで要件管理を行っていましたが抜け漏れの心配があり、Excelでの管理に限界を感じていました。システムが複雑になるにつれ、例えばソースコードのどこに反映されているかといったトレーサビリティが必要でした。こうした背景から、ConTrackの導入を決めました。

設計者の心理的安全性を確保

──これまでの約２年半のサポートを振り返り、どのような成果が得られましたか？

酒井： まだ開発が全て完了しているわけではありませんが、ソフトウェアレビュー観点リストは大きな成果です。現在、レビューの際には必ずこのリストを使用しています。これが無いと、それぞれの開発者が過去の経験だけに頼って判断することになり、属人的になってしまいます。

私がとりわけ実現したかったのは設計者の「心理的安全性」です。ロケットは一発勝負で、15分〜1時間ほどの短い飛行時間に何年もかけた開発の成果が集約されます。それだけに開発者の心理的な負荷を減らし、安心して仕事に取り組める環境を作りたかったのです。

複数の目で確認できるような仕組みがあるだけで、開発者の心理的な負担は大きく軽減されます。規約や基準が整備されることで、チーム全体で品質を支える体制ができたと言えます。

──心理的安全性について、もう少し詳しく教えていただけますか？

酒井： ソフトウェアエンジニアは「最後のとりで」なのです。ハードウェアやFPGA^※3の担当者の後ろにはソフトウェアエンジニアがいて、彼らのバグもソフトウェアで拾うことができます。しかし、ソフトウェアエンジニアの後ろには誰もいません。

ハードウェアの担当者は、モノが出来上がればある意味で“卒業”できますが、ソフトウェアは最後まで変更可能なため、「ソフトだから変えられるだろう」と言われ続けます。しかし、コードを1行でも変更すれば、また膨大なテストが必要になるのです。また、ソフトウェアには「故障」という逃げ道がありません。だからこそ、少しでも心理的な負担を下げる仕組みが不可欠でした。

※3 Field Programmable Gate Arrayの略。後から回路構成をプログラムで自由に変更できる半導体チップのこと。

高橋： そういう意味では、コーディング規約やレビュー観点リストを整備したことで、品質の「ゴール」が見えるようになったと思います。これまでは「レビューしました」「テストしました」という報告でも、どのレベルの品質が担保されたのか分からなかったのですが、基準を設けたことで「これならば安心しても大丈夫」と言えるようになりました。細かいロジックのミスは残る可能性がありますが、致命的な問題は防げるようになったのです。

ロケット開発特有の課題にも対応

──自動車と宇宙の共通点は多いとありましたが、逆にテストのアプローチで違いはありますか？

酒井： 最も大きな違いは、ロケットは実際に飛ばせるのが1回だけという点です。自動車のように試作機で何度も試験走行することができず、基本的には全ての動作をシミュレーションで検証と評価をする必要があります。一方で、動作時間は自動車に比べて圧倒的に短く、数時間動く品質を確認できれば十分です。

高橋： 自動車の場合は実際に動いている様子を見て、動作が正しいかどうかを確認できます。しかしアビオニクスの場合は”手足“がないので、計算結果が正しいかどうかを見た目だけで判断することができません。従って、テストで飛行中の動作挙動などを押さえたり、計算結果をプログラミング言語「Python」などでグラフ化し、きちんと機能しているかをチェックしたりしています。その辺りの難しさはありますね。

──1回しか打ち上げられないからこそ、自動車よりもシビアに故障注入テストを実施されるのでしょうか？

高橋： ロケットの場合、飛行ルートは事前に決まっていますが、故障が発生してもリカバリーする手段がほとんどありません。どちらかと言えば、演算結果の正しさを重視しています。

例えば、位置計算では積分処理を行いますが、浮動小数点の変換の仕方を間違うことで生じる誤差や、振動・温度・電波によるセンサーの出力誤差が生じる場合があります。こうした誤差が積み重なり、最終的に位置がずれるのを防ぐことの方が重要です。

WIN-WIN（お互いにとって良い結果になる状態）の関係を重視

──今後の展望について教えてください。

酒井： 私が基本的に重視しているのは、ベリサーブさんをはじめとするサプライヤーの皆さまとWIN-WINの関係を構築することです。WIN-WINの関係がなければ、長く付き合っていただくことはできません。

私自身は以前コンポーネントメーカーにいたため、サプライヤーさん側の気持ちもよく分かります。今後も検討が必要なプロセスはベリサーブさんと一緒に取り組んでいきたいと思っています。

今はZEROの初号機の打ち上げに向けて全力を注いでいますが、その後は打ち上げ高頻度化に向けた対応も必要になります。初号機では、エンジンなど他部門からの要求を極力全て受け入れる方針で開発を進めたため、多くのアビオニクスコンポーネントを搭載しています。
いずれは、これをいかにスリム化していくかが課題になってきます。機能などをそぎ落としていく中で、影響範囲をどう把握するか、心理的安全性をどう担保するかといった点で、引き続きベリサーブさんの支援が必要です。

高橋： 現在の一品物の開発フェーズでは、とにかくやり切ることが重要ですが、その後スリム化していく際には、影響範囲の分析が必要になります。心理的安全性という話がありましたが、「ここまでやったから安心」と言える状況が求められていると感じており、パートナーとしてその役目を果たせればと思っています。引き続き、インターステラテクノロジズ様の品質向上に貢献できるよう、全力でサポートしてまいります。

──ありがとうございました。