本記事は以下のMicrosoft トレーニングを要約したものです。

DevOps の概要 - Training

この基本モジュールでは、DevOps の原則、プラクティス、および変換戦略の包括的な概要を提供します。 DevOps とは何か、組織が DevOps の取り組みを開始する方法、Azure DevOps や GitHub などの主要なツールを...

learn.microsoft.com

　

DevOps とは

1. DevOps（デブオプス）とは何か？

従来の「開発（Dev）」と「運用（Ops）」は、壁（サイロ）によって分断されがちでした。DevOpsとは、この壁を取り払い、一つのチームとして協力し合う文化や手法のことです。

• 目的: 顧客に価値を素早く、継続的に届けること。
• 重要な要素:
  • 文化（責任の共有）
  • 自動化（CI/CD：継続的インテグレーション/デリバリー）
  • 監視
• ポイント: DevOpsは「導入して終わり」ではなく、「永遠に改善し続けるプロセス」です。

2. DevOpsのビジネス価値（メリット）

DevOpsを実践すると、具体的に以下の「4つの指標」が改善し、ビジネスに貢献します。

指標	従来	DevOps導入後
デプロイ頻度	年に数回	頻繁に（毎日、毎週）
変更のリードタイム	アイデアからリリースまで数ヶ月	数時間〜数日
平均復旧時間 (MTTR)	障害対応に時間がかかる	すぐに復旧できる
変更失敗率	リリースするたびに不具合が出る	不具合が少ない

結論： 新機能をすぐに市場に出せ、かつシステムも安定するため、顧客満足度も開発者の満足度も上がります。

3. サイクルタイムとOODA（ウーダ）ループ

ビジネスで競合に勝つためには、「意思決定のスピード」が重要です。そのフレームワークとしてOODAループが紹介されています。
• Observe（観察）：データやユーザーの行動を見る
• Orient（方向づけ/状況判断）：データから何ができるか分析する
• Decide（意思決定）：何をやるか決める
• Act（行動）：実際にリリースしてユーザーに使ってもらう
サイクルタイムとは？ このループを1周するのにかかる時間です。
　　　例: 「コードを1行修正して、それが本番環境に反映されるまでの時間」 これが2週間かかるなら、あなたのチームの改善速度（サイクルタイム）は「2週間」です。これを短くするのが目標です。

4. データ・インフォームド（データに基づく判断）

「データ分析」に時間をかけすぎて動けなくなってはいけません（分析麻痺）。 重要なのは、「小さく試して、結果を見て、次を決める」ことです。これを「ピボット（方向転換）か、継続か」と呼びます。
• リリース結果は3つしかありません：
1. 成功（ポジティブ）
2. 失敗（ネガティブ）
3. 変化なし
• 戦略: ダメならすぐに撤退し（Fail Fast）、うまくいったら投資を増やす。

5. 検証された学習 (Validated Learning)

推測や思い込みではなく、「実際のデータ（証拠）」に基づいて学ぶことを「検証された学習」と呼びます。
サイクルタイムを短くし、デプロイ頻度を上げると、この「実験と学習」の回数を増やせます。
• 良いフィードバックの条件:
○ 事実に基づく: ユーザーが実際にどう動いたか（テレメトリデータ）
○ アクション可能: 次に何をすべきかがわかる
○ タイムリー: すぐに次の開発に活かせる

DevOps 体験を探索する

1. DevOpsの目標とロードマップ

最大の目標 「サイクルタイムの短縮」です。 つまり、「たった1行のコード変更を、本番環境に出すのに何分かかるか？」という問いに対し、その時間を極限まで短くすることを目指します。

導入の4段階（ロードマップ） いきなり全てやるのは無理なので、段階を踏みます。

フェーズ 1：基盤作り

• Gitでソースコード管理をする。
• 基本的な自動化（CI/CD）を導入する。
• 監視を入れる

フェーズ 2：自動化の徹底

• テストを自動化する。
• インフラ構築をコード化する（IaC）。
• セキュリティチェックを自動化する。

フェーズ 3：最適化

• 高度なデプロイ手法（カナリアリリースなど）を取り入れる。
• 監視を強化する（※より詳細な分析やコスト最適化）。

フェーズ 4：文化と拡大

• この成功体験を他のチームにも広げる。

2. 具体的な5つのプラクティス

DevOpsを支える5つの柱です。

