インナーソースでイノベーションを加速する方法

はじめに

オープンソースはソフトウェアの開発方法に変革をもたらしました。世界規模の開発者コミュニティが作成した、無料の再利用可能なコードを使用して、ホテル予約から銀行業務までほぼ全ての新規アプリケーションが開発されています。Gartner によると、オープンソースであることに気付いているかどうかに関係なく、世界中の 87% を超える IT 企業がミッションクリティカルな IT ワークロードにオープンソースを使用しています。

一方で、プロセスは出力と同じくらい重要です。オープンソースコミュニティが開発と拡大を続けるなかで、地域、タイムゾーン、言語の枠を超えてスピーディかつ効率的にコラボレーションを行う方法が見出されました。オープンソースコミュニティは大規模な分散チームによってコードを開発し、分散型バージョン管理システムを業界標準へと押し上げただけでなく、現在の DevOps の基礎を作り上げました。Git や Python を使用している場合、またはチーム内でコードの共有や再利用を行っている場合は、オープンソースのベストプラクティスを実践していることになります。

DevOps でも見られるように、企業の開発チームがこうしたベストプラクティスを実践することで同じ速度とイノベーションを実現できます。オープンソースコミュニティのやり方を見習うことで、企業では自社の開発者に馴染みのある方法でソフトウェアを開発できます。さらに、使いやすく、注意力を阻害するような不要な要素がなく、スピーディなインクリメンタルイテレーションを通じたイノベーションに重きを置いた環境が実現されます。

ここまで説明してきたことは「インナーソース」と呼ばれています。オープンソース同様、この言葉をこれまでに一度も聞いたことがなくても、その原則の一部についてはすでにご存じのはずです。インナーソースの形は企業ごとに異なる場合もありますが、オープンソースのツール、プラクティス、文化を導入してプロプライエタリソフトウェアを開発するという目標は常に共通しています。

世界のオープンソースコミュニティの拠り所である GitHub では、インナーソースがもたらす影響をいち早く目の当たりにしてきました。たとえば、「2021 State of the Octoverse」レポートでは、コード再利用などのインナーソース原則に従ったチームの生産性が 87% 向上したという驚くべき成果が明らかになりました。このホワイトペーパーでは、Ford や 3M などの組織がインナーソースのこうしたベストプラクティスやその他のベストプラクティスを実践して速度の改善とイノベーションの加速を実現した事例、そして GitHub の活用方法について紹介します。

インナーソースの定義

インナーソースはさまざまな方法で説明されてきました。自社のエンジニアリングチームが連携してコードを開発するやり方を指す場合に、多くの企業が「インナーソース」という言葉を使っています。大規模なオープンソースコミュニティに以前から参加している組織内の開発者なら、インナーソースという言葉を一切使わないこともあります。こうした開発者たちは、オープンソースの方法論を現場のソフトウェア開発に応用する手段としてインナーソースをシンプルにとらえています。

インナーソースとは、大規模なオープンソースプロジェクトのベストプラクティスを実践してエンジニアがプロプライエタリソフトウェアを開発する開発方法論のことです。インナーソースのプラクティスを実践するのは、組織内でオープンソースコミュニティを立ち上げるようなものです。オープンソース同様、透明性の高いコラボレーションによってコミュニティの知識とスキルが集約され、質の高いソフトウェアの開発へとつながります。対照的に、インナーソースコミュニティでは人の知識、スキル、能力、およびツールが一企業内に制限されたものになります。

インナーソースではオープンソースのベストプラクティスがもたらされ、誰もが参加したくなる DevOps 文化が実現されます。こうしたベストプラクティスには、コアチームに所属していない開発者とのコラボレーション、共有と再利用が可能なコードによる重複作業の削減、透明性の高いディスカッションとコラボレーションの促進、スピーディなイテレーションとフィードバックループなどがあります。これらを全て組み合わせると、カスタマーエクスペリエンスの向上や納品期間の短縮につながります。

インナーソースでイノベーションを加速させる 5 つの方法

チームとタイムゾーンの垣根を超えて背景を共有するコラボレーション

