なぜ今、開発スタイルを変える必要があるのか
こんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
現在、私たちの開発組織では、チームごとに最適化された「サイロ化」が進行しています。 これにより、同じような機能を複数のチームが個別に開発する「車輪の再発明」や、 特定の担当者しかコードの内容を把握していない「ブラックボックス化」が、 開発スピードを停滞させる要因となっています。組織が大きくなればなるほど、この『重複の無駄』は指数関数的に増大します。
これらの課題を解決する手段が、世界中のエンジニアが信頼するオープンソースの開発手法を 組織内に取り入れる「InnerSource」です。コードを社内全体に開放し、 部署の垣根を越えて協力し合う仕組みを構築することで、資産の再利用性を高め、 組織全体の技術力を底上げすることを目指します。
成功のために不可欠な「三位一体」の支援
InnerSourceを単なる「コードの公開」に終わらせず実効性のある活動にするためには、 以下の3つの要素をバランスよく整備する必要があります。 これら三要素は独立したものではなく、マインドが行動を促し、ルールがその行動を正当化し、 基盤がその効率を最大化するという相互補完の関係にあります。
1. 組織的なマインドセットの変革
まず第一に必要となるのが、「組織的なマインドセットの変革」です。 他部署のコードに触れることを「越権行為」ではなく「全社貢献」と定義し直す必要があります。 特に現場のエンジニアが安心して活動できるよう、トップマネジメントからの明確な支持表明と、 他部署への貢献を業務時間として認める文化的な裏付けが不可欠です。 InnerSourceの導入は、技術の導入ではなく、 『組織の境界線を溶かす』 作業です。 コードを隠すことで守るのではなく、共有することで磨く。この価値観の転換こそが、 開かれた強いエンジニア組織を作る第一歩となります。
以下で詳細に見ていきましょう。
「所有」から「共有」へのパラダイムシフト
これまでの組織では「自分たちのコードを自分たちだけで守る」ことが責任感の証でした。 しかし、InnerSourceではこれを「全社の資産を預かっている」という感覚にアップデートします。 これを実現するポイントは次のようなものです。
- 「見せるのは完成してから」を捨てる
未完成の状態、いわゆる「WIP（Work In Progress）」の段階でコードをさらけ出すことを推奨します。 早期に公開することで、手遅れになる前にフィードバックを得られるメリットを浸透させます。 - 「情報の非対称性」による優位性を捨てる
「自分しか知らない」ことを価値とするのではなく、「誰もが知っている状態を作った」ことを賞賛する文化へ移行します。
心理的安全性の確保（失敗を「学び」に変える）
他部署のコードに触れる、あるいは自分のコードに口出しされることは、エンジニアにとって大きなストレスを 伴います。
例えば、他部署の人がバグを見つけた際、それを「恥」や「攻撃」と捉えるのではなく、 「システムを堅牢にするためのギフト」として歓迎するマインドを醸成します。 つまり 「バグは宝」という空気作り が必要なのです。
また 敬意を持ったフィードバック（コードレビュー） も必要です。 指摘は「人格」ではなく「コード」に対して行うというOSSの基本作法を徹底します。 これにより、「他人の領域を荒らす」という心理的障壁を「プロフェッショナル同士の協力」へと変換します。
マネジメント層の「コスト」に対する認識変革
現場がどれだけ熱望しても、上司が「自部署のタスク以外は無駄」と考えていればマインドセットは変わりません。
他部署への貢献に時間を使うことは、巡り巡って 「社内のナレッジが循環し、自部署が困ったときにも助けてもらえる」という、 いわば 「技術的・組織的な貯金」 であると理解を求めます。 「短期的な自部署の利益」から「中長期的な全社利益」への意識変革が必要です。
また、本業100%の余裕のない状態では変革は起きません。余白を持ち、 「全社貢献活動へのリソース割当」や「スキルスラック（余裕）の活用」 を行うことが 結果として組織全体のレジリエンス（回復力・弾力性）を高めるという認識を共有します。
「コントリビューター」という誇り
「他人の手伝いをする人」ではなく、「組織の壁を壊す開拓者」としてのアイデンティティを確立します。 たとえば 「全社的な認知と称賛」として、優れた貢献をした個人やチームを、社内広報や技術ブログで 「ヒーロー」として紹介します。これにより、「あの人のようになりたい」というポジティブな模倣を生み出します。
2. 透明性の高いルール整備
第二に必要となるのが、「透明性の高いルール整備」です。 誰でも参加できるからこそ、参加の作法（コントリビューション・ガイドライン）や、 コードの品質を最終的に保証する責任者（メンテナー）の定義を明確にしなければなりません。 これにより、メンテナンスの責任分界点が曖昧になる不安を解消し、秩序ある協力体制を維持します。
これには以下のようなことが必要になります。
参加の「プロトコル」を標準化
誰でも迷わず参加できるように、「入り口」と「進み方」を可視化します。
たとえば CONTRIBUTING.md を必須化します。すべての公開プロジェクトに、
環境構築手順、コーディング規約、プルリクエスト（PR）の出し方を記した「説明書」として
CONTRIBUTING.md を用意します。これによって「これさえ読めば誰でも参加できる」状態を標準にします。
「意思決定プロセス」の透明化
InnerSourceで最も揉めやすいのは「送った修正がなぜ却下されたのか」 「いつ取り込まれるのか」という点です。
こうしたことを起こさないようにするために レビュー基準を公開し、「どのようなコードならマージされるのか （テストコードは必須か、パフォーマンス基準はあるか等）」を事前に定義します。
修正を採用しない場合も、その理由をロジカルにログとして残します。これにより、「個人的な好み」ではなく「プロジェクトの方針」に基づく判断であることを示し、「納得感」のあるリジェクトとなるようにすることで 貢献者のモチベーション低下を防ぎます。
「責任分界点」と「保守ルール」の明確化
「他人のコードをマージしたら、その後の面倒もずっと見なければならないのか？」 というメンテナー側の不安を解消します。
これには以下のようなことを実施します。
- Trusted Committer（信頼されたコミッター）の定義
最終的なマージ権限を持つ人を明確にします。彼らの仕事は「自分で書くこと」以上に 「他者のコードを導き、承認すること」であると再定義します。 - サポートレベル（SLA）の設定
「このコードは実験的なので、不具合への対応はベストエフォートです」といった、 プロジェクトごとの「期待値」をラベルなどで可視化します。 これにより、利用側と提供側の認識のズレをなくします。
「貢献」を正当に記録・可視化するルール
「誰が何をしたか」を組織が公認するためのルールです。 たとえば コントリビューター・インベントリ です。誰がどのプロジェクトにどれだけ貢献したかを、 ツール（GitHubのダッシュボード等）で自動的に可視化します。 もう１つの例が、成果の「ポータビリティ（持ち運びやすさ）」です。 A部署での貢献実績が、B部署に異動しても「技術的実績」として正当に評価されるよう、 評価基準の全社共通フォーマットを作成します。
3. 基盤組織（CCoE/ISPO）による支え
第三に必要となるのが、「基盤組織（CCoE/ISPO）による支え」です。開発者がスムーズに交流できるよう、 共通のCI/CD環境やプロジェクト検索ポータルを整備する技術的支援が必要です。 さらに、これらを専門に扱う「InnerSource Program Office (ISPO)」のような組織を設置することで、 マッチングの促進や成功事例の横展開、さらには人事評価制度への組み込みといった、 現場のエンジニアだけでは解決できない組織課題を解消していきます。
現場に「あとは自分たちで自由にやってね」と丸投げするのではなく、 「参加したほうが楽で、得をする」という状況をプラットフォームとして提供するのがこれらの組織の役割です。
この基盤組織による支援は次の4つで考えます。
「発見可能性（Discoverability）」の提供
InnerSourceにおける最大の敵は「どこで何が行われているか分からない」ことです。
Backstageなどのツールを活用し、社内のリポジトリ、APIドキュメント、 誰がどの分野の専門家かを一括検索できる環境を作ります。 さらに活発に活動しているプロジェクトや、全社的に利用を推奨するライブラリを ピックアップして発信し、エンジニアがどこに貢献すべきかの「道標」を作ります。
「参入障壁」を技術的に下げる（CCoEの主役割）
他部署のコードを触る際、環境構築に3日かかるようでは貢献は生まれません。 こうしたことの「実現」や「解消」するために必要となるのが 標準化されたCI/CDパイプライン の用意です。 どのプロジェクトでも、プルリクエストを出せば自動的にテストとセキュリティスキャンが走り、 品質がチェックされる環境を共通基盤として提供します。 また、セルフサービス型インフラ も重要です。貢献者が自分のローカル環境や サンドボックス環境を即座に立ち上げられるよう、コンテナ化やIaC（Infrastructure as Code）の テンプレートを整備し、開発の「準備」にかかる時間をゼロに近づけます。
「マッチング」と「コミュニティ運営」（ISPOの主役割）
ツールを提供するだけでなく、人間同士を繋ぐ「触媒」としての役割です。 たとえば次のようなことを行います。
「Help Wanted」の流通
人手が足りないプロジェクトと、スキルアップしたい開発者をマッチングさせます。 「このIssueは初心者向けです」といったラベル付けを推奨し、社内インターンシップのような 交流を促進します。
InnerSource Day の開催
社内の成功事例を発表する場や、部署をまたいだハッカソンを企画し、InnerSourceを 「一部の人の活動」から「社内の公認イベント」へと昇華させます。
「データによる可視化」と「継続的な予算確保」
活動を文化として定着させるためには、その価値を経営層に証明し続けなければなりません。 「コードの再利用率」「部署をまたいだ貢献数」「オンボーディング期間の短縮」などを数値化する、 活動メトリクスの計測 が必要です。
また、 ROI（投資対効果）の発信 も重要です。これによって、 「自分たちで作っていたら◯人月かかっていた機能が、InnerSourceの活用でこれだけ削減できた」と いった成果を可視化し、活動への投資（専任組織の維持費など）の正当性を担保します。 加えて数値化しにくい 『エンジニアの離職防止』や『技術広報（採用力）の強化』といった 無形の価値も重要なROIとして定義します。
実践的なアプローチ
スモールスタートからの成長
InnerSourceに必要な3要素ですが、これらすべてを一斉に導入するのは現実的ではありません。 まずは「小さく始め、実績を積みながら大きく育てる」戦略をとります。
具体的には、まず社内の多くのチームが利用している「小さな共通ライブラリ」や 「インフラのテンプレート」を最初の対象に選びます。いきなり不特定多数からの修正を受け入れるのではなく、 まずは関連チーム間での「コードの公開」から始め、徐々に要望（Issue）の受け入れ、 そしてプルリクエスト（PR）の受け入れへと段階的にハードルを上げていきます。
この草の根の活動で得られた「開発リードタイムの短縮」や「バグの早期発見」といった 具体的な成功体験をエビデンスとして、徐々に専任組織の設置や全社的なルール化へと、 トップダウンの支援を引き出していく流れが最も確実です。
そして次のステップへ
以前「Platform Engineering成功への最短ルート」と題して、「Platform Engineering」「Team Topologies」そして「InnerSource」は 三位一体の統合戦略であるとお伝えさせていただきました。
このときはPlatform Engineeringを中心に見ていきましたが、その内容は「InnerSource」側からみても同様です。 InnerSourceを成功させるにはその基盤としての「Platform」、そして役割分担（境界）を明確にしていくための「Team Topologies」が必要です。
そして、そうした情報を統合していくための「ポータル（Backstage）」が必要ということは前回、そして今回も述べさせていただいたとおりです。
スモールスタートしながらも将来はこうした要素を取り込みながら、その適用範囲を拡大することが求められます。
エンジニアが輝く組織へ
InnerSourceの推進は、単なる効率化の手段ではありません。エンジニアが他者の優れたコードから学び、 自らの成果を広めることで、キャリアの成長を実感できる「モダンな開発文化」を築くための投資です。 まずは特定のプロジェクトをパイロットケースとして選定し、実験的な取り組みを開始することを提案いたします。
最後に。
弊社では、Backstageのマネージドサービスである「PlaTT」 を提供しています。
開発者ポータルの前提となる Platform Engineeringの導入支援も行っております。
開発者体験を向上し、開発生産性を高めたいとご検討の皆様、ぜひ弊社までご相談ください。
