はじめに
こんにちは、ACS事業部亀崎です。今回は「開発生産性の壁」とその解決方法についてご紹介したいと思います。
開発生産性の壁とは
壁を見てみる
以下の図をご覧ください。
緑の線は開発者個人の生産性です。そして赤の点線は組織単位でみた場合の生産性です。
AIツールの登場により個人の生産性は、以前よりも高まっていると実感されているものと思います。 では、組織単位での生産性はどうでしょうか？ 実は組織単位でみると個人の生産性のようには伸びないと感じる方もいらっしゃると思います。それはなぜでしょうか？
従来からの壁、AI時代の壁
実はこうした個人と組織の生産性向上のギャップはAIだから発生しているというものではなく、以前から起きているものです。AIの登場によってそれがより早くより顕著に顕在化するようになったと考えられます。
まず従来から以下のような壁が存在していました。
- 組織内での「車輪の再発明」
- ベストプラクティスの散逸
- 組織内開発アセットの再利用の低さ（使えるものが見つからない）
- 組織間のシステム連携時のコミュニケーション負荷
- オーナーシップが不明確、だれが改善しだれに依頼すべきかが不明となり改善が進まず
- 開発標準、ツール標準の欠如（ツールの乱立）
- 多数のツールの利用による一覧性の欠如
これに加えてAI時代では以下のような課題も出ているものと思います。
- チーム・個人のサイロ化
- 自動生成依存による再利用やベストプラクティス共有などの活動の一層の低下
こうした要因が積み重なり、個人の生産性は高まるけれども組織レベルでみると高まらず、早期に頭打ちになるといった状況になります。
Backstageによる壁の解消
Backstage登場の背景
このブログをご覧いただいている方はもうすでにBackstageとはなにかをご存知かとは思いますが、あらためて簡単に紹介します。 （ご覧になられていない方はぜひ以下をご参照ください）
Backstageはオープンソースの開発者ポータルフレームワークです。組織内にある様々な開発アセットをカタログ化し、その開発状況やドキュメントを集約・表示するものになります。
BackstageはもともとSpotify社が開発したものです。
Spotify社では組織が拡大する過程で、組織単位で見ると生産性が頭打ちになっていたそうです。 ご想像いただけると思いますが、当然個人の生産性はとても高いにもかかわらず、です。Spotify社でこの原因を分析したところ、まさに前述のような「開発生産性の壁」が課題として浮き彫りになりました。これらの課題を解決すべく開発されたのがBackstageです。
世界の開発組織でも同様の現象が起きているに違いないと考えたSpotify社は、2000年にBackstageをCNCFに寄贈しました。以来多くの組織・開発者が活用し、機能拡張が続けられています。
Backstageの4つの価値
ではBackstageがどのように「開発生産性の壁」に対応しているかを簡単にご紹介します。
エコシステムの統合
さきほども述べたように、Backstageは組織内の開発アセットを様々な「カタログ」情報として登録し、それに関連する情報を表示することが主な機能になります。
DevOpsを実現している開発組織では、開発チーム内で数多くのツールを利用していることに気が付きます。例を挙げると以下のようなものがあると思います。
- コード管理
- Issue管理（GitHub Issues）
- CIツール（GitHub Actions）
- Pull Request （GitHub Pull Request）
- Dependabot
- Security Scan
- デプロイ管理
- HCP Terraformデプロイ
- Argo CDによるデプロイ
- Observability
- Alert一覧表示
これ以外にも多数ご利用になられていると思います。日々の業務ではこれらのツールのUIを表示して確認しているものと思います。確認対象となるリポジトリが１つであればそれぞれ見に行くこともできると思います。しかしそれが複数になってくるとどうでしょうか。それぞれのリポジトリごとに確認していくとかなり面倒ではないでしょうか。 特に高速な開発をしているシステムではマイクロサービス化などでリポジトリが増加する傾向にあります。このような状況確認をするコンテキストスイッチが多数発生するためとても大変な作業となってしまいます。
Backstageでは Pluginという機能拡張の仕組みを持っており、こうした各種ツールのポータルとして機能します。各種ステータスをこのポータル上で確認することができ、コンテキストスイッチを削減します。
ドキュメントや依存関係の可視化
APIとドキュメント
ある程度の規模になると、サービス間連携というものが重要になります。相手先サービスが組織内の別チーム開発であることも多々発生します。そうしたサービス間のインターフェースがどういった内容になっているのか、ひとつひとつ担当チームに確認するのも手間になりますし、相手チームの開発作業にも影響を与えてしまいます。 こうした場合に活用できるのが、APIのインターフェース定義とドキュメント公開機能です。サービス提供側チームが要したAPI定義と利用方法などを説明したMarkdownドキュメントをBackstage側で集約・表示します。これにより、利用者側はいつでも必要なときにその内容を確認することができます。担当チームへのコンタクトは本当に必要とされる状況だけとなります。
APIのインターフェース定義の表示
ドキュメント表示
関係性マップ
もう１つ依存関係の機能として重要なのが関係性マップ表示機能です。 今度は社内の各サービスから利用される側のチームの立場になって考えてみましょう。 担当しているAPIを利用しているのはどこのサービス／機能でしょうか。利用者側のサービスを開発しているチームはどこでしょうか。そのサービスのそのまた先はどういったものでしょうか？例えばAPIの中身を変更したい、大幅なバージョンアップを考えているなどのケースでは影響範囲などを考慮するためにこうした情報が必要になると思います。
Backstageでは保持しているアセット情報の依存関係を保持することができます。この機能を活用するとAPIを利用指定するサービスはどれか、そのオーナーはどのチームか、その先のサービスの有無などもグラフとして表示することができます。
オーナーシップの明確化
Backstageでアセットを登録する際、そのオーナー（個人又はグループ）を指定する必要があります。そのアセットのオーナーシップが絶えず明確になっていることで、そのアセットの管理者（オーナー）が不明になるといったことも防止できます。 オーナーがどういったアセットを保持しているか、といった情報も簡単に表示することができるので、管理上のオーバーヘッドが削減できます。
インナーソース文化
Backstageのようなアセット管理ツールを有効に活用することで、ライブラリやベストプラクティスなどの共有なども促進することができます。組織内のアセットを誰もが利用でき、かつ意見等も出せる状況にすることで、組織内の車輪の再開発も低減でき、かつ改善活動にもつなげることができます。
導入結果
以上のようなBacktageが提供する4つの価値でSpotify社では「開発生産性の壁」を解消できるようになり、組織単位の生産性も向上しました（以前に比べ55％改善したとの報告もあります）。
最初にあげた課題がBackstageのどの価値で解決するかマッピングすると以下のようになります。
| 課題 | 解決策 |
|---|---|
| 組織内での「車輪の再発明」 | 「エコシステムの統合」 、「APIとドキュメント」 |
| ベストプラクティスの散逸 | 「エコシステムの統合」 、「APIとドキュメント」 |
| 組織内開発アセットの再利用の低さ（使えるものが見つからない） | 「APIとドキュメント」 |
| 組織間のシステム連携時のコミュニケーション負荷 | 「APIとドキュメント」、「関係性の可視化」、「インナーソース文化」 |
| オーナーシップが不明確、だれが改善しだれに依頼すべきかが不明となり改善が進まず | 「オーナーシップの明確化」 |
| 開発標準、ツール標準の欠如（ツールの乱立） | 「エコシステムの統合」 |
| 多数のツールの利用による一覧性の欠如 | 「エコシステムの統合」 |
| チーム・個人のサイロ化 | 「エコシステムの統合」「インナーソース文化」 |
さらにAI時代への対応も万全です。Backstageは開発者ポータルを実現するフレームワークであるため、非常に拡張性に優れています。様々な機能を世界中の開発者が開発・公開しています。生成AIに関連する機能ももちろん開発が進んでいます。
時代にあわせ様々な機能で開発生産性の向上に寄与する、それがBackstageになります。Backstageがあれば、これまでの「開発生産性の壁」だけでなく、これから登場するであろう壁にも対応していくとが可能になります。
最後に
Backstageには他にも開発者の認知負荷を低減する様々な機能が存在します。その効果も使い方次第でより大きくなります。 ご興味のある方がいらっしゃいましたらぜひ弊社までご連絡ください。よろしくお願いします。
www.ap-com.co.jp www.ap-com.co.jp
また、弊社では開発者ポータルBackstageのマネージドサービスである「PlaTT」も提供しております。 Backstageに興味があるという方もぜひご連絡をいただけると嬉しいです。
それでは次の機会にまたお会いしましょう。
