重力に縋るな

千種夜羽です

ArkEdge Space で正社員になって半年が経った

タイトルの通りなのだけれど，ArkEdge Space で正社員になって半年が経っていた．

何をやっているかといえば，そこかしこで何度も言っているが，人工衛星を作っている．

sksat.hatenablog.com

正社員になるなんてことは人生で始めてのことだけれど，正直なところその「変化」の瞬間には思い入れがあるわけではない． というかあんまり覚えていない．その前日と同じように仕事をしたんだと思う． たぶん一番大変だったのはバックオフィスの人だろう． まるで正社員かのように働くインターン生も，（大学生をやりながらであることによって）インターン生かのように働くこともある正社員も，どちらもとても面倒だと思う．いつも本当にありがとうございます．

だったらなんでこんな記事を書いているかといったら，まあ久しぶりに文章を書きたい気持ちになってきているからだろう． 一歩引いて考える余裕ができてきたということかもしれない． それも当然といえば当然で，期間を半年から１年に伸ばせば，家出しての一人暮らしに退学に入学にと，単純に生活環境があまりに大きく変わって最初の１年だったからだ，という話は年末に少し書いた．

sksat.hatenablog.com

それにしても，（いい機会なのでちゃんと懐古しておくが）個人的な事情を含めずとも実におもしろい半年だったし１年だった． うちのチームの振り返り記事もあるので貼っておく．

blog.arkedge.space

仕事そのものがおもしろいことはもちろん，組織の成長を目の当たりにできるというのもとてもいい経験だった． 成長というか，ほとんど無いようなところからだったので，だいぶ感慨深い． そう言ってうちのチームの Slack channel を遡ると，一番最初の投稿が音信不通になった僕と Twitter DM で連絡を取ってたり，その後初手で寝坊かますみたいなかんじだったりする．まあ，うん．ごめんて．

正社員というロール

なんだかんだ書いたけど，正社員になったことによる変化が無いのかというかというと，当然そんなこともない． まあ最も生活に関わる部分で言えば給料と社会保険なのだけど，それに限らず．

ひとつ大きいものを上げるとすれば，「明確に責任を持てるようになった」ということがあると思う． こういう書き方をすると責任を取りたい人みたいになってしまうが，そういうことではない． ぶっちゃけ責任なんてできる限り取りたくない． コードだってそうだ．各構成要素はそれが必要な最小の権限を持つべきだし，それぞれが小さな責任を果たすべきだ．

では何かというと，それこそコードで例えるなら「適切に AssumeRole したい」みたいな話だ． 単純に「このリポジトリのメンテ権限が欲しい」みたいなやつから， 「あのコンポーネントのソフトウェアは僕が面倒見ます」みたいなやつもある． 前者については，気軽に言える空気感と，"誰に言えばいいか"が明瞭であれば問題無いし，弊社ではそれこそ１年前ぐらいにレポートラインが大きくリファクタリングされたのもあって，その点についてはあんまり心配していない． しかし，後者は結構難しい．なんというか，その運用がだ．

なにをもって（特にソフトウェアに対して）責任を持つと言えるのかというのも難しいけれど， ここで大事なのはスケジュールを考えることだと思う． より正確には，本物のスケジュールを考えメンテするという部分には僕は気持ちも経験もあまり無く，実際それはマネージャ側の責務なので， 重要なのはスケジュールを考えるための制約条件をちゃんと解きほぐすことだ． 「コレはあの人タスクだからそこでブロッキングが発生する」とか， 「実はコレとコレは並列で回せるしそうした方が速い（ので，そのためにまずココを分割するのが最優先）」，みたいな．

そして，だからこそ正社員ではないインターン生には「スケジュール的な制約があまりないものの今やっておくと後で活きる」みたいなタスクを投げるのがよいのだと思う． うちの部長: id:meltingrabbit はインターン生を取る時に面接で毎回これを本人に言っていて本当に正しいと思う（「なので，ちゃんと余裕のある時期にね」，みたいな suffix が付く）． そういった言葉の意味というか裏側がちゃんと分かるようになったというか，実感を持てるようになったのは正社員になってからのことな気がする．

ソフトウェアエンジニアとして働くということ

似たようなところでいうと，他人の仕事だったり，その仕方についての興味が強くなった，というのもある． この他人というのは当然ながらソフトウェアエンジニアに限らない． なんというか，元々興味はあったけれど，それを元にコミュニケーションができるようになったというか，それを勘定に入れて振る舞えるようになった，という方が正確かもしれない． 具体的には，「アレはあのヒトに任せられるから，一旦任せておいて僕の出番が来そうになったら出現しよう」とか， 「あのヒトがやっていることはたぶんアレにも使えるから感触を聞いておこう」みたいな動きをするようになった． スケジュールを考えながらどうこうするのだって似たようなものだ． 「いついつまでにアレとかソレの試験をしたいということは，そのための試験用ソフトウェア（とそれをうまくやるための仕組み）を作っておかないとなあ」とか．

そして，僕はどうやら色々なことに首を突っ込むのがかなり得意なのだ． ベンチャー企業で平社員一人にそんなにたくさん首突っ込める（そしてそれが有効に機能する）ことなんてあるかよという気もするが，宇宙開発というやつが総合格闘技であるからか，そうでもない． 姿勢（制御, 計算）系をやっているヒトも，通信系をやっているヒトも，熱系をやっているヒトも，電源系をやっているヒトも，構造系をやっているヒトも，そしてバックオフィスをやっているヒトも全然やっていることが違うのだ． やっていることが違う中で，ソフトウェアというやつはなんだかんだ大抵全部に関係する．そこに実機のマイコンがあれば言わずもがなだし， 数値計算をしていればその計算をするソフトウェアがある． わかりやすいところでも，全員 GitHub と Slack というソフトウェアを使っているわけだ．

