重力に縋るな

千種夜羽です

セキュリティ・キャンプ2024全国大会で「探査機自作ゼミ」をやった

セキュリティ・キャンプ seccamp

お久しぶりです。sksat です。 タイトルの通り、セキュリティ・キャンプ2024全国大会で、「探査機自作ゼミ」というゼミを開講させてもらいました。 まあ色々やったので、つらつらと書いていきます。

（この記事を書くのがめっちゃ遅くなってしまったのはすみません......）

（流石に年を跨ぐのはヤバいなと思って今になっての投稿です）

（と思っていたら JST では年跨いでしまいました。あけましておめでとうございます。でもまだ2024年な国もあるので許してください。）

「探査機自作ゼミ」とは

「探査機自作ゼミ」、どう考えても怪しい文字列ですね。 探査機ってなんやねん。それを自作とは。

まあまずは講義概要を見てみてくださいよ。え？長い？

www.ipa.go.jp

一緒に探査機を作ってみませんか？

このゼミでは惑星探査機の開発を題材として，複雑なシステム開発への向き合い方を，実際に手を動かしながら考えます． （中略） このゼミでは，模擬的な惑星探査機の自作を通して，システムズ・エンジニアリング的な観点を持ってチーム開発を体感してほしいと考えています．他の受講生と，そして講師と協力しながら，ひとつの探査機というシステムを作っていきましょう．自分より上ないし下のレイヤや，別の人が開発しているサブシステム，システム全体，開発体制のことを考えながらものづくりをする経験は，宇宙開発に限らず，あなたが将来大きなものづくりに関わる時に確実に役に立つと信じています．皆さんの応募をお待ちしています．

はい。というわけで、探査機というのは模擬的な惑星探査機のことで、その自作を題材に複雑なモノへどう向き合うかを体感する、というのがこのゼミのテーマでした。

ゼミの設計

このゼミは今年始めて実施したので、まずどのようなゼミにするかを考える必要がありました。 最初に来た講師依頼は正直「Rust とか宇宙とかそういうかんじの、どうよ」というかんじだったので、かなりゼロからの設計となりました。

話が来たのは開発コースだったので、集中的にナニカを作るネタにすることはほぼ確定していました。しかし、はてさて、何を作りましょうか。 まあ僕は普段仕事で人工衛星を作っているので、セキュキャンでも人工衛星を作ることができればアツいんですが、いくら比較的安くて短期間で作れる人工衛星を作っているとはいえ、ちょっと期間が短いですし、流石にロケットを確保できそうにありません。

そこで、人工衛星というか、宇宙開発の面白い部分を抽出してナニカを作ることができるとよいのかな、というのがまず雑な発想としてありました。

で、宇宙開発の何が面白いかといえば、もちろん自分の書いたコードが軌道上にデプロイできる、みたいな部分やミッションそのものもありつつ、総合格闘技である、という部分も個人的にはすごく強いと感じています。

ソフトウェアエンジニアというロールで働いていたとしても、特定のソフトウェア技術の話をひたすらしているなんてことは一切なく、考えることがあらゆるレイヤで無限にある上に絡み合っています。 去年こんなブログも書きましたね。 sksat.hatenablog.com

ちなみに、ここ１年ぐらいは姿勢制御のソフトウェアを中心にどうにかするチームを立ち上げて色々やっています。 その範囲内でも、制御のアルゴリズムの議論をすることもあれば、よりよい設計をソフトウェアアーキテクチャ・コンポーネントの選定や配置などから考え直してみたり、検証のためのシミュレータの設計を PoC を作りながら探ったり、別々の人工衛星のためのソフトウェアの開発体制を考えたり、コンポーネントのドライバをゴリゴリ書いたり、実機での開発をラクにするための治具をラズピコで作ったりと、やることも考えることも本当に多岐に渡ります。

もちろん姿勢制御以外のいわゆる Platform Enginnering 的なことも続けています。 抱え込みすぎていてよくないし、信頼できる仲間も着実に増えてきているのでちゃんと移譲していきたいというのもありつつ、多くのコンテキストが交わるからこそ感じられる面白さというものも確実にあり、バランスが悩ましいところです。

これはダイマですが、最近は†衛星運用†ってやつも始まってめちゃめちゃ面白いことになっています。

arkedgespace.com

さらにメタな視点としては、そんなに毎回考えることが多いと（特にたくさんの人工衛星を作る時に）認知負荷が大きくて大変すぎるので、認知負荷を抑えるためにどのような設計がよいかを考え続け、そこに向かって現状を少しずつ漸近させていく、という活動が必要になるわけです（もちろん、これもあらゆるレイヤで）。 そしてこれもすごく面白いんですよね。

......みたいな直近の自分の気持ちを踏まえはしつつ、独りよがりにはしたくありませんでした。僕（だけ）ではなく、受講生のみなさんが楽しめるゼミにしたかったわけです。 そこで、「中学生のsksatが見たら噛り付いて応募する」という仮想的な目標を置き、ガリガリと最初の Design Doc を書いてゼミの基本コンセプトを決めました*1。

ゼミ設計のための初期の Design Doc

テーマ設計

ということで考えたゼミの基本コンセプトが、「やたら考えることの多い CanSat のチーム開発」です。 CanSat というのは、まさに教育のために作る、空き缶サイズの模擬的な人工衛星のことです。

ja.wikipedia.org

僕も過去に一度理科大の宇宙教育プログラムでやったことがあります。

www.tus.ac.jp

そしてありがたいことに、過去にネクストキャンプで CanSat をやったことがあったようです。 ハードウェアが絡むことですし、似たような前例があると事務局などへの調整もしやすくなりそうです。

www.ipa.go.jp

さて、CanSat のようなことをやるのはよいとして次に問題になるのが、どのようなテーマ設定をするかです。 ここで最もありがちなのは、Comeback Competition と呼ばれる競技です。

www.jstage.jst.go.jp

これはフィールド上にゴールとしてカラーコーンなどが置いてあり、その緯度経度が与えられているので、ロケットやドローンなどから CanSat を放出し、着陸してゴールに向かっていく、というようなものです。 ネクストキャンプで行われたのもこの Comback Competition のようで、フィールドとして近くのグラウンドを確保して当日そこまで移動する、というようなこと自体は事務局とも調整可能なようでした。

