【書評】現代の多忙な管理職の実態 | 罰ゲーム化する管理職

読書

罰ゲーム化する管理職　バグだらけの職場の修正法（インターナショナル新書） (集英社インターナショナル)

罰ゲーム化する管理職　バグだらけの職場の修正法（インターナショナル新書） (集英社インターナショナル)

Amazon

現代の管理職は、組織のフラット化により負担が高いにもかかわらず、賃金がメンバー職と格差が少なく報われない。また、近年のパラハラ対応や働き方た改革の煽りを受けておりさらに問題が複雑化している。本書はそのような罰ゲーム化している管理職の現状に関して、データを使って可視化をしたという点で意義深い。解決策の提案につながる論理展開に「ん？」というところがあるが、それを差し引いても管理職の実態について豊富なデータを提供してくれて参考になることが多い。

以下のような読者にお勧めである。

  • 自分の状況をデータを元に見つめ直したい管理職
  • 管理職になることに不安を感じる非管理職
  • 管理職を取り巻く課題解決に関心のある経営者

参考になった点

  • 人事部と管理職で問題意識のすれ違いがある。管理職は人/時間のリソース不足に問題意識があり、人事部は働き方改革など近年表面化している課題への対応に問題があると思っている。人事部の現状把握不足、サーベイの必要性。
  • 経営層ともジェネレーションギャップがある。経営層は「俺の頃はもっと大変だった」「苦労は進んでしろ」という根性論的意識があるが、今の世代では「なぜこの会社でそこまでしないといけない？」と経営層の言葉が響かない。経営層と管理職のコミュニケーション不足。
  • 管理職と管理監督者は違う。人事権がないのは管理監督者とは言えない。
  • 官僚制にはメリットがある、大量の仕事に対して全体を気にせずに専門領域に集中して効率的に仕事を進められる。官僚制を享受している中で、全体を見て欲しい、経営思考を持てと言うのは矛盾している。これは、部分最適をしている人間が全体を見ないと機能不全になってしまうと言う、敷いている官僚制のシステムに不備があると言っているようなもの、権限の移譲やジョブの分割がうまく行ってないということ。
  • 目標管理はそれが自身のスキルアップとかにつながるという価値観でないと機能しない
  • フォローワーシップ・アプローチの一つとして紹介された、管理職の研修や管理職へ指示していることを部下にも伝えるのは良い試み。管理職のブラックボックス化は、メンバー層の管理職へ昇進意欲の障壁になってると思う。給与とかもよくわからんし。

イマイチな点

  • 4章の修正編で4つの解決アプローチを紹介している。しかし、この4つアプローチが、前述までのどの問題に対するアプローチなのか明確ではない。おそらく、3章までの問題に対する施策を、問題に対する施策をまとめるのではなく、施策の種類別にカテゴライズしてしまっているため、3章までのつながりがわかりづらくなっている。
  • 「ネットワーク・アプローチ」が前述までの問題のどれに対する解決策なのか読み取れない。急に湧いてきたように見える。
  • 「キャリア・アプローチ」は、現在の日本のキャリアアップ方式であるオプトアウト方式の是正を求めるものである。しかし、そもそもオプトアウト方式の強固なデメリットが本文で示されておらず、さらにそれが管理職の負担増にどう繋がっているのか自明ではないため、なぜその是正を施策に持ってくるのか納得感がない。

Object-Oriented Conference 2024参加まとめ

ソフトウェア

Object-Oriented Conferece 2024に参加してみました。 なかなかこういうカンファレンスに参加する時間が取れず久々の参加でした。 設計とは、とか、オブジェクト指向とはというそもそも論から、やってみた系の事例紹介まで幅広く取り上げられており、非常に刺激的でした。

本記事は身内で公開用にまとめていたのですが、その機会も無くなったのでここに投下します。 まとめは自分が参加した講演のみです。 一応自分なりにまとめてみたつもりですが、メモとかは結構スライドそのままになってしまっています。 詳細については公開資料の場所がわかったものはURLを載せていますので公開資料を確認してみてください。

