5日でできる! セキュリティ・キャンプ応募課題執筆入門(兼 探査機自作ゼミ課題晒し)
こんにちは。標準偏差と申します。普段は特にセキュキャンの伝統があるわけではない学校で普通の中学生をやらせてもらっています。今回、セキュリティ・キャンプ全国大会2024の開発コース(探査機自作ゼミ)に参加してきたので、応募課題と執筆課程を晒し、過去の自分を上から目線で評価していこうと思います。
課題提出までの流れ
応募を決めた流れについては本筋と関係がないうえに後世に残す意味が薄い(この記事を読んでいる方々はすでに応募したい気持ちが多少なりともあるはず)ので省きますが、応募を決めたのは締切5/21に対して4/19となかなかに早めの時期でした。ということはそこから5日で書きあげて4月中に提出したのかというと、別にそんなことはありません。むしろ締切3秒前まで粘っていました。途中で煮詰まって、けっこうな時間ほったらかしにしていたからです。探査機自作ゼミの課題は問題文自体の理解は容易なものの、その分相当にパンチがあるものを書いて差を付けたいと思っていたため、風呂に入っているときに課題について考えるたり、宇宙関連の記事を読んだり、はやぶさを聞いたりしつつも、(良い内容が降ってくるのを待機し)三週間ほど基本放置していました。これは手札が揃ったな!あとは書くだけだ!と感じたあとは、賞味4日程度で素早く仕上げました
結果論にはなるのですが、この寝かし期間にかなり決定的な仮説を得たりしたので、「早めに着手し、しばらく心の隅に放置し、執筆作業自体は一気に終わらせる」という戦略は一定程度有効だと思われます。
考える時間を長くとることで盛り込める手札を増やしつつ、素早く書くことによってモチベの低下や文章の肥大を抑制できる、なかなかいいメソッドなんじゃないでしょうか。
なお、講師氏自身が過去にセキュキャンに参加した際の応募課題を晒していらっしゃったのでありがたく参考にさせていただきました。応募課題晒しの中で他人の過去の応募課題を間接的に晒すとはこれ如何に
当然ですがsksatさん本人の許可は取れています!!
本体(応募課題晒し)
今回解いた応募課題はこれ
はじめに・評価について: 応募課題ページより引用
この応募課題は，あなたに考えてもらい，講師があなたのことを知るためのものです．
明確な答えの無い設問となっているため，分からないと思っても，何をどう調べ，どう考えたかを途中まででもぜひ書いてみてください．
評価は加点方式で行います．
あなたが考えた道筋やあなたの熱意を重視します．
不正確なことを書いても減点するようなことはしません．
文字数の制限はありません．
回答の長さによって評価が有利になることはありません．
一部の設問には発展課題を付けています．
発展課題の回答はあくまで任意です．無理に回答するよりは，それ以外の回答を丁寧に考えて書いてもらうことに価値があります．
発展課題の回答は元の課題と混ぜて書いても分けて書いても構いません．
回答を考えるにあたって，Web で情報収集をしたり，ChatGPT のような LLM を用いても構いません．
適宜出典や引用元は明記してください．
LLM などへの入力（プロンプト）を回答に含めても，含めなくても構いません．
回答に擬似コードやソースコードを含めても構いません．
実装のポイントや意図が分かるコメントがあると助かります．
これは重要ですね。特に、不正確なことを書いても致命傷にならないこと、発展課題の回答が真に任意であるという情報が明示されているということはかなりありがたかったです。ちなみに今後の回答中に出典が少ないのは、あまりにも設問が特殊でWeb検索はあまり役に立たないし、専門書を買う金も読む時間もないと判断し、ほぼ自力で解いたためです。
Q1
Q. あなたが今までに作ったことのあるものを自由に語ってください。複数人で作った場合は、どの部分をどう担当したのかを明示してください。それがソフトウェアないしソフトウェアを含むものであれば，どのような言語・ライブラリを使ったかも教えてください．作ったものが公開リポジトリなどにある場合は，そのリンクも書いてもらえるとうれしいです．
A.
まず一番印象深い制作物は、半年ほど前(中学2年)にPython(Flask)で実装した簡易な掲示板です。
(https://github.com/KijitoraFinch/flask-simple-bbs)
辛うじて動いているようなもので、全くレベルの高いものではありません。コードを読みなおしてみましたが当時の自分の苦心が伺えます。しかし、中学一年生の半ばからプログラミングをはじめ、途中でしばらく脱線があった自分にとっては初の大きめな規模の開発だったため、忘れがたい、極めて強い印象があります。ここで初めて、「Webのよくみるあの機能ってこんな仕組みになってたのか...」と衝撃を受け、
同時に「すでにあるものでも自作は楽しい」「時間と自力で調べられる気力さえあればだいたいなんとかなる」という事実を身をもって実感した思い出深い経験です。
そのあとは、boid(鳥のような動きをシンプルな演算で再現するアルゴリズム)をPythonで実装してパラメーターをいじって遊んでみたり、jp2aという画像をアスキーアートに変換するプログラムのクローンを百行のGoで書いてみたりしていたのですが…
(https://x.com/HomeKijitora/status/1756586035075817550 https://x.com/HomeKijitora/status/1756567413343309898)
環境を吹き飛ばしてコードが消え去ってしまいました。
ただ、前者はシミュレーションの楽しさに、後者は画像や信号処理への興味を持ったきっかけになっているため印象が深いです。
ちなみにこの2つがきっかけで、今丁度オーディオビジュアライザを高速フーリエ変換から自作しているところです。
今FFTと可視化がなんとか動いて、標準入力から渡された数列からスペクトラムを作って表示まではできるようになっています。今はこれをオーディオビジュアライザとして動くようにしているところです。
(https://github.com/KijitoraFinch/audionim)
出ました。これはいわゆるイキリオタクゾーンです。ここでいかに †圧倒的実力† or †圧倒的独創性† をアピールするかが重要...なのですが、残念なことに私は大した技術力も面白プロジェクトも持っていませんでした。実績を盛りまくろうと思っても盛れるほど派手なものを作っていなかったんです。哀れ...
ということで、技術力をアピールすることをあきらめ、せめて技術力の方向性(≈興味を持っている方向)だけでも明確に見せよう、という方針にシフトしました。技術力で勝負しろよ
その結果が上のぬるま湯で割ったアイスアメリカーノのような舐めた内容の薄い文章なのですが、十分な技術力がある方々は強さもアピールした方が絶対に良いと思います。
講師のsksatさんの過去の応募課題晒し記事でも技術力のアピールの重要性が書かれています。盛る元手があるなら盛りたかった!!!
余談ですが、このオーディオビジュアライザを書き初めた当時は「これいい感じに完成させたらセキュキャンの応募課題で実績として語れるじゃん!」と甘いことを考えていたのですが、見てもらえば分かるように数学の難しさにボコボコにされており、なんとか遅いFFT(低速な高速フーリエ変換とは?)を実装するのが精一杯で、特に語れるほどの成果は生まれませんでした。
とはいえ、おぼろげながら信号処理の世界を覗くことはできてかなり楽しかったです。もう少しまともに数学をやったら雑に飛ばしてしまった理論を含めてしっかり理解したいです。
Q2
Q.
"Q1" で作ったものを作る前や作る最中，作った後にあなたが感じた壁のうち，特に印象に残っているものを教えてください．あなたはその壁をどう調査し，克服しようとしましたか？具体的に教えてください．壁が克服できなかった場合は，何が不足していたと思われるか，今やり直すならどうするかなどの考えを聞かせてください．
A.
先程の掲示板が完成して、部活の文化祭で展示するかと思いHerokuにデプロイしてみると、ログイン処理回りで不可解なエラーが出る現象に出くわしました。調べてみると、ログイン情報をハッシュ化した後の保存でなにかしらの不具合が起きていることまでは分かったのですが、手元では完全に動作していて、コードの変更もライブラリのバージョンも変えていないのにこれはおかしい、とかなり困惑しました。実際手元と違いがある点はネットワークやDBとの通信ぐらいしか思いつかず、一日ずっと詰まっていました。
もう普通に調べてもらちが明かないと考えた自分は、自分のコーディングの過程ではなく、コーディングの前提としているもの、すなわち依存している技術そのものや、それに対する認識そのものをデバッグすることに決め、「プログラムを書く際にミスをしている可能性がある」という普段のデバッグ時の前提ではなく、「(調査中も含めて常に)ミスをしている可能性があるし、誤った知識を元に推論をしている可能性がある」という前提で調査をしました。
結果、判った原因は「手元で使っていたSQLite3と、Herokuで使っていたPostgreSQLとで、データ型周りの仕様が違う」という初歩的な今であれば真っ先に疑うべきだと思うようなものだったことが発覚しました。当時の自分は、ORMを使っていればその先のレイヤーのことは考慮しなくていい、という考えを根本的に持っていたため、最後まで考えが至らなかったのです。プログラムを書き終わったあとのデバッグの過程でも致命的なミスや勘違いをすることはあるという当たり前の事実を痛感しました。
これは完全な蛇足なので読み飛ばしてもらっても結構ですが、自分はORMなどバックエンド間の差異を吸収するタイプのwrapperは、完全に差異を吸収するように努めて、もしそれが不可能となれば異常終了してくれるのが理想だと思っていますし、自分が実装するならそうしたいです。少しでも差がでる可能性があれば、ユーザーはそれを常に頭の片隅に置きつづけなければならず魅力が半減してしまうからです。仮にユーザーが想定できそうだとしても、疑わしきはエラーという原則で行きたいと考えています。
まあこれについては設問の問に正直に答えており特にコメントはありません。
ちなみに
プログラムを書き終わったあとのデバッグの過程でも致命的なミスや勘違いをすることはあるという当たり前の事実を痛感しました。
こんなことを書いておいて何ですが、キャンプ期間中に「まあドキュメントが事実と逆の嘘をついてることはないだろ(ついてた)」「さすがに引数の数がドキュメントと違うのはおかしい、余程古いバージョンを使用してしまったのでは？(ドキュメントが長年放置されていた)」「常識的に考えてI2Cアドレスの設定用のメソッドもプロパティーもnewするときの引数も存在しないなんてことはないだろ...(なかった)」 「デフォルト改行コードが\nじゃないイカれたシステムなんて存在するわけないだろ」 などと、ザルな仮定のもとに作業してハマることが結構ありました。
「推測しすぎるな、手札を駆使して計測しよう」「メタ手札が大事」などはキャンプ期間中に得た教訓です。(特にメタ手札などの用語は意味不明だと思いますが、今度参加記で詳しく書きます)
とはいえデータを取って考察するよりは既存の知識から決め打ちで推測する方が楽で、ついついやってしまいがちなので、今後もこれは気をつけたいところです。
あと、wrapperについての考えは今も変わっていません。差異の吸収による抽象化ができない、使用者が下のレイヤの細かい実装の差異を常に考慮しないと爆死するwrapperってヘルパー関数に毛が生えた程度のものでしかないじゃん!
Q3
Q.
あなたの印象に残っている「これは便利だ」と感じたものを教えてください．工具でも，エディタやその拡張機能のようなソフトウェアでも，5回のクリックを1回にするショートカットでも，なんでも構いません．また，それはなぜ便利だったのでしょうか．つまり，どのような課題があり，どう解決しているのでしょうか．
A.
Ankiというオープンソースの単語帳ソフトが本当に便利で大好きです。
https://apps.ankiweb.net/
使用者のフィードバックから最適な復習の時期を計算してくれるのが売りなのですが、他の似たようなアプリとは
- マルチプラットフォームで、取りまわしが良好なこと(ファイル一つで全ての情報をバックアップできる)
- 拡張性が高い
- アプリ自体はシンプル
- 技術に疎い人でも最大限に活用できる
という特徴により、一線を画す「便利さ」があります。私が英検準一級に受かった理由の7割くらいはこれです。
これらの一見相反する機能を同時に実現している方法は、ユーザーとアプリ側の責任範囲の分離の巧妙さ、そしてコミュニティの力を上手く活用するシステムです。
まず前提として、Ankiは学習する単語カードを最小単位として、それを集めたデッキを学習していくシステムになっています。そしてこのカードは極めて柔軟性が高く、完全なHTMLとJavaScript(!)をサポートします。
フロントエンドのフレームワークに対応づけると、デッキがアプリの、カードがコンポーネントのような役割を果たしているといったところでしょうか。
たとえば、ボタンをクリックすると英単語を画像検索して写真を表示してくれるカードを作ったりといった活用例があります。
(一般的にイメージされる単語カードについて話していますが、公式の用語に従うと今の説明における「カード」は「ノート」と呼ばれる別物です。)
このようにAnkiは、復習時期の算出は単体で高精度にこなしてくれる反面、カードの機能は全てユーザーに丸投げします。「学習効果の計測と評価はこっちでやるから、学習効果の工夫とかはそっちでやってね」という学習用アプリにしてはかなり思い切った設計で、これによって軽量かつ高機能でポータブルな学習体験を可能にしています。もちろん、これだけでは「便利」とは言えません。このようなユーザー主導型のソフトウェアは使うまでのセットアップが面倒で高難易度になりがちですし、コードや設定ファイルを書く必要のあるツールはプログラミング未経験者に勧められないという新たな問題が発生します。しかしAnkiはこれを上手い方法で緩和しており、それこそが「コミュニティの活用」です。仕様のかなりの部分がオープンソースであることにより、ユーザー同士の情報共有が活発で、プログラミング未経験者向けのテンプレートを作成して配布しているユーザーの方々も多くいます。そして、アプリ本体と比較的密に連携した(とはいえセルフホストも可能)デッキ配信サーバーを持っており、これによってデッキの配布を支援しています。
長くなってしまいましたのでまとめると、便利機能の組み込みはユーザー個人の裁量に任せて、それに伴って有効利用に技術力が要求される問題はコミュニティの力で解決するというアプローチで高機能かつシンプルかつ便利な体験を実現している、と考えています。
Ankiに命を救われたオタクによるガチ怪文書が出てきました。前半は「Ankiの素晴らしさを伝えよう!!」と思いながら書いたのですぐに書けたのですが、後半は結構苦労しました。
あと、この文章を読んだ方々は当然Ankiを使いたくなっていることと存じ上げますが、Ankiはここに書かれているようなカードのギミックがある上、スマート単語帳ソフトとしても普通に出来が良く、さらに企業にそこまで生殺与奪の権を握られていないので、まずは雑に使ってみることをオススメします。Ankiは遥かに良いです。ちなみにiOS版はApple税の影響か有料ですが、Android/Web/Desktop版は完全無料です。
Q3.1(発展)
Q.
どのようにすれば，そのような便利なものを自分で開発できるか考えてみましょう．もし既に自分が作った便利なものがあれば，そのエピソードも教えてください．
A.
Ankiの類いのアプローチは素晴しく便利なものを生みだしますが、これを実践するのはなかなか難しいことです。多くの人が欲しているものは基本的に競争が激しく、既に十分便利な解決策があることが多いです。よしんば少し便利なものを新たに出しても使用者は獲得しにくいです。これは商業ソフトウェアの場合は致命的で、大企業同士の戦いの最中に身を投じつつ利益を得るという超高難易度ゲームになります。他方オープンソースの土俵で勝負する場合、採算は度外視できるとはいえ、いまあるものより便利になる保証はありません。(多くの需要に応え多くのリソースがさかれているため)ただし成功した場合は莫大なコミュニティの力を得られるためどんどん改良され便利になっていけるでしょう。
では小規模ならいいのかというと、あまりにもマイナーすぎるものはコミュニティの力を借りることができません。全てを自分でやる必要がありますが、厄介なことに問題に直面している人の数と問題解決の難しさとの相関は弱く、そう簡単に便利なものを作れるわけではありません。それに、そこまでマイナーな問題だと、自分が気付く可能性も低いです。
つまり、Ankiアプローチで行くならばこの中間くらい: そこそこの人が必要としていて、そこそこに競合が少ない分野に(半強制的に)なるでしょう。正直この先は自分にもはっきりとは分からないのですが(分かれば直ぐに作っています)、既存のものがギリギリ見逃しているいわゆる画竜点睛的機能を実現するのが一番現実的なのではないでしょうか。たとえばAnkiでいうところのプログラム可能なカードなどです。
これは未だに正解が分かっていませんし、めちゃくちゃ知りたいです。
(分かっていれば今ごろ私はGithubでスター稼ぎまくりですよ!!!!)。
しかし応募課題の説明に「加点方式」「不正確なことを書いても減点はしない」とあったので、分かるところだけ書きました。まあ特に見るべきところもないですね。次。
Q4
Q.
宇宙開発においては，「枯れた技術」と形容されるような，比較的古めの技術が使われることが多いです．特に情報技術においては一般的なIT業界と比較して10年，20年程度の開きがあることも珍しくありません．例えば，C89 や XML が幅を効かせていることはよくあり，PIC や SHマイコン，PowerPC，SPARC も現役です．
これはなぜでしょうか？そして，この方針にはどのようなメリット・デメリットがあるでしょうか？ ソフトウェア以外とソフトウェアの両方の面について，それぞれ論じてください．
A.
まずハードとソフト共通に考えられる理由について述べ、その後固有の理由を述べます。最後にメリットについてそれぞれ考えます
理由
一般に、枯れた技術が使われる理由については「古くから使われていて知識が蓄積されているため」と言われていることが多いですし、それも理由の一つではあろうと思います。これについては良く言われる一般論なので省略します。今回注目したのは、宇宙開発の場合、技術の側が勝手に枯れていくという側面も無視できない程度に大きいのではないか、という点です。
つまり、
- (仮に開発初期には古くないスタンダードな技術を選定するようにしたとしても) 宇宙開発には相当な時間がかかることから、全体的に技術のトレンドの移り変りが遅めになる。
- 結果、現役で使われているものに古い技術が多く使われているという状況になる
- 古くてかつ一般で残っている技術は、枯れた技術と形容されていることが多いため、「宇宙開発では一般開発でいうところの枯れた技術をよく使っている」という結果となる
このような現象が起こっていることはかなり確からしいと考えられます。
もちろんこれは他の理由を否定するものではありません。しかし、一つの現象に対して数個の原因が強く関係しているということは現実世界では珍しくないでしょう。
ハードウェア特有の理由としては、
ハードウェアは制作にかかる時間がソフトウェア以上に長い上に予算も高くなりがちで、更に部品の互換性などの問題が多くありますが、これは宇宙開発という放射線防護や安全性、冗長性などが必要となる特殊な目的の場合より顕著になると考えられ、その結果既に普及したデファクトスタンダート的部品を使い回すことのメリットが大きいなどが考えられます。
逆にソフトウェア特有の要因としては、ハードウェアの性能による縛りを受けることが挙げられます。
前半だけでも情報量が多いですね。「枯れた技術が採用されている以前に、技術の側が枯れていっている面も大きいんじゃないの？」と設問の前提から疑う回答を書いていますが、先程書いた「寝かしたことで書けた回答」がこれです。ちなみに風呂に入っているときに思いつき、変な声が出ました。やはり時間は多めにallocateしたほうがいいですね。
メリット
どちらにも言えるメリットとしては、(積極的にやっていようがいまいが)蓄積された知識の恩恵を受けやすいという点が挙げられます。
もっともこの恩恵はハードウェアはより受けやすいかもしれません。物理的な要件があるものにとって、実運用で得られる経験則は安全性の確保のための極めて重要な要素になりえます。実際飛行機事故は、製造会社が想定していない極めて特殊な状況下でのみ起こる異常な動作が原因となっているものがいくつもあります。ソフトウェアの場合はエッジケースをつついてみたりエミュレーションしてみたりで地上でも十分にデータが取れますがハードウェアはそうもいきません。宇宙という極限環境ならなおさらでしょう。
ソフトウェア特有のメリットとしては、枯れたハードウェアへ対応するのには同年代の枯れたソフトウェアを使う方が楽ということがあげられるでしょう。PC98向けにコードを書くときに最近できたイケイケなhoge言語を使おうとすれば恐ろしく手間がかかるのは容易に想像できます。こちらの記事はsksatさんのプロフィールからアークエッジ株式会社さんについて調べたときに見つけたものですが「Rustでの組み込みソフトウェア開発は地上でもまだまだ例が少なく、エミュレータやデバッガなどの開発環境や、デバイスドライバをはじめとするハードウェア固有のコード資産などは C 言語ほど充実していません」と書かれていらっしゃいます。
(https://diary.hatenablog.jp/entry/2021/09/28/093000)
そのものズバリなことが書かれているArkEdgeの社員の方のブログを引用していますが、これは「ArkEdge Rust」と直球な検索をしたら降ってきたものです。
Q4.1(発展)
Q.
ちなみに，講師の sksat はかなり新しいエコシステムである Rust を実際に仕事の衛星開発で使っており，講義でも Rust を使用する予定です．つまり，前述の「枯れた技術」に対して，少なくともソフトウェア開発の観点ではどちらかというと否定的な立場なわけですが，これに意見があれば自由に述べてください．
ヒント：意見は賛成でも反対でも「それでは足りない」のようなものでも構いません．sksat と意見が異なっても減点するようなことはありません．意見がすれ違うのは当然のことです．ぜひ語り合いましょう！
これ実は回答していません(任意だったので)。
しかし、「sksatと意見が異なっても減点するようなことはありません．意見がすれ違うのは当然のことです．ぜひ語り合いましょう！」という文章を読んだことが「お、これは噛みつき待ちでは!?じゃあ書かせていただきますか」とQ4の例の節を書くことに繋りました。
Q5
Q.
宇宙機はロケットという輸送手段で地上から宇宙に輸送され，軌道にデプロイされます．一度デプロイされた宇宙機は，原則として物理的に修理することができません．なぜなら，宇宙に出張に行って機体に近づいて蓋を開けることができないからです．そこに行って蓋を開けられないということは，ノートPCを持っていってデバッガをアタッチし，ソフトウェアを書き換えることもできません．これが非修理系です．
これは非常に不便な特性です．打ち上げて運用を開始してからバグが見つかったらどうしましょう？そのバグは姿勢制御系の秘孔を突いて高速回転を発生させ，遠心力で機体が破壊されてしまうような致命的なものかもしれません．
また，バグでなくとも，途中から要求が変わるかもしれません．例えば気象目的の人工衛星で，特定の種類の雲を衛星上で認識するミッションがあるとします．これは問題なく動作していたのですが，運用開始後，また別の種類の雲を衛星画像から判定するアルゴリズムの研究が発表されました．これを即座に軌道上の衛星に組み込めると非常に価値があります．
このような問題に対して，どのような技術的解決が考えられるでしょうか？また，どのように宇宙機やそのソフトウェア，送信するコマンド群などの運用計画を設計しておけば，運用時に後から発生する問題に対して対処しやすくなるでしょうか？自由に提案してみてください．
ヒント：漠然としていて考えにくい場合は，宇宙機を普通のLinuxサーバだと仮定してみるとよいでしょう．ただし，物理筐体を直接操作することはできず，通信機会が1回数分で1日に1回程度の不便なサーバです．インターネットにも繋がっていません．このような制限は適宜調べたり，想像してみたりしてください．
A.
まず修正のための通信自体の効率化について考えると、差分のみを送信したり、効率的な圧縮をしたりが挙げられます。圧縮については通信できる回数自体が少ないので、復元時間は気にせず可能なかぎり圧縮したいところです。
ソフトウェア自体は、修正や機能改善を行なったあとに地上で正確なシミュレーションをするためには実機と環境を揃えることが望まれますが、実機と通信できる機会が少ないことにより機体の取り得る状態が増えれば増えるほど再現が難しくなります。(例えば、消費電力が一定以上になったら自動的にモードを切り換えるなどの動作を組みこむことは、例え有益であったとしても地上での再現の難しさとのトレードオフになります)
コマンドなどの送信に関わらず変化しうる状態変数はできるかぎり減らしておくべきでしょう。
また、これもベタですが、何らかの不具合で機体が危険に晒された場合、機体が自ら判断して、地上が対策をするまで持ちこたえる機能も必要です。具体的には、プログラムを実行するのと並行して絶対に達成しないといけないタスク(姿勢の制御など)を自ら監視し、異常があれば全てのプログラムを停止して最低限必要な機能のみで再起動する一種のセーフモードなども必要です。
まとめると、実際に変更を適用する前に実環境と近いテストができるように、限られた情報の伝達でも再現をしやすくすること、致命的な不具合が発生した場合余計なことをせずにログを残しつつ動作を続けることが宇宙機には必要だと考えます。
これは一番大変でした。非修理系、かつ宇宙に存在していて通信が難しいもののデバッグなんてやったことがあるわけがないです。まあこれはほとんどの応募者がそうだと思われますが...
とにかく設問通り、想像を働かせて書けるだけ書きました。想像力と未知の複雑性の分解の過程を見る問題だったんでしょうかね。
セルフ総評
当社比だとなかなか良い文章で回答できているような気はします。特にQ4前半は自分史上最高に良かったと感じています(最大出力でこれか？という批判は甘んじて受け入れさせていただきます)。
第一志望の探査機自作に行けたので個人的に結果に文句はないのですが、課題への取り組み方で後悔している点を一つ上げるとすれば、探査機自作ゼミに全振りした結果他ゼミの課題にまるで取りくめなかったことです。次にこのような併願可能な課題をやるときは第一志望に全てを注いでしまうという自分のクセを理解した上で行動するべきであるという知見を得ました。
それでは寝ます!後日上がるであろう参加記でお会いしましょう!
Discussion