【まとめ】Satellite Navigation and Coordination with Limited Information Sharing

arxiv.org

現在、上空には推定8,800個の衛星と100万個以上のデブリが存在するが、2030年までには推定150,000個の活動中の衛星が宇宙に存在することになる。軌道上の物体の数が膨大になり、その結果、衝突の可能性が生じるため、現在のアプローチは通用しなくなる可能性が高く、自律的な意思決定が将来の宇宙交通管理（STM）に不可欠な特性となる。

ナビゲーションや衝突回避問題において、マルチエージェント強化学習(MARL)が有望な結果をもたらしている。ナビゲーションや衝突回避問題を含め、MARLに関する多くの研究が最近行われているが、宇宙領域アプリケーションでの使用は限られている。著者曰く、この研究は、衛星ナビゲーションと衝突回避のためにMARLを使用する最初の試みの一つである。

筆者らは地上ベースの衝突回避MARLモデルを転移学習して宇宙空間に適用することが非常に効果的であることを示した。宇宙環境でモデルを直接訓練する場合よりも、サンプルの複雑さが改善され、報酬がわずかに高くなる。次に、地球の扁平率に起因する重力擾乱の摂動を考慮した、より洗練された宇宙環境の抽象化を検討し、転移学習が依然として効果的であることを見出した。

最後に、衛星事業者の意思決定において情報共有が果たす役割について調べた。衛星運用者はセキュリティ上の懸念から衛星の情報を共有することを躊躇っている。これによりスクリーンサービスは誤警報率が高い。これにより警報に対する信頼性を著しく落としている。その結果、衛星運用者の通信ミスにより衛星間のニアミスが発生している。筆者らは、情報を共有した場合と、しない場合で、衛星が目的地に到達する成功率と目的地までの到達時間を比較した。その結果、情報を共有した場合、成功率は最大で100%以上の改善、到達時間は最大14%近く改善することがわかった。

表示しているページのURLをPerplexity AIで検索するブックマークレット

ChatGPTやBingのAIチャットが世間を賑わせています。世の中のビッグウェーブに乗りたい！と思って触ってみましたが、それぞれ一長一短があるようです。

• ChatGPT： 参考文献を返さない、最新の情報にアクセスできない
• Bing：参考文献は返してくれるが、Edge以外のブラウザで使えない <- これ大事

私はMacユーザでSafariを使っているのですが、これらのAIチャットでは「慣れ親しんだブラウザで、参考文献付きの回答を得る」ことは難しそうです。

そこで、もう一つのAIチャット、「Perplexity AI」に現在表示しているページのURLを放り込んで表示するブックマークレットを作りました。 Perplexity AIは他のAIチャットに比べて表現力はそこまで豊かではないのですが、検索結果に基づいて回答してくれて参考文献もつけてくれるので、自分で検索結果の確認をすることができます。ただし、Perplexity AIのブラウザ拡張機能はGoogle Chrome版しか用意されていないのでそれならばとブックマークレットを作りました。以下がソースです。

javascript:(
    function(){
        var searchKeyword = window.prompt("Perplexity.ai search keyword",location.href);
        if(searchKeyword != null){
            window.open('https://www.perplexity.ai/?q=' + searchKeyword);
        }
    }
)();

対象ページを開いてブックマークレットを実行すると以下のようなダイアログが出ます（例は私が最近気になった論文です）。

OKを押すとPerplexity AIのサイトに飛びます。

View Detailedを押すともう少し詳しく教えてくれます。

論文ライフが捗りますね！

【書評】プロダクトマネジメントのはじめの一歩 | ゼロから始めるプロダクトマネジメント

ゼロから始めるプロダクトマネジメント

プロダクトマネジメントの基礎を幅広く学びたくて読んだ。中学生がオリジナルアプリを開発、成長させていくというストーリーの中で、プロダクト開発をする中でプロダクトマネジメントの要素をどう取り込んでいくのかというのが例として示されており具体性があってとてもわかりやすかった。

浅く広くという本のため、開発自体の初心者であってもプロダクトマネジメントの全体像を知ることができる。また、アプリ開発は経験があっても、それをどう世の中に売り出してくか、という点について経験がない人にとっても参考になると思う。

プロダクトマネジメントでは、以下のような活動を行う。

• ユーザが抱える問題の仮説を立てる
• プロダクトを完成させ、ユーザに使ってもらう
• ユーザの利用状況を分析する
• エンゲージメントを獲得する
• プロダクトの認知を広げる
• エコノミクスを成立させる

本書を読むことでそれぞれの活動でのポイントを幅広く学ぶことができる。 例えば、以下のような内容がある。

• 最初の仮説検証のタイミングでは、ユーザは欲しい機能を言うことがあるが、ユーザは解決策を考えるプロではないので言う通りに作ってもユーザの要望を叶えることができない場合がある。言われたものを作るだけではなく、なぜその機能が必要なのかユーザのペインとニーズを分析する。
• 素早く仮説検証のサイクルを回すために、最小限の機能でプロダクトをリリースする
• 利用状況分析において、現象、パターン、構造、メンタルモデルに分解する考え方を「氷山モデル」と呼ぶ