OOCとは

Object-Oriented Conference はオブジェクト指向をテーマに、アイデアを共有し、議論を深めるイベント。

ooc.dev

オブジェクト指向のリ・オリエンテーション　～歴史を振り返り、AI時代に向きなおる～

  • 10:50-11:30 Track A（共2-201）
  • スピーカー：羽生田 栄一（株式会社豆蔵）
  • 公開資料：

speakerdeck.com

所感

  • OOPの5段階の話が印象的だった
  • OOPの5段階を自分に当てはめてみると、3段階目で留まっている（というか2段階目もちゃんとできているのかあやしい）
  • DDDも気になるけどまずは4段階に進めるようにしたい

メモ

OOPの5段階

  1. オブジェクトとメッセージ
  2. 責務を割り当てる
  3. クラス、継承、ポリモルフィズム（を使っている）
    1. 意味のあるまとまりをクラスにまとめてないと意味がない
    2. getter/setterでカプセル化できたことにならない
    3. リスコフの置換原理...継承クラスは親クラスを置換可能でなければならない...置換できない継承はNG
  4. 抽象データ型、サブタイピング、インタフェース指向設計、コンポジション、OCP、DbC、SOLID
  5. 依存反転、イミュータブル、DDD

第三段階は形式的で意味がないので早く次の段階へ

生成AIの不確実性と向き合うためのオブジェクト指向設計

  • 11:40〜12:00 Track A（共2-201）
  • スピーカー：菊池　琢弥（Algomatic）
  • 公開資料：なし

所感

  • ユースケースの説明はとても良かった。生成AIというとなんとなくすごいものというイメージしかなかったので、システム化の観点が得られた。

メモ

生成AIのユースケース

  • 扱いにくいデータをいい感じに扱える
    • 扱いにくいデータ...メインのメニューを集計したいが店ごとに異なる、アイスとアイスクリームで表記が違う
    • ファクトチェックが必要
  • AAAA
    • Automation: 人がやりたくない（心理的にしんどい、危険）、やり切れない（量的に）
    • Agent: 人が持ってない知識、スキル
    • Advice: 人が責任を持つ作業、人の内省・成長を促す
    • Augment: 楽しいこと、リアルタイム性が求められる

生成AIプロダクトの難しいところ

  • 技術基盤の進歩が早い
  • 遅くて高額なAPI
  • 生成AIとの結合度が悩ましい（別のモデルに切り替える必要性が高い）

実践！RDRAを活用した既存システムの仕様変更

  • 12:30-12:50 Track C（共2-102）
  • スピーカー：今本　光（株式会社ラクス）
  • 公開資料：

speakerdeck.com

所感

  • RDRAは知っていたが今一どう手を動かしていくかというイメージがついていなかったが、上位を入力に下位にというのは参考になった
  • RDRAの採用理由とか適用の事例として参考になった
  • どういうケースであれば無理なく適用できそうかイメージアップできた

RDRAをどう生かしたか

  • RDRAを利用した理由
    • デグレリスクの低減
    • 社内の小規模なシステムであった（RDRA自体はかなりカロリーを使う活動だが、社内だし小規模だし適用させやすかった）
  • システムリプレースなので下位レイヤから上位にフィードバックしていった
    • リバースしてシステムの情報の洗い出し
    • ユースケースを整理
    • 既存システムの要求をリストアップ（これを変えないようにリプレースや改修する）
    • 整合をとりながら下位レイヤを修正

実施してみて

  • 既存の処理に無駄なものが見つかり整理できた
  • 要求を見直す機会になった
  • 小規模でもかなり工数がかかる
  • 開発者目線のモデルになりがち

イベントストーミングによるオブジェクトモデリング: オブジェクト指向プログラミングへの適用/開発プロセスの変遷/アーキテクチャの変革

