みなさんこんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
皆さんの組織では、どれだけのソフトウェア／アプリケーションを開発していますか？ 他のチームで開発しているものの内容をご存知ですか？
組織内のソフトウェア開発資産をリスト化し表示するのがソフトウェアカタログです。 そしてそのソフトウェアカタログを実現するのが内部開発者ポータルです。
では、実際ソフトウェアカタログの何が重要なのでしょうか？今回はその重要性について 解説していきたいと思います。
ソフトウェアカタログ
内部開発者ポータル（Internal Developer Portal / IDP）において ソフトウェア関連資産のカタログ化（ソフトウェアカタログ）は 単なるリスト作りではありません。 Platform Engineeringにおけるコア要素の１つといえるものです。
「認知負荷」の低減
まずソフトウェアカタログの重要性としてはじめに挙げられるのが 認知負荷の低減です。
認知負荷とは「人間が新しい情報を学んだり理解したりするときに、 「どれだけ脳に（認知的）負担がかかるか」を示すものです。 認知負荷には「Germane / Intrinsic / Extraneous」といった３つの 種類があります。
- Intrinsic（課題内在性）: 基礎知識（言語の文法、サービスの仕様の理解など）。
- Extraneous（課題外在性）: 本質的でないノイズ（探し物、複雑なデプロイ手順、ツールの使い方など）。
- Germane（学習関連）: 本質的な理解や価値創造（ビジネスロジックの設計など）。
これらについては以前のブログでも紹介しています。
エンジニアが新しいプロジェクトを始める際や、既存のサービスを修正する際、
「どこに何があるか、用途に適したものが公開されていないか」、
「同じものを別のチームで作成していないか」、
「利用するサービスやライブラリの使い方は？」、
「どのように修正すべきか」
といったことを探す時間は大きなロスです。
利用できるサービスがあること（Extraneous）、そうした存在を見つけること
（Extraneous）、サービスの利用方法を理解すること（Intrinsic）といった
認知負荷はできるだけ少なくしたいものです。
こうしたことを解決するために必要なのがソフトウェアカタログによる 「情報の集約」 です。 リポジトリ、ドキュメント、デプロイ先、API定義などが一つの画面で紐付けられます。 こうした情報を１か所にまとめ公開することで、利用者自身がサービス・利用者を 発見し利用できるようになり、有識者に質問するといった頻度も大きく削減されます。
さらに 「このサービス・ライブラリのオーナーは誰か？」 を明確に定義することができます。オーナーシップを定義することで
- その資産のライフサイクル管理の責任者（更新や廃棄・削除決定の責任者）
- その資産に貢献したいときに、その貢献を受け入れるかを決定する承認者
といったことが明確になります。そのオーナーシップが明確になれば、 どうしてもわからない点が出てきた場合でも問い合わせ （チャット機能などを用いた質問）が可能になります。
「認知の断片化」の解消
ソフトウェアのコンポーネント化・マイクロサービス化は時代の要請です。 AIを用いた開発が浸透するとこれまで以上のスピードでこうした設計が増えるものと 考えています。 マイクロサービス化が進むとシステム全体の構造を把握するのが難しくなっていきます。 複数のシステムを把握しようとする場合はなおさらです。
ソフトウェアカタログによって、点在する資産を「線」でつなぐことができるようになります。 これにより 「依存関係の可視化」 が実現でき、例えばあるサービスを アップデートする際の影響範囲を特定することもできるようになります。
またすでに似た機能の存在に気づくきっかけにもなり、さきほどの「情報の集約」とあわせて 「重複開発の防止」 といったことも期待できます。
ガバナンスとコンプライアンスの自動チェック
カタログ化されていることで、組織全体の資産に対して「標準」を適用しやすくなります。 例えば 「スコアカード機能」 を作成し、「最新のセキュリティパッチが適用されているか？」、 「テストカバー率は基準以上か？」といった状態を可視化することが可能になります。
また、開発者ポータルで提供されている 「テンプレート機能」 により、 様々な「標準」の適用をセルフサービスで自動化することも可能です。 例えば、セルフサービスで以下のようなことを実現することができるようになります。
- GitHubリポジトリの作成と標準のリポジトリルールの設定
- (GitHub Actonsなどの) CI/CDパイプラインの標準設定の導入
- カタログ情報そのものの作成
- ボイラープレートコードの用意
- クラウドリソース（Azure等）のプロビジョニング
- 品質評価ツールやセキュリティスキャンツール等への登録
こうしたことを各開発者が手動で行うと、設定の漏れや「野良サービス」の発生原因になります。 テンプレートはこれらを 「ゴールデンパス」 として自動化します。
開発者体験の向上
カタログは、開発者が「作る」作業に集中するための基盤（ゴールデンパス）への入り口となります。
ここまで述べてきたように、集約された 情報から必要となるものを発見 し、 そこから 作業に必要となる情報に効率的にアクセス できるようになります。 また「テンプレート機能」により、 簡単に 標準を適用 することも可能となります。
こうしたカタログには、ログ等のモニタリングツールや実行環境ステータス確認ツール、 品質評価ツール等、ソフトウェアの開発・運用に必要な様々なツールへのアクセスも集約されます。
さらに作成したソフトウェアを、組織内の他の開発者に公開し利用してもらうことも容易に 実現できます。
このように、開発者が担うすべての開発プロセスの作業が開発者ポータルからアクセスすることが できるようになるため、 開発者体験（DevEx） も向上するのです。
組織の地図としてのカタログ
このように内部開発者ポータルにおけるカタログ化は、いわば「組織内ソフトウェア資産の地図」の ようなものです。目的地（開発目標）に最短距離でたどり着くための地図がなければ、 開発者は迷子になり、生産性は低下してしまいます。 カタログ化の真の価値は「登録すること」ではなく、登録された情報を元に 「アクション（デプロイ、修正、問い合わせ）を素早く起こせること」 にあります。
ソフトウェアカタログを実現する IDP 「Backstage」
ここまで説明してきましたソフトウェアカタログを実現するのが先日ご紹介した 開発者ポータル 「Backstage」 です。
Backstageに関してはこれまでにも数多く紹介してきたので、皆さんご存じだと思います。 もしご存じない方はぜひこれまでの記事をご覧ください。
いかがでしたでしょうか。ソフトウェアカタログの重要性についてご理解いただけましたでしょうか。
なお、今回の記事は私自身の考えをベースに Geminiとディスカッションしながらまとめさせていただいたものです。 イメージはGeminiの Nano Bananaを用いて作成させていただいております。 記述に人間臭さがないのはこうした作業の影響かと思いますが、できる限りわかりやすくということを優先しこのような 形態とさせていただいています。皆様の参考となる内容になっていましたらさいわいです。
最後に。
弊社では、Backstageのマネージドサービスである「PlaTT」 を提供しています。
開発者ポータルの前提となる Platform Engineeringの導入支援も行っております。
開発者体験を向上し、開発生産性を高めたいとご検討の皆様、ぜひ弊社までご相談ください。