しかし、Comeback Competition ではあまり考えることが多くならない、という問題がありました。 「与えられた座標に GNSS で向かっていき、最終的な誘導は画像処理で頑張る」というような定石があり、やることが割と目に見えているのです。 *2 また、セキュキャンの場合はハードウェアの設計からやっている時間的な余裕がありません。 事前学習期間を活用するとしても、その間はオンラインでのやりとりになる上、みなさんの家には3Dプリンタはおろか、半田ごてすら無いかもしれません*3。

そうなると、色々やったところで「なんかよくわからないけど、マイコンとか、NMEA のパースとか、画像処理とか、大変だったね」という曖昧な夏の思い出になって終わってしまうかもしれません。 それはそれでいい思い出になったり、組み込みの面白さに目覚めたりしてくれる可能性ももちろんありつつ、そういう結論にするのであれば、わざわざ僕という人間がやる意味はちょっと薄いです。 体感してほしいことの目的がズレてしまうという意味でも、その目的であれば僕よりも教えるのが上手い人間が他にいるという意味でも。

あとは単純な問題として、GNSS での誘導のデバッグはどうしても外に出てやりたくなりがちで、セキュキャンの短い時間（全体では５日あっても、開発コースとしての実作業時間は３日程度）を外と室内を行き来する時間で消費してしまうのはもったいない*4し、季節的に熱中症になられても困る、というの課題もありました。

そこで、あえて Comback Competition ではなく、以下のようなテーマというか、設定を導入することにしました。

  • 惑星探査機（着陸機）
  • 本体の探査機は別にあり、作るのは子機

なんとも曖昧な設定ですが、この曖昧さは意図的なものです。 具体的には、以下のような理由によるものです。

  • 本当はミッションそのものから考えてみてほしいが、流石にそこまでやる時間的余裕は全く無い*5
    • 気持ちと腕力のある人間がいれば機構設計のような HW まで手を出してもらうのはやぶさかではないが、とはいえ初期実装は欲しい
  • 何をゴールとするか（サクセスクライテリア）を自分たちで協力して考えてほしい
    • 自分で考えたゴールのためのスケジュールを自分で考えてみてほしい
    • ゴールすら変数であるという一種の"複雑"性を感じてほしい
  • いくらでもゴールを難しくする余地がある
    • 何をどのように"探査"してもよい
    • 親機との通信など。親機の開発は sksat がやっているという設定なので、sksat とのインターフェース調整のようなこともできる。

また、ゼミの名前については、"CanSat"という語はどうしても Comeback Competition を想起してしまう（知らずとも調べるとそのような印象を受けてしまう）ので意図的に排除し、「OS自作」や「Cコンパイラ自作」にあやかって、キャッチーさも少し狙って「探査機自作ゼミ」としました。

ちなみに、「信頼性のための Rust」みたいな話は入れないことにしました。*6 この理由は２つほどあります。

１つ目は、単純に僕の専門というかメインフィールドはそこには正直無いからです。 これについても、おそらく別の適任な人がいるでしょう。中途半端なゼミにしないためにも、これは譲れない事実でした。 実際別にS15『Rust プログラム検証ゼミ』が開講されたりしたわけです（この時には知りませんでしたが）。

２つ目は、Rust で書いたら既存の C/C++ などで書くより"安全"なコードを書きやすい、というのは単なる事実以上のことは無いからです。 もちろんその上で色々なテクニックはありつつ、セキュリティ・キャンプはテクニックを伝えて終わり、という場ではないと思っていますし、Rust の難しさの大半はコンピューターの難しさというところもあり、Rust を学ぶというよりはコンピューターを学んでほしいし、Rust はそのよいきっかけのひとつでしかないと考えているからです。

これを踏まえた上で、では「"sksat が主催する"ゼミ」によって提供できる価値はなんなのか、と考えた結果が、探査機のチーム開発、というものでした。

専門、と呼べるような資格などは何ひとつないのでおこがましくはあるのですが、僕のここ数年のメインフィールドは複雑性の構造的な改善のためのプラットフォーム的な技術や、開発体制・チーム構造といったヒト方面からの解決なのかなと強く感じているため、このような考えに落ち着きました。

ちなみに、この段階での最大の問題はゼミの人数でした。 セキュリティ・キャンプ2024全国大会開発コースでは、基本的に１ゼミあたり受講生２人まで、という条件が提示されていたのです。

チーム開発をテーマに据える以上、２人を１チームとするのはいくらなんでも無理がありました。 ２人だと逆立ちしても「わたし」と「あなた」という関係性にしかなりません。

僕もチームメンバーとして入るという手もなくはないですが、講師という立場や、結局テーマを持ってくるのは僕であるという構造的な問題から、決して対等なチームメンバーになることはできません。

チューターがいればまだどうにかなったのですが、今年は色々あって開発コースはチューターがいないとのことでした。 というわけで、流石にどうにもならないので、ごく初期の時点で増枠を求めていました。 この早めの調整が功を奏し、探査機自作ゼミは３人の受講生の枠を得ることができました。

その後、怒涛の勢いでゼミ概要と応募課題を設計・実装しました。 最初に声をかけてもらってからそれらの確定の締め切りがちょうど１ヶ月後とかで、かなり慌ただしかった記憶があります。

教材の開発

さて、やることはゼミ概要・応募課題を決めることだけではありません。 なぜなら、このゼミはハードウェアを扱うからです。

そもそもどのようなハードウェアがあればどんなゼミが展開できるか、手段を知る必要がありましたし、ハードウェアやると言いながら僕は構造設計とかはまだまだてんで分かりません。

そこでまずはじめに考えたのは、STEM 教育の教材の流用でした。 しかし、どうにもお手軽な値段の適度な難易度のキットが見当たりませんでした。 載せるコンピューターも大抵 Arduino か Raspberry Pi の二択で、ショボすぎるかリッチすぎるかしかありません。

