コントリビューターになろう
インナーソースにおけるコントリビューターの活動は、組織やプロジェクト、チームといった垣根を越えたものになります。このとき、次の5つのポイントを意識すると、コントリビューション活動がとても効果的なものとなります。
- 何か見つけたらコントリビューションしてみようと考えてみる
- コントリビューションする際はホストチームのルールに従う
- コントリビューションの過程はオープンにする
- コメントをもらったら感謝する
- 受け入れてもらえない場合もあることを認識する
コントリビューションしてみようと考えてみる
共通の課題を見つけて、コントリビューションできるチャンスがそこにあるとき、最初にくるハードルはコントリビューションした後に、何が起こるかわからないという不安かもしれません。例えば、「コントリビューションした内容が間違っていたら責任を取らされるのではないか」「他の仕事まで押し付けられないか」などの不安があると思います。こうした不安は、ホストチームが何を行うかを理解すれば、感じる必要がないものだとわかります。
ホストチームは、コントリビューションされた変更が正しいものかを確認した上で取り込みます。つまり、取り込んだ責任はホストチームにあるのです。まずは、コントリビューションする先のプロジェクトでの、責任はないという意識で始めてみましょう。
コントリビューターとしては、ホストチームが取り込みの判断をするために必要な情報を提供する必要があります。何か間違えた場合には指摘を受けることもあるでしょう。とはいえ、それはホストチームによるレビューの過程で明らかになるもので、コードの品質向上に寄与するものです。間違えたこと自体が問題ではないので、指摘に対しては前向きに対応しましょう。
コントリビューションした結果、取り込まれた変更に対して、いつまでも問い合わせに回答することは負担になるでしょう。そのような場合は、30日保証ルールなどを定めて、期間を限定するという方法があります。そうすることで、最終的にはホストチームがコードのメンテナンスを引き継ぐことになります。
ホストチームのルールに従う
前回、コントリビューションを受け入れるチームをホストチーム、コントリビューションするチームをゲストチームと表現し、このホストやゲストの言葉は、お客（ゲスト）を家に招く人（ホスト）からきたものだと述べました。ホストチームにコントリビューションしようとするインナーソースのコントリビューターは、ホストチームから見るとゲストになります。ゲストを家に招くにあたっては、良いゲストとして振る舞うことが期待されます。
例えば、誰かの家に招かれたとき、たとえドアがあいていたとしても、ノックやドアベルを鳴らさずに、いきなり家に入るようなことはしないと思います。インナーソースでも同様に、ホストチームのコードリポジトリに対して直接コミットすることはできません。
ホストチームのコードに変更を取り入れてもらうためには、ホストチームの開発ルールや、コントリビューション方法を理解する必要があるでしょう。開発ルールには、コーディング規約やビルド方法などがあり、コントリビューション方法についてはパッチの送付方法や問い合わせ窓口の情報などがあります。こうした情報は、通常、リポジトリの中にあるREADME.mdファイルや、CONTRIBUTING.mdファイルにまとめられています。もしなければ、ホストチームの誰かに問い合わせた上で、その回答で得た内容をドキュメントへのコントリビューションにしても良いかもしれませんね。
プロジェクトが続いていると、暗黙知として蓄積されてしまう情報があります。初めてコードを見る人は、こうした暗黙知を見える化するために最も適した人だともいえます。初めて見た時に不便と感じれば、それがコントリビューションのチャンスです。
コントリビューションの過程はオープンにする
コントリビューションする際にオープンに議論し、その内容を公開することは、ホストチームとコントリビューターの双方にメリットがあります。
まず、コントリビューションの内容が公開されていると、ホストチーム以外の人の目に触れることになります。その結果として、コントリビューターが提案するよりもさらに良い解決方法の提案や、コントリビューションした内容に含まれる未知のバグ発見に繋がるかもしれません。ホストチームとしては、より品質が高いコードを取得することができ、コントリビューターは、他の提案内容やコメントから学ぶことでさらに成長することができます。
こうしたコントリビューションや意思決定事項に関連する議論の内容が公開され検索できるようになっていると、後に続くコントリビューターにも良い影響があります。コントリビューションが受け入れられるまでの経緯や背景を理解することができるため、自分がコントリビューションする内容がホストチームによって受け入れられるものなのかを事前にある程度判断することができるだけでなく、対策を講じることも可能となります。つまり、過去の議論から学ぶことで、同じことをせずに済み、続きからスタートすることかできます。
コメントをもらったら感謝する
コントリビューションの過程で行われるホストチームからのフィードバックは、すべてがギフトです。フィードバックは、ホストチームの専門的な知識を元に行われ、コントリビューターのスキルを引き上げてくれます。また、ホストチームは、コントリビューションの内容を改善しようとしてフィードバックを行います。もしかすると、コントリビューションの結果生じるかもしれない、将来のトラブルからコントリビューターを救うことにもなるかもしれません。このように、フィードバックをポジティブなものとして捉え、お互いにポジティブな気持ちで活動ができるようにするためにも、感謝の意を伝えるということは大切です。
受け入れてもらえない場合もあることを認識する
コントリビューターになるということは、単に機能を要求するだけの人に比べると、ホストチームに近い立場になります。ただし、コントリビューターには、ホストチームのプロジェクトに対する責任がないということが大きな違いになります。
どのようなコントリビューション受け入れるかの最終的な判断はホストチームが行います。そのため、ホストチームがコントリビューションを受け入れない可能性もあります。
その場合は、ホストチームと協力して、なぜコントリビューションした提案が受け入れられないかを明確にする必要があります。もしかすると、ホストチームのニーズにマッチしない内容を含めていることが問題となる場合や、提案した内容がホストチームの管理する他の機能に影響し、ロードマップの変更を迫られている可能性もあります。
こうした問題は時として長い議論に発展するかもしれません。それを解決するためには、Web会議や直接合って議論する機会を設けるなど、対話により解決することが有効な場合もあります。いずれにしても、ホストチームとの対話により、一緒に解決策を見つけてゆくことがポイントです。
コントリビューションを始めてみよう
コントリビューションは、次の3つのステップを経て行われます。
- コントリビューションの機会を見つけて取り組む準備をする
- コントリビューションするコードを作成する
- ホストチームに提供する
コントリビューションすることに慣れてくると、これらのステップを意識しなくても良くなるかもしれませんが、最初のうちはそれぞれのステップで気をつけるべきポイントを意識しておくことが大切です。
取り組む準備をしよう
コントリビューションする機会を見つけたら、次の3つのポイントについて準備を兼ねて考えてみましょう。
- リードタイム
- 信頼関係の構築
- 提案を受け取ってもらうための戦略
リードタイム
初めてコントリビューションするときは、どのような場合でも常に新しいコミュニティーに参加することになります。引っ越しや、進学、就職など、新しいコミュニティーのに入ることを考えてみてください。引っ越し先や、就職先などに既にあるコミュニティーには、それぞれ特徴があり、馴染むまで時間がかかると思います。
インナーソースで他チームにコントリビューションするときにも同じことがいえます。ホストチームが利用している開発環境やコーディング規約などの技術面の特徴もありますが、チームの雰囲気やコミュニケーション方法といった技術面以外の特徴もあります。こうした違いを理解して馴染むために、特に最初は長めのリードタイムを確保する必要があります。ホストチームへのコントリビューションが何回か成功すると、1回のコントリビューションあたりに必要なリードタイムは短くなります。
信頼関係の構築
ホストチームからコントリビューションに対する期待が高ければ高いほど、スケジュールに影響する遅延は不安や焦りを大きくする原因となります。こうしたネガティブな影響を緩和するためにも、信頼関係の構築はとても大切です。
信頼関係を構築するためのひとつのアプローチは、期待の管理があります。例えば、ホストチームからのフィードバックに対応する時間が取れない場合に、「1週間くらい時間がかかってしまいそうです」と伝えておくだけで、いつまで経っても返信がないと思われてしまう状況を避けることができます。ホストチームから期待されることは良いことですが、常にその期待に応えるというのは、ゲストチームや個人の都合があるため現実的には困難です。何を期待されているかを意識して、その期待に応えることが難しい場合には、素直にそれを伝えることが大切です。
信頼関係を構築するためのもうひとつの方法は、チームや人を知ることです。そのためのコミュニケーションが、とても大切です。コミュニケーションは、時と場合に応じて最適な方法が異なります。例えば、メールだけでは細かなニュアンスを伝えることが難しい場合には、Web会議で話をしたり、直接会って話し合う機会を作ったりすることも必要です。コミュニケーションを円滑に行い、その人の個性を知ることができれば、リモートのコラボレーションもより円滑に行うことができます。
提案を受け取ってもらうための戦略
コントリビューションできる機能が見つかり、それを実行に移したとして、提案した内容がすべて無駄になってしまったらどのように感じるでしょうか？ 提案までの間に、ホストチームが似たようなものを作っていたり、計画の変更でコントリビューションを予定していた機能が必要なくなったりすることは起こり得ます。
確実に提案する内容を受け取ってもらうためには、取り組む前にコントリビューションする内容についてホストチームの理解や同意を得ておくことが大切です。ホストチームがコントリビューションの予定を把握していれば、ホストチームの優先度が変更され、予定していた提案内容の優先度が上がった場合でも、コントリビューターとホストチームの共同作業という形で、双方の作業量の削減や、開発の加速という効果を得ることができます。
こうしたコミュニケーションを円滑に行うポイントが、開発の透明性の確保です。議論の段階から開発に至るまでオープンな場で行うことで、ホストチームだけでなくすべての関係者が開発の方向性を把握することが可能になり、将来のコントリビューションも含めたコラボレーションが円滑になります。
コードを作成しよう
準備が終わったら、コントリビューションするコードを書いてみましょう。このとき大切なのは、次の2点です。
- ホストチームの開発を理解する
- ホストチームのルールを守ってコードを作成する
ホストチームの開発を理解する
コードを作成する際には、まずホストチームが提供するドキュメントや、コードをよく調べましょう。もし必要な情報がドキュメント化されていない場合には、ホストチームにオープンな場で質問することをお勧めします。あなたの質問と受け取る回答は、後で他の人があなたと同じ問題を解決するときに役に立つだけでなく、ホストチームのドキュメントを充実させるのにも役立つ可能性があります。
このようにコントリビューションに必要な情報をホストチームから得ながら、開発に参加することで、ホストチームとコントリビューターの間にあるコントリビューションの障壁を低くすることができます。
ホストチームのルールを守ってコードを作成する
開発者は、コーディングスタイルやインデントなどについて好みや意見を持っていることがあります。これは、ホストチームのプロジェクトも同様です。
コードを書く際、ホストチームが指定するコーディングスタイルが、あなたの好みや設定と異なることがあるかもしれません。そのような場合、ホストチームが指定した方法を用いるようにしてください。もし、コーディングスタイルを設定する方法がわからなければ、ホストチームに尋ねることも良いでしょう。コントリビューションは、機能やバグ修正に対して行うもので、ホストチームに新しいコーディング規約を導入したりするものではないと認識しておくことが大切です。
ホストチームに提供しよう
コーディングが終わったら、いよいよホストチームにプルリクエストを送付します。コントリビューターとしての重要なゴールのひとつは、提案内容を受け入れてもらうことです。できるだけスムーズにホストチームのコードにマージできるようにするために、プルリクエスト送付にあたり、次の3点を意識する必要があります。
- コントリビューションの内容を説明する
- テストを実施する
- 少しずつ変更を入れる
コントリビューションの内容を説明する
もし、何も書かれていない封筒や箱を受け取ったら、どのように感じるでしょうか？ それが、初めて会う人からのものだとしたら、いかがでしょうか？ 中に何が入っているかわからず、不安に感じるのではないかと思います。もしかすると、そのままゴミ箱に捨てることになるかもしれません。これは、コントリビューションに対しても同じことがいえます。
コントリビューションをする際には、それがホストチームのどのような問題を解決するものなのか、要求されるどの機能を実現するのものなのか、どのようにテストをすれば良いか、利用方法はどうなるかなど、コントリビューションの内容を説明することが重要です。簡潔であっても、説明が正しく書かれていることで、ホストチームはコントリビューションされた内容がホストチームに必要なものかを判断でき、レビュー担当を決めることができるようになります。
テストを実施する
コントリビューションする際には、コードのテストを追加して、他の人がコントリビューション内容を検証できるようにしておく必要があります。もしホストチームが自動テストのフレームワークを提供しているのであれば、そのフレームワークに従ってテストを行えるようにすることも考慮してください。それにより、ホストチームの受け入れ基準を満たすことが容易になります。
なお、ホストチームのテスト環境でテストをする前に、ローカルの環境でテストを実施して機能が正しく動作することを確認することも重要です。こうしたテスト結果を公開して、議論できるようにしておくことで、ホストチームや他の関係者からのフィードバックも得られコード品質やスキルが向上します。
変更は少しずつ入れる
プルリクエストには、解決すべき課題に関係する変更のみ、または特定の機能ひとつのみを入れるようにすることが重要です。複数のトピックを一度に解決する非常に大規模なコミットや、大量のファイル送付は避けなければなりません。
プルリクエストの範囲が広すぎたり大きすぎたりするとレビューが難しくなるため、受け入れられるまでにかなり時間がかかります。より大きな機能を提供する場合は、その機能を複数のプルリクエストに分割して、順番に送信、レビュー、承認となるようにしておくと、早くフィードバックをもらうことができ、マージがよりスムーズに進みます。
まとめ
今回は、インナーソースで組織の壁を越えて活動するコントリビューターの役割について解説しました。コントリビューターはホストチームの一員ではありませんが、課題を共有して一緒に解決に向かう仲間となります。こうしたコントリビューターとしての心構えと、コントリビューションを成功に導くためのポイントについても説明しました。
次回は、ホストチーム側の窓口となり、コントリビューターと一緒に活動し、指導などのサポートを行うトラステッドコミッターについて説明します。コントリビューターとトラステッドコミッターの役割の両方について理解が進むと、インナーソースのコラボレーションの主要な部分が明らかになります。
