公開コンサルテーションでいただいたご意見等と回答
2024/3/31
#1頁

箇所

意見等

回答

52.4 1～2 パラ

この説明は必要？課題は理解できるが、対処法がネガティブな印象を受けた。
まず、アジャイルマニフェストの「プロセスやツールよりも個人と対話を」に逆行しているように読めてしまう。人に「依存」と考えるのではなく、人を「活かす」と考えられないか。
さらに、スクラムをやる目的は再現性を高めるためではない。
「人」と「型」は二項対立ではなく、「人」が考えて改善していくためのベースラインとしての「型」であってほしい。（アジャイルのルーツのひとつであるトヨタ生産方式の「標準」の考え方と同じ）人事異動が多いのは行政機関に限らず民間企業でも同じであるが、「人」に依存したアジャイル開発には期待できないとはなっていない。

削除しました。

7②プロダクトではなく、専門人材の“仕事”を調達する
下から 7 行目

237849596107812表 1 アジャイル
開発において対応が求められる取組み⑤検収を柔軟に捉える
上から 6 行目
3.4. 組織横断的支援として実践されているプ
ロセスの抽出
4.1. 本章の意義
これにより、行政機関や自治体がアジャイル開発の導入・実践の手順やガイドラインを策定するにあたって活用可能な“ガイドラインの素材”を提供する。
図 2 本報告書と他のリソースとの関係
各局 PO の進
捗・課題の把握、調整・相談等"専門人材の工数" →工数といいきっている所が気になりました。
工数なのですが、専門人材の知識とスキルを調達するのかと。契約上は工数ですが・・。
---スクラムガイドよりスクラムを構成するのは、作業に必要なすべてのスキルと経験をグループ全体として備える人たちである。また、必要に応じてそうしたスキルを共有または習得できる人たちである
ウォーターフォール型開発を前提としたプロセス自体をアジャイル開発ベースで考え直した方がいい。
開発チームで作成した基準に基づいて受入を判断することになる。
→スクラムチームで合意した基準に基づいて・・
個人的には、アジャイルはマインド変えていかないといけないので、出島のような組織にしていくのが最初はいいのでは・・と思ってます。

3.2.②「一般的には専門人材の工数」→「専門人材の知識やスキル」に修正しました。

「今後取り組むべき課題」として「ウォーターフォール型開発前提ではなく、アジャイル開発を前提としたサービス開発プロセスの検討」と追記しました。
3.2.⑤「開発チームで作成」→「スクラムチームで合意」に修正しました。
B-1-1 に「⑧組織風土変革：各種の情報発信、“出島”型プロジェクトの企画運営を含む。」を追記しました。

各省庁や自治体個別で作ると、またばらばらなものが出来そう&コストもかかるので、デジタル庁が作ったものを参考にしてテーラリングするとか出来たらよいのかなと。

ご指摘の通りかと思います。ただ、現状ではまだ提示されていないので、デジタル庁の取組みを待ちたいと思います。

アジャイルマニフェストを先頭に入れても。

現状ではガイドライン素材では引用していませんが、今後、引用する場合には追記するようにします。

汎用的なガイドラインとするならば PO に限らなくてよさそう。
課題の把握や調整・相談などはどちらかというと SM の役割。

1

「各局 PO」→個別プロジェクト」に修正しました。

#9頁

箇所

12

各局 PO の進
捗・課題の把握、調整・相談等

アジャイル推進の進捗なのかプロダクト開発の進捗なのかを明示したほうがよい。
ここではどちらかというとアジャイル推進の進捗を指していると推測。
従来の手順は、WF ベースで作られているので、アジャイル開発を前提として見直す必要があるところを強調しても良さそう。

B-1-1. アジャイ
ル開発推進部門の特定

14

B-1-3. 組織横断でのアジャイル開発実践予算の確保

契約は、次の契約がきれて空き時間ができるとチームが解散してしまう、先ほどのベンダー失注も同じですが、安定したチームを継続することがコスト削減と成果を出せることにつながるので、ここの課題定義を協調してあってもよいかもと思いました。

15A-2-1. PO のア
サイン

PO としての責務は、プロダクトの価値最大化、ROI を高めること。(政策が意図した成果をだせているか) KPI 設定してもいいですし、Output 思考ではないよということを伝えれたらと。。

111216141715171716

回答

121013

意見等