世界中にチームが分散し、リモートワークが当たり前になったことで、働き方にも変化がもたらされました。世界中のワークフォースをフル活用するには、本社からリビングのソファーまで、どこでも互いに協力しながら、透明性が高く開かれたやり方で働けるようにする必要があります。さらに、組織では居住地に関係なくその仕事に適した人材を採用することで、よりインクルーシブかつ柔軟な採用方針を導入する必要があります。

Zendesk のグローバルオフィスが好例として挙げられます。同社では特にエンジニアリング面において透明性を重視しているため、コペンハーゲン在住のエンジニアでもサンフランシスコの業務を理解して活用できます。Zendesk のエンジニアリング担当 VP である Jason Smale 氏は、チームの社内環境がオープンソースプロジェクトと似ていると説明しています。つまり、自社のエコシステムでメンテナーとコントリビュータが協力し合うのです。

プロジェクトの担当を明確に文書化することで、各チームは素晴らしいアイディアを排除することなく、さまざまなワークストリームの混乱を管理できます。Zendesk では、どのチームのどのメンバーでも既存の作業で貢献、開発、再利用を行えるようにすることで、自社の知を結集した力を活用しています。「当社のエンジニアリングカルチャーは開かれたものであり、チームでサービスを担当し、本番環境での運用に責任を持つことに重きを置いています」と Smale 氏は説明します。

Spotify でも、責任を分かち合うことがコード品質とコラボレーションの面で重視されています。「オープンな環境と責任の両方が重要です」とプロダクトマネージャーの Laurent Ploix 氏は言います。特定のプロジェクトに対してチームに責任を持ってもらうことで、自分たちの業務に対してさらに誇りを持ってもらえるようになります。また、変更の承認において個人またはグループで最終決定できるため、意思決定が簡素化されます。「強い責任感を持つことで、使われているかどうか誰も知らないコードが積み上がっていくのを回避しています」と Ploix 氏は言います。一方で、担当者以外にも改善案の提案を許可、推奨することで、バグが見つかる可能性が高くなり、プロジェクトで革新的な新機能が生まれるようになります。また、Ploix 氏が言うように、担当者よりもそれ以外の人の方がより良い解決策を見つける場合さえあります。

インナーソースではチーム間の連携が強化されるだけでなく、距離と時差の壁を超えた、時間をずらしたチームの働き方が可能になります。これはあらゆる組織においてますます重要な要素となっています。「GitHub のおかげで遠く離れた人たちとのコラボレーションが可能になりました。プルリクエスト内で多くのディスカッションが行われています」と Deliveroo のシニアソフトウェアエンジニアである Erika Moreno 氏は説明します。シニアソフトウェアエンジニアである Florian Thomas 氏のチームでは現在、機械学習モデルを記述するデータサイエンティストの協力を得ており、GitHub 上でこのデータサイエンティストを新しいバージョンに簡単にリンクできています。「同じアクセス権を持っているため、作業についていくのも簡単です」

チームメンバーがさまざまな場所や地域に分散している場合でも、GitHub とインナーソースでは Otto Group などの国際組織に「共通言語」を提供してコードとリソースを共有できるようにしています。GitHub を信頼できる情報源として利用している Otto Group では、18 の子会社で一歩進んだインナーソースプログラムを実施しています。「コラボレーションの新時代を体現した、グループが一丸となった変革プロセスによって開発が進められました」と Otto Group のテクノロジー戦略、ガバナンス担当 VP である Hanna Huber 博士は述べています。

さらに、インナーソースで見習われているオープンソースコラボレーション同様、最初からスケーラビリティが意識されていました。Engie のツールおよび CI/CD 責任者である Jean-Hervé Laveau 氏によると、インナーソースイニシアティブによって「拡大のためのキャパシティ、知識、ソースの共有」が促進されたとのことです。従業員が 70 か国に分散している Engie では、開発者が世界規模で共有を行うことができます。

GitHub からのヒント: タイムゾーンの壁を超えて業務を進めるために、GitHub をコラボレーションプラットフォームとして利用し、GitHub Issue とプルリクエストで非同期的にアイディアのディスカッション、変更、レビューを実行しましょう。詳細情報

顧客に新たなアイディアをスピーディに提供