speakerdeck.com

所感

  • イベントストーミングという設計手法自体は結構使えるような気がする、
  • システムの全体像をみんなで共有できるという点は良い

メモ

イベントストーミング

  • メインエキスパートと開発チームが協力してドメインの理解を深めるワークショップ手法
  • イベントに着目して洗い出しをする
  • 効果
    • イベントを中心として業務フローを明確化できる
    • ドメインの認識齟齬解消
    • 全体像が俯瞰できる

CQRS(Command Query Responsibility Segregation)

  • 従来のアプリケーション
    • データベースには検索のためのデータを格納（登録時のデータが欠損する）
    • コマンド（登録）とクエリ（参照）は要件が異なる（従来のアプリケーションでは区別せず一つのアプリ）
      • コマンド：整合性が求められる、集約単体に対する処理
      • クエリ：処理実行時の高速化が求められる、集約を跨いだ処理
  • CQRS
    • イベントとクエリを分離、イベントから変換をしてクエリ用のデータを作成する
    • Event Sourceing
      • イベントをそのままjson形式で格納する
      • イベントストーミングのイベントがそのままCQRSのイベントになるため相性が良い

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

  • 14:00〜14:40 Track A（共2-201）
  • スピーカー：pospome（DMM.com）
  • 公開資料：

speakerdeck.com

所感

  • よりコーディングを意識した設計力を高める必要がある
  • DDDをやるには、設計に軽くフィードバックできるプロセスが必要

メモ

DDDを理解する

  • ドメインとは、ソフトウェアを適用する領域
    • vs. データベース駆動
      • ORMを使うと自然とクラスができるのでそれっぽくなるが、DBの構造はプログラミングに最適というわけではない
      • 依存関係が多くなりモデルがFatになりがち（Fat Model)
      • モデルがFatになることを避けるためにアプリケーションレイヤに逃すとドメインモデル貧血症になってしまう
    • ドメインに適した設計を心がける（ドメインに自由度を与える）

設計能力の壁

  • どうすれば満たせるか？
    • 設計の基礎力を固める
      • 勉強あるのみ（DRY原則、SOLID原則、DI戦略）
    • DDD本が示すのはあくまでプラクティスで実装をどうするかは与えてくれない
      • 設計の基礎力を高めないと進められない
    • 勉強とアウトプット
      • 現場にあるコードを、書籍で学んだパターンでリファクタリングしてみる
      • ブログを書く

非デザイナーのフロントエンドエンジニアがOOUIを考える

  • 15:00-15:20 Track D（共1-301）
  • スピーカー：Oyu（DMM.com）
  • 公開資料：なし

所感

  • OOUIのエッセンスをおさらいできた
  • タスク指向でも向いているケースがあり使い分けのイメージができた

メモ

OOUIとタスク指向UIの使い分け

  • OOUI: 創造的なUIの作成
  • タスク指向UI: 定型的な作業用のUI
  • エイブルのUI、初回はタスク指向、二回目はOOUI

sevendex.com

  • 自由すぎてユーザが何したらいいかわからない場面はタスク指向でもハマるかも（トレーニングとか）

宅配クリーニングサービス「Lenet」開発におけるDDD7年の歩み

  • 15:30-15:50Track D（共1-301）
  • スピーカー：仲見川 勝人（株式会社ホワイトプラス）
  • 公開資料：

speakerdeck.com

所感

メモ

DDD導入のためのアプローチ

設計の抽象からAIに代替されない設計力について考える

  • 16:00-16:40 Track B（共2-101）
  • スピーカー：石橋 隆平（株式会社YESOD）
  • 公開資料：

docs.google.com

所感

  • 設計とはというそもそも論から整理されており参考になった
  • AI時代を生き抜くためのヒントが得られた

