アジャイル開発の運営

運営の概要

アジャイル開発の実際の運営に際して、以下の内容を把握しておきましょう。

• 役割

• 実施ミーティング（スクラムイベント）

• 作成物

なお、本ガイドブックでの説明は最小限の内容に留めています。実践にあたってはより広く、深い知識が問われるため、第５章「参考情報一覧」において提示する文献等を参考に知識拡充に努めましょう。

役割

アジャイル開発（スクラム）における体制には４つの役割があります。

プロダクトオーナー

開発する情報システムの価値を最大化することに責任を負います。具体的には、開発する機能の仕様策定に関する議論を主導する役割を担い、「プロジェクトとして何を作るべきか」という判断に最も影響を与えます。また、開発する機能の順序についても、「何から形にしていくべきか」という判断を下す際の中心的な役割を果たします。

政府情報システム開発においては、原則としてPJMOのうち課長級の職員がプロダクトオーナーを務めることが一般的ではありますが、プロジェクトとしての判断を適切に実施できる職員であれば、責任者から当該職員に必要な権限を委譲した上で、当該職員をプロダクトオーナーとすることもできます。

なお、意思決定が混乱しないように、１つのプロジェクトに設置するプロダクトオーナーは原則として１名です。他の職員は、当該プロダクトオーナーが行う意思決定の支援にあたります。

コラム：プロダクトオーナーが果たす役割

プロダクトオーナー支援

アジャイル開発におけるプロダクトオーナーの振る舞い並びにシステム開発及びプロジェクト運営に対する職員の知見を補完する役割を担います。特に、プロダクトオーナーが行う意思決定に適宜助言を行い、またプロダクトオーナーの意図を開発チームに適切に伝えるなどの補完的な役割を期待します。

プロダクトオーナー支援は、支援事業者又は政府CIO補佐官が担います。

開発チーム

情報システムを構築する役割を担い、情報システム構築にあたって必要となる様々な専門性をチームメンバー間で分担します。専門性に基づく分担は各プロジェクトで定義します。

政府情報システム開発においては、事業者がその役割にあたります。本来は発注者も開発チームとして携わる可能性がありますが、政府の情報システム開発においては事例が少ないことを考慮し、本ガイドブックでは事業者の役割としています。

開発チームとして十分にアジャイル開発の練度があり、各メンバーが自律的である場合を除いて、開発チームを取りまとめる役割（リーダー）の設置を検討しましょう。なお、１つの開発チームにおけるチームメンバーは７、８名を上限とし、それ以上となる場合は開発チームの分割を検討しましょう。

スクラムマスター

チーム（プロダクトオーナーを含めた全体を指す）が機能するようにコーチングする役割を担います。具体的には、アジャイル開発が前提としている価値観、考え方、また実践にあたって必要な振る舞い、方法について適宜レクチャーや寄り添った支援を行います。

また、スクラムマスターの重要な役割の一つに「プロジェクト進行の阻害要因の除去」があります。阻害要因とは、例えば、要件や仕様が決まっていないこと、開発環境の不備、仕様に対する不必要な開発チーム外部からの干渉といったものがあります。これらの阻害要因に対し、時には（ウォーターフォールでの）PM（プロジェクトマネージャー）のように、時にはアーキテクトのように振る舞い、臨機応変に阻害要因を取り除きます。ただし、外部からの干渉をただ排除してはより良いプロダクトにならないため、要不要や重要性を適切に見極めて協働の精神で対応します。

なお、事業者には、スクラムマスターは従来のPMと誤解されることが多い役割です。PMは事業者側の「プロジェクトの責任者」であり、「指揮者・指示者」として上位者の立ち位置から様々なアクションを取ります。それに対して、スクラムマスターは、システムや開発の専門家によって自律的に運営される開発チームに対して対等であるとのスタンスを取り、指示はしませんから、PMとは全く異なります。PMと同じ認識でスクラムマスターを担当するとプロジェクトの進行に混乱を来すので、注意が必要です。

政府情報システム開発においては、設計・開発事業者、支援事業者（工程管理事業者）、政府CIO補佐官、PJMO職員等のいずれかがスクラムマスターとしての役割を担います。１つのプロジェクトに設置するスクラムマスターは１名です。

なお、プロダクトオーナーとスクラムマスターを同じ人が兼任することは避けてください。

アドバイザー

