Backstageで始める新たな開発者体験

Transcript

普段私の仕事としては、AzureとKubernetesを使ったお客様のインフラ作りというか、メインの仕事になっています。

続いて弊社の簡単な紹介となります。我々APコミュニケーションズ、業態としてはSIerにはなるんですけども、ただお客様のシステムを言われた通り作るというだけではなくて、そういった旧来のSIビジネスから脱却するために、お客様の内製化あるいは自動化の文化を支援していく、ネオSIerと名打ちまして、お客様のご支援をさせていただいております。

もちろん旧来のSIerと同じように、お客様のシステムを作るというようなこともやっているんですけども、ただシステムを作るという形で終わるのではなくて、お客様の中で文化を作っていくというところのご支援をさせていただいているというような会社になっております。

タイトルにありますBackstageの紹介をしたいと思ったんですけど、まずPlatform Engineeringとは何かという話をしようかなと思って資料を準備してきたんですけど、正直草間さんの先ほどのセッションと内容だだかぶりなんですよね。ただオンラインの方とかお仕事とかあってね、今から見ている方もいらっしゃるかもしれないので、さっき聞いたぞという人もいると思うんですけど、改めておさらいです。お話しさせていただきます。

Platform Engineeringが始まる前に、前の時代のことをちょっと振り返ってみたいと思います。いわゆる昔ながらの組織って、開発であったり、インフラ部隊とかQA品質の部隊であったりとか、保守運用のチームってみんなチームが分かれてました。なのでプロダクトの開発からどんどん作っていくというフェーズの中で、各チームの中で依頼をして実行するというようなやりとりが挟まっていて、非常に効率が悪い、サイロ化した組織の欠点が出ているというところがありました。

それを解消するために、それぞれの役割を一つのワンチームにまとめるDevOpsという概念、これはもう皆さんご存知の話かなと思っております。じゃあDevOps、本当に皆さん幸せになったのかというと、決してそうではない側面もあると思っています。いろんなロールの方をワンチームに集めたことで、当然それらの人たちがやってきたことを全部ワンチームの中でやらなきゃいけないという、逆に負担が増える分大きくあったかなと思います。

アプリケーション開発の中で、新規の機能追加でバグ修正というような作業だけではなくて、それのCICDを考えなきゃいけない、インフラを作るIaCを考えなきゃいけない、Kubernetesを使っているんだったら定期的にKubernetesのクラスターバージョンアップしていかなきゃいけないですよね。アプリのデプロイにはHelmチャートを書かないといけない、インフラのアプリの監視をどうしていこう、また新しいメンバーが入ってきたらオンボーディングもやっていかなきゃいけないですよね。

そんな形でDevOpsチームの認知負荷というのは、どんどん高い状態になってきています。そういったお仕事面のところというのと、あとやっぱり世間のクラウドネイティブ技術って特に発展スピードが速いというので、これ今表示しているのが皆さん大好きCNCFのランドスケープ。こんなにいろんなソフトウェアが出ていて、我々がやりたいことに対して何を使っていったらいいのか、選定も考えなきゃいけないですし、それらの技術を使っていくということにも頭を悩ませなければいけない。非常に認知負荷が高まっていく一方というのが今の世の中です。

そんなDevOpsチームってありますけど、当然できる人がいるんですよ。先ほどの草間さんとか青山さんみたいなスーパーエンジニアの方がいらっしゃれば、それを別に苦もなく乗り越えることもできると思います。ただ世の中の皆さん、そんなにスーパーマンばっかりじゃないです。私と同じような凡人の方もたくさんいらっしゃると思います。

なので組織の中で、会社の中で最初に立ち上げたDevOpsプロジェクトというのは、場合によってはうまくいくかもしれません。それを他のプロダクトを作っていく、新しいチームを作っていくとなったときに、本当にそれがスケールするんですかという問題かなと思っています。このような形でプロダクトごとに、またDevOpsのチームをポコポコ作っていくことによって、逆に先ほどのロールベースの再サイロ化ではなくて、プロダクトベースの再サイロ化というのがまた起きてしまう。時には各チームが同じようなことをやりたいというので、車輪の再発明みたいな、他のチームでは作っているものと同じようなものを作っていくというような非効率が出てきてしまうというのが欠点かなと思っています。