① 継続的インテグレーション (CI)

• 何をする？: コードを毎日（あるいはもっと頻繁に）マージし、自動テストを実行する。
• メリット: バグを「開発した数分後」に見つけられる（数週間後ではない）。

② 継続的デリバリー (CD)

• 何をする？: いつでも本番環境にリリースできる状態にし、リリース作業を自動化する。
• 高度な戦略:
  • Blue-Green: 本番環境を2面用意し、瞬時に切り替える。
  • カナリア: 一部のユーザーだけに新機能を公開して様子を見る。
  • 機能フラグ: コードはリリースするが、機能はOFFにしておく（後でONにする）。

③ バージョン管理 (Git)

• GitHub Flowなどを使い、コードレビュー（Pull Request）を経てマージするルールを徹底する。

④ アジャイル計画

• 小さな単位（スプリント）で計画し、実行する。
• 重要: 「完了の定義 (Definition of Done)」に「テレメトリ（監視データ）が取れるようになっていること」を含めるべきです。動くだけでは完了ではありません。

⑤ 包括的な監視 (Monitoring)

• APM (Application Performance Monitoring): 応答速度、エラー率などを監視。
• 分散トレーシング: マイクロサービス間の処理の流れを追跡。
• ビジネスメトリクス: 「機能が何回使われたか」など、ビジネス上の成果を計測。

3. インフラの現代化

DevOpsを加速させる技術要素です。
• クラウド (IaaS/PaaS): サーバーを即座に調達できる。
• IaC (Infrastructure as Code): インフラ構築をコード（プログラム）で行うことで、再現性を高め、ミスを減らす。
• マイクロサービス: アプリを小さく分割し、変更の影響範囲を狭くする。
• コンテナ: 仮想マシンより軽量で、どこでも同じように動く環境を作る。

4. アンチパターン（やってはいけないこと）

• ツール優先: 「高いツールを買えばDevOpsになる」わけではありません。
• ビッグバン: 一気に全てを変えようとすると失敗します。小さく始めましょう。
• DevOpsチームというサイロ: 「DevOps担当チーム」に全て任せて、開発者が運用に関与しないのは間違いです。全員でやるものです。
• セキュリティ軽視: 最後にセキュリティチェックをするのではなく、最初から組み込む（DevSecOps）。

5. 成功のためのマインドセット

「痛みを伴うなら、もっと頻繁にやれ（If it hurts, do it more often）」

• デプロイ作業が辛くて大変なら、たまにやるから大変なのです。
• 毎日（あるいは1日に何度も）デプロイするように自動化・改善すれば、それは「日常」になり、痛みはなくなります。
• まずは「手動でやっていて辛い作業」を自動化するところから始めましょう。

　

変革チームを特定する

1. なぜDevOps変革は失敗しやすいのか？

新しい組織をゼロから作るなら簡単ですが、既存の会社を変えるのは困難です。主な理由は2つあります。
• 可用性の課題（時間がない）: 変革リーダーが「日常業務（顧客対応やトラブル対応）」も兼任していると、必ず日常業務が優先されます。「未来のための改善」より「今の火消し」が勝つからです。
• 組織の慣性（変われない）: 既存のプロセスは今のビジネスを回すために作られているため、新しいやり方（DevOps）を導入しようとすると、既存のルールや習慣が邪魔をして、現状維持の力が働きます。

2. 解決策：専任の「変革チーム」を作る

片手間で改革はできません。「イノベーションを実行する方法」の研究によると、既存の業務から切り離された「別のチーム（変革チーム）」を作ることが成功の鍵です。

推奨されるコアチーム構成（3〜7名）
このチームのメンバーは、日常業務から解放される必要があります。

役割	稼働率	責任とスキル
DevOps エンジニア (リーダー)	100%	【技術の実装】 CI/CDパイプラインの構築、自動化、クラウド基盤の整備。 指標：パイプラインの信頼性、デプロイ頻度。
開発 (Dev) 代表	50-75%	【開発現場との橋渡し】 開発者のワークフロー改善。現場の痛みを理解している人が担当。 ※重要：**バックフィル（代わりの要員）**を用意し、元の業務から抜ける時間を確保すること。
運用 (Ops) 代表	50-75%	【運用現場との橋渡し】 インフラ、監視、障害対応の視点を提供。 ※重要：こちらもバックフィル（代わりの要員）が必要。
チェンジマネジメント専門家	75-100%	【人と文化の変革】 トレーニング、広報、抵抗勢力への対応、組織心理学。 技術よりも「人」を動かす役割。
プロダクト/ビジネス代表	25-50%	【ビジネス価値の調整】 技術遊びにならないよう、ビジネスの利益に直結しているか監視・助言する。