上記４つの役割に該当しない関係者をまとめて指します。システム開発における意思決定には関与せず、あくまでチームに対する助言、フィードバック等を行います。チームが有しない専門性や知見の提供に努め、決してシステム開発の進行を妨げるようなことがあってはいけません。

政府情報システム開発においては、プロジェクト外の府省職員、政府CIO補佐官などがあたります。

• 本ガイドブックにおけるアドバイザーは、一般的なアジャイル開発における「ステークホルダー」に相当する役割を想定しています。一方で、標準ガイドラインでは、直接的又は間接的に影響を受ける外部関係者や内部関係者のことを「ステークホルダー」と定義しているため、便宜上、異なる用語を用いています。

実施ミーティング（スクラムイベント）

実施ミーティングは以下の５つを基本とします。これら以外の会議体はプロジェクトごとに検討し、定義します。

リリースプランニング

リリースプランニングでは、プロジェクト全体の計画作りを行います（本ミーティングはスクラムの規定にはありません）。具体的には、プロジェクトの開発範囲の規模から、スプリントがいくつ必要かを見立てます。この見立ては、開発の進行具合やフィードバックを取り込む分量によって変わっていくため、プロジェクト開始後も継続的に実施する必要があります。プロジェクト予算からスプリントの数が足りなくなることが予測された場合は、ただちにその対策を練ります。

まず、プロジェクトを始める最初の段階で実施します。その後は、数スプリントに１回の頻度か、１か月に１回は実施します。

スプリントプランニング

スプリントプランニングでは、これから始めるスプリントの計画を作るために、２つの活動を行います。１つは、プロダクトバックログの中で当該スプリントではどれを開発対象とするか（＝スプリントバックログ）を決定することです。開発対象の決定にあたっては、当該スプリントで何を実現するべきなのかというゴールについて、プロダクトオーナーを含めたチーム全体で確認し、そのゴールを実現するのに必要な開発対象を選定します。

もう１つは、開発対象となった機能をどのようにして完成させるかについての議論です。開発に必要な作業などを挙げて、やるべきことの不明点を明らかにしたり、必要に応じて詳細化したりします。

スプリントプランニングは、スプリントの最初に行い、１つのスプリントにつき１回実施します。所要時間は、１か月スプリントの場合であれば最大８時間を目安とします。実際の運用にあたっては、２週間スプリントであれば４時間、１週間スプリントであれば２時間など、各プロジェクトの実情を踏まえて調整しましょう。

デイリースクラム

デイリースクラムは、スプリントのゴールが達成できそうかを日々確認するために行います。基本的には、開発チームの状況を共通理解とするべく以下の３点を確認します。いずれもスプリントのゴールを達成できるのかを判断するための情報提供にあたります。

• 昨日実施したこと

• 本日実施すること

• 直面している問題、懸念点

毎日決められた時間に実施し、１回の所要時間の目安は１５分程度です。議論が発生し、それ以上の時間となる場合は、デイリースクラム後に別途ミーティングを持って必要な参加者を集めるようにします。

通常は開発チームのみで実施するものですが、この拡張版として、プロダクトオーナーなどを交えて仕様を確認・決定する協働の場としてのミーティングを、日次や隔日で定例化したものも開発効率化の観点で有効な場合があります。そこで決定されたものが「受け入れ条件（アクセプタンス・クライテリア）」となり、開発チームに開発作業の指針やゴールとして示すことができます。

スプリントレビュー

スプリントレビューは、スプリントの成果を確認し、今後（特に次のスプリントで）何を行うべきかを決定するために行います。チーム、アドバイザーが参集して、スプリントの成果を確認し、ゴールがどの程度達成できたかを判断します。また、確認したスプリントの成果を基に、今後何を実施するべきか議論を行います。このレビューで寄せられる情報システムへのフィードバックは一旦チームで受け止めた後、次のプランニングで適用可否や実施順序を検討します。

スプリントの終わりに実施し、１つのスプリントにつき１回実施します。所要時間は、１か月スプリントの場合で最大４時間です。

スプリント・レトロスペクティブ（ふりかえり）

スプリント・レトロスペクティブは、スプリントの活動を省みてプロダクトオーナーを含めたチーム全体としてのカイゼンを計画するために行います。次のスプリントの活動が効率的、効果的となるよう、継続すべき工夫、取り除くべき問題、そのための施策などを検討します。

スプリント・レトロスペクティブは、スプリントレビューの次に行うため、スプリントの最終ミーティングにあたります。所要時間は、１か月スプリントの場合で最大３時間です。

作成物

スプリントでは３つの作成物があります。

