Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
PayPal がインナーソースの取り組みを初めて発表した場は、2015年に北米で開催された OSCON(O'Reilly's Open Source Convention) です。 我々はその時、すべての答えを持っているわけではなく、オープンソース由来の方法を応用して PayPal 内の壁を壊し、協働を引き起こしてきた一連の旅路を公開するという意志を持っていたにすぎませんでした。 この発表は、その意志の表れなのです。
この旅の成功は、文化的な発展に貢献するツールとプロセスを構築できるチームの存在が大いに関係しているでしょう。 Silona Benewald が PayPal 全体にわたりインナーソースを実現できた背景には、彼女のオープンソースとプロダクトマネジメントにおける経験と、データサイエンスへの愛着があります。
Silona は秩序を大事にしています。 彼女がチェックリストを使う理由は備忘録のためでもありますが、実践的な規律を設けるためでもあり、新しいアイデアを素早く試すためでもあるのです。 彼女は、この小さな本(ブックレット)を書き上げ、我々の考えたインナーソースを実現するためのチェックリストに至る考えを広めようとしています。 皆さんがこの本を楽しみ、新たな知見を得ることができることを願っています。
Danese Cooper, オープンソースおよびインナーソース責任者, PayPal
要約 企業がインナーソースを導入するとき、親近感を持てるように定義を曲げることがあまりにも頻繁に起こります。 そのため、筆者らは導入企業がインナーソースを正しく定義し、正しく実践できるように支えなければと考えました。 営利企業としての利益に焦点を当てつつも、オープンソースの文化を受け入れられるような定義が必要なのです。
最も典型的かつ根源的な問題は、語彙の問題です。 基本的な概念の誤解とも言えます。 筆者らがインナーソース適用のプロジェクトをいくつか終えた後に気づいたのは、適用先の社員がインナーソースという言葉を矮小化して使い始めたことでした。 最も有害な誤解は、インナーソースという活動が忙しいチームの手を離れた外注的な作業である、というものです。 成功のための文化を考えようとせず、決まった作業手順に従おうとしたり特定のツールを使ったりすると、良いプロセスであっても簡単に失敗するのです。
こうした語彙の問題はインナーソースコモンズ全員の結束をうながすものとなりました。 多くのメンバーは、文化の刷新という大きな問題に挑戦したいと考えており、インナーソースに対する歪んだ理解は戦う相手の筆頭だったのです。 インナーソースは単純なプロセスやツールよりも上位の概念であり、企業に定義を浸透させてゆくのは難しいのです。
語彙の問題というと小さく聞こえる読者もいるかもしれません。 ですが、用語を明確かつ厳格に定義して合意することが変革には不可欠であることを、我々は何度も痛感してきました。 また、定義はすぐに確認できるものでなければなりません。 インナーソースの定義だけでなく、そのための組織標準、役割、責任といった定義が明確かつ組織全体に示されている必要があるのです。
GitHub は組織におけるコードの透明性を上げますが、それだけで組織の縦割り問題が解決するわけではありません。 本書で扱うプロセスがなければ、GitHub が協働やインテグレーションの深刻な問題を引き起こします。 また、そうした問題は、たくさんのチームが依存する中心的なコードベースにおけるボトルネックになりかねないのです。
インナーソースの実現には GitHub が必要だという意見は、私達が毎日戦っている概念です。 ほとんどの人々は、GitHub の活用よりもはるかに大変なことに気づいていません。 それは、社内におけるオープンソースの源を見つけ、コミュニティとして育ててゆくことなのです。 コミュニティがソフトウェアを作るのであって他の何者でもないのですが、大企業にはそれに気づくための全体的なコミュニティに対するセンスがないのです。
インナーソースを実現する第一歩は、信頼を育むことと透明性のあるコミュニケーションを増やすことです。 これにより、新たな協働を引き起こして改善してゆくためのセンスを磨く機会が生まれるのです。 ただし、ビジネスでは なぜか？ よりも どのように？ から考えがちであることに注意しましょう。 チームの信頼を育むというのは漠然としていて、具体的な作業内容を定義できません。 ですから、組織的階層とプロセス vs 顧客への影響とアジリティ、という対立が生まれるのです。 さて、我々はどうすれば良い意思決定と多くの協働をコストを抑えて実現できるでしょうか？ これこそがインナーソースにできて GitHub にはできないことなのです。
GitHub のようなバージョン管理とコード検索のツールを使うこと自体は、インナーソースの実現に向けた正しい方向です。 ですが、ツールの良し悪しよりも人を考慮する必要があります。 企業は、人々の恐れ、習慣、定型作業、階級、動機によって形成されており、技術よりも社内の政治的力学によって動いているのです。 本書の終わりに示すチェックリストが人に関連するものとなっている理由はこれなのです。
筆者らがインナーソースの導入時に直面した最初の大きな問題は、マネージャー間で依頼が連鎖することでした。 筆者らはこの問題を "お偉いさんのお使い" と呼ぶことにしました。 願わくば企業の中だけで起きることであり、決してオープンソースの世界で起きてほしくはないことです。 インナーソースコモンズのメンバーからの報告では、この問題はあちこちの企業で起きていることがわかりました。 そして、素晴らしいことにオープンソースのプロセスでは、この問題を解決する鍵がいくつか既にあるということです。 ただ、企業では鍵を見つけられていなかったのです。 一体どういう意味なのか、"お偉いさんのお使い" をもとに理解していきましょう。
あるとき、インナーソースを始めた会社がありました。 インナーソースなのですから、全てのコードを GitHub Enterprise へ移すことにしました。 それ以前は部署横断的なバージョン管理の仕組みが無かったので、社内ではあちこちから歓喜の声が上がりました。 ついに他の開発者のコードを見ることができるようになったのです！ 何か変更を提案するときに、それが受け入れられたとしても実現するのは来年のいつか…なんていう首を長くする時間とはおさらばなのです。 開発者達は円滑な協働のできる未来を想像して浮足立っていました。
ある勇敢なプログラマーは大きなコードベースに対してプルリクエストを送ると決め、マネージャーに「数週間で書ける」と報告しました。 彼女のレポートラインにいるマネージャーはとても喜び、彼女はついにプルリクエストを送りました。 そして、待てど暮らせど一向にマージされません。 とうとうマネージャーの機嫌は悪くなり、なぜ変更されないのか勇敢なプログラマーに問い詰めました。 彼女は「自分の仕事は終えてプルリクエストを送ったのですが、一向に受け入れられないのです。」と答えました。
そこで、彼女のマネージャーは別のコードベースを統括する別のマネージャーを訪ねました。 そのコードベースを担う組織の1グループに、変更を受け入れてもらうように強く願い出たのです。 なにしろ他に仕事が山積みなのですから！ 頼まれたマネージャーは提案に同意し、グループ内の冴えないプログラマーに変更を受け入れるよう命じました。 ところが冴えないプログラマーは勇敢なプログラマーのコードが気に入りませんでした。 自分流の書き方ではないからです。 コーディングスタイルも違うし、テストの仕組みも違うし、既存のモジュールも活用していないようでした。 結局、冴えないプログラマーは提案されたほとんどのコードを書き直してからコードベースへ取り込む羽目になりました。
色々と苦労があったにも関わらず、誰も何も学びませんでしたし、何のドキュメントも作られませんでした。 インナーソースは手間がかかるし、マネージャーの印象も良くないからダメだ、と皆が感じるようになっていきました。 また、プロダクトオーナーは自分を通さずに物事が進むのにイライラしていました。
インナーソースの適用プロジェクトを始めた頃は、"お偉いさんのお使い" に驚かされました。 他チームのコードを見ることができれば、それらをどのように自チームのコードと統合したり、あるいは自分たちのチームのために再利用したりできるかに役立つと考えていたからです。 しかし、単にコードが見えるだけでは協働にはつながらないということがわかりました。 特に大企業であるほどこの問題は顕著です。 オープンソースの世界とは利害の力学が違うのです。
まず、それまでほとんどのコードは閉じた部署(サイロ)の中で開発されていました。 つまり、部署の構造も業務プロセスも習慣も明文化されておらず、部外者は知るよしもないのです。 ですから、部外者がコードの変更を提案しても受け入れられなかったのです。 それだけではありません。 部署では内部の社員とだけ話し、部外者には通じない言葉を使う文化がありました。 これは複雑な構造の組織ではよくあることであり、後の章で説明します。
ソフトウェアのアーキテクチャを理解していない開発者がいたとして、特にそのソフトウェアが古いものでドキュメントに乏しい場合、その開発者が特定の集団に閉じこもろうとするのは自然なことです。 自分達の理解できるコンポーネントのみに責任を持つ方が簡単であり、コントロールし続けられるからです。 しかし、それでは協働しようという雰囲気にはならず、アーキテクチャは複雑になり、コンポーネントは再利用されなくなってしまうのです。
コントリビューションをしたいと思っている開発者であっても複雑さの前に恐れてしまい、本当に協力しないとまずいという切羽詰まった段階になるまで踏み切ろうとしません。 また、コードベースの責任者は、自チームではない開発者が書いたコードに対する優先度を低く見積もり、責任を受け入れることを嫌がりました。 こうした協働への反作用が、マネージャーになんとかしてもらうという連鎖を生みました。 そして、需要の高いコードベースであるほど GitHub がボトルネックになってしまいます。 結局、最も多くの人からアクセスされるコードが、最もコントリビューションしにくいコードになってしまうのです。
さらに、コントリビューターが他のコードベースにプルリクエストを送る動機は、自らの需要だということもわかりました。 ですが、プルリクエストを送られた人々は、余計な仕事と責任が増える(ハイリスクローリターン)と考えるため、それを受け入れようとしないのです。
我々はそうした文化的な問題の解決方法を探るべく、オープンソースの歴史に学ぶ必要がありました。 また、オープンソースで上手くいっている方法を企業の中で発揮できるように応用する方法を見つけ出す必要がありました。 さらに、全社員がくまなく受け入れられるように単純明快な方法に仕上げることも望ましいのです。 この方法を3章で解説します。
閉じた文化におけるコミュニケーションの問題は、伝統的なオープンソースの世界で起きる問題とは異なるものです。 特に計画段階における問題は全く異なります。 筆者が PayPal に入社する2週間前、四半期計画の一環として、ある中心的なコードベースに対して複数のチームが機能レベルの変更を要求しました。 そのコードベースを担うコアチームは、寄せられたユーザーストーリーをコードベースの建てつけに合わせて勝手に書き直し、要求元である外部のチームに送り返したのです。 四半期の終わりになり、それらのチームは書き直されたユーザーストーリーを持ってインナーソース推進チームに駆け込んできて不満をぶちまけました。 「まるでインナーソースは徴兵されたコードだ」というのです。 他チームの仕事をするように強制されてしまったと感じたのです。 一体どういうことかと調べてみると、変更要求を受け取ったチームは、それらの変更要求が事業の四半期計画を達成するための必要な変更であることに気づいていなかったのです。 インナーソース推進チームは混乱しながらも、元々の変更要求をコアチームに再送して事情を説明しました。
こうして筆者らは、変更要求が勝手に書き直されるという明らかなコミュニケーションの失敗を経験しました。 そして、その次回からは、変更要求を書き直す際には全チームのいる場で交渉するように改善しました。 このコミュニケーションの問題が解決された後、大きな成果を上げることができました。 プルリクエストとして溜まっていたコード変更は承認され、バックログに溜まっていた他チームからのユーザーストーリーも解消したのです。
他の問題もあります。 何の気なしに大きなプルリクエストを送るチームがいたのです。 企業において計画もコミュニケーションもないままこのように多くのリソースを費やすと、マネージャー同士の戦いになってしまいます。
筆者らはこうした問題を経験し、実証された一連のプラクティスを定義する必要があると判断しました。 良質なコミュニケーションとは何か、チーム間の期待は何かを明示することが絶対に必要があると確信したのです。 6章では、筆者らの解決に向けた歩みを示します。
要約
パッシブドキュメンテーション[4-1] は部族内知識の捕捉と人材育成に欠かせないものです。チームは初期にコミュニケーションの落ち込みを感じることがありますが、速度の向上はその落ち込みを補っても余りあるのです。
ドキュメンテーションの作成者と消費者の両方に報酬を与えることで、パッシブドキュメンテーションを促進できます。
パッシブドキュメンテーションを利用可能とするためには、それが検索可能な状態でなければなりません。これはサイロ化した複数のデータセットにまたがるタグづけをときどきする必要性を意味しています。
パッシブドキュメンテーションは将来のためではなく、現在必要なことを説明するために書かれた情報から成っています。 例えば以下のようなものです。
トラステッドコミッター (TC) が、コントリビューターに対して、彼らのコードベースを統合する方法を指導する際に行われる会話
プロダクトオーナーたちが互いにタスクの優先順位を説明したり、整理整頓するときに交わす会話
コードの一部とプロジェクトのコードに関するストーリー、そしてこれらに関する生きた会話
最初に最も難しいのは、人々に対してこれらの会話をもっとオープンにすることを説得することです。 彼らは今後も参照するドキュメントを事前準備なしに作ることに対して慎重になる傾向があります。 しかし彼らが公式なドキュメントを書いているのではなく、単に育成のために交わした会話を記録しているだけであると気づくと、抵抗感がなくなっていくことがわかりました。 またドキュメンテーションの急速な拡充によるメリットは誰の目にも明らかでした。
パッシブドキュメンテーションに記録されるには、会話は文書上で行われる必要があります。 一般的な記述形式はプルリクエストのコメント、Slack のパブリックチャネルにあるタグ付けされた会話、wiki 内のコメントページ、メーリングリストにあるタグつきメッセージなどです。 オープンソースの世界では、メーリングリスト、もしくは wiki で公開されていない会話は "本物" ではないとよく言われます。 私たちは、社内においても同じような文化へ変化させていこうと取り組んでいます。 また、もし対面で重要な議論があったのであれば、その終わりには必ず誰か一人が記録に残すことを合意します。 そのためには、全ての関係者が承認できるように議論の内容を詳しくメールに記述し、その内容をより大きなコミュニティにも公開します。
トラステッドコミッターがプルリクエスト上で公開されたいくつかの質問に答えたあと、次のコントリビューターからのプルリクエストの速度がすぐに上昇することがわかりました。
まじめなコントリビューターは助けを求める前に、あるいはプルリクエストを出す前にドキュメンテーションを探します。 私たちの場合、これらのドキュメントはすべて GitHub 上で管理しているのでどこを見ればいいかほとんど迷うことはありません。 また、コントリビューターが過去のアドバイスをプルリクエストに反映していないとき、過去の会話を参照するように差し戻すことをトラステッドコミッターたちにおすすめしています。
私たちは、こうした公開された会話に報いる方法を模索しています。 関連性の高いドキュメントを書いた人がいた場合には、そのことを強調するダッシュボードを作成しています。 また、調査を先に行ったコントリビューターに対して、トラステッドコミッターが報酬を与えることができます。 トラステッドコミッターは、誰がその方向性に従うのかを素早く知り、その人のプルリクエストを優先的に処理することになるでしょう！
オープンソースの世界では、何かをする方法について知りたいとき、単にググれば良いのです。 しかし、企業においては、情報を見つけることがオープンソースの世界と比較すると、はるかに難しいのです。 たいていの情報は様々なソフトウェアやデータストアに保存され、検索可能かどうかもわかりません。 多くの場合でこれらの保存先にある情報は、デフォルトで非公開にした方が安全だと思われがちです。 ですが、長い目で見るとこの状態は企業に大きなダメージを与えることになってしまいます。 情報を閉ざした場合、新しく入社した従業員のオンボーディングは困難なものになり、オンボーディングの際に習得できる知識の統一がほぼ不可能になります。 そのうえ、部族内知識を招く、あるいは助長する雰囲気を生み出しかねません。
時に、これらの問題はツール自身が持つ検索機能が粗悪だったり、そもそも存在しないことにより生じます。 ただ、多くのツールを使用しているので、情報の集約が難しいのです。 また、全てのユーザーがアクセスできるようにするためには、追加で費用がかかることが多く、この問題を悪化させているケースがよくあります。
しかしドキュメントが役に立つのはそれを見つけることができる場合に限られるため、この問題の解決は非常に重要です。 私たちのチームの多くは手動で検索ができるように、サイロ化されたアプリケーションをまたぐようなタグづけを要求し始めています。 たとえば、バグ修正のための JIRA の Issue 番号や、GitHub の機能レベルのプルリクエストに対する Rally のストーリー番号など検索可能なタグが設定されていないプルリクエストは検討対象外とコントリビューション協定で定めているチームもあります。 これは誰かが閉ざされた複数のデータストアをまたいで検索する必要があるときに大きな助けになりますが、理想的な方法ではないですし、開発者たちがかなりまじめであることが求められます。
そこで私たちは情報の発見と共有を手助けするツールの開発を始めました。 それが RallySlack です (オープンソースです！)。 Slack 上で誰かが活動しているとき、RallySlack は自動的にその個人のすべての Rally ストーリーを取り出して、Slack の会話を見つけてタグ付けしやすくします。 RallySlack を使えばユーザーは Rally のストーリー番号を探したり覚えたりする必要がなくなります。 また、現在私たちは GitHub でのプルリクエストや Issue に対して Rally のストーリー番号のタグ付けを手助けする類似のツールを開発しています。 最終的にはこのツールも RallySlack 同様にオープンソース化したいと考えています。
[4-1] (訳注) ドキュメント(document)が単一の文書を指すのに対し、ドキュメンテーション(documentation)はドキュメントの集合を指します。本章で解説されているように、プルリクエストのコメント、Slack のパブリックチャネルにあるタグ付けされた会話、といった過ぎ行く(パッシブな:passive)文章の集合がパッシブドキュメンテーションです。
要約
リスクの程度に関わらずプロジェクトには トラステッドコミッター が必要です。リスクの程度に応じ、役割の責任を明確に定義しましょう。
トラステッドコミッターは役割としての責任に加えコーディングに対する責任も持ちます。その責任対象は行ったり来たりします。
トラステッドコミッターは難しい役割です。その役割にふさわしく、引き受けてくれる社員には報酬を与える必要があります。
企業は、より統合されたコード、コードレビューの質向上、プルリクエスト応答時間の短縮、より明確なリファクタリングのノウハウ、ドキュメント作成の省力化、ボトルネックの解消といった素晴らしい恩恵をうけます。
前章では、私たちが直面したいくつかの文化的な問題を取り上げました。 コードの所有者はプルリクエストを受け付ける必要があります。 そうしない場合はボトルネックが発生し、上層部へのエスカレーションがおきます。 また、外部チームはコードのスタイルと標準に準拠するべく学習をする必要があります。 そうしない場合はコントリビュートした内容を大幅に書き直さなければなりません。 コードの所有者と外部のコントリビューターが協力しなければ、何も改善されず、誰もが失望することになってしまいます。
企業における開発者は、プルリクエストのレビューと承認、および他部署・他プロジェクトの開発者の育成に時間を割くことを望まない傾向があります。問題の多くは、これに起因しているのです。 ただしそれを責めることはできません。 一般的には、全ての人は自身にアサインされたタスクや目標を持っています。 それは彼らのプロジェクトに対するものであり、たまたまコードベースを触ることになった誰かのプロジェクトに対するものではないのです。 そしてほとんどの人は、自分が書いていないコードに対して責任を負うことに抵抗があります。
しかし、インナーソースが機能するためには、一部の開発者がサイロの外に責任を負わなければ_なりません_。 そのため、私たちは責任を定義した新しい役割をつくり、それをトラステッドコミッターと呼ぶことにしました。 これは、私たちがこれまでに実施した最も基本的な変革であり、インナーソースを機能させるために不可欠なものです。 事実として、トラステッドコミッターを取り入れることはインナーソース実現への第一歩です。
トラステッドコミッターには以下のような責任があります。 (各項目は、トラステッドコミッターのチームがより良いコミュニケーションと協業を実現するために役立ちます)
コードベースへのコントリビューションに対するルール作成と管理
受け取るコード(プルリクエスト)のレビュー
他領域からのコントリビューターへの助言
プルリクエストのマージ
リファクタリングやモジュール化作業へのリーダーシップ
チケットやチャットにおける議論への参加
連絡事項の周知
コラボレーション機会の新規開拓
なおオープンソースの世界では、多くのグループが独自に同様の役割を進化させていることを指摘しておきます。 私たちは特に Apache ソフトウェア財団が開発した提唱した理念である"The Apache Way" を借用しています。 これらの役割は、プロジェクトに高いレベルの貢献をした人に与えられます。 トラステッドコミッターは、コードに対する最終的な責任を負っており、しばしばコードのゲートキーパーとなります。 これらの役割における力の程度は、ときにリスクの大きさと直接的な関係を見ることができます。 例えば、Linuxカーネルは広範囲に渡っておりリスクが高いため、Linuxカーネルではトラステッドコミッターの役割を Janitors と Mentors のレベルに分けています。 一方で Node.js のモジュールは非常にローリスクです。 コミュニティは精査後に新しいモジュールを受け入れないかもしれませんが、新しいモジュールが何かを壊すことはできません。 そのため Node.js にはトラステッドコミッターの役割はありません。Node.js のモジュールは、誰でも npm で公開できます。
さて、トラステッドコミッターの役割を定義した後、新たな問題が見つかりました。 開発者はコードから引き離されてしまうことを恐れ、この役割を好まなかったのです。 なぜならその多くはコーディングの時間を失いたくなかったからです。 また、彼らはコーディングとトラステッドコミッターのタスクの優先順位付けに苦労していました。 これらのタスクを頻繁に切り替えることは、時間と注意力の面でコストがかかります。 トラステッドコミッターになることで開発者はコードを書くための集中モードに入ることが難しくなりました。 我々はこの問題を解決するため、プログラマーをアクティブなコーディング作業から外し、フルタイムの仕事としてトラステッドコミッターの役割をアサインすることを検討しました。 しかし、これには別の問題がありました。社員がコードのコントリビューションをしなくなると、コードレビューがますます難しくなってしまったのです。特に統合作業においてはなおさらでした。 プログラマーは業界に入った理由でもあるプログラミング作業に携われなくなるのですから、憂鬱になることは言うまでもありません。
我々の解決策は、トラステッドコミッターがプロダクトのスペシャリストと協力して、役割のローテーションスケジュールを作成することです。 他チームにいるコントリビューターからの期待に配慮して、このスケジュールは社内に公開されます。 この期待とは、レビューと指導における専門知識への期待です。 スケジュールに各トラステッドコミッターの専門分野を記載しておくと、適切な専門知識を持った人がいつ支援できるかをコントリビューターが知ることができるようになります。 また、トラステッドコミッターが行う困難で重要な仕事に対して、新しい報酬体系を作ることも重要でした。 このプロセスについては、トラステッドコミッターへの報酬というセクションで後ほど説明します。
私たちの経験では、プロジェクトごとにトラステッドコミッターの人数は大きく異なります。 30人程度の開発者が参加する高リスクのプロジェクトでは、6人のプログラマーにトラステッドコミッターの役割を担ってもらうようにお願いしています。 常時、半分はトラステッドコミッターとしてコードのレビューや技術的な相談をし、残りの半分は積極的にコードを書くようにしています。 2週間のスプリントごとにその役割は交代します。 これはトラステッドコミッターにとって理想的でした。 2週間という期間は、コーディングに没頭するにも、メンタリングや文書作成に専念するにも、ちょうど良い長さだからです。
ツール開発のようなリスクの比較的低いプロジェクトでは、1人のトラステッドコミッターが10個以上のリポジトリで作業します。 ほとんどの開発者は、自分の開発したツールセットに関するコントリビューターへのメンタリングにとても熱心です。 このようなツーリングには誰もが気軽に貢献できるため、企業全体のチームがツールセットをより適切に標準化する方法を見つけるのに理想的です。 これらのトラステッドコミッターに対する我々の主な提案は、コーディングに没頭し、その集中を維持するためのまとまった時間をもてるように、オフィスアワーを設けることです。
プルリクエスト[3-1] のコードレビューをトラステッドコミッターの役割に割り当てることで、プルリクエストのターンアラウンドが大幅に加速し、コードレビューのレベルも上がりました。 さらに、トラステッドコミッターはメンタリングの時間を使って、次の大きなリファクタリングに備えた素晴らしいドキュメントを作成することがわかりました。 とある主要なアーキテクチャの再構築に取り組んだ責任者は、インナーソースを使用することで、コードベースを大幅にリファクタリングする方法を、チームが本当の意味で理解するのに役立ったと述べています。 また、外部からの割り込みタスクとして入ってくるバグ修正に関しても、そのプルリクエストで対処されるようになり、大幅にコードの量が削減されました。
このドキュメントは、トラステッドコミッターとコントリビューターの間で行われた公開メンタリングの議論をアーカイブし、コードベースのコンテキストに応じた場所から簡単にアクセスできるようにすることで、ほとんど苦労せずに作成されました。 これは、メンタリングに費やされた価値のある時間が、二重の役割を果たしたことを意味します。 これをパッシブドキュメンテーションと呼び、4章で詳しく説明します。
トラステッドコミッターの役割が正式に認識されるようにするには、人事部および経営陣と協力することが重要であることがわかりました。 そうすることにより、管理者がコードレビュープロセスを尊重する必要があることを再確認できるため、開発が成功しやすくなるほか、"お偉いさん" がコードの変更を強制することがなくなります。 この新しい役割は、プログラマーをコーディングから引き離すことなく昇進させる手段を提供するため、企業にとってもメリットがあります。
トラステッドコミッターの役割は、開発者の高度なスキルを明確にします。 それはメンタリング、アーキテクチャに関する深い知識、コードレビューのベストプラクティスなど多岐にわたります。 トラステッドコミッターの役割が難しいものです。 そのため企業は、追加の責任を負う献身的なスタッフにどのように適切に報いるかを決定する必要があります。
私たちはこのような複雑性を反映するために、開発者が "フェロー" に昇進するためのパスを強化しています。 これはフルスタックな開発者を生み出し、一部の開発者が退屈に感じる管理職に移行することなく昇進することにつながります。 そして、さまざまなコードベースを本質的に理解しているプログラマーを抱えることで、リファクタリングや技術的負債の削減に貢献できるようになります。
[3-1] 他のいくつかのツールと同様に GitHub はプルリクエストという言葉を使っています。これらのツールを使用していない企業では、同じものを問題報告、変更要求、あるいはチケットと呼ぶかもしれません。
私たちはオープンソースコミュニティのグループの1つとして、オープンソースの原則とプロセスを企業に取り込むことで、もっとうまく仕事ができるようになると強く感じています。 この取り組みは、会社には開発スピードの向上やチーム間のコラボレーション向上、さらにはドキュメントの充実などの面で効果があります。また、従業員にはメンタリングや説明責任、コミュニティからの支援を通して職場の雰囲気が良くなるという効果があります。
これは大きなゴールです。 私たちは、組織の中で情報やアイデアを共有するインナーソースという枠組みを広めるために、 InnerSource Commons というコミュニティを立ち上げました。 私たちは、まずは小さな変化を起こすことに焦点をあてています。 なぜなら、完璧を求めることは行動の妨げにしかならないからです。
Commons は、企業がオープンソースの基本的な枠組み理解すれば、自信をもってオープンソースコミュニティで生産的な活動ができると確信しています。 インナーソースは、誰もが各々の限界を尊重しつつ参加できる仕組みです。 インナーソースは、会社の中のチームや部門にオープンとはいえ、プロプライエタリな情報を公開するものではありません。 むしろ、サイロを減らして組織間の相互理解を深め、イノベーションを加速するのに効果的なものです。
どのようにオープンソースのツールや方法論を取り込んで、企業内にインナーソースコミュニティを立ち上げるか、その方法を共有するために、本書を執筆しています。 末尾には、組織の中ですぐに使えるチェックリストを掲載しています。 そのチェックリストを使えば、読者の組織がどの程度インナーソースプロジェクトの実装に近づいているかを確認できます。 インナーソースの実装としては、推奨する一般的なステップを記載しており、そのステップを完了したグループが「インナーソースの準備ができている」状態となることを目指しています。
本書の目的は、典型的な企業活動の根本的な部分に変化を促す簡単な方法を見つけることにあります。
インナーソースの優れた点の1つは、本社からのトップダウンの指示で開始する必要はないということです。また、開始すべきではありません。 ある部門の1つのチームが、その効果を確認するのに良い場所で小さな変化を起こすことができるものです。 そして願わくば、他のチームが刺激されて同じようにすることを期待しています。
多くのインナーソースのプロセスは、エラーや問題を解決することから始まっています。 実際、私たちの最大の強みの1つは、自分や他人が犯した誤りから学んだ教訓を共有できることです。 私たちが教訓を共有することで、別の機会に他の人たちが助けてくれます。 これが透明性を奨励する理由の1つです。
例えば、製品のインテグレーション関わっている人たちは、一部の関係者だけでプライベートにメールをやり取りしたりミーティングをしたりする方が、すべてのステークホルダーを巻き込むよりも簡単だと感じています。 関係者全員に透明性のあるコラボレーションを要求し大きな効果を得る [1-1] には、自らが率先して情報を(見つけられる場所に)置き、他の人が学べるようにすることが必要です。
インナーソースは、ツールとプロセスがあれば実施できますが、文化の変化を起こすものでもあります。 最も大きな変化は、ミスを許して議論し、そこから学ぶことにあります。
この本は、こうした前提のもと、実際に経験したことを元にして書かれています。 そして、その経験から学んだことや解決方法を共有し、誰でもコメントをしたり、その情報を参考に人々が成長できるように、 InnerSource Commons のサイトに全て公開しています。 また、紙の書籍も出版しています。 私たちは "プルリクエストの文化" で活動するようにしているので、もし本書を読んでいて間違いを見つけたり、議論を追加したりする必要があると感じたときには、いつでもオンラインでフィードバックしてください。
ビジネス環境においては、自由にフィードバックを共有することがブランド価値を低下させ金銭的な影響を生じる可能性があることから、難しいこともあるでしょう。 Commons は、チャタムハウスルールで活動しているので、明示的に公開を許可しない限り、誰もあなたの関与について触れません。 実際、この本でも関わった人を守るために、何人かの名前を変更しています。
本書に記された私達の経験を読むことで、小さな変化がより大きな文化の変革へと繋がることを追体験していただきたいと願っています。 そのために重要なソフトウェア変更管理の方法も本書で説明しています。
この本は、全ての読者がそれぞれの立場について学ぶことができるように書かれています。 開発者は、コントリビュータや、コントリビューションされた内容を確認する トラステッド・コミッター (この役割については後ほど説明します)が、どのようなものが学べます。 プロダクトオーナーやプロダクトスペシャリストは、再利用やコラボレーション、インテグレーションを通して、大きな効果が得られます。 プランナーは、インナーソースの導入による変革をどのように管理するか理解することで、複雑なインテグレーションやコラボレーションを調停したり、属人的な知識や技術的な負債を減らせるようになります。 そして最後に上位の管理者は、従業員満足度を向上したり、新しい事業ユニットや買収した企業を統合するための、新しい方法を発見できます。
端的に言うと、オープンソースには柔軟性があり、透過性に基づくグループ間の相乗効果があり、コラボレーションを推奨するカルチャーがあり、そして標準化され簡単に見つけられるドキュメントを用いることで学習曲線を大幅に改善しているという特徴があります。 オープンソースには、メンターに対する敬意を持ち、コントリビューションを負担と考えずにギフトと考えて自発的に参加する開発者がいます。 透明性や広範なコントリビューションで、より多くのユーザのニーズが満たされるようになっています。
OSS(Open Source Software) は、「勝利した」と言われています。 Fortune500に掲載されている会社は、何らかのオープンソースプロジェクトを利用したり、そこで活動したりしています。 オープンソースコミュニティにおける主要なプレイヤーである Sonatype は、2014に大企業を対象に行った調査で「今や典型的なアプリケーションの90％以上がオープンソースコンポーネントとなっている」ということを明らかにしました [1-2]。 OSS の主な強みのひとつに、欠陥密度が産業界の平均よりも一貫して低いということがあります [1-3]。
しかし、 企業内 でオープンソースの力はどのように役に立つのでしょうか。 現実的には、ほとんどの企業が、規制や契約上ソースコード共有が禁止されているなどの理由で、オープンソースの力を活かすことができていません。 ここでインナーソースの出番となります。 インナーソースは、オープンソース・ソフトウェアの活動から学ぶことを、企業内のソフトウェア開発に活かす方法なのです。
インナーソースはオープンソースの利点を企業文化に取り入れることで、企業がオープンソースコミュニティでより良い活動者となるのに役立ちます。 その重要なゴールには、次のものがあります。
企業内のコラボレーション改善方法を学ぶ
企業内で洗練されたコードの作成を促進する
ボトルネックを減らす
チーム間連携を促進する
大きな変革を素早く起こすことは、ほとんどの企業にとって大変困難なことです。 急激な企業文化やプロセスを変更は、状況を改善させるのではなく、悪化させてしまうことがあります。 これがトップからの強要で、関係者からの賛同が得られない場合はなおさらです。 インナーソースの仕組みをうまく機能させるためには、効果測定しやすい小さな活動から始め、状況に応じて折り合いをつけながら柔軟に進めることが重要です。 こうすることで、大きな変革を起こす前にインナーソースはどのような効果があるか関係者が理解でき、混乱を最小にできます。 実際に、ある部門の１チームからインナーソースを始めるのが効果的です。
企業全体にオープンソースの方法論適用を決めることは、特に新しいことではありません。 オープンソースが提唱されて以降、多くの人々が同様の方法を用いてプロジェクトに取り組んできました。 オープンソースプロジェクトに関わる人の多くは、その方法論を職場に適用したいと考えるため、こうした決定がされることは自然な流れです。 「社内オープンソース」、「エンタープライズオープンソース」、「ビジュアルソース」、「コーポレートオープンソース」など様々な名前を用いてオープンソースの方法論を企業に適用するための説明が行われてきましたが、今まで成功した人はほとんどいません。 現在用いているインナーソース(InnerSource)という用語は、15年以上前に Tim O’Reilly が提案したものです。 提案当初は「 Inner Source 」としていましたが、単語間のスペースを削除して用語検索しやすくしました。
インナーソースの方法論を広める活動は、それぞれの企業で個別にオープンソースの開発方法を社内適用する活動をしてきた人たちが、オープンソースコミュニティで知り合い会話を始めたことから始まりました。 そして、オープンソースの開発スタイル[1-4] を取り入れたオープンなコンソーシアムを設立して、インナーソースの定義や標準を作成し、その維持に取り組んでいます。 こうすることで、オープンソースのリーダー達は、時に困難が想定される企業内でもインナーソース本来の考え方や文化を維持できます。 この活動の重要なポイントの1つは、チャタムハウスルール (Chatham House Rule) を厳格に適用していることです。
会議の一部や全体がチャタムハウスルールで行われる場合、参加者はその会議における発言者を含む参加者全員の身元や所属を明かさないというルールに従う限り、その会議で得た情報を自由に利用できます。
チャタムハウスルールのようなシンプルなルールを作ることは、インナーソースの活動にも活かされています。 誰もが守れる簡単なルールを作成することで、変革の効果を最大にできます。 しかし、商慣習がある中での透明性の確保は大きなハードルでした。 透明性を確保するというルールは、たとえ競合相手であってもオープンにコラボレーションする方が、より大きな効果を得られる場合があるということを認識するためのものでもあります。 グループとして協力し合う中で、互いに失敗を認めて情報や不満を共有することで、問題をより素早く解決できるようになります。
本来、チャタムハウスのルールはオープンソースに必要ないものですが、インナーソースの活動開始と発展には重要なものでした。 インナーソースの定義や標準の作成に関わる人のプライバシーを尊重しつつ透明性やオープン性を確保することは、この活動の特徴と言えます。 今でも、プライバシーと透明性の両立という二律背反な状況のバランスを取りながら活動しています。
ジョークやユーモアには長い伝統があり、(例えばカーゴ・カルトで竹を使ってハリボテの飛行機を作るのは何故かという事と同様に)それをよく理解していない子供ですら見様見真似していることがあります。 しかし、ユーモアという言葉には相手を単に笑わせるだけでなく、相手への配慮をもって傷つけずに笑わせるという側面もあり、相手の理解はとても重要です。 残念ながら企業がオープンソースの方法論採用で失敗する原因の多くは、この方法論の本質の理解不足にあります。 なぜオープンソースが成功するか、その本質を理解せずに実践について語るだけではオープンソースの方法論を上手に採用できません。
ほとんどのビジネスドキュメントは、「なぜ」それが必要かという事より、「どのように」それを行うかを強調しています。 ビジネス環境は、往々にしてプロセスを決めるより早く変化します。 本書は、「なぜ」に着目して書かれており、新しいプラクティスの成功可能性を高める適切な環境作りに配慮しています。 本書の末尾にインナーソースを開始するためのチェックリストを掲載しています。これを見れば、なぜそのようなプロセスをとったのか、その背景や関係者との関わりついて学ぶことができます。 インナーソースを企業に取り入れることは一筋縄ではいかず、この本の事例を真似しても全ての人がうまく行くとは限りません。 なぜ 新しいルールやプロセスが必要で、それが有効かを学ぶことで、個々のニーズにあったプロセス、つまりは「自分の やり方 」を見つけてください。
もちろん、早く先に進みたければ、この本のチェックリストやウェブサイトはスキップできます。 しかし、「なぜ」を簡単に理解できる工夫が各所にあります。 各章の最初には要約があり、問題とその解決のための最小のステップ、さらにはその解決策が有効な理由を解説しています。
[1-1] 6章に詳細があります。
[1-2] Wayne Jackson, “The 2014 Survey: Marked by an Industry Shock Wave”, The Nexus, June 20, 2014.
[1-3] Coverity 静的解析年次レポートより。最近では “Coverity Scan Report”
訳注：原著では Coverity Scan Report 2013 へのリンクがありましたが、邦訳を執筆している2023年5月現在は存在しないので、2017年版に差し替えています。
[1-4] 具体的には Apache Software Foundation のスタイルを指します。
要約
トラステッドコミッターには、コントリビューション協定の記述を通じてコントリビューターにハウスルール[5-1] を説明する責任があります(例えば、コード規約や依存関係等)。コントリビューション協定は生きたドキュメントです。
コントリビューターは「良き来客」となり、コントリビューションの前にアグリーメントや他の目につくドキュメントを読む必要があります。コントリビューターが協定に沿って整ったコントリビューションをするほど、それが受け入れられるようになります。
マネジメントはトラステッドコミッターがこれらのアグリーメントを作成することを支援する必要があります。
アグリーメントを標準化することは、トラステッドコミッターのオーナーシップが低下することにつながるので慎重になる必要があります。複雑なアグリーメントはコントリビューションの妨げになるので、リスクの高いプロジェクトに限定されるべきです。
トラステッドコミッターは、壊れたコードや、適切にテストされていないコード、ドキュメントが書かれていないコード、彼らのコーディングスタイルから乖離したコードを受け入れ、オーナーシップを持たされることはできません。 コントリビューション協定は、それらの責務をコードを書いた開発者が担えるように形式化する方法なのです。
トラステッドコミッターは、コントリビューション協定 を記述して所有します。 コントリビューション協定があることでハウスルールは明確になり、コードによるコントリビューションをトラステッドコミッターが受け入れるために必要なことをコントリビューターに知らせることができます。 コントリビューション協定は開発に携わるすべての人の目に触れられるものです。 アグリーメントには、トラステッドコミッターの名前や連絡先、スケジュールが記載されていなければなりません。 それ以外の内容はトラステッドコミッター次第ですが、以下の点が書かれていると良いでしょう。
トラステッドコミッターの専門領域
コミュニティ・ガイドライン
コーディング規約
テスト記述の規約
ブランチ作成の規約
コミットメッセージの規約
良いプルリクエストを作成する方法
機能リクエストの提出方法
不具合報告の提出方法
セキュリティ上の問題の報告方法
ドキュメントの書き方
完了の定義
依存関係
ビルドプロセスの流れ
スプリントの流れ
ロードマップ
トラステッドコミッターは、プロジェクトを保護するためにこれらのアグリーメントを利用できるようにしておくことが重要です。 トラステッドコミッターは、もし他のチームによるコントリビューションが指定に従っていない場合、コントリビューション協定を参照しつつ、なぜコントリビューションが拒否されているかを説明できる必要があります。 そうすることは、社内政治や、より広範に渡る問題を最小化することに大いに役立ちます。
コントリビューション協定は、コントリビューターの期待値を管理するためにも重要な役割を果たします。 私たちは、宿泊客にとってのハウスルール[5-1] を比喩として使います。 全員が同じ道徳規範に従っていると思い込むのではなく、宿主が宿泊客に自らの期待値を伝えれば物事はスムーズに進みます。 壊れやすいものがたくさんあり、整理整頓されたキッチンで普段から過ごす人と、程よい生活感のある部屋や猫の引っかき傷のある家具に囲まれて生活している人とでは、異なるハウスルールを持つことになるでしょう。
そして宿主は、電子レンジと食器洗浄機を同時に動かそうとするとブレーカーが必ず落ちてしまうといったような、家の中にある予測のしづらい構造については予め客に注意を促さねばなりません。 コードに関するそのようなハウスルールや落とし穴を一覧化して配置するのに、コントリビューション協定は理想的な場所です。 そうすることで、それは明確に書かれたハウスルールのように、客が損害を被ったり、誤解をしたり、嫌な感情を覚えたりすることを未然に防ぎます。
ここまでの比喩は、コントリビューターの取るべき行動にも当てはまります。 善良な宿泊客は提示されたハウスルールに従いますし、当然のことながらルールにかかれていないことでも率先して整理整頓をするでしょう。 つまり、目についた不具合を回収したり、リファクタリングを施すこともあります。 そして 素晴らしい 宿泊客はボトルワインを持ってきてくれることさえあるでしょう。 素晴らしいコードベースの「お客さん」は、新しい機能の開発にコントリビューションしてくれたり、誰もが待ち望んでいた修正をしてくれるかもしれません。
多くのコントリビューターは、自分の行動や成果物がコントリビューション協定により従うほど、それがより早く受け入れられコミットされると気づくでしょう。 また、より寛大なコントリビューション協定を見れば、変更を提案したり提出することのリスクはより低いとわかるでしょう。
オープンソースの世界では、団体が異なればコントリビューションする際のルールも異なります。 違いのほとんどはリスクに関することです。 Linuxカーネルは、非常に厳しいコード提出のガイドラインや、単純なコントリビューション協定よりも遥かにプロセスを敷いています。 一方で、Node.js のモジュール開発は非常に寛大であり、プロジェクトに関わる人々には自分の作業が誰かの試みの重複になっていないかを検索を通じて確認するように求めている程度にとどまっています。
このような多様性が存在することは、ひとつの企業の中でいろいろなプロジェクトがあることと似ています。どんな企業でも、失敗すれば会社が傾いてしまうことが避けられない中核のプロジェクトがあり、そのプロジェクトには厳密なコントリビューション協定が求められます。 一方で標準化することが望まれるツールも存在し、これは比較するとかなりリスクの低い活動だと言えます。 そのツールを開発しているチームはよりシンプルなコントリビューション協定を敷き、人々がコントリビュートしてくれるように誘い出す柔軟さをもつべきでしょう。 時に、このようなリスクの低いコードベースはコントリビューターがインナーソースプロジェクトに参加する方法を学ぶのに安全な場所となるでしょう。
コントリビューションの作成では、安全性と参加しやすさのバランスが問われます。 短く簡単な協定は、コントリビューションが歓迎されていて、その過程でトラステッドコミッターたちが助言や支援をする意思があることを示すことになるでしょう。 長く、より複雑な協定はプロジェクトの難しさやリスクを伝え、そしてコードが受け入れいられるまでにコントリビューターはいくつかの関門をくぐり抜ける必要があるという事実を告げることになります。
会社全体で標準化を進めて1つのコントリビューション協定を標準化しようと試みたことのある企業も存在します。 これは大企業が無意識に取る行動としてはいたって自然なものです。 しかし、私たちはこういった企業の取組には反対してきました。 なぜなら、会社全体に適用させる協定はトラステッドコミッターからオーナーシップを取り上げることになり、企業にとっても彼らの同意を得ることが負担になるからです。 また、これまで述べてきたような柔軟性を失うことに繋がってしまうのももうひとつの理由です。 代わりに、トラステッドコミッターのための出発地点として、様々なリスク水準や複雑さに適応できるコントリビューション協定の雛形を作成します。 加えて、私たちは、振り返りの後や、新しいトラステッドコミッターが加入したタイミングなどに、コントリビューション協定を読み返し必要な更新を加えるよう、トラステッドコミッターたちに依頼しています。 コントリビューション協定は生きたドキュメントであり続けることが不可欠なのです。
[5-1] (訳注) 一般にハウスルールとは、特定の団体や組織でのみ適用される規則を指しますが、この章では宿泊施設を比喩として持ち出し、プロジェクトのオーナーを宿主、コントリビューターを宿泊客、ハウスルールを宿泊規約と例えています。
[5-2] (訳注) 原文では "Mi Casa Es Su Casa" と記載されています。これは直訳すると「私の家はあなたの家」ですが、転じて「気楽にしてね」という意味で使われます。
インナーソースを行うにあたり多くのツールが必要です。 こうしたツールには、議論を促進するもの、標準化やコンプライアンスを支援するもの、測定と結果のレポートを支援するものがあります。 InnerSource Commons では、こうしたツールをオープンソースで開発しています。 是非、ご参加ください。
例えば、 Agora というツールはエンタープライズ検索のためのものです[8-1]。 多様なデータソースを従業員が簡単に追加できるオープンなシステムを目指しています。 これによりツールやドメインを超えた検索が可能になります。
Commons では成熟度モデルについても議論しています。 その最初のステップとして、 GitHub や GitLab から得られる指標について議論しました。 複数のデータソースから、再利用やコラボレーション状況の測定をしたいと考えましたが、 そのためには少なくともデータを取得しなければなりません。
私達は、 InnerSource Commons という組織を立ち上げました。 既に50名以上のメンバーがおり、そのほとんどは大企業から参加しています。 私達の最初のゴールの1つは、インナーソースの標準を作ることです。 そこで、メンバーの経験をもとに、インナーソースパターンを作成しています。
こうした情報を広めるにはいくつかの方法があります。
インナーソースに興味を持つ人や会社が学べるように、(本書のような)トレーニング資料を含む本をオライリーメディアの協力を得て出版しています。
カンファレンスで使用した資料を30分程度の講義資料にまとめました。
InnerSource Commons のサイトにを掲載しています。これらの資料について何かコメントがあれば、是非 InnerSource Commons のサイトや などでフィードバックをお願いします。
Commons で進行中の最も大きなプロジェクトに、インナーソース実施の課題に対処するパターンを作成することがあります。 Leonardo da Vinci は、解決困難な課題の解決を自然に求めました。 私達 が解決困難な課題に直面した時、オープンソースとして作成されたこれらのパターン集の中に類似のものがあれば、その解決方法を参考にできます。 そこで、次の5つのポイントを含むようにパターンの作成します。
問題についての解説
問題を一段上から広く見たときの状況
解決策発見にあたり注意すべき点
考えられる解決策
解決策を用いた結果生じる新しい状況
ありがたいことに、この動きは素早く順調に進んでおり、
原題:
著者: Silona Bonewald
発行日: 2017年5月
発行元: O’Reilly Media
翻訳: InnerSource Commons Japan
要約
チームを分けると情報のサイロ化が進み、意思決定に支障が起きがちです。
そうした場に透明性を再度もたらすには、ドキュメント作成のルールと、重要な意思決定をする会議のルールが必要です。
イギリスの人類学者である Robin Dumbar の説によると、群れを作る動物が快適だと感じる群れの個体数は、その動物の大脳新皮質の大きさに依存します。 この数はと呼ばれ、人間においては約150人だとされています。 また、その中でもより小さな50人ほどの集団と強く結びつく傾向があるそうです [7-1]。 これが部族の大きさを決める法則だと考えられます。 会社で働いたことのある人であれば、組織構成図において似たような上限が描かれていることを知っているでしょう。 サイロとは、そうした組織階層を作ることの延長上に自然と現れるのです。 人を専門性で分けようとするときにもサイロは現れ、その区分における部族的知識が生まれるのです。
サイロがあれば、各サイロ内の意思統一をそれほど気にかける必要はありません。 小さなグループでは、コミュニケーションも許可を得ることも簡単になるのです。 それぞれのグループに誰が属するかを決めれば説明責任も簡単になります。 例えば、セキュリティに問題があれば、それはセキュリティグループの責任だ、と言えるようになるのです。
サイロ同士でコミュニケーションをとることが難しくなり、組織内で問題が連鎖することは多くの読者が想像しているでしょう。 壁を超えたコミュニケーションの心理的な影響は、超えずに済む場合と決して同じではないのです。 あなたが作ってしまったバグによって、個人的なつながりもある顧客担当者からの通話が荒ぶるのを聞けば、物事を正しく理解することの重要さがわかるでしょう。
事業の統合や買収が進む現代では、サイロはチーム同士のコミュニケーションの大きな障害となります。 その障害とは、あらゆる承認を得ることを泥沼化させる生産性への大ダメージであり、川上のサイロに閉ざされた部族内知識を得ようと上流へ泳ぐようなものです。 巨大企業では、承認を得るための道筋がジャングルのように入り組んでおり、その図示を試みることがあります。 しかし、図を描いている間にツルが伸び続けるため、負け戦であることは確定しています。
ここまでの記述で、コーディングには様々な面で透明性が欲しいと想像できたのではないでしょうか。 これは科学と学術でも同様で、厳密さのための核となる考え方なのです [7-2]。 そして、学術で透明性が働くのと同様に企業でも機能すると私たちは確信しています。 透明性はコラボレーションを改善し、プロジェクトを脱線から軌道修正できる力を全ての社員に与えるのです。
世の中のビジネス事例で、顧客とのコミュニケーションに透明性があることの価値を学んだケースは多いことでしょう。 Facebook、Twitter などのソーシャルメディアによって、顧客は公共の場で問題を解決できる力を得ました。 企業は、問題を効率的に解決する姿を見せることによって、顧客の信頼を得ることができるようになったのです [7-3]。
多くの組織では、複数のチームをまたぐ意思決定へ関与できないことに大きく悩まされています。 そうした社員は「中で何が起きているかわからないから判断できない」と言うでしょう。 本書がインナーソースの文化として提唱している明文化とオープンな会議は、この問題を解決するための長い道を進むでしょう。 社員が意思決定に関与するには、ドキュメントとしての情報、情報への到達、そして情報を閲覧する許可というインナーソースの文化の3種が必要なのです。
サイロによる問題がコミュニケーションの阻害と部族的知識の非公開だとすれば、その解決策はオープンなコミュニケーション方法を確立し、ドキュメンテーションを見つけられるようにすることです。
これまでの章で述べたように、そのどちらも同じプロセスで実現できます。 インナーソースへの道はサイロを壊す道と同じであり、以下に示すものです。
ソフトウェアやチームへの期待と要求を記すドキュメントの作成に責任を持つ役割を定める。この役割は、ドキュメントに記された変更の影響を受ける人々に働きかける必要がある。
ソフトウェアの統合を計画する段階において、その計画を明文化し、計画の議論に関係者をできるだけ呼ぶためのプロセスを作る。
議論の場と連絡網は決まったものを用いることを義務付ける。
そうしたコミュニケーションを会社の誰もが閲覧できるようにする。
議論の結果を発見可能な場に残す。
新しい役割が増え、他のメンバーも会議やオンラインでの議論へ関わるようになります。 これにより、プロジェクトの進行が遅くなるというコスト増の可能性があります。 ですが、そのコストに対するメリットは早くやってきます。
現代人は、欲しい情報を検索することに慣れています。 メールも検索すればよくなったので、時間をかけてフォルダに振り分ける方法は過去のものになりつつあります。 一方、企業で必要なドキュメントを探すことは宝探しのようです。 これに対する私達の目標はドキュメントを作る方法を改善することですが、改善するのは書き方ではなく検索可能性です。 ドキュメントの検索可能性とは透明性の一部なのです。
ドキュメントがアクセス可能であり理解しやすい場所に置かれていることは、透明性とコラボレーションにとって重要なことです。 ドキュメントの作成は優先度が低く、熱意を持って取り組む人は少ないものですが、学習曲線が劇的に短縮し、コラボレーションを容易にし、誤解を防止できます。 そして、インナーソースが適切に実施された副次的な結果として、広範かつ検索可能性の高いドキュメントが得られます。
企業がインナーソースを目指す過程で、コミュニケーションの追加という時間的コストが発生します。 しかし、早い段階からパッシブドキュメンテーションというプロセスを整備して、その追加されたコミュニケーションを残すことができれば、その記録(ドキュメント)は未来を加速させる財産になるでしょう。 うまくいったこと、いなかったことからの学びは組織にとって常に有用なものですが、そのために努力する企業は少ないものです。 情報を残さないことは責任の恐れによる場合があります。 ただ、社内に公開された場所で何らかの会話がなされれば、おのずと社員はその影響に気づき、より質の高い会話が残されてゆくでしょう。
パッシブドキュメンテーションの実現方法を社内のあらゆる職種や部署で検討しましょう。 方法は、開発者が使う GitHub, メーリングリスト、Slack だけではありません。 パッシブドキュメンテーションによって、書いた当事者以外が知識を必要としたときに得やすくなります。 また、パッシブドキュメンテーションに対する質問や感想といったフィードバックは素早く伝わり、適切な回答も得られます。 Slack に代表されるサイロを超えられるコミュニケーションツールは、コラボレーションの加速に大きな価値があるものです。
類するドキュメントは既に社内に断片的に存在していることでしょう。 インナーソースコモンズにいるメンバーの多くは、複数の部署やツールに対応した大きな検索方法を求めています。 しかしながら、検索して見つけた情報から何が起きていて誰の意志によるものかはわかっても、その内容を変更したり議論に加わることは検索ツールではできないのです。 その情報を作るのに使われたツールを開く必要があります。 その点、Slack は議論の推進と記録の両方に長けていることを多くの企業で証明しています。
また、コラボレーションを創出する優先度が高いことを経営レベルで判断することも重要です。 インナーソースへの移行に伴い、コミュニケーションコストは一時的に上昇します。 これはどの企業の移行でも共通することです。 しかし、早期にチーム間でコラボレーションすることは大きな利益を生みます。 部署の統合や買収した企業の統合にかかるコストは億単位であり、統合の頻度は度重なるものです。 本節で述べたドキュメントの検索可能性を高める活動に取り組むことによって統合も促進され、さらなる統合や買収が可能となります。
インナーソースを実践している我々は、コードの透明性については GitHub の活用によってクリアしています。 計画とコミュニケーションの透明性を高める活動についても始めています。 それでも、まだやれることがあるのです。
多くの場合、ツールそのものが部署間の透明性を妨げています。 ユーザー単位で費用が決まる商用ツールでは、全社員にアカウントを発行することが財務的に難しくなるからです。 この解決策として、現代のツールが API を備えていることに着目して、Zapier や IFTTT を用いて、当該ツールのアカウントを持っていない社員もツールから情報を得たり書き込んだりできるようにする方法が挙げられます。
営利企業では透明性に厳しい限界があり、オープンソース組織との大きな相違点です。 特に、上場企業、多数の政府との法的遵守を考慮する必要のある多国籍企業では顕著です。 もう1つの落とし穴と言える点はリモートアクセスの管理であり、これも規制が大きく影響しています。 透明性のためのソリューションを検討する際には、技術面だけでなく、これらの問題を考慮する必要があります [7-4]。
オープンソース組織に対して、世界に情報公開する仕組みや支援を期待する企業がいます。 しかし、インサイダー取引に接触しないように情報公開するには、企業自身の努力が必要です。
とはいえ、失われた部族的知識を取り戻そうとする動きは、生産性と社員のモラルを高めるインナーソースによって加速されており、前述の限界や落とし穴があるとしても投資価値ありと確信する企業が増えています。
過剰な情報が生まれ、コミュニケーションも過剰になるのではないか？という落とし穴も考えられます。 これに対しては検索が重要になります。 情報を必要とする人に対して情報を持つ人が継続的に更新を通知するというプッシュ型よりも、必要なときに必要な情報を検索できるというプル型に企業文化を移行させるべき、というのが著者らの意見です。
(訳注) ダンバー数については、"友達の数は何人？ - ダンバー数とつながりの進化心理学" (2011, インターシフト) という邦訳書があります。
[7-4] (訳注) 例えば、外為法による輸出規制はグローバルなソフトウェア開発体制に影響します。
[8-1] (訳注) 2023年5月現在、 に Agora は見当たらない。
[7-1] Ipsita Priyadarshini, , visiontemenos.com.
[7-2]
[7-3]
要約
計画段階において、透明性はとても重要です。我々の経験上、組織内での透明性を確立することで、外部からのコード受入れ件数は桁違いの向上を見せる事がわかっています。
組織内での正式なプロセスを作成し、定型化することで、全員が共通認識を持てます。
もし仮に透明性が無く、意思決定の背景や理由を知らないようであれば、従業員はコードの修正提案を行う事ができなくなります。 トップダウンによるマネジメントは複雑で、めったに機能する事はありません。オープンな共創こそスケールするのです。
インナーソースとオープンソースの最大の違いは、企業における事業構造や制約に起因します。 企業の中では往々にして組織階層や権力が存在しますが、これらは透明性と個人の主体性を重んじるオープンソースの文化に反してしまいます。 一方で、ビジネスの世界ではオープンソースから学べる場合が多々あることも事実です。 では、どのように我々はオープンソースの基本的な文化を薄めることなく、企業内に応用していけばよいのでしょうか？
私たちの最大の成功は、企業組織の中において既に存在している鍵となるような力を発見し、それをどう活用するかにありました。 現状のプロセスを見直し、それらをインナーソースに向けて小さく修正していくための方法を見つけるのです。 私たちは透明性や所有権について議論することなく、 なぜ ではなく どのように を考えながらビジネス環境の要望に応え、結果を改善するための明確な手段をシンプルに相手に伝えています。 適応性を高め、大きな組織が変化に対する拒絶反応を起こさないようにするためにも、変更は出来るかぎりシンプルにするのがベストです。
例えば、私たちのコントリビューション協定を作成するためのプロセスは非常にシンプルで、要求事項はほとんどありません。 コントリビューション協定はトラステッドコミッターが所有し、他のチームからも閲覧が可能であり、トラステッドコミッターの連絡先や予定が書かれています。 むしろ、トラステッドコミッターの連絡先と予定以外には何も強要していません。 もちろん、他の情報も多く記載される事は推奨していますし期待しています! ゲストコントリビューターが直面する問題は、コントリビューション協定の追加や変更を経験する理想的な学習体験になります。 これは誰かの家に泊まった時、その家の家主が深夜2時以降は音楽を大音量で流してはいけない、というルールがあるのと同程度です。
トラステッドコミッターのプロセスで重要なのは、その変更の影響を最もうける従業員には、それを管理するためのより大きな権限を持つという事にあります。
これらのシンプルな要求事項に加え、トラステッドコミッターがコードの変更を受け入れるか拒否するかのルールというのは、比較的小さいもので、インナーソースプロセスに対してあまり警戒されません。 しかし、こうした要求事項は次の結果につながるのです。
トラステッドコミッターには、新しいプロセスに関与するという大きなインセンティブが生まれます
協定に連絡先が掲載されていれば、すぐによいコミュニケーションとドキュメンテーションが始まります
明確に期待している事がドキュメントに書かれていれば、更に良いコラボレーションへつながります
コードの変更は、更に迅速なポジティブフィードバックループへつながります
多くのコードを変更し、トラステッドコミッターがより多くのメンタリングを行う事は、結果として多くのドキュメンテーションにつながります
トラステッドコミッターは自分達のコードと外部への影響について更に深く理解する事になります
要求事項を必要最低限に抑えることにより、チームのプロセスをチーム固有のニーズ(オープンソースの信念)に合わせることができます。 そして、良いコラボレーション、良いインテグレーション、ボトルネックの低減、整理されたコードというインナーソースの目標にもつながるのです。
トラステッドコミッターとコントリビューション協定を活用しインテグレーションを加速させることに成功した後、製品を企画するプロセスにおいても同様の必要性を感じました。 製品のライフサイクルにおけるあらゆる側面を注視している製品スペシャリストは、チームや製品間のサイロをなくし、社内にある他の製品とインテグレーションできる方法を常に考える必要があります。
また製品スペシャリストは他チームと適切に交渉しつつ、実装すべきフィーチャーの優先順位を決める事ができる能力と知識が必要になります。 しかし、製品のコードや製品のインテグレーションに関わっている人でさえ本来は腰を据えて他のチームとじっくり議論しなければならないと 知っていつつも 強制されない限り時間を作らないものです。 元の予定に無かったものは、簡単に後回しになります。 その結果、コミュニケーション不足、遅延、誤解を生じさせます。 これを正すための手段は、正式なプロセスを変更し必要な会議を必ず開催すると同時に、適切な参加メンバーをより多く集め、透明性を高め、サイロ化された考え方をより多く壊していく事となります。 製品スペシャリストとは、このオープンなプロセスを改善するために協調しています。
プロセスを円滑に進めていくためには、全てのチームが最初の企画段階から参加する事が不可欠となります。 ストーリーグルーミングのプロセスでは、主要なコードのオーナーだけでなく各チームの代表者が参加する必要があります。 ときにチーム間で優先順位は異なり、それらは相反することもあります。 各チームの企画者が集まることで、全てのタスクが完了するために何が必要か互いに話し合う事ができます。 インクルージョンによって協業は更に円滑になります。
企画段階での透明性も同時に重要で、対立の減少に役立つと我々は考えています。 お互いの会話がパブリックな記録に残すつもりで行われると、参加者は全体によってより良い優先順位を考えられるようになる事を発見してきました。 つまり、サイロ化の考えに打ち勝てるという事です。
企画会議に参加する人数を増やした事で透明性が更に高まるという側面もあります。 トレードオフの議論をする場に、より多くの人が参加できるからです。 また、行った変更がたとえ小さなものだったとしても、関連するチーム同士の全ての会話をパッシブドキュメンテーション(4章)として保存しておく事は非常に重要です。 これは、将来に渡り過去にどんな会話があったかをチェックできると同時に、チーム同士の会話のあり方自体を変えるという事を意味します。 そして、会話が自動的に保存されていくということは情報の過多を防ぎ、検索性を向上させ、スパムをへらすことにも繋がります。
通常多くの企業では、プロジェクトやリソースをどう優先順位付けするかという議論を密室の中で行います。 そのため、従業員はその優先順位を説明するためには独自の物語を考えなければなりません。 ここでも なぜするのか ではなく、 どうするのか という事に焦点をあてなければ、その都度物語を考えさせられるはめになり、改善に向かえません。 不透明であるという事は、社員の意思決定のスピードを遅らせエスカレーションのプロセスも悪くなる要因となります。
プロセスを透明化する事で、メンバーは必要に応じ軌道修正ができるようにもなります。なぜなら、本当のゴールを理解することで、誰かに指示されたものの間違った成果に繋がるやり方を妄信的に進むことがなくなるからです。 加えて、優先順位付けとリソース配置の透明性を高めることで、組織階層から生じる権威への不安や、実際にその権威の出現は少なくなります。
私達はシンプルなルールから着手しました。 リスクや需要が大きいコードベースでは、計画を形式化する必要があることがわかりました。 そこでプロダクトスペシャリストとTCが協力し、外部のコントリビューターが重要な変更を提出する際にはイシューリクエストの提出を義務付けるよう、コントリビューション協定にルールを追加しました。 ここでの"重要"とは、Rallyにおける３以上のストーリーポイントを使用する事を意味します。 このルールは、両チームの製品スペシャリスト同士、またコントリビューターとTCが協調する事を必須とする、強固なプロセス形成のための第一歩となりました。
他のコードベースではこのような形式ばったミーティングは必要となりませんでした。 その代わり、決められたコミュニケーションチャネルの中で、潜在的なコントリビューターがTCと製品スペシャリストに事前に連絡しておくことをコントリビューション協定の中で定めています。 繰り返しになりますが、柔軟な適用性がキモとなるのです。
計画段階から関連メンバを巻き込むことは最初はリソース上の問題を引き起こします。 たとえば、大勢のメンバーの都合のつく予定を見ながら会議を設定する事が難しかったり、会議自体が予想よりも長引く事もあります。 また、会議に参加しなければならないメンバーは他の業務を後回しにしがちです。 しかし私達はそれ以上の価値をすぐに理解しました。 チームメンバーは優先順位付けのプロセスを今まで以上に理解しはじめ、アジャイルプロセスの改善に活かされました。 一方でコアチームが外部からのコードを取り入れるスピードは非常に大きく改善されました。結果として、計画段階に費やされた時間の10倍以上を補填する事にまで繋がりました。 そして、何年もの間バックログに放置されていたコントリビューターチームの要望を完了できたのです。
より多くの人を巻き込んでプロセスを開かれたものにし、高い透明性を確保することは組織間のコラボレーションを行うにあたって非常に良い効果を発揮します。 これによって、チーム内・チーム間を問わずより効率的な意思決定が出来るようになりました。 また、パッシブドキュメンテーションを徹底することによってコミュニケーションの質自体も改善し、結果として会議時間の縮小にも繋がる事もわかりました。
初期段階でコミュニケーションを増やすには、外部からのファシリテートが必要であることがわかりました。 重要なのは、会社にとってWin Winとなる解決策を常に模索し続け、より効果のあるコミュニケーションを製品スペシャリストに徹底してもらうよう働きかけた事です。 この期間は比較的短く終わりました。チーム間で物事が円滑に進むようになった後はコラボレーションが劇的に増加し、外部からの支援はほとんど必要がなくなりました。
私達の大きな目標を実現するために、PayPal 内のチームは抜け目がなく非常に複雑な交渉を共同で進めました。 ある製品スペシャリストは我々が実際にインナーソースチェックリストに追加した簡単なプロセス変更を考案しました。それは、製品スペシャリストは HELPWANTED.md というファイルを自分たちで作成し、所有しなければならないというものです。 彼らは透明性を保ちつつ、このバックログをファイルの中に記載して掲載できます。 通常、作業対象のコードリポジトリを探している開発者たちは、たとえアクセス権があったとしてもプロジェクト管理ツールの中まで調べようとは思いません。 よって、 HELPWANTED.md をコードリポジトリに設置する事となるのです。 繰り返しますが、発見のしやすさは重要です。
いくつかの良くできた HELPWANTED.md は、ノートや優先順位付けのレベルも含め、プロジェクト管理ツールから生成されました。 これはゲストコントリビューターが他のチームが求めていることを知るのに大きく役立っています。 潜在的なコントリビューターは自分達の抱えているプロジェクトと近しいストーリーを見分けやすくなり、最もコントリビューションできそうなものを選びやすくなります。 HELPWANTED.md は、Win/Winの精神に大きく寄与しています。 コントリビューターは他のチームのバックログの中にあるアイテムをこなす代わりに、自分達が追加したい変更をレビューリストの上位に移動するといった取引ができるようになりましたし、実際に行っています。
アリストテレスの言葉とされる「全体は部分の和より大なり(The whole is greater than the sum of the parts.)」に初めて出会ったきっかけは、ソフトウェア工学の名著であるピープルウェアでした。 その言葉は、大きな会社でソフトウェア工学技術の向上を担っていた私にとても刺さるものでした。 組織のどこを見ても、全体が部分の和より小さく感じられたからです。 皆、せっかく同じ会社にいるのに、こんなに協働がうまくできていないのは勿体ない！と常々思っていました。
以降の私は、特定のプロセスや特定の職種に焦点を当てた技術ではなく、ソフトウェアライフサイクルの全体を広く支える技術に着目するようになりました。 より具体的に言えば、バックログ、リポジトリ、自動テスト、ビジネスチャット、共同編集によるドキュメンテーションが代表的なものです。 加えて、そうした情報を社員の誰もが検索できる透明性と、みんなが使うものはみんなで作るという協働も重視していました。 2016年当時の私はインナーソースという言葉を知らなかったのですが、今思えばインナーソースを志向していました。
そして、それがうまくいく仕組みは企業レベルで設計する必要があると考えるようになりました。 例えば、製品同士の親和性による共通ソフトウェアコンポーネントの需要、担当製品と所属部署を超えた協働に対する管理会計、情報システム部門と人事部門の理解、外為法に基づく輸出管理と列挙すれば、インナーソースの実現が純粋なソフトウェア工学に収まらない領域であることを直感できるでしょう。 訳者の7名は皆、そうした歯がゆい経験を重ねており、翻訳のモチベーションになっているようです。
本書は、実質的に "インナーソース入門" に続く入門書であるとみなせます。 "インナーソース入門" では、オープンソースの原則と、PayPal がインナーソースを始めた経緯が記されています。 対して、本書では、インナーソースとは何か？なぜインナーソースなのか？PayPal で工夫したことは何か？が記されています。 これらの薄い本を読めば、少なくとも1社における企業レベルのストーリーを理解できるでしょう。
日本でインナーソースはまだまだ無名だと思いますが、その内容に共感するエンジニアとマネージャーは多くいると確信しています。 本書をきっかけに、ソフトウェア開発における透明性と協働の文化に興味を持ち、挑戦する人が増えることを願います。
金子昌永 (masskaneko), 2023年6月20日
masskaneko (監訳, 2章, 7章)
ystk (1章, 8章)
yuhattor (3章)
bory-kb (4章)
mura-mi (5章)
shrimp78 (6章)
hiromotai7 (9章)
インナーソースプロジェクトを開始する事に対してプレッシャーを感じるのはその通りで、ましてや、真のインナーソースまたはオープンソース企業への移行を通じて、あなたの組織をかじ取りをするのは簡単ではありません。 PayPal 社は、自社独自の経験と、インナーソースへ移行している他社に勤める同志の経験からチェックリストを記載しています。 私たちは、あなたが何をすべきかを整理し、集中するのに役立つよう、ここにチェックリストを提示します。 もちろん、このチェックリストに素直に従うだけでは、成功は得られません。 全ての組織は、調査、議論、インナーソースの恩恵を得るための文化的に変化することを始めていく必要があります。 しかし、あなたがこのチェックリストを常に確認していれば、進捗があることがわかり安心するでしょう。
このチェックリストは、GNU宣言と Checklist Manifesto(邦訳：アナタはなぜチェックリストを使わないのか？(晋遊舎, 2011)) の両方に触発されたものです。 私たちはあなたがインナーソースにむけて少なくとも小さな一歩を踏み出し、あなた自身のチェックリストを作成し、それを私たちにも共有(展開)してくれることを期待しています。 Apache Way はチームにとって重要なインスピレーションであり、あなたもこのリストに同じような感覚を感じることでしょう。
原著では、本章は9章という扱いではなく、付録(Appendix)です。 ですが、構成的には章であり、原稿を公開している GitHub および本書を公開する Gitbook においても章として見えることから、9章と致しました。 また、原著にはセクションがありませんでしたが、見やすさを考慮してセクションを設けました。 そして、よりチェックリストらしく、Markdown の拡張形式である * [ ] を用いた記述としました。