LogoLogo
Contribute to InnerSource PatternsJoin the community
🇯🇵 日本語
🇯🇵 日本語
  • イントロダクション
  • 目次
  • パターンの一覧
  • この本へのコントリビューション
  • パターン
    • 30日の保証期間
    • RFCを用いたチーム横断的な意思決定の透明化
    • イシュートラッカーの使い方を多様化する
    • インナーソースポータル
    • インナーソースライセンス
    • ギグマーケットプレイス
    • クロスチームプロジェクト評価
    • コアチーム
    • コミュニケーションツーリング
    • コントラクトコントリビューター
    • コントリビューションの功労を称える
    • サービス対ライブラリ
    • スタンダード・ベース・ドキュメンテーション
    • トラステッドコミッター
    • リポジトリアクティビティスコア
    • レビュー委員会
    • 共通要件
    • 基本原則ガイダンスの文書化
    • 実験として始める
    • 成熟度モデル
    • 持続可能な成長のためのエクステンション
    • 正式なコミュニティリーダー
  • 付録
    • パターンテンプレート
    • その他
      • README テンプレート
      • CONTRIBUTING テンプレート
  • リソース
    • GitHub
    • InnerSource Commons
GitBook提供
このページ内
  • Title
  • Patlet
  • 問題
  • ケーススタディ
  • 状況
  • 組織に働く力学
  • ソリューション
  • 結果の状況
  • 事例
  • その他の呼び方
  • ステータス
  • 著者
  • 謝辞
  • Changelog
  • 翻訳の履歴

役に立ちましたか?

GitHubで編集
PDFとしてエクスポート
  1. パターン

正式なコミュニティリーダー

前へ持続可能な成長のためのエクステンション次へパターンテンプレート

最終更新 1 年前

役に立ちましたか?

Title

正式なコミュニティリーダー

Patlet

インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。

問題

新しいインナーソースのイニシアチブがその影響を拡大するために適切なを持っていることを確認するにはどうすればよいか 間違った人を選択し、またはそれらのために十分なキャパシティを提供しないことは、無駄な努力と、最終的に新しいインナーソースイニシアチブの失敗を引き起こすリスクになる

ケーススタディ

次のようなストーリーを考えてみましょう。ある企業が、組織の境界を越えたコラボレーションを促進するために、インナーソースイニシアチブを始めたいと考えています。彼らは、範囲を限定した実験的な段階から始めることを決定しました。経営陣は、最初のインナーソースコミュニティに適したパイロットトピックを選択し、組織全体の多くのビジネスユニットからのコントリビューションを期待しています。会社はまだ完全に計画をできていなかったので、新入社員をコミュニティの責任者に指名し、業務時間の50%を割り当てました。6か月後、コミュニティにはわずかなコントリビューションしかなく、そのほとんどはひとつのビジネスユニットからのものでした。そこで、コミュニティリーダーを社歴の長い人物に代え、今度は30%の時間しか割かないようにしました。さらに6ヶ月後の結果は、コントリビュートがわずかに増加したのみでした。同社は、部門を超えたコラボレーションを増やす目標を達成するのに、インナーソースが役立つと確信できなくなり、インナーソースを放棄しました。

状況

  • この会社は大企業で古い会社で、またオープンソースやその他のコミュニティベースのワークモデルの経験がありません。企業文化は古典的なトップダウン経営スタイルとして最もよく特徴づけられています - それは一般的にコミュニティ文化とは相反するものです。

  • トップレベルの支持者とスポンサーがいる一方で、会社の中間管理職はまだインナーソースの価値を納得できていません。

  • 経営陣は、パートタイムのコミュニティ・リーダーに対し、限られた予算以上のリソースを提供することに納得していませんでした。

  • 最初に選ばれたコミュニティのリーダーは、オープンソースの作業モデルについてほとんど、あるいは全く経験がありません。

  • 最初に選ばれた開発者コミュニティのリーダーは、社内に広いネットワークを持っていません。

組織に働く力学

