インナーソースの概要

この最新のアプローチをソフトウェア開発に採用することは、コラボレーションを可能にし、高品質のコード記述を促進する変革となり得ます。しかし、それを成功させるには原則と潜在的な課題を理解することが欠かせません。

多くの企業では、自社のエンジニアリング チームが連携してコーディングする方法を指して「インナーソース」という言葉を使っています。インナーソースは開発方法論の 1 つです。エンジニアは Kubernetes や Microsoft の Visual Studio Code などの大規模なオープン ソース プロジェクトのベスト プラクティスを使用してプロプライエタリ ソフトウェアを開発します。

大規模なオープン ソース プロジェクトでは、数千人の関係者間の調整とチームワークが必要不可欠です。最も成功しているプロジェクトはユーザーの日常的なニーズであるスピード、信頼性、機能性に加えて、将来のビジョンに基づいて推進されます。このような大規模に運営されるプロジェクトからはいくつかの教訓が得られます。それを活用して、インナーソースを使用してより良いソフトウェアをより速く構築して企業に役立ててください。

この記事では、チームが日常のワークフローでインナーソースを使用し、オープン ソースのプラクティスを適用して効率的に協働する方法の基礎について説明します。

オープン ソース プロジェクトの特徴

GitHub には世界最大級のオープン ソース コミュニティがあります。このコミュニティが構築したものは数百万ものコントリビュータの関心とスキルセットを包含しています。コントリビュータたちはコードを記述するだけでなく、共に Apple の Swift などのプログラミング言語や Facebook の React.js などのフレームワークに取り組みます。データセット、公的文書などもオープン ソースとなり得ます。

オープン ソース ソフトウェアは誰でも使用できます。また、オープン ソース ライセンスで規定されているとおり、プロジェクトは任意の目的で表示、改変、配布できます。同様に、誰でもオープン ソース ソフトウェアの構築をサポートできます。通常、コード、フィードバック、バグ レポートなどを共有する、分散するコントリビュータのコミュニティによってプロジェクトは開発されます。

このようなオープンなコラボレーションのベスト プラクティスは、インナーソースの基本となります。これ以降、この記事ではいくつかの重要な教訓、ツール、用語について説明していきます。

オープン ソース プロジェクトの使用を開始してコントリビューションを行う方法の詳細は、GitHub のガイドを確認してください。

オープン ソース コミュニティから得た教訓

チームでソフトウェアを構築する場合、おそらく開発者は既に他のメンバーと協力して、または他のメンバーのオープン ソース プロジェクトに構築しているはずです。コミュニティにはタイム ゾーンをまたがってコラボレーションする方法、コントリビュータを集める方法、大規模かつ複雑なプロジェクトを管理する方法に関する教訓が豊富にあります。インナーソースのプラクティスを設定するにあたって留意する点をいくつか紹介します。

オープンなコラボレーションはコントリビューションを促す

コントリビューションが増えると、可能性も広がります。オープン ソース プロジェクトは世界中のあらゆるユーザーが変更できます。これは、プロジェクトの進歩、ユーザー ニーズの達成、バグの発見と修正に多くの知恵が注ぎ込まれるということです。

同様に、インナーソースでは多くのアイディアが集まります。チームはより簡単にイノベーションを実現できます。また、多くの開発者がコードにエラーや不整合がないかを検査することで、より安全で信頼性の高いソフトウェアを構築できます。不適切なユーザーが見つける前に問題を発見して修正できます。

開発者は必ずしもゼロから構築する必要はない

オープン ソース プロジェクトは、わずかな例外を除く全ての動機に基づいて、あらゆるユーザーが探して再利用できます。また、他のものを構築するために使用したり、自身の固有なニーズに適合するように改変したりできます。

同様に、インナーソースのコードはチーム メンバーが既存の社内プロジェクトを探し、カスタマイズし、再利用できるようにします。また、ドキュメント化された一連の共有プロセスを構築し、それをベースにして、企業がソフトウェアを導入、使用する方法に最適化できます。これにより、コスト削減、柔軟性の向上、ベンダー ロックインの終了につながる可能性があります。

透明性の高い意思決定がプロセス、信頼、整合性を築く

成功しているオープン ソース メンテナーは基本として意志決定を記録する。会話にはそれぞれ独自の URL を持ち、コメントの履歴から文脈を追えるため、タイム ゾーンが問題になることが少なくなり、開発者は円滑に、非同期的に作業できます。

プロジェクトをオープンにすることにより、組織の透明性が新しいレベルに到達します。コードだけでなく、その背景にある過程や意思決定を表示できます。会話が十分に記録されていると、分散しているチームに所属する開発者がすぐに構築を始められるようになります。オープンな環境で作業しているため、プロダクト マネージャー、設計者、セキュリティ チームなどがコラボレーションに参加している場合もあります。

重要なのは貢献すること

オープン ソース プロジェクトが成功するかどうかは「貢献」にかかっています。もともと、スキルを向上する、メンターを見つける、評価を築くなど、貢献の動機は多く存在します。しかし、プロジェクトのメンテナーは貢献を歓迎し、奨励するコミュニティ文化もつくる必要があります。