メモ

  • 設計とは、コンテキスト、要求、形、適合の4つが揃ったモノである
  • 設計の正解は要求や制約次第である
  • AIが人間の仕事を代替する時代が来ている
  • 領域特化の人材は価値が下がる（AIが得意な分野なので）
  • 横断的領域で調整や意思決定ができる人、要求に関する体系的な知識を持っている（つまり制約をコントロールできる）ことが重要

オブジェクト指向は必要なのか

  • 17:00-17:40 Track B（共2-101）
  • スピーカー：きしだ なおき（LINE ヤフー）
  • 公開資料：

speakerdeck.com

所感

メモ

Macでプロセス停止時の再起動を実現するには

Mac

CentOSなどではsystemdのRestartの設定でプロセス停止時の再起動が実現できる。 MacではlaunchdのplistのKeepAliveで指定できる。

launchd実行の仕組み

launchdではplistというファイルにプロセスの設定を記載し、launchctlコマンド経由でlaunchdに対して設定の読み込み、プロセスの起動などを指示する。

plistの場所

plistはプロセスの種類によって以下のような場所に格納する。

場所 説明
~/Library/LaunchAgents ユーザが提供するユーザごとのエージェント
/Library/LaunchAgents 管理者が提供するユーザごとのエージェント
/Library/LaunchMaemons 管理者が提供するシステムワイドのデーモン
/System/Library/LaunchAgents OSが提供するユーザごとのエージェント
/System/Library/LaunchDaemon OSが提供するシステムワイドのデーモン

今回は自分で作ったプロセスなので「~/Library/LaunchAgents」配下に作成した。 自分の場合は~/Library配下に該当のフォルダがなかったので自分で作成した。

plistの記載

自分が設定したplistの記載例を以下に示す。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        //プロセスを識別するラベル
        <key>Label</key>
        <string>com.hoge.process</string>
        //実行プロセス
        <key>Program</key>
        <string>/nanika/no/program</string>
        //サーバ起動時に起動
        <key>RunAtLoad</key>
        <true/>
        //落ちたら再起動
        <key>KeepAlive</key>
        <true/>
        //ワーキングディレクトリ
        <key>WorkingDirectory</key>
        <string>/working/directory</string>
        //標準エラー
        <key>StandardErrorPath</key>
        <string>/log/wo/hakutokoro/Error.log</string>
        //標準出力
        <key>StandardOutPath</key>
        <string>/log/wo/hakutokoro/Std.log</string>
        <dict>
            //環境変数
            <key>PATH</key>
            <string>/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin</string>
        </dict>
    </dict>
</plist>

このKeepAliveでプロセス停止時の再起動を実現できる。

標準エラーや標準出力は特に最初の起動確認では重宝するので設定をお勧めする。

自分の場合は環境変数を指定しないと以下のようなエラーが標準エラーのログに出力された。

env: node: No such file or directory

環境変数をplistに書くことで解消した。

launchctlコマンド例

plistのload/unload

launchctl load xxx.plist
launchctl unload xxx.plist

設定したplistの内容を実行/停止

launchctl start xxx.plist
launchctl stop xxx.plist

参考

以下のサイトなどがわかりやすかった。

MacOSのデーモンをマスターしよう：Launchdプロセス #MacOSX - Qiita

launchd, launchctlについて(導入編) · GitHub

windowsバックアップエラー(0x8078015B)の原因はsambaのバージョンだった件（その2）

raspberrypi Linux

以前、raspberrypiに構築したsambaの共有フォルダへのバックアップが失敗する件に対するブログを書いた。

niwanoniwatori.hateblo.jp

あれから何事もなかったのだが、ある日からバックアップがまた失敗するようになってしまった。ググってみたところ、このエラーコードはその他の原因でも出ることがあるらしい。

 

以下の記事を見て、バックアップファイルを一度削除（移動）してもう一度バックアップをやり直してみると、事象が解消しバックアップできるようになった。フルバックアップになってしまうので時間がかかることに注意。

 

superuser.com

日本庭園マップをGoogle mapのマイマップで公開しました

