実験として始める

Title

実験として始める

Patlet

インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。

問題

インナーソースイニシアチブは検討されているものの、経営陣がその結果について確信が持てず、その結果として投資にコミットする意思がないため、なかなか開始されません。

状況

会社は、ソフトウェアプロジェクトにおけるコラボレーションの効率を高めるために、InnerSourceを検討しています。しかし、ほとんどの管理者は、オープンソースの作業モデルに精通しておらず、代わりに階層的な、トップダウンの制御スタイルの管理に慣れています。InnerSourceのアイデアは、社内のソフトウェア開発者に非常に人気があり、少なくとも多くの開発者がオープンソースソフトウェアを使用しているか、積極的に開発しているためです。

同社は、ソフトウェアプロジェクトでのコラボレーションの効率を高めるためにインナーソースを検討しています。 ただし、ほとんどのマネージャーはオープンソースの作業モデルに精通しておらず、代わりに階層的なトップダウンの制御スタイル管理に慣れています。インナーソースのアイデアは、社内のソフトウェア開発者に非常に人気があります。その理由は特に、多くの開発者がオープンソースソフトウェアを使用または積極的に開発しているためです。

組織に働く力学

  • マネージャーは長期的な投資を行う前に、インナーソースを用いたコラボレーションにおいて効果が期待できるかを検証する必要があります。これには通常、改善したかを測定することが含まれます。

  • インナーソースイニシアチブが開発者の間で大きな支持を得る可能性が高く、多くのプロジェクトがそれに依存する可能性が高い場合、それをシャットダウンする決定は非常に不人気であり、実施するのは困難でしょう。導入した結果、コントロールを失う可能性が認識される場合、一部のマネージャーはインナーソースを始めることさえ思いとどまる可能性があります。

  • インナーソーススタイルの作業モデルの実装は、以前に実践されていた作業モデルからの根本的な逸脱であることがよくあります。したがって、既存の必須プロセスはもはや適用できず、適切な管理プロセスが失われてしまう可能性があります。その結果、規制や、時には法的規制のない場所で活動しなければならなくなるかもしれません。例えば、複数の国に複数の法人を持つ大企業では、税金や輸出管理関連の規制があります。

ソリューション

インナーソースイニシアチブを期間限定の実験として宣言します。インナーソース実験に参加するプロジェクトの基準を定義し、伝達します。健全なコミュニティを構築する可能性を最大化する基準を選択してください。実験の文脈の中でそこから生み出された洞察が、他のインナーソースプロジェクトの可能性を含む文脈に直感的に適用できるならば、一連の基準は良いものであると言えるでしょう。 このような基準の例は次のとおりです。

  • 開発者の十分な地理的分布

  • 開発者の十分な部門別構成

  • コミュニティ内の風通しの良さ

  • コミュニティ内での能力に応じたキャリアパス

  • コミュニティ内での民主的な意思決定

再評価するために、実験のおわりを ピボット、 変更 、または 一時停止 のポイントに指定することを検討してください。また、参加を通じて経営陣の賛同の機会を増やすために、レビュー委員会を設立することを検討してください。企業の文化によっては、適切なメトリックを使用して実験を行うことが役立つ場合があります。実験のプロジェクトが企業の収益に直接影響を与えない場合は、チーム間のプロジェクト評価を導入して、その価値への貢献を強調することを検討してください。

結果の状況

マネージャーが、インナーソースをキックスタートできる理由になりうるのは以下です。

  • インナーソースプログラムを以前の典型的なプロジェクトのように精査することが実験的なセットアップにより緩和されます。

  • 実験の失敗の可能性が理解され、受け入れられているので、サポートするマネージャーの個人的なリスクが最小限に抑えられます。

  • 失敗した場合でも、実験的なセットアップにより、会社は失敗から学ぶことができます。

  • 成功した場合、実験中に収集されたデータによって、マネージャーはインナーソースに対してより長期的なコミットメントを行うことができます。

インナーソースの実験参加者は、インナーソースが約束された利益をもたらすことを経営陣に証明する必要があることを認識しています。 したがって、最も実証可能な価値を提供し、成功の可能性を高める活動に集中するのに役立ちます。 また最後に、実験として開始すると、成功の可能性を減らすかもしれないツールやプロセスポリシーなどの規制や力を回避することがはるかに簡単になります。

Related Patterns

事例

  • Robert Bosch GmbH (グローバルな分散型ソフトウェア開発組織を有する)

ステータス

  • Structured

著者

  • Georg Grütter (Robert Bosch GmbH)

謝辞

  • Jason Zink (Robert Bosch GmbH)

  • Diogo Fregonese (Robert Bosch GmbH)

  • Robert Hansel (Robert Bosch GmbH)

  • Hans Malte Kern (Robert Bosch GmbH)

  • Russ Rutledge (Nike)

  • Tim Yao (Nokia)

  • Clint Cain (Optum)

翻訳の履歴

前へ基本原則ガイダンスの文書化次へ成熟度モデル

最終更新