拡張メンバー（必要に応じて参加）
• セキュリティ・チャンピオン: 初期の段階からセキュリティを組み込む (DevSecOps)。
• 測定・分析スペシャリスト: 成功を数値化する（KPI定義、ダッシュボード作成）。
• エグゼクティブ・スポンサー (役員クラス): 「予算」と「権限」を持つ後ろ盾。組織の壁を壊すために不可欠です。

3. 抵抗を乗り越えるための戦略

現場からの「なぜ変える必要があるの？」「面倒だ」という抵抗をどう管理するか。
• まず “Why” (なぜ) を伝える: 「上司に言われたから」ではなく、「ビジネスにどう役立つか」「あなた（開発者）にとってどう楽になるか」を明確にする。
• 段階的に進める (スモールスタート): いきなり全社展開しない。まずは「パイロットプロジェクト（早期導入チーム）」で成功事例（クイック・ウィン）を作り、「あれ、便利そうだな」と周囲に思わせる。
• オープンなコミュニケーション: 不安や不満を聞く場（タウンホールミーティングなど）を設ける。悪いニュースも隠さない。
• 成功を祝う: 小さな改善でもチームや個人を称賛し、変革が進んでいることを可視化する。

4. メンバー選びの基準（誰を選ぶべきか）

単に技術力が高い人を選べばいいわけではありません。以下のような資質が必要です。
• 社内で尊敬されている: 他の人に影響力を持ち、話を聞いてもらえる人。
• 日常業務から離れられる: 結果にコミットできる（火消しに呼び出されない）人。
• 多様な視点: 開発、運用、ビジネスなど異なる背景を持つ人。
• 既成概念にとらわれない (Box outside thinking): 「枠にとらわれない発想ができる人」。現状を疑い、実験を楽しめる人。
• コラボレーション: 自分の部署だけでなく、組織の境界を越えて協力できる人。
外部専門家の活用
社内に知見がない場合は、外部のコンサルタントや専門家を入れることも検討します。彼らは「客観的な視点」と「他社での成功体験」をもたらし、学習を加速させてくれます。

　

アジャイル プラクティスの組織構造を定義する

1. 組織変革の課題：なぜ変われないのか？

大企業がアジャイルになりきれないのには、構造的な理由があります。
• 厳格な階層構造: 何をするにも上司の承認が必要で、決定が遅い。
• コンプライアンス重視: 「顧客に価値を届けること」よりも「社内ルールを守ること」が優先される。
• リスク回避: 失敗が許されないため、新しい実験ができない。
• サイロ化: 部門ごとに壁があり、全体最適ではなく「自分の部署の都合」で動く。
しかし、市場の変化やスタートアップの台頭に対抗するため、多くの企業がこの壁を壊そうとしています。

2. 文化のシフト：何を変えるべきか？

① 階層（ヒエラルキー）から「ネットワーク」へ
• 従来: 上層部が決定し、部下に指示が降りてくる（トップダウン）
• アジャイル: 現場のチームに権限を委譲する（自律型）
○ 管理職の役割は「命令・管理（Controller）」から、チームを支援する「コーチ」へと変わる必要があります。
○ 「ここまでなら自分たちで決めていいよ」という境界線を明確にします。
② プロセス遵守から「成果（Outcome）」へ
• 従来: 結果がどうあれ、決められた手順通りにやることが正義。
• アジャイル: 顧客に価値が届いたか（成果）が正義。
○ 成果が出ないなら、プロセス（やり方）自体をチームが自分たちで変えていく。
○ これを定期的に行うのが「レトロスペクティブ（振り返り）」です。

3. チーム構造：水平 vs 垂直（ここが最重要）

チームをどう編成するかについて、「水平分割」と「垂直分割」という対比で説明されています。DevOpsでは垂直分割が推奨されます。

❌ 水平チーム（Horizontal Teams）：従来のやり方

