インナーソースにおけるプロダクトオーナーの役割とは？
1ページ目でも言及しましたが、トラステッドコミッターの説明の最初で、インナーソースの仕組みを、お客（ゲスト）を家に招く人（ホスト）に例えた時、プロダクトオーナーは、家主のような存在だと説明しました。企業という組織では、どのような方がプロダクトオーナーになるのでしょうか？ 部・課・プロジェクト・チームなどの単位の責任者、いわゆる中間管理職の人がプロダクトオーナーなのでしょうか？
インナーソースにおけるプロダクトオーナーは、プロジェクトの方向性に対して責任を持つ人となります。これは先に述べたような中間管理職の方と同じ役割を担う部分もありますが、インナーソース特有の新しい役割も担うことになります。具体的には、次のような役割を担います。
- 実装する要件の優先付け
- インナーソースで進める方針決定
- トラステッドコミッターの選抜
- 他のプロダクトオーナーとの交渉
- 仕事を進める環境の整備
- 社内マーケティング
要件の優先付けの役割は、アジャイルプロセスで開発する場合のプロダクトオーナーの役割と同様です。しかし、それ以外の役割はインナーソースのプロダクトオーナーに求められる新しい役割と捉えることができます。以降では、これらの新しい役割について詳しく見ていきましょう。
インナーソースとしての方針決定
インナーソースとしてプロジェクトを進めるにあたり、プロダクトオーナーとして方針を決定して行動に移すべきこととして、次の二つがあります。
- オープンコード
- オープンプランニングとオープンドキュメント
オープンコードは、コードが企業全体から見えるようにするということ、そしてコントリビューターがコードベースにプルリクエストを送信して受け入れるプロセスがあるということです。オープンコードにより、他チームはバグ修正や機能実装を待ったり、エスカレーションしたりする必要がなくなり、コントリビューションという形で、必要な実装を計画的に進めることが可能となります。コントリビューションされるものは、プロダクトオーナーの所属するチームの最優先事項ではないかもしれませんが、時には何年も放置されているバグをバックログから取り除くことに繋がるかもしれません。
オープンプランニングとオープンドキュメントは、すべての人がオープンかつ標準化された方法でプランニングプロセスや、それに関連するドキュメントを公開することです。オープンプランニングは、開発計画やスプリント計画のロードマップを公開することです。他のチームが何に取り組んでいるか、現在何を優先しているかが分かれば、チーム間の連携をより効果的に行うことができます。またオープンドキュメントは、開発に関係するドキュメントを公開することです。これには、設計やAPI仕様、開発標準などが含まれます。
オープンプランニングとオープンドキュメントを行う際の重要なポイントは、ある程度の中央集権化を行い検索できるようにすることで、見つけやすい環境を作ることです。上級管理職からも見えるため、プロジェクトの過去と今後に関してあなたが何をしているかを把握でき、信頼を得ることができるかもしれません。
トラステッドコミッターの選定と支援
トラステッドコミッターの選定は、インナーソースのプロダクトオーナーとして最初に行うことの一つです。トラステッドコミッターは、コードのアーキテクチャを深く理解しているリード開発者で、プロダクトオーナーの右腕ともなる存在です。
トラステッドコミッターは、技術とコミュニティの両面に責任があります。トラステッドコミッターが迷わずにそれらの役目を遂行できるようにするためには、プロダクトオーナーはトラステッドコミッターを選定するだけでなく、時にはメンターとしてサポートすることが必要です。
他のプロダクトオーナーとの交渉
インナーソースのプロセスでは、コラボレーションやネゴシエーションなどのスキルが重要になります。複数のコードベースが関係するプロジェクトでは、各コードベースをまとめるプロダクトオーナーとの交渉が必要になることがあります。例えば、プロジェクトの進捗に影響しないように自チームからコントリビューションする際には、チームの意見を理解してもらうために、コントリビューション先チームのプロダクトオーナーとの交渉が必要となります。
もし相手のプロダクトオーナーが、そうしたインナーソースのプロセスに慣れていない場合には、プロダクトオーナーを支援する必要もあります。その際には、個々のチームのプロセスを尊重しつつ、コントリビューションの受け入れやコラボレーションの考え方を指導します。
プロダクトオーナーが、こうした交渉を通してチーム間のコラボレーションを活性化することで、すべてのチームが企業のビジョンを実現するために一体感を持って活動できるようになります。
仕事を進める環境の整備
プロダクトオーナーが行う環境の整備は、単に開発環境として利用するツールの整備にとどまらず、仕事を進めるための周辺環境全般に及びます。
インナーソースでは、オープンプランニングやオープンドキュメントが重要だと述べました。例えば、UXやUIの標準、API標準、テスト要件などを、誰が見ても分かるようにドキュメント化しておく必要があります。しかし、こうしたドキュメントを作成するためには時間が必要です。
プロダクトオーナーには、こうした時間が必要だということを理解し、時には上層部の理解も得て、リソースを確保することが求められます。実際にどの程度の時間が必要かについては、トラステッドコミッターと連携して決める必要があります。こうした人や時間などの環境整備を行うことで、プロジェクトのメンバーは安心して活動できるようになります。なお、これら環境の整備は、理解しやすくコントリビューションしやすい環境を得ることに繋がるため、長期的にはプロジェクトの継続性や発展性にもポジティブな効果をもたらします。
社内マーケティング
インナーソースは企業内にあるため、潜在的なコントリビューターの数が少ないという制約があります。しかし、企業全体を見渡すことができれば、同じような課題を抱えていて、プロジェクトに貢献してくれそうな潜在的ユーザーがいるかもしれません。
こうした潜在的なユーザーやコントリビューターを発掘し、コントリビューションを受け取ることに繋げるためには、まずコードがあることを知ってもらい、実際に使ってもらうためのマーケティングが必要です。
この活動は、企業全体に広くアナウンスするという方法を採ることも一案ですが、似たような課題に直面し、冗長な作業を行っている可能性があるチームを探すことも並行して行うべきです。インナーソースが最も有効に働くのは、共通の課題解決に向けて活動する時です。同じ課題に興味がある人を見つけるには、実際にコードを利用する経験をしてもらう、コードアソンやハッカソンの開催も有効な方法の一つです。こうして同じ目的を共有できれば、連携して機能分割を行うことで、コラボレーションが可能になり、時間やリソースを節約できます。
もし、インナーソースで活動した結果として、リソースが節約できた場合、逆に連携がうまく行かずに失敗した場合のどちらについても、積極的に情報共有するようにしてください。成功事例により、他チームがインナーソースを実践する際に効果を出しやすくなるかもしれませんし、失敗事例は開発プロセスをより早い段階で見直すきっかけになるかもしれません。こうして企業内にインナーソース実践のノウハウが蓄積されることで、インナーソースの活動の効果をより高めることができるようになります。
プロダクトオーナーを引き受けよう
トラステッドコミッターと同様に、プロダクトオーナーの立場も、企業における活動の成果やリーダーとしての資質が認められ、その結果として得られるものです。時間や人、資金などのリソース面の制約、複数のビジネスユニットの異なる期待がある中で活動することは大変なことです。
しかし、インナーソースのプロダクトオーナーとして活動することで、単により多くの責任を担うだけでなく、得るものも多くあります。トラステッドコミッターをサポートし、他のプロダクトオーナーとコラボレーションすることで、より多くの作業をより短期間で行うことができるようになります。オープンプロセスを用いることで、開発に対する周りの理解も得やすくなり、以前よりも多くの信用を得ることができるだけでなく、中間管理職が頭を悩ませる政治的問題を少なくすることもできます。
社内マーケティングを行うという点では、管理とは異なる新しいスキルを身につけなければならないかもしれません。しかし、いったんそれをマスターすれば、チームの作業を完了させるための多くのリソースを手に入れることができます。また、結果として組織としての冗長性向上に繋がるかもしれません。
開発をスケールさせて加速できることを責任者の立場で実感できることが、インナーソースのプロダクトオーナーの醍醐味です。
おわりに
今回は、インナーソースプロジェクトをホストするチームの役割となるトラステッドコミッターとプロダクトオーナーについて解説しました。
今まで3回にわたり、インナーソースの概要と、それに関わる人達それぞれの役割について説明してきました。次回はいよいよインナーソースを実際に始める場の作り方の話になります。企業の中でインナーソースを始めるために何を準備すれば良いか、準備する際に気を付けるべきポイントは何かについて説明します。いよいよインナーソース実践が近づいてきました。お楽しみに。