インターンとして入って最初にやった大きなことが GitHub/Slack を使った働き方を整備・普及させる活動だったのも，こういうところから来ていると思う． まあこれに関しては自分が働きにくくて困ったので率先してやったというところもあるけれど．

blog.arkedge.space

そこにソフトウェアがある以上，多少なりともソフトウェアを知っている奴として首を突っ込んで「それこうすると便利っすよ」とか「そのやり方だと後で詰むんでこうした方がいいです」とか言うだけでも価値があることは多い． なんとなくリポジトリを見かけて CI が無くて組めるなら Pull Request を投げに行くし， ソフトウェアでなくても，省力化・自動化できそうなことを見つけたら「これってどうなんですかね？」と聴きに行く．

もちろん，それですぐに本当の問題に辿りついたり，問題が解決するとは限らない． だって後から首を突っ込んできているのだ．そもそもその問題の対象をよく知らないし，聴いても中身は全然分からないこともある． とはいえ，中身がちゃんとわからないなりにそこをブラックボックスとして扱ってもを考えられることは結構ある． ソフトウェアエンジニアってやつにはレイヤーを分けて考えるとか問題の切り分けとかに関しては一日の長はやっぱりある． それはそれとして，そもそも全然知らないことに対する好奇心が結構あるので，自在に操れるようにはならなくとも「どういう気持ちがあるのか」までは咀嚼しに行くようにしている． まあ，最悪なんも役に立てなくても，ドメイン知識の無い他人に対して説明することで思考が整理されるとかは（自分がやる側になっても）結構あるし， あとで別の人が似たようなことを気にしていたときに「それあの人が詳しいですね」みたいなルーティングもできるし，ドキュメント化されるべきものがドキュメント化されるいい機会になったりもするし，ということで許してほしい（？）．

他人と働くということ

あと，こういったことを考えるようになったことで，本当の意味で他人にタスクを投げられるようになってきたとも思う． 色々なことに首を突っ込むということは，仕事を増やすということでもある． 大抵の場合は首を突っ込んでいる理由は自動化だとか開発体験の改善だとかのスケールメリットのためだし，そこについてはあんまり大外れしたことは無いので突っ込む先の人には許してほしい． それはそれとして，一人で各所に首を突っ込んでいる僕自身の仕事は首を突っ込めば突っ込むほどに増えていくのだ． 自分から仕事増やして仕事が多いというのも本末転倒だが，悲しいかな首は１本しか無いのだ． 増やせるなら増やしたい．ついでに頭も．

じゃあどうするかというと選択肢はいくつかあって，

  • 首のスループットを上げて超人になる
  • 他の人に託す
  • 未来の自分（たち）に託す

などがある．首のスループットを上げるのはなんとか頑張っていきたいところだけど，時間がかかる． そしてその瞬間に性能が足りていないなら取らぬ狸の皮算用なので，実際には後の２つだ． ちなみに，完全に諦めるという選択肢はあんまり無い． これは脳筋だからではなくて，（首を突っ込んでいることそのものではなく）首を突っ込んだ結果仕事，つまりなんらかのタスクが発生しているということは， なにかしらの問題の把握ができていて，それを解決するための手段（直接的な解決策ではなく，それを探るためのメタタスクでもいい）への分割には成功しているからだ．

もちろん，単にやれる人がいないので一旦やらないとか，スケジュール的に無理があるのでやらないとか，もっといい解決策が出てきたのでそっちでやるとか，そういうことはある． しかし，それは一つの問題への対処ではあるし，そもそも我々は何機も何機も人工衛星を作ろうとしているのだから，どこかで発生した/させられた問題というか，課題意識はどこかで絶対に役に立つと言っても過言ではない． そういう意味では，一旦の諦めも大体未来の自分（たち）に託すのとあまり変わりない．その課題感が GitHub の Issue のようなストック情報から読み取れるようになっていれば完璧だ． さらにまとめてしまうなら，未来の自分（たち）に託すのだって他の人に託すようなものだ． 「数ヶ月後の自分は他人なので，一人でやっていてもコメントを書くべき」みたいなことはよく言われるけれど，だいたい同じだ．

そういうところでいうと，上司とか経営陣みたいなロールの人たちは１つ２つレイヤーの高い「タスク」を我々に投げているのだからすごい． もちろん彼らは使用者なのだから，そこにはカネという明確な媒介物とかがあるとはいえ，それにしたってすごい信頼関係モデルである． まあそういう関係そのものを信仰してもお互いによくないので，こっちに関しては一歩引いて見ていなければならなくはあるけれど．

ビルドシステムの面倒を見るということ

責任を取るとか，面倒を見る，みたいなところでいうと，最近社内で「ビルドシステム大臣」と名乗っている． いや，別にそのように名乗りを上げているわけではないけれど，Slack の自分の profile の末尾に書いたり， なんらかのビルドシステムで困っていそうな Slack post を見かけたら出現したりしている． というか，そういう振る舞いをしているので名前を付けたという方が正しい．

「ビルドシステム大臣」という語には， CI/CD 大臣という意味も含めているつもりだ． そこにデプロイがあるならできるだけ自動化したいし，当然デプロイするモノをビルドする過程がある． それはビルドシステムと呼んで差し支え無いだろう．

