
この記事でわかること
-
未知のドメイン(宇宙開発など)へ越境するための学習アプローチ
-
AIツールの普及による「開発のスケール変化」と品質担保の仕組み
-
キャリアの空白期間や技術発信を通じた、自己理解とモチベーション整理術
新卒でWeb系の事業会社に入社し、基盤開発などで活躍したのち、未知の領域である「宇宙開発」へと活動の場を移したKOBA789氏。現在は株式会社アークエッジ・スペースで、人工衛星のシステム設計からソフトウェア開発まで幅広い領域を牽引しています。
本記事では、KOBA789氏へのインタビューを通じて、ドメインの壁を越えるためのキャッチアップ術や自己分析、そしてAI時代における品質担保の考え方まで、エンジニアが生き抜くための実践的な知見をお届けします。
▶ソフトウェア開発とは?種類や仕事内容、プログラミングとの違いを解説KOBA789さん
株式会社アークエッジ・スペース ソフトウェアエンジニア
2017年に新卒でクックパッド株式会社に入社。ログ分析基盤や検索基盤の開発・刷新を行う。2021年2月に退職後、半年間の無職を経て同年9月から株式会社アークエッジ・スペースにて人工衛星関連のソフトウェア開発に従事。YouTubeでの配信活動も行っている。
【X(旧Twitter)】:https://x.com/KOBA789?lang=ja
株式会社アークエッジ・スペース
「衛星を通じて、人々により安全で豊かな未来を。」をミッションに掲げる、東京大学発の宇宙スタートアップ。超小型衛星の設計・開発から量産化、運用まで総合的なソリューションを提供するインテグレーターとして、IoT通信や地球観測など多様なミッションに対応可能な人工衛星コンステレーションの構築を目指す。
【HP】:https://arkedgespace.com/
目次
Webから宇宙へ。人工衛星の「全体設計」を牽引する普遍的なエンジニアリング
まずは、アークエッジ・スペース様がどのような事業を展開されているのか、簡単に教えていただけますか。
当社は「衛星を通じて、人々により安全で豊かな未来を。」をミッションに掲げる、超小型衛星システムの総合インテグレーターです。次世代の海洋通信インフラや衛星データの利活用、新たな衛星測位システムなど、多様なミッションに対応可能な高性能な超小型衛星の設計・開発から量産化、運用までを総合的に提供しています。

なるほど、民間主導で自社サービスとして多角的に事業を展開していくスピード感はスタートアップならではですね。その中で、KOBA789さんは現在どのような業務を担当されているのでしょうか。
一言で表現するのが難しいのですが、役割としては「衛星のシステム設計」という範囲になります。考慮する対象は非常に幅広く、電力、熱、姿勢、軌道といった物理的な要素から、無線通信(RF)、地上の管制システム、そして人工衛星内で動くオンボードのソフトウェアまで多岐にわたります。簡単に言えば、異なる専門領域をつなぎ、一つのシステムとして成立させる仕事ですね。
| システム設計で行うこと | 衛星における具体例 | 目的 |
| ミッション要求を技術要件に落とし込む | 観測の頻度や精度、データを地上へ届けるまでの時間を、軌道、姿勢、通信、処理能力などの要件に分解する | 何を作ればミッションを達成できるかを明確にする |
| システム全体の構成と接続方法を決める | 衛星内の機器、オンボードソフトウェア、無線通信、地上局、管制システムの役割分担やインターフェースを設計する | 個別の要素を、一つのシステムとして機能させる |
| 制約や異常時を含めて全体を成立させる | 電力、質量、熱、通信容量などを調整し、通信できない時間帯や機器故障時の動作も考える | 打ち上げ後に直接触れられない衛星を、継続して運用できるようにする |
調整しなければならない領域の広さに驚かされます。前職でのWeb基盤開発のご経験からすると、全く違う次元のお仕事のように感じますが、重なる部分はあるのでしょうか。
コンピューターを使っているという意味でごく一部は重なりますが、基本的には「全く違う」と言った方が正しいですね。ただ、普遍的なコンピュータサイエンスの知識や姿勢は活きています。
コンピュータがなかった時代にゼロからシステムを作り上げてきた先人たちの歴史や背景に思いを馳せ、「何もないところから立ち上げていく人たちの思考の型」をなぞれることが、現在の全く新しい環境でシステムを構築していく上で大きな武器になっています。
そもそも、なぜそこまで未知の領域である宇宙開発のスタートアップへ挑戦しようと思われたのでしょうか。
誰もやり方がわからない未知の領域で奮闘しているのを見て、自分のエンジニアとしての課題解決力が活かせる、参画する意味があると感じたからです。きっかけは、前職を退職して半年ほど無職期間を過ごしていた時期に、アークエッジ・スペースの創業エンジニアから声をかけられたことでした。
いざ話を聞いてみると、彼自身が会社づくりや人工衛星の産業化という「前例のない壁」に直面していたんです。そこで本気で試行錯誤している状況が伝わってきて、「自分にできることで力になりたい」と感じたことが、挑戦を決めた大きな理由ですね。
ご自身のキャリアの志向として、新しいプロダクトを作ることよりも、技術をどう社会に役立てるかに関心があったのでしょうか。
そうですね。仕事としてやるからには、社会の役に立っていないとフェイクだと思っていて、そこは絶対に外せない部分でした。というのも、私は7歳からプログラミングを始め、長くコンピューターの技術を追求してきた分、データだけで完結する世界には少し飽きが来ていたんです。
それに、もともと電子工作など物理的なモノづくりの趣味を持っていたこともあり、「コンピューターをどう使うか」という技術的関心よりも、それを「何に使うか」、つまり現実世界の課題にどう作用させるかへと関心が移っていました。超小型人工衛星はまさに社会課題の解決に向けてユースケースを広げていく段階だったため、自分の技術でそこを実用レベルまで持っていくことに意義を感じたんです。
「絶対に壊れない」より「柔らかい」システムを。宇宙開発に挑むエンジニアの仕事
貴社が開発している「超小型衛星」は、デスクトップPCほどのサイズ(6U衛星の場合)しかないそうですね。
はい、36.6cm×22.6cm×10cmという、机の引き出しにも入るようなサイズ感です。実績としては、2025年1月に運用を開始した当社の6U衛星「YODAKA」では、低消費電力で長距離通信が可能なLoRaを用いて、宇宙を介した短歌の送受信を行うなどIoT通信ミッションの実用性を確認しています。他にも、ハイパースペクトルカメラを搭載したリモートセンシング衛星「AE2a」など、多様なミッションに対応しています。