プロダクトバックログ

プロダクトバックログとは、システム開発に必要となる要求のリストです。リストの並び順で取り組むべき順序を表現します。プロダクトバックログの一つ一つについて、それ1つで完結する機能を目安として記述しますが、どの粒度でどこまでの記述を行うかはプロジェクト内で決めます。少なくとも開発チームが規模を見積もれる程度の情報が必要です。

リリースプランニングでは、その時点でのプロダクトバックログを俯瞰し、必要なスプリント数を概算するために使います。スプリントプランニングでは、当該スプリントで開発対象とする範囲を決めるために使います。

スプリントの途中や、スプリントレビューで必要と考えられたシステム要求については適宜プロダクトバックログへの追加を行います。プロダクトバックログの順序については、スプリントプランニングやスプリントレビューで確認し、適宜並び替えを行います。

なお、同様にプロジェクトで取り組むべきものを列挙したリストとして作業又は成果物を階層的に要素分解したWBSがありますが、これは下位レベルの要素を足し合わせると上位レベルと一致する「100%ルール」に従って作成されるため、トップダウン的なアプローチとなります。一方、プロダクトバックログは個々の「やるべきことリスト」であり、発生の都度バックログは追加されるため、目下の関心事を中心としたボトムアップ的なアプローチとなります。

スプリントバックログ

スプリントバックログとは、当該スプリントで開発対象となった要求のリストであり、その要求を実現するために必要な作業を含んでいます。スプリントバックログは開発チームによる、開発チームのための計画です。デイリースクラムで状況を把握できる程度に詳細にしておきます。

スプリントプランニングでは、当該スプリントで開発対象とする範囲として特定されます。デイリースクラムでは、何が終わっていて、これからどれを始めるのかなどの確認の対象となります。

開発成果物（情報システムの機能）

開発成果物（スクラムではインクリメントと呼ぶ）は、機能する情報システムそのものであり、スプリントによって完成された機能性が追加されていきます。開発成果物はスプリントごとに常に検査され、完成された状態を保つ必要があります。なお、「完成」の定義はプロジェクトごとに決定します。何をもって完成したと言えるのかは、開発チームで共通の理解とします。

スプリントレビューで、スプリントの成果として具体的な確認の対象となります。

運営の体制

政府情報システム開発において、アジャイル開発の運営は３．１の「1）役割」で示す役割を担うPJMO職員、設計・開発事業者、支援事業者、政府CIO補佐官などによって行われます。必要に応じて、体制を補完する役割として、「プロダクトオーナー支援」の設置を検討します。

ここまで説明してきたとおり、アジャイル開発の運営は各者の協働を前提とし、全体で１つのチームとして運営にあたります。

運営の準備

アジャイル開発の運営を始めるにあたり、以下の点を準備として取り組みましょう。

アジャイル開発に関する知識の獲得

本ガイドブックを手がかりにアジャイル開発に関する知識の獲得を進めましょう。また、各府省のPMO、政府CIO補佐官、情報通信技術（IT）総合戦略室等にアジャイル開発の勉強会やレクチャー会の開催を相談することも選択肢の一つです。

上記の場を利用し、運営に関する疑問の解消及びプロジェクトの実際の状況や課題を想定したシミュレーションを行うことも良いと考えられます。これまで実施を終了しているプロジェクトを題材に、アジャイル開発として運営した場合の利点や課題について関係者内で意見交換を行いましょう。

事業者との協働

アジャイル開発を成功させるためには、プロダクトオーナーである発注者と、開発チームである事業者との協働が極めて重要です。発注者（プロダクトオーナー）は、システムの専門家・有識者である事業者と共に考え、議論し、事業者との共通認識として仕様を固める作業に多くの時間を費やします。情報システムが提供するサービスはどうあるべきかという、情報システムがその仕様によって実現する根幹部分だけでなく、場合によってはUX（ユーザー体験）／UIを通じたシステムの振る舞いの細かな部分までがその対象となります。もちろん、事業者はそういった観点でシステムの専門家・有識者たる技量や経験が必要ですし、事業者はその議論や決定のために日々技術調査や検証を行ったり、プロトタイプやモックの作成を行ったりしつつ、発注者とより良いプロダクト作りに注力することが求められます。

協働を促進するために、事業者を決定した後は、速やかにチームビルドのためのセッションを持つようにしましょう。セッションでは、プロジェクトの目的から、開発する情報システムの特徴、チームに参画するメンバーの役割とコミットメント、プロジェクト内における優先基準、リスク、想定スケジュールなどを確認します。