ステークホルダー及び開発委託先との協働の姿
勢［方法］開発委託
先候補に対し、プロダクトの規模やスケジュール、ユーザーストーリー（後述）、前提条件や制約条件、MVP*1 部分の要件などの基本要件を示し、概算見積額などの情報提供を求める。
ウォーターフォール型開発とアジャイル開発の２つのパターンで取得しておくと「3.
開発方針の策定」で行うアジャイル開発の採否の判断に役立つ。
プロジェクト間で機動的にリソース（開発チームメ
ンバーの稼働時間など）の融通を可能とする。
A-3-1.概算見積の作成

後者を想定していました。明確にするためにも「各局 PO」→「個別プロジェクト」に修正しました。
「③ルール整備：手順や書式等の整備」に示されていますが、具体的な考え方について、前章「4.4. 注意点」として「①本章の構成とアジャイ
ル開発のプロセスについて」を追記しました。
A-14-1 に「契約等の要因でプロジェクトの中断が続くと開発チームは解散し、復活できなくなることに留意が必要である。」と追記しました。
A-2-1 に「PO としての責務は、プロダクトの価値最大化にあることを明らかにする。」と追記しました。

スクラム用語にするなら開発者。
全体的にスクラムの役割を示す用語「開発者」と契約関係を示す用語「開発委託先」が混在。

開発委託先で一貫させています。

これは実際に機能するのか？
ウォーターフォールとアジャイルそれぞれで概算見積を出してほしいと言われても困惑するベンダがほとんどだと思われる。
通常、開発手法よりも他の条件・パラメータによる見積変動のほうが圧倒的に大きいため。

削除しました。

プロジェクト間、プロダクト間、チーム間いずれにするのかポリシーを決めて用語を統一したほうがよい。

「プロジェクト間」に統一しました。

先ほどお話しした部分。過渡期なので仕方ないかもですが、概算見積りのやり方、枠で予算確保の運営の仕方を工夫しないと、WF 的になってしまいそう。
ユーザーストーリーと MVP はあくまで仮説であって、変更する前提としておくことを浸透できたらと思いました。

2

A-6-1 に「なお、調達時に作成するユーザーストーリーは、確保する専門人材を想定するためのものであり、実際のプロジェクト開始時に再度見直すことになる旨も記載しておく。」と追記しました。

#17

18頁

箇所

意見等

回答

18

一般的には、
MVP 特定までの実証及びUI/UX の改善はアジャイル開発に向くとされる*5。

出典の記載なし？

追記しました。

18

A-4-1. 開発方式の決定

開発方式の選択の際、アジャイル開発とローコード開発の親和性の高さも判断材料として提供しておいてはどうか。

自治体におけるローコード開発の２／３はアジャイル開発で行われているとの調査結果もある旨を［参考］に追記しました。

1918A-4-1. 開発方式の決定

2021A-5-1.案件毎の探索

2122232222222324

アジャイル開発では、プロダクトの仕様を確定しない。
仕様書に替えて、プロダクトの作成を通じて実現したいことを複数のユーザーストーリーとして記述する。

A-6-1. ユーザーストーリーの作
成

A-7-1. 事業者がアサインすべき専門家の条件を明示する。

ウォーターフォール型とアジャイルの関係は“どちらか”ではな
く、gradual（同時・連続的）である。最初の数ヶ月間はユーザーの要求を探るとともに、並行して段階的に要件定義を固めていく。また、ウォーターフォール型開発としてのマイルストーンを定めていく。そしてフェーズごとに成果物とユーザーストーリーをメンバーと共有して行く、といった形になる。
行政機関側から情報発信することも重要。現在は地方であっても特別な不利があるわけでない。例えば最初の 1～2 週間は現地で一緒に取り組み、あとはオンラインで進めることもできる。なお、地方で人材を確保する場合は、IT コーディネーターのような人材で、アジャイルに理解がある人の協力を仰ぐことも考えらえるが、現実には、アジャイルに馴染みがない場合が多い。
表現が誤解を招きそう。
仕様を確定しないわけではなく、直近着手する優先順位の高い PBI は確定しますし、先にやる優先順位の低い PBI は適度に決めておく。
ユーザーストーリーは「会話の約束」と言われるように PO と開発者が会話しながら書いていくことに意味がある。
書き終えたものを文書のみで伝えるのであればユーザーストーリーの要件は満たしていない。
ユーザーストーリーは固定的なものではなく、(a)や(b)の段階ではあくまで予測。(c)において開発が進むにつれて解像度が上がっていき、重要度や取捨選択にも逆転が起こっていく。当初のユーザーストーリーは、あくまで最初のたたき台でしかなく、固定されてしまうものではないということを認識することが必要。ユーザーストーリーは、PO が作って与えるものではなく、開発チームと一緒にダイナミックに変えてゆくものであり、いわばステークホルダーと開発チームのインターフェースであるといってもよい。要求の実現が技術的に難しいから、こういうふうに変えたいというニーズが開発チームにあれば、PO と相談し、理解が得られれば変えていけばよい。こうしたダイナミックなコミュニケーションをするためのツールであり、固定的なものと考えてはいけない。そのことを POだけでなく、ステークホルダーにも教育し、理解してもらう必要がある。段階的に精度を上げていき、時々見積をし直すというプロセスが必要になる。
専門家が備えるべき業務経験及び資格→業務経験には、技術的な知識や経験も含まれると思いますが、見る人によっては行政の業務の経験ととられる場合もありそうなので、知識・スキルのような表現の方がいいかもと思いました。