技術的な「層（レイヤー）」ごとにチームを分ける方法です。
• UIチーム（画面を作る人たち）
• サーバーサイドチーム（ロジックを書く人たち）
• DBチーム（データを管理する人たち）
【デメリット】
• 伝言ゲームが発生する: 1つの機能を作るのに、複数のチームの調整が必要。「DBチームの作業待ちでUIチームが動けない」といったことが頻発します。
• 責任の押し付け合い: バグが出た時、「俺たちのせいじゃない、あっちのチームだ」となりがち。
• ビジネスが見えない: 技術的なことばかり気にして、「ユーザーにとって何が良いか」が見えなくなります。

✅ 垂直チーム（Vertical Teams）：推奨されるやり方

ビジネス機能（フィーチャー）ごとに、必要な職種を全て詰め込んだチームです。「クロスファンクショナル（機能横断）チーム」とも呼ばれます。
• メール機能チーム（このチーム内に、UI担当、サーバー担当、DB担当が全員いる）
• 音声通話チーム
• 動画配信チーム
【メリット】
• エンドツーエンドの責任: その機能に関しては、アイデア出しから運用・監視まで、そのチームだけで完結できる。
• スピード: 他のチームの作業を待つ必要がないので、爆速で開発・リリースできる。
• 顧客視点: 「メール機能を良くする」という目的で団結しているため、ビジネス価値に集中できる。

4. スケーリング（拡大）の原則

垂直チームを増やして組織を大きくする際のポイントです。
• チームは小さく: 5〜9人が理想（Amazonの「ピザ2枚ルール」のように、コミュニケーションコストを下げるため）。
• プロジェクトではなく「製品」: 「プロジェクトが終わったら解散」ではなく、その機能を長く担当し続ける固定チームにする。
• コンウェイの法則 (Conway’s Law):
「システム設計は、組織のコミュニケーション構造を反映する」 つまり、「独立したきれいなマイクロサービスを作りたければ、組織も独立した垂直チームに分けなさい」という教えです。
• 共有サービス（プラットフォームチーム）: 各チームでバラバラにやるのが非効率な部分（セキュリティ基盤や共通ツールなど）は、専門の「プラットフォームチーム」が作って、各垂直チームにサービスとして提供します。

まとめ

このページが言いたいのは、「技術レイヤー（UI/DBなど）でチームを分けるのをやめて、ビジネス機能（買い物カゴ/決済/検索など）単位で、職種ごちゃ混ぜのチームを作りなさい」ということです。
そうすれば、「他部署の承認待ち」や「依頼待ち」がなくなり、自分たちだけで意思決定してリリースできるようになる＝DevOpsのスピードが手に入る、というロジックです。

　

共有された目標を調べてタイムラインを定義する

1. SMARTな目標を設定する

DevOpsの変革を成功させるには、曖昧なスローガンではなく、以下のSMART基準を満たす目標が必要です。
• Specific（具体的）
• Measurable（測定可能）
• Achievable（達成可能）
• Relevant（関連性がある）
• Time-bound（期限がある）
具体的な目標設定の例（Before/After）

項目	ダメな目標（曖昧）	SMARTな目標（良い例）
デプロイ頻度	「もっと頻繁にリリースする」	CI/CDを整備し、6ヶ月以内にリリース頻度を「毎月」から**「毎週」**にする。
バグ対応	「バグを減らす」	テスト自動化により、9ヶ月以内に本番環境での重大バグを60%削減する。
計画外作業	「火消し作業（トラブル対応）を減らす」	自動化と監視強化により、12ヶ月以内に突発的な対応時間を70%削減する。
勤務時間外	「残業や深夜呼び出しを減らす」	8ヶ月以内に、緊急呼び出しによる稼働時間を全体の10%以下にする。

2. ビジネス価値にフォーカスする

エンジニアは「デプロイ回数」や「サーバー稼働率」ばかり気にしがちですが、本来の目的は「顧客を満足させること」です。 技術的な指標だけでなく、以下の顧客中心の指標も追う必要があります。
• NPS (ネットプロモータースコア): 顧客がどれくらい満足し、他人に推奨したいと思っているか。
• 機能利用率: 作った新機能が実際に使われているか。
• 解決時間: 顧客からの問い合わせをどれくらい早く解決できたか。

3. OKR（目標と主要な結果）を使う