企業内では、ひとりひとりの開発者が自分の関心を追求し、公平な場でアイディアを共有し、チーム メンバーからより簡単に学びを得ることができます。しかしながら、インナーソースにも文化改革が必要です。チームの文化は、組織全体からの知識の共有を奨励し、貢献を歓迎するものである必要があります。

コア開発チームがプロジェクトのプロセスを強化する

オープン ソース プロジェクトには数千人ものコントリビュータおよびコミュニティ メンバーが参加している場合がありますが、通常、小規模なチームがプロジェクト全体の指揮を執る役割を担います。これにより、意思決定が迅速になり、責任者が常時いる状態を確保できます。

インナーソース プロジェクトでは、小規模な参加者グループ全体に管理権限を分配すると、多くの場合は承認とレビューの効率が向上します。小規模で部門横断型の意思決定者チームを編成することは、チームが品質基準を守り、経営陣のサポートを得るのに役立ちます。

ファイアウォールに守られたオープン ソース コミュニティ

インナーソースはさまざまな形で説明されてきました。大規模なオープン ソース コミュニティに以前から参加している組織内の開発者なら、インナーソースという言葉を一切使わないこともあります。このような開発者はインナーソースをファイアウォールの内側で行うソフトウェア開発にオープン ソースの方法論を応用したものとしてシンプルに捉えています。

インナーソースは安全性やプライバシー性が低くなることを意味するわけではありません。プロプライエタリ ソフトウェアを公開して共有することや、外部ユーザーにソース コードを見せたり、インナーソース プロジェクトにアクセス権を与えたりすることは必要ありません。ご安心ください。全ての非公開コードは自社の環境内に安全に保管され、適切な権限を持った開発者のみが貢献できます。

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

企業がインナーソースを導入する理由

企業はソフトウェアとデータを使用して自社の製品とサービスを発展させ、差別化している、またはソフトウェアとデータが自社の製品またはサービスであると理解しているため、従来の開発手法とツール導入があまり機能していないことにすぐに気付きました。要件の収集、ミーティングの開催、サイロでの開発といったスピードが遅く、体系的なプラクティスは現代の技術のペース、それどころか顧客の要求のペースに合っていません。では、どのようにすれば企業は加速できるでしょうか。

インナーソースを使用すると、チームはより速くソフトウェアを構築でき、連携しやすくなります。その結果、開発品質が向上し、効果的にドキュメント化されます。また、以下により、企業の効率化をサポートします。

• コードを広範囲で探し、再使用することが容易になり、無駄なリソースや重複を避けることができる

• 企業規模にかかわらず、迅速な開発を促進する

• チーム/部門内の、チーム/部門間の、チーム/部門を横断して、組織全体のサイロを削減し、コラボレーションを単純化する

• エンジニアとマネジメントの間の、および関心がある人に対して透明性を向上する

• オープン ソース貢献の先行モデルであるオープンな文化を築く

• 必要とされる場面でサポートを提供するチーム メンバーが誇り、成長、仕事の満足感を得ることができるようにする

PayPal、Bloomberg、Walmart などのトップ企業はインナーソースを利用して自社チームと顧客向けのソフトウェアを構築しています。インナーソースにより独自の競争優位性が実現し、認識されたベスト プラクティスを導入することで優位性を保てます。

インナーソース プロジェクトの構造

個人、チーム、リソースを適切に組み合わせることがプロジェクトの成功につながります。多くのオープン ソース プロジェクトが類似する組織構造を持っています。企業のインナーソース プロジェクトを管理する部門横断型のチームを設立する場合にこの構造を検討することをお勧めします。典型的なオープン ソース プロジェクトには次のようなタイプの人が参加します。

• メンテナー: ビジョンを推進し、組織的な側面を管理する役割を担うコントリビュータ。コードの当初の所有者または作成者である必要はありません。

• コントリビュータ: プロジェクトになんらかの貢献を果たした全ての人。

• コミュニティ メンバー: プロジェクトを使用する人。会話に参加したり、プロジェクトの方針に意見を表明したりする場合があります。

大規模なプロジェクトにはツール導入、トリアージ、コミュニティ管理などの異なるタスクに特化したサブ委員会または作業グループがある場合もあります。

多くの場合、インナーソース プロジェクトは類似の構造を持っています。多くのエンジニアリング組織では、開発者をアプリケーション エンジニアリング、プラットフォーム エンジニアリング、Web 開発といったチームに分類しています。この方法で組織を構成すると盲点が残り、有能な開発者が除外されてしまうおそれがあります。組織全体のチームがサポートする、コアとなる意思決定グループを編成すると、必要な専門家を集めて特定の問題をすばやく解決できるようになります。

企業内において「コントリビュータ」は企業全体の開発者であり、「メンテナー」はプロジェクトのリーダーであり主要な意思決定者です。

• メンテナー: 企業内の開発者、プロダクト マネージャー、その他の主要な意思決定者。プロジェクトのビジョンを推進し、日常的なコントリビューションを管理する役割を担います。