コンピューター以外の構造物・センサ・アクチュエータのみを流用して、Rapberry Pi Pico とか STM32 とかの適当なマイコンに載せ替える、というのも考えてみたのですが、そういった改造をされることは考慮されていないのでやりにくいです。 実際にいくつか手頃な値段のモノを買って試してもみたのですが、組み立て性が非常に悪かったりして、どうにもよいモノが見つかりませんでした。

やはり信じられるのはタミヤ

そこで辿り着いたのは、タミヤの工作キットでした。 やはり組み立て性・拡張性・改造しやすさ、どれを取ってもピカイチなのですよね。 工作少年だった頃の記憶が蘇ってくるようです。

考えることを多くしたい、という意味では、拡張性に優れているのはメリットとして圧倒的でした。

ですが、そのかわり、コンピュータやセンサについては更地も更地です。だからこその拡張性でもあるのですが。

ここで次に考えたのは、タミヤのキットの板の上に Raspberry Pi Pico のようなマイコンボードとブレッドボードを載せる構成です。 なんか段々どこかのゼミを彷彿とさせる形になってきましたね。

しかし、これにも問題がありました。 ブレッドボードはもちろん簡易的な実験には非常に便利である一方、組める回路に対してサイズが嵩張ります。 複雑性に向き合ってほしい、という元のコンセプトのことを考慮すると、センサはできるだけ多く積みたいです。 たくさんのセンサを積もうと思うと、大きなブレッドボードを複数載せなければならなくなってしまいます。

また、ブレッドボードでは実際に回路を組む手段はジャンパワイヤです。ジャンパワイヤの品質が悪さや、刺しの甘さによる接触不良や刺し間違えのリスクなども、配線数が多くなればなるほど指数関数的に増加します。 そして何より実際それに向き合った時の感覚は「しょーもな」です。

そこで、自分で基板設計をすることにしました。 え？基板設計の経験？ありませんが......

無い経験は積むしかないですねえ。ついでにこれを名目に長らく入門できていなかった基板設計に入門できてお得ですねェ～ 実際の入門は、ちょうどよい友人を家に一晩拉致して招いてみっちり教えてもらう、という方法を取りました。 某氏マジでありがとうございます。本当に助かりました。

教材基板のプロトタイプ第一号 / 人生初の基板設計

KiCad と JLCPCB は本当に便利ですね～。

また、これは明らかに経験がモノを言う分野だということが想定されたため、キャンプの準備期間中は連日のように KiCad を弄り JLCPCB に発注を繰り返すことで PDCA を回していました。 金はかなりかかったのですが、まあその甲斐あって高速に経験を積むことができたと思います。

金の弾丸で基板発注 PDCA を回す図

ここらへんの話はセキュリティ・キャンプ・アフターイベントの飛び入り LT でも話したので、よかったらこちらもどうぞ。 speakerdeck.com

コンセプト再考 ～ 選考のその前に

教材の開発に四苦八苦しながらも、運営側としては重大なマイルストーンである選考の時間がやってきます。慌しいですね。

単純に選考の締め切りがあまりにも短くて大変だったというのもありつつ*7、これはとても、とても大変でした。

仕事では多少採用に関わっていることもあり、人を選ぶ、ということそれ自体にはある程度慣れがあったものの、やはり毛色がまったく異なります。そして何より若者の人生を変えてしまいかねないという事実から来るプレッシャーがありました。 もちろんどの程度・どんな影響があるか／できるかは人によってまちまちではありつつ、僕自身はセキュリティ・キャンプは確実に人生の大きなターニングポイントのひとつではありましたからね。

そういった心持ちだったこともあり、時間は無くとも半端には望めません。

問題も多くありました。具体的には以下のようなものです。

  • 教育目的での選考経験の欠如
  • （コンセプトはある程度固まっているものの）具体的どうゼミを実施するかまでは見えていない
  • 枠がかなり限られているため、どんな視点で選ぶかによってゼミの姿もまだ大きく変わりうる

そこで秘密兵器を導入しました。Cコンパイラゼミ講師の id:hsjoihs です。

あまりにも雑に hsjoihs を呼び出す図

id:hsjoihs は「人に何かを伝える」ということに関しては最も信頼のおける友人のひとりです。 その上Cコンパイラゼミ講師を歴任しており、セキュリティ・キャンプの事情もかなり把握しています。なんなら今年も講師なので、守秘義務的な意味でも内部事情や実際提出された応募課題の議論をすることすら可能です。 そのため、最も適任な相談相手だったのです（まあ、彼も選考に追われているはずではあったのですが）。 *8

というわけで、id:hsjoihs に背景情報やゼミ・選考課題の意図をあの手この手で伝え、壁打ち相手になってもらいながらゼミの具体的なコンセプトを（再度）固めていきました。*9

最も重要だったのは、僕が各所で言いまくっている／書いている「複雑なシステム（や目的）」とはなんなのか、ということです。 ゼミ概要にはこんなことを書いていました。

宇宙機は非常に複雑なシステムです．なぜ非常に複雑なのかと言えば，考えなければならないことが多いからです．まず，宇宙にコンセントはありません．そのため，自分で発電能力を持つ必要があります．多くは発電手段として太陽電池を用いますが，そこまでパワーのある発電手段ではなく，使える電力にかなりの制限がかかります．太陽電池があったら発電自体は安泰というわけでもなく，適切に太陽の方向を向くために制御しないといけません．制御しやすいような機構も考えた方がいいかもしれません．そもそも制御するためには自分が向いている方向や太陽の方向をどうにかして得ないといけません．ずっと太陽の方向を向いていても，放熱ができず部品の温度が数百度になって不可逆的に破壊されてしまうかもしれません．

先述のように非常に複雑なシステムは，一人で作ることはほぼ不可能です．機械的な構造，熱や電力の収支，姿勢決定/制御，コンピュータ・ボード，そしてソフトウェアなどすべてを設計し，開発する必要があります．特に宇宙機はデプロイ環境やワークロードが特殊だということもあり，それぞれの設計に特有の難しさがあり，プロフェッショナルが必要になります．それだけでなく，太陽電池の例からも分かるように，それぞれ別々の専門領域を持った人間同士が適宜連携し，調整しながら開発を行う必要があります．

我々はこの"複雑"とは、「分割統治法を素朴に回せるほど甘っちょろくない」ということだと再定義しました。

