# クロスチームプロジェクト評価

### Title

クロスチームプロジェクト評価

### Patlet

会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します

### 状況

* あなたは、社内のプラットフォームとして機能するクロスチームを担当しています。
* クロスチームプロジェクトは、企業の収益に直接的な価値をもたらすものではありません。

### 問題

チーム横断的なプロジェクトは、会社に非常に大きな影響を与える可能性がありますが、データに基づいた形で表現することは困難です。 その結果、真の価値を生み出さないプロジェクトを追求してしまったり、本来なら大きな価値を生むはずのプロジェクトに資金を投入しなかったりすることがよくあることはご存知の通りでしょう。

### 組織に働く力学

* プロジェクトが資金を得るためには、会社のリーダーシップに価値(客観的または主観的)を示す必要があります。
* チーム横断的なプロジェクトの価値は、複数の最終事業部門に分散しています。
* このように分散しているため、クロスチーム・プロジェクトの価値を直接測定することは困難になっています。

### ソリューション

チーム間のプロジェクトを評価する方法のパターンとモデルを設定します。このようなモデルは、会社にとって価値の高いコラボレーションに焦点を合わせて拡大するために必要なツールを提供します。 チームをまたがるすべてのプロジェクトにおける価値の核となるのは、離れるよりも一緒に多くのことを成し遂げることができるという考えかたです。 チーム間の取り組みに価値を与えることは、一緒に行われていることの量を定量化するための演習にもなります。 生産性に関する実際の差は、ドメインやプロジェクトによって異なります。ここではモデルを作成して計算できる一般的なプロセスがありますので以下で紹介します。

#### 解説

まずあなたのドメインにおける特定分野の専門家からなる小さなチームを編成します。その専門家チームで、プロジェクトの成果物を利用するそれぞれの人について、以下の4つのことを見積もってください

* プロジェクトの成果物をユーザーが使うのにどのくらい時間がかかりますか？
* そうでなければ、あなたのプロジェクトのアウトプットの価値をユーザー自分たちのものにするために、どれくらいの時間がかかりますか？
* プロジェクトの成果物の何パーセントが、実際に彼らにとって有用ですか？
* 自社で開発したソリューションのメンテナンスに、継続的(理想は使用ごと)にどれだけの時間を費やすことになりますか？

これらの見積もりを行う場合、アクティビティにかかる時間を正確に知ることは不可能です。また、それはあなたの目標ではありません。 正確さではなく、これらの見積もりに最悪の場合の限界を設定するように努める必要があります。専門家のグループがお互いに「どれくらいの時間がかかるかは正確にはわかりませんが、少なくともこれだけだということには同意できます」と言うことができるという考えです。 具体的には、プロジェクトのアウトプットを消費するための最大の妥当な時間と、消費者が独自のソリューションを自分のものとして使用、および維持するための最小の妥当な時間を見積もる必要があります。

自前でソリューションを開発する(ホームロール)場合のコストについては、一つ注意点があります。ソリューションの自作にかかるコストは、必ずしも共有ソリューションの作成コストと同じとは限りません(実際、非常にまれです)。 同じ機能であれば、チーム横断的な共有ソリューションの構築に必要なモジュール性と品質により、一度だけ使用する迅速でハードコードされた実装よりも明らかに高い投資となることがよくあるのです。

#### 数式

ワーストケースを設定すると、単純な計算式でチーム横断的なプロジェクトの成果物を評価することができます。

```
[節約した時間] - [投資した時間]

([新しいオンボーディングの数] * [自分のものにするためのコスト] * [成果物のうち使える機能の割合] + [利用数] * [利用ごとのメンテナンスコスト]) - ([新しいオンボーディングの数] * [オンボーディングのコスト])

[新しいオンボーディングの数] * ([自分のものにするためのコスト] * [成果物のうち使える機能の割合] - [オンボーディングのコスト]) + [利用数] * [利用ごとのメンテナンスコスト]
```

#### 解説

一見このプロセスには厳密さがあるように見えますが、チーム横断的なプロジェクトの成果を正確に測定する方法を提供するものではありません。 ただし、実際には、この作業に資金を提供する方法を適切に決定するためのフレームワークが提供されます。 上記の説明に従って適切で妥当なデータを取得したら、少なくとも次の3つのレベルのうち、小さい方までプロジェクトを実行するための専用の開発時間に資金を提供する必要があります。

1. 上記の式によって節約された実際の時間。 公式が実際に節約された時間数よりも少ない数を生み出すと私たちは皆確信しています。そのため、その時点までのプロジェクトへの資金提供はあなたにとって確実な勝利であると確信することができます。
2. チーム間のプロジェクトへのインナーソースのコントリビューションをサポートするためにかかる時間。コントリビューターは、一度限りのワークを提供することが多いでしょう。そのワークを共有の場所に持っていくための時間に投資することには価値があります。
3. あなたが心地よく進められるものなら何でもかまいません。評価式を持つことの意図的な副次効果として、ユーザーに価値を提供する重要ポイントの測定を自然に強制することができます。

それらの測定値を理解し、そのまま使うことで、プロジェクトの価値を直感的に理解することができます。 この評価手法が正確さに欠けることを心配される方もいらっしゃるかもしれません。このプロセスでは正確な測定値が得られなくてもかまいません。ただ、以下2つの目的を達成するのに十分な精度があることが重要です。

1. チーム横断的な取り組みを組織し、資金を提供している人々に、起こっていることの価値を表す手段を提供します。
2. チーム横断的な取り組みのうち、どの分野がより高い価値を持ち、優先的に追求されるべきかを関係者が知ることができるようにします。

実際には、これらの評価が現実と一桁以内の誤差である限り、これらの目的を満たすのに十分な精度であると言えます。 ドキュメント冒頭の「**問題**」で述べたような場当たり的な評価（およびその結果生じる影響）に比べ、現場での結果は頭一つ抜きん出たものになるでしょう。

### 結果の状況

* チーム横断型プロジェクトの価値と資金調達について、リーダーシップと議論するためのデータ駆動型の手段になります。
* クロスチーム・プロジェクトに関する主要な指標を素のデータの形で計測することができます。
* クロスチーム・プロジェクトがどのように価値を提供するかを定義することで、実際に企業にとってより大きな価値を生み出すことにつながる傾向があります。
* 一般的に成功したプロジェクトの周辺でバズが生まれます。

### 事例

* Nike

### ステータス

* Structured
* Proven in multiple domains.

### 著者

* Russ Rutledge

### Acknowledgement

* Jeremiah Wright さんは、クロスチーム・プロジェクトを、開発者の時間という"通貨"を扱う社内ビジネスとして考えるように教えてくれました。

### 翻訳の履歴

* **2022-06-03** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
* **2023-06-18** - 最終更新


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://patterns.innersourcecommons.org/ja/crossteam-project-valuation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.