もし人工衛星開発部署に入ってしまったらの参考ケースつづき
今回はつづきである。
mechanical-systems-sharing-ph.hatenablog.com
前回は、新人向けに次のことを最初に教えておくとよい、としていた。
- システム系統図を教えておく。
- 状態遷移図で人工衛星の動作を教えておく。
- 不具合の共有を行う。
ちなみに、ベテラン向けには、検討課題項目と、リスク管理シートを出しておけばよいと、なかなか乱暴な感じであった。
上記の一連の説明は、ロケットの射場から人工衛星の放出と軌道上で動き（初期運用）まで説明することで、まとめて説明することができる。
ついでに、その時に人工衛星が受ける環境も伝えることで、振動試験や電気試験についても説明することができる。
人工衛星単体は、複雑なシステムの集合体であり、様々な技術が凝縮された製品であることは間違いない。
しかし、それだけでは嗜好品を作り上げた、というだけで終わってしまうだろう。
それではダメである。
現在は、人工衛星を使ったサービス、体験といったものに注目が集まれるような環境が整いつつある。
昔の自動車の広告がどのようなものだったか知っているでしょうか。
ボディがスマートでかっこよく、タイヤのデザインもきれいで、高級感を打ち出し、持っていることがステータスである。
そんな広告を中心に販売していた。
現在はどうだろうか。
自動車の中に家族が居て、家族で旅行して、旅行先で遊ぶ。
持っていることがステータスではなく、持っていることで新しい体験を、感動を与えてくれるツールであるという広告が多いのではないだろうか。
もちろん、高級感を打ち出す車種は存在しており、持っていることでのステータスを示す広告が残っているのは確かである。
しかし、見かける広告の種類としては逆転しているように感じないだろうか。
人工衛星も持っているだけではなく、どのようなサービスを提供できるツールであるかが重要になってきている。
それを打ち出さなければ、失速してしまうのだから。
そこで重要なのが地上局システム（地上システム）である。管制システム/運用システムという場合もある。
サービスをどのように提供するかは、最終的なアウトプット創出側となる地上局システムを考えておく必要がある。
地上から通信を行い、人工衛星を制御するという説明だけではなく、地上局で何をしているのかも含めて説明した方がよい。
なぜなら、人工衛星開発者は、地上局システムで実現可能な操作を越えた、ウルトラCな検討をすることがあるからだ。
そして結局は、人工衛星の機能として搭載されていても、使えないまま、使わないではなく使えないまま終わってしまう機能を開発してしまうからだ。
地上局で何をしているのか、なぜ電波を変更するのか、なぜ暗号化処理をするのか、暗号を複合するにはどうするのか、ミッションデータ（画像データ、観測データ）をどのように処理して提供するのか。
詳細とは言わず、ある程度の流れを知っておかないと、人工衛星単体の電気試験はもちろんだが、地上局と連携した地上試験の試験項目にも抜けが出てしまう。
開発終盤になって、地上局側でデータ処理を行うつもりだったのが、搭載しておらず、人工衛星側である程度のデータ処理を行うつもりと考えていたなどのすれ違いが発生してしまう。
地上局側にも、小規模でなければ、人工衛星と同様に機能に特化したサブシステムが存在することを忘れてはならない。
人工衛星側の運用設計あるあるで、トラブル対応やイレギュラー動作による対応を重点的に考えすぎており、平時の運用が驚くほどぼんやりとしており、決められていない（正確ではない・実現不可能）ことがある。
逆に、平時の運用のみ重点的に考えられているが、トラブル発生やイレギュラー動作への対応を全く考えていない、という両極端であることが多い。
声を上げても、優先度は、自分たちの開発している側しか考えられておらず、検討の優先度が下がるばかりで、結果、合同試験の半年前や数か月前なんてことは、よくある話である。
設計の抜けは、新人は知らないので抜けてしまうことはあるが、中途あるいは経験者でも、今まで考えてこなかったから問題ないと考えて、設計が抜けてしまうこともあり、十分注意が必要である。
日本であればやっぱりJAXA標準を参考にした方が早い
そしてJAXA標準である。
JAXA標準は、公開している部分だけでも総数500ページを超える巨大な知識の集合体である。
最初の説明は、エッセンスだけ抜き出すとよい。
そして、JAXA標準はあくまで標準である。
罰則があるわけでもなく、技術の革新が起こっている現状では、すべてカバーしきれているわけでもない。過去の情報をもとに作成されたであろう文書も残っているところもある。
JAXA標準を目安として、適合しないところは、理屈をつけて、別途プロジェクトごとの基準文書に詳細に記載したり、社内規則/手順書を更新していくのが、効率の良い使い方である。
このJAXA標準だが、実は公開されていない標準や付随文書としてハンドブックというくくりも存在する。
そこにはJAXA内部の実験データやノウハウが蓄積されている。
現在、民間の人工衛星が広がり、JAXAがサポートに回るようなことがたまに言われたりもするが、JAXA衛星のみが許された蓄積情報を存分に使って、人工衛星開発の統括を進めてもらいたいものである。
話が逸れたが、JAXA標準は前述のようにあくまで参考にして、基準文書として自分たちの人工衛星の指針をまとめていくとよい。
少なくとも、社内の設計規則に準じた基準書を作成することで設計の抜け防止にはつながる。
人工衛星の「継続的な」開発は、時間との勝負である。
開発期間が長くなりがちで、個人に依存した技術がある場合は、その人が退職や転職により、あっという間にロストテクノロジーになってしまう。
技術の蓄積は継続して進めるべき活動である。
そのためにも、JAXA標準は参考にした方がよく、新人の方には、検討不足がないように一通り目を通しておくように進めると、案外、経験者よりも地に足の着いたコメントを出してくれるはずだ。