誰もがプロジェクトに参加できるようにすることで、より多くのアイディアが集まってきます。さらに、チームではコード品質の向上、プロセスの効率化、本番環境へのリリースまでの期間短縮を実現できます。Ford のグローバルソフトウェアツールおよびプロセス担当スーパーバイザーである Tom Erickson 氏は、コードに関するアイディアだけでなく、プロセスや働き方に関するアイディアもより多く集まる点をメリットとして挙げています。「開発者は提案を行い、よりオープンかつ自分のニーズに合った働き方を採り入れることができます。「より質の高いソフトウェアをより早く出荷するには、インナーソースが理にかなっています」と同氏は言います。

インナーソースではスピードとイノベーションを両立できるため、GitHub のようなプラットフォーム上でコードを共有すると開発者と顧客両方にメリットがもたらされます。たとえば、DXC ではアプリケーションを短期間で開発 (市場環境が急速に変化する現代においてはこれが特に重要になります) しており、開発者は自身が作成した全てのコードを一元管理しています。ある同僚が Web テスティングフレームワークの Cypress について疑問があった際、自社の GitHub を検索するだけでそのテクノロジーに関する社内エキスパートを見つけられたと DXC のテクニカルリードである Tom Halpin 氏は述べています。「おかげで DXC 社内に眠っていた知識を活用できるようになりました」と同氏は言います。

DXC のフェローでモダンアプリケーションおよびクラウドネイティブ担当 VP 兼 CTO の Chris Swan 氏は、これまでなら 6 か月かかっていたであろう製品開発が 6 週間で済むするようになったと述べています。「家造りに例えると、家を建てる前に基礎をしっかり固めておくべくだとお客様は考えています。しかし、『基礎はすでにこちらで用意したので、あとは資材をくみ上げるだけです』と提案できるようになりました」。その結果、DXC の顧客は市場投入期間を短縮して競争力を上げることができました。

複数の部門と子会社がある Otto Group や 3M のような組織では、インナーソースによって、顧客だけでなく開発者も社内のソリューションとテクノロジーにスピーディにアクセスできるようになりました。「一度作ってしまえばあとはたくさんの人に使ってもらえます」と Corporate Research Systems Lab (CRSL) のリード DevOps エンジニアである Kevin Truckenmiller 氏は言います。3M では数え切れないほどの部門で Docker コンテナを使用しており、AWS で開発を行っています。全員に AWS へのアクセス権が必要になるため、数千におよぶ AWS 認証情報の管理も必要になります。GitHub を利用する前までは、部門ごとに独自の認証情報管理ツールを作成していたため、同じ目的のために複数のツールが存在していました。そこで、チームが自社の企業ディレクトリの認証情報を使用して AWS アカウントにアクセスできる共通ツールを CRSL では作成しました。その結果、チームでは簡単にプルリクエストを開いて、GitHub リポジトリからツールのコードをダウンロードして使用できるようになりました。「重要なのは速度です。機能を開発してもらえるかどうかを尋ねる代わりに、プルリクエストを開いて自分自身で機能を追加できるのです」と Truckenmiller 氏は言います。こうしたセルフサービスモデルによって、他の人に頼らなくても作業を進められるようになります。

それでも、インナーソースが成功するかどうかは、トップスピードの維持と重要なステップを飛ばさないことのバランスをうまく取れるかどうかにかかっています。チームの拡大に合わせてプロジェクトの速度が落ちないようにするには、よく考えられたプロセスとドキュメントがいずれも同じように重要になります。たとえば、Stripe では従業員どうしがお互いのコードを協力し合って開発していますが、誰が開発したコードでも必ず同じレビュープロセスを経ます (さらに、GitHub Advanced Security のコードスキャンや文法チェッカーなどの自動化ツールを使用すれば、このレビュープロセスをスピーディかつ効率的に進めることができます)。コードへの貢献とレビューを文書化することで、各コントリビュータは次に何をすべきか気にする必要がなくなり、プロジェクトの条件に従いやすくなります。スムーズに貢献できるようになることで、「修正が必要なものを見つけたら、プルリクエストを提出してディスカッションを開始できます」と Stripe のデベロッパーアドボケートである Michael Glukhovsky 氏は感じています。

GitHub からのヒント: README ファイルと CONTRIBUTING ファイルをリポジトリに追加することで、コードベースに関する重要な情報と参加方法をコラボレーターに周知しましょう。詳細情報

チームの垣根を超えたコードの検索と再利用