3［参考］として追記しました。

［参考］として追記しました。

「プロダクトの完成品としての仕様を事前に確定しない」に修正しました。

「概要レベルのユーザーストーリー」とした上で、誤解のないよう［方法(2)］及び［参考］に説明を加えました。

［参考］として追記しました。

A-7-1.
「調達仕様書に事業者がアサインする専門人材が備えるべき知識・スキル、プロジェクト経験及び資格を設定する。」に修正しました。

#頁箇所

意見等

回答

24

A-7-2. 準委任契約に基づくアジャイル開発に対応した調達仕様書を作成する。
A-7-2. 準委任契約に基づくアジャイル開発に対応した調達仕様書を作成する。

先ほどお話しした点。
契約前にどこまで実施するのかの全体プロセスが示されているとわかりやすくなりそう。。とはいえ、今は過渡期なので示さない方がいいのかとも思いました ww。

参考５を追加しました。

一種のマネジメント予備として、特定のスプリントに紐づけないリソースを確保しておくとプロジェクトの成功率が高まる

A-7-3 の［参考］として、左記を追記しました。

非定型の情報共有の仕組み（コミュニケーション環境）を使えるかどうかは入札参画の判断を大きく左右する。
・コミュニケーションツールとしてのチャット・オンラインホワイトボード・テレビ会議システムの３点は使えた方がいい。アジャイル開発が進んでいるところほど、こうした環境が利用できないと参画に後ろ向きになってしまいがち。
レビューによる品質確保のプロセスにも影響する。ユーザーの環境に対象となるドキュメントを置き、それをレビューするのが最も効率的、「非定型のコミュニケーション環境を整えることが望ましい。アジャイ
ル開発が進んでいる企業ほど、参画意欲への影響が大きくなる。特に、ビジネスチャット、オンラインホワイトボード、テレビ会議システムは非常に重要。」と追記しました。

2526272424252829262930

3129303233

34

A-7-2. 準委任契約に基づくアジャイル開発に対応した調達仕様書を作成する。

A-7-2. 準委任契約に基づくアジャイル開発に対応した調達仕様書を作成する。
A-8-1. 準委任契約の契約書の作成（プロジェク
ト単位）A-9-2. チーム
ビルディングPO 支援は、あるべき PO の状態と役割を理解した上でどういう役割とするかを決めないと、うまくいかなくなるので、難しいところですね。PO 代理にならないようにしたいですよね。(ひとりごと)

A-9-2. チーム
ビルディング

私見では行政がこれを推進するには発注者として PO の育成が重要

A-10-1. アジャ
イル開発の計画

プロダクトバックログには、プロダクトゴールが含まれてはいるのですが、プロダクトゴールを外だしして書いてあった方がいいかもしれません。(意識するために)アジャイル開発の成功のポイントはやはりお客様と開発ベンダが一体となって両者の役割を確実に果たしていくことが重要と考えております。お客様 PO のシステム（製品）と業務に対する理解と日々のコミュニケーションが成功のポイントと思います。

30

A-10-1. アジャ
イル開発の計画

31［方法］各プロジ
ェクトにおけるリソースの消化やベロシティの状
況、抱えている課
題を踏まえ、個別プロジェクトの支援やプロジェクト間でのリソースの再配分を行う

準委任契約で契約したとしても、開発委託先でウォーターフォール的に扱われてしまうことも多い。事前に契約内容について開発委託先との間で読み合わせをするなどして十分に本旨を理解してもらうことが重要になる。
チームビルディングは、チームは継続的に実施することが書かれてあってもいいと思いました。

