--- type: guideline title: 政府情報システムにおけるアジャイル開発 source: デジタル庁 ds_code: ds-121 category: government-system updated: 2021-03-30 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/52bfa543/20220422_resources_standard_guidelines_guidebook_02.zip --- # 政府情報システムにおけるアジャイル開発 ## アジャイル開発とは アジャイルとは、元来は特定の開発プロセスを指すものではなく、より良い開発のあり方を追求する態度のことを指しています。実際には、アジャイル開発の１つとされる「スクラム」が国内外を問わず、適用されていることが多いです。本ガイドブックも、スクラムを基本として説明します。 アジャイル開発を方法として端的に表すと、インクリメンタルかつイテレーティブな開発であると表現できます。インクリメンタルとは漸次的に（少しずつ）作り進める様を指し、イテレーティブとは反復的に開発行為を繰り返すことを言います。つまり、少しずつ反復的に作り進める開発です。 こうした開発スタイルによって、作成したアウトプットに基づき、情報システムの挙動がどうあるべきかを検討、判断し、その次に取り掛かる開発の行為を最適化します。なお、反復する期間は、１か月以下（１、２週間、または４週間）を基準として検討することが多く、それ以上の期間にするとウォーターフォール型の開発に近くなり、アジャイルの利点も薄れて行くこととなります。 スクラムでは、短期間のスプリントの中でスプリントプランニングやスプリントレビューといったイベントのタイミングを予め決めて明確にし、それを反復継続していく考え方を大切にします。いつ何を行うのか、それぞれにかける時間はどれくらいかをあらかじめ決定し、関係者がそれを守るスタイルです。これによって、時間調整等にかかるコストを削減するとともに、日常の作業にリズム感が生み出され、円滑に進められるようになります。 また、前述したとおり、アジャイル開発は従来の開発スタイルとは異なり、すべての要求、仕様を言語化し、事前のドキュメントとして整備することなく開発を行うこともできます。ドキュメントで定義しなくとも、短期間のスプリントで得られるアウトプット（インクリメント）が、動くシステムそのものとなり得るためです。ドキュメントの作成にかける手間を最小限にとどめ、情報システムそのもので動作確認を行うことで、要求の確認から設計、開発、テストまで、情報システムの機能追加を短い期間で行うことができます。 開発にあたって不足する情報については、関係者間での対話コミュニケーションで補います。そのため、アジャイル開発においてはより円滑なコミュニケーション、それを実現できる関係性を重視します。 なお、アジャイル開発の歴史的な成り立ちと、アジャイル開発で確認されている価値と原則については第５章「参考情報一覧」を参照してください。 コラム：「混ぜるな危険」

従来の開発スタイル（ウォーターフォール型）に慣れ親しんだ人が、アジャイル開発では逆に足を引っ張ってしまうことがあります。

例えば、開発工程での進捗を確認する方法について、従来の開発スタイルであればWBSに基づいてクリティカルパスを把握し、週次の報告会でイナズマ線やEVM※に基づいた実績を確認し、そのために様々な資料を事業者が作成することになります。一方で、アジャイル開発ではスプリントのプランニング、開発、レビューというサイクルの中で「動くシステム」を確認しながらプロダクトオーナーを含めた関係者が進捗状況を共有することが中心であり、中間成果物としての報告書等に重きを置きません。

このようなカルチャーの違いを理解せずに、アジャイル開発であるのに進捗を心配して報告書提出等の監視を強めようとすると、アジャイル開発の流れを阻害してしまうことにもつながりかねません。従来型の開発スタイルにもアジャイル開発にもそれぞれメリットとデメリットがありますが、両者の異なる文化を無意識に「混ぜて」しまうことには注意を払いたいところです。

  • EVM：Earned Value Managementの略。WBSにより詳細化した各作業項目に出来高計画値（PV：Planned Value）を設定し、プロジェクトの進捗を出来高実績値(EV：Earned Value)として定量化して管理すること。詳細は標準ガイドライン実践ガイドブック第３編第７章Step.３-２-Ｆ「EVMを用いた進捗管理手法を理解する」を参照のこと。
