Join us on Tuesday, October 8th, at 8am GMT / 9am CEST / 12:30pm IST / 6pm AEDT when Vincent Caldeira, Red Hat, Clemens Jütte, Humanitec, and Luiz Fernando Almeida de Oliveira, Red Hat, will discuss Promoting InnerSource Practices with an Internal Developer Platform.

新しい役割と責任

InnerSourceのリーダーには、新しい役割と責任が伴います。 その最初の1つが、TCをサポートすることです。TCは、 Trusted Committer です。 あなたが最初に行うことの1つは、おそらく、TCが誰になるかの選抜を支援し、彼らの仕事をサポートすることです。 もし、TCの役割について詳しく知りたければ、 Trusted Committer の章を参照してください。

彼らは、あなたのコードベースのゲートキーパーです。 通常、彼らはコードレビューを得意とし、コードベースのアーキテクチャを深く理解しているリード開発者です。 彼らにはあなたのサポートが必要です。 他チームとのコラボレーションにおいても、彼らは重要です。 見積りやインテグレーションでは、あなたの右腕となるでしょう。彼らをサポートするのを忘れないでください。 彼らにはいくつかとても大変な新しい責任があり、 コントリビューションするチーム を支援するために指導が必要になるかもしれません。 開発者が交渉方法を教えられることはあまりありません。 私は、 Getting to Yes という本を、彼らと一緒に使うことをお勧めします。

2番目は、他のプロダクトオーナーです。 これから、特に交渉やコラボレーションについて新しい時間的な約束を果たすために、他のプロダクトオーナと交渉することになります。 それには時間がかかります。あなたは指導する必要があります。 他のプロダクトオーナー、特にプロセスに慣れていないプロダクトオーナーを指導する必要があるかもしれません。あなたのプロセスも彼らのものとは異なるかもしれません。それは大丈夫です。

私はプロジェクトのコードベースを家のようなものだと考えています。 古い家の中には、その家の風習があり、他の家よりも多くのルールや指示が必要なところもあります。 例えば、昔の家では温水と冷水の標準はありませんでした。 なので今では、ゲストがシャワーで冷水は右側ではなく左側と知らせるために記載しています。

3番目はドキュメンテーションの時間です。 最初は、オープンドキュメントに関して、オープンなロードマップや他のオープンなプロセスだけではなく、それ以上にかなりの時間を費やす必要があるかもしれません。 私はまた、UXやUIの標準、APIの標準、テスト要件などについても述べています。 それから、もちろん、 Trusted Committer と共に、彼らのコーディング要件のいくつかに関して安心できるように調整する必要があります。それだけの価値はあります、約束します。

他のチームと一緒に仕事を始めて、新しい開発者たちと一緒になって、以前よりもずっと多くの仕事をするようになったら、 新しい開発者たち に新しいドキュメントのいくつかの作成を支援してもらうこともできるということを思い出してください。 もし、あなたのツールがボトルネックの1つであり、彼らにとって本当に重要であるなら、彼らはあなたの製品と統合したいと考えているので、標準化に関する多くの大変な作業を手伝ってくれるかもしれません。

最後は、社内マーケティングです。 誰もがコードを提供したいと思っているプロジェクトがいくつかあります。 多くの場合、こうしたプロジェクトがボトルネックとなります。 私が思うに、そのボトルネックとなっているプロジェクトの1つに何かを取り入れなければならないため、人々は最初にInnerSourceプロジェクトに取り組み始めます。 それで、彼らはプロジェクトを進めることができます。しかし、あなたがそのプロジェクトの一員でないとしたら、どうでしょうか? 実際そうだとして、あなたが会社の他の人からの無償の支援を本当に望むのであれば、あなたのコードベースを彼らに売込む必要があるでしょう。

時には、新しいスキルを学ぶためのものとして、売込むこともできます。実際に、履歴書にモバイルの経験を載せたい人が多くいたため、Androidチームには多くのコントリビューションがありました。 また、優れたスタートアップガイドのドキュメントは、他のチームがコントリビューションの準備をしたり、あなたと一緒に作業する準備をするのに役立ちます。 あなたができるもう1つのことは、冗長な作業を行っている可能性のある他のチームを探すことです。 もし同様の機能を実行するさまざまなツールがあることを見つけたら、皆と一緒に連携して機能分割を行うことで、コラボレーションが可能になり、時間やリソースを節約できます。 InnerSourceを実行したことで、どれだけのお金が節約できたかを理解できるように、そのことをよく考えるようにしてください

InnerSourceコモンズ には、他にもいくつかパターンがあります。 詳細については、 innersourcecommons.org を参照してください。 私がすぐに思い浮かぶ、コードアソン(Code-a-Thon)と、コードベースの準備完了とビジネス向け公開を伝えるさまざまなアナウンス方法の2つは、とても良い事例です。ありがとうございました。

Contributors