プラットフォームエンジニアリングの “入り口” になる開発者のホーム画面
インシデント時や日々の開発で、「どこを、何から見ればいいか」迷わないための、
サービスとチーム、ツールを一箇所にまとめた “開発者のためのサービス図鑑(ソフトウェアカタログ)” です。
アラートが飛んできても、毎回「このサービス、どのチームが担当で、どのJiraを見ればいいんだっけ?」から始まり、初動だけで10〜30分が過ぎていく。
開発者の認知負荷が重い。変更対象のサービス仕様や依存関係、関連ドキュメントを探すだけで、Jira → ソースコードリポジトリ → Wiki → 監視ダッシュボード → Slack…とタブがどんどん増えていく。
任されたサービスやシステムについて知ろうとしても、「全体像」「関係するチーム」「見るべきツール」がバラバラに散らばっていて、キャッチアップに数週間〜数ヶ月かかってしまう。
Compass はサービスごとにオーナーチームや Jira、監視ツールなどを紐付け、一画面で集約管理できるツールです。異常発生時に「どのサービスで」「誰に連絡して」「どの Jira やダッシュボードを見ればいいか」をすぐ特定でき、担当者探しや情報探索のムダを減らして初動対応を早めます。
Compassを導入すると、Bitbucket や Slack、各種ドキュメントを一箇所に統合し、プルリクエストレビューやインシデント対応時の「探し物」を減らします。ツール乱立による開発者の認知負荷を下げ、新人もすぐ開発に集中できる迷わない環境をつくれます。
これまで Jira プロジェクトごとに管理してきたサービスや共通部品を、Compass で開発組織共通の “サービス図鑑(サービス/共通部品カタログ)” として見える化・管理できます。
サービスやライブラリ、インフラパーツ同士のつながりやオーナーシップも紐づけられ、関係性をひと目で追いかけられます。
Compass はサービスやコンポーネントごとに、Jira 課題、ソースコードリポジトリ、監視ダッシュボード、Runbook、設計ドキュメント、Slack チャンネルなどを紐付け、一画面に集約できます。
これまで「Jira → Wiki → 監視ツール → Slack」と行き来していた情報探索を、「まず Compass を開く」の一歩に統一できます。サービス単位で必要な情報が揃うことで、「このサービスのことはまずここを見ればいい」という状態を組織全体で共有できます。
サービスやライブラリ、インフラパーツ同士の依存関係を、Compass 上でコンポーネントとして登録・可視化できます。あるサービスの変更や障害が発生したときに、「どのサービスやチームへ影響しうるか」「どのシステムを確認すべきか」を素早く洗い出せます。
担当者だけが把握していた影響範囲の知識を、チームや組織で共有できる形にすることで、リリース判断やインシデント対応のリスクと迷いを減らします。
サービスごとに概要や目的、関連システム、担当チーム、主要なドキュメントやダッシュボードへのリンクを整理しておけます。新しく配属されたメンバーや異動者でも、誰かに聞き回る前に、自分で全体像をつかみ「どのサービスが何をしていて、どの資料を見ればよいか」を追えるようになります。
単なるリンク集ではなく、サービス単位で情報をまとめた“サービス図鑑”として使えるため、属人化していたシステム知識をチームの資産へと変えていけます。
Compass には、セキュリティや運用、アーキテクチャなど、組織として守ってほしい項目を定義し、各サービスの達成状況をスコアとして可視化できるスコアカードがあります。
新しいサービスはテンプレートから作成できるため、プラットフォームチームやテックリードが望むベースラインに沿った設計を自然と踏襲しやすくなります。個々人の意識に頼らず、開発ルールや運用基準を組織全体に浸透させる土台として機能します。
Compass の料金モデルでは、コンポーネントの作成や編集などを行うアクティブユーザーのみが課金対象で、サービス図鑑を閲覧するだけのユーザーはライセンス不要です。
少人数のプラットフォーム/SRE チームが中心となってコンポーネントやスコアカードを整備し、数十〜数百人規模の開発者や関係者がそれを参照する、といった使い方でもコストが膨らみにくいのが特長です。組織全体に「まず Compass を見に行く」文化を広げやすい料金設計です。
見積もりの依頼、
製品説明、
デモのご案内をします。