こんにちは、M2のあおしまです。
僕たちの代もあと3か月で卒業です。
衛星開発に捧げた大学生活6年間でしたが、
長かったような、短かったような不思議な感覚を持っています。
充実した時間だったのは間違いありません。
現在、当センターでは、代替わりが本格的に進行しています。
ひろがりプロジェクトに関しては、新PMの仲瀬くんの元、後輩たちが引っ張っていってくれています。
このままミッションサクセスまで突き進んでほしいです！
そして、ひろがりプロジェクトに次ぐ当センター3機目の衛星開発プロジェクトも、12月21日に無事キックオフをしました。
多くの方々を感動させるような（開発する自分たちも感動するような）ミッションを期待しています！
そんななか、「残りの3か月、自分には何ができるだろうか...」ということを考えていました。
おそらく、僕たちの代はひろがりの運用開始時にはすでに居ないか、居たとしても極めて短い期間だと思われます。
そして、3号機衛星プロジェクトの開発フェーズでは確実に卒業しています。
そんな去り行くものは何をしたらいいのか？
結論としては、僕の残り3か月のミッションは
- ひろがりプロジェクトがフルサクセスするための運用計画・練習のサポート
- 3号機衛星プロジェクトの開発を軌道に乗せるためのサポート
だな、と思いました。
1に関しては、
- 運用手順書を後輩と一緒にブラッシュアップする。
- 運用練習に参加して、運用者の「衛星」「作業手順」への理解を深めてもらう。
ことを最後までやり遂げることに尽きるだろうと思っています。
Just Do it！
2に関しては、
アプローチがすごく難しい...
開発が軌道に乗ると思う体制や開発方法を考えても、実施するのは後輩なので、僕がとやかく言うのは違う。
何をしたらいいのだろう...
色々考えたのですが、まずは
「衛星開発の反省をしっかりと行い、感想文的なものを残そう」
ということに行きつきました。
とりあえず、感想文を書く。そして、後輩が見える形でどこかに保存しておく。気休め程度に読んでもらう。
せっかくなので、多くの人が見える場所に残そう、ということで、このブログにまとめたいと思います。
自分って6年間何してたっけ？衛星ってそもそもなんだっけ？
そんなことを考えていました。
以下は、その個人的な感想文です。
技術的に細かい反省もあるのですが、局所的な解だと思いますので省きます。
できるだけ抽象的な感想文を書きたいと思います。
まだ何も成し遂げていないペーペーの自分が考えをさらすのは非常に恥ずかしいのですが、
自分の考えの整理、後世に1mmでも役に立つかもしれない、ということを思って書きたいと思います。
まあ、自己満です。
長文、乱文、失礼します。
1. 百聞は一見に如かず
開発のための知識を効率的に身につけるために一番良かった行動は
「とにかく形にしようとする」
ことだったと思います。
大学入学時の僕の知識習得の理想論は
必要な知識を体系的に身に着ける → 定着した広範な知識で殴り、目的の成果物を獲得する
でした。
この流れで成果物を得たときは、
広範な知識が会得できている安心感や万能感があり気持ちがいいと思います。
しかし、この方法は自分にとってはあまり効率のいいものではありませんでした。
原因は以下の通りです。
- 勉強の目的意識が薄くなり効率が下がる
- 利用先が明確にイメージできず、利用可能な知識に至らない場合がある
知識は利用可能になって初めて意味があると思います。
実際に何かを作ろうとしようとして、発生する勉強は
何のために勉強するのかが明確です。
そして、勉強の終了条件が自然と「利用可能になるまで」となります。
このように取得した知識は体系的とは言えないかもしれませんが、
点のような知識が、モノづくりを繰り返していくうちに
増えていき、網のようにつながって広くなっていく。
この知識習得プロセスが今の自分の理想論です。
特に衛星開発はウォーターフォール型の開発になりがちですので、
その考え方に慣れてしまい、
とりあえず作ってみよう ＜ とりあえず、深く考えてみよう
と偏ってしまいがちな気がします。
場合にもよりますが、意識的に
とりあえず作ってみよう
とりあえず行動してみよう
と考えるのが重要なのではないかと思います。
2. 衛星開発において重要な「デバッグ」
衛星の試験はデバッグの連続です。
問題の原因特定能力、修正能力が必ず必要になると思います。
ちなみに、僕の最初のデバッグ作業は、「OPUSAT-KITのFM通信中のヒューズ作動原因の究明」というものでした。
問題の原因が「安定化電源から衛星へ芋虫クリップで電源供給したことによる配線抵抗」であったのを今でも覚えています。
デバッグで重要なこととして3点あると個人的には思います。
①便利なツールが使えること
テスター、オシロスコープ、ロジアナ、SDR、スペアナ、ベクトルネットワークアナライザなど、状況を観測するための
便利なツールはあふれています。これらのツールをとにかく使ってみて観測できる幅を広げることが重要だと思います。
ただし、高価な計測器も多々あるので、これは先輩と一緒に使った方がいいというのが感想です。
②観測可能な設計にしておくこと
いくら便利なツールがあっても、観測できる余地がないと意味を成しません。
設計段階で、試験のことを意識して観測可能なピンを出しておくなどの工夫をしておくことが重要だと思います。
これをするかどうかで試験時の負担が大きく変わります。
ただし、EMやFMに試験システムを付随できるかどうかはリソースと相談ですし、
この試験システムが宇宙上で問題を起こすリスクもあるので、できれば取っ払いたいとなると思います。
少なくともBBMまではこの観測可能な設計を駆使して、できるだけバグを減らす、という方法をとるべきだと思います。
③システムを切り分けて問題を考える思考方法
闇雲にデバッグをしていても問題はなかなか特定できません。
システムを切り分けて、どこまでが正常で、どこからが異常を含んでいるかを意識的に思考することが重要だと思います。
(1) システムのどこに問題がありそうか仮説を置く
(2) 仮説を検証する試験を実施し観測を行う
(3) 正常に動作している or 異常を発見
このプロセスを繰り返して、正常な部分を増やしていき
異常を含んでいるコンポーネントの候補を狭めていき、原因特定。
という流れなのかな、と思っています。
ここで重要なのが
- システムの全体像、構成がイメージできること。（ポンチ絵が書けること）
- 本当に困ったときは、できるだけ最小単位のシステムに切り分けて試験を行うこと（ごちゃごちゃしてると切り分けられない、複数の原因がある場合がある）
だと思います。
あとは、最初は先輩と一緒にデバッグ作業を行い、先輩がどのような思考手順で問題を特定しているのかを観察するのが重要だと思います。
2回生の時に2学年上の先輩に考え方を叩き込んでいただいたのが思い出されます。とても貴重な経験でした。
3. 我が団体にあった開発手法
モノのクオリティは
① 初期設計の設計思想
② 試験・利用によるフィードバックの反映
で決まると思います。
衛星は一度宇宙上に放出されると、基本的に設計変更ができません。（リプログラム機能があればソフトウェアはアップデートできる）
さらに言ってしまうと、EM→FMでの設計変更は基本的に許されません。
早い段階で衛星のクオリティを上げておくことが非常に重要です。
そうなってくると、前者の方法である、
初期設計でできるだけ深く考慮し、設計変更が起こりにくく洗練されたシステムを設計する
としたい気持ちが強くなります。
しかし、この方法は強烈なリーダーシップ・経験を持つ人物が、
全力をかけて設計作業を行うことで大きく効果を発揮する方法だと思います。
我々の団体は学生が衛星を開発するので、衛星開発経験が長くても6年のものしかいません。
当センターには合っていないのかもしれません。
ですので、当センターは後者の方法主体で衛星のクオリティを上げていくしかないと思います。
ユースケースからくる大雑把な機能仕様、大枠のインターフェースをある程度決めてしまったら
とにかく手を動かしてモノにしてみる。そこから出た反省点をフィードバックして、再度ものにしてみる。
このサイクルを個人的にはBBMで3サイクルくらい回すべきなのではないかと考えています。
ここで忘れてはならないのは、
- とにかく手を動かすといっても、頭を動かさないわけではない。「とりあえず作る＝とりあえず作ろうと思考する」（戦略のない試行錯誤は闇雲である）
- 専門家・経験者にアドバイス、レビューを仰ぐこと（早めに！）
- たまに大局的にシステムを振り返る場を作ること（システムの規模が小さくないので、視点をいくつも持つ）
です。
「早く作って、試験する」といっても、そうはいかない部分はあります。
例えば、環境（放射線→信頼性、熱、無重力→姿勢制御）に依存して試験が困難な個所などです。
そういった部分は、手を動かすよりも頭を動かして検討に検討を重ねる、試験も万全の態勢で臨む、というアプローチになると思います。
まとめると、
基本的には手と足を動かして、早く形にする。
そのような方法が取れない部分は深く考える。
という開発方針がうちのセンターにあっているのだと思います。
泥臭さがいいところだと思います。
4. コミュニケーションは断固会話
Slackやメールよりも断固会話（zoomなど含む）だと思います。効率が高い！
堅苦しい会議はしなくてもいいので雑談が重要だと思います。
ただし、重要な設計情報はドキュメントで残し、それを使ってコミュニケーションが取れるようにする必要はあります。
また、外部団体との話し合いの場合は、会話で話した内容は再度確認の意味でドキュメントとして残し合意を取ることも必要だと思います。
5. 意義の高いミッションを考える必要条件
この方法に関しては自分の中で研究不足です。
デザイン思考という手法があるということについては最近PERSEUSの講演会で教えていただきました。
ひろがりでははじめ、2016年度後半に、学生がミッション案を出すという作業をしました。
しかし、なかなか良いアイデアは出てきませんでした。
最後は、
- 先生方を通じて、室蘭工業大学航空宇宙機システム研究センターの皆様に協力を仰いでいただいた
- 西無線研究所の西さんに、302A送信機でより高速な通信出力ができるという、ネタを聞いた機会があった
- アマチュア無線家の方には「衛星にアップリンクをしてみたい」という要望があることを、UNISECで耳にした
という経緯で現在のメインミッションが固まっていきました。
学生から良いミッションが出ない要因は分かっていることだけでも以下があります。
- そもそも社会・技術的なニーズが分からない
- 衛星開発期間が短いため、実現可能性が検討できない
ですので、学生団体が意義が高いミッションを提案するためには、以下の事は意識しなければならないのだと思います。（必要条件）
- 社会技術的ニーズを知るために、独自のアンテナを張る（新聞を読む、インターネット記事を読む、ニュースを見る、雑談をする）
- 有識者にヒアリングを行うことができる環境を作る（府大にはその環境があるので、利用できるようにする）
- とにかく質より数でミッション案を出す
- 「どのようなことをすると」「誰が」「どのくらい」喜んでくれるのかをまとめる。その喜んでくれる人とお話を深める。
衛星を作ったことがないからこそ、思いもつかなかったぶっとんだアイデア出る時もあります。
最近だと、「宇宙上でとあるインスタントラーメンを作る」「衛星ラジオ放送：府大衛星チャンネル」なんてアイデアも出ていて、見ていて面白いです。
このようなアイデアを一蹴するのではなく、真剣に検討し価値があるなら実行できるような環境が作れたら、
多くの人を感動させられる衛星が作れるのではないかと思います。
あと、個人的な意見なのですが、いいアイデアが出るのは、
会議中ではなく、何気なくご飯でも食べながら衛星について話しているとき、
というシチュエーションが多いような気がします。
6. お金の話
ひろがりの状況としては、2017年6月に予算計画をした際、
打ち上げ費用：500万円
衛星開発：約800万円
そして打ち上げを決めるためには、2017年度中に400万円を集める必要があるということが分かりました。
しかし、SSSRCの資金集めの能力はそれまでは年間40~100万円程度であり、このままだと確実に衛星を打ち上げられないということも分かっていました。
何としてもお金を集めよう、という活動が始まりました。
そこで意識したこととしては、以下の通りです。
① どなたならご支援いただけるか検討をする
② どうしたら①の方々に活動を知ってもらえるか検討する
③ どうしたら①の方々が支援しよう、という気持ちになるかを考える
④ どうしたらご支援いただいた方々に報いることができるのか検討する
⑤ ご支援のお願いをチーム一丸でできるように、①~④の考えをメンバーで綿密に共有する
⑥ チーム一丸でご支援のお願いをする
⑦ ご支援いただいた方に還元するための仕組みづくり
報いるための方法ですが、僕たちの団体はお金を稼いでいるわけではないので、
どうしても「ご支援のおかげで衛星開発が進捗しているという成果を継続的にお伝えする」というのがメインになってきてしまいます。
ここから脱却して
- 僕たちの団体が有名になって広報能力で企業の皆様のご支援をアピールする
- より社会に役に立つ技術を宇宙で実証して、ご支援いただいた方々の生活の豊かさに還元する
などを目指しています。
応援してくださる方々が大勢いらっしゃったという本当に温かい環境だったので
この反省が役に立つかは分からないのですが、
お金集めの活動から学んだことは、
- どなたに応援してもらうか
- 応援していただく方々にどうしたら僕たちの活動を知ってもらえるか
- どのようにしたら応援しよう、という気持ちになるか
- どのようにしたら、ご支援に報えるか
ということを検討し、それに沿って練った計画を実行に移すこと。
そして何よりも
- 実現させたいという情熱
が重要であるということです。
あと、よくある話なのですが、
物の値段が高価だと、使うのがもったいないという発想になってしまいがちです。
衛星開発では高価なものが多く、金銭感覚は学生のものですので。
当然なのですが、高価なものを買って、それ相応の時間を削減できるのであればその物は安いと言えます。
額面だけがコストではなく、時間もコストであることを考えてお金を使うのが重要だと思いました。
大切なお金なのですが、お金をケチって多大な時間がかかるよりは、お金をかけてより早く、完成度の高い成果物を出したほうが
ご支援いただいた方々へ報いられるのだと思います。
7. チームが駆動するヒント
今年度、新型コロナ感染症の流行により4月から2か月間大学への入構が禁止になりました。
そんな中、2020年6月からの2か月間、チームが今までに見たことがないようなすさまじい進捗をたたき出しました。
チームが高効率で駆動する姿を見ました。
具体的な作業
- 構体の再製造（フィットチェックケースに入らなかったのです...。 非常にお恥ずかしい）
- 再製造に伴う各種検査
- 2か月で予定していた機能試験を3週間で完了させる
- 各種審査
そこで、この高効率で駆動した原因を分析して、一般化できないかと考えました。
いわゆるデスマーチというものなので、参考にできないこと（してはいけないこと）もあると思いますが、
普段、チームを駆動させるためのヒントにはなるのではないかと考えています。
以下が、チームが高効率で駆動した原因の分析です。
① ゴールが明確であった
まず、8月初旬に衛星の納品をする。納品が完了したら、衛星局システムの開発は終了。
とゴールが明確であったことがあると思います。
普段の開発でも、成果物を明確化することが開発効率向上につながるのではないでしょうか。
② ゴールまでの期間が短かった
2か月後、衛星納品というゴールが見えていました。
成果物が出るまでの期間が分からないとなかなかモチベーションが上がってこないということもあると思います。
短いスパンでの成果物を設定することが開発効率向上につながるかもしれません。
③ 納期に強烈なプレッシャーがあった
納品できなければ打ち上げ自体が頓挫してしまう。
悲しいのですが、この納期という外発的要因は僕たちを動かす大きな原動力になっていました。
納期がないと人は作業をしない（場合が多い）。
④ 作業が明確化されていた
何をやればいいか明確だと効率が上がる。当然
⑤ 会議は少なかった
雑談で方針や問題点を議論することはあっても、堅苦しい会議はなかったと思います。
会議している時間もなかったし、雑談で話し合う方が議論の密度が高かったと思います。
最後は規模が小さかったのでこの方法でコミュニケーションがうまくいったのかもしれませんが、
会議が目的化せずに重要な部分を会議で議論する（雑談で済むなら雑談で）というのは重要なのだろうと思います。
⑥ メンバーの練度が上がっていた（自走できる状態）
衛星開発に参加する中で、衛星がどういうものかを知るだけでなく、
この衛星は自分たちが作り上げるものだという意識が深くなっていたと思います。
以下の記事でもありますが
「これは、自分のプロジェクトだ！」と思える人が多くなっていたのだと思います。
あと、やはり仲間が頑張っている姿は、自分の心を震わせ、動くための原動力になると思います。
⑦ 応援してくれる方々の存在
学生だけではできないことの連続でした。
僕たちの活動を応援・支援してくださる方々がいてはじめて、プロジェクトが回っていくのだと強く思います。
感謝してもしきれません。
8. 衛星開発が一段落した時に飲む酒は格別
衛星が無事試験をクリアし、納品まで達成した時に、開発メンバーと飲む酒は最高でした。
これが、宇宙へ行き、ミッションが達成した時にはもっとおいしいと思います。
衛星開発は苦しいことも多くありますが、それを仲間たちと乗り越えたときの達成感は格別です。
以上が、衛星開発の反省の一部になります。（まとめきれなくて妥協しました）
最後までお付き合いいただきありがとうございました。
残りの大学生活は3か月ですが、
ひろがりがミッションサクセスし、うまいお酒が飲めるように
3号機に微力でも貢献できるように
修論を書き上げられるように
精進したいと思います！