ここで、プロジェクトでよく見られる事例を 1 つご紹介します。あなたが所属するチームで製品用の新たな UI パターンを計画、設計、実装したとしましょう。この UI パターンは実用に耐え効果的で、数か月におよぶイテレーションで完璧なものに仕上がっています。しかし、別のチームが単独で開発した類似機能のプルリクエストを偶然発見することになります。このような場合、あなたのチームで開発したコードを別のチームのコードにもある程度使えただけでなく、製品のユーザーエクスペリエンスに不整合が生じる結果にもなります。フィールドテスト済み機能の調整と再利用は行われたようですが、コードを他のチームが検索できるようにはしなかったようです。

ENGIE Digital のインナーソースプロジェクトリードである Florent Zara 氏が[インナーソースの目標]としていたのは、サイロを解消してコラボレーションを促進することでした。インナーソースのおかげで誰もがプロジェクトに参加できるようになり、組織内でのコードの検索、再利用、開発が容易になったと同氏は言います。デジタルコミュニティおよびコミュニケーション責任者の Charline Grenet 氏もこれに同意しています。「再利用のためにあらゆる業務を産業化する必要があります。プロジェクトを完全にインナーソース化したいと考えています」と Grenet 氏は言います。

Autodesk や Ford などの大企業でもインナーソースはその効果が証明されています。GitHub などでコードを一元管理することで、コードが検索しやすくなると Ford のチーフエンジニアである Florian Frischmuth 氏は感じています。「当社の環境では、開発者は既に開発済みのソリューションを探すことができます。そうしたソリューション上でコラボレーションを行い、ソリューションを再利用することができるのです」

これまでは、既存のソリューションではニーズの 90% までしか満たせなかったために、Autodesk のエンジニアはソフトウェアの複数なコードを何度も開発していたと開発プラットフォーム担当シニアディレクターの George Swan 氏は言います。ブランチをコピーして自分のものにした後、足りない 10% を補っていたのです。現在では、従業員が Autodesk の知的財産のほぼ 100% にアクセスできるようになっています。19,000 個あるリポジトリのうち、非公開になっているのは約 10 個だけです。「当社では誰でもプロジェクトに参加できます」

コードの共有と再利用を通じて、インナーソースや DevOps のベストプラクティスが生まれたオープンソースコミュニティを再現しているチームもあります。Spotify では、プロジェクトを担当する開発者がオープンソースメンテナーのような役割を担っています。開発者が新しいバグやアイディア、コードの受け付けとトリアージを行っているのです。さらに、プロジェクトの廃止だけでなく、アーカイブを担当する場合さえあります。「開発者が文字どおりメンテナーになっているのです。強い責任感を持つことで、使われているかどうか誰も知らないコードが積み上がっていくのを回避しています」と Ploix 氏は言います。

GitHub からのヒント: Enterprise アカウントでは、組織内の全 GitHub リポジトリに対してデフォルトの権限レベルを設定できます。デフォルトのリポジトリ権限を全員か「none」に設定することで、開発者がコードを簡単に見つけて共有できるようにしましょう。詳細情報

コード品質とセキュリティの向上

「オープン」であることと「安全」であることを両立するのは容易なことではありません。オープンソースを利用してソフトウェアをリリースする開発者が増えるなか、ソフトウェアチームが最初からセキュリティを優先することがこれまでにないほど重要になっています。実際のところ、__コラボレーターが多いほどバグや他の問題を見つけられる可能性が高くなると企業のチームでは感じています。さらに、このアプローチではセキュリティの専門知識をプロセスに早い段階から採り入れることができるとも感じています__。

Nationwide ではかつて、チームが自分たちだけでプロジェクトを進めていました。しかし、少なくとも社内では誰でも参加できるようにすることが、質の高いコードを大規模に作成するうえで必要不可欠であることが証明されました。プロジェクトチームでは、外部の視点を採り入れることでメリットが最も得られることが多いにもかかわらず、それを行うのを一番ためらっていたと Nationwide の IT アプリケーションサービス担当アソシエイトバイスプレジデントである Cindy Payne 氏は説明します。このプラクティスを実践することでセキュリティの脆弱性にも対処できるようになった結果、チームで影響を素早く評価し、それに応じて状況のトリアージを行うことができるようになりました。