それを解消するために出てきた概念というのが、Platform Engineeringだと我々は考えております。複数のDevOpsチームが持っている、本来プロダクトの開発、プロダクトの価値を生み出す以外の、本質的ではないだけど必要な作業というのを切り出して、プラットフォームチームに集約する。プラットフォームチームが各DevOpsチームに対して価値を提供する、サービス提供する形に変革していくというのがPlatform Engineeringという考え方のベースかなと考えております。

それもチーム間のやりとりが、依頼を受けて作業するという形になると、やはりそのやりとりで時間がかかってしまう、効率悪い、また前の次第に戻ってしまうということになるので、そこはセルフサービス型で、サービス提供できるような形でやっていきましょうという考え方ですね。

ここでまたチームを分けていくというのは、もともとロールが分かれていた人は、私たちを一つのチームに集めて、DevOpsチームを作りました。じゃあまた分ける、再サイロ化された世界にまた戻っていくんですかというと、それは明らかにそうではない、NOです。もともと再サイロ化されたのが効率悪いというところから始まっていますし、なんでDevOpsやっていたのかというと、サービスの価値を素早くユーザー・お客様に届けること、これが目的です。これはPlatform Engineeringという文脈においても一切変わってないです。

その目的のために、どういうアプローチをしていくかというところで、プラットフォームチームは開発チーム・DevOpsチームを顧客と見立てて、顧客体験を向上させるため、開発者の認知負荷を低減させるために、どういったプラットフォーム機能が必要かというのを考えて、機能追加・改修をしていく。

再サイロ化するかどうかという話に戻しますと、プラットフォーム、どういったものが開発者体験を向上させるの、どういったものが認知負荷を低減させるのということを考えていくと、やっぱり開発チームとやり取りをして、対話しながら、どういったものが必要かというのを組み立てていく必要があるので、そこは完全に分断されたサイロではなくて、きっちりやり取りをして、どういったものが価値があるかというのを見出していく必要があります。とはいえ、開発の方があれも欲しいこれも欲しいというのを全部受け入れるのではなくて、本当に価値があると思うもの、プラットフォームチームがちゃんと選定をして組み立てていくというのが重要な概念かなと思っております。

草間さんの話の振り返りはこんなところで、草間さんのおさらいでもちょっとあったんですけども、IDPという話をさせていただきたいと思います。Platform Engineeringにおいて、IDPって大きく2種類あって、Internal Developer Platform、内部開発者プラットフォームと、Internal Developer Portal、内部開発者ポータル、この2つの概念があります。

その2つのIDPがないと、どうなっているかというと、先ほどの認知負荷が高いという状態と同じ話です。いろんなことを考えなきゃいけないので、何かやろうとしたときに、開発チームの人はいろんなところを見たりしないといけないというので、認知負荷が高い状態です。

それを解消するためのプラットフォームとしてのアプローチとして、こんな考え方で、ざっくり考えていただければいいです。複雑なプラットフォームを抽象化したプラットフォームを作って、それを操作するためのユーザーインターフェースを作っていく。その抽象化したプラットフォームをInternal Developer Platform、それを操作するためのユーザーインターフェース部分をInternal Developer Portalという形で、ポータルの部分もある意味プラットフォームの一部ではあるので、全体を指してInternal Developer Platformと言い方をするシーンもあるかと思います。この辺は明確な定義があるものではないので、我々としてはこう考えています、というものですね。

今説明したような内容を、こちらのスライドに入れています。IDPの、プラットフォームの方のIDPは、インフラの環境であったりとか、あるいはCICDであったりとか、アプリケーションを動かすための環境を抽象化したものと捉えてください。それらを操作するためのユーザーインターフェースが、ポータルです。

このInternal Developer Portal、内部開発者ポータルというものの代表的なプロダクトというのが、Backstageです。ようやくここでタイトルの話にやってきました。

Backstageは何かというと、もともとはSpotifyが開発した開発者向けのポータルのOSSの製品です。今はCNCFに移管されていて、インキュベーティングの段階にあるプロジェクトになっています。主な機能として、以下の5点が挙げられます、というところで、テンプレート、カタログ、TechDocs、あとKubernetes連携と、プラグイン機能、この5点があります。