一方で，CI でやりたいものは test だったり lint だったりして，それはビルドではないのではという気もするが，これもまた無関係な話ではない． test のための小さなプログラムがどのようにビルドされるかはかなり大事だ． その test にはアーキテクチャ依存はあるのか？そこで使う別のコンポーネントのバージョン管理は？見るべきところは多い． lint だってそうだ．特にコンパイル型言語であれば，目の前にある最重要の linter はコンパイラの error/warning である． clang-tidy みたいな linter 専用のモノもあるし，弊社でもこういうのはとても使っているけれど， この類の linter は「めちゃめちゃ warning を出すコンパイラ」として振る舞いがちだ．つまり結局ビルドしている． 余談だが，こういう側面からしても「とりあえず rust-analyzer と clippy」，と言える点で Rust は本当によい．

ちなみに，clippy, clang-tidy の出力を reviewdog に喰わせて PR comment とかに流すための GitHub Action を作ってある． reviewdog は本当によい文化だと思う． CI がコケた時には赤いバツマークと共に status check failed とだけ表示される以上の情報が出てくるべきだ． 何より，機械に理路整然と怒られるのは気分がよいのだ*1． どうしても人間に怒られるのは（別に感情的になってるとかそういうことではなく，ある程度本質的に）ムカついてしまうのだ，人間というやつは． 今日も一日コンパイルエラーに，そしてワーニングに，ありがとう．

github.com

github.com

さて，なんでわざわざ自分の振る舞いに「ビルドシステム大臣」なんて名前を付けたかと言えば，責務を表明するためだ． 我々はよくソフトウェアを細かい責務に分割しているししていくべきだけれど， コンポーネントの区切り方にしても，変数の名前にしても，命名という行為は常に責任分割の単位だ． 個人的に「名の無いところに責務は立てられぬ」などと言ったりしている． これは不適切な命名をしてしまうと責務の分割も不適切になってしまいがちということでもある． とまあグダグダと書いたけれど，「CI/CD 大臣」ではなく「ビルドシステム大臣」なのは，CI/CD みたいな目の前の（あえて言ってしまうと）瑣末な自動化に気持ちがあるのではなく， もっと広範なところに気持ちがあるのだということをみなさんになんとなく認識してもらいたい，みたいな意図がうっすらとある．

そしてそれを表明するということは，そういう話題があったらまず僕に話を通せという意思表示だ． 人工衛星の実機に焼くソフトウェアのビルドシステムも，それをコンテナに固めて AWS 上で仮想的な人工衛星を飛ばすための仕組みも，マイコン毎にコードを共有するための仕組み作りも，全部だ． 弊社で僕の目の届かないビルドシステムは高速に腐って手に負えなくなるだろう．断言していい．少なくとも今は．だから任せてくれ．

数十cm角の箱，あるいは調整の塊

弊社で作っている人工衛星はそこかしこで口酸っぱく言っているように超小型人工衛星というやつで，どれくらい小さいかと言ったら僕のメインのATXのデスクトップマシンの半分未満か1/3くらいだ． デスクトップマシンが地球を回っているだけだったらまだラクだったのだけど， そんな中にとてもたくさんのモノが詰まっている．*2

たくさんのモノが詰まっているということは，たくさんのヒトがいるということだ． しかも，そのたくさんのヒトが，それぞれの専門性を持ってあの数十cm角の箱について考えて手を動かしているということだ． そこに載せるマイコンボード一つを挙げても，その上で動くソフトウェアについてばかり考えているヒトもいるし，そこで使うネットワークプロトコルやIDが気になるヒトもいるし，その電力収支が気になるヒトもいるし，それが発する熱の影響が気になるヒトもいるし，それが慣性モーメントに与える影響が気になるヒトもいる．

そして，そのたくさんヒトたちがあの箱をどのように・どう作るかについてやいのやいの言いながら，あの箱が作られている． つまり，あの箱を作るのにも，なんなら軌道上にデプロイしてもらうためにも恐ろしい量の調整が行われている． 我々は調整の塊を軌道上にデプロイしているのだ．

というようなことを書くと，「みんなでつくる感」というか，ちょっと感動的なかんじがしてくるかもしれない． まあ正直個人的にもそういうのは自分でやる分にはかなり好きだと思う．*3 とはいえ，我々はビジネスとしてやっているのだから，観客がいるのならまだしも我々自身が感動しても一銭にもならない． そして我々だって別に感動したくてやっているわけでもない． モノを作るついでに感動できるならそれに越したことはないけれど，感動してモノが作れなかったらそれは本末転倒だ． 別に感動もできない．みなさんの努力の結果軌道上に文鎮をデプロイしても何もおもしろくない． 軌道上にある文鎮，遠すぎて目の前にある紙の上に置けないし．

国家プロジェクトとかで，莫大なカネとヒトを注ぎ込んで１つ２つの巨大な調整の塊を打ち上げるならそれもいいだろう． しかし，今はもうそんな時代ではない． 地球・宇宙観測のために，通信インフラのために，安全保障のために，なんならエンターテイメントのために人工衛星が打ち上がるのだ． ようは人工衛星が特別な一品物ではなくなって，ポンポン作って打ち上げて気軽に使えるようになっていくし， なにより我々はそうしていきたいのだ．

prtimes.jp

これはつまり１０個，１００個，１０００個とたくさん人工衛星を作って打ち上げていくということだ． とりあえず弊社が関わっている人工衛星というだけでも，この年始で２機軌道に放出された．幸先のいいことだ． まあデプロイしたということは運用が始まるということで，本当はこっちが本番だし，これも当然調整の塊なので超大変なのだけれど．

