InnerSourceコモンズ では、オープンソースで学んだ オープン の概念について説明し、また、企業の中で私たちが知っていることや学んだことを再利用する方法について説明します。 それでは、マネージャーの視点からいくつか順を追っていきましょう。ディレクターとして、そしてPayPalではプロダクトオーナーと呼ぶプロダクトマネージャーとして、私にどのようなメリットをもたらしたかを説明します。
最初は、 オープンコード です。 オープンコードとは、何でしょうか？基本的には、コードが企業全体から見えるということ、そして、他の開発者が他のコードベースにプルリクエストを送信して受け入れるプロセスがあるということです。 さらに理解を深めるために、詳細については Trusted Committer と、コントリビューションアグリーメントに関する記事を参照してください。
マネージャーにとってのオープンコードとは、他チームのコードベースでバグ修正や機能実装されるのを待ったり、エスカレーションしたりする必要がなくなることを意味しています。 実装や計画を、より効果的に始めることができます。 多くの場合、あなたのチームの問題(または機能)は、他チームの最優先事項ではないかもしれません。 そのチームにアクセスするために、上層部へのエスカレーションや政治に頼る必要はもうありません。 代わりに、あなたのチームで優先順位を決定し、他者への依存を減らすことができる、より多くの力を手に入れます。 知識の習得までに、より時間がかかる場合もあります。しかし、それが常にボトルネックとなっているチームでは、何年も放置されているストーリーを、他チームのバックログから取り出すことができます。
オープンプランニング - これは、全ての人がオープンかつ標準化された方法でプランニングプロセスを公開することです。 PayPalには、UPE標準があります。これは、 Unified Product Experience (統一された製品体験) の略です。 これには技術ハブが含まれており、すべてのチームがスプリント計画のロードマップとスプレッドシートを公開しています。 誰もが、それらの文書が個々の製品毎にどこにあるかを知っています。
このメリットとして、あなたやあなたのチームが行った作業に対する信用を得られやすいことがあります。 他のチームが何に取り組んでいるか、現在何を優先しているかがわかれば、チーム間の連携をより効果的に行うことができます。 オープンプランニングは、チーム間の交渉をより効果的なものにします。
私たちがInnerSourceでよく取り組んでいることの1つに、 オープンドキュメント があります。 これには、プランニングプロセス、標準などの種類のものが含まれます。 これの重要なポイントは、見つけやすさと、ある程度の中央集権化が行われているという事にあります。そのため、より適切なコラボレーション方法を理解するためのドキュメントがどこにあるか、全ての人が知っています。
それは、あなたの成功に関わる多くのメリットがあります。 その中にはオープンプランニングやオープンスタンダードがあり、より良いコラボレーションが可能になります。 また、上級管理職が、あなたが経験しているさまざまな道筋や、プロジェクトの過去と今後に関してあなたが何をしているかを見ることができるという信用の側面もあります。
最初は時間がかかるように見えますが、オープンプロセス、オープンスタンダード、およびオープンドキュメントにより、コラボレーションは、はるかに効率的になります。 これらのドキュメントは、標準化された場所で公開される必要があります。 これにより、それらを発見できるようになります。 それらは、標準または優れた検索エンジンを介して実施することもできます。
このメリットは、あなたとあなたのチームが行ってきた仕事についてより多くの信用が得られることにあります。 あなたにも歴史はあります。優先順位が変わる理由は明らかです。 これは、中間管理職のストレスの要因に関して先に述べた、信用の問題に大いに役立つものです。
また、コラボレーションの速度も向上します。 コラボレーションに興味のあるチームを簡単に調べることができ、彼らが何をしているかを確認できます。 中でも最大のメリットは、仲間内のノウハウを減らし、サイロを壊すのに役立つということです。 チームとのコラボレーションが難しい場合、速度が大幅に遅くなることや、ドキュメントが過度に複雑、制限的または否定的になったりすることから、すぐに明らかになります。 時には、脆弱でレガシーなコードベースのように適切な理由がある場合もありますが、今ではリファクタリングにリソースを優先して割り当てる必要性を、上層部がより明確に理解できるようになりました。
コラボレーションと交渉: 中間管理職は通常、自分たちのリーダーシップスキルを活用する権限があると感じていません。 これは、先に述べた、中間管理職がこれまで経験した不満のトップ5に挙げられています。
InnerSourceのプロセスでは、コラボレーションやネゴシエーションなどのスキルが重要になります。これらを明示しておくと、チーム間で期待の水準を決めることが、はるかに簡単になります。 他のチームが、あなたのドキュメントや標準の作成を支援することもできます。 ほとんどの場合、人々は特に標準化プロセスに関して意見を述べたいと思っていることに気づきました。 また、それはチームが最初に一緒に仕事をするときに、それらのチームが作業にとりかかるための良い方法であり、時には安全な方法でもあります。
事例
InnerSourceのプロセスが、私の取り組んだいくつかの大規模なプロジェクトの方向性をどのように大きく変えたかを示す、3つの素晴らしい事例があります。
事例1 - 支払い
最初の例は、支払い機能になります。支払い機能は、リファクタリングとモジュール化が必要でした。 私は、支払いチームおよび他の5チームと協力して、8ヶ月間、新しいInnerSourceプロセスを設計しました。
私たちは、80%が割り込み駆動型だったチームを、最終的にリファクタリングできるようになりました。 他のチームは、何年も前から滞っていた機能を取り除くことができました。 最後に、ディレクターは私に、InnerSourceプロセスとファシリテーションの間に、これらの5つのチームからのインプットがなければ、新しい支払いモジュールのリファクタリングとモジュール化がどのようなものになるのか適切に理解できなかったと言っていました。
事例2 - ALM
2つ目の例は、ALM (Application Lifecycle Management：アプリケーションライフサイクリ管理) プロセスです。 このチームは、コードの作成から本番稼働までのすべてのツールをオーケストレーションする責任があります。 コンテナ化やデータベースサービス化 (DBaaS: Database as a Service) など、15の主要機能を1年足らずで実装することができただけでなく、ALMをリファクタリングしてサービス化されたプラットフォームに移行することもできました。 このチームは、さまざまなチームと協力し、どれだけの速度を生み出したかを確認した後に、素晴らしいオープンスタンダードのドキュメントを作成しました。
事例3 - FDI
3つ目の例はFDI (Failed Developer Interactions：開発者の対応ミス) です。 私たちは、オープンスタンダードの開発を支援するために、開発者標準委員会 (Developer Standards Committee) を設立しました。 結局のところ、FDI（開発者の対応ミス）の有無を判断できるのは、1時間単位で直接影響を受けている開発者たちをおいて他にいないのです。
これによって、政治的な問題も解決されました。以前はチームごとに失敗の測定方法が異なっていましたし、言うまでもなく、開発者が納得しないケースもありました。しかし、議論を公開することで、以前よりも正確な標準を作ることができたと私は信じています。
これらの例は、オープンなプロセスがうまく行われれば、中間管理職の表情が変わることを示しています。 中間管理職の役割が変わります。 プロダクトオーナーは、チーム間でさらに交渉しなければなりません。 プロダクトオーナーは、もう少しコラボレーションに注力しなければなりません。 しかし、うまくやれば、すべてのチームが企業のビジョンにさらに参加できるようになります。
このオープンプランニングをトップにしておくことがベストです。 多くの場合、これはプロダクトオーナーが、交渉の際の追加のトレーニングと指導を必要とすることを意味していします。 しかし、これは、中間管理職には権限がないと感じているという、主な不満を解決します。