## アジャイル開発の本質 ### アジャイル開発の９つの意義 アジャイル開発は、具体的にどのような意義を持つのでしょうか。ここでは以下の９つを挙げます。 #### フィードバックに基づく開発で、目的に適したシステムに近づけていく 漸次的な開発を反復的に行う意図は、早く形作ることでいち早く利用者(もしくはその代弁者たるプロダクトオーナー)からフィードバックを得ることです。 ここでいうフィードバックとは、実際に情報システムを使って得た操作感、理解を情報システムの目的、利用用途に照らし合わせた際の差分です。情報システムの目的を果たすために必要な機能性、利用用途に適した操作性を発見することを狙います。 コラム：モニタリング改善におけるアジャイル開発の有用性

ある省庁では、給付を行う情報システムの構築にアジャイル開発を採用しました。リリース時点では、すべての機能を作り込むのではなく、直近で必要ない一部の機能はリリース後に追加するロードマップとする一方で、システム構成は将来的な改修を想定したつくりとして、実際の改修は容易に行えるようにしました。

また、この情報システムでは、給付によって得られるアウトプットやアウトカム、給付事務の効率化、受給者の利便性向上等をモニタリング指標としています。これらを適切にモニタリングしていくためには、データを様々な観点から收集・分析することが必要であるため、アーキテクチャをマイクロサービス化し、さまざまな断面でデータを取得できる仕組みを構築しました。

別の省庁の情報システムでは、職員自身がBIツールを使いこなしてデータ分析を行えるようになっており、データの抽出などを運用事業者に依頼する必要がありません。この手法によって、社会環境の変化を捉えたデータを、法律改正の根拠などに活用できるようになっています。

