要約 企業がインナーソースを導入するとき、親近感を持てるように定義を曲げることがあまりにも頻繁に起こります。 そのため、筆者らは導入企業がインナーソースを正しく定義し、正しく実践できるように支えなければと考えました。 営利企業としての利益に焦点を当てつつも、オープンソースの文化を受け入れられるような定義が必要なのです。
最も典型的かつ根源的な問題は、語彙の問題です。 基本的な概念の誤解とも言えます。 筆者らがインナーソース適用のプロジェクトをいくつか終えた後に気づいたのは、適用先の社員がインナーソースという言葉を矮小化して使い始めたことでした。 最も有害な誤解は、インナーソースという活動が忙しいチームの手を離れた外注的な作業である、というものです。 成功のための文化を考えようとせず、決まった作業手順に従おうとしたり特定のツールを使ったりすると、良いプロセスであっても簡単に失敗するのです。
こうした語彙の問題はインナーソースコモンズ全員の結束をうながすものとなりました。 多くのメンバーは、文化の刷新という大きな問題に挑戦したいと考えており、インナーソースに対する歪んだ理解は戦う相手の筆頭だったのです。 インナーソースは単純なプロセスやツールよりも上位の概念であり、企業に定義を浸透させてゆくのは難しいのです。
語彙の問題というと小さく聞こえる読者もいるかもしれません。 ですが、用語を明確かつ厳格に定義して合意することが変革には不可欠であることを、我々は何度も痛感してきました。 また、定義はすぐに確認できるものでなければなりません。 インナーソースの定義だけでなく、そのための組織標準、役割、責任といった定義が明確かつ組織全体に示されている必要があるのです。
GitHub は組織におけるコードの透明性を上げますが、それだけで組織の縦割り問題が解決するわけではありません。 本書で扱うプロセスがなければ、GitHub が協働やインテグレーションの深刻な問題を引き起こします。 また、そうした問題は、たくさんのチームが依存する中心的なコードベースにおけるボトルネックになりかねないのです。
インナーソースの実現には GitHub が必要だという意見は、私達が毎日戦っている概念です。 ほとんどの人々は、GitHub の活用よりもはるかに大変なことに気づいていません。 それは、社内におけるオープンソースの源を見つけ、コミュニティとして育ててゆくことなのです。 コミュニティがソフトウェアを作るのであって他の何者でもないのですが、大企業にはそれに気づくための全体的なコミュニティに対するセンスがないのです。
インナーソースを実現する第一歩は、信頼を育むことと透明性のあるコミュニケーションを増やすことです。 これにより、新たな協働を引き起こして改善してゆくためのセンスを磨く機会が生まれるのです。 ただし、ビジネスでは なぜか？ よりも どのように？ から考えがちであることに注意しましょう。 チームの信頼を育むというのは漠然としていて、具体的な作業内容を定義できません。 ですから、組織的階層とプロセス vs 顧客への影響とアジリティ、という対立が生まれるのです。 さて、我々はどうすれば良い意思決定と多くの協働をコストを抑えて実現できるでしょうか？ これこそがインナーソースにできて GitHub にはできないことなのです。
GitHub のようなバージョン管理とコード検索のツールを使うこと自体は、インナーソースの実現に向けた正しい方向です。 ですが、ツールの良し悪しよりも人を考慮する必要があります。 企業は、人々の恐れ、習慣、定型作業、階級、動機によって形成されており、技術よりも社内の政治的力学によって動いているのです。 本書の終わりに示すチェックリストが人に関連するものとなっている理由はこれなのです。
筆者らがインナーソースの導入時に直面した最初の大きな問題は、マネージャー間で依頼が連鎖することでした。 筆者らはこの問題を "お偉いさんのお使い" と呼ぶことにしました。 願わくば企業の中だけで起きることであり、決してオープンソースの世界で起きてほしくはないことです。 インナーソースコモンズのメンバーからの報告では、この問題はあちこちの企業で起きていることがわかりました。 そして、素晴らしいことにオープンソースのプロセスでは、この問題を解決する鍵がいくつか既にあるということです。 ただ、企業では鍵を見つけられていなかったのです。 一体どういう意味なのか、"お偉いさんのお使い" をもとに理解していきましょう。
あるとき、インナーソースを始めた会社がありました。 インナーソースなのですから、全てのコードを GitHub Enterprise へ移すことにしました。 それ以前は部署横断的なバージョン管理の仕組みが無かったので、社内ではあちこちから歓喜の声が上がりました。 ついに他の開発者のコードを見ることができるようになったのです！ 何か変更を提案するときに、それが受け入れられたとしても実現するのは来年のいつか…なんていう首を長くする時間とはおさらばなのです。 開発者達は円滑な協働のできる未来を想像して浮足立っていました。
ある勇敢なプログラマーは大きなコードベースに対してプルリクエストを送ると決め、マネージャーに「数週間で書ける」と報告しました。 彼女のレポートラインにいるマネージャーはとても喜び、彼女はついにプルリクエストを送りました。 そして、待てど暮らせど一向にマージされません。 とうとうマネージャーの機嫌は悪くなり、なぜ変更されないのか勇敢なプログラマーに問い詰めました。 彼女は「自分の仕事は終えてプルリクエストを送ったのですが、一向に受け入れられないのです。」と答えました。
そこで、彼女のマネージャーは別のコードベースを統括する別のマネージャーを訪ねました。 そのコードベースを担う組織の1グループに、変更を受け入れてもらうように強く願い出たのです。 なにしろ他に仕事が山積みなのですから！ 頼まれたマネージャーは提案に同意し、グループ内の冴えないプログラマーに変更を受け入れるよう命じました。 ところが冴えないプログラマーは勇敢なプログラマーのコードが気に入りませんでした。 自分流の書き方ではないからです。 コーディングスタイルも違うし、テストの仕組みも違うし、既存のモジュールも活用していないようでした。 結局、冴えないプログラマーは提案されたほとんどのコードを書き直してからコードベースへ取り込む羽目になりました。
色々と苦労があったにも関わらず、誰も何も学びませんでしたし、何のドキュメントも作られませんでした。 インナーソースは手間がかかるし、マネージャーの印象も良くないからダメだ、と皆が感じるようになっていきました。 また、プロダクトオーナーは自分を通さずに物事が進むのにイライラしていました。
インナーソースの適用プロジェクトを始めた頃は、"お偉いさんのお使い" に驚かされました。 他チームのコードを見ることができれば、それらをどのように自チームのコードと統合したり、あるいは自分たちのチームのために再利用したりできるかに役立つと考えていたからです。 しかし、単にコードが見えるだけでは協働にはつながらないということがわかりました。 特に大企業であるほどこの問題は顕著です。 オープンソースの世界とは利害の力学が違うのです。
まず、それまでほとんどのコードは閉じた部署(サイロ)の中で開発されていました。 つまり、部署の構造も業務プロセスも習慣も明文化されておらず、部外者は知るよしもないのです。 ですから、部外者がコードの変更を提案しても受け入れられなかったのです。 それだけではありません。 部署では内部の社員とだけ話し、部外者には通じない言葉を使う文化がありました。 これは複雑な構造の組織ではよくあることであり、後の章で説明します。
ソフトウェアのアーキテクチャを理解していない開発者がいたとして、特にそのソフトウェアが古いものでドキュメントに乏しい場合、その開発者が特定の集団に閉じこもろうとするのは自然なことです。 自分達の理解できるコンポーネントのみに責任を持つ方が簡単であり、コントロールし続けられるからです。 しかし、それでは協働しようという雰囲気にはならず、アーキテクチャは複雑になり、コンポーネントは再利用されなくなってしまうのです。
コントリビューションをしたいと思っている開発者であっても複雑さの前に恐れてしまい、本当に協力しないとまずいという切羽詰まった段階になるまで踏み切ろうとしません。 また、コードベースの責任者は、自チームではない開発者が書いたコードに対する優先度を低く見積もり、責任を受け入れることを嫌がりました。 こうした協働への反作用が、マネージャーになんとかしてもらうという連鎖を生みました。 そして、需要の高いコードベースであるほど GitHub がボトルネックになってしまいます。 結局、最も多くの人からアクセスされるコードが、最もコントリビューションしにくいコードになってしまうのです。
さらに、コントリビューターが他のコードベースにプルリクエストを送る動機は、自らの需要だということもわかりました。 ですが、プルリクエストを送られた人々は、余計な仕事と責任が増える(ハイリスクローリターン)と考えるため、それを受け入れようとしないのです。
我々はそうした文化的な問題の解決方法を探るべく、オープンソースの歴史に学ぶ必要がありました。 また、オープンソースで上手くいっている方法を企業の中で発揮できるように応用する方法を見つけ出す必要がありました。 さらに、全社員がくまなく受け入れられるように単純明快な方法に仕上げることも望ましいのです。 この方法を3章で解説します。
閉じた文化におけるコミュニケーションの問題は、伝統的なオープンソースの世界で起きる問題とは異なるものです。 特に計画段階における問題は全く異なります。 筆者が PayPal に入社する2週間前、四半期計画の一環として、ある中心的なコードベースに対して複数のチームが機能レベルの変更を要求しました。 そのコードベースを担うコアチームは、寄せられたユーザーストーリーをコードベースの建てつけに合わせて勝手に書き直し、要求元である外部のチームに送り返したのです。 四半期の終わりになり、それらのチームは書き直されたユーザーストーリーを持ってインナーソース推進チームに駆け込んできて不満をぶちまけました。 「まるでインナーソースは徴兵されたコードだ」というのです。 他チームの仕事をするように強制されてしまったと感じたのです。 一体どういうことかと調べてみると、変更要求を受け取ったチームは、それらの変更要求が事業の四半期計画を達成するための必要な変更であることに気づいていなかったのです。 インナーソース推進チームは混乱しながらも、元々の変更要求をコアチームに再送して事情を説明しました。
こうして筆者らは、変更要求が勝手に書き直されるという明らかなコミュニケーションの失敗を経験しました。 そして、その次回からは、変更要求を書き直す際には全チームのいる場で交渉するように改善しました。 このコミュニケーションの問題が解決された後、大きな成果を上げることができました。 プルリクエストとして溜まっていたコード変更は承認され、バックログに溜まっていた他チームからのユーザーストーリーも解消したのです。
他の問題もあります。 何の気なしに大きなプルリクエストを送るチームがいたのです。 企業において計画もコミュニケーションもないままこのように多くのリソースを費やすと、マネージャー同士の戦いになってしまいます。
筆者らはこうした問題を経験し、実証された一連のプラクティスを定義する必要があると判断しました。 良質なコミュニケーションとは何か、チーム間の期待は何かを明示することが絶対に必要があると確信したのです。 6章では、筆者らの解決に向けた歩みを示します。