• コントリビュータ: 企業内の開発者、データ サイエンティスト、プロダクト マネージャー、マーケター、その他の役割を持つ人。ソフトウェアの推進をサポートします。コントリビュータは直属のプロジェクト チームに所属しているとは限りませんが、コードの提供、バグ修正の登録など、ソフトウェアの構築をサポートします。

よく使われるツール

GitHub でのオープン ソース開発を促進するツールをいくつか紹介します。ツールはインナーソース プロジェクトの主要な構成要素でもあります。

• Issues: Issues はトピックを提起して会話を開始する場所です。バグを発見した、または新機能のアイディアを思いついた場合、誰でもアクセスでき、会話に参加できる Issues は最適な出発点です。Issues の詳細はこちら。

• プル リクエスト: プル リクエストは開発者がプロジェクトに反映する必要がある変更に関する活発なやりとりです。解決策への取り組みを開始し、進行中の変更をレビューする場所です。プル リクエストの詳細はこちら。

• 同期的チャット チャネル: チームがすぐに意思決定する必要がある場合もあります。Slack などの同期的チャット チャネルは GitHub の Discussions やコメントを補完するもので、問題についてリアルタイムで会話するのに最適です。

プロジェクト管理から継続的インテグレーションやデプロイまで、チームがより効率的に作業できるようにサポートする数百ものツールを GitHub で使用できます。全てのツールはこちら。

自分の組織に適合するか

インナーソースは技術変革であると同時に文化変革でもあります。インナーソースにより、一部の組織が直面する可能性がある問題を過小評価しないことが重要です。オープン ソース プロジェクトと同様に、インナーソース プロジェクトは見つけやすさと再利用に自然と注力される環境で成功します。同様の関心と専門知識を共有する、組織の規模な部門横断型のコミュニティがあることも役に立ちます。

一般的に、仕事をインナーソースにして計画プロセスを開始できるかどうかを決定する際に指標となる要素がいくつかあります。

• プロジェクトビジョンは、現実的ものであり、チーム間で共有されています。プロジェクトでは対処すべき問題と機会が明確に定義されている必要があります。

• インナーソース化を計画しているプロジェクトの主要な参加者 (イニシエータ、カタリスト、エバンジェリスト) は、協働の経験を持っています。

• 新しい「コントリビュータ」やその他の参加者がオンボーディングし順応するための計画があります。

• チームにオープンにコミュニケーションをとり、整合性を持ってビルドするためのツールとプロセスがあります。

• 定義された目標を共有する組織内グループで行動を開始できます。

インナーソースにより、個人が認識している自身の役割や責任が変わる可能性があるため、組織構造は重要な考慮事項となります。効果的なインナーソース プロセスは非公式であり、指導者がおり、自己選択的で、協力的な参加者がいます。

インナーソースのプラクティスを効果的に導入するには、コントリビュータがサイロやその他の組織部門を越えて協働できる必要があります。知識共有のイニシアチブを組織がどの程度サポートしているかが、導入がどの程度うまくいくかの良い指標となります。

実際の例については、「インナーソース文化を構築する: Booz Allen Hamilton」をご確認ください。

チームの準備状況を評価するいくつかの質問を以下に紹介します。答えが「はい」の質問が多ければ、企業でインナーソース プログラムを開始する準備ができている可能性が高くなります。

• 組織の文化はオープンで透明性の高いものですか?

• 単一のオープン プラットフォームでソフトウェアを開発していますか?

• エンジニアリング イニシアチブにリソースが十分に割かれ、リーダーシップ チームのサポートを受けていますか?

• 組織の開発者には十分な自主性があり、直属のチーム以外のプロジェクトに貢献できますか?

• 会社はオープン ソース コミュニティに参加していますか?

• エンジニアリング チームは継続的インテグレーション ツールを使用していますか?

• 会社にチームを越えて協働する確立されたクロスファンクショナルなコミュニティはありますか?

• 存在する場合、それらのコミュニティには、リーダーシップを発揮する人はいますか?

企業はそれぞれに異なるため、これらを組織がインナーソースを導入する前提条件として捉える必要はありません。通常、インナーソース プラクティスを始めるタイミングは組織内のチーム間に、自身の作業を閲覧し、その作業に貢献し、フィードバックを提供してもらうことに対して十分な信頼があると感じた時です。多くの企業ではまずパイロット プログラムとして開始し、最善策を決定する方法を選択しています。

今すぐ利用しますか?

多くの企業がインナーソース プログラムを小さい規模から開始しています。パイロット プロジェクトではインナーソースを大規模に適用する前にチームがよりオープンなプロセスを試し、コードへのアクセスを民主化し、ベスト プラクティスを記録することができます。小さく成功することで、社内の開発者コミュニティにコードを最大限活用し、より良いソフトウェアをより早くリリースする方法を提示できます。

ソフトウェアを構築する方法は 10 年前とは根本的に異なります。インナーソースはプロセスを近代化し、開発スピードを向上し、組織的な障壁を克服し、ソフトウェアの品質を向上するアプローチの 1 つです。世界で最大級のオープン ソース コミュニティである GitHub はオープン ソースのベスト プラクティスが生まれる場所です。皆で力を合わせれば、チームの構築方法を変えていけます。