分割統治法は最もプリミティブで強力な問題解決のパラダイムです。 どんなにスケールの大きな話でも、それを構成する個々の要素に分割して小問題を倒していけば、きっと元の大きな問題も倒せるはずです。きっと。 しかし、"複雑"な問題では、（素朴に）分割した各要素は実はあまり分割できておらず、密結合になってしまっています。 こうなると、例えば小問題ごとに担当者を割り当てて独立に取り組んでもらい、解決した小問題をいざマージしようとした途端、大量のコンフリクトが発生したり、大量の手戻りが発生したり、もはや何のために何をやっていたのかすらよくわからなくなってしまったり、といった事態が発生してしまいます。 そして、そんな事態を事前に予測・対処することは非常に困難です。 特に似たような前例がないような問題であれば、実際にはどんな部分が密結合なのか、ということすらほとんど unknown-unknown でしょう。 だからこそ、一見妥当だと思った分割統治が機能しなくなってしまうのです。

そんな"複雑"な問題に対して使える手札のひとつに、たとえば、いきなり本丸の問題に切り込むのではなくまずは PoC をやる、というものがあります。 PoC を実際にやってみることによって得られる最大の効果は、unknown-unknown をある程度 known な領域に落とすことができるということです。

そして、その unknown-unknown だったモノは、最悪の場合大本の目的そのものや計画を揺るがしてしまうようなモノかもしれません。 しかし、早い段階にそれが分かれば、単に学びが得られるだけでなく、大本の目的や計画に対してすらフィードバックがかけられます。 むしろ、そのまま突き進んでしまうと、暗黙の前提が意外と成立せずに最終的に巨大な無が産まれてしまった、ということにもなりかねません*10。 "複雑"な問題は、"複雑"であるが故に、その問題そのもの（前提）も疑ってみるべきことも案外多いのです。

そんなことを考えながら、ホワイトボードに書き殴ってできたのがこんな図です。

本質.png

先ほどの"PoC をやる"であったり、その PoC の賞味期限が切れないように細かく iteration を回すような、"複雑"さに立ち向かうための具体的な手段のことを"手札"と呼ぶことにしましょう（図では青く書いています）。 "手札"は取り組み方の方針だけではなく、具体的な技術なども含まれます。例えば実機を使ったE2Eテストを行うしかなかったことによって発生していた開発の複雑性は、シミュレータを作って上のレイヤはソフトウェア上ないし単体でのユニットテストを可能にすることによって構造的に解消可能かもしれません。

そして忘れてはいけないのは、具体的な"手札"だけでなく、具体的な"手札"を次々に繰り出していくため、なんなら次々に産み出していくためのメタ的な手札、"メタ手札" の存在です。 前述の「前提を疑う」というのも"メタ手札"のひとつでしょう。

"複雑"な問題は多くの場合複数人、つまり組織で立ち向かうことになるわけですが、その組織構造は成果物に非常に強い影響を及ぼします（コンウェイの法則）。 そのため、組織構造をより効率的な形に変えられるようなインターフェース設計や技術開発なども強力な"手札"として存在します。 そんな組織というファクターも"メタ手札"のひとつと言えるでしょう。

さらに、シミュレータによるソフトウェア上でのテストの実現のような、レイヤを横断した"手札"は、（下にも上にも）幅広いレイヤとその責務に対する深い理解という"メタ手札"が無ければ思い付くことはできないでしょう。 もちろん、"複雑"だからといって関わるレイヤが幅広くなるわけでは必ずしもないのですが、直接的な対象となっているレイヤに閉じない深い理解があればできることがものすごく広がる、というのはよくある話でしょう。

この図ができたことで、選考それだけでなく、探査機自作ゼミのその後の方針が定まったと言っても過言ではありません。

これはつまり、

このゼミでは惑星探査機の開発を題材として，複雑なシステム開発への向き合い方を，実際に手を動かしながら考えます．

というのは、

  • 分割統治法を素朴に回せない"複雑"さを実感しながら
  • 実際に様々な手札を繰り出しながら取り組み
  • 単なる手札だけではなく"メタ手札"にまで手を伸ばしてほしい

ということになったわけです。

選考

さて、（実際応募してくれた人などには気になるところであろう）選考そのものの話をサボっていますね。しますか。

選考課題も結構頑張って考えたので、興味があったら見てもらえるとうれしいです。

https://sksat.net/misc/seccamp2024-entry.html

特に気を使ったのは最初の注意事項です。

この応募課題は，あなたに考えてもらい，講師があなたのことを知るためのものです．

明確な答えの無い設問となっているため，分からないと思っても，何をどう調べ，どう考えたかを途中まででもぜひ書いてみてください．

  • 評価は加点方式で行います．
    • あなたが考えた道筋やあなたの熱意を重視します．
    • 不正確なことを書いても減点するようなことはしません．
  • 文字数の制限はありません．
    • 回答の長さによって評価が有利になることはありません．
  • 一部の設問には発展課題を付けています．
    • 発展課題の回答はあくまで任意です．無理に回答するよりは，それ以外の回答を丁寧に考えて書いてもらうことに価値があります．
    • 発展課題の回答は元の課題と混ぜて書いても分けて書いても構いません．
  • 回答を考えるにあたって，Web で情報収集をしたり，ChatGPT のような LLM を用いても構いません．
    • 適宜出典や引用元は明記してください．
    • LLM などへの入力（プロンプト）を回答に含めても，含めなくても構いません．
  • 回答に擬似コードやソースコードを含めても構いません．
    • 実装のポイントや意図が分かるコメントがあると助かります．

LLM の使用については賛否あると思いますが、どうせ禁止と書いたところであまり効力は無いですし、もはや日常的に使っている人も多くいる現状では、どの程度からが使ったと呼べるのかもかなり微妙なところです。 調べるきっかけに使ったり、文章の清書に使ったりしてくれるのであればこちらとしても大歓迎ですし。

