GitHub プロジェクトを構成する

プロジェクトのスコープと所有権を理解することは、GitHub プロジェクトと Azure Boards の間のコラボレーションを成功させるために非常に重要です。 このユニットでは、プロジェクトの境界と責任を定義するための重要な考慮事項について説明します。

プロジェクトのスコープと所有権の決定

組織プロジェクトとユーザー プロジェクト - 決定マトリックス:

要素	組織プロジェクト	ユーザー プロジェクト
チームコラボレーション	複数チーム、部門間の作業	個人または小規模のチームの実験
ガバナンス	正式な承認プロセス、監査証跡	簡易化された迅速な反復プロセス
視認性	エンタープライズ全体の透明性	個人または限定的な可視性
アクセス制御	ロールベースのアクセス許可、エンタープライズ SSO	個々のコントロール
ライフサイクル	長期的な運用ワークロード	プロトタイプ、学習、テスト

ベスト プラクティスの推奨事項:

• 運用アプリケーションと共有サービスに組織プロジェクトを使用する
• 概念実証と個々の学習のためにユーザー プロジェクトを活用する
• スコープを選択するときは、データ ガバナンスとコンプライアンスの要件を考慮する

プロジェクト作成ワークフロー

組織プロジェクトの場合:

1. GitHub で組織のメイン ページに移動する
2. 組織のナビゲーションで [ プロジェクト ] をクリックする
3. [新しいプロジェクト] ドロップダウン → [新しいプロジェクト] を選択する
4. ワークフローのニーズに基づいて適切なプロジェクト テンプレートを選択する

ユーザー プロジェクトの場合:

1. アバターをクリックして、プロジェクトを選択
2. [新しいプロジェクト] ドロップダウン → [新しいプロジェクト] を選択する
3. プロジェクトの目標に合わせてテンプレートを選択する

プロジェクト テンプレートの選択ガイド:

Template	ユースケース(事例)	主な機能
チーム バックログ	スプリント計画、機能開発	ストーリー ポイント、スプリント サイクル
特徴	製品ロードマップ、リリース計画	マイルストーン、依存関係
バグの優先順位付け	課題管理、品質保証	重大度、優先度、状態の追跡
Blank	カスタム ワークフロー、特殊化されたプロセス	完全なカスタマイズの柔軟性

プロジェクトのドキュメントとコミュニケーション戦略

README と説明のベスト プラクティス:

1. プロジェクトに移動する
2. 右上の設定メニュー (3 つのドット) をクリックします
3. [設定] を選択する
4. 包括的なプロジェクト ドキュメントを作成します。

プロジェクトの説明フレームワーク:

• 目的:プロジェクトの目的と範囲の明確な声明
• 利害関係者: 主要なチーム メンバー、スポンサー、意思決定者
• 成功基準: 測定可能な結果と受け入れ基準
• タイムライン: 主要なマイルストーンと配信の期待

README コンテンツ構造:

# Project Name

## Overview

Brief description of project goals and context

## Getting Started

Prerequisites and setup instructions

## Workflow Guidelines

- Issue creation and labeling standards
- Review and approval processes
- Communication protocols

## Team Information

Contact details and responsibilities

エンタープライズ README テンプレートの例:

# Customer Portal Enhancement Project

## Project Overview

Modernize customer self-service portal to improve user experience and reduce support ticket volume by 30%.

## Key Stakeholders

- **Product Owner**: Name (email@company.com)
- **Tech Lead**: Name (email@company.com)
- **UX Designer**: Name (email@company.com)

## Success Metrics

- Page load time < 2 seconds
- User satisfaction score > 4.2/5
- Support ticket reduction of 30%

## Workflow Standards

- All features require design review before development
- Security review mandatory for user-facing changes
- Performance testing required for all releases

戦略的作業項目の計画と管理

問題の作成と組織戦略

プロジェクトの初期セットアップ ワークフロー: 新しいプロジェクトが初期化されると、項目を追加するように求められます。 これは、プロジェクトの基盤を確立する機会です。

戦略的な問題の作成アプローチ:

1. エピックとテーマから始める: 主要な機能やイニシアティブを表す高レベルの作業項目を作成する
2. ユーザー ストーリーに分けて: ユーザーの観点から特定のテスト可能な機能を定義する
3. 技術的なタスクの追加: インフラストラクチャ、テスト、デプロイ作業を含める
4. 依存関係を計画する: ブロック関係とクリティカル パス項目を識別する