日本庭園

以前日本庭園の地図アプリとして「庭っぽ」というものを公開していました。

当初はAWSで運用していたのですが無料期間が過ぎてしまいそれ以降はHerokuで運用していました。 しかしHerokuも無料枠廃止となってしまいました。

そのため、google mapのマイマップにデータを設定して利用できるようにしました。 元々地図にアイコンを表示させるものでしたので、大きな違和感はなく使えるかなと思います。 日本庭園の散策計画用にご利用いただけると幸いです。

www.google.com

【まとめ】AMOS 2023 個人的に面白かった論文

宇宙状況監視/SSA 宇宙交通管理/STM

SSA関係の最大級の国際カンファレンス、AMOS(The Advanced Maui Optical and Space Surveillance Technologies)が2023/9/19〜9/22に開催されました。 amostech.com

私は非常に興味があったのですが、業務の都合でリモート参加すらできず。 しかし、この会議は素敵なことに毎年アーカイブとしてテクニカルペーパーを公開しています。 先日この2023年分のテクニカルペーパーが公開されたのでその中から面白かった論文の概要書いていきます。

amostech.com

An Investigation into Transecting Satellites in Future Space Traffic Management Scenarios

著者：Brian C. Gunter, Georgia Institute of Technology, School of Aerospace Engineering
URL：https://amostech.com/TechnicalPapers/2023/Conjunction-RPO/Gunter.pdf
概要：

  • 次の10年間に、地球近傍の宇宙に増加する大型衛星は、軌道の初期から目標高度に到達し、終了時には軌道離脱によって廃棄するため、軌道を変更します。これにより、衛星同士の衝突リスクが増加します。
  • 横断する衛星が将来の宇宙交通管理戦略に与える影響を評価するために、シミュレーションツールを使用して検討されました。
  • 横断衛星は多くのコンジャンクションを引き起こす可能性があり、最大5％の追加燃料がCAマヌーバに必要です。
  • 小型衛星は将来のシナリオでは比例的なリスクを持ち、現在の宇宙環境においては過大なリスクをもたらしません。

Characterizing A Novel Coordinated Optimal Avoidance Maneuver Framework for Space Traffic Management (STM)

著者：Andre Antunes de Sa, Kayhan Space
URL：https://amostech.com/TechnicalPapers/2023/Poster/Antunes_de_Sa.pdf
概要：

  • 現在、居住宇宙物体（RSO）の増加が宇宙の混雑問題を引き起こし、軌道上での衝突のリスクが増加しており、将来の宇宙経済の潜在力を危険に晒している。
  • 衝突回避リスク指標に関連する宇宙機の追跡の不確実性や不正確さは、回避マヌーバの燃料使用量の増加と回避機動の数の増加につながっている。
  • 著者らは新たな最適な回避マヌーバフレームワークの研究を行い、特に自動化と宇宙機の調整が必要な場合、最適な回避マヌーバ計画は複雑な問題であることを指摘している。
  • 実用的な回避マヌーバフレームワークは、各利害関係者のミッションおよび/または組織のニーズを考慮して柔軟かつカスタマイズ可能でなければならない。
  • Kayhan Spaceは、上記の必要性に対処するために最適な回避マヌーバフレームワークを開発し、更新を続けている。
  • このフレームワークは、資産の自動化構成のためのユーザーインターフェースと広範なマヌーバ提案エンジンを組み合わせている。
  • マヌーバ提案エンジンは、回避マヌーバフレームワークの重要な部分であり、この論文の主要な焦点である。
  • 今後の研究の計画には、回避マヌーバフレームワーク全体の特性の特徴付け、自動化能力のさらなる向上、マヌーバ提案エンジンに多目標関数のサポート、およびサポートされるリスクメトリクスとアルゴリズムの拡充が含まれる。

Autonomous Information Gathering Guidance for Spacecraft-to-Spacecraft Tracking with Optical Sensors

