はじめに
こんにちは、ACS事業部の大久保です。 今回はBackstageの成り立ちから見た、組織の安全なスケーリングの実現について書きたいと思います。 すべての企業において、安全な組織のスケーリングの実現とは理想であるとともに、属人化や人材育成など様々なボトルネックによって阻まれることが多く、企業にとっての大きな課題であると考えております。
Spotifyが今日の成功を築くにあたり、これとどう向き合ったのかの軌跡がBackstageの開発において残されており、彼らはBlogとして公開したり、OSSとして自分たちの成果を公開することによってそれを伝えようとしております。 今回はまずは
- Backstageの３つのユースケースについての紹介
考察として
- 3つのユースケースをハンバーガー屋さんに置き換える -現場作業者の違いから生まれる情報集約の２つのアプローチ
という流れでBackstageによる安全な組織のスケーリングについてお話ししたいと思います。
Backstageの３つのユースケースについて
組織スケーリングのボトルネック
一般的に創業初期において、少人数の連携が取れたチームではスピードと品質を両立することが多いと思いますが、事業の拡大に伴いそれらが大きく低下することがあります。
私は以下のような原因があるのではないかと考えます。
- 事業拡大の際にビジネスモデルや業務情報、仕事の手順が明文化されずメンバーの頭の中やメモの中に閉じられた。
- 中核となる少数のメンバーでコミュニケーション中心で低コストで意思疎通ができたが、メンバーやステークホルダーが増えたことによりドキュメンテーションコストが膨大になっていった。
- 中核となるメンバーが新しいメンバーのオンボーディングやレビューを行うために負担が増えた。
- 組織の拡大に対応するために情報やリソースに対する権限管理や承認などのプロセスが煩雑になり、業務の滞留が生まれた。
これらはIT企業に限らず一般的な組織でも見受けられることで、これらを一般的な組織課題としたときに、Spotifyがどのように整理し対処したのかを掘り下げることでBackstageの背景にあるPlatform Engineeringが普遍性が共有されるのではないかと思います。
Backstageにおける三つのユースケース
Backstageには、ソースコードやクラウドインフラのテンプレート機能やシステムのリソースの状態の可視化やプラグインの連携によるリソース管理、ナレッジのシェア機能など様々な機能群がありますが、これらは主にSpotifyがBackstageのキーとしている３つのユースケースに大別されます。
| 名称 | 概要 |
|---|---|
| Create(作成) | 開発者がソフトウェアを作成するために必要な営み。コードを書いたり、オンボーディングしたり、インフラを用意など。 |
| Manage(管理) | ツールと連携しシステムや各リソースの各情報を集約や管理を行う。 |
| Explore(調査) | システムや各リソースの情報検索や文書共有を行う。 |
彼らが３つのユースケースを導いた経緯
彼らのブログによると規模を拡大し続けながら製品開発のスピードを維持するという課題について、内部でのユーザーリサーチしたところ、文書化されていない組織的な知識がシステム開発を妨げていることが指摘されたことがきっかけとして挙げられています。
Rolling back the clock just a few years, Spotify was challenged to continue to scale our engineering team (and the number of features and components built) but retain the speed of product development. Some user research with Spotify developers highlighted a clear problem: there was simply too much non-documented institutional knowledge needed to get things done. No one could find anything and everyone was interrupting everyone else trying to figure things out.
また、当時開発チームが置かれていた課題を感じる場面として以下のようなものが挙げられます。
① 既存のメンバーが新しいメンバーに素早く作るだけでなく、最善の方法があることを伝える必要があった。
② 各開発チームは急拡大で変化が激しい中でも、自分たちのシステムの構造や設計を頭に描き続ける必要があった。（運が良ければ情報を追跡しているスプレッドシートが見つけられた。）
③ 違うチームが同じものを作る二度手間を防ぎために、他のチームやサービスの開発状態に目を光らせる必要があった。
They not only needed to build software quickly, they also needed to pass along knowledge to new joiners about how best to create new components. They needed to somehow maintain a mental model of the systems their squad owned. (Or, if they were lucky, they found a hopefully-up-to-date spreadsheet tracking this information.) They needed to keep an eye on what squads around them might be building to ensure they could reuse systems when they needed to solve similar problems in the future. In short, Spotify developers needed to continue building industry leading features at breakneck speed, while simultaneously maintaining a mental model for all the software at Spotify (oh, and help every new joiner develop that mental model as well!).
これらは３つのユースケースとマッピングすることができます。
| 場面 | ユースケース | 理由 |
|---|---|---|
| ① | Create(作成) | 新規メンバーのオンボーディングや開発着手する場面におけるリソースの作成課題。 |
| ② | Manage(管理) | システム設計やAPIの設計などリソースの管理する課題。 |
| ③ | Explore(調査) | 自チーム、他チームの管理するシステムやリソースの情報調査の課題。 |
３つのユースケースは相互に関連してるので切り取り方によっては、別のユースケースに対応する側面もあります。 Spotifyが定義した３つのユースケースを見ると課題を一般的なものと考えるために、ハンバーガー屋さんを題材にどういった課題や解決するための営みがあるかを考えてみます。
考察： 3つのユースケースをハンバーガー屋さんで置き換えてみる
安全に店舗をスケールをし続けているハンバーガー屋さんといえば、皆さんにスマイルと美味しいバーガーとポテトを届けるあのハンバーガー屋さんです。
企業名は出しませんが、モバイルオーダーをいち早く導入し、UberEatsとも密に連動したり、
店舗設計やドライブスルーの最適化も怠らない、あのお店をイメージして以下を記述します。
ハンバーガー屋さんのCreate(作成)
ハンバーガー屋さんがハンバーガー、ポテトなどのフードやドリンクを作るにはさまざまな工夫が凝らされております。
- フードを作り方や接客のための業務ルール研修の実施。
- フードを作るためのハンバーガーを焼くための機械やフライヤー、ジューサーを用意する。
- キッチン上に適切な導線を作る。
- 形式の揃った特注のフライドポテトや整形された特別なミートパティを用意する。
これらのために店舗や工場が作業をテンプレート化したり、人事がそれに対応するオンボーディングを行うことで作業しやすい環境を整えます。
これにより、美味しいフードが手早く手元に届きます。
ハンバーガー屋さんのManage(管理)
ハンバーガー屋さんが管理するリソースと言えば、フード、ドリンク、包装、椅子やテーブル、調理器具やドライブスルーなどの設備、それに人材を始め無数にあります。
これらを管理するためにはどのような営みがあるか考え例を挙げてみました。
- パティを焼いている時間を表示したり、ポテトが揚がったら独特の音を出す。
- フードや付録のおもちゃの在庫数などをPoSに表示したり、発注したりする。
- スタッフの勤怠やスキルなどの情報を表示する
などを始め無数の様々なリソースの管理をクルーが使いやすいようにデザインされたルールや設備によってオペレーションを最適化してます。
ハンバーガー屋さんのExplore（調査）
ハンバーガー屋さんは売上アップのために様々な情報を検索しています
- 商品の情報を表示する
- 新製品やキャンペーンの情報を検索する。
- 各商品の売れ行きをエリアや時期ごとに検索する。
- 出店計画のために、地域ごとの情報を集約する。
など、店舗や別のチームが持っている情報を検索し、それぞれのチームが合理的な判断を行う手助けをしていると考えております。
考察：現場作業者の違いから生まれる情報集約の２つのアプローチ
ご覧の内容は３つのユースケースを通じて、情報の集約しリソースの管理を効率化することで組織をスケールすることは、
一般的な話として捉えることができますが、同時に組織の情報基盤をBackstage、開発者ポータルは何故ボトムアップで作られてきたのかという疑問が生まれました。
そして、考えているうちに現場作業者の自律性というワードがハンバーガー屋さんとSpotifyとを比較したときになんとなく浮かんできました。
仮設：現場の自律性の有無がわける情報集約のアプローチ
以下にそれぞれの現場作業者の仕事の性質とサイクルの違いを表します。
| 現場 | 仕事の性質 | 仕事のサイクル |
|---|---|---|
| ハンバーガー店のクルー | マニュアルを順守し、品質の高く粒のそろったサービスを提供する。 | 定常業務 |
| 開発者 | 要件の実現に向かいルールに従いながら自律的に実現方法を考え、誤りを指摘することも求められる。多量の情報や組織が存在するため全体を把握することが難しく、現場じゃなければ知らないことも多く存在する。 | プロジェクトやプロダクトやサイクルに従う。（２週間から数か月、数年） |
これらを見比べると、開発者組織は以下の理由からトップダウンで情報集約することが難しく、必然的にボトムアップになったのではないかと考えました。
- 要求事項やソースコード、インフラそれを支える技術情報は開発サイクルの中で激しくアップデートがされるので中央が集約することが難しいです。
- 従って、情報集約のためには個々の開発者やチームが情報を持ち寄って１か所に集約、共有する必要があります。
- そのためには気持ちよく情報を共有したり、情報に基づく作業ができたりする仕組みが必要です。
- だからこそボトムアップで開発者のUXが高いポータルを作る必要があった。
開発組織に限らず
- 自律性が高く
- 非定常な業務で
- チーム間連携が求められる業務
においてはボトムアップアプローチでポータルを作ることが適しているのかもしれません。
ボトムアップで作る情報集約基盤がフィットしそうな業界
他に自律性の高く情報の変化が激しい、非定常な働き方をする産業を列挙してみると
- 新聞記者
- コンサルタント
- 証券マンやバンカー
- ファッションやデザイン
- エンタメ
- 資源系
- 商社
- 諜報機関員、インテリジェンス組織
- 科学
などはボトムアップでポータルを作るとうれしい業界かもしれません。
こうして並んでみると、MI6なんかはスパイポータルってありそうで各国に送った諜報員が情報集約したり、
可能な範囲について公開してたりしそうですね。
次回はBackstageのプラグインを見ながら各ユースケースについてどういった具体例があるか紹介したいと思います。
おわり
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