実際の選考は、以下のようなフローで行いました。

  1. ゼミ概要と応募課題を印刷する
  2. 応募回答を全部印刷して応募者ごとにホチキスでまとめて床に広げる
  3. 回答の型を取れて回答できているかを中心に大雑把な評価ごとのグループに分類
  4. ゼミ概要・課題文の行間や意図を汲んだ回答を加点しつつ分類を修正
  5. 応募者特有の評価できる点をメモしつつ分類を修正
  6. 適宜ゼミ概要や課題文を読み返しつつ3～5に戻って繰り返す
  7. ぜひ来てほしい評価のグループ内で、どの3人を組み合わせるのが最も効果的かという観点で見返したり5に戻る
  8. 断腸の思いで心を決める

なんというか、家にレーザープリンターとデカいホワイトボードがあると便利ですね。

「回答の型を取れて回答できているか」というのは、課題文中で（字義通り）期待している回答の"型"を満たす文章になっているか、という意味です。 セキュリティ・キャンプのようなものに限らない文章題あるあるではありますが、やはり意外と取れていない時は取れていないです。 「Aとは何か」と聞かれているのに、「Aの背景は～」のような微妙に違う型の回答になってしまっているやつですね。 「論じてください」という型は結論だけでは満たせない、とか。

また、"型"という表現を用いると、注意書きにはベースクラスがある、というような言い方もできると思います。

一方で、加点方式であり、「あなたが考えた道筋やあなたの熱意を重視します」と書いたこともあり、この"型"のチェックはそこまで厳密にはやりすぎないようにも気を配りました。 文章にまとめる能力の高さはあるに越したことはないのですが、そこを特に見たいわけではなかったためです。

ちなみに、"型"や意図といったところでいうと、勘違いしてほしくないので明示的に言及しておきたいことがひとつあります。 それはやったことや使ったことのある技術スタックの単なる一覧のようなものは特に良いとも悪いとも評価できないということです。

ゼミ概要にも

C言語の基礎的な文法は一通り分かり，なにかしらのプログラムを書いて動かしたことがあるのが望ましいです（ただし，未経験でも応募後や事前学習期間中に自走できる熱意がある場合は応募をためらわないでください）

と書きましたが、どんな技術を使ったことがあるかやどんな技術レベルであるかは応募時にはあまり重要ではありません。 2次選考でもあればそこで深掘りするきっかけにこそなりますが、書類選考のみでしたし。

もちろん、実績を求めている、ということも当然無いです。書いてないですからね。

以前こんなことも書きましたね。

まあ、選考後に具体的にどのように取り組んでもらうか講師が考える材料にはなるので、迷惑というわけではないのですけどね。

そして、「ゼミ概要・課題文の行間や意図」を汲めているか、という部分は、かなり評価を分けた部分でした。 例を出さずに書くのは厳しいので端的に言うと、ゼミ概要と課題文や、課題の前半と後半は繋がっている、というやつです。

最後に、3人という非情に限られた枠に入れ込むための組み合わせ問題を解くのは非常に胃の痛くなる作業でした。 なんだかんだ偉そうなことを書きましたが、6～8人くらいは「枠があったら来てほしい」という判定をしていたので、この最終段階は本当に悩ましかったです。 目を皿のようにして何度も読み返しました。そこで先ほど再考したコンセプトが役に立った、というかんじです。

裏側はこんなかんじでしたが、新設の何をやるんだか怪しそうなゼミにも関わらず応募してくれた皆さん、本当にありがとうございました。 月並みですが、本当に色々な回答があって楽しく読ませてもらいましたし、第一希望の応募が多かったのもとても励みになりました。

事前学習

どうにか選考を終えると、またしても慌しいことに事前学習期間が始まりました。

新しいゼミであること、そして何よりハードウェアを取り扱ったり、やることが多いゼミという意味で、この事前学習の設計と実装（？）が最も大変だったと言っても過言ではありません。

ちなみに、事前学習をどの程度の期間設けられるかは、受講生のみなさんがセキュリティ・キャンプ運営の用意した Discord サーバにどれくらい早く参加してくれるかにかかっていました。これは今年は（去年の講師などから話を聞いた様子だと）かなりスムーズで、非常に助かりました。

実際の事前学習はこの Discord サーバを使い、週に一度同期的なミーティングの場をボイスチャットで設け、それ以外にもテキストチャットや GitHub の Issue での非同期コミュニケーションを適宜活用する形で実施しました。

雑にテキストコミュニケーションをする

まず最初に案内したのは、雑にコミュニケーションをするということです。

bash0c7.hatenablog.com

こういう教育イベントのチャット欄というものはどうしても「講師」から「受講生」への一方的な連絡の場としてのみ使われてしまう圧がかかりがちなので、この圧を明示的に排除する必要がありました。 ここでいう圧というのは、そのようにする必要があるように上からお達しがある、というようなことでは一切ありません。

しかし、それでも「講師」と「受講生」という構造的な権力勾配が（実態はともかく、見た目として）存在するのは厳然たる事実です。 このような構造的な問題はどちらの立場であっても見過ごしがち／ナアナアにしがちなので、一般論としても常日頃から意識して積極的に改善していきたいところですね。

ゴタゴタ書きましたが、実際やったこととしては↓のような便利な話の共有であったり、（全体の雑談チャンネルだけでなく）ゼミ専用のチャンネルで雑談を積極的にしたり*11、開発リポジトリの通知を webhook で全部流したり、といった程度のことです。

非情に曖昧なリポジトリを作りみなさんの通知を汚す様子

裏目的のひとつとして、期間中で最も騒がしいチャンネルになることを目指してもいました。これはそこそこ達成できた気がします。*12

また、テキストコミュニケーションを有効活用しよう、という案内もしました。 これは、事前学習期間中のエフォートは受講生ごとに量も時間も異なるので、毎週の同期的なミーティングが事実上一人一人との個別具体的な長々とした相談の場になってしまったり、ミーティングの頻度に事前学習（というか開発）が律速されてしまうと非常にもったいないためです。事前学習期間は意外とあっと言う間に過ぎ去りますからね。

オリエンテーション

そうして始まった事前学習ですが、最も気を遣ったのはやはり初回や最初の数回です。

このゼミは各所で強調しているように、チーム戦です。 そのため、初めのオリエンテーションが非常に重要です。 ここで一緒にものづくりをやるという空気間の醸成や、受講生同士でのアイスブレイクに失敗してしまったり、時間がかかりすぎてしまうと、無のゼミになってしまう可能性があるわけです。