著者：Jesse Greaves, University of Colorado Boulder
URL：https://amostech.com/TechnicalPapers/2023/Poster/Greaves.pdf
概要：

  • 宇宙機対宇宙機の絶対追跡は、宇宙領域認識のために他の宇宙物体を観測し、宇宙システムの自律航法を可能にする。
  • 宇宙機間絶対追尾は、観測対象と観測者の絶対的な状態を同時に推定する方法で、光学センサーで実現可能。
  • 光学センサーは協調追跡と非協力追跡ができるが、距離情報の不確実性が大きくなる可能性がある。
  • 正確な追跡のために、状態情報を収集するための操縦を採用できる。
  • 情報収集マヌーバをステーションキーピングと組み合わせて、運用の複雑さと燃料消費を減らせる。
  • 本論文では、情報収集マヌーバをステーションキーピングセットに統合し、レンジの不確実性を最小限に抑えながら望ましい状態を達成する手法を提案。
  • この手法は、シスルナ空間でシミュレーションされ、望ましい状態のターゲティングと情報収集能力を示す。

A System-of-Systems Approach Towards Future Space Traffic Management Autonomy and Policy Co-Design

著者：Neera Jain, Purdue University
URL：https://amostech.com/TechnicalPapers/2023/Poster/Jain.pdf
概要：

  • 宇宙の安全性を確保するには、宇宙船とデブリの衝突リスクを排除する必要がある。
  • この目標を達成するために技術と政策の解決策があるが、これらは独立して追求されており、相互作用と全体の影響が不明確。
  • 宇宙の安全性と持続可能性を包括的に分析するためのモデリングフレームワークが提案されており、技術と政策の組み合わせが結果に与える影響を予測し、分析するために使用できる。
  • このフレームワークは宇宙交通管理がシステム・オブ・システムであることを示し、宇宙の多くの要因を考慮し、宇宙環境の安全性と持続可能性への影響を共同で分析する手法を提供。

Space Sustainability and Traffic Management Requires Trusted Space Stakeholder Coordination

著者：Harvey Reed, MITRE
URL：https://amostech.com/TechnicalPapers/2023/Poster/Reed.pdf
概要：

  • テキサス大学のMoriba Jahは2022年5月に議会で証言し、「宇宙内サービス、組立、および製造の戦略」に言及。彼は進行中の宇宙分野での監督が重要であり、明確で分散した台帳が必要だと主張。
  • 宇宙交通の複雑化に伴い、高度なステークホルダー調整が必要であり、信頼性のある情報と動的な調整が必要。
  • 個々のステークホルダーが信頼性のあるデータに対してアクセスできる場合、宇宙活動と安全性が向上し、宇宙の保全が期待される。
  • 宇宙は国際的なドメインであり、単一の統制権限がないため、分散型のソーシャルテクニカルな手法が必要。
  • このような情報共有を進めるために、著者はSISE (Space Information Sharing Ecosystems)というエコシステムを推進している。
  • 論文では、国際的なSISEプロトタイプを追求するための行動を呼びかけて結んでいる。

Challenges in Space Traffic Management

著者：Jim Reilly, Booz Allen Hamilton
URL：https://amostech.com/TechnicalPapers/2023/Poster/Reilly.pdf
概要：

  • 論文の焦点: 宇宙交通管理（STM）と宇宙状況認識（SSA）に焦点を当てる。
  • 挑戦の指摘: 衛星数の急増とデブリの増加による課題を強調。
  • 重要性の強調: 宇宙交通管理、データ統合、情報共有の重要性を特に強調。
  • 民間宇宙機関の必要性: 民間STM能力を強化し、宇宙状況認識を改善するためには、統一データライブラリ、データと通知の低遅延アクセス、通信フレームワークなどが必要。

Contrasting Architectures for Cislunar SDA and STM

