Azure DevOpsのシステム開発は、要件整理、サービス選定、設計・開発を経てテストへ進み、稼働と定着へと順に進みます。
稼働と定着まで進めると、開発から運用改善までを追跡できる仕組みになります。全体像は、Azure DevOpsのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・Azure DevOpsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Azure DevOpsのシステム開発の全体像
Azure DevOpsは、作業計画、コード管理、ビルド、テスト、デプロイをつなぐ開発・運用プラットフォームです。Azure上に作る業務システムそのものではなく、開発と改善を続けるための土台にあたります。
Boards・Repos・Pipelinesなどを一つの流れでつなぐ仕組み
各サービスが担う工程を把握しておくと、チームの運用に必要な範囲を選びやすくなります。
- Azure Boards：エピック、機能、ユーザーストーリー、タスク、バグ、スプリントの管理。
- Azure Repos：Gitリポジトリ、ブランチ、プルリクエスト、コードレビューの扱い。
- Azure Pipelines：コミットを契機に、ビルド、単体テスト、静的解析、パッケージ作成、ステージング配布、本番リリースを自動化できます。
- Azure Test Plans：手動テストや受入テストの管理。
- Azure Artifacts：NuGetやnpmなどのパッケージを社内で共有する。
作業項目、プルリクエスト、実行結果、テスト結果を関連付けておくと、後から追跡できます。Microsoft Learnも、計画からデプロイ、監視までの連携を基本イメージとして示しています（出典: Microsoft Learn「Azure DevOpsとは」、2026年8月確認）。
ServicesとServerの選び方（データ配置と運用体制）
データ配置と運用負担を比べると、ServicesとServerの候補を絞れます。
- Services：Microsoftが管理するクラウドで、サーバーのパッチ、可用性、更新を自社で抱えにくい方式。
- Azure DevOps Server：自社または委託先で運用する方式。
ソースコードやテストデータの配置、ネットワーク分離、既存の認証・監査基盤を細かく統制したい場合は、Serverが候補になります。Azure、Microsoft 365、Microsoft Entra IDを使う企業は、Servicesの計画を組み立てやすい環境です。
選定では、データ分類と接続できるネットワーク、復旧目標を確かめます。バックアップ担当と更新の許容範囲も確かめます。
Serverでは、サーバーやデータベースの費用と担当者が必要です。バックアップや監視、更新、保守も、自社か委託先が受け持ちます。
Servicesでも、Entra ID連携や条件付きアクセス、最小権限、エージェントの設計が必要です。Azure側リソースは、どこまでを自社が受け持つかを決めておきます。
Azure DevOpsのシステム開発の進め方
Azure DevOpsの導入は、アカウントを作りパイプラインを動かした後も続きます。6つのフェーズで技術要件と現場の運用ルールを決め、各フェーズの終了条件を明確にしておくと、手戻りを抑えられます。
1. 要件整理：導入目的と対象範囲
まず、改善したいことを言葉にしておきます。目的が曖昧なまま機能を選ぶと、Boardsが使われずReposの規則だけが厳しくなり、現場の負担が増えることがあります。
- 目的：月1回から週1回へのリリース、要件・変更・テスト結果の追跡、Jenkinsの手作業削減などです。
- 現状と移行：利用ツール、残すもの、移行履歴、廃棄データ、連携先、本番承認者の洗い出し。
- 対象範囲：チーム、プロジェクト、利用者数、Services／Server候補、移行対象、予算の合意。
調査では、リポジトリや課題管理、CI/CD、テストの状況を確かめます。加えて、認証の仕組みと個人情報の扱いを押さえ、Azure上の資産と運用担当も把握します。
GitHubやGitLab、Jenkins、Subversionなどの既存ツールを、一度に置き換える必要はありません。たとえば、Boardsだけを先に導入する、Reposだけを移行するといった選び方もできます。
KPIは、リードタイムや変更失敗率などから2〜4個選びます。導入の前後で比べられる指標にしておくと、定着後の効果を測りやすくなります。
2. 選定：Services／Serverと導入方式の比較
保管条件と接続要件を確かめてから方式を比べます。データの分類によって、選べる環境や必要な統制が変わるからです。
- データと規程：個人・顧客情報、ソースコード、テストデータのSaaS保管、国外保管、監査条件の整理。
- 接続条件：Entra ID、Microsoft 365、Azureサブスクリプション、Visual Studio、GitHubとの連携の確認。
- 導入方式：標準機能、Marketplace拡張や既存ツール連携、REST APIや独自拡張の比較。
- 見積もり範囲：DevOps環境構築とAzure上の業務アプリ開発の切り分け。
独自ダッシュボードなどを先に作り込むより、1チームのMVPでBoards、Repos、Pipelinesの流れを検証するほうが安全です。テストと承認も、同じMVPで試します。
利用者数やプロジェクト数、同時実行パイプライン数は、導入規模を決める材料になります。Self-hosted agentやArtifacts容量のほか、履歴移行、SLA、障害窓口も確かめます。
3. 設計・開発：権限、作業項目、パイプラインの形づくり
まず、OrganizationからProject、Team、Area、Iterationまでの構造を決めます。分割しすぎると横断的な進捗や権限の管理が難しくなります。一方で、集約しすぎると、領域別のバックログやアクセス制御が曖昧になります。
- 構成：組織、製品、開発ライフサイクルのどの単位で区切るか、将来のチーム数も含めた検討。
- ReposとBoards：mainへの直接プッシュを禁止し、ブランチポリシーでレビュー人数、ビルド成功、脆弱性検査、作業項目との関連を設定します。
- PipelinesとIaC：YAML定義の再利用、変数と承認による環境差分の管理、Azure構成のコード化。
- 秘密情報：パスワードや接続文字列をコードに書かず、Key Vaultなど安全な接続を使います。
Boardsのストーリーやバグを、コミットやプルリクエスト、デプロイ結果につなぎます。そうすると、変更の理由や確認者、配布先を後から追跡できます。
開発、検証、本番の各環境の差は、変数や承認、チェックで扱います。その構成をコードにする手段として、BicepやTerraformなどのInfrastructure as Codeがあります。
IaCの対象は、App ServiceやContainer Registry、SQL Databaseなどです。Key VaultやMonitorも含まれます。
4. テスト：自動テストと受入条件の対応づけ
パイプラインが成功したかどうかに加えて、要件に対応する受入条件を定義します。必要なテストを組み合わせ、結果を作業項目に関連付けます。
- テスト種類：単体、結合、E2E、性能、脆弱性、手動の探索的テストを、必要な範囲で実施。
- テスト管理：Test Plans利用時は、ケース、スイート、実行結果、不具合をBoardsにリンクする。
- 移行確認：件数、金額、関連キー、文字コード、日時、添付の照合と、少なくとも1回のリハーサル。
- リリース判定：重大障害、受入条件、復旧、監視、運用手順の実行可否の確認。
テストデータは、本番の個人情報を匿名化したものにし、最小権限と利用期限を設定します。誰が取得し、どこに保存し、いつ削除するかも決めておきます。
移行リハーサルでは、失敗時のロールバックも実行します。テスト件数に加えて、再現性や欠陥の早期検知、修正後の再テストも確かめます。
5. 稼働：承認、切り替え、監視の実行
本番デプロイでは、承認者と実行時間、失敗時の戻し先をあらかじめ決めておきます。Pipelinesの環境ごとに承認者とチェックを設定し、緊急変更と通常変更の記録も残します。
本番運用の対象は、アプリに加えてパイプラインやエージェントです。サービス接続、権限、監視も含めて扱います。
- 切り替え計画：デプロイ、移行、DNS・接続先変更、バックアップ、ロールバック、問い合わせ先を時系列に並べる。
- 利用者周知：日時に加えて、停止時間、画面・権限の変更、障害時の連絡先を伝える。
- 判定記録：初回リリースでは、開発、業務、QA、運用、セキュリティの各担当が同じ記録を確認する。
Microsoft Learnの監査ログでは、権限変更やリソース削除のほか、ブランチポリシーの変更やログアクセスなども記録できます。ただし、2026年8月時点ではパブリックプレビューで、Entra ID接続組織が対象です（出典: Microsoft Learn「Azure DevOps監査ログ」、2026年8月確認）。
監査イベントは標準で90日後に削除されます。そのため、長期保存が必要な場合は、外部保存やストリーミングを設計しておきます。
6. 定着：ルールと改善サイクルの現場への展開
導入後に現場がExcelや個別チャットへ戻る原因は、ツールの操作よりも、ルールが決まっていないことにあります。決まっていないのは、作業項目の粒度や優先順位の決め方、レビュー責任、完了の定義などです。
最初の1〜2スプリントは、週次で運用レビューを行います。
- 運用レビュー：未更新の項目、長く停滞したプルリクエスト、失敗したパイプライン、未テストのリリースの確認。
- 共通ルール：役割、Boards必須項目、ブランチポリシー、命名、承認、障害対応、権限の見直し、教育資料、問い合わせ窓口の整備。
- 教育：開発者、QA、業務、運用の各担当が作業を登録する場所を演習し、クイックスタートを用意する。
- 改善評価：KPIが改善したかを、新機能の利用とは別に四半期ごとに見る。
2025年以降、Azure DevOps MCP ServerやCopilotによる開発支援が進んでいます。さらに、2026年にはリモートMCP ServerやTest Plans関連の資料も更新されています。
プレビュー機能に本番の削除や権限変更、承認を任せる場合は、まず読み取り専用から始めます。承認、監査、ロールバックの手段も、あらかじめ用意しておきます。
Azure DevOpsの費用相場とコストの内訳
費用は、ライセンスとクラウド利用料、導入支援、業務アプリ開発、保守運用の4つに分けて考えます。DevOpsの利用料と業務システムの開発費を分けておくと、提案を比べられます。
ライセンスの公式価格と、リサーチノートに基づく導入支援費の推定レンジは、分けて扱います。
ライセンスとAzure利用料（ユーザー数・実行量による違い）
MicrosoftのAzure DevOps Services公式価格では、Basicは最初の5ユーザーが無料です。6人目以降は1ユーザーあたり月額6ドルです。Basicには、Boards、Repos、Pipelines、Artifactsなどが含まれます。
手動テストやテスト管理を使うBasic＋Test Plansは、1ユーザーあたり月額52ドルです（出典: Microsoft Azure「Azure DevOps Servicesの価格」、2026年8月確認）。価格は米ドル基準で、契約、地域、為替などにより変わります。円換算は、見積時点の公式価格で確認します。
- Basicを20人：無料の5人を除く15人分で、計算上の目安は月額90ドルです。
- Basic＋Test Plansを5人：計算上の目安は月額260ドルになります。
上記はユーザーライセンスだけの金額です。Microsoft-hosted agentの追加並列ジョブやSelf-hosted agent、Artifacts容量の利用料は、別に発生します。
対象になるのは、App ServiceやContainer Registry、SQL Databaseなどです。Key VaultやMonitorも含め、これらAzure側リソースの料金は別途かかります。
導入支援費の目安（小規模は100万〜300万円）
導入支援費に標準の価格表はありません。次に示す金額は、人数やチーム、移行の範囲から整理した推定レンジです。CI/CD、権限、研修の範囲も考慮しています。
- 小規模：1チームでBoards、Repos、ブランチポリシー、単一CI/CD、簡易研修を行う場合で、100万〜300万円、1〜2か月が目安。
- 標準：権限、移行、YAML、テスト、承認、IaC、運用、研修を含む場合で、300万〜800万円、2〜4か月が目安。
- エンタープライズ：複数組織やネットワーク制限に対応する場合で、800万〜2,000万円以上、4〜9か月が目安。
標準導入では、複数チームの権限とリポジトリ移行を扱う点が、小規模との違いになります。エンタープライズ導入では、Self-hostedまたはManaged agentや、Jenkinsとの並行稼働を含むことがあります。監査やSIEM連携、内製化教育も対象になる場合があります。
小規模の想定は、既存リポジトリの移行とEntra ID連携の負荷が軽い場合です。導入支援費には、Azure上の業務アプリ本体の開発費は含まれません。
業務システムを新規開発する場合の一般的な規模別レンジは、小規模で300万〜1,000万円、中規模で1,000万〜5,000万円、大規模で5,000万〜1億円以上です。要件定義から運用までの見積もりは、導入支援費とは別枠で取得します。
保守・運用費の仮置き（初期費用の15〜25％）
保守・運用の見積もりは、対応範囲、料金の目安、契約形態の3つに分けて確認します。
- 対応範囲：権限の見直し、パイプライン対応、エージェント更新、脆弱性対応などを含む。
- 料金の目安：一般的な業務システムでは、初期開発費の年15〜25％を保守費として仮置きする考え方があります。
- 契約形態：月額・年額の固定保守と、障害・追加改修の従量費に分けて契約する。
実額は、利用者数や稼働時間、SLAによって上下します。サポート時間やAzureリソースの範囲でも変わります。Azureの料金監視や復旧訓練、Microsoftの仕様変更への追随も、運用に含めて考えます。
具体的には、平日日中の問い合わせや夜間の重大障害対応、月次の権限レビューがあります。四半期ごとのパイプライン改善やAzureコストレポートも含まれます。
Servicesは安く見えても、運用設計や内製化支援が抜けていると、現場の隠れコストが増える点に注意が必要です。
Azure DevOpsの見積もりを取る際のポイント
見積もりは、環境構築一式でまとめず、次の5つの工程に分けてもらいます。
- 調査と要件
- 設計
- 設定・開発
- 移行とテスト
- 教育、稼働支援、保守
安さだけで選ぶと、後から追加費用が生じることがあります。
要件整理の資料（対象範囲と終了条件）
RFPや相談資料には、組織・プロジェクト・チーム数と利用者数を記載します。加えて、開発言語やリポジトリ数、ブランチ数も書いておきます。
- 現行環境：課題管理、CI/CD、テストツール、移行対象の履歴、認証方式を書き出す。
- 制約と運用：ネットワーク、必要環境、リリース頻度、Services／Serverの希望を示す。
- 成果物：構成・権限・ブランチ・Boards設計、YAML、IaC、移行・テスト計画、手順、教育資料の定義。
ServicesかServerか決まっていない場合は、両案を依頼して、初期費用と3年程度の運用負担を比べます。PoCの完了条件は、作業項目から本番承認まで追跡でき、失敗時に戻せることです。
複数社比較での確認事項（対応範囲と担当者）
各社には、同じ前提条件と成果物の一覧を渡します。対応する領域を工程ごとに確かめると、提案の範囲を比べやすくなります。
- 技術範囲：Azure DevOps設定、Azure基盤、セキュリティ、業務アプリ、移行、テスト自動化の対応可否を見る。
- 運用支援：SRE、教育、保守の対応可否の確認。
- 担当体制：設計から運用を担う人の役割、稼働予定、再委託、障害時の連絡経路の確認。
- 契約条件：成果物の所有権、引き渡し、終了時のデータ返却・削除の取り決め。
DevOps支援会社と、Azure上の業務アプリを請け負う会社が同じとは限りません。必要な工程ごとに、実績を質問します。
成果物の所有権と引き渡し条件は、契約書に記載しておきます。対象には、ソースコードやIaC、設計書のほか、パイプラインやテスト結果も含まれます。
追加費用になりやすいリスクの洗い出し
移行量やネットワーク条件は、後から分かると作業範囲が変わります。そのため、追加費用の原因になりそうな点を、早めに洗い出しておきます。
- 移行元：履歴や添付ファイルの量の確認。
- 接続と権限：Self-hosted agentの要件や既存権限の複雑さを調べる。
- テスト準備：本番データ利用の要否と匿名化方法の確認。
- 事前検証：移行サンプルでの接続や権限、デプロイのリハーサル。
見積書では、「含む」「含まない」「前提」「追加単価」「変更管理」の記載を確かめます。Azure利用料やライセンス、拡張、移行元契約のほか、Microsoft問い合わせ費も対象になります。
24時間監視や脆弱性対応、教育の追加開催が、除外されていないかも確かめます。必要な運用を含めた総額と、社内の作業量で判断します。
よくある質問（FAQ）
導入範囲、既存ツールからの移行、内製化について、よくある質問に答えます。
Azure DevOps ServicesとServerはどちらを選べばよいですか？
インフラ負担を減らし、AzureやEntra IDと早く連携したいなら、Servicesが候補です。
データ配置やネットワーク分離を細かく統制したい場合で、サーバーやDBを運用できる体制があれば、Serverを検討します。
最終判断では、データ分類や社内規程に加えて、復旧目標と3年程度の運用費を並べて比べます。
GitHubやJenkinsからAzure DevOpsへ移行できますか？
移行はできますが、コード以外の履歴や設定は個別に確認します。すべてを同じ形で移せるとは限りません。
- 対象の分類：Issue、プルリクエスト、コミット、パッケージ、パイプライン、権限、テストケースの確認。
- 移行方法：「必ず移す」「参照用に保管」「移さない」への振り分け。
- 検証：サンプルで件数、関連付け、権限、実行結果を確かめる。
既存のJenkinsやGitHub Actionsは残したまま、段階的に移行する方法もあります。
Azure DevOpsの導入は社内だけでできますか？
小規模チームで既存ツールが少なく、標準機能から始める場合は社内導入も可能です。複数の専門領域を同時に整えるには、知識と時間が必要です。
まず、権限や移行、IaCを社内で担えるかを確かめます。テスト自動化や本番承認、監査、運用教育についても、社内で担えるかを検討しておきます。1チームのMVPを作り、不足する領域だけ外部支援に依頼すると、内製と委託のバランスを取りやすくなります。
Azure DevOpsの導入費用を抑えるにはどうすればよいですか？
全社展開や独自拡張は後回しにし、対象チームと成功指標を絞ったMVPから始めます。Basicの無料枠を活用するほか、Test Plansは必要な担当者だけに付けます。既存ツールとは段階的に併用し、標準YAMLとIaCも使います。
テストや権限、バックアップ、運用教育を削ると、障害や追加改修の費用が増えることがあります。一方で、削る対象は、まず機能の作り込みから検討します。
まとめ
Azure DevOps開発は、要件からコード、テスト、リリース、運用改善まで追跡できる仕組みをつくる取り組みです。6フェーズそれぞれの終了条件と担当者を明確にしておくと、導入の成否を判断しやすくなります。
導入前に確認する5つのポイント
この5点は、導入前にまとめて確かめます。
- 費用と体制：DevOps導入と業務アプリ開発の切り分け。
- サービス選定：Services／Serverの比較（データ配置と運用負担で）。
- 追跡性：Boards、Repos、Pipelines、テスト結果の関連付け。
- 安全性：権限、秘密情報、テストデータ、監査、ロールバックの設計。
- 定着：研修とKPIを含む見積もりの取得。
最初の1チームのMVPと現状調査
全社展開の前に、代表的な1チームで作業登録から振り返りまでを一周します。途中では、プルリクエストやCI、テスト、承認付きデプロイ、監視を通します。
見つかった権限や移行、ネットワーク、教育の課題は、見積もりに反映します。成果物と運用ルールを標準にしてから、対象を広げます。
▼全体ガイドの記事
・Azure DevOpsのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。