個人的には、自分でアプリを作る場合はどうしても自分が使えればいいやと言う考えで、他者にどう見えるかどうしたら使ってもらえるかという視点が持てていなかった。本書で示されているHOOKモデルやPBLの考えを取り込むとより使ってもらえるアプリに出来るんじゃないかと思う。

【書評】ソフトウェアを設計するようにチームを設計する | チームトポロジー

チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計

チーム編成についてどうすればもっと良くできるのか悩んでいた時期に手に取った。この本は、ソフトウェアアーキテクチャの考えを組織に適用するという逆転の発想に基づいた組織論、チーム編成の本である。そのため、マネージャーなどの人事権を持つ人はもちろんだが、開発者にこそこの本を読んでソフトウェアを設計するようにチームを設計する面白さを知ってほしいと思う。

組織構造がソフトウェアのアーキテクチャを決定づけてしまうコンウェイの法則というものがある。本書ではそれを逆手に取って、目指すべきアーキテクチャを実現するように組織編成をするという、逆コンウェイ戦略に基づき、以下の4つのチームとチーム間の3つのインタラクションモードを提示している。

4つのチーム

• ストリームアラインドチーム
• プラットフォームチーム
• イネイブリングチーム
• コンプリケイティッド・サブシステムチーム

3つのインタラクションモード

• コラボレーション
• X-as-a-Service
• ファシリティテーション

それぞれのチームとモードがどのような役割でどういう場面で使うことで効果的かを詳しく説明しているので、この本を読むことで自分達のチームのあり方を見つめ直すことができる。

この本の中で取りあげられているチーム分割の観点はソフトウェアのアーキテクチャにも通じるところがあり、得体の知れない組織論ではなく、普段のソフトウェア開発の考え方を組織論に適用すれば良いチームに近づくことができる。

例えば、ソフトウェアの設計においては、コンポーネント同士は疎結合で高凝集となるように設計するのが良いとされている。これはチームにおいても同じで、１つのドメインには１つのチームを割り当て、そのチーム同士の依存関係を疎にするように境界を設計することで、１つのチームで仕事を完結させることができ、仕事のスピードも品質も上げることができる。 そういった、どのようなソフトウェアアーキテクチャとするのが良いのかということは、当然開発者が一番よく知っていることである。つまり、良い設計をするには、開発者は組織編成や人事権に口を出さなければならない。 本書にあるように

どのサービスを構築すべきか、どのチームが構築すべきかということをマネジャーに決めてもらっているなら、それはシステムのアーキテクチャーをマネジャーに決めてもらっているのと同じだ

というほどの危機感を開発者は持つべきである。

また、本書ではチームの「認知負荷」をいかに下げるかが鍵であると説明している。認知負荷とは心理学用語で、一つの仕事に対してあれもこれも考慮しながら作業すると頭が疲れてしまう状態のことを指す。PCで言うところのメモリが一度に大量の処理をするせいでパフォーマンスが落ちているような状態とも言える。

ソフトウェアの設計の際に、1つの巨大なクラスを作るのではなく分割して適切なサイズのクラスを作る、1つのクラスには1つの責務を与える、と言うことが良いとされる。サイズが適切で、責務が明確なクラスがコードリーディングしやすいように、チームも適切な作業規模で、知識ドメインを限定してあげる方が認知負荷が低くなり全体像を理解しながらも自分の仕事に集中できるようになる。

他にも、

モノリシックアーキテクチャーかマイクロサービスアーキテクチャーを選ぶのではなく、ソフトウェアをチームの認知負荷の制限に合った形に設計するのだ。

とあるように、マイクロサービスのような流行りに飛びつくのではなく、チームのスキル状態を鑑みて慣れ親しんだアーキテクチャを選択するのも認知負荷の観点からは適切な選択と言える。もし、業務要件でどうしても新たなアーキテクチャを採用せざるを得ない場合は、事前にチーム内で学習するなど認知負荷を下げる努力をするべきだろう。

以上のような、ソフトウェア設計のベストプラクティスをチーム設計に適用することで、良いチームに近づけるということを本書は教えてくれていると思う。

【書評】メタバースの最良の入門書 | メタバース さよならアトムの時代

メタバース　さよならアトムの時代 (集英社ノンフィクション)

マイクロソフトのちょまどさんが結婚する、ということでお相手のクラスター社の加藤直人さんの本ということで読んでみた。これまでメタバース関係の本を読んだことがなく、軽い気持ちで読んでみたのだが、「最重要キーワードが一番よくわかる教科書」の帯に偽りがない、メターバス関係の最良の入門書であると感じた。

本書では、メタバースの歴史的から、現在の世界の状況、そして将来の展望といった内容が非常に網羅的に書かれている。筆者自身がメタバースのプラットフォームを運営する会社の代表であり、この分野における熱量が感じられ引き込まれる。また、開発者目線での現状の問題点も取り上げられている。メタバースとは何かを学びたい人に最適だと思う。後書きにも書かれているが、2022年あたりに話題になっていることがかなり取り上げられているため、まさに今読むべき本である。