著者：Joshua Wysack, Ball Aerospace
URL：https://amostech.com/TechnicalPapers/2023/Poster/Wysack.pdf
概要：

  • SDA（Space Domain Awareness）とSTM（Space Traffic Management）についての議論は、目的において混同されることが多い。
  • これら2つのミッションは要求事項に重複があるが、シスルナ空間をサポートするための異なるアーキテクチャを提唱している。
  • 最も大きな違いは、監視量と監視量を探索する再訪問率である。
  • 本論文では、SDAとSTMのアーキテクチャを要求空間の違いに合わせて紹介し、深宇宙探査のための複数の軌道ファミリーを評価し、各ミッションへの適用性を検討する。
  • また、両ミッションの偵察ボリュームを定義し、候補となるアーキテクチャを検討する。

Probabilistic Space Weather Modeling and its Impact on Space Situational Awareness and Space Traffic Management

著者：Smriti Nandan Paul, West Virginia University
URL：https://amostech.com/TechnicalPapers/2023/Poster/Paul.pdf
概要：

  • 低軌道（LEO）の宇宙物体の位置予測の不確実性は、熱圏密度の不確実性に影響を受ける。
  • 熱圏密度は、宇宙の気象条件が不安定な場合に変動する可能性がある。
  • LEO内の物体数が増加し、宇宙交通管理（STM）に課題が生じている。
  • 新しい確率的な密度モデルであるHASDM-MLおよびMSIS-UQに関する研究が行われ、これらのモデルが衛星の位置予測の不確実性を定量化するのにどのように役立つかが評価されている。
  • SpaceXのStarlinkやPlanetのDove連星などの衛星の軌道について、大気モデルの選択が検討されている。
  • これらの新しい密度モデルの影響は、最接近時刻や衝突の確率などの指標を用いて評価され、将来の作業に関する提案が議論されている。

宇宙状況監視/宇宙交通管理を手がけている企業(2023年版)

宇宙交通管理/STM 宇宙状況監視/SSA

近年、スペースデブリ問題や、衛星の大規模コンステレーションの構築により宇宙状況監視(SSA)に対する関心が高まっています。また、2023年6月に改訂された宇宙基本計画では初めて宇宙交通管理(STM)に言及があります。

そこで、この分野の特に民間企業の情勢を把握するために、宇宙状況監視や宇宙交通管理を手がけている企業をまとめてみようと思います。基本的には以下のようなカンファレンスに登壇している企業や、関連している企業を独断と偏見でピックアップしています。SSAというと防衛関連とつながりが強い分野であるため情報を公開していない企業は含まれていません。網羅性については期待しないでください。

www.strausscenter.org

www.iaassconference2023.space-safety.org

NeuraSpace

会社URL：Smarter Space Traffic Management - Neuraspace

SSAを生業にする企業はいくつかあるが、この企業はSTMを中心に据えるポルトガルの企業。特に、機械学習に強みがあり、誤警報の少ないスマートなSTMシステムを目指している。NeuraSpace社では、人工知能を宇宙交通管理の業界に初めて適用した、「機械学習予測プロット」を提供している。「機械学習予測プロット」により、オペレーターは衝突回避行動の準備をする前に、利用可能なデータで進めるか、追加データを待つかを数日早く決定することができる。これにより、貴重な燃料を節約し、不必要なマヌーバーを避けることによって衛星の寿命を延ばすことができる。

credit: NeuraSpace

GMV

会社URL(STM関連記事)：Space | GMV

スペインに本社を置き、世界各国に拠点を展開するハイテク企業。宇宙・防衛分野のみならずサイバー、自動車、金融など様々な事業を手掛ける。SSAにおいては90年後半からESAと協力して物体カタログや衝突回避のシステムを構築している。STM分野においては欧州委員会（EUSTMプロジェクト）のSTMガイドラインやベストプラクティス定義のための欧州コンソーシアムを主導するなど、この業界をリードしている。

credit: GMV

Kayhan Space Corp.