まあ、とはいっても正直こちらからできることはあまり多くありません。 せいぜい、最初の自己紹介のテンプレートを用意しておいたり、初めの何回かはアバターの姿で登場したり、Discord の探査機自作ゼミにのチャンネルでめちゃめちゃ雑談をしたり*13、といったぐらいのものです。

講師自己紹介すら曖昧なアバター姿

最初は傍から見ていてすごくハラハラしていましたが、後述するように比較的早めに共同作業する機会を設けることができたこともあり、少しずつみなさんが打ち解けていくことができて本当によかったです。

座学的なところ

結局のところチームビルディングが最重要なのだ、みたいなことを書きましたが、しかしそれはそれとして、ある程度は座学的なこともやる必要がありました。 雑に３人だけで集まってこのゼミができるなら僕要らないですからね。

そして何より、今回の受講生は３人とも、組み込みはほぼ触ったことがなく、全員 Rust は初めて、チーム開発は人によっては少しやったことはあるけれど、決して慣れてはいない、というような状態でした。 そこから数ヶ月と３日で組み込み Rust で探査機をチーム開発させようというのだから、無理があろうというものです。 腕が鳴りますね。

さて、そんな状態で「講師」として、いや、正確には「経験者」として、何かを教えようと思うと、果たして何を教えるべきでしょうか。

Rust の文法でしょうか？ したり顔でする衛星開発で大変だったところ昔話でしょうか？ 「組み込みって大変なんだよ」という老人のうんちくでしょうか？

そうではなさそうです。

そこで、僕が（結果的に／優先的に）選んだのは以下のようなことでした - 設計という行為のため心構えと手法の一部 - 組み込み開発のハンズオンと基本的な世界観の解説 - テンプレートとなるコードの提供と便利なツール群の紹介 - ドキュメントの辿り方（docs.rs やデータシート）

docs.rs

事前学習期間中は、こういったことを毎週何をやるべきかを考えては投げつけてみる、ということをしていました。 一応の計画は立ててはいたものの、結局毎週みなさんの感触を見ては次の週やることをまた悩み直していました*14。 それもあって、講義資料としてはあまり厚みが無くなってしまったのは、後で振り返りをしてもらう時などに不便だったかなと反省しています。

シミュレータを使った事前学習

さて、そんな事前学習ですが、ひとつ重大な問題がありました。 それは、ハードウェアをみなさんの家に届けるのには時間がかかる、ということです。

特に僕の場合は部品の一部を事務局に用意してもらった上で一部を自分で用意（自作基板など）してマージしてから事務局に送り返す、というような手順を踏んでいたこともあり、だいぶ時間がかかってしまいました。 これは大きな反省点のひとつです。

それはそれとして、いくら反省したところで、すぐに届かないものは届きません。 しかし、だからといってずっと座学的なことばかりやっていても、面白味に欠けますし実感が湧きません。そしてなによりモノが届いた後のギャップが大きすぎます。

そこで目を付けたのが、wokwi というシミュレータでした。 これはオンラインおよび VSCode 拡張で使えるマイコンのシミュレータです。

wokwi.com

これはパッと見では ESP32 系のマイコン専用なのかと思っていましたが、今回使用した Raspberry Pi Pico の模擬も可能だったため、うまく使うことができました。

無料枠でも何個か回路を組んで permalink を生成することができるため、演習問題を作って渡しておき、次の回で様子を見る、といったこともできました。

VSCode 拡張版を使えば、受講生のみなさんに VSCode Live Share で相互接続してもらうことで、モブプロを体験してもらう、ということも行えました。

さらにこの wokwi がよかったのは、Raspberry Pi Pico の模擬に使用されている rp2040.js というライブラリが、雑な Arduino レイヤの模擬ではなく、そこそこちゃんと CPU レベルで模擬を実装している上、実際に RP2040 に書き込む際に使う .uf2 ファイルを入力に与えることができる、という点でした。

github.com

これによって、VSCode 拡張版の wokwi シミュレータ上の Raspberry Pi Pico に対して、Rust からビルドした .uf2 ファイルを書き込んで動かすテンプレートを作ることができ、実機が届く前に Embedded Rust の開発環境をセットアップし様子を見せることが可能になりました。

github.com

セキュリティ・キャンプ -14日目

どうにかハードウェア一式が届いたあと、受講生のみなさんには「タミヤのキットは組み立てに時間かかるから事前にやっておいてね」というお願いをしていました。 すると、受講生の方から、集まって作業したい、という要望がありました。 なんというかややグレーな気もしつつ、今回は受講生全員が関東在住であったこともあり、せっかくなので集まってこの組み立てを行うことにしました。 さらにせっかくなのでと作業場所として弊社のオフィスを提供し、色々なモノを見せつつ交流するよい機会を設けることができました。

弊社オフィスで実機を組み立てる受講生のみなさん

（これはとてもよかったなと思うものの、受講生の居住地という運に左右されるので、もしまた似たようなことをやることがあれば難しいよなあ、とも思っています）

当日

いよいよ待ちに待ったキャンプ当日です。 僕はつくばの自宅から、@_Alignof と共に異常な量の荷物をスーツケースとコンテナに詰め込んで会場に向かいました。

あまりにも大量の荷物を持ち込んでいたので、キャンプ期間中は"マキシマリスト"を自称していました。 ああ、もちろんコンテナを動かす*15ための台車も持っていきましたよ*16。

08/12（１日目）

キャンプはパッと見１週間ありますが、１日目は共通講義やグループワークなど、「開発コース」以外の時間がほとんどです。

夕食後に交流会や LT 会に参加していたらあっという間に１日目が終わ......ると思うじゃないですか。 僕も思っていました。でもどうやら３０分だけ「ホームルーム」なる「開発コース」の時間があるらしいです。なんだこれは。

これを発見した僕は、みなさんがグループワークに勤しんでいる間に『当日資料』をでっちあげました。