調整役を介するイメージよりは「個別プロジェクト間で調整できるように促す」というような形の方がアジャイルらしい動き。

4

A-9-1.に「特に、PO 支援は、あるべき PO の状態と役割を理解した上でどういう役割とするかを決めないと機能しなくなるので注意が必要。」と追記しました。
［推奨］として追記しました。
A-9-2.に「なお、プロダクト開発後の持続的改善のあり方も想定しておく。」と追記しました。
A-9-2.「チームビルディング」で言及していましたが、見出しからは辿りづらいので、「教育・チームビルディング」に修正しました。
A-2-2 に「［方法］プロダクトビジョン及びそれに紐づくプロダクトゴー
ルを定める。」と追記しました。
A-10-2. アジャイル開発の推進の説明に趣旨を取り込む形で修正しました。

ご指摘の点も含めた個別プロジェ
クト支援に関する内容は B-10-1に、プロジェクト間でのリソース配分に関する内容は B-10-2 に整理し直しました。

#頁箇所

意見等

回答

31A-10-2. アジャ
イル開発の推進①スプリントプランニングの説明が、リファインメントの説明になっています(優先順位づけと完了条件)。スプリントゴー
ルを定めて、スプリントの計画を立てます。
あと、用語としては、完了条件は、受入基準と完成の定義でしょうか？

ここでの用語説明はプロセスの決め打ちにならないよう削除します。
その上で、成果の確認に関する考え方を A-12-1.で整理します。

35

3136

37

38

39

B-10-2. 推進部門によるプログラム管理③スプリントレビューは、プロダクトゴールに対する進捗を確認することを入れてもいいと思います。
全体推進の方は、全体でのノウハウ共有を推進する役割をもつこと加えてもいいかと思いました。

31

A-10-2. アジャ
イル開発の推進

MVP も変化していく。結果として MVP の大部分が変化してしまったとしても、ユーザーがそれに満足していることが証明できているのであれば、問題はない。逆に MVP どおりに構築したとしても、ユーザーの満足が得られなければ、それは良くない成果物となる。

33［方法］（各機関の判断として検収を必要とする場
合は）スプリント
プランニングで完了条件を定め、スプリントレビュ
ーで定めた完了条件の充足確認を行う

スプリントレビューはゲートではない。検収のために必要ならばスプリントレビューとは別に確認の時間を設けた方がスク
ラム用語を別の目的で使うことにより発生する混乱は少ない。

33

33
40

プロダクトの受入テストを行う。

アジャイルでは「受け入れテスト」という用語は別の用途で使われるため、ここは別の用語にした方がよい。

A-12-1. スプリントレビュー

スプリントレビュー
スプリントプランニングで定めたスプリントゴールを達成していることを確認し、実際に動くものを見てプロダクトゴールに向けた改善のアイデアを出す。
検収のあり方と品質確保のあり方について何らかの方向性が出るとよい。
民間企業でも品質確保のあり方は論点となる。
準委任契約に基づく支払の直接の根拠が稼働状況報告となるのであれば、検収の直接の対象は当該報告になるのであって、成果物の確認は善管注意義務を果たしていることを示すための証左として位置付けられるのではないか。
妥当性確認（Validation）のレベルなどは、開発チーム以外がチェックしていく。これはウォーターフォール型開発の場合以上にしっかりと行うことが求められる。プロダクトは与えられた仕様通り定義されるものではなく、ユーザー側が意図しているものなのか、ということが重要になる。スプリントごとにスプリントレビューを行ない、そのたびにユーザーの目的や意図とずれていないかを確認する必要がある。これをチェックするためには、プロダクトバックログとスプリントバックログに DONE の定義を書き込んでもらい、それを満たしていることをチェックしてもらうという進め方になるのではないか。
また、スプリントが進むにつれてデグレが起きていなことを確保するプロセスも重要になる。

41

33

A-12-1. スプリントレビュー

4233

A-12-1. スプリントレビュー

4333

A-12-1. スプリ
ントレビュー5「B-13-1. ナレッジの収集・蓄積・共有」で実施します。

［参考］として追記しました。

検収の捉え方も含め、本項目の記述を全体的に見直しました。

「調達上の受入テスト」に修正した上で、「(注)スクラムでは、プロダクトバックログアイテムが完成の定義にしたがって実装されたことを確認することを受入テストと呼ぶため注意が必要。」と追記します。
成果の確認のあり方も含め、全体的に見直しました。

