インナーソースとプラットフォームエンジニアリングの親和性
この記事は GitHub Pages で公開していたブログのアーカイブです
はじめに
インナーソース ( InnerSource ) もプラットフォームエンジニアリング ( Platform Engineering ) もみなさん聞きなじみありますか？
どちらの概念も Gartner 社の発表する Hype Cycle for Software Engineering 2022 において黎明期にある、と発表されています。
(なおプラットフォームエンジニアリングについては Emerging Technologies Hype Cycle 2022 においても同様に黎明期にあるとされています)
ここではこれら2つの概念の関係性について考えていこうと思います。
インナーソースとは
インナーソース ( InnerSource ) とは、オープンソースの原則を社内にも適用して実践する取り組みや、その活動によって生まれる組織文化のことを指します。具体的には、インナーソーシングの対象となるソースコードを社内で公開し、社員が内発的動機に基づいて協働できる環境を整え、組織間のコラボレーションを促進します。
より詳しくは インナーソースで始める組織内オープンソース開発入門 をご覧になることをおすすめします。
プラットフォームエンジニアリングとは
プラットフォームエンジニアリング ( Platform Engineering ) とは、セルフサービス型のプロダクト型プラットフォームづくりを促進する概念です。
プラットフォームエンジニアリングについて詳しく理解するためには プラットフォームエンジニアリング(Platform Engineering)とは？ 解説と考察、 Platform Engineeringへの招待 を参照することをおすすめします。
プラットフォームエンジニアリングは、セルフサービス型とは対極にある依頼型でプラットフォームを提供してきた（であろう）インフラエンジニアの方々の関心が強いような印象です。
実際、勉強会での事例でも IaC や k8s などで構成されたプラットフォームをベースに語られています。
しかし、プラットフォームエンジニアリングはインフラに限らず、 UI ライブラリやバックエンドの認証プロセスなど適用可能な領域が広い概念だと考えています。
プラットフォームエンジニアリングの成功とその先にあるもの
プラットフォームエンジニアリングにおいて難易度が高いのはプラットフォームの継続的な利用や価値向上でしょう。 プロダクト志向が重要であることは間違いありませんが、それだけではプラットフォームの維持は難しいと考えられます。 プラットフォームの価値が継続的に上昇すると、そのプラットフォームのユーザーは増えるでしょうし、 それに伴ってフィードバック数も増えることが予想されます。 フィードバックが少ないうちは迅速に対応でき、ユーザーを満足させることができますが、 フィードバックが増えると対応が追いつかなくなり、「プラットフォーム維持チームは対応が遅い」という評価を受ける恐れがあります。 いくらプラットフォーム維持チーム内でフィードバックに優先順位をつけて対応をしたとしても、上述の評価を避けるだけの開発速度を達成するのは難しいでしょう。 また、フィードバックへの対応が遅いと、本来プラットフォームとして提供すべき機能をユーザー自身がプラットフォームの外で機能追加をする可能性があります。 これは車輪の再発明となり得るだけでなく、「使わなくていいプラットフォーム」という評価にもつながる可能性があります。
しかし、プラットフォームエンジニアリングにおいては、多くのフィードバックを効率的に処理する方法がまだ十分に検討されていないと思われます。 現状では、ほとんどのフィードバックに対して「実装を検討します」「今期は立て込んでいるので来期実装します」というような返答をせざるを得ないのではないでしょうか。 そこで解決策の一つとして出てくるのがインナーソースです。
プラットフォームエンジニアリングを取り巻く協働の形
改めてインナーソースについて軽く解説をしますが、インナーソースとは、オープンソースの世界の価値観や考え方を組織内にも取り入れ、協働を促進する取り組みのことです。 特にサイロ化され分断された組織間のコラボレーションを促進することを目的としています。 このインナーソース実践により得られる組織間コラボレーションを利用し、プラットフォームに対する多くのフィードバックを効率的に処理しようというのが、プラットフォームエンジニアリングにおけるインナーソースの可能性です。
具体的には、プラットフォームのリポジトリを社内向けに公開し、寄せられるフィードバックを Issue として登録してもらいます。 そして、プラットフォームのユーザーにも、必要であればこの Issue に取り組んでもらい、プルリクエストを作成してもらいます。 もちろんコードレビューは必須ですが、こうすることでユーザーは多くを待たずして必要な機能をプラットフォームとして利用することができます。 プラットフォームという特性上、あるユーザーが必要としている機能は他のユーザーが必要としている可能性も高いはずですから、これは車輪の再発明の防止ともなります。
ここまでの話からプラットフォームエンジニアリングにおいても、プラットフォーム維持チームとユーザーは組織を跨ぐ関係性であることがわかります。 加えてこの提供者・利用者の関係性は潜在的に対立関係になりやすいでしょう。 そのためインナーソースを実践し、プラットフォーム維持チームとユーザーを提供者・利用者の関係性から協働の関係性に移行させていくことが重要です。
さいごに
インナーソースはプラットフォームエンジニアリングを実践し、価値を提供し続けるプラットフォームをつくるために必要な取り組みの一つだと確信しています。 とはいえインナーソースは多くの日本企業において実践のハードルが高く国内の事例もまだ多くありません。 InnerSource Commons コミュニティではプラットフォームエンジニアリングという観点に限らず、インナーソース実践者を増やす活動をしています。 興味がある方はぜひ Connpass のコミュニティページや Slack への参加をお待ちしています。