従来の情報システムでは、運用事業者に依頼しなければデータ抽出も困難でしたが、近年はアジャイル開発やBIツールなどの技術を活用することで、実際のデータを見ながら試行錯誤を経て分析方法を検討できるようになりました。このような新しい技術を駆使して、社会環境の変化を迅速に捉えつつ、証拠に基づく政策立案（ＥＢＰＭ）を推進していくことが重要です。
#### 形にすることで、関係者の認識を早期に揃えられる 情報システムを形作り、早期に確認、試すことで、作るべきものへの関係者の認識を引き出すことができます。ドキュメントや会話によるコミュニケーションで理解できることも多分にありますが、実際に使ってみることで得られる認識もあります。関係者それぞれの認識を表出させることで、その間でのズレを解消する機会を生み出すことができます。 #### システム、プロセス、チームに関する問題に早く気付ける 最短１週間から、長くとも１か月以下という短期間でシステムをアウトプットしていくことによって、作るべきものに対する認識相違や誤謬、開発上の準備不足、開発フローの不備、開発チーム内でのコミュニケーション齟齬や不足等に気付くことを早めることができます。 #### チームの学習効果が高い アジャイル開発では、フェーズという概念を置いてフェーズごとにチームを切り替えるということを行いません。単一のチームで、何を作るべきかを探索し、開発し、試行し、さらに調整するということを繰り返し続けていきます。そのため、フェーズ間での知識の受け渡しという行為が発生せず、すべての行為の経験とナレッジとがチームに蓄積されていくことになります。 また、技術領域によっても担当者を分けず、例えば、１人のエンジニアがインフラ（サーバー、ネットワーク、ミドルウェア等を含むシステム基盤）構築からアプリケーション開発、運用まで幅広く担当したりサポートしたりする体制を組むこともしばしばあります。この点では、インフラ構築を専任のインフラ・エンジニアでなくアプリケーション・エンジニアが行うことも多いクラウドとの相性が良いと言えます。こうしたフォーメーションが組めるようになると、チーム内での役割を特定の個人に固定する必要がなくなり、開発が効率よく進むようになります。 #### 早く開発を始められる すべての要求を仕様化するまで開発を始められない従来の開発と比較すると、アジャイル開発は１か月以下の開発期間（この期間のことを特にスクラムではスプリントと呼びます）ごとに何を作るか選択しながら進めるため、少なくとも最初の数スプリント分の要求が仕様化されていれば開発を始めることができます。 #### システムの機能同士の結合リスクを早期に解消できる 機能一つ一つを単独で作り、結合テストフェーズで機能間の整合性を検証する方法だと、機能間の認識齟齬について検知できるのがかなり後になってしまうリスクがあります。アジャイル開発では、基本的にスプリントごとに開発した機能を結合し、テスト環境や本番環境に展開し、動く状態にします。つまり、結合時の問題について早期に検知できる可能性が高くなります。 #### 利用開始までの期間を短くできる すべてのフェーズが終了しきらないと利用が開始できない開発スタイルに比べると、アジャイル開発の場合は、すべての機能を開発しなくても利用が試せる利点があります。一部の要件しか満たさない情報システムであっても当該システムの利用が緊急に必要な場合や、一部機能であっても利用開始に十分と判断される場合には、その時点で当該システムを利用開始することができます。すべての機能を備えるために長期間開発を続けてからリリースする場合と比べ、開発期間中に社会情勢や環境の変化によって要件が変わったり、情報システムがリリース前に陳腐化してしまったりといったリスクを避けることができます。 なお、実際に本番運用を始めるレベルとしての利用開始なのか、あくまで試行レベルでの利用開始かによっても、そのために必要な準備作業が異なってきます。プロジェクトごとに利用開始の位置づけやスケジュールを決める必要があります。 #### 開発のリズムが整えられる スプリントの中では、開発に必要な行為やイベントをひと揃いで行います。あるスプリントではプランニングを行うが、あるスプリントではプランニングを行わない、ということはありません。 そのため、スプリントを繰り返していくと進め方に安定性が生まれます。このような開発のリズムが定着することで、開発の効率も高めることができます。 #### 協働を育み、チームの機能性を高める スプリントごとに成果を出すために、進め方やコミュニケーションのあり方についてより良くしていく機運を高めやすいという利点があります。協働によって成果が上がるというサイクルを作ることで、よりチームの機能性を高めていくことが期待できます。 ### ９つの意義を十分に発揮するための前提 以上の９つの意義を十分に発揮するためには、以下の前提をチーム及び関係者間で確認する必要があります。 #### 常にカイゼンを指向すること アジャイル開発とは、スプリント単位での開発に必要な「準備」、「実施」及び「適応」の繰り返しです。適応とは、実施した結果から情報システムやプロセス自体をより良くする働きかけであり、具体的には「ふりかえり（スプリント・レトロスペクティブ）」を定期的に行うことです。こうした適応行為がなければ、ただ定められたタスクを繰り返し実施するだけになってしまいます。 #### 対話コミュニケーションの重視 短い期間でアウトプットを行う開発では、ドキュメントに過度に依存したコミュニケーションではなく、対話による共通認識作りが重要となります。そのため、対話がしやすいチーム体制（過度な階層構造を避ける）の構築及び定期的なコミュニケーションの場の設定と、その遵守がチーム全員に求められることになります。 ただし、それは必ずしも同じ会議室に一同に会するということではありません。コミュニケーションツールを用いて、オンラインで打ち合わせや短時間のコミュニケーションを行う方法も、積極的に検討・導入し、コミュニケーションしやすい環境を作ります。 また、ドキュメントの共同作成・利用も重要です。オンラインでドキュメントを共有して同時編集することができるサービスを用いると、オンラインの打ち合わせの最中にもリアルタイムで同じドキュメントを参照し、その場で決定・変更した内容を反映して共通認識とすることができます。打ち合わせ後に議事録と変更後のドキュメントをメールで送るといった旧来の方式と比べて円滑に作業を進められることが期待できます。 #### 情報システムの変更容易性を確保し続ける スプリントを繰り返す中で、開発した機能がより良い内容となるよう変更を加えていくことになります。そのため、プロセスだけではなく、そもそも変更が可能なシステム設計が前提となります。どのようにして変更容易性を確保するのか、設計上の不断の注意が必要です。 変更容易性を確保するには、構成を柔軟に変更できるクラウドやコンテナ技術、CI/CDやDevOpsの考え方が有効です。システム間をREST APIによって疎結合とする方式や、データ構成を柔軟に変更できる非構造型のDB（No SQL）の活用、クラウドデザインパターンと呼ばれるシステム構成を利用することも選択肢の一つです。なお、変更を容易にするためのマイクロサービスアーキテクチャは、その利点とともにデメリットや副作用もありますので、導入する場合にはレベル感（サービスを分割するだけなのか、サービスメッシュまで導入するのか等）を含めて慎重な見極めが必要です。 #### 利用者目線で開発を進める フィードバックを反映できる開発手法を採用し、それができるチームを作り上げたとしても、利用者目線の適切なフィードバックができなければ意味がありません。 このような利用者目線を踏まえたシステム開発を行うための心構えと視点として「サービス設計１２箇条」があり、特にアジャイル開発と親和性が高い以下の７箇条を念頭において進めることが重要です。実践ガイドブック「第３編第４章　サービス・業務企画」で詳しく説明しているのでこちらも参照してください。 - 第１条　利用者のニーズから出発する - 第４条　全ての関係者に気を配る - 第７条　利用者の日常体験に溶け込む - 第９条　オープンにサービスを作る - 第１０条　何度も繰り返す - 第１１条　一遍にやらず、一貫してやる - 第１２条　システムではなくサービスを作る コラム：サービス設計１２箇条を意識したWebサイトの構築