会社URL：Making Spaceflight Safer™ - Kayhan Space

衛星運用の自動化を推し進めるアメリカのベンチャー企業。同社の提供するSTMプラットフォームであるPathFinderは、コンジャンクションの評価、衝突回避のためのマニューバー計画作成、宇宙物体のスクリーニングを可能とする。また、2023年のSmall Satellite ConferenceではBenchmark社の衛星運転支援システムであるSmartAIMとの連携を発表し存在感を強めている。

credit: KayhanSpace

ExoAnalytic Solutions

会社URL：ExoAnalytic Solutions – Creative Solutions to Challenging Problems

3人の物理学者が創業を手がけたアメリカの企業。世界最大の光学望遠鏡ネットーワークExoAnalytic Global Telescope Network（EGTN）を提供している。その数は、観測所35以上、望遠鏡350台以上。これらの地上ネットワークの強みを活かして、宇宙物体の監視、アラートの発信、宇宙物体のカタログ提供など様々なSSAソリューションを提供している。

credit: ExoAnalytic Solutions

COMSPOC Corp.

会社URL：COMSPOC - Home

SSAの総合的なプラットフォームを提供するアメリカ合衆国の企業。2014年設立。SSAソフトウェア・スイート（SSS）は、サービス指向アーキテクチャの包括的な宇宙運用センター（SpOC）ソフトウェア・ソリューションです。このアーキテクチャは、スケーラビリティ、信頼性の高いパフォーマンス、完全なデータベース統合、安全な運用、ウェブベースのユーザーインタラクションのために設計されている。SSSはCOMSPOCの運用チームによって使用され、世界中の宇宙業務をサポートしている。

credit: COMSPOC

KBR Inc.

会社URL：KBR | We Deliver

アメリカ合衆国の民間軍需産業企業。宇宙分野では宇宙飛行士の訓練支援や、JWSTの開発等も行っている。SDA情報の収集、分析などのインテリジェンス活動や衛星の追跡監視等の支援をおこなっている。2022年には、宇宙商務省とSSAシステムのパイロットプロジェクトに関する契約も結んでいる。ただし、軍需産業色が強い企業のせいか、具体的なサービスや製品の情報は不透明。

credit: KBR inc.

NorthStar Earth & Space Inc.

会社URL：NORTHSTAR - Empowering humanity to preserve our planet

宇宙から宇宙を監視するという世界初のサービスを提供するカナダの企業。NorthStarは宇宙物体を宇宙から監視するための衛星コンステレーション「skylark」の構築を目指しており、2023年に最初の衛星の打ち上げが予定されている。日本ではAxelspaceがSSAデータを補完するために、自社衛星GRUSの衛星画像を提供することを発表している。また、ExoAnalyticと戦略的コラボレーション契約を結んでおり、ExoAnalyticの光学望遠鏡ネットワークで取得したデータと、NorthStarの衛星コンステレーションで得られたデータを組み合わせたSSAサービスの提供を目指している。

credit: NorthStar

Slingshot Aerospace

会社URL：Slingshot Aerospace - Mission First. Safety Included.

宇宙でのシミュレーションや分析のためのサービスを提供するアメリカ合衆国のベンチャー企業。2017年設立。宇宙状況監分野ではSlingshot Beaconという衛星衝突回避プラットフォームを提供している。Slingshot Beaconは以下のページからユーザ登録をすることで無料版を使用することができる。

slingshotaerospace.com

The Space Data Association

会社URL：Welcome to the Space Data Association - Space Data Association

宇宙環境における安全に関するデータの管理、および効率的な共有をサポートするために衛星オペレータを取りまとめている英国の非営利組織。SDAにはNASAやNOAA、日本ではスカパーJSATが参加している。加盟団体はSDAが提供するSpace Data Centerにデータを提供し、コンジャンクションの評価サービスや、宇宙物体の事業者の情報を得ることで、衛星運用に役立てることができる。

credit: space data association