そして、初日の最後の最後の３０分で受講生の皆さんを集めて煽発破をかける暴挙に出たのです。 冷静になると初日から夜の最後の最後で一人だけ急に早口でなんか言ってくる講師、怖すぎますね。ごめんなさい。

まずはじめに伝えたのは、ゴールを決めること、そして、そのために必要なタスクを DAG に分解し、やることとやらないことを決めなければならない、ということです。

「開発コース」内で最大のホワイトボードの領域を手に入れることができたこともあり、ホワイトボードに色々書き込んでいきながら議論しよう、という話もしました。

あ、ちなみにホワイトボードマーカーとイレーザーは私物を持ち込んでいました。これがマキシマリストですよ。

ボードマスター以外は認めない

そんなことをやっていたら、初日から時間外に自然とホワイトボード前に集まる受講生の様子が観測されるなどしていました。熱量がすごい*17。 ここで最初のゴールが決定され、そこからブレークダウンされた各開発要素のうち、他の人とやることが被らないようにタスクの分担が発生していました。完璧すぎる*18。

初日夜から自主的に廊下のホワイトボード前で議論が発生していた

というわけで、探査機自作ゼミは無事（？）、初日からフルスピードで開始できたのでした。

08/13（２日目）

１日目で完全にエンジンが暖まっていたので、２日目は議論の続きから始まり、あとはひたすら開発というかんじでした。

ここまで来たらもう僕の仕事はほとんど無いと言っても過言ではありません（オイ）。 あとはたまに質問を受けて答えてくれる便利な機械になったり、詰まっていそうだったらたまにつつくぐらいのものです。

そんな調子でやっていると、14時頃には以下のようなことが分担して行われていました。

  • PWM によるモータの速度調整
  • 左右のモータを使い分けて機体の回転動作を実現
  • ９軸センサの初期化／値をシリアル経由でログ保存して特性確認
  • 超音波センサの値をシリアル経由でログ保存して特性確認

１日目の早口が功を奏したのもあり、質問に答えるのもどんどんラクになっていました。最高すぎる。

夕方には以下のようなことへの挑戦が行われていました（もちろんパラで）

  • 超音波センサの値を使った制御
  • SD カードへのセンサデータ保存
  • モータからの９軸センサのノイズの影響測定

この日の夜には、お互いの状況を共有しつつ次に向けてのかなり具体的な議論が行われていました。

現状整理と次のタスクの議論やインターフェース設計が行われている様子
機体の制御を９軸センサのデータを使って滑らかに行えるようにしたいが、滑らかな機体制御と９軸センサのデータを制御側から扱いやすくするためのラッパーは別の受講生が実装しているため、お互いの仕事をパラのまま進めるためにデータのインターフェースをどうするかといったことや、現状までの開発状況を踏まえたゴール設定の調整などが議論されていたようです。

08/14（３日目）

全員（講師含む）遅刻して別の講師に無人のゼミの様子を撮られました（無念）。

起床失敗ゼミ

カスの様子

2日目の朝は多少議論から実装に入る形だったのですが、この日は完全に最初からパラで開発が行われていました。

なので、あとはスポットで Rust を教える人になったり、

docs.rs と rust-analyzer 見ろ教を布教して回ったり、

みんなで Rust 最高じゃんという顔付きになったり、

スリッパを壊したりしていました。

午後には、Rust の強い型システムを使って単位系のミスを防ぐ仕組みが作られてうまく動いていたのも、うまく Rust という道具を活用してもらえつつあってとてもよかったですね。

ちなみに、僕が質問に答える時は、できるだけ背景となるコンピュータの様々な事情を散りばめて説明するようにしていました。 trait の説明をする時ですらまずはホワイトボードにメモリ空間を書いたほどです。

この日の午後には、以下のような状況になっていました

  • 9軸センサの値を使って正確に360度回転するロジックを考え、実機に実装中
  • microSD カードへのデータの読み書きができた
  • 9軸センサや制御のための状態管理を行うラッパーを実装
    • 単位系のミスを型レベルで防ぐ仕組みを実装
  • 無線モジュールを触り始める

夜にはセンサデータの microSD カードへの記録が成功したり、無線機のテストが行われていました。

08/15（４日目）

この日は朝から GitHub がユニコーン吐いてて本当に終わったと思いましたね。 受講生間でのコード共有は完全に GitHub に依存していたので。

そしてもちろんこの日も元気に chatsksat として活動していました。

デバッガを繋いでいる時だけ再現しなくなるハイゼンバグが発生していたのはアツかったですね。 これでこそ低レイヤ、これでこそ組み込みという部分も体感してもらえたのではないでしょうか。

ja.wikipedia.org

そして、朝の早い時点で以下ができていました。

  • 無線モジュールの単体でのテスト動作
  • 超音波センサでサンプルを検知し、サンプル付近に向かって移動する制御
  • サンプル回収用のアームを複数パターン製作開始

この頃にはソースコードのマージ作業も順次行われていたわけですが、ハードウェアのマージやそのための調整も行われていました。

しかし、実は４日目は「開発コース」としての作業可能日としては最終日。 お昼頃にはだいぶ焦りが見えてきます。

ちなみに、ここまでの書き方だとものすごく順調に開発が進んでいるように見えますが、もちろんそんなことはなく、様々な部分で行き詰まりが発生したり、それによって計画やゴールを修正したり、といったこともかなり発生しています。 そして、何かに行き詰まることそのものも非常に体感してほしい部分であるため、理不尽でない行き詰まり（元の設計や分業判断、完全な unknown-unknown によるもの）については、僕は自分からは助け舟を出しませんでした。 相談には乗りますが、「答え」を授ける係ではないですからね。

そればかりか、僕はむしろみなさんの気を散らす方向にこそ動いていました。 例えば、「より大変かもしれないけれど十分に魅力的な提案をする」といった手段によってです。*19

さらに、マキシマリスト装備パワーを使って、「＊＊が無いから＊＊はできないなあ」という言い訳を封じる活動も行っていました。

そして午後になって、各々が各々の担当領域で行き詰まっていきます。 焦りがミスを産み、ミスが焦りを産みます。

───ようこそ、締め切り直前デスマーチの世界へ────

と思っていたら行き詰まりのひとつの原因は僕が作った基板のエラッタだったのでマジ謝罪が発生したりもしました。*20 いやこれはホント申し訳ありませんでした............