個人的には、旧Facebook、現在のMeta社がなぜメタバースに参入しているのかという筆者の考えも入った話が印象的だった。Facebookの収益は広告であるが、広告を見てもらうには自社のコンテンツを使ってもらう必要がある。ユーザにコンテンツを使ってもらうには、ユーザの可処分時間を奪い合う形で、ゲームやNetflexなどの動画サービスなどとも競合となる。ゲームや動画に比べるとSNSというのはユーザの時間をそこまで得ることはできない。しかし、ユーザの世界自体を作ってしまえば広告はどこでも自在に提示することができる。

従来の、リアルの延長にあるバーチャル空間であればユーザが単に暇つぶしに滞在する空間という程度の意味しかなく、あまり可能性を感じていなかった。しかし、マーケティグ的な必然性がバーチャル空間にあるのであれば、ビジネスとしてバーチャル空間がなくてはならないものになり、それに伴いメタバース周辺の発展も期待できる。今後はもう少しメタバースに注目していきたい。

【書評】ザ・ダークパターン ユーザの心や行動をあざむくデザイン

ザ・ダークパターン ユーザーの心や行動をあざむくデザイン

ユーザに不利益をもたらすWEBサイトの形式をダークパターンと呼ぶ。この本はさまざまなダークパターンを紹介しそれが一時的に組織の指標を改善したとしても将来的にはユーザ離れを引き起こすことを説明している。また、どのようにすればダークパターンを防ぐことができるかも紹介している。

本書はデザイナーやUI担当の開発者が読むことでダークパターンを知り、そこに陥らないようなデザインができるようになると感じる。マネージャーや経営者はダークパターンを生み出さないように、組織としてどのような目標を設定するべきか、また指標の見方を学ぶことができる。また、特に開発に携わらない人であっても、ダメなWEBサイトあるあるなのでただ読むだけで楽しめると思う。

個人的には、今までなんとなくダメだなと思っていたことが、これを読むことで、あぁ、これはダークパターンだな、とカテゴライズすることができ、そのパターンを採用している企業を評価できるようになることがこの本の1番有意義な点だと思う。以下は気になった話。

• こっそりカゴに入れるダークパターンは、例えば航空券予約の際にデフォルトで有料座席が選択されているケース。デフォルト値は本来はユーザ操作をスムーズに行うためのものでこれを悪用している。デフォルト値を適切に運用するのであれば9割以上のユーザが選ぶ、リスクの少ない選択肢をデフォルトにする。

• おとり商法のダークパターンはWindows10のアップデート画面のXボタン。Xボタンはアップデートを止めるではなく、アップデートを実行してしまう。マジで悪質。

• 信頼の貯水地のコンセプト、操作が難しかったりすると水位が下がり、価値を提供できると上がる。ダークパターンを使うと売上は一時的に上がるかもしれないが、信頼の水が枯渇してしまいユーザは去ってしまう。

• 定量的な指標を追い求めすぎると見かけだけ指標達成するためにダークパターンを使ってしまう。時には定性的に、ユーザーに良い体験を与えられているのか？に立ち返ることも大事。

• サービスを改善する時には、どうやったらユーザーは登録してくれるか？ではなく、なぜユーザーは登録したくないのかというユーザの不安を出発点にする。

• 顧客体験向上を目的とした「ノーススターメトリクス」を設定する。

• ダークパターンを防ぐために、無料会員登録数に対する有料会員登録数のような、「カウンターメトリクス」をみる。

【書評】 Amazon Mechanism

Amazon Mechanism （アマゾン・メカニズム） ― イノベーション量産の方程式

Amazonがなぜこんなにゲームチェンジを起こすような商品、サービスを提供できているかを書いた本。HowToの説明もあるが、企業文化、組織文化をどのように熟成させているかの説明もあり、組織論としても参考になる。

基本的には企業で企画を担当するような人が読むのかと思うが、企業を小さな組織と捉えて自チームの文化を変革したいマネージャ職や、リーダ職の人が読んでも参考になると思う。

以下は参考になった点。

Amazonでは企画書をプレスリリース形式で記載する。こうすることでユーザ目線で最終ゴールから逆算した視点で企画をブラッシュアップできる。顧客目線で考えるためのツールとして取り入れやすいのではと思った。

リーダへの権限委譲を進めるために、ツーウェイドアとワンウェイを判断基準にしている。ツーウェイドアとは後戻り可能な決定、ワンウェイは後戻りが困難な決定。前者であればリーダが独自の判断で決定してもよいとして、意思決定を迅速に行えるようにしている。何でもかんでも上にお伺い立てていると時間がかかるので、判断基準を示してあげることで上司は楽できるし、リーダは自分でプロジェクトを進めているという実感につながると思う。

人の評価に再現性があるかどうかを重視している。プロジェクトの成功/失敗というアウトプットは運によることが大きい。それよりはどれだけプロジェクトに対して準備できたか、インプットできたかどうかを評価する。評価基準として自分の中でも新しい考えと思ったし、自分の行動としても問題が起きる前にいかに準備対策できるかを意識したいと思った。