それぞれどんなものかというのを見ていきますと、テンプレートということで、社内の標準の構成というのをテンプレート化しておいて、Backstageに登録しておきます。それを使って、プロジェクトを開始する。どんなことかというと、例えば皆さん新しく新規のプロジェクトを始めると、例えばREST APIのサービスを新しく作るよといったときに、ある程度社内で使う標準技術ってあると思うんですね。うちの会社はNode.js使ってますよ、うちはJavaですよ、どんな環境で動かすよ、ある程度パターンってあると思うんですよ。それぞれを新規のプロジェクトを始めるときに一から考えていくと、やっぱり時間がかかってしまうとしょうがないので、ある程度型にはめたテンプレートというのを初め作っておいて、それを登録しておく。新しくプロジェクトを始めるよという人は、このBackstageのテンプレートから必要なものを選んで、これ使おうと。クリエイトすることで、テンプレートを元にしたリポジトリができあがる、それを元にしたインフラが作られるという形で、スムーズに新規のプロジェクトを立ち上げるということができます。

続いてカタログ。これは社内のプロジェクト、サービス、アプリケーションを一覧化したものです。社内でどんなAPIが他のチームが作っているのか、自分が管理しているサービスも、特にマイクロサービスだと一つのチームが複数のサービスを管理している。それらを一覧化して管理しやすくする。あちこちのGitHubのリポジトリを見たりというのを防ぐために、一つの場所に集めて、ここからたどれるようにする。ステータスごとにフィルタリングもして見やすくするというのがカタログ機能になっています。

それらいろんなプロジェクトをやっていると、それぞれのプロジェクトごとにドキュメントというのがもちろんあると思うんですけど、それらのドキュメントもプラットフォーム上で一元管理するというのがTechDocs機能です。マークダウンのドキュメントをGitHubとかのリポジトリに置いておいて、それを表示するだけと言ってしまえばそれまでではあるんですけど、このBackstageのプラットフォーム上で検索したいというので、横断的にいろんなプロジェクトの情報を管理できるというところで、とりあえずBackstageを見ればいいという状態を作れるというようなものです。

あとKubernetes連携は、アプリケーションのデプロイ先にKubernetesを使っている場合であれば、このアプリケーションがデプロイされている状態を、Backstageの中で見ることができるというのが一つです。よくあるKubernetesの管理ツールだと、クラスター全体の状態を管理する、インフラエンジニアの方向けのツールが多いと思うんですけど、BackstageのKubernetes連携機能って、どっちかというとプロジェクトのアプリケーションがどういうデプロイされているか、クラスター全体の状態を見るんじゃなくて、アプリケーション目線で今Podが3つ動いてますよというようなものを見せる形の画面になっています。

あとプラグイン機能は、名前の通りではあるんですけど、Backstageの公式のサイトを見ていただくと、いろんなプラグインがいろんなベンダーであったり、個人の方、コミュニティが作って公開されているものがあります。ここから必要なものを選んで組み込んでいくことができるというような機能になっています。ただちょっと弊社内でも触っているんですけど、プラグイン機能というか、ポチポチっていったら導入できるのかなと思ったら、結構導入に複雑な手順が必要だったりして、この辺はまだまだ困っているかなというところがあります。導入に結構パワーかかりそうなサービスかなと思っております。

こういった機能があることで、Backstageは何ができるのって話は、一言で言うと認知負荷を低減させるためのサービスです。先ほど言ったように、新規のプロダクト開発を始める時とか、それが複数できてきて自分が担当しているサービスを管理する、あるいは社内全体のプロジェクトを管理する、ドキュメントもまとまってますので、新しく入ってきたメンバーの方に対するオンボーディングも、デプロイ後の運用管理、Kubernetesクラスターの状態を見るっていうのも、全部Backstageを見れば完結する。いろんなポータル見たり、Azureのポータル見る、AWSのコンソール見る、GitHubを見る、そんなようなですね、あっちこっち見ないと情報がわからないという状態を排して、Backstageを見ればとりあえず全部わかるっていう状態を作る。それによって開発チームが認知負荷を低減して、自分たちのやりたいこと、本来やるべきこと、プロダクトの価値創造というものに注力できるというのが、このBackstageの考え方になってます。

