LoginSignup
22
17

More than 3 years have passed since last update.

アポロ計画におけるマトリックス組織について

Last updated at Posted at 2021-01-21

はじめに

この記事は趣味で宇宙開発をしている団体「リーマンサット・プロジェクト」がお送りする新春アドベントカレンダーです。

今更ですが、宇宙工学などに興味を持ったのは2年前からでした。凄すぎて馴染みがないというか。。
このため最近だとスペースXの偉業などが話題になっていますが、宇宙科学についても何も知らず、最近になって本やネットでの情報をもとに調べているところです。そしてその技術は調べるほどにハマっていきます。

タイトルになっているアポロ計画についてですが多くの文献が公開されています。SpaceSuitsの開発などをはじめ、様々なプロジェクトにて参考にさせていただいております(本当にこんなの公開していいのかというのもありますが。。)。実際に調べてみると写真や映像からは古さを感じますが、その考え方や技術については、古さを感じさせず多くの学びがあります。参加する以前は身の回りに関係するわけでもなく何の役に立つのか理解できていませんでしたが、その内容は奥深く今使われている技術のベースともなっており驚くことが多いです。今回は調べ思った結果をオチもなくタイトルとも関係なくポエム化した記事になります。

マトリックス組織とは

1960年代にNASA(米国航空宇宙局)がアポロ計画に参画した航空宇宙産業の企業に導入を推奨したプロダクトマネージャ制が始まりとされ、プロジェクトごとにマネージャーがおかれ、従来の職能型組織に、プロジェクトチームが横串を指すような形に編成された組織でした。
https://www.hrpro.co.jp/glossary_detail.php?id=22

アポロ計画をトップダウン的に意思決定したために、期限とコストを考慮してミッションの達成をしなければならなくなりました。担当する側にとっては専門分野におけるアウトプットとプロジェクトの責任分担を同時に課される必要がでてきため、ある意味無茶振り組織構造だと思います。
通常、何か目的を決めた時にツリー構造で表現すると情報の伝達は上下に展開されます。横への展開はコミュニケーションが円滑にいった場合のナレッジの共有ぐらいかなと思います。しかしプロダク及びプロジェクトが複雑化し、さらに多数の人が関わるシステムでは、アルゴリズム的に優先度などが考慮されてしまいます。そこでコストと納期や責任の観点から次元拡張して、同系列のタスク負荷を与えることにより両立させようとしたものと考えています。

今となっては珍しくもないですが、当時においては人材や資源を有効にするためには画期的だったでしょう。新たにシステムを文書化する中で合理化、形式化し、ブレのない開発を進めていく上では非常に有用で、当初は専門性、独自性を有するセンターとの摩擦があり、その均衡がいい意味で作用し、成功へつながったとのことです。(NASA-宇宙開発の60年)
そして中央の権限が強くなっていく中で、均衡が崩れ形式的な特色を残していった過程があります。また、タスクが増え担当レベルでは全体を見渡せなくなった影響もあるでしょう。

人類未踏の偉業を成し遂げたプロジェクトのプロセスとシステムをみてみると、自分が業務のプロジェクトにアサインされ、緩く他のプロジェクトに参加している身としては責任の重さを感じさせられ、またどのような立場をとっていけばいいかを考えさせられます。

私個人としてのプロジェクトとの関わり

今、rsp-02の電源系の開発と宇宙服のサークルに所属しています(サボリ気味になっていますが。。)。rsp02の電源開発については各系への要求に対して分割された機能ブロックを各人に割り当てられている状況です。一方で宇宙服のサークルについては、まだメンバーも少なくパーツのモデリングをしてすぐに辞めたり、電装のシステム設計をやったりと気の向くままに携わっています(ご迷惑をおかけしています)。