検収の捉え方も含め、本項目の記述を全体的に見直しました。
検収の捉え方も含め、本項目の記述を全体的に見直しました。

［推奨］として追記しました。

#頁箇所

意見等

回答

35

B-13-1. ナレッジの収集・蓄積・共有

ナレッジ収集したり、全体でコミュニティ運営を推進して、組織のケイパビリティをあげていくことを促進することまで書いてあってもいいかと。

35

B-13-1. ナレッジの収集・蓄積・共有

組織の障害を取り除く推進をしていくのも、アジャイル推進部
門かと思うので、どこかに書かれてあってもよいかと思いました。
(契約、ベンダー、人事異動などの問題など組織課題の解決を推進する役割があるといいと思います)

アンチパターンが示されており、アジャイル開発の真の目的を達成できないことにならないような歯止めにもなれば良いと思いました。
実際に、ウォーターフォールでの開発が多く、突然アジャイル開発が必要となった場合に、IPA の資料等、何かを参考にすると思いますが、知見のあるメンバーに相談できるというのは、大変心強く感じるのではないかと思いました。

B-1-1.
④「ナレッジの収集・蓄積・共有*5：各プロジェクトで得られた経験やノウハウの収集・蓄積・共有」に修正しました。
⑧「組織風土変革：コミュニティ形成、“出島”型プロジェクトの企画運営を含む」を追加しました。
B-10.2.「プログラム管理：全プロ
ジェクトの統括、進行管理、及びプロジェクト運営の推進及び課題解決を行う。」に修正しました。
B-1-1.に「アジャイル開発推進に当たっての課題解決（例：組織間の調整・連携）」を追加しました。
B-13-1 に「アンチパターンや失敗事例、その改善策やリカバリー策などの情報も有用。」と追記しました。
B-13-1 に「現役のアジャイルチームがアジャイル開発経験者など知見のあるメンバーに相談できる体制を作る。」と追記しました。
B-13-1 に「アンチパターンや失敗事例、その改善策やリカバリー策などの情報も有用。」と追記しました。

4445

46

35

B-13-1. ナレッジの収集・蓄積・共有

47

35

B-13-1. ナレッジの収集・蓄積・共有

48

35

B-13-1. ナレッジの収集・蓄積・共有

アンチパターン、あるいは失敗事例とその改善手法等があると、後続の方が喜びそうだと感じました。

6

#頁箇所

4936

A-14-1. 継続的な改善

5036A-14-1. 継続的な改善

51

36

A-14-1. 継続的な改善

意見等

回答

プロダクトオーナーが異動する前提として、課題に対して熱い想いを持つ職員がプロダクトオーナーとして任命されることがベストです。
今回対象としているプロジェクトは３ヶ月～半年を想定していると思いますので、プロジェクトの途中でプロダクトオーナーが異動する可能性は低いと思います。
しかし、今後は以下の２つの観点で、プロダクトオーナーが途中で異動する可能性があり、今後の課題として検討が必要と思います。
(1)サービス公開した後の数年間は改修を続けて機能を強化する(2)大規模システム開発になると数年単位のプロジェクトになる
特に(1)については、東京都の PLAYBOOK で紹介されたサービスにおいて、近いうちに問題として挙がって来ると考えられます。
対策として、以下が考えられますが、どれもベストとは言えません。
(a)プロダクトオーナーを異動させないような人事にする(b)新しいプロダクトオーナーに引継ぎやすい仕組みにする(a)の案として、職員の異動は避けられないとするなら、職員ではなく外部採用した人材をプロダクトオーナーに任命することが考えられますが、以下のデメリットがあります。
・本来は課題を良く知る職員が適任であること→課題への想いが薄くなる
・都度採用が必要になり、他の部署への横展開が難しくなる(b)の案として、インセプションデッキなどでプロジェクトの方向性や当初の想いをしっかりと残しておくことや、ベンダー側の開発者を含めて共通認識を強めておくことで、新しいプロダクトオーナーが想いを共有しやすくなります。また、ベンダー側がプロダクトオーナー補佐を立てておき、新しいプロダクトオーナーをサポートする方法も合わせて行なうと良いと思います。ただしリスクもあります。ベンダーが入札で継続できなくなった場合、プロダクトオーナー補佐や開発者が入れ代わってしまい、引継ぎの大きな阻害要因になります。
総じて、アジャイル開発を適用するシステム開発プロジェクト
は、息の長い利用と改修が想定されます。これまでのシステム開発は「作って終わり」と考えてしまいがちですが、アジャイル開発の世界では、「初版をリリースしてからがスタート」と言われています。継続性の観点で良い仕組みを設けることが、アジャイル開発の本来の効果を発揮することができ、アジャイル開発の定着を促進することになると思います。
「プロダクトが内製化可能なタイプ」→そういったタイプなのかどうか、判断が難しいのではないか。
PO 補佐は PO のバックアップとしてだけでなく、積極的な役割を果たすことも考えられる。この場合、PO 補佐は、ユーザー部門の業務に精通していて、ユーザーの声を引き出せる人であることが重要となる。必ずしもシステムやアジャイルに詳しくなくてもよい。住民やコミュニティの案件であれば、きちんとそうした方と接することができる人であること、利用者とのワークショップなどを、開発チームなどと一緒に、適時に企画できること、行政上の目的がどこにあるのかを理解し、説明できることが重要となる。
プロジェクトに一定程度の時間を取れることが必要である。
特に PO の異動を見据えて PO 補佐をアサインする場合は、PO の意志やビジョンを共有できること、機能の変化にきちんとキャッチアップできることが重要だ。