宇宙から短歌が送られてくるというのは非常にユニークです。 宇宙開発というと「絶対に壊れないように神経をすり減らして作る」というイメージを持たれがちですが、そうした超小型衛星の開発現場は少し違うのでしょうか。
そうですね。一度打ち上げると手が届かない「非修理系」のシステムであることは間違いありません。しかし、見えない・届かないところでは必ず予想外のことが起きます。だからこそ、ガチガチに固めた「絶対に壊れない」システムを目指すのではなく、多少バグってもワークアラウンド(代替策)で回避できる「柔らかい」システムを作ることが重要なんです。
| 比較項目 | 宇宙開発における一般的なイメージ(誤解) | 開発現場のリアル(真実) |
| 信頼性へのアプローチ | 「絶対に壊れない」よう神経をすり減らして作る | エラー前提でログ取得や軌道上アップデートを可能にする「柔らかい」設計を重視 |
| 宇宙放射線への対策 | ハードウェアで完璧な対策を行う必要がある | ハードでの対策は限界があり、ECCメモリ等のハード機構とそれを活用するソフトを組み合わせ、システム全体でカバー |
| 求められる専門知識 | 姿勢制御など、高度な物理学や宇宙工学が必須 | 物理に加え、NANDフラッシュのドライバやWebシステム等、普通のシステム開発の分量が多い |
エラーは絶対にログに残し、軌道上でソフトウェアをアップデートして直していくアプローチなのですね。宇宙という特殊な環境でありながら、Web開発で重視されるアジャイルやモダンな開発の考え方と通ずる部分が多いことに驚きました。
まさにその通りで、開発の進め方だけでなく、技術や言語の選定思想も地続きなんです。以前、衛星のフライトソフトウェアにRustを採用している理由について、X(旧Twitter)で「一番の理由は何か?」とアンケートをとったことがあります。