ただソフトウェアの宣伝をしてもしょうがないので、ちょっとここからですね、弊社の宣伝をさせてください。こういったコミュニティイベントで、あんまり宣伝って皆さんちょっと嫌がるかなって思うんですけど、冒頭話したように、今日の会場と、あと懇親会のフード・ドリンクのスポンサーやって、会社から金引っ張ってきてるんですね。これ入れないと、私会社から怒られちゃう。我慢していただければと思います。

弊社のサービス提供のコンセプト、冒頭申し上げたように、我々ただものを作るっていうだけじゃなくて、文化の変革というところも支援している会社です。軸としてはこの3つのトライアングルになってる、この3つです。一つにはテクノロジー。これはもう完全に我々のマンパワーを使って、お客様のシステム構築をお手伝いさせていただきます。それで終わるのではなくて、お客様の社内あるいはチーム内の開発プロセス、運用プロセスの変革のお手伝いをする、アジャイルプロセスっていうところと、さらにもっと踏み込んで、お客様の中の組織をどうあるべきかっていう形のコンサルティングですとかトレーニングさせていただくというところと、オーガナイゼーション。この3つの柱で今ビジネスをやっております。

今回このPlatform Engineeringというテーマで、我々が今サービスを作ろうとしているのが、Platform Engineering as a Service、お客様の社内のPlatform Engineeringを支援するためのサービスっていうのを今考えているところです。どういったことをやるかというと、まず最初テックのところですね。これはもう単純にIDP、IDP、2つのIDPですね。ポータルとプラットフォームそれぞれを我々が構築をご支援させていただきます。Backstageというインターナルデベロッパーポータルそのものの構築と、それに連なるインターナルデベロッパープラットフォームの方っていうのもご支援をさせていただくという形で、こうやって今図にしております。

我々はMicrosoft Azureのパートナーでもありますので、我々の方からプロバイダーという形でAzureのプラットフォームを提供させていただくこともできますし、冒頭申し上げたように我々のチームは今AzureとKubernetesを得意領域としているので、そういったところの環境構築のご支援であったりとか、それらを作るためのIaCであったり、データマネジメントというところのご支援ができるかなというところで、こういった構築のサービスを受け負っております。

それで終わってしまったらPlatform Engineeringではなくて、その先としてそのIDPを使ってどうやって行ったら効率が良くサービス提供できるかというところの、開発プロセスのご支援をさせていただくというのも次のステップとして考えております。これはどういったことをやるかというと、先ほどのテンプレートの登録というのを説明させていただきましたけれども、そこの初期テンプレートを作っているところのご支援、我々の方でよくあるお客様向けに提供しているテンプレートというのを、スターターキットというのを作っているんですけれども、そういったものをご提供させていただいて、まず最初にお客様が使い始められるような環境を作っていきます。それらをうまく使うためのSRE的な支援であったりとか、社内のDevOps推進というところにお力を貸して支援していくというものになっています。

さらにそこから踏み込んで、お客様社内のプラットフォームチームを作っていくというところで、組織編成のためのアセスメントとかコンサルティングをさせていただいたり、プラットフォームチームになる方向けに必要なトレーニングを提供させていただくというものも。これら3つの話をペアにして、Platform Engineeringアザサービスという形でご提供したいと考えております。

先ほどから考えておりますというのは、まだちゃんとサービスとして整っていなくて、本来であれば今年の後半ぐらい、バタンとリリースする予定だったんですけど、このミートアップ向けにちょっと急いで整えて持ってきた次第です。なのでちょっと細部のところは、これからまだ詰めていく部分もあるんですけど、一旦こんな形で我々Platform Engineeringのビジネスを始めていこうと考えております。

ぜひ今日の話に興味を持っていただいたら、登録フォーム用意しておいたので、ぜひこちらからお問い合わせいただければと思います。いきなり商談の話をすると重いよというのがあれば、まずは相談ベースとか、とりあえずディスカッションしようぜというのでも全然構わないので、ぜひ一度お声掛けいただければなというふうに思っております。

あとですね、弊社は技術ブログというのをやっているんですけども、そこでPlatform Engineeringとは何かみたいな記事ですとか、あと今日説明したBackstageの話なんかもブログの中に記事として載せていますので、よろしければこちらもご覧になっていただければと思います。webとかリンクとかで、APC技術ブログって検索すると出てくるので、よろしければぜひご覧になってください。

はい、ありがとうございます。以上で私のセッション終わりとなります。どうもご清聴ありがとうございました。ありがとうございました。