issue テンプレートのベスト プラクティス:

フィーチャー課題テンプレート:

## User Story

As a [user type], I want [functionality] so that [business value].

## Acceptance Criteria

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Definition of Done

- [ ] Code review completed
- [ ] Unit tests written and passing
- [ ] Integration tests updated
- [ ] Documentation updated
- [ ] Accessibility review completed

## Dependencies

- Links to related issues or external dependencies

## Technical Notes

Implementation considerations and architectural decisions

プラス記号 (+) をクリックして、プロジェクト計画に基づいて体系的に問題を追加します。

作業項目の階層と組織:

• エピック: 主な機能または取り組み
• 機能: 提供される機能
• ユーザー ストーリー: 特定のユーザー向け機能
• タスク: 技術的な実装作業
• バグ: 解決が必要な欠陥と問題

高度な問題の分類の例

エンタープライズ プロジェクトのラベル付け戦略:

カテゴリ	ラベル	Purpose
優先順位	priority:critical、 priority:high、 priority:medium、 priority:low	リソースの割り当てとスケジュール
タイプ	type:feature、 type:bug、 type:technical-debt、 type:research	作業の分類とレポート
Team	team:frontend、 team:backend、 team:qa、 team:design	所有権と責任
地位	status:blocked、 status:in-review、 status:needs-info	ワークフローの状態管理
リリース	release:v2.1、milestone:q1-2024	リリースの計画と追跡

高度なプロジェクト構成とガバナンス

セキュリティとアクセスの管理

右上隅にあるメニュー (3 つのドット) をクリックして、プロジェクト設定に移動します。

アクセス制御のベスト プラクティス:

役割	アクセス許可	ユース ケース
管理者	プロジェクトの完全な制御、設定の管理	プロジェクト所有者、技術リーダー
書き込み	アイテムの作成/編集、ワークフローの管理	開発チーム メンバー
読み取り	プロジェクトコンテンツの表示、コメントの追加	利害関係者、QA チーム
アクセスなし	プロジェクトを表示できない	外部ユーザー、制限付きデータ

エンタープライズ セキュリティに関する考慮事項:

• すべてのプロジェクト管理者に対して 2 要素認証を有効にする
• 定期的なアクセス レビューとアクセス許可の監査 (四半期ごとに推奨)
• エンタープライズ SSO および ID 管理システムとの統合
• コンプライアンスとセキュリティの監視のための監査ログ

ユーザー設定フィールドとワークフロー構成

戦略的なユーザー設定フィールドの設計:

ビジネス価値の追跡:

• 作業量の見積もり: ストーリーポイントまたは時間見積もり
• ビジネスの優先順位: 顧客への影響または収益の可能性
• リスク評価: 技術的な複雑さまたは依存関係のリスク
• コンプライアンス要件: セキュリティ、アクセシビリティ、規制のニーズ

一般的なエンタープライズ ユーザー設定フィールドの例:

フィールド名	タイプ	値/オプション	Purpose
ビジネス価値	選択	High、Medium、Low	優先順位付けと ROI 分析
作業	Number	1-13 (フィボナッチ配列)	スプリントの計画とキャパシティ
コンポーネント	選択	フロントエンド、バックエンド、データベース、API	技術的所有権と専門知識
顧客セグメント	選択	企業、中小企業、個人	機能のターゲット設定と検証
リリース ターゲット	日付	特定の日付	マイルストーンと依存関係の計画

自動化とワークフローの最適化:

• プル要求の状態に基づいて自動状態遷移を設定する
• 重要な更新プログラムとブロックの通知を構成する
• レビュー サイクルと承認ワークフローを確立する
• 実行に滞った作業項目に対するエスカレーション手順を実施する

継続的な改善と分析

プロジェクトの正常性の監視:

• 速度の傾向とチームの容量使用率を追跡する
• 問題の作成から完了までのサイクル時間を監視する
• ボトルネックとプロセス改善の機会を特定する
• 定期的な振り返りとワークフローの調整

統合チェックポイント:

• 毎週のプロジェクト定例会議およびステークホルダーへのアップデート
• 毎月のプロセス レビューと最適化セッション
• 四半期ごとの戦略的アラインメントと目標評価
• 年次プロジェクト ガバナンスとセキュリティ監査

プロジェクトの詳細については、以下を参照してください。

• プロジェクトのクイック スタート - GitHub Docs。
• 問題の作成 - GitHub Docs。