小型衛星と大型衛星の違いはサイズの違いだけではないのである
プロジェクト開発において、小さいプロジェクト、大きいプロジェクトそれぞれで開発の管理/マネージメントが違うといわれることがあります。
大型衛星から小型衛星に変わった場合でもそれは変わりません。
大型衛星のマネージメントのまま、小型衛星のマネージメントを行う。
逆に、小型衛星のマネージメントのまま、大型衛星のマネージメントを行う。
おそらくそれぞれ経験者がいたり、舵取りが上手ければ失敗することは少ないかと思います。ただ、1度、大きな不具合が発生した時に煽りは、とても大きなものになるかと思います。
経験者であれば、かつて経験していた方の衛星以上に苦労することでしょう。
本記事では、イベントとなる審査会を減らした方がいいだとか、作成プロダクトを減らした方が良いといったことは述べません。一長一短があるのですから。
その辺りはプロジェクトマネージメントらしく、管理側は柔軟に対応し、審査側も弾性的に受け入れていただければと思います。
それぞれの常識をかざしても、決して前に進まないのですから。どうにか、いいとこ取りができるようにしていただければと思います。
いくつかネットに小さいプロジェクトの管理手法のようなことが書かれていますが、小型衛星開発では小さいプロジェクトに分類されますが、長期間であるということに気を付けなければいけません。
情報システムのプロジェクト開発において、小さいプロジェクトは数か月と言われていますが、小型衛星開発は年単位です。
大型衛星の5年から10年程度からすれば、小型衛星の開発は2年から4年程度と短いですが、情報システムの小さなプロジェクトが数か月～半年と考えると長期間になります。
プロジェクトにおけるモチベーションの維持については、大きなプロジェクトと同じように、フォローをしていかなければいけません。
他の電化製品で2年以上かける新製品のプロジェクトはほとんどありません。流行や技術の進歩、社会情勢により目まぐるしく変わるからです。
通常の電化製品の開発メンバーからすれば、異常で、なぜそのモチベーションを保つことができるのか不思議なレベルといえるかもしれません。
その点、大型衛星から小型衛星に移ったのであれば、成果が早く表れ、成功体験を積むことができやすいというメリットはあります。
それでも、4年というのは長い、ということは記憶に残っていてほしいです。
曖昧な境界線
大型衛星ですと、全体を構成するシステムとサブシステムで分けられています。
ここでいう分けられているとは構成上の話ではなく、責任分界点として分かれている、区切られているということです。
システムとサブシステムはメンバーが同じであったり、情報を密に共有していますが、基本的には区切られています。
システムから与えられたリソースをサブシステムの中で構築していきます。
サブシステムからすると、システムの領域はぼんやりと想像できるが手を加えるのに障壁のある領域、不可侵領域となります。
手を入れたくても入れられない領域で、それだけ責任分界点が明確にされているとも言えます。
サブシステムは、システムからの要求をもとに作り上げていき、関係している他のサブシステムとのインターフェースも、基本はシステムを介して構築していきます。
一方、システムはすべてを見れないため、サブシステムとシステムとの主要な機能や分界点にあるインターフェースをはじめ、全体を主要な部分を管理していくことが多いです。ただ、すべてを把握し、管理しておくべきといえど、複雑なシステムであるため、様々なツールを使用していきます。
そこでインタフェース文書や要求文書、条件書、標準や基準、リスク管理文書などを利用して管理していきます。一人や二人でさばききれる量ではないのですから。
サブシステムはツールを利用して、システムに関わる部分、別のサブシステムに影響がある部分を把握したり、時に想像しながら、維持設計をしていきます。
このあたりの手法は、システムエンジニアリングの手法にあり、大型衛星でなくとも情報システムのシステム設計でも一部使用される手法となります。
主要となるインターフェースを管理し、システムとして齟齬が出ない様に全体を構築し、アクセスのしやすさやユーザビリティを設計していく、何も変わらない、はずです。
では、小型衛星で違う点は何があるのでしょう。
まずは、サブシステムとシステムの間が明確に区切られていない点です。
大型衛星ほど明確に責任分界点が区切られているところが少ないのではないでしょうか。
小型衛星の設計開発の人数は、小型衛星の設計規模によりますが、5人から30人程度。
ただ、すべてが同じ衛星に関わっているわけではなく、並行で複数の衛星であったり、衛星開発以外の業務に関わっているとなると、30人規模ですね。
もちろん、サブシステムではなく小型衛星の全体の体制としてです。
責任分界点が明確にされていないとサブシステムはどうなるでしょうか。
単純です。今まで不可侵に近かったシステムの領域にも触れることになります。
これはメリットでもあると同時にデメリットでもあります。
システムの領域に触れたのであれば、必要なところだけ検討したかったにもかかわらず、類似するすべての部分もサブシステムは、検討していかなければならなくなります。
今まで考えてこなかった、サブシステムからは見えなかった部分に関してもです。
考えなかったことを新たに考えるということは、当初予定した以上の時間がかかるのです。
新規設計ではないのですが、設計者の中での新規部分や今まで考えていなかったシステムとして検討し、把握する時間があった方がいいでしょう。これは、思いのほか順当に進まない可能性があり、スケジュール遅延の大きな原因となります。
小型衛星になったことで責任分界点があやふやな部分は、設計の抜け漏れにつながるため、明確化しておいた方がいいでしょう。
その部分を考えるのは誰なのか、抜けがないか、といったことは想像していた以上にメンバーでの情報共有が大事になります。
サブシステムが不可侵領域ではなくなったから設計を進めていったときに、他のサブシステムと関係することに後に気づいたり、他のサブシステムの構想とは違うものになり、やり直しになったりします。
情報共有が後手後手になっていくと、詳細設計時でサブシステム同士の設計のぶつかりが多くて、時間が大幅にかかることになります。
情報共有不足は人工衛星に限らず、プロジェクトが炎上、失敗する要因と言われています。
プロジェクトとして、何が必要で、何が不足しているのか、どの程度優先とするべきなのか、プロジェクト憲章ともいわれる根幹の部分を概念設計や基本設計で共有しておくべきだったと後々で気づくことになります。
そしてだいたい気づいてからは遅いのです。
システムとサブシステムで分かれ、それぞれの責任区分で進めていた時とは、システムが管理していたのですが、小型衛星になることで責任区分が(人工衛星自体が小さくなっているにもかかわらず)大きくなっているのです。
繰り返しになりますが、システム担当であっても、想像より複雑化している人工衛星システムを把握するのは難しいのです。
人間同士でコミュニケーションをとっているため、システムを挟んでいたとしても、別々のサブシステム同士が共通の認識をもったとしても、システムが同等の領域まで認識を深められるとは限らないのです。
(ただ、システム担当もサブシステムと同等の領域まで認識を深めた方がいいでしょう。キーポイントとしては記憶しておき、キーポイントが変更した場合に素早く影響のあるサブシステムを収集し、情報を吸い上げ、判断情報をまとめておいた方がいいでとは、思います。)
システムにまで食い込んだサブシステムが設計する曖昧な領域は、システムがフォローしてくれるとは限らないのです。
なぜか、人員が少ないからです。
システムを挟みつつ、サブシステム同士が情報を共有し、解決していく心持ちでないと抜けは発生します。
割り振られた仕事を処理していくだけではなく、システムとして関係しているところにも気を巡らせつつ、情報の共有や時には議論・討論をしていかなければならないことが、大型衛星より多くなりえます。
この辺りはプロジェクトマネジメントの知識を初期から設計開発の全メンバーで共有しておけば、抜けや食い違いの発生を最小限に抑えられるかもしれません。
システムから見れば、大型衛星はサブシステム同士がリソースの食い合い、そのバランスを調整しているのですが、小型衛星はリソースの譲り合いが行われるように調整しているのかもしれません。
まあ、この辺の加減を確認・管理していくのは、システムなのか、プロジェクトマネージャーなのか、プロジェクトリーダーなのか、組織の体制や性格によるところだと思います。
気づきは経験によるものが多いので一概には言えませんが、俯瞰してみているプロジェクトマネージャーの方が確認できればいいのではないでしょうか。管理はシステムかプロジェクトリーダーな気もしますね。
スケジュールによるかもしれませんが、メンバーが少ないほど意思疎通が取れ、メンバーが多くなるほど思ったほどプロジェクトが早くならない、不具合が発生してしまうことがあれば、初期からの情報共有が上手くいっていないためなのかもしれません。
ミッション系のシステムの優先度
前半に比べると要素としては小さいかもしれませんがミッションとの兼ね合いです。
大型衛星ではミッション系のシステムが最優先して、システムやバス機能を構築することが多いのですが、小型衛星ではミッションの実証衛星を除けばサブシステムの中のバス機能を含めて優先度はそれほど高くならないことが多いという点です。
小型衛星はリソース(ペイロード)が少ないため、人工衛星を動かく基本的な機能にも大型衛星に比べて大きなリソースを占めており、必然的にミッション系のシステムの優先度が下がるのです。
大型衛星のようにミッション系を最優先にしていると、システム全体が破綻するリスクを秘めています。
大型衛星のようにミッションの機能の一つや二つが、運用制限を受けるのではなく、ミッションすべてが破綻する可能性を秘めています。
システム全体の破綻を防ぐためには、本当に必要な最低限の機能を改めてメンバーで共有しておいた方がいいでしょう。
どうもエンジニアは、バランスではなく最良を目指す傾向が多いのです。
この機能もあの機能も「追加しておいた方がいい」と考えて、設計してしまいます。一度必要な機能のみを明確にして、そのほかは補助機能として明確にしておいた方が、最後に再設計するということは少なくなるのではないでしょうか。
また、必要な機能が明確でなければ、不要に大きな要求を担当者に指示し、結局は使わないという結果になりかねないからです。
といっても、大型衛星でも必要な機能の確認はされていると思いますが、大型衛星で必要な機能と小型衛星で必要な機能は変わってきます。
前述のミッションの優先度もその要因の一つですが、ロケット打上げ時の初期挙動をはじめ、動きが違うことも大きいです。
動きが違うということは機能が違う。機能が違うと、優先順位も変わるからです。
大型衛星と小型衛星の常識が違うということを認識したうえで、プロジェクトを進める必要があります。
案外、大型衛星の開発でサブシステムを担当し、小型衛星の開発に移り、大型衛星の戻ると、システムの最適化に望めるかもしれません。
もちろん、各人工衛星には量産品では無ければ、各々の特徴があるため、知識や経験からなる設計の思い込みを防止するための情報共有があった方がいいでしょう。
参考文献
プロジェクトチームが破綻する3つの理由。これからは「統制」ではなく「衆知」が成功の鍵を握る
https://goworkship.com/magazine/pm-project-team/
プロジェクトマネジメントの失敗はマネジャ，リーダーの資質に原因？
https://xtech.nikkei.com/it/free/ITPro/OPINION/20030803/1/
小さな社内プロジェクトを舐めてはならない
https://study-pm.com/practice/small-internal-project-failure/
お勧め書籍