目標管理のフレームワークとして、GoogleやIntelなどで採用されているOKR (Objectives and Key Results) が推奨されています。
• Objective (目的): ワクワクするような定性的な目標（方向性）。
例：「世界一信頼性の高いソフトウェア配信組織になる」
• Key Results (主要な結果): その目的が達成されたか判断するための、具体的な数値目標。
例1： 稼働率 99.9% を達成する 例2： 平均復旧時間 (MTTR) を 30分未満 にする 例3： ダウンタイムなしで 毎日 デプロイする

4. タイムライン（ロードマップ）の引き方

いきなり全てを変えるのではなく、期間ごとに区切って進めます。

短期目標（2〜8週間）：クイック・ウィン（小さな成功）

• 狙い: すぐに結果を出して、チームの士気を上げ、上層部の信頼を得る。
• やること: 基本的なCIの導入、監視ダッシュボードの作成、手作業の1つを自動化する。

中期目標（3〜6ヶ月）：本格的な改善

• 狙い: 勢いに乗って、重たい課題を解決する。
• やること: 完全なCI/CDパイプラインの構築、IaC（インフラのコード化）、テスト自動化。

長期目標（6〜24ヶ月）：文化の変革

• 狙い: 組織全体の当たり前を変える。
• やること: DevOps文化の完全な定着、レガシーシステムの刷新。

5. レビューと適応（PDCAを回す）

計画は一度立てたら終わりではありません。短いサイクル（週次・月次）で振り返りを行います。
• なぜ短いサイクルがいいのか？
○ 方向転換（ピボット）しやすい: 間違っていたらすぐに修正できる。
○ 学習スピード: 「やってみて、ダメだった」というフィードバックを早く得られる。
○ リスク低減: 小さく失敗することで、致命傷を防ぐ。

まとめ

「『頑張ります』ではなく、『いつまでに、どの数値を、どう変えるか』を約束しなさい」 ということです。
そして、その約束（数値目標）を守れているか確認するために、定量的データ（監視データ）が不可欠になります。

　

Azure DevOps とは

1. Azure DevOpsの5つの主要機能

Azure DevOpsは、以下の5つのサービスの総称です。これらは開発ライフサイクルの各フェーズに対応しています。

サービス名	何をするもの？	競合/類似ツールのイメージ
Azure Boards	【計画・管理】 タスク管理、カンバン、バグ追跡。誰が何をやるか管理します。	Jira, Trello, Redmine
Azure Repos	【コード管理】 Gitリポジトリ。ソースコードを保存する場所です。	GitHub, GitLab, Bitbucket
Azure Pipelines	【自動化 (CI/CD)】 コードのビルド、テスト、デプロイを自動でやるロボットです。	Jenkins, GitHub Actions, CircleCI
Azure Artifacts	【部品管理】 作成したライブラリやパッケージ（npm, NuGetなど）を保存・共有する場所です。	npm, Maven Central, JFrog Artifactory
Azure Test Plans	【テスト管理】 手動テストの手順書管理や、テスト結果の記録を行います。	TestRail

2. 「Microsoft専用」という誤解を解く

このページの後半で強調されているのは、「Azure DevOpsは、Windowsや.NETのためだけのツールではない」ということです。
• 言語は何でもOK: Node.js, Python, Java, PHP, Ruby, C++, Go, Android, iOS… なんでも扱えます。
• OSは何でもOK: Windowsはもちろん、LinuxやmacOSのビルドもできます。
• デプロイ先は何でもOK: Azureだけでなく、AWS (Amazon) や GCP (Google) へのデプロイも標準でサポートしています。
• 全部使わなくてもOK: 「コード管理はGitHubがいいけど、パイプラインだけAzure DevOpsを使いたい」という使い方も可能です（柔軟性）

　

ライセンス管理戦略を設計する

1. パイプラインの「待ち時間」問題（並列ジョブ）

開発が進み、複数のチームがCI/CDパイプラインを回し始めると、渋滞（キュー待ち）が発生します。
• 現状: Azure DevOpsには無料枠がありますが、基本的には「一度に1つの処理」しかできません。
• 問題: Aさんがビルドしている間、Bさんのビルドは待ち状態になります。
• 解決策: 「並列ジョブ (Parallel Jobs)」にお金を払うことで、レーンを増やし、同時に複数のビルドを走らせることができます。
検討すべきこと:
○ 「ビルド待ち」で開発者の手が止まっている時間はどれくらいか？
○ それは今すぐ必要な緊急ビルドか？それとも急がない検証用か？
○ お金を払ってレーンを増やす価値があるか？