もし、企業がインナーソースの予算とキャパシティの面で初期のインナーソースコミュニティに大幅に投資していない場合、インナーソースへのコミットメントの信頼性は疑わしいと認識されるかもしれません。期待通りに実行されていないプロジェクトやイニシアチブに対する伝統的な管理文化を持つ企業の一般的な動きは、そのリーダーを交換することでしょう。コミュニティを巻き込むことなく、そして功績至上主義の原則に従わずに活動を行うことは、現在の企業文化とコミュニティ文化との間の摩擦を強調することにつながり、インナーソースへの企業のコミットメントをさらに弱体化させます。 インナーソースプロジェクトにおける価値の貢献は、従来のプロジェクト管理方法に慣れ親しんでいる多くのマネージャーにとっては明らかではありません。これらのマネージャーは、通常は非インナーソースプロジェクトから高い需要があるトップクラスの人物の1人を、作業時間のかなりの割合でインナーソースプロジェクトに割り当てる可能性が低くなります。 コミュニケーションは、コミュニティリーダーの日常業務のかなりの割合を占めています。同時に、担当者は初期開発の先頭に立つ必要があるでしょう。限られたキャパシティに直面して、経験の浅いリーダーは開発に集中し、コミュニケーションを怠る傾向があります。コミュニティリーダーが連絡を取りにくい場合や、時間不足のためにフィードバックや質問への回答が遅い場合、潜在的なコントリビューターが最初のコントリビューションをしてコミュニティにコミットするための障壁ははるかに高くなります。さらに技術的に経験の浅いリーダーは、企業で目立つトップパフォーマーと比べると、経験豊富なコントリビューターを引き付けて維持するのに苦労する可能性があります。 もしコミュニティが十分に速く成長し、十分なスピードを手に入れることができなければ、インナーソースの可能性を説得力を持って示すことができない可能性があります。 もし会社が伝統的な管理手法に慣れた経験豊富なプロジェクトマネージャーやラインマネージャーをコミュニティリーダーに選んだ場合、その人は功績至上主義で模範を示すのではなく、リソース配分、構造、報告ルートといった伝統的な管理テーマに焦点を当てる可能性が高いです。これは、開発者の目から見たインナーソースイニシアチブの信頼性を損ねることになります。

ソリューション

以下のようなコミュニティリーダーを選択します。

  • オープンソースの作業モデル、または類似のコミュニティベースの作業モデルの経験がある

  • 自然なリーダーとして活動するために必要なソフトスキルを持っている

  • 模範を示して指導し、コミュニティの功績至上主義において自分の立場を正当化することができる

  • 優れたネットワーカーであること

  • コミュニティーのメンバーにインスピレーションを与えることができる

  • 経営陣と開発者の両方に効果的にコミュニケーションをとることができる

  • コミュニティ活動の経営的な面を扱うことができる

コミュニティリーダーには、コミュニケーションや開発など、自分の時間の100%をコミュニティ活動に捧げることができるよう、権限を与えましょう。コミュニティ運営に変化をもたらす際には、コミュニティの意見に耳を傾ける必要があることを経営陣に伝え、理想的には、コミュニティが自らコミュニティリーダーを指名できるようにすることが望ましいです。

結果の状況

上記の能力を持つコミュニティのリーダーは、会社のインナーソースへのコミットメントを人前に出て体現することになります。彼のネットワーク内の他の同僚は彼のリードに従い、インナーソースに貢献する可能性が高くなります。

時間が経つにつれて、リーダーは、開発者の安定したコアチームを構築することができ、したがって、インナーソースプロジェクトの成功の可能性を高めることができます。 インナーソースの可能性について社内の十分な数のオーディエンスを納得させることによって、リーダーは企業文化をよりコミュニティ中心のものにする変革に大きく貢献することになります。

優秀で熱心なコミュニティリーダーを持つことは、インナーソースを成功させるための前提条件です。しかし、それは銀の弾丸ではありません。インナーソースには、予算、法律、財政、あるいはその他の組織的な課題など、コミュニティリーダーが取り組める以上の課題がたくさんあります。

事例

Robert Bosch GmbH における BIOS。Bosch社のインナーソースは、大半の場合、イノベーションを高めることを目的としており、かなりの割合で内部向けのプロダクトを扱っていました。このパターンは、資金不足のため、現在Bosch社では使われなくなりました。

その他の呼び方

Dedicated Community Manager

ステータス

  • Structured

著者

  • Georg Grütter (Robert Bosch GmbH)

  • Diogo Fregonese (Robert Bosch GmbH)

謝辞

  • Tim Yao

  • Padma Sudarsan

  • Nigel Green

  • Nick Yeates

  • Erin Bank

  • Daniel Izquierdo

Changelog

  • 2016-11-06 - 1st review

  • 2017-04-06 - 2nd review

翻訳の履歴

  • 2023-06-18 - 最終更新

2022-06-01 - 翻訳

2022-06-21 - レビュー

コミュニティリーダー
Yuki Hattori
@hirotakatoya