もし人工衛星開発部署に入ってしまったらの参考ケース
もう2か月も経っていますが、新年度に入り、日本では多くの人が様々な企業に入社されていることでしょう。
人工衛星の開発プロジェクトは、企業において立ち上がり段階から軌道に乗るまでは、人工衛星でなくとも何かしらの開発経験者が中心となって進めていくことが多いことでしょう。
しかし、すべての企業において、開発経験者を毎年人工衛星の開発プロジェクトに送り込むことはない。
大学で人工衛星の開発をしていたものもいるかもしれないが、毎年、配属できるわけでもない。
スタートアップ企業であれば、早急な結果を出す必要があるため、経験者を取るだろう。
優秀で熱意と、勤勉さを兼ね備えていれば大学を出たばかりでも配属されることはあるかもしれないが、大多数はそんなことはない。
そんなのは正直レアケースだ。
今回は、企業あるいは組織側に、人工衛星ってなんなの?何の役になっているの?親や友人になんて話せばいいのか分からないレベルの人が、どのように既存のプロジェクトに参入して、人工衛星開発を学んでいくかをまとめてみた。
[まとめ]
- 現在のシステム系統図で説明
- 「私たちの作っている」人工衛星はどのような機能・特徴を持っているのかを説明。システム系統図と一緒であった方が理解は早い
- ベテラン領域の人材の場合、検討課題項目と、リスク管理シートを提示しよう
- 状態遷移図を説明
- 過去の不具合を共有
- 人工衛星の機器は手作業で組立製造
- ベテランあるいは人工衛星経験者には、各機器を対象に既存開発、改善開発品、公開情報開発品、新規開発品を識別して提示
新規プロジェクト参入者への説明者が認識しておくべきこと
恐らく、教育担当から人工衛星とはなんなのか。どこに使われて、どんな風に役に立っているのか、テレビのニュースに色を付けた説明をすることになるのが多いのではないか。
しかし、プレゼンが上手ければ別だが、そんなことは新入社員からすれば、重要ではないというか、あまり記憶に残らない。
彼らが思うことは簡単
私がこれから何をするかを知りたい。何ができるのか知りたい。
ただ、それだけである。
ニュースや、業界関係者が分かりやすいとしている説明は、人工衛星とは?で説明されるものばかりである。
彼ら、彼女らが知りたいのは人工衛星開発とは?ではないのだ。
システム系統図から説明してみよう
自主的に課題や不明点を探し、自分なりに構築して、既存のメンバーとすり合わせるだけの能力を持っていればよいのだが、全員が全員持っているわけではない。
人数が多い組織では、その傾向が潜んでいる。
全員ができる現場であれば「アタリ」だけど、そんなことはない。
開発の立場から、地道に学んでおく必要がある。
そこで説明には、現在のシステム系統図が便利だと感じた。
しかも、なるべく詳細のシステム系統図を用意した方が良い。
開発初期であれば、過去に製造した人工衛星のシステム系統図を使用することでも問題はない。
その時注意するべきなのは、システム系統図をもとに、「私たちの作っている」人工衛星はどのような機能・特徴を持っているのかを説明することだ。
特に秀でているわけでなければ、汎用の量産機という説明でもいい。
教育担当は、同業他社から、あなたの人工衛星の特徴は?と聞かれたときに、絞り出せるすべてのことを最初から新入社員にぶつけるのだ。
そうでないと、多くの場合、取り組み始める新人が組み上げる人工衛星の設計思想がブレてしまう。
ニュース記事などで他の人工衛星を知ると、どうしても比較してしまう。
比較した時に違いを出せるように、最初のうちから説明した方がいい。
人工衛星開発は、各機能が複雑に絡み合っている集合体である。
人工衛星の分野に特化した、いわゆるサブシステム(姿勢軌道制御特化、構造特化、電源特化、通信特化など)を将来に渡り担当してもらうのであれば、システム系統図は不要である。
むしろ、コンポーネントやサブシステムの場合は、機能ブロック図を伝えた方が良い。
しかし、近年の人工衛星の小型化や高性能を出すための課題は、1つのコンポーネント、サブシステムの範囲を越えてた複的な範囲で影響し合うことが多い。
構造的に解決しても、電源的に不成立になったり、姿勢軌道制御的に解決しても、通信的に不成立になることも多い。
全体のバランスを取るのがとても難しいレベルに人工衛星開発がある。
システム系統図をもとに、どのような機能を持っているのか説明することをお勧めする。
人工衛星ではない、携帯や車のシステム系統図と比較するものよいだろう。
先にシステム系統図を説明しようといいつつ、一度は説明しても、謎の物体である人工衛星は、分かったような気でいて、実はぼんやりとした理解であると、配属されて一年弱ぐらいで気づかされるのだ。
身近な商品と比較することで、知識を馴染ませる方が、比較的理解が早かったと感じている。
身近な物体と比較することで、複雑なシステムを、ぼんやりと靄のかかったものではなく、シンプルに考えてもらう土壌をつくるのだ。
経験者であっても、システム系統図から学ぶことは多い。
例えば、自分の知っている人工衛星のシステム系統図を比較して、機器の数が違ったり、名称が違ったりすることがある。
名称が違うのは、組織内の文化による可能性も大いにあるが、細かく機能を見ていくと、自分の知っている人工衛星と近いけど違う機能をもつ機器であるという発見もできる。
機器が2つ以上ある場合は冗長系なのか、性能・機能の問題で2つ以上ないと目的(ミッション)を達せられないのか、といった気づきを得ることができる。
ちなみに、ベテラン領域の人材の場合だと、検討課題項目と、リスク管理シートがあれば、とりあえずは問題はないし、理解が早い。(課題とリスクは違うので、必ず分けて考えること)
なぜなら、細かい違いはあるが人工衛星のシステムは似ているからだ。
そこに作業のリソースを掛けるよりも、過去の経験則からこの組織では知らない検討課題の解決方法や、リスクの潰し方で、現在の人工衛星開発を前に進ませた方がいいと理解しているからだ。
人工衛星は打上げ日程が決まっている。
短い期間に多くの検討課題を素早く解決していく必要があるという経験を持っているはずだからだ。
システム系統図で全体を知ってもらったあとは、状態遷移図で衛星システムが、どのような状態を持っているのか知っておいた方がいいだろう。
状態遷移図は、姿勢軌道制御に関わる状態遷移図の方が理解が早いと感じている。
姿勢制御以外では、電源制御や通信の状態遷移図もある。
しかし、最初の説明では詳しすぎる。
姿勢制御と担当の状態遷移図があれば、それを説明するにとどめておいた方がいい。
開発フェーズによっては状態遷移図を見せられない時がある。
その場合は、最近の会議でよく話されている状態遷移を絡めて教えていくと、聞き手側も、後々の会議の理由を知ることができ、効果があるだろう。
そして、過去の不具合を共有すること。
過去の不具合で、作業者あるいは設計者の経験不足のために発生した、と分析をした経験はないだろうか。
まさしく、経験不足の作業者あるいは設計者がが今から作業を行う。
過去の不具合が再度発生する可能性は高い。
通常の手順書通りの作業の流れだけではなく、過去発生した不具合事項も含めて概要だけでも展開しておいた方が良い。
一覧表にするなり、列挙一覧としても問題はない。
不具合は各組織のフォーマットで提示するとして、少なくとも概要(数行)、発生詳細、原因/背景(具体的に記載)、対策、効果確認結果あるいは効果確認時期がある方がよい。
過去の不具合を経て手順書を反映しているので同じ不具合は発生しない。
それは正しいのだが、大抵、不具合を出した手順の少し後の方で違う不具合を出していることも多い。
集中力切れであったり、過去不具合を出した担当者は、これ以上不具合を出せないという集中力で後工程をカバーしていた可能性もあるのだ。
人工衛星の機器は、手作業で組立製造していることが多い。
今後、オートあるいはセミオート製造になれる部分が増えていくだろうが、まだまだ手作業の割合が多い。
単純作業であるからといってミスを発生させずに、不具合が発生したことのある作業であると伝え、緊張感をもって作業を行うようにした方がよい。
もちろん、組織によっては訓練制度もあるだろうから、十分な練度を積んだほうがよい。
最終的には、ワークマンシップと呼ばれる人工衛星の仕上がり品質に関わるため、忘れてはならない。
そして、ベテランあるいは人工衛星経験者に対しては、各機器を対象として、既存開発、改善開発品、公開情報開発品、新規開発品を識別して提示するなど、バックグランドをまとめておくと、実績具合を分かり、リスク管理もしやすくなる。
新人向けには、このあと、JAXA標準とかの話をはじめたりするのだが、まあ今日はこんな感じで。
mechanical-systems-sharing-ph.hatenablog.com