あるWebサイトでは、開発手法としてアジャイル開発を採用しました。加えて、利用者目線で構築を行わなければ利用されなくなるという危機感の下に、利用者目線に沿ったユーザインタフェースの実現、継続して使われるサイトの実現を目指して、当初からサービス設計１２箇条、特に以下の３箇条を意識して検討を進めました。

  • 第４条　全ての関係者に気を配る

アドバイザーには、他府省の関係者、民間の事業者や団体を加え、議事の結果をインターネットで公開するなど、検討過程をオープンにしています。

  • 第８条　自分で作りすぎない

情報を活用するアプリケーションは、アドバイザーとして集まった民間事業者が任意に構築することとし、当該Webサイトではデータを利用しやすい形で提供するにとどめることとしました。

  • 第１０条　何度も繰り返す

リリース後の運営方針でも、将来的なあるべき姿に向かってサービス設計１２箇条を意識して改善を続けることを明示しています。

  • 本ガイドブックにおけるアドバイザーは、一般的なアジャイル開発における「ステークホルダー」に相当する役割を想定しています。
## アジャイル開発の適用方針 ### アジャイル開発に向いている・不向きな領域 アジャイル開発には、前述のような意義がありますが、どのような場合でもアジャイル開発を採用すれば良いというものではありません。アジャイル開発が向いている領域や不向きな領域について以下に示します。 #### 向いている領域 開発対象についてある程度の方向性はあるものの、全容が明らかになっておらず、開発を進めながら詳細化していく必要があるケース。あらかじめ詳細を決めることができない、あるいは決めにくい領域（例えば、利用者の体験デザインから検討が必要な情報システム）。 #### 不向きな領域 あらかじめ対象範囲や実現するべき詳細が定められており、明らかになっているケース。業務内容が明らかになっており、作って確認するという余地が少ない領域。 ただし、業務内容が明らかになっている領域であっても、具体的なUI（ユーザインタフェース）の部分は、利用者からのフィードバックを得ながら構築するアジャイル開発が向いている場合があります。 #### 慎重な判断が必要な領域 大規模な情報システム、業務内容等が極めて複雑、あるいはミッションクリティカルな(業務、サービス提供上ほぼ一切の障害や誤作動が許されない)ケース。 このような場合は、どこまでをあらかじめ詳細化するか、どの部分をアジャイルに開発するか、また、どのように品質を確保し、継続的に高めていくかといった判断が必要となります。 ### 開発方針の検討 アジャイル開発の向き・不向きを踏まえ、どのような開発方針を採用するか検討しましょう。開発方針の決定は、プロジェクト全体に大きな影響を及ぼすため、調達仕様書を作成する際に、有識者と十分な協議を行い判断することを推奨します。 また、調達段階で決定した方針を一方的に押し通したところで事業者が対応できなければ意味がありません。もちろん、開発方針に対応可能と考えられる事業者を選定することが前提となりますが、実際にプロジェクトを進める事業者とも十分なすり合わせを行いましょう。 以下では、どのような開発方針があるのか、２つの軸をもとに分類します。 #### プロジェクトの初期計画の緻密さ プロジェクトの初期で緻密に計画を立て、大きな変更は認めず、計画どおりに開発を進めていくケースや、まずは全体計画を大まかに決めておき、詳細化は次に開発に取り掛かる範囲だけを対象とするケースがあります。 #### 開発の反復頻度 反復を行わずに要件定義、基本設計などのフェーズを順に進めていくケースや、これまでに完了した作業を踏まえて次にとりかかる開発範囲の計画を立て、開発し、振り返るという一覧の手順を反復して開発するケースがあります。
![](../assets/ds-121-ch01-image2.png)

　図 ２ ２軸による開発方針の分類

