以下の文章は Markdown として記述しています。  
視認性が悪い場合は https://sksat.net/misc/seccamp2025-entry.html を見てください。同一ソースのレンダリング結果を掲載します。

# はじめに／評価について

この応募課題は、あなたに考えてもらい、講師があなたのことを知るためのものです。明確な答えのない設問となっているため、分からないと思っても、何をどう調べ、どう考えたかを途中まででもぜひ書いてみてください。

* 評価は加点方式で行います  
  * あなたが考えた道筋やあなたの熱意を重視します  
  * 不正確なことを書いても減点するようなことはありません  
  * すべての回答が満足いくほど書けていなくても、とりあえず提出してみてほしいです  
* 文字数の制限はありません  
  * ただし、回答の長さによって評価を行うようなことはしません  
  * 短い回答は必要十分に簡潔であれば伝わりやすい一方で情報が不足するリスクが大きく、長い回答は情報量を増やしやすい分冗長にもなりやすいというトレードオフの関係にあります  
* テキストのみで回答しにくい場合はファイルを添付してください  
  * 一部の設問では作図を要求しています  
    * 作図方法は問いません。なんらかの作図ツールを用いてもよいですし、紙やホワイトボードに描いたものの写真でもなんでも構いません。  
  * 添付ファイルの形式は問いません  
  * すべての回答を１つの PDF ファイルにまとめて提出する、といったことをしてもよいです  
    * この場合は、通常の課題回答欄に「添付ファイルで回答」といった文字列を入れておいてください  
    * 図をたくさん描いて文章で適宜参照していくような書き方をする場合、こちらの方がみなさんも書きやすいし講師も読みやすい、ということもあると思います  
* 一部の設問には発展課題を付けています  
  * 発展課題の回答は任意とします  
    * 無理に回答するよりは、それ以外の回答を丁寧に考えて書いてもらうことに価値があります  
    * しかし、（応募の後でも）ぜひ考えてもらえるとうれしいです  
  * 発展課題の回答は元の課題と混ぜて書いても構いません  
    * つまり、Q3 の回答中で Q3.1 や Q3.2 の回答を含めてよいです  
* 回答を考えるにあたり、Web で情報収集をしたり、ChatGPT のような LLM を活用して構いません  
  * 適宜出典や引用元は明記してください  
  * LLM への入力（プロンプト）を回答に含めても、含めなくても構いません  
* 回答に擬似コードやソースコードを含めても構いません  
  * 実装のポイントや意図が分かるコメントがあると助かります  
  * （疑似）コードはロジックやインターフェースを分かりやすく伝える強力な道具のひとつです（たとえそれがソフトウェアでなかったとしても）

# Q1

あなたが今までに作ったことのあるものを自由に語ってください。複数人で作った場合は、どの部分をどのように担当したのかを明示してください。それがソフトウェア、もしくはソフトウェアを含むものであれば、どのような言語・ライブラリを使ったかも教えてください。作ったものが公開リポジトリなどにある場合は、そのリンクも書いてもらえるとうれしいです。

# Q1.1（発展課題）

Q1 で作ったものを作る中であなたが感じた壁のうち、最もあなたにとって難しかったもの、もしくは、特に印象に残っているものを教えてください。あなたはその壁をどう調査し、克服しましたか？具体的に教えてください。壁が克服できなかった場合は、当時どうしたかに加えて、当時は何が不足していたと思われるか、今やり直すならどうするかなどの考えを聞かせてください。

# Q2

あなたの印象に残っている「これは便利だ」と感じたものを教えてください。工具でも、エディタやその拡張機能のようなソフトウェアでも、5回のクリックを1回にできるショートカットでも、なんでも構いません。

また、それはなぜ便利だったのでしょうか？つまり、どのような課題があり、どう解決しているのでしょうか？

# Q2.1（発展課題）

どのようにすれば、そのような便利なものを自分で開発できるでしょうか？考えてみましょう。