インナーソースが企業のファイアウォールの中で行われることもありますが、スケーラビリティは常に最優先されています。「3M のコアバリューは必ずしも自社のことだけを考えたものではありません。自社以外のことについても深く考えています。知的財産を保護したいと考えていると同時に、同じ問題を 5 つの方法で解決したいは思っていません」と Truckenmiller 氏は言います。よりオープンなインナーソースモデルに移行することで、1 つのソリューションを複数の研究者と共有し、消費者にまで波及する影響をもたらすことができます。「当社ではさらに開かれた環境へと移行を進めています。その結果、官僚的でプロセスに基づいた文化ではなく、コミュニケーション文化とジェネレーティブな文化が生まれることになります。

「GitHub だけでなく、他社の専門知識を通じてクエリベースは拡大する一方です。おかげで、現在静的解析だけであっても、得られるメリットの可能性がはるかに広がります Postmates、スタッフセキュリティエンジニア、David Ross 氏

GitHub からのヒント: セキュリティは、セキュリティチームだけでなく全員で背負うべき責任です。コードスキャンアラートを有効にすることで、開発者は新しいプルリクエストを開くたびにセキュリティ問題を見つけて修正できるようになります。詳細情報

セルフサービスによる時間の節約とイノベーションの加速

新規プロジェクトの開始に関しては、今でも多くのチームが「リクエストを起票してそれが承認されるまで待つ」モデルに従っています。リクエストを起票すると、本社の管理者が新しいリポジトリをスピンアップするのです。このモデルでは、管理上の維持管理と新しいことへの挑戦に対する障壁によって、本来であればシンプルにできるプロセスがより複雑になります。一方、インナーソースでは誰でもスムーズにプロジェクトを開始できます。

チームで自分たちのプロジェクトを作成できるようにするとかえって仕事が増えるように見えるかもしれません。また、あらかじめ新しいプロセスを文書化したうえにガバナンスモデルを作成する作業が困難に感じる場合もあるでしょう。しかし、結局はセルフサービスモデルによって維持管理にかかる時間が節約され、開発者が簡単に作業を始められるようになったと多くのチームが感じています。

セルフサービスの GitHub リポジトリによってプロセスがスムーズになっただけでなく、インフラストラクチャの観点から自社の時間とコストが節約されたと Payne 氏は感じています。モデルの切り替えについては、「コストが削減されることはわかっていましたが、それがすぐにチームのキャパシティ増加へとつながり、当社のビジネスにとって最も重要な業務に集中できるようになったのは予想外でした」と同氏は述べています。

Continental や Ford などの歴史あるメーカーでも、障壁をなくすことで新たなアイディアがどんどん生まれるようになったと Continental のインナーソースプロジェクトマネージャーである Zsuzsanna Gnandt 氏は説明しています。「インナーソースによって、全ての開発者が想像力を自由に発揮し、スムーズにイノベーションを推進して企業に対する貢献に感謝される環境を実現したいと考えています」

Ford では社内の誰もが自社のコードにアクセスできるようになったため、組織的な構造による分断はなくなり、協力してコードを新たに作成し、既存のソリューションを最大限に活用できるようになりました。「当社の環境では、開発者は既に開発済みのソリューションを探すことができます。それをベースにコラボレーションを行い、再利用することができるのです」とチーフエンジニアの Florian Frischmuth 氏は言います。

GitHub のコラボレーションプラットフォームとオープンソースコミュニティとの確かなつながりを活用することで、Spotify の開発者たちは社内のインナーソースと非 IP 業務のオープンソース化という 2 つの世界をフル活用しています。

ファイアウォールの内外で数千人ものコントリビュータが数千にのぼるアイディアを出しあうことで、思考の幅が大きく広がって最終的に優れたカスタマーエクスペリエンスが実現されます。「プルリクエストは大歓迎です。担当者よりもそれ以外の人の方がより良い解決策を見つける場合さえあります」と Ploix 氏は言います。

GitHub からのヒント: 全員が一丸となって貢献することで、パブリックリポジトリとプライベートリポジトリで開発者のイノベーションを高く評価しましょう。開発者の GitHub Enterprise アカウントを GitHub.com アカウントと連携することで、開発者の努力が公に認められるようになるだけでなく、コラボレーションの機会が生まれ、新たな人材とツールが発掘されます。詳細情報