業務ではいくつかの複数の分割されたプロジェクトに参加しており、一方で別の開発にも参加しています。業務においては完全に分業化されているためモノに触ることは少なくなっていて、実践主義のリーマンサットに参加したときはそのギャップにビビりました(😱💦)。機会が少なければ、複数のプロジェクトに携わることを通して専門性を高めていきたい、そう考えるようになってきました。さらに、マトリックスの縦の軸にいながら横の軸に引っ張られ、時には布石としての立ち位置変え新たな可能性を見る。マトリックスを引っ張り出したときにそのような考えが浮かんできました。
マトリックス.JPG

組織としての3要素

1.共通の目的をもっていること(組織目的)
2.お互いに協力する意思をもっていること(貢献意欲)
3.円滑なコミュニケーションが取れること(情報共有)
https://preneur-preneur.com/3elements-of-organization/

組織の3要素という成立条件があるようです。
今携わっている業務の分担された内容や範囲を考え振り返ってみると、組織の3要素についていくつかの点においては取捨選択されることで優先順位がつけられている気がします。それは組織として稼ぐという事に重点を置かれた自分の環境下においては仕方のない事なのかもしれません。一方でリーマンサットにおいては、プロジェクトのアサインは個人の裁量に任され、何かを成し遂げるという目的達成のために非常に影響を受けています。

一つの開発を協力して立ち上げていくと同時に個々のアウトプットとは何かと考えた時、1軸ではなく多元的広がっていく成長も団体のアウトプットではないかと考えてみました。そういう意味では所属する環境を利用して可能性を広げてみるのもありかなと思います(恐れ多い🙇)。私自身として今スキル不足(深さが足りないと実感)のため戦力になれなくても(そうなれるよう継続する)、そこでの経験を次につなげていく事が大切だと思いたい(私の楽観)と常日頃考えています。物事を単純にするのは理解する上で楽ではあるが、その過程を失う事なく次へのプロジェクトにフィードバックできる、そのようなサイクルこそが必要ではないかと考えます。

個人的には縦の軸をこなすことで専門のスキルレベルを深め、ラテラルシンキングの考えを取り入れ、横に展開することで技術間のつながりを確認する。ゲームにおけるスキルマップとして活用していきたいかなと考えています。

アポロ計画の成功のカギはシステム工学

アポロ宇宙船ほどの複雑さをきわめる技術システムは、システム工学なくしては開発が不可能だったとされる。
                         NASA-宇宙開発の60年

今私個人として未体験の開発をしています。
冒頭に書いた凄すぎて想像できなかった衛星と宇宙服の開発。
できるか、できないか未知の領域。すでにモデルが過去にありそれを再現することができたならよいのですが、複雑で理解ができない。それをシステム工学の知見で要素を紐解きながら開発を続けられたらなと思います。さらに最新の情報を取り入れながら、先は長いとは思いますが着実に続けられたらと願いながら。。

備忘録

本当はプロダクトのシステム設計について書きたかったのですが、まずはシステムといえば組織だろということで書いてみました。ただ書き終わってみると、あまりにまとまりのない文書になってしまいました。システムの構造化については、調べるほど興味深く、調べていくうちにデザイン・ストラクチャ・マトリックスという設計手法があるらしく今後の開発で使えないか理解を深めていきたいと考えています。
https://otepipi.hatenablog.com/entry/2019/05/08/204932

参考文献

NASA-宇宙開発の60年
NASAのチームビルディング
https://ntrs.nasa.gov/citations/19800015708
https://history.nasa.gov/orgcharts/evol_org.pdf
http://coconut.sys.eng.shizuoka.ac.jp/ando/contr/Intro_Sys_Eng.pdf

終わりに

明日は @pmbit_jam「KiCADである程度の規模の基板を効率よく設計したい(モジュール設計を気軽にオープンソース開発環境で)」についてです。

リーマンサット・プロジェクトは「普通の人が集まって宇宙開発しよう」を合言葉に活動をしている民間団体です。
興味を持たれた方は https://www.rymansat.com/join からお気軽にどうぞ。

22
17
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
22
17