> For the complete documentation index, see [llms.txt](https://jp-contents.innersourcecommons.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jp-contents.innersourcecommons.org/understanding-the-innersource-checklist/contents/3-the-most-important-role-and-the-first-step-trusted-committer.md).

# 最も重要な役割、そして最初の一歩: トラステッドコミッター

**要約**

* リスクの程度に関わらずプロジェクトには *トラステッドコミッター* が必要です。リスクの程度に応じ、役割の責任を明確に定義しましょう。
* トラステッドコミッターは役割としての責任に加えコーディングに対する責任も持ちます。その責任対象は行ったり来たりします。
* トラステッドコミッターは難しい役割です。その役割にふさわしく、引き受けてくれる社員には報酬を与える必要があります。
* 企業は、より統合されたコード、コードレビューの質向上、プルリクエスト応答時間の短縮、より明確なリファクタリングのノウハウ、ドキュメント作成の省力化、ボトルネックの解消といった素晴らしい恩恵をうけます。

***

前章では、私たちが直面したいくつかの文化的な問題を取り上げました。 コードの所有者はプルリクエストを受け付ける必要があります。 そうしない場合はボトルネックが発生し、上層部へのエスカレーションがおきます。 また、外部チームはコードのスタイルと標準に準拠するべく学習をする必要があります。 そうしない場合はコントリビュートした内容を大幅に書き直さなければなりません。 コードの所有者と外部のコントリビューターが協力しなければ、何も改善されず、誰もが失望することになってしまいます。

企業における開発者は、プルリクエストのレビューと承認、および他部署・他プロジェクトの開発者の育成に時間を割くことを望まない傾向があります。問題の多くは、これに起因しているのです。 ただしそれを責めることはできません。 一般的には、全ての人は自身にアサインされたタスクや目標を持っています。 それは彼らのプロジェクトに対するものであり、たまたまコードベースを触ることになった誰かのプロジェクトに対するものではないのです。 そしてほとんどの人は、自分が書いていないコードに対して責任を負うことに抵抗があります。

しかし、インナーソースが機能するためには、一部の開発者がサイロの外に責任を負わなければ\_なりません\_。 そのため、私たちは責任を定義した新しい役割をつくり、それをトラステッドコミッターと呼ぶことにしました。 これは、私たちがこれまでに実施した最も基本的な変革であり、インナーソースを機能させるために不可欠なものです。 事実として、トラステッドコミッターを取り入れることはインナーソース実現への第一歩です。

## 役割を定義する

トラステッドコミッターには以下のような責任があります。 (各項目は、トラステッドコミッターのチームがより良いコミュニケーションと協業を実現するために役立ちます)

* コードベースへのコントリビューションに対するルール作成と管理
* 受け取るコード(プルリクエスト)のレビュー
* 他領域からのコントリビューターへの助言
* プルリクエストのマージ
* リファクタリングやモジュール化作業へのリーダーシップ
* チケットやチャットにおける議論への参加
* 連絡事項の周知
* コラボレーション機会の新規開拓

なおオープンソースの世界では、多くのグループが独自に同様の役割を進化させていることを指摘しておきます。 私たちは特に [Apache ソフトウェア財団](https://www.apache.org)が開発した提唱した理念である["The Apache Way"](http://theapacheway.com) を借用しています。 これらの役割は、プロジェクトに高いレベルの貢献をした人に与えられます。 トラステッドコミッターは、コードに対する最終的な責任を負っており、しばしばコードのゲートキーパーとなります。 これらの役割における力の程度は、ときにリスクの大きさと直接的な関係を見ることができます。 例えば、Linuxカーネルは広範囲に渡っておりリスクが高いため、Linuxカーネルではトラステッドコミッターの役割を Janitors と Mentors のレベルに分けています。 一方で Node.js のモジュールは非常にローリスクです。 コミュニティは精査後に新しいモジュールを受け入れないかもしれませんが、新しいモジュールが何かを壊すことはできません。 そのため Node.js にはトラステッドコミッターの役割はありません。Node.js のモジュールは、誰でも npm で公開できます。

## 役割に磨きをかける

さて、トラステッドコミッターの役割を定義した後、新たな問題が見つかりました。 開発者はコードから引き離されてしまうことを恐れ、この役割を好まなかったのです。 なぜならその多くはコーディングの時間を失いたくなかったからです。 また、彼らはコーディングとトラステッドコミッターのタスクの優先順位付けに苦労していました。 これらのタスクを頻繁に切り替えることは、時間と注意力の面でコストがかかります。 トラステッドコミッターになることで開発者はコードを書くための集中モードに入ることが難しくなりました。 我々はこの問題を解決するため、プログラマーをアクティブなコーディング作業から外し、フルタイムの仕事としてトラステッドコミッターの役割をアサインすることを検討しました。 しかし、これには別の問題がありました。社員がコードのコントリビューションをしなくなると、コードレビューがますます難しくなってしまったのです。特に統合作業においてはなおさらでした。 プログラマーは業界に入った理由でもあるプログラミング作業に携われなくなるのですから、憂鬱になることは言うまでもありません。

我々の解決策は、トラステッドコミッターがプロダクトのスペシャリストと協力して、役割のローテーションスケジュールを作成することです。 他チームにいるコントリビューターからの期待に配慮して、このスケジュールは社内に公開されます。 この期待とは、レビューと指導における専門知識への期待です。 スケジュールに各トラステッドコミッターの専門分野を記載しておくと、適切な専門知識を持った人がいつ支援できるかをコントリビューターが知ることができるようになります。 また、トラステッドコミッターが行う困難で重要な仕事に対して、新しい報酬体系を作ることも重要でした。 このプロセスについては、トラステッドコミッターへの報酬というセクションで後ほど説明します。

私たちの経験では、プロジェクトごとにトラステッドコミッターの人数は大きく異なります。 30人程度の開発者が参加する高リスクのプロジェクトでは、6人のプログラマーにトラステッドコミッターの役割を担ってもらうようにお願いしています。 常時、半分はトラステッドコミッターとしてコードのレビューや技術的な相談をし、残りの半分は積極的にコードを書くようにしています。 2週間のスプリントごとにその役割は交代します。 これはトラステッドコミッターにとって理想的でした。 2週間という期間は、コーディングに没頭するにも、メンタリングや文書作成に専念するにも、ちょうど良い長さだからです。

ツール開発のようなリスクの比較的低いプロジェクトでは、1人のトラステッドコミッターが10個以上のリポジトリで作業します。 ほとんどの開発者は、自分の開発したツールセットに関するコントリビューターへのメンタリングにとても熱心です。 このようなツーリングには誰もが気軽に貢献できるため、企業全体のチームがツールセットをより適切に標準化する方法を見つけるのに理想的です。 これらのトラステッドコミッターに対する我々の主な提案は、コーディングに没頭し、その集中を維持するためのまとまった時間をもてるように、オフィスアワーを設けることです。

## 即時に得られる効果

プルリクエスト\[3-1] のコードレビューをトラステッドコミッターの役割に割り当てることで、プルリクエストのターンアラウンドが大幅に加速し、コードレビューのレベルも上がりました。 さらに、トラステッドコミッターはメンタリングの時間を使って、次の大きなリファクタリングに備えた素晴らしいドキュメントを作成することがわかりました。 とある主要なアーキテクチャの再構築に取り組んだ責任者は、インナーソースを使用することで、コードベースを大幅にリファクタリングする方法を、チームが本当の意味で理解するのに役立ったと述べています。 また、外部からの割り込みタスクとして入ってくるバグ修正に関しても、そのプルリクエストで対処されるようになり、大幅にコードの量が削減されました。

このドキュメントは、トラステッドコミッターとコントリビューターの間で行われた公開メンタリングの議論をアーカイブし、コードベースのコンテキストに応じた場所から簡単にアクセスできるようにすることで、ほとんど苦労せずに作成されました。 これは、メンタリングに費やされた価値のある時間が、二重の役割を果たしたことを意味します。 これをパッシブドキュメンテーションと呼び、4章で詳しく説明します。

## トラステッドコミッターへの報酬

トラステッドコミッターの役割が正式に認識されるようにするには、人事部および経営陣と協力することが重要であることがわかりました。 そうすることにより、管理者がコードレビュープロセスを尊重する必要があることを再確認できるため、開発が成功しやすくなるほか、"お偉いさん" がコードの変更を強制することがなくなります。 この新しい役割は、プログラマーをコーディングから引き離すことなく昇進させる手段を提供するため、企業にとってもメリットがあります。

トラステッドコミッターの役割は、開発者の高度なスキルを明確にします。 それはメンタリング、アーキテクチャに関する深い知識、コードレビューのベストプラクティスなど多岐にわたります。 トラステッドコミッターの役割が難しいものです。 そのため企業は、追加の責任を負う献身的なスタッフにどのように適切に報いるかを決定する必要があります。

私たちはこのような複雑性を反映するために、開発者が "フェロー" に昇進するためのパスを強化しています。 これはフルスタックな開発者を生み出し、一部の開発者が退屈に感じる管理職に移行することなく昇進することにつながります。 そして、さまざまなコードベースを本質的に理解しているプログラマーを抱えることで、リファクタリングや技術的負債の削減に貢献できるようになります。

## 3章の参考文献と注釈

* \[3-1] 他のいくつかのツールと同様に GitHub はプルリクエストという言葉を使っています。これらのツールを使用していない企業では、同じものを問題報告、変更要求、あるいはチケットと呼ぶかもしれません。