2. ユーザーライセンスの最適化（誰に何を見せるか）

全員に高いライセンスを買う必要はありません。役割に応じて使い分けます。

ユーザーの種類	役割	ライセンスの考え方
Basic Users	開発者	コードを書く、パイプラインを回す人。5人までは無料ですが、それ以上は有料です。
Stakeholders	管理者・顧客	コードは書かないが、進捗（ボード）は見たい、承認だけしたい人。無料で無制限に追加できます。
Visual Studio Subscribers	Pro開発者	既にVisual Studioのサブスクリプション（MSDN）を持っている人。Azure DevOpsの権利も含まれているので、追加料金は不要です。

戦略: マネージャーやビジネス担当者には無料の「Stakeholder」ライセンスを割り当ててコストを削減しましょう。

3. アーティファクト（容量）の問題

「Azure Artifacts」は、作成した部品（パッケージ）を保存する場所です。 無料枠（2GB）を超えると課金されます。「古いバージョンを自動で消す」などの戦略が必要になります。

まとめ

ライセンス戦略を設計する際は、以下の質問に答えてプランを決めます。
1. フェーズは？ （実験段階なら無料枠でOK、本格運用なら有料化を検討）
2. ユーザー数は？ （5人を超えるか？ その中にVisual Studio所有者はいるか？）
3. スピードは重要か？ （ビルド待ち時間を減らすために追加料金を払えるか？）
4. 役割は？ （コードを書かない人には無料ライセンスを割り当てているか？）
要するに、「無駄なライセンス料を払わず、かつ開発チームを待たせない最適なプランを選びましょう」ということです。

　

ソース管理とは

1. ソース管理（バージョン管理）とは？

一言で言えば、「コードのためのタイムマシン兼コラボレーションツール」です。
• 何をするもの？: 誰が、いつ、どこを修正したかをすべて記録します。
• なぜ必要？: これがないと、開発者は自分のPCで「code_v1.txt」「code_final.txt」「code_final_real.txt」といったファイルのコピーを管理しなければなりません。これは事故の元です。

2. チーム開発における役割

• 衝突の解決: AさんとBさんが同じファイルを修正しても、それを安全に統合（マージ）できます。
• 履歴とロールバック: バグが出たり、間違ってファイルを消しても、過去の時点（スナップショット）にいつでも戻せます。
• 資産の保護: ソースコードは企業の「知的財産（IP）」です。これを人為的ミスや事故から守ります。

3. DevOpsの「基礎」である理由

ここが最も重要なポイントです。テキストには「アジャイルやDevOpsは、堅実なバージョン管理に依存している」とあります。
なぜなら、DevOpsの自動化（CI/CD）はすべて「ソース管理システムへのコードの登録」をトリガー（合図）にして動き出すからです。
• コードをコミットする → 自動テストが走る
• コードをマージする → 本番へデプロイされる
つまり、バージョン管理がしっかりしていないと、その後の自動化は一切できません。

4. 立場別のメリット

テキストでは、開発者と管理者それぞれの視点でメリットを整理しています。

立場	メリット
開発者	「毎日の必須ツール」 安心して実験ができ、チームと協力するための土台。これがないと仕事になりません。
管理者 (マネジメント)	「リスク管理とスピード」 知的財産（コード）が守られる安心感（IP Security）。 そして、市場に早く機能を届けるための基盤となります。

まとめ

「バージョン管理は単なる『ファイルの保存場所』ではなく、DevOpsという城を建てるための『土台』である」と伝えています。
ここがグラついていると、その上にどんな高度な自動化や監視を積み上げても崩れてしまいます。まずはGitなどのバージョン管理を徹底することが、DevOpsの第一歩です。

　

Git のローカルでの操作について説明する（演習の要約）

この実習の全体像（ストーリー）

この演習では、以下の「開発者の日常的なフロー」を体験します。
1. 準備: 自分のPCにGitリポジトリを作る。
2. 開発: アプリを作り、セーブ（コミット）する。
3. 改善: 本番（main）を汚さないように、別の場所（ブランチ）で作業する。
4. 統合: 作業が終わったら本番（main）に統合（マージ）する。
5. やり直し: 間違えた時に過去の状態に戻す（リセット）。

1. 環境構築と初期化 (Setup)