7

PO の異動リスクを踏まえた形に加筆修正しました。

「内製化可能なプロダクトである場合」に修正しました。

［参考］として追記しました。

#52頁

全体箇所

意見等

回答

-

スクラムを行政機関に合うようにカスタマイズして適用しようとしているのは分かるが、本来のスクラムガイドの解釈を書いた上でカスタマイズや用語の置き換えををした理由を記載しておかないと、スクラムを分かっていない人が書いたと思われてしまい、この資料自体が軽視されてしまう懸念がある。

スクラムの用語利用が我田引水にならないよう注意していきます。

-

開発委託先の立場であえて要望するのであれあば、発注先決定から事業開始までの期間に柔軟性があるとよい。
多くの開発ベンダは労働集約型のビジネスモデルであり、エンジニアの稼働率が直接収益に関係する。入札案件の場合、受注確度が他の商談よりも低いものと見なされる。受注確度が低い案件のために要員の稼働をあけて待つことは難しい。
そうすると、ベンダとしては受注決定後に要員のやりくりをすることになるが、優秀なメンバーほど稼働中の別案件から連れてくるのが難しく、言葉は悪いが調整できた要員の寄せ集めでプロジェクトをスタートすることになってしまう。

A-7-2.に以下を追記しました。
・落札後、実際の開発開始までに一定の準備期間があることが望ましい（受注者がより良いメンバーで体制を組めるようにするため）。

53

全体

54

全体

-

55

全体

-

56

全体

-

論点部分にもあるように実際の運用する際のハードルは高いと感じるので、課題になりやすい箇所の解決につながる案を含んだガイドラインに成長していってほしい。

57

全体

-

アジャイル開発に適した開発内容、不向きな開発内容を具体例を交えて示すことで、自治体様や省庁様でアジャイル開発を導入する案件のイメージがわきやすいと感じました。

58

全体

-

幹部職員や管理職層や教育が重要。

59

全体

-

現場レベルでの浸透やカルチャーづくりも必要。

60

全体

-

ユーザーストーリーは慣れるまで作成するのは難しい。事例が公開されるとよい。

価値をだすことを意識したいので、プロダクトビジョン(政策で意図した成果)を目指し、プロダクトゴール、スプリントゴールを定めてビジョンに向けて取り組むことが入っているとよ
いと思いました。
自治体にはアジャイル開発を行う必要性を訴求し、自治体職員の興味を引き、認識を変えて行くものになればと思っています。

8「A-2-2. プロダクトの企画」という項目を追加し、追記しました。

今後とも訴求するための素材となる情報の収集と認知拡大に努めていきたいと思います。
「今後取り組むべき課題」として「アンチパターンや失敗事例、現場での課題、及びその改善手法などの事例の収集・共有」と追記しました。
「今後取り組むべき課題」として「アジャイル開発に向いている／不向きな開発内容の具体例の収集・共有」と追記しました。
「今後取り組むべき課題」として「多くの行政機関、及び行政機関内の様々な関係者へのアジャイル開発の認知拡大」と追記しました。
「今後取り組むべき課題」として「多くの行政機関、及び行政機関内の様々な関係者へのアジャイル開発の認知拡大」と追記しました。
「今後取り組むべき課題」として「各段階でのユーザーストーリーの粒度、表現方法の検討、事例の提供及び作成方法のガイダンス」と追記しました。