少し遅いですが,あけましておめでとうございます. 株式会社アークエッジ・スペースのソフトウェア・基盤システム部(以下,ソフトウェア部)を統括している鈴本 (@_meltingrabbit) です. 我々ソフトウェア部は,人工衛星そのものに搭載されるソフトウェアはもちろんのこと,衛星の運用・開発を支援する地上ソフトウェアや果ては社内システムまで,ソフトウェアっぽいものをまるっと担っている部で,先日,結成(?)から1年ほどが経ちました. その詳細は『宇宙業界にソフトウェアの力で挑むチームができてから1年が経ちました』をご覧いただくとして,本日はもう少し踏み込み,今期(2022年10月~2023年3月)に実現したい夢を大公開しようと思います!
話の大前提として,アークエッジ・スペースには,エッジの効いた超小型人工衛星 / 探査機 1 機を開発・運用する能力はありますが,それをさらにスケールさせ, 異なる人工衛星 / 探査機を同時に開発・運用できる能力 を獲得しようと奮闘しております. そのために我々ソフトウェア部は,ソフトウェアの力によって様々な課題を解決しようとしています. 具体的にどのような課題があり,どういったアプローチで解決してきたか,といったことは,今後個別の記事でご紹介していく予定ですので,ここでは 我々はこうあるべきだという "ポリシー(強い意志)" と,課題解決のために整理した今期の "OKR (夢)" についてご紹介します. OKR とは,"Objectives and Key Results" の略で,和訳すると,"目標とその達成を定量的に判断するための成果指標" です. 詳細については Google の OKR の解説 をご覧頂きたいと思いますが,ソフトウェア部では毎期ごとに部の OKR を設定します. そして,その部の OKR にぶら下がる形で各部員の OKR が個人目標として設定されています.
Key Results についてはどうしても社内の内部事情に触れてしまうため,今回は部のポリシーと OKR の Objectives について紹介できればと思っています.
ソフトウェア部 ポリシー
このポリシーは "ソフトウェア部のあるべき姿" を定義します. そのポリシーというのは......
- 意思決定において,開発体験のよさについて妥協しないべきである
- 開発するすべてのソフトウェアは, update 可能であるべきである
- 開発するすべてのソフトウェアは,検証可能な状態を保ち,自動で検証されるべきである
- 開発機数に対してコストが劣線形になるように(スケールメリットが出るように)ソフトウェアを開発するべきである
- ハードウェアや人間が絡むコストの高い仕組みや作業を発見し,ソフトウェアに落とし込むことで効率を向上させていく活動を,全社で実施していくべきである
です!
ソフトウェア部では,すべての意思決定はこのポリシーに基づきます. つまり,このポリシーに反するような提案は否定されます. それでは,ひとつづつ詳細に見ていきましょう.
意思決定において,開発体験のよさについて妥協しないべきである
技術選定を含む意思決定において,開発体験のよさにもきちんと意識を向けましょう,ということです. 我々は人工衛星というハードウェアを扱っており,人工衛星に搭載されるコンピュータボード (On-board Computer; OBC) なども開発しています. たとえば,OBC に搭載されるマイコンが,
だった場合,どうでしょう? 自由な開発はできませんし,GitHub Actions などで CI を組むのも大変です. 様々な自動化の妨げにもなります. そんなことは意思決定の時点で防がなければいけないのです.
開発するすべてのソフトウェアは, update 可能であるべきである
キモは,開発する すべての ソフトウェアが対象,ということです. そうです,地上のソフトウェア(衛星運用ソフトウェアやインフラなど)だけでなく,人工衛星に搭載されるフライトソフトウェアについても全てです. 衛星搭載メイン OBC だけではなく,サブ OBC も含めて*1,です.
私の個人ブログでも最近書きましたが,「組み込みだから~」や「リスクが~」や「人工衛星は最悪の時に人が直しに行けないから~」などは言い訳にはならないのです. ソフトウェアが update 可能だからこそ,ソフトウェアの開発コストだけではなく,人工衛星の運用コストも下がっていきますし,その人工衛星が提供する価値も向上するものです. そして,ソフトウェア update を可能にするためには,ハードウェアの設計段階から注意深く設計していくべきなのです.
開発するすべてのソフトウェアは,検証可能な状態を保ち,自動で検証されるべきである
一見して至極当然のようなことに聞こえるかもしれませんが,きちんと考えていくと,なかなか難しいことがわかります. 衛星運用のための地上システムを動かしたいと思っても,実際に人工衛星と通信するアンテナというハードウェアが必要ですし,通信先の人工衛星そのものも必要です. 衛星搭載フライトソフトウェアの場合では,宇宙空間特有の物理現象が絡み,地上での再現が困難な動作(例えば人工衛星の姿勢制御など)すらあります.
そういったソフトウェアであっても,検証のためのシミュレータやHILS (Hardware in the Loop Simulator) と呼ばれる部分的に実機を用いたシミュレーション環境を構築し,可能な限りカバレッジ高く,自動検証できるようなスキームを作っていくべきだと考えています.
これを達成するのはまだまだ道半ばですが,頑張っていきます.
開発機数に対してコストが劣線形になるように(スケールメリットが出るように)ソフトウェアを開発するべきである
人工衛星 1 機の開発コストが C0 だったとしましょう. それを C1 (< C0) に圧縮できたとしたら,それは有意義なことです.
しかしながら,人工衛星 N 機の開発コストが NC1 (つまり開発機数に対して線形)だったらどうでしょう? まったくスケールしていません. スケールしていないということは,ソフトウェアのパワーを有効活用できていない,ということです. 我々は,N 機の開発コストが直線 NC1 に対して劣線形になる,つまり上凸な曲線になることを目指し,それに貢献する成果を高く評価します. また,人工衛星の開発を強力にサポートするようなシステムの開発も進めます.
ハードウェアや人間が絡むコストの高い仕組みや作業を発見し,ソフトウェアに落とし込むことで効率を向上させていく活動を,全社で実施していくべきである
ハードウェアや人間が絡む作業は,どうしてもコストが高くなりがちです. 我々は常に「それ(その仕組み / その作業 / その設計 / その課題 etc...),ソフトウェア側に押し付けることできないか?」という着想を持ち続けます. そうすることで,全社のパフォーマンスを常に改善し続けていくことができると考えています.
ソフトウェア部 Objectives
ポリシーは普遍的な共通認識なため,それだけでは目先に注力して取り組むべき課題が決められません. そこで,全社を俯瞰した上でソフトウェア部が,今期の終わりに目指すべき "理想状態" を OKR の形で明文化しました. つまり,この OKR とは言い換えると今期の我々ソフトウェア部の実現可能な夢なのです. そして,各部員の今期の OKR もすべてこれに紐づく形で設定されています.
我々ソフトウェア部の Objectives は,
- 高品質なフライトソフトウェア*2を低コスト・短期間で多種多様な衛星向けに開発できる
- 労働集約型にならない衛星運用システムの開発サイクルが回っている
- アークエッジ・スペースの事業にソフトウェア技術の思想を投入し,改善し続けている
- ソフトウェア部として各所に Rust を採用していることで,生産性と企業価値が高い状態である
- アークエッジ・スペースがソフトウェアの強い宇宙ベンチャーという対外的なイメージ・評価が醸成され,それに見合うチームである
となります! ポリシーと比較して,より具体的な目標になったのを感じて頂けますでしょうか?
ポリシーと同様に,ひとつづつ見ていきましょう.
高品質なフライトソフトウェアを低コスト・短期間で多種多様な衛星向けに開発できる
もっとも重要な Objective です. アークエッジ・スペースでは,様々なニーズに合わせて多様な人工衛星を短納期で開発,打ち上げ,運用することを目指します. そのためには,この Objective が達成されている必要があります.
この実現のためにすべきことはたくさんありますが,例えば次のようなことに今期は注力しています.
- ミッションが異なる人工衛星であっても,同じコードベースで動作可能にする
- 人工衛星の量産体制に対応可能な,試験用の環境やソフトウェアを開発する
- フライトソフトウェアと人工衛星シミュレータのインターフェースを整理する
- ビルド CI やテスト CI の整備を進める
- 次世代の OBC のハードウェア開発を進める(設計段階からソフトウェアに寄り添う必要がある)
労働集約型にならない衛星運用システムの開発サイクルが回っている
皆さんは,「人工衛星の運用」と聞くと,どのようなイメージを抱きますか? 例えば探査機が無事に惑星に着陸したなどといった大きなマイルストーン達成時に,沢山の人が運用室で拍手喝采している映像をニュースなどで見たことがあるのではないでしょうか?
もちろん,まだ見ぬ未知の世界に挑む探査機の運用では,多くの労力が必要なのは理解できます. 一方で,産業として,インフラとして,価値創造の手段として,多数の人工衛星を次々と打ち上げて運用していくことを考えたとき,たくさんのモニタの並んだ大きな部屋でたくさんの人間がたくさんの作業をしなければ人工衛星が運用できないという世界観では,どうしても限界を迎えてしまいます. そのために,労働集約型にならないような衛星運用を実現するシステムを開発中です.
アークエッジ・スペースの事業にソフトウェア技術の思想を投入し,改善し続けている
「ハードウェアや人間が絡むコストの高い仕組みや作業を発見し,ソフトウェアに落とし込むことで効率を向上させていく活動を,全社で実施していくべきである」というポリシーを踏まえて今期注力する Objective にしたものです. ソフトウェア部が,他部署の様々なことに首を突っ込み,全社の効率を上げていこうとしています. そして,効率を上げるために,現在の衛星開発コストの可視化なども行っていこうとしています.
ソフトウェア部として各所に Rust を採用していることで,生産性と企業価値が高い状態である
我々は Rust というプログラミング言語の生産性を信じており,OBC のデバイスドライバや高信頼性が必要な地上のシステムなど,ミッションクリティカルなソフトウェアはすべて Rust で開発しています. そして,それが持続できるように,日常的に Rust を書くエンジニアを増やしていきます.
さらに,今後我々が開発するすべての OBC は,Rust が実行可能になります. つまり,Rust が動作しないマイコンは,我々は決して採用しません.
アークエッジ・スペースがソフトウェアの強い宇宙ベンチャーという対外的なイメージ・評価が醸成され,それに見合うチームである
頑張っていきます!
そのためにも,可能な限り社内の様子を皆様にお見せできるようにしたり,様々なソフトウェアを OSS にしたり,様々なイベント・学会で登壇したり,と積極的な活動を続けていきたいと考えています. 何卒どうぞよろしくお願いします.
おわりに
いかがでしたでしょうか? 我々がどういった目的意識で日々開発を行っているのか,多少なりとも感じていただけたとすれば,とても嬉しいです.
この記事をお読みいただき,弊社で働くことに興味を持っていただけた方は,採用ページをご覧いただければ幸いです. また,ぜひ twitter などで気軽にメッセージをください.まずは雑談しましょう.