まず、フォルダを作ってGitの管理下に置きます。
• git init: 今いるフォルダをGitリポジトリ（保存場所）にします。
• git config …: あなたの名前とメールアドレスを登録します。「誰が変更したか」を記録するためです。
○ ※プロキシ設定の話が出てきますが、社内ネットワークなどで制限がある場合のみ必要です。通常は無視して構いません。

2. アプリ作成と「除外設定」 (.gitignore)

dotnet new mvc コマンドでASP.NET CoreのWebアプリを作ります。ここで重要なのが.gitignore（ギットイグノア）ファイルです。
• なぜ必要？: プログラムの実行時に自動生成されるファイル（binやobjフォルダ）や、個人のエディタ設定（.vscodeフォルダ）は、Gitで管理すべきではありません（ゴミになるため）。
• 操作: .gitignoreファイルに「管理したくないファイルやフォルダ」を書くことで、Gitに無視させます。

3. コミット (Commit)

Gitの保存は2段階で行われます。
1. ステージ (Stage / git add): 保存したいファイルを「カゴ」に入れる。
2. コミット (Commit / git commit): カゴの中身にメッセージを付けて「保存」する。
テキストではVS Codeの画面（GUI）で操作していますが、裏ではこのコマンドが動いています。

4. ブランチを切る (Branching)

直接 main ブランチ（本番用のコード）をいじるのは危険です。
• git branch feature-devops-home-page: 「ホームページ改造用」という作業場（ブランチ）を作成。
• git checkout …: その作業場に移動。
• 作業: ここでコードを修正（Index.cshtmlの書き換え）し、コミットします。

5. マージ (Merge)

作業場（ブランチ）での修正がうまくいったら、本番（main）に取り込みます。
1. git checkout main: mainに戻る。
2. git merge feature-devops-home-page: 作業場の内容をmainに合体させる。
3. git branch --delete …: 用済みになった作業場を削除する。

6. 履歴確認とリセット (Log & Reset)

• git log: 過去の変更履歴を見ます。「いつ、誰が、何をしたか」が分かります。
• git reset --hard <コミットID>: 【重要】 時間を巻き戻します。指定した過去の状態に強制的に戻します。
  • 注意: –hard を使うと、その時点より後の作業内容はすべて消えます。強力ですが危険なコマンドです。

重要なコマンド一覧（チートシート）

テキストに出てくる主要コマンドのまとめです。

コマンド	意味
git init	ここをGitリポジトリにする
git status	今どのファイルが変更されているか確認する
git add .	変更された全ファイルを「ステージ（保存候補）」にする
git commit -m “msg”	ステージされたファイルをメッセージ付きで保存する
git branch <名前>	新しいブランチ（作業場）を作る
git checkout <名前>	指定したブランチに移動する
git merge <名前>	指定したブランチの内容を今いるブランチに取り込む
git log	履歴を見る
git reset –hard	指定した過去の状態まで強制的に戻す（取り消し）

Azure Repos の概要

1. 2種類のバージョン管理システム

Azure Reposは、以下の2つの方式に対応していますが、現在はGitが圧倒的な主流です。
• Git (分散型): 現在のスタンダード。前のページで学んだものです。
• TFVC (Team Foundation Version Control – 集中型): 昔ながらの管理方式。古いシステムで使われることがありますが、新規プロジェクトでは通常Gitを選びます。

2. Azure Reposで何ができるのか？（主な機能）

単にコードを保存するだけでなく、「チームで安全に開発するための機能」が充実しています。
• 無制限のプライベートリポジトリ: 自分たちだけが見られる非公開のリポジトリを、容量無制限・個数無制限で作れます（※無料枠でもかなり使えます）。
• プルリクエスト (Pull Requests / PR): コードを変更した際、「これをマージしてもいいですか？」とチームメンバーにレビューを依頼する機能です。
ここでチャットのように議論（スレッド式ディスカッション）を行い、OKが出たら統合します。
• セマンティック・コード検索: 単なる文字検索ではなく、「クラス名」や「変数名」を認識して、巨大なコードの中から目的の箇所を賢く探し出せます。

3. 最も重要な機能：ブランチポリシー (Branch Policies)