もし既に自分が作った便利なものがあれば、そのエピソードも教えてください．

# Q3

一般的な単色のボールペンを用意してください。ゼブラ JJ15 のような、シンプルかつ外装が透明で中の構造が確認しやすいものが望ましいです。

用意しましたか？それでは、このカチカチとペン先を出し入れする機構のことを考えながら、できるところまで分解してみましょう（元に戻せる自信が無ければ、他人のボールペンではやらないように注意！）。 

分解したら、各パーツをよく見て、この機構の仕組みを図を交えて解説してください。ペンは発明しているもののこのカチカチ機構はまだ存在していない世界の人にこのアイデアを伝えることを考えてみてください。

 追伸：ぜひ何度か組み上げたり分解したりしてみてほしいのですが、最後は元に戻すようにしてください。

# Q4

宇宙開発においては、「枯れた技術」と形容されるような、比較的古めの技術が使われることが多いです。特に情報技術においては一般的なIT業界と比較して10年、20年程度の開きがあることも珍しくありません。例えば、C89 や XML が幅を効かせていることはよくあり、PIC・SHマイコン、PowerPC、SPARC も現役で使われていることはしばしばあります。

これはなぜでしょうか？そして、この方針にはどのようなメリット・デメリットがあるでしょうか？ ソフトウェア以外とソフトウェアの両方の面について、それぞれ論じてください。

# Q4.1（発展課題）

ちなみに、講師の sksat はかなり新しいエコシステムである Rust を実際に仕事の衛星開発で使っており、講義でも Rust を使用する予定です。つまり、前述の「枯れた技術」に対して、少なくともソフトウェア開発の観点ではある種否定的な立場なわけです。これに意見があれば自由に述べてください。

ヒント：意見は賛成でも反対でも「それでは足りない」のようなものでも構いません。sksat と意見が異なっても減点するようなことはありません。意見がすれ違うのは当然のことです。ぜひ語り合いましょう！

# Q5

宇宙機はロケットという輸送手段で地上から宇宙に輸送され、軌道にデプロイされます。一度デプロイされた宇宙機は、原則として物理的に修理することができません。なぜなら、宇宙に出張に行って機体に近づいて蓋を開けることがほとんど不可能だからです。そこに行って蓋を開けられないということは、ノートPCを持っていってデバッガをアタッチし、ソフトウェアを書き換えることもできません。この性質は「非修理系」と呼ばれています。

これは非常に不便な特性です。打ち上げて運用を開始してからバグが見つかったらどうしましょう？そのバグは姿勢制御系の秘孔を突いて高速回転を発生させ、遠心力で機体が破壊されてしまうような致命的なものかもしれません。

また、バグでなくとも、途中から要求が変わるかもしれません。例えば気象目的の人工衛星で、特定の種類の雲を衛星上で認識するミッションがあるとします。これは問題なく動作していたのですが、運用開始後に別の種類の雲を衛星画像から判定するアルゴリズムが新たに開発されました。これを即座に軌道上の衛星に組み込めると非常に価値があります。

このような問題に対して、どのような技術的解決が考えられるでしょうか？また、どのように宇宙機やそのソフトウェア、送信するコマンド群などの運用計画を設計しておけば、運用時に後から発生する問題に対して対処しやすくなるでしょうか？自由に提案してみてください。

ヒント：漠然としていて考えにくい場合は、宇宙機を普通のLinuxサーバだと仮定してみるとよいでしょう。ただし、物理筐体を直接操作することはできず、通信機会が1回数分で1日に1回程度の不便なサーバです。インターネットにも繋がっていません。このような制限は適宜調べたり、想像してみたりしてください。

# Q6

このゼミで自作する探査機で探査してみたいものや、やってみたいことを自由に述べてください。  
実現可能性などはさておいて、ブレインストーミング的に自由にアイデアを書いてみてください。

余裕があれば、それを実現するための手立てをできるだけ具体的に考えてみてください。