こうした内容を確認するワークショップとして「インセプションデッキ」作りをチーム、関係者で行うことを推奨します。インセプションデッキについては、第５章「参考情報一覧」の「５.１ アジャイル開発全般」に記載の『アジャイルサムライ』や『カイゼン・ジャーニー』を参考にしてください。

当該プロジェクトでの開発方針を定める

「２.３　アジャイル開発の向き、不向き」で示したとおり、「アジャイル開発」にも進め方や考え方の幅があります。これから始めるプロジェクトにおける「アジャイル開発」とは何なのか、言葉にして、チーム及び関係者と認識を合わせておくようにしましょう。アジャイル開発である狙いや課題、具体的な進め方などは、「本ガイドブックのとおりとする」という周知ではなく、プロジェクトごとに定義しましょう。

チームにおいてアジャイル開発の経験が不足している場合、要件定義フェーズを設置するなど、新たな取組に対する難易度を下げる処置を取るようにしましょう。

全体計画についての認識を合わせる

アジャイル開発だからといってプロジェクト全体の計画が不要なわけではありません。想定スケジュールについての確認や認識合わせを、チーム全体で必ず行うようにしましょう。

計画を確認する際は、マイルストーンの確認を行うようにしましょう。プロジェクトで実施するイベントや報告ごとに(あるいは月単位で)、プロジェクトの断面としてどのような状態になっているのが望ましいのか、チーム全体で確認しましょう。マイルストーンの定義がない場合はこれを作ることから始めましょう。

マイルストーンを設ける上で、「早めに小さく失敗しておく」ということも意識します。アジャイルでは、要件や仕様を詳細化しながら開発するため、MVPとして初期開発したものが目的に合致しないことや、合致していても将来に向けて技術的な「負の遺産」となると想定されること等があります。その場合、MVPそのものを一度破棄して再度作り直すことがあり得ます。そのため、作り直しが発生する可能性を織り込んだマイルストーンを設定し、リスクを低減します。

なお、全体計画の段階で、従来型の開発に慣れ親しんだ方が「最初に決めたものをすべて作る」という姿勢を貫こうとしてしまうことがあります。アジャイルでは、MVPから始めて機能を順次追加して実際に動くものを見て考えや発想を進化させていくので、そのことを前提として、マイルストーンを設定していきましょう。

そして、リリースプランニングにおいて、想定する開発規模に対して必要となるスプリント数を見立てましょう。

チームでワーキング・アグリーメントを決めていく

準備を経て開発を始めてからも、進め方について認識齟齬は生まれるものと考えましょう。チームの活動を行うにあたって、必要なルールや守るべき原則をチームの中で決めても構いません。

ワーキング・アグリーメントとは、チーム活動を円滑なものにするためのチームメンバー同士の約束事です。コミュニケーション上お互いに守りたいことなどを定義し、折に触れて確認し、意識できるようにしていきましょう。

チーム内コミュニケーションの一元化

アジャイル開発では、動くシステムを基に、開発者が利用者（又はプロダクトオーナー）とコミュニケーションを行い、フィードバックを得て開発を進めていきます。このため、チーム内で円滑にコミュニケーションを行えるよう配慮が必要です。チームの組織構造が複雑化して開発チームのリーダー層とプロダクトオーナー支援とのやり取りが増え、開発者とプロダクトオーナーが直接コミュニケーションを取れなかったり、開発を事業者へ丸投げしてコミュニケーションが発生しなかったりといった状況は避けなければなりません。

コラム：アジャイル開発におけるWeb会議を中心としたミーティング

運営の適応

アジャイル開発の本質は、経験したことに基づいて、その次の活動を最適化していくところ（適応）にあります。この適応は、情報システム及びチームそのものにおいて行います。情報システムを開発し動かしてから可視化されることで判明することや改善点を次のスプリントプランニングに反映していきます。また、チームとしても、スプリント・レトロスペクティブ（ふりかえり）を通じて、開発の進め方についてのカイゼンを常に行いましょう。これらの適応を両輪として、プロジェクトを進めていきましょう。

また、全体の計画や理解（インセプションデッキで表現する内容）についても、開発を進めていく上で適宜ふりかえり、目的が果たせているのかを確認しましょう。ふりかえった結果、計画や理解について修整を行う必要がある場合はこれを行い、変更点に対してチーム全体で認識合わせを行うようにしましょう。