## 調達時に留意すべきこと アジャイル開発の調達を行うにあたって、以下の点に留意しましょう。 ### 経験者の参画 開発の大部分を担う事業者の選定にあたっては、事業者側からアジャイル開発の経験者がプロジェクトに参画することを前提とします。参画者がどのようなシステム開発（領域、規模）において、どのような役割を果たしたのか確認し、参画者の経験と調達対象の領域や規模とがかけ離れている場合は、その差分を解消する工夫が必要となります。アジャイル開発に関する有資格者は一定の知識があるとは判断できますが、それだけでアジャイル開発を実践できるかまでは判断できません。 また、参画者が当該プロジェクトでどのような役割を果たすのか事業者と認識を合わせましょう。責任者やマネージャーとして参画するだけでは十分に機能しない可能性があるため、現場活動への関与者として経験者が存在することを確認しましょう。特に、開発チームの中で重要な役割を果たすスクラムマスターとなる予定の方の見識、経験は重要です。 なお、事業者からさらに外部委託が検討されている場合は、その委託先のアジャイル開発経験を確認する必要があります。事業者や府省職員の経験が不足している場合は、別途外部支援者の確保を検討しましょう。 ### 発注者の姿勢 アジャイル開発を採用する場合、調達仕様書に「開発手法はアジャイル開発を採用すること」と記載すれば、あとは事業者がうまく進めてくれると考えてはいけません。発注者（プロダクトオーナー）は、仕様を決定するためにアドバイザーやエンドユーザーを含む関係者に日々確認や調整を行ったり、事業者と検討や議論を行うための日次ないし週数回以上の打ち合わせの時間を確保したりする必要があります。 これらの十分な時間と、より良いプロダクトのための不断の努力ができる環境を準備できない場合、アジャイル開発でのプロジェクトは成功確率が大きく下がります。 ### 開発範囲にMVP（Minimum Viable Product）の範囲を用意する MVPとは、実用的で最小限の範囲で動くプロダクトを意味します。具体的には、予定されている開発範囲に含まれる、プロジェクトの課題を解決するために重要でかつ極力範囲を絞った領域を指します。つまり「その時点で必須もしくは解決すべき優先度の高い開発範囲 (MVP)」と「開発対象としたいが実現範囲と内容は調整可能」という少なくとも２つの領域を設けて、調達仕様書に示しましょう。 MVPに関連して「YAGNI」と呼ばれる考え方があります。これは「You Ain’t Gonna Need It」もしくは「You Aren’t Going to Need It」（あなたはそれを必要とはしない）の略で、XP（eXtreme Programming）が提唱するアプローチの1つです。XPは、ペアプログラミングやテスト駆動開発、ソースコードを個人ではなくチームで共同して責任を持つことなど、現在のアジャイル開発の基本となる考え方を説いた手法の1つです。多くのソフトウェアで、開発した機能の半分以上がほとんど使われないという統計的データをもとに、今本当に必要なものだけを作ろう、という考え方です。使われない機能であっても、開発すればテストや保守、マニュアル作成等のコストもかかりますし、ソフトウェアの複雑度も増加します。 MVPについては確実に実現するようにプロジェクトを進め、そのほかの領域については開発を進めながら実現範囲と内容を決めていく、という方針を置くことで、アジャイル開発を適用したために実現するべき開発範囲が揃わなかったという事態を防ぐようにしましょう。ある情報システムでは、初期に優先度がそれほど高くない機能に工数を使い、後々優先度の高い機能の実現に支障が生じてしまいました。MVPで重要な機能を明らかにしていても、常に残りのスプリント数を注視し、管理しなければ、本当に重要な開発範囲を実現できなくなるおそれがあります。 ### 契約方式を検討する アジャイル開発では、実現する機能の優先度を決め、プロジェクトの状況によっては、一部の機能の実現を見送ったり、要件を変更したりします。このような場合には、あらかじめ内容が特定された成果物を予定どおりに完成させることに対価を払う請負契約よりも、業務を受託した事業者が専門家としての注意義務を果たしながら業務を遂行することに対価を支払う準委任契約の方が馴染みやすいという考え方もあります。プロジェクトの開発方針を踏まえて、適切な契約方式を検討する必要があります。この点については、実践ガイドブック「第3編第6章Step.2-1-E.参考：アジャイル開発を行う場合の契約方式」も参照して検討を進めてください。