ちなみに前者は SpaceX の Transporter-6 というミッションで打ち上げられ， これは小型衛星だけを同時に１１４機軌道に投入するものだった． 様々な組織が様々な目的のために作った衛星群とはいえ，一度の打ち上げで１１４機も上がるのだ． なんならそれを打ち上げている SpaceX は Starlink のために ３０００機ほど上げている． というかこの文章を書いている間にも Starlink 衛星が上がっていた．今日は４９機増えたらしい．

さて，こうなってくると，調整の塊をそのまま増やすだけでも調整の量が扱いきれなくなる． しかも，当然調整の塊を増やすための調整も発生してくる． 調整の塊を１個から１０個にするための調整も，１０個から１００個にするための調整も，１００個から１０００個にするための調整もそれぞれ別種のものであることを考えると，ナイーブにやればその調整はもはや人類に扱い切れない量になるだろう． 調整という言葉を，時間計算量とか空間計算量に倣って「人間計算量」みたいに言い換えてもいいかもしれない．

何を言いたいかというと，人間計算量のオーダーを下げなければならない． つい最近うちの部のポリシーが公開されたけれど，「開発機数に対してコストが劣線形になるように（スケールメリットが出るように）ソフトウェアを開発するべきである」とかはまさにこういうことだ．

blog.arkedge.space

宇宙は近くて遠い

少し話が逸れるけど，どうにも宇宙というやつは雲を掴むような話と思われるというか，遠い世界の話のように思われがちなので，我々が働いている世界観の話を少し書いておきたいと思う． 実際宇宙は雲より遠いし，「宇宙」と呼べる範囲から遠くは全部宇宙なので，なんというか平均的な宇宙は遠い． 単純に地上からの距離というか，高度を持って宇宙の話をするなら，100km < 宇宙 というかんじだ． 実際の閾値は 100km とは限らない*4のだけど，だいたい 100km （より上）と言っておけば間違いはない．

ja.wikipedia.org

100km．遠くはある．でもちょっと考えてみてほしい． 実は東京を中心に半径 100km の円を描いたら，「関東圏」は入るかな，という程度だ． 東京-名古屋とか実は 300km くらいだ．桁を一つ足して 1000km にしても，まあ「日本列島」の目立った範囲は入るかな，という程度だ． 僕のとても好きなアニメのひとつに，『宇宙よりも遠い場所』という女子高校生が南極まで行く作品があるのだけど， 実は東京から新幹線に乗って名古屋に行ってひつまぶし食べてくるだけで宇宙よりも遠い場所への旅である． というかつくばから東京のオフィスに出社するだけで 50～60km くらいだ．往復したら宇宙より遠い． そして，この距離にしてはつくばエクスプレス（TX）が十分に速すぎるのでそこまで遠くは感じない．

じゃあなぜ宇宙が「遠い」のかといえば，理由は大きく分けて２つある．

  • 宇宙まで新幹線やTXが開通していないから
  • 本当に必要なものは距離ではなく速度だから

前者は身も蓋もないようであるけれど，それはそうだ． 人工衛星のデプロイ先に新幹線で出張に行って帰ってこられるなら解決する問題は多い．デバッガ刺してアタッチできるし． でも新幹線は宇宙に停車してくれないのだ．そればかりか地上を２次元的にしか移動できない．上方向に伸びているホームも今のところ見当たらない．残念．

そして，最大の問題は後者の速度だ．ぶっちゃけ距離が遠いとかは比較的どうでもいい．距離が問題になるのは光が遅すぎて渋いときとかだ． これも考えてみれば単純な話だ．宇宙にモノをデプロイしたい．そして宇宙とは地上から 100km より高いところである． ナイーブな発想としては，モノを勢いよく上にブン投げればいい．まあ実際にはあの箱を 100km 上空までブン投げられる筋力のあるヒトはいないのでもうちょっと考えることはあるけれど，基本的にはそうだ． さて 100km 上空まで真上にブン投げることに成功したとする．するとどうなるかは賢明な読者ならもうお気付きだろう*5． そう，落ちてくるのだ．なんと重力とかいうやつがあるのでね． 幸いなことに地球は回っているし，空気抵抗とかもあるので顔面にぶつかってきてケガをする心配はあまりないけれど，これでは困る．

じゃあどうするかといったら，真上ではなく真横にブン投げればいい． ある程度の速度で投げることに成功すると，地球が丸いおかげで「常に落ち続けている」という状態が発生する． 実際には真横に投げるとビルとか山とかがとてもジャマだ． あと空気抵抗ってやつが一番ジャマだ．せっかく速くブン投げてもアイツが速度を奪っていってしまうのだ． そのため，結局 100km くらいの高度は欲しくなってくる．アレは「空気がほとんどなくなってくるライン」だからだ． 高校物理みたいな話をしたけれど，結局のところ人工衛星をデプロイするのがなんで大変かといったら，めちゃめちゃ速くブン投げないといけないからなのだ． そして，その速さってのは秒速 8km とかになってくる．時速じゃなくて秒速．まあそりゃ大変だ．

この大変な速度は TX も新幹線も飛行機も出せないのだけれど，ひとつだけこの速度を実現可能な輸送システムがある．それがあのロケットってやつだ． アレは巨体に燃料をたくさん詰めて，それをひたすらに燃やしまくって，そのガスを後ろに押し出して反作用で前に進む，という動作モデルのシステムだ． 燃料と書いたけど，実は酸素が無かったら燃料は燃やせない（燃やす，という操作がそもそも酸素とくっつけることだ）． なので酸素ないし酸素を含んだモノも同じくらい詰めてそれを使って燃やす．酸化剤ってやつだ． ちなみに酸素とかをガスのまま詰めても大した量を詰められないので，めちゃめちゃ冷やして液体として使うことが多い． なので（液体燃料）ロケットってやつはめちゃめちゃ冷えたものでめちゃめちゃ熱いガスを吹くシステムだったりする．まあ大変そうだ．

