協力してソフトウェアを開発する文化のベスト プラクティス

成功しているソフトウェア開発者は、職場で協力して同じ方法を構築します。これが「インナーソース」と呼ばれるアプローチです。以下のインナーソースのベスト プラクティスを導入すると、チームがコラボレーションしやすく効果的な開発者の文化を構築できます。

透明性を高くする

大規模なオープン ソース コミュニティと同様に、透明性はあらゆるインナーソース文化のベースラインです。

• 組織全体で可能な限り広くプロジェクトを共有する 場合により、高いレベルのセキュリティが必要なプロジェクトは例外とすることができます。
• オープンにやりとりし、整合性を保って構築できるようにチームにツールとプロセスを必ず用意する。また、そのツールとプロセスの使用を徹底する。まだそのようにできていない場合、習慣がしっかりと根付くまでその理由の追究と修正を繰り返します。
• エンジニアリング イニシアチブにリソースが十分に割かれ、リーダーシップ チームのサポートを受けていることを確認する。
• 組織の開発者には十分な自主性を持たせ、直属のチーム以外のプロジェクトに貢献してもらう。

ワークロードの分配

インナーソースのプラクティスを効果的に導入するには、コントリビュータがチームや組織的なサイロを越えて協働できる必要があります。

• 小規模な参加者グループ全体に管理権限を分配することで、承認とレビューの効率を向上させる。小規模で部門横断型の意思決定者チームは、チームが品質基準を守り、リーダーシップのサポートを得るのにも役立ちます。
• 負荷の高いワークロードを地理的に分散している開発者または開発者以外のチーム メンバーに分配する。
• 開発者ではないメンバーもインナーソース コミュニティの有益なアセットであることを念頭に置く。
• プロジェクト マネージャーがプロジェクトの状況を簡単に評価でき、プロジェクト タイムラインへの変更が問題となっているコードに直接関連付けることができる。
• テクニカル ライターがプロジェクト エンジニアと共に作業することを推奨し、正確にコード機能の作成元を記録できるようにする。
• セキュリティ エンジニアはコンプライアンスとセキュリティに関連する弱点がないかコードをレビューし、ワークフローの早い段階で問題を予防する。

コミュニケーションと継続的なレビューを推奨する

作業とフィードバックをオープンに共有することによりより多くのアイディアとコードがインナーソース コミュニティにもたらされます。

• バージョン管理システムのコメント、タグ付け、レビュー機能を十分に使用する。
• フォークとブランチを使用して、開発者が元のプロジェクトに影響を与えずに異なる変更を試せるようにする。このようなツールを使用すると、新しいコードを毎回書くのではなく簡単に既存のソリューションから始めることが可能になります。
• コード コミット時に他のメンバーをタグ付けすることにより、開発者が自分の直近の作業を早く、頻繁に共有するように促す。
• バグを発見したメンバーは問題を説明する Issue を作成する必要がある。コードを更新したら、そのコントリビュータをタグ付けして、バグが修正されたことが通知されるようにする。
• ソフトウェア開発ライフサイクル (テストやデプロイなど) で全てのメンバーが各ステップを見られるようにする。

必ず記録する

インナーソース プロジェクトが複雑になるにつれ、コード内に記録することが作業の前進を支え、整合性を保ちます。

• 記録は基本であり、補足ではない。効果的な記録は意志決定プロセスが外部のコントリビュータに明確になり、リソースの無駄や重複を回避できます。
• 全てのリポジトリに README と CONTRIBUTING ガイドを追加して、基本的な使用方法とプロジェクトのベスト プラクティスを全員が理解できるようにする。
• 新しい「コントリビュータ」やその他の参加者がオンボーディングし順応するために記録を使用する。
• コード内の記録を定期的に更新し、ユーザー ガイドとマニュアルがコードの最新バージョンと同期するように維持する。