そのとき、多くの方(74.7%)がメモリ安全性などの「信頼性」と予想されました。ですが、フライトソフトウェアでRustを採用している実際の理由は「生産性(書きやすさ)」です。
衛星のフライトソフトウェアで、信頼性よりも「生産性」を重視しているというのは意外ですね。
背伸びした渾身の一撃を作るのではなく、継続的・加速度的に技術を成長させたいと考えているからです。技術の発展には、試行錯誤の繰り返しが一番効くと信じています。作りやすくなれば試行錯誤のサイクルが速くなり、より速く高度な技術が手に入りますから。
ただ、私が入社した当時はビルドや書き込みの手順すら確立されていない黎明期でした。自分が実装したものがそのまま社内の標準になってしまうリスクがあったため、そこは非常に慎重に進めました。
ドメインの壁を越える「仮説検証型」のキャッチアップ術
全くの異業種である宇宙開発の世界に飛び込んだ際、ドメイン知識のキャッチアップはどのように進められたのでしょうか。
入社当時は、人工衛星とロケットの関係すらわかっていない状態でした。まずは「何もわかっていない」という事実を受け入れ、課題に対して極めて謙虚になることから始めました。思い込みで行動すると必ずトンチンカンなことをしてしまうからです。
謙虚になる、というのは簡単そうでいて経験を積むほど難しいことだと感じます。具体的にはどのようなプロセスで知識を吸収していったのですか。
まずは軌道の種類や用途、真空中での力学的な運動など、物理の原理原則から腹落ちするまで理解することに努めました。社内の詳しい人に質問し、自分でも検証し、また質問する。これを繰り返していくと、実は詳しい専門家の説明の中にも、原理原則からの応用という点で矛盾が生じていることに気づく瞬間があるんです。その矛盾を突くことで、結果的にシステムの設計改善のヒントを抽出することができました。
素人目線での本質的な問いが、専門家の盲点を突くことになったのですね。ソフトウェアの新しい技術やツールを評価する際も、同じようなアプローチをとられているのでしょうか。
話題のソフトウェアがあれば、単にマニュアル通りに動かすのではなく、コードを直接読みに行きます。ただ読むのではなく、「事前に自分なりに『それをどう実現しているのか』の仮説を立ててから読む」ことを徹底しています。
| ステップ | 新技術をハックする「仮説検証型」コード読解プロセス | 目的・得られる気づき |
| ステップ1:仮説立案 | 謳い文句から「自分ならどう実装するか」を推測する | 自身の既存知識との境界線を明確にし、設計者の思考をトレースする準備をする |
| ステップ2:コード読解 | 実際のコードを読み、自分の仮説とのギャップを確認する | 自分が思いつかなかったアプローチや、実装の巧みさを客観的に把握する |
| ステップ3:原因の同定 | 仮説が外れた原因(前提の誤り、未知の原理、誇大広告)を分類する | 自身の要件定義の甘さや未知のアルゴリズムを知り、技術の解像度を劇的に高める |
この仮説検証型のコードリーディングは非常に高度ですね。単に「使ってみる」だけでは得られない「設計者の思考」までトレースできそうです。
マニュアル通りに使うのは誰にでもできます。私が知りたいのは「なぜ自分はこのアプローチを思いつかなかったのか」「どうやったら自分にこれが作れるのか」という部分なんです。この思考訓練の繰り返しが、未知の技術に対する解像度を劇的に高めてくれます。
「何もしない半年間」が教えてくれたこと。エンジニアのキャリアを加速させる自己認知と発信
少し時間を遡りますが、前職を退職された後の「半年間の空白期間」はどのように過ごされていたのでしょうか。優秀なエンジニアの方だと、時間ができると個人開発など色々なことに取り組むイメージがあります。
コロナ禍のど真ん中だったこともあり、Webサービスを設計して途中まで実装してみたり、海外の大学の講義動画を手当たり次第に見たりしてみました。
やはり色々とインプットやアウトプットを試されていたのですね。そこからどのような気づきがあったのでしょうか。
結果として「自分は一人でゼロから新しいものを作り続けるような、根っからのクリエイタータイプではない」ということがはっきりと分かり、諦めがついたんです。やりたいと思っていたことの99%は、いざ手をつけてみるとそこまで気乗りせず、1人では何もやる気にならないことに気がつきました。
| 取り組み内容 | 「空白期間」のアウトプットを通じた仮説 | 実際の結果と得られた気づき |
| 個人でのWebサービス開発 | 時間があれば、1人で優れたプロダクトを作れるはず | ソロでの創作志向は強くなく、気乗りしないため途中で投げ出してしまった |
| 大学の講義動画での学習 | 幅広い分野の最先端の知識を身につけられるはず | ミーハーなだけで身にならなかった |
| YouTubeでのライブ配信 | コロナ禍のよい暇つぶしになるはず | 「取り繕えない所作」から自身の思考の癖や強み・弱みを客観視する装置になった |
それは非常に興味深い自己分析ですね。日々の業務に追われていると「時間さえあればもっとすごいことができるはずだ」と思い込んでいるエンジニアは多いと思います。
まさにその通りで、私自身もそう思っていました。ですが、実際に時間があってもやらないんですよね。自分が意外とクリエイティブではないと気づいて満足したことで、「時間があったらあれもできるのに」という邪念がなくなり、かえって目の前の仕事に深く集中できるようになりました。この自己理解は、今の仕事への向き合い方にもすごく良い影響を与えていると思います。
個人での創作志向が強くないと気づいた中で、YouTubeでの発信活動だけは継続できている理由は何でしょうか。
「自分が本当に気が向くこと」しかやっていないからだと思います。発信内容を、キャリアアップのため、トレンドやブームに乗るためなど、外部の動機に委ねてしまうと、他人の期待に応えるうちに自分の本心からどんどんズレていきます。そして、結局は継続できなくなってしまう。
だからこそ、私は「気が向かないことは絶対にやらない」という自分のルールを徹底しているんです。純粋な興味やモチベーションだけを大切にしているからこそ、無理なく自然に続けられているのだと思います。
テキストのブログ記事などではなく、あえて動画、それも「ライブ配信」というフォーマットを選ばれているのには理由があるのですか。
ライブ配信は「取り繕えない」のが面白いんです。とっさに出たコードの書き方や思考プロセスには、自分に染み付いている技術や習慣、考え方の癖がどうしても表に出てしまいますから。
だから私にとってライブ配信は、「自分を客観的に観察するためのツール」のような感覚なんです。アーカイブを自分で見返すと、自分の強みや弱みがリアルに浮き彫りになってくる。そうやって自分の思考の癖に気づくことで、日々の技術や習慣をアップデートしていくための良いヒントになっています。
AI時代こそエンジニアリングの基本を。仕組みで品質を担保し、新たな領域へ踏み出す
品質担保や開発効率という文脈で、昨今のAIツールの普及は現場にどのような影響を与えていますか。
一番大きな効用は、AIによって「試験の物量」に対処できるようになったことです。ハードウェアの品質はどれだけ試験をしたかで決まる部分が大きいのですが、超小型衛星はコスト制約が厳しいため、これまでの人力の試験では、優先度の低い項目はリスクを許容して後回しにせざるを得ませんでした。そこをAIエージェントなどの力を借りることで、品質の底上げ、いわば「マイナスの取り戻し」ができるようになりました。
AIがコードを大量生成する時代になり、エンジニアからは「AIが出力したコードの正確性をどう担保すればいいのか」と悩む声も多く聞かれます。AIの出力を人間がチェックするコストが逆に跳ね上がっている現場もあるようです。
そういった声を聞くこともありますが、そもそも「AIがない時代、人間はミスをしなかったのか?」というと、そんなことはないですよね。AIの登場によって変わったのは、ミスの有無という問題の本質ではなく、生み出されるコードの「圧倒的な物量(スケール)」なんです。人間が手作業で書いていた頃は物量が少なかったから誤魔化せていた「品質を担保する体制の不備」が、AIによる桁違いのアウトプット量によって一気に表面化しただけなんですよ。
なるほど。開発プロセスの全体像に当てはめて考えてみると、AIというツール自体が問題なのではなく、生み出される大量のコードに対して品質を担保する「仕組み」が追いついていないという構図が明確になりますね。
その通りです。対策としては、まず自動テストの徹底。次に、Rustのような型システムの強い言語を採用し、コンパイル時に論理的な誤りを検出すること。さらにクリティカルな部分には形式手法による証明を用い、それでも本番で起きたエラーに対しては、即座にロールバックや緩和ができる運用フローを全体で作り込むことです。
| 品質担保のフェーズ | 従来の手法・課題 | AI時代にアップデートされた仕組み |
| 開発・実装時 | AI生成コードの目視チェックに追われ、人間がボトルネックになる | 「テストコードのない変更は許可しない」方針とし、AIを活用して自動テストで網羅率を上げる |
| コンパイル時 | 実行時に想定外のバグや論理エラーが発生する | Rustなど型システムの強い言語や関数型要素を採用し、コンパイル時に論理誤りをあぶり出す |
| 運用・本番環境 | デプロイ後に致命的なエラーが発覚し、対応が遅れる | クリティカルな部分には形式手法で証明を行い、万一のエラー時も即座にロールバックできるフローを構築する |
AIだからと特別視するのではなく、エンジニアリングの基本に立ち返り、許容できる範囲までリスクを減らす仕組みを構築することが重要です。
基礎的なエンジニアリングの徹底こそが、AI時代を生き抜く鍵になるのですね。最後に、KOBA789さんのように新しいドメインへ越境してみたいと考えているエンジニアへ、アドバイスをお願いします。
まずは飛び込んでみればいいんじゃないかと思います。ただ、漠然と悩んでいる時は、自分自身の「モチベーション」に対して自覚的になることをお勧めします。なぜその分野に行きたいのか。例えば、新しい知識の範囲を広げたいのか、給料を増やしたいのか。その動機を言語化し、具体的に分析できれば、未知の領域に飛び込むリスクの緩和策を見つけられるはずです。自分の軸を明確にして、恐れずに新しいチャレンジに踏み出してみてほしいですね。
ライター