で，もちろん燃やし方とかもめちゃめちゃ頑張っているのだけれど，それでも軌道に乗れるような速度に到達するためにはあの巨体の９割以上を燃やし尽くすことになる． なのであの巨体のほとんどは燃料タンクだ．そんでもって先っちょの方の本の少しの部分に人工衛星が鎮座ましましていて，それだけが軌道に投入される． そういう乱暴なモデルの輸送システムなのだ．乱暴なモデルではあるけれど，素朴にやったら燃料に火が付いて大爆発するだけだし， 投入したい軌道ってやつも結構ちゃんと決まっているので，緻密に制御しなければならない． そんなわけで，これのコストがめちゃめちゃ高い． その結果，宇宙開発というやつは元々国家プロジェクトでしかできない領域だったと言っても過言ではないだろう．

その後，主に通信衛星とかの需要によって，民間企業も人工衛星を作るようになった． とはいえこれも結局とても高いのは変わらない． で，これをある程度どうにかする方法が「人工衛星をめちゃめちゃ小さく作って，他の人工衛星のついでに打ち上げてもらう」というものだ．相乗りってやつである． 小さく，というのは体積的にもそうだけれど，質量の方が大事だ． 大きな人工衛星は数トンとかあるので，ここで例えば 数十kg とか 数kg とかのオーダーの人工衛星を作ることができれば，まあついでに載せてやらんこともないかなという気がしてくる*6． これが小型衛星とか，我々がやっている超小型衛星ってやつなのだ．

ついでに載せてもらう以上，もちろん色々と制約はある．軌道が自由に選べないとか． とはいえ，人類が使いたくなる軌道というか，人類にとって便利な軌道というのは結構限られている． なので，これは意外と困らない．実は人類は日々色々な人工衛星を打ち上げているので，そこそこの頻度で使いたいような軌道に上がる人工衛星はある． というかロケットに拘りがあるわけでもあんまりないので，ダメだったら次を探せばいい．そういうかんじの世界観だ． これでデプロイ費用はだいぶ安く済む．代わりにめちゃめちゃ小さい人工衛星でいったい何がどのようにできるかは考えないといけないけれど，まあここがチャレンジングな要素なわけだ． そして意外と小さい人工衛星にもできることは色々あるぞ，というのは分かってきている．

これで桁がいくつか違うレベルでデプロイ費用が安くなった．まあそれでも一番インパクトがある金額ではあるのだが． そしてここはロケット屋さんという運送業者側の責務だ．必要以上に考えても仕方ないし，何より彼らも日々安くするための努力をしている． 我々はロケットの縛りはあんまりなく，あの小さな箱を軌道上までデプロイしてもらえればそんなに文句は無い． 安くて便利なロケットが出てきたらそれを使えばいいだけの話だ．

それでも，人工衛星にかかるトータルのコストは十分企業がためらう額になってしまう． なので，更に安く人工衛星が使えればそれに越したことはない．なのでここもチャレンジングな要素だ． で，デプロイコストの他にどういうコストが発生しているのかといえば，人件費と原価だ． 人件費という点で，上で書いた"人間計算量"はとても重要だ．ベンチャー企業みたいな少ない人数で効率的にたくさん人工衛星を作って売れれば最高というわけ． まあ別に経営者でも無いし単純に詳しくないのでこのぐらいにしておくが．

ということで次は原価だ．実はあの箱は普通に原価がめちゃめちゃ高いのである． こっちはまだ自分に近い話なのだけど，なんかもう数百万とか数千万みたいな桁の金額の話はちょっと見慣れてしまった． これは全体の価格ではなくて，一部のコンポーネントでの話だ． まあ宇宙という極限環境でもブッ壊れない特殊なデバイスであることを考えると，ある程度はどうしようもないものがある． ECC メモリが高いみたいな話だ．世の中には「航空宇宙グレード」みたいな概念があって，ようは一番すごくて高いやつである．しかも大抵の場合量産していない．そりゃあ高い．

そして，そんな高くてすごいモノを使っても，実はダメな時はダメだ．ちょっと太陽が元気で荷電粒子がめちゃめちゃ降り注いできて回路がブチ壊れる，とか． そこで，よくあるのが同じモノを２個とか３個とか載せて冗長化することだ． 我々とはまた別の世界観の話だけれど，有人宇宙機では三重冗長が基本みたいな話も聞いたことがある． しかし，そんなことをしていたら当然どう考えてもコストが倍どころではなくなってきてしまう． それだけではなく，我々の人工衛星はとても小さく作っていて，あの大きさで色々なことを実現するために中身がギチギチに詰まっている． そうなると単純に増やした分を入れるだけで超大変だ．

観察し手を動かす

じゃあどうするかというと，リスク評価をちゃんとやる． つまり，その対策は（とくに超小型人工衛星という文脈において）リスクに見合うのか？ということをちゃんと突き詰めて考えて，見合わなければ割り切るということだ．

まず一つ重要な観点として，超小型人工衛星は大型衛星と比較して寿命が短くても構わない． 大型衛星は打ち上げコストも開発コストも開発期間もすごいことになっているので，１０年とかは使えないとコストに見合わないのだが，超小型衛星はそうではない． もちろん長く動いてくれたらそれに越したことはないのだけど，そもそもが桁が違うレベルで安く済むし，開発期間も短くできるというモデルなのだから，リプレースする期間は短くていい．