そんなこんなで、最後に予定していた「打ち上げ」は時間通りに行うことができませんでした。

その後も成果報告資料の提出期限などがあり、実際の「探査」は行えずに時間が終わってしまいました。 これは実装状況の問題もありつつ、ペース配分の調整をもう少しすべきだったという側面もかなりあり、結構大きな反省点のひとつです。

その後、みなさんの努力により、理想的な条件であれば、サンプルを探索し、接近したのちアームでサンプルを確保する、という一連の動作が行える状態になっていました。 執念が本当に素晴らしかったです。

最終日夜の実装状況

08/16（最終日）

ガチ寝坊しました。マジで申し訳ない。 自分のゼミの成果報告は聞けたのでギリギリ致命傷で済みました。 緊張の糸が解けましたね。

成果報告が終わった後は、受講生のみなさんは協賛企業イベントのためもう１泊、講師陣は解散......という予定でした。*21 が、しかし、我々がクロスウェーブ府中に１週間幽閉されている間、外界では台風がヤバいことになっていました。 そのため、協賛企業イベントは中止になり、急遽即席のイベントが開催されることになり、さらに講師陣の延泊も可能になりました。

セキュリティ・キャンプ・エクストラステージの開幕です。

08/17（シン・最終日）

帰宅し、爆睡しました。みなさんが秋月に集まっていたらしいという噂もあったんですが、先に帰ってしまったし、体力が完全に完売していましたね。

さいごに

まず、すごく素朴な感想として、半年近くにわたって非常に疲れましたし、時間も取られました。が、その価値はあったのかなとも強く思っています。 個人的にそう確信できるキャンプにできたことは本当によかったです。

一方で、僕は人にモノを教えるという経験があまりなかったこともあり、受講生のみなさんやキャンプ関係者のみなさんに対して色々と至らないところがあったかなとも思っています。 皆さん色々と配慮していただきありがとうございました。

ゼミをやった感想、という意味では、この記事に色々と書けたかなと思います。 全体を通した感想としては、ゼミ自体の企画から実装・運用までの一連の流れをほぼ一人でやり切ることができたこと、そして人に考え方を本気で伝えるためにひたすら考え続ける機会が得られたことはかなり強力な経験になったと思います。

「探査機自作ゼミ」に参加してくれたみなさんへ。本当に、本当にお疲れ様でした（これ書くの遅すぎて今更すぎるけど！！！）。 このゼミを面白いと思ってくれたり、何かを持ち帰ってくれていたら、とてもうれしいです。

受講生のみなさんのブログ記事も貼っておくのでよかったら見てみてください（講師と違ってすぐ書いていて、えらすぎる）。

zenn.dev

onogono.hatenablog.com

zenn.dev

さいごに、探査機自作ゼミがうまく行ったのは以下のみなさんのおかげです。重ねて感謝します（敬称略）。

  • 探査機自作ゼミに応募していただいたみなさん
  • 探査機自作ゼミに参加していただいたみなさん
  • セキュリティ・キャンプ関係者のみなさん
  • 僕に講師をやってみないかともちかけてくれた id:hikalium
  • 色々と相談に乗ってくれ、当日つくばから車を出してくれた _@Alignof
  • いきなり呼びつけて相談に乗ってくれた id:hsjoihs
  • いきなり 基板設計・KiCad を教えてくれと頼んで快く引き受けてくれた某氏
  • ゼミ概要・応募課題のレビューをしてくれた id:hrstmyk811m

*1:講師依頼を受けてからちょうど１週間くらい

*2:もちろんこれは言うが易しなのでちゃんとやるのは結構大変ですし、何よりセキュキャンの受講生として主に想定できるのはハードウェアはあまりやったことがない人なので、組み込みソフトウェア開発への入門だけでも十分大変ではあります。

*3:実際無かった

*4:アレはアレで結構いい経験ではあるんですがね

*5:そこまでやるならオフラインでの作業機会込みで半年～１年欲しい

*6:めちゃめちゃ正直な話をすると、最初はこういう名目でお誘い頂いたので、かなり巨大な裏切りをしているかもしれない

*7:フルタイムで働いている状態で１週間より少し短い程度、というのはまあ厳しかったです。時期的に衛星の出荷準備とかもありましたしね（まあこれはキャンプ準備一般そうだったのですが）。

*8:Cコンパイラゼミの選考も少し手伝ったし、本を紹介したりしたので許してほしい（？）

*9:この会は選考も含めて土曜の昼から日曜の朝まで続きました。@hsjoihs 本当にありがとう。

*10:スタートアップにおける pivot のようなもの、とでもいうといいかもしれません

*11:ちょうど初回数日前に Starship が飛んだりして便利でした

*12:ただ、Discord だと全チャンネルが全員に良くも悪くも最初から見えているので、他のゼミの人の通知を破壊しかねないという意味では難しいな、とも思っています。Slack だとチャンネルの存在を認知した上で参加しない、ということが最初からできるので棲み分けしやすいんですけどね。

*13:Starship fourth flight test がいいタイミングで上がってくれて便利でした

*14:正直これは結構大変でした。仕事からのコンテキストスイッチのコストも踏まえて、途中からは金曜日を次の日何をやるか考え教材を準備する時間とするようにしていました。

*15:docker run ではない

*16:でも１個ではなく２個持っていくべきでしたね。ちょくちょく NOC の台車を借りる謎の人になっていました。ありがとう NOC（？）。

*17:やれって言ったわけじゃないです本当なんですでもよかったですねとても（開き直り）

*18:もちろん多少のアドバイスはしたんですが、タスクをどう分割するかやアサインについては完全にノータッチです

*19:さらに質の悪いことに、これは本当に大変なやつと、やってみると実はすごく簡単だけどやってみないとその大変さの判断が付かないものをそれぞれ出していました。損切り能力が試されますね。

*20:しかもまさかの TX, RX ミス

*21:ちなみに、これそもそも把握してなくて受講生向けのカレンダ見て予定決めてたので台風来なかったら宿無しマキシマリストという最悪な状態になるところでした。予定はちゃんと確認しましょう！