このページで特に注目すべきは「ブランチポリシーによるコード品質の保護」です。 これは、「人間がミスをしようとしても、システムがそれを阻止する」機能です。
main ブランチなどの重要な場所に、以下のような「マージの条件」を強制できます。
• 「承認」が必須: 最低2人の先輩がレビューして「承認」ボタンを押さないと、マージできないようにする。
• 「ビルド成功」が必須: CI（継続的インテグレーション）が走り、エラーが出ていないこと。
• 「テスト合格」が必須: 自動テストがすべてパスしていること。
これらを設定しておけば、「バグのあるコードや、誰もチェックしていないコードが誤って本番環境に入ること」を物理的に防げます。

4. ツールとの連携

• あらゆるGitクライアントに対応: Visual Studio Code, Visual Studio, IntelliJ, コマンドラインなど、使い慣れたツールから接続できます。
• CI/CD連携: コードがプッシュされたら、自動的に Azure Pipelines を起動してデプロイまで行う、といった連携がスムーズにできます。

まとめ

Azure Reposは、「Gitリポジトリのホスティング」に加えて、「強力なレビュー機能」と「マージ前の強制チェック（ポリシー）」を提供するサービスです。
DevOpsの「スピード」と「品質」を両立させるために、このブランチポリシーの設定が非常に重要になります。

GitHub の概要

1. GitHubとは何か？

• 世界最大の開発プラットフォーム: 4000万人以上（現在はさらに増加）の開発者が利用しています。
• オープンソースの聖地: 世界中のほとんどのオープンソースプロジェクト（Linux, Node.js, VS Codeなど）がここで開発されています。
• 機能: Gitリポジトリのホスティングに加え、強力なコラボレーション機能（Wiki、タスク管理、SNS的機能）を持っています。

2. 主な機能とメリット

テキストでは多くの機能が挙げられていますが、特に重要なのは以下の4つの柱です。

① 自動化 (GitHub Actions)

Azure DevOpsの「Pipelines」に相当する機能です。
• コードからクラウドへ: コードをプッシュしたら、自動でビルド・テスト・デプロイまで行います。
• マーケットプレース: 世界中の誰かが作った便利機能（アクション）を自分のワークフローに簡単に組み込めます。

② セキュリティ (Security)

GitHubは「コードを置く場所」だからこそ、セキュリティ機能が非常に強力です。
• 脆弱性アラート (Dependabot): 「使っているライブラリに脆弱性が見つかったよ」と教えてくれるだけでなく、「修正版にアップデートするプルリクエスト」を自動で作ってくれます。
• シークレットスキャン: 「AWSの鍵」や「パスワード」をうっかり公開リポジトリにアップロードしてしまったら、すぐに検知して警告してくれます。
• CodeQL: コード自体を分析して、「ここがセキュリティ的に弱い書き方だ」と指摘してくれます。

③ コラボレーション (Code Review)

チーム開発の中心となる機能です。
• プルリクエスト (Pull Request / PR): GitHubが広めた開発スタイル。「変更案」を出して、みんなで議論・修正してから取り込みます。
• インラインコメント: コードの特定の行に対して直接コメントや質問ができ、会話がスムーズに進みます。
• ブランチ保護: 「テストに通らないとマージできない」「2人の承認がないとマージできない」といったルールを設定し、品質を守ります。

④ プロジェクト管理 (Project Management)

• Issues (イシュー): バグ報告や機能要望をチケットとして管理します。
• GitHub Projects: カンバンボードのような画面で、タスクの進捗を見える化できます。
• GitHub Pages: ドキュメントやWebサイトをリポジトリから直接、無料で公開できます。

3. Azure DevOpsとの使い分け

ここまで読むと「Azure DevOpsと何が違うの？」と思うかもしれません。

特徴	Azure DevOps	GitHub
得意分野	企業内のプロジェクト管理、大規模で複雑な権限管理	オープンソース、コミュニティ主導、開発者体験重視
雰囲気	管理ツール的（堅実）	SNS的（モダン・オープン）
現状	多くの企業で現役利用中	今後の主流（Microsoftもこちらに力を入れている）

まとめ

GitHubは単なる「コード置き場」ではなく、「開発者が協力し、自動化し、安全にコードを守るためのプラットフォーム」です。

概要

このモジュールでは、組織が DevOps 改革の取り組みを開始し、チームのマインドセットを変え、タイムラインと目標を定義するために取り組む必要がある重要な点について確認しました。
また、次の機能の利点と使い方を説明する方法も学習しました。

• DevOps とは何かと、実現するための手順
• プロセスを実装するチームの特定
• 目標とタイムラインを共有して変換を計画
• 目標に対するタイムラインを計画して定義