ここではソフトウェアに関連するマイコンとかメモリの話をするけれど， 次に重要なのは人工衛星の中には結構たくさんのマイコンが載っているという点だ． 電源管理をしているもの，温度管理をしているもの，ミッションを実行するためのもの（望遠鏡が付いてるとかならそのカメラとか画像処理とかをやる），中心で API サーバみたいなことをしているものと，色々ある． そして，この中で一番重要なのは当然電源管理をしているものだ．コイツの気が狂うと流石に困る． 人工衛星全体が完全に再起不能になる可能性が高いからだ．軌道上を周回する文鎮にはなんの価値も無い． なので，コイツはカネとか電力とか体積とか質量みたいな貴重なリソースを割いてでも冗長化する意味がある．

では，他はどうだろうか？中心にいるやつとか結構大事そうだ． しかし，例えばコイツをハードウェア的に冗長化するとして，どのようにしたらいいのだろうか． 冗長化というか，HA構成みたいなかんじにするとかはアリかもしれない．でもそうなると３台とかあってほしい気がしてくる． でもそれで得られる効果はカネ・電力・体積・質量に見合うのか？ そもそも人工衛星にアクセスできるのは人工衛星が地球の周りを回ってきて，地上局の上に来てくれた時だけだ． 衛星間通信とかをやるなら話は変わってくるけれど，別に文鎮にさえならなければダウンタイムは結構許容できるのではないか？ 訂正できないレベルでメモリの中身がビット反転してる状態は困るが，回路が焼き切れてるとかでなければ再起動すればいいのでは？ などなど，色々と考えてみることができる．

また，特に放射線というやつは実は地上で試験することができる． 世の中には加速器で高エネルギー粒子をブチ当てまくって試験できる設備というやつがあるのだ． ここで数年分の放射線を当てながらマイコンやメモリの動作をテストすることができる． これにより，「このくらい当たったらこれくらいビット反転したり壊れたりするんだな」というのを定量的に評価することができる．

そして，これがとても重要なのだけど，「航空宇宙グレードではないけれど，秋月で買ってきたアレがある程度は動いた」みたいなことが結構ある． コストという面でも桁が３つ４つ違うことがあるし，量産されていることによって圧倒的に使いやすかったりする．つまりこれもリスクに見合うなら全然アリなのだ． もちろんそういう普通のもの，「民生品」は宇宙での動作なんて保証していないし，just works ではあるのだけれど，ある程度は動くというのはまた一つの正義だ． こういうのは COTS (commercial off-the-shelf) なんて呼ばれている．

というか，超小型人工衛星そのものが「秋月で買ってきたやつで小さい人工衛星っぽいものを作って飛ばしてみたら結構動いた」みたいなところから始まっているまであるのだ． 大学で人工衛星作ってますみたいな話で，何百万もする航空宇宙グレードのブツをポンポン買えるわけがないので，それはそうだ． そしてそいつらはある程度は全然動いているのだ．その事実は否定できない． 当然，何も考えずに「無保証で安いモノ使ったけどこれでよかったわw」みたいなことを言いたいわけではない． できることはやるし，何のために何を取って何を取らないかって話だ．

「枯れた技術」を盲目的に信仰するなということ

ちゃんと観察して手を動かそうぜ，ということに関しては一つ強く言いたいことがある．

宇宙業界ってやつでは，なにかしらの技術選定をするときに「あの衛星ではアレを使ってたよ」というのを参考にするというか，丸パクリすることが多い． 「軌道上実績」というやつだ．もっと大雑把に「枯れた技術」みたいな言葉を好む人も多い． 軌道上実績があるのはとても強い．「動いたことがある」という事実が与える安心感はとても大きい． しかし，業界全体でこの言葉が一人歩きしすぎているように思う．

ようは全体的に新しいモノに対するかなり強い忌避感があるのだ． ハードウェアが絡むとそういうところがありがちではあるけれど，中でも群を抜いて執着があると思う． まあファーストペンギンをやるのが大変すぎるので，気持ちはわかるし技術選定の方針としても特段間違ったものではない． 巨人の肩に乗るのもとてもいいことだ．

でも，その肩ちゃんと巨人なんだろうか． 別にペンギンは大きくはない． 宇宙でやりたいことが色々と増えてきているし身近にもなりつつあるところで， ちょっとペンギンの肩に重荷を載せすぎていやしないだろうか． 彼らにモノを載せられるような肩あるかわからないけど（滑りそうだ）．

これはソフトウェアでは特にそうだ． そもそも，「宇宙開発」の界隈の人たちは別にソフトウェアに明るいわけではない． 大抵の場合専門外なのだから至極当然ではある． とはいえ，人工衛星というやつはどこからどう見ても計算機の集合体であり，要求が特殊な組み込みシステムだし， ナニカを宇宙でやりたくて作っているそのナニカを実行することになるのも，そのデータを受信して処理するのもソフトウェアなのだ． そんなこんなで，「結果的にソフトウェアをやっているヒト」が多い．

それ自体はいい．なんなら両方できる体力はめちゃめちゃすごいと思う． しかし，しかしだ．ロボコンとかをやったことがある人にはなんとなくわかってもらえると思うのだが，彼らが書いたソフトウェアは，なんというかすごいことになっている． 超巨大な main 関数だとか，コピペされまくった違いがよくわからないしコメントがあるわけでもない謎の関数とか，フラグとしてもカウンタとしてもアドレスとしても使われる謎の変数とか， それの名前が謎の３文字だとか，そういうやつだ． 運が良ければその謎の３文字は謎の PDF ファイルの用語集とかに載っていることもある*7．

あと，そういう背景と，組み込みってやつが C言語 でありがちなことが悪魔合体してとても直視できない代物になっているところも多い． 我々ソフトウェアに気持ちがあるマンでも「こればっかりはどうしようもないので void* で......」みたいなことばかりやることになるのだから． そして，悲しいかなこれが動いてしまうのである．気合と根性で． いや，動かないこともあるけど，そんなことになっていたらデバッグは困難を極める． というか「ちゃんと動いている」ことの判定すら難しい．その「動作試験」にはどれだけ妥当性があるのだろうか．

で，もう何を言いたいかわかると思うけれど，これが「軌道上実績」というやつと非常に，非常に相性が悪いのだ． 気合と根性で宇宙で１回動いてしまったら，もしくは動いたように見えてしまったらもう悲惨である． それはもう軌道上実績である．免罪符の誕生である．なんてことだ．もう助からないぞ！！！

軌道上実績があるということは再利用できるということだ．きっと使い回せる．きっと． 今度は前と少し違ったミッションをしたい．少しなのでそんなに変更点はないはずだ．

じゃあ実装変更しようか～，............どこを！？！？

......みたいなことは容易に想像が付く．

では，そのコンポーネントは丸ごと使い回すみたいな場合だったらいいのか？ソフトウェアに「改修」が「必要ないはず」だったらいいのか？

そんな甘い話は無いということは，我々ソフトウェアエンジニアは「2000年問題」とでも横から囁かれたらハッとするはずである． まあ僕はその年に生まれたんでその時のことは知らないのだけど．

そう，ソフトウェアは腐るのだ．コードの書き方がひどかろうとマトモであろうとだ． 2000年問題みたいないずれ来ると分かっていたものならまだマシだ． 宇宙業界にだってちゃんとそういう話はある． まあ正直あんまり表に出てないだけでたくさんあるだろうと思うのだけど，最も有名な事例はアリアン５初号機というロケットのバグだろう．

www.shippai.org

ja.wikipedia.org

これは 64bit 浮動小数点数から 16bit 整数 へのキャストでオーバーフローして制御装置がハングし，５億ドルが文字通り爆発して吹き飛んだ，「高くついた」バグとして名高い． そして，このシステムはアリアン４の「実績のある」実装を再利用したものだ． アリアン４ロケットは実際とても実績のあるロケットだ． だが，アリアン４では水平方向の加速度がこのキャストに失敗しない程度の範囲に収まっていたことで，このバグは発現してこなかった． ところが，アリアン５では性能が上がり，あら残念，というわけだ．

（これはこれで雑な物言いであることは承知の上で）ソフトウェアの「実績」なんて割とそんなもんである． なぜ，どのように「実績」が打ち立てられてきたのかにこそ意味があるが，「実績」そのものは安心するための言い訳でしかないことは常に頭の片隅に入れておくべきだ．

こういうことは高校生の時から思っているし，弊社と巡り会う前からずっとそういう気持ちがある．

*8

「必ずしも新しい技術がいいとは限らない」とか言ってる人も見たことがあるけれど，そんなの当たり前だ． 当たり前のことを言って何かカッコイイことを言った気にならないでほしい． だったら「古い技術」ってやつだっていいとは限らないに決まってるだろうに． 技術選定をサボるな．

「古い技術」が信頼するに足るとき，その理由はその歴史の長さから well-tested なことが期待できるからだ． 使われ続けてきて，先人が足を踏み抜きまくり，穴が潰されてきたからだ．古いからじゃない． それっぽい言い方が好きなら，「踏み均された」とか言ってもいい．

欲しいのは安心感じゃない．踏み均された有用性・確実性と，高速に踏み均すための仕組みだ．

「宇宙開発」をソフトウェアでやっていくということ

弊社では人工衛星を作っている，とよく言っているけれど，それだけではあまり正確ではない． では何を作っているかというと，人工衛星と人工衛星の作り方を作っている，というのが正しい． 人工衛星をたくさん作ろうとしているのだから，一つ一つをゼロからチマチマ作り直していたら単純にやってられない．コストがかかりすぎる． コストが何かと言ったら，原義コストであるところのお金と，上で書いた人間計算量だ．

原義コストについては，上で書いた COTS なブツを使うとか，買っていたコンポーネントを自作するとか，そういうことはできる． できるのでやるけれど，結局のところ大事なのは確立された開発・生産方法と，量産だろう． 目の前でチマチマとした努力をしたところで，１０～１０００機とかのスケールに対して毎回「一点物」をやっていたら人生が終わってしまう． それこそ大型衛星では数個でも終わってしまうという話は聞く．人生が終わるだけで作れはするとかならそういうタイプの買い物で済むけども．

じゃあ何をやらないといけないかって，人工衛星とかいう面倒な代物を速く・安く作れるやり方・仕組みを作らないといけない． そして，うまいやり方とか仕組みみたいなやつを作るのって，我々の大好物なところなわけだ． そもそもオーダーを下げるみたいな発想がソフトウェア的でもある． 目的がソフトウェア的なんだから，ソフトウェア的にやって何も損は無いだろう．それこそ踏み均された方法論はたくさんある． ちょっと適用先が見慣れないだけだ．開発体制とか，組み込み開発とか，ナイーブには組めないテストだとか．

まあ色々と面倒な対象はあるが，個人的には最近は「開発体験」みたいなものに気持ちがある． この前 id:koba789 に教えてもらったのだけど，英語だと "Developer Enablement" みたいな言葉があるらしい．いい言葉だ． 開発体験をよくする活動は，まさに人間計算量を下げるための一つのアプローチだ．

我々が Rust でやっていくと常々主張しているのだって，開発体験のためによるところが大きい． 組み込みソフトウェア開発ではありがちだけれど，謎の巨大 IDE を苦労してインストールして*9， 謎の何故か不安定な上にシングルスレッドなビルドシステム*10がチマチマと謎のCコンパイラ*11を呼び出していくのをジッ......と待って， ようやくビルドできたものをポチポチして書き込むとか，やってられんのだ． 仕事でそんなことしないといけないものなら労災請求したくなる．いやカネ貰ってもやりたくはないが．

単に手元でやってられんと僕が済むだけならまだマシですらある．自動化できないのだ．CI も組めない． そしてまた，ああいったソフトウェアもソフトウェアが主戦場なわけではない人間が作っていがちなことによって，どうにも挙動もとても不穏ないしは不安定だ． 何をどうしたらあんなことになるのかはよくわからないが，しかし現実としてそうなのだ． 大抵は「枯れた技術」ってやつをちょっとビルドして試してみたいだけなのだけど，それすらままならないこともある． 仮にソースコードは信頼できるとして，あの不安定な開発環境が吐き出したバイナリをどれだけ信頼できるだろうか． 個人的にはとてもじゃないが安心して首を縦には振れない． しかし悲しいことにこういう点は「枯れた」判定をする人の視界の外にありがちだ．

さて，一方の Rust である．

環境構築？ rustup を入れよう．組み込みならお好みのターゲット向けに rustup target add も叩いておくといい．

ビルド？ git clone して cargo build．それだけだ．

もちろんそれだけにするために中で色々なことをやってはいるのだけど，ありがたいことにそのエコシステムは結構整ってきている．しかも全部オープンソースだ． ボードが違うとか，アーキテクチャが違うとか，そういうのは当然あり得るけれど，何より Rust というエコシステムそれ自体が様々なモノを細かい責務に（半ば偏屈なほどに）分割可能だしする特徴がある． std と core が分割されてるのなんかも最高だ．そして，これが本当に都合がいい． それこそ別のボードに移植するみたいな話も，そのボード特有の部分の crate を切って開発すればいい．trait があればそれに沿って実装するだけだ． そして実装したものは他の crate と驚くほど簡単かつ確実に接続する． 使う側は Cargo.toml に crate とバージョンを書くだけだ．2023年現在の本当のコードの再利用の姿はこういう形だ． Git submodule？冗談も大概にしてくれ．

とまあ Rust をべた褒めした（安全性とかはみなさん言っているしもはや当然のものなので書かなくてもいいでしょう）けれど， じゃあ一気に全部 Rust で書き直すのかというとそういうわけでもない． 別に Rust が向いていないケースだってたまにあるし，なにより C/C++ で書かれた本当に有用な（踏み均された）資産が世界に満ちているのはみなさんご存知だろう． そもそも普通に Rust でアプリケーションを書いてもみなさん glibc のお世話になっている． で，Rust ってやつは C/C++ の資産を適切な形で再利用するのにも超便利なんだな，みたいな真面目な話はいくらなんでも長くなってきたので別のところで書こう．

とまあ，本当に長々と書いたが，最近はこういうかんじだ（どういう？）． なんでこんなポエムで１２万字（今見たら倍になってた．なんで？）とか書いてるんだろうな．

ポエムだし，ピチピチの大学一年生（２回目）なので，恥ずかしいことでも言って締めということにする．

結局のところ，やっていくぜということだ．準備は結構整ってきた．やっていこう．

*1:まあ，ChatGPT みたいなやつにレビューされるようになった時にムカつかないかというとちょっと怪しいが

*2:空気がほぼ無いところで動くので空冷とかしてなくてギチギチというのはある．

*3:仲間内で"文化祭病"と呼んでいる．

*4:ちなみにこれはカーマン・ラインというやつだ．雑に地上と書いたけど，正確には海抜高度から 100km としている．とはいえ，そのキリのいい数字から分かるように，これは「まあそんくらいでいいよね」という値である．なんなら「80km にしてもいいんじゃね？」みたいな話もあったらしい．実際アメリカの軍とかは50海里とか 80km とかの値を使っていることもある．

*5:一回こういうの書いてみたかった

*6:アポロ計画の時代であれば，あれは載せる側のためにロケットを作っていたし，少しでも切り詰めようとしていたので数kgとか減らせたらパーティーものだったみたいな話もあるけれど，現代ではロケットもできるだけ同じ設計で同じものを作るし，そこまでの切り詰めは基本的にやっていないので，そのぐらいの余裕はある．なくても余裕があるやつを使えばいいのだ．実はロケットってやつは日々たくさん打ち上がっている．

*7:まあそれも事前に誰かが相当苦しんだ結果としてのものだろうし，その場合でも命名を見直すとかより気合で覚えるみたいなかんじになりがちである

*8:まあこれは大学１年生（１回目）のときのツイートだが，この前から思っているし，「宇宙」で「ソフトウェア」をやりたいと言い続けてきた理由の一つだ

*9:たまによくインストーラも本体の IDE も機嫌を損ねてダンマリしがち

*10:実は GNU Make を呼び出していた，とかならだいぶマシなのだけど，なんかよくわからないやつもたまにありがち

*11:GCC 4 系の fork ならまだマシだが，なんかそうでないやつもあるし，そうだったとしても本当に謎のパッチが当たっていて gcc なのにも関わらず動作が不安定になっている，みたいなことすらある．GPL にありがとうと叫びながらソースコードは見られるが，果たしてビルドできるかは見物だ