[[168245]]

[51CTO.com 速報] オースティンで開催された今回のOpenStack Summitは、オープンソースプロジェクト管理における経験を共有する最高のプラットフォームとなりました。長年にわたりコミュニティで活動し、プロジェクトに貢献してきた私は、この件に関して発言するだけの確かな力を持っていることを証明してきました。

しかし、今日の記事では、この問題を逆の観点から解釈し、オープンソース プロジェクト管理におけるさまざまな望ましくない慣行について議論したいと思います。

1. 貢献者に迷惑をかける

ソフトウェア開発者やメンテナーは既に十分忙しいため、タスクを過剰に割り当てると不満が募るだけです。実際、オープンソースの世界における最大の誤解の一つは、マネージャーが過剰な作業負荷を与えることでチームメンバーのエンゲージメントが高まると信じていることです。率直に言って、タスクが多すぎると、メンバーが離れていく可能性があります。

2013年からCeilometerに貢献してくれている親友がいます。彼のコードレビュースキルは抜群で、他の人なら見逃してしまうようなエラーさえも見つけられます。プロジェクトマネジメントチームは、単にタスクを増やすのではなく、最終的に彼をコアレビュアーに昇格させました。信じてください、この達成感こそが、多くの優秀な技術者がこのプロジェクトに留まっている理由なのです。

2. 面倒な作業にのみ人を関与させる。

新規参加者の参加動機は様々です。貢献を通して自身の価値を実感したい人もいれば、学びたい人もいます。しかし、一般的に、人々は単調で高度な仕事に常に従事することに抵抗を感じる傾向があります。マネージャーが低レベルの貢献者の気持ちに全く無関心であれば、退屈なコンテンツと前述の作業負荷が相まって、多くの意欲的なオープンソース愛好家をあっという間に追い払ってしまうでしょう。

3. 小さな貢献を評価しない

タイプミスの修正は貢献とみなされるのでしょうか？ドキュメントの改訂も貢献とみなされるのでしょうか？このような考え方はオープンソースプロジェクトでは珍しくありませんが、こうした作業は実際には大きな価値があることが証明されています。

かつて私自身がプロジェクトを率いた経験があり、ドキュメントの誤りを修正し、短期間で56件のパッチをリリースし、バグを修正し、機能追加を行いました。些細な作業だったため、誰からも軽蔑されることはなく、自分の仕事に真に価値があると信じています。

4. 新婚夫婦に過度に高いハードルを設ける

オープンソースプロジェクトに新人が参加する場合、個々の技術スキルや職務経験には大きなばらつきがあることがよくあります。そのため、多くのマネージャーは彼らに過度に複雑なタスクを割り当ててしまい、結果として不満が生じ、中には自分の能力不足を感じてひっそりと辞めてしまう人もいます。

実際、新入社員の技術スキルを評価し（簡単な会話で大まかなレベルを把握するのに十分なはずです）、能力の範囲内でありながらも多少やりがいのあるタスクを割り当てる必要があります。

5. 人々に個人的な生活を犠牲にすることを要求する。

参加者のほとんどは、余暇にのみオープンソースへの貢献を行うため、これは非常に健全な開発アプローチです。ただし、プロジェクトメンバーが貢献のために私生活を犠牲にすることを期待するのは非現実的であり、プロジェクトの長期的な発展にとって有害で​​あることにご留意ください。

さらに、ビデオ会議やIRCミーティングの頻度が高すぎると、面倒に感じることがあります。オープンソースプロジェクトは、メンバーごとに異なるコミュニケーションや貢献方法を採用し、人間中心であるべきです。

6. 基礎となる行動規範を統合するのは難しすぎる。

コミュニティが発展するにつれて、根底にあるスタイルややり方が必然的にそのコミュニティを特徴づけるようになります。これはベテランにとっては楽しい経験となるかもしれませんが、新規参入者にとっては阻害要因となることもあります。

確かに、行動規範に関するガイドラインや指示書を作成する必要はありません。しかし、プロジェクトマネージャーとして、新入社員の気持ちに十分配慮しながら、チームが個性を維持できるよう努めるべきです。社内用語や「ミーム」を次々と生み出すことは、組織の成長を妨げるだけです。

7. 英語を母国語としない人が関与していないと感じないようにする。

ほとんどのオープンソースプロジェクトコミュニティは英語でコミュニケーションを行っており、これはコラボレーションの重要な前提条件です。しかし、技術スタッフの中には英語圏以外の国から来ている人もいるため、既存のメンバーとの円滑なコミュニケーションが難しく、結果としてモチベーションが下がってしまう可能性もあることを考慮する必要があります。

このような状況に直面した場合、代替手段を検討することができます。例えば、非同期通信、つまりテキストメッセージを送るといった方法があります。こうすることで、相手は翻訳ソフトを使って大まかな意味を理解することができ、外国語を話す際の緊張感も回避できます。

8. 先見性の欠如と権限委譲への意欲の欠如

これら2つの誤りは、様々なオープンソースプロジェクトでよく見られます。実際、参加後に新機能を開発し、既存メンバーからのフィードバックを求める貢献者もいます。この時点で、メンテナンスを担当する管理者は、メンバーが技術のこの部分に精通していないことに気づき、離脱を決意するかもしれません。プロジェクトの開発ビジョンとそれを取り巻くコミュニケーションが極めて重要であることを強調する必要があります。そうすることで、すべてのメンバーが同じ判断を持ち、チームに残って貢献すべきかどうかを理解できるようになります。

さらに、一部の責任は、一人で全てをコントロールするのではなく、他のメンバーに委任するべきです。パッチレビュー、サブシステム設計、バグ修正、ドキュメント作成などは、すべて担当する担当者が担当します。こうすることで、各メンバーは自分の役割と価値を実感し、プロジェクトチームに留まるモチベーションを高めることができます。

9. 貢献者の貢献を認めない。

オープンソースプロジェクトへの貢献方法は様々で、コードの作成だけに限りません。ドキュメント作成、バグのデバッグ、ユーザーサポート、エクスペリエンスデザイン、普及活動、さらには翻訳なども、非常に重要なタスクです。

したがって、非技術的な貢献に十分な注意を払い、チーム メンバーの階層を構築する際には、あらゆるタイプの才能を見逃さないように細心の注意を払う必要があります。

10. 感謝の気持ちの欠如

最後に、オープンソースプロジェクトにおける感謝の気持ちの重要性を強調したいと思います。これらのプロジェクトは多くの場合、参加者によって無償で構築されており、管理者として、私たちは皆の共有の精神を称賛すべきです。もちろん、参加者が直接感謝できる形で！

原題: オープンソースプロジェクト管理における悪習慣の回避、著者: Julien Danjou

[この記事は51CTOによって翻訳されました。提携サイトへの転載の際は、元の翻訳